[16762] in Kerberos_V5_Development
Re: Fwd: Delegation and Moonshot
daemon@ATHENA.MIT.EDU (Henry B. Hotz)
Wed Apr 6 15:11:20 2011
Mime-Version: 1.0 (Apple Message framework v1082)
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
In-Reply-To: <mailman.685.1302106006.18705.krbdev@mit.edu>
Date: Wed, 6 Apr 2011 12:11:13 -0700
Message-Id: <A10DD59A-8ADA-451E-81D4-F4CDEC895907@jpl.nasa.gov>
To: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Apr 6, 2011, at 9:06 AM, krbdev-request@mit.edu wrote:
> Date: Tue, 5 Apr 2011 13:44:41 -0500
> From: g.w@hurderos.org
> Subject: Re: Fwd: Delegation and Moonshot
> To: Luke Howard <lukeh@padl.com>, krbdev@mit.edu
> Message-ID: <201104051844.p35Iifkq032067@wind.enjellic.com>
>
> On Apr 3, 3:27pm, Luke Howard wrote:
> } Subject: Fwd: Delegation and Moonshot
>
> Good afternoon, hope the day is going well for everyone.
>
>> If you're interested in protocol transition with preservation of
>> authorisation attributes, see below. It allows you to delegate a user
>> authenticated via GSS EAP to Kerberos, whilst preserving the SAML
>> attributes present in an assertion received from a AAA (RADIUS)
>> server.
>
> ..
>
>> I wanted to describe some interesting work in bringing delegation to
>> Moonshot. (Well, at least I think it's interesting :-)) I've tried to
>> keep this as high level as possible, but unfortunately it does require
>> a bit of an understanding of GSS-API, Kerberos and SAML. I've used the
>> terms "client" and "service", but you can read "initiator" and
>> "acceptor" or "peer" and "AAA client". I'm cross-posting to krbdev,
>> because the code involved here is all to do with MIT Kerberos; there
>> are no changes to the Moonshot GSS mechanism.
>
> ..
>
>> We define a new authorisation data type, KRB5_AUTHDATA_SAML, that
>
> ^^^^^^^^^^^^^^^^^^
>> contains a SAML assertion. Moonshot aside, KDCs are free to issue
>> assertions based on their own information. An AAA server that supports
>> services doing "assertion transition" signs assertions with a key
>> shared between it and the KDC. (The AAA service is an ordinary service
>> principal registered with the KDC. The signatures are XML DSIGs as
>> specified by SAML.) In the Moonshot model, the AAA server vouches for
>> assertions that it issues or forwards to the service; here, we extend
>> this to other services in the KDC's realm.
>
> ..
>
>> A service doing "assertion transition" makes a normal protocol
>> transition request to a KDC that has the SAML plugin installed. (A KDC
>> without this plugin will copy the assertion into the response, but the
>> service will not be able to validate it.) The KDC validates the AAA
>> server's assertion signature, verifies that local policy permits it to
>> vouch for the assertion, and returns the assertion in the issued
>> ticket (this time signed with the ticket session key, and ultimately
>> encrypted with the service's long term key).
>
> Very interesting work but I need to catch up a bit. I assume we as a
> community are no longer shouting down the thought of kerberos ticket
> mediated transmission of authorization information as the incarnation
> of evil....? :-)
>
> That seemed to be the case 8 years ago or so when we were working on
> the problem of identity linked service authorization assertions.
> There seemed to be a plethora of issues raised surrounding the
> inability of anything in the ecosystem to handle kerberos tickets
> which enclosed auth_data encoded payloads. If I remember correctly
> the thought of loading any type of XML data as authorization
> information was voiced as profoundly repugnant.
I will own up to being one of those. I still regard the use of XML instead of ASN.1 as ugly in the context of Kerberos. I would prefer an attribute certificate to a SAML assertion.
That said, the use of XML and SAML has increased over the years, and I am bowing out of that battle.
>> From the last pair of quoted paragraphs above it would seem the KDC
> will now be involved in what amounts to authorization policy
> decisions. I'm assuming the KDC will simply issue a naked ticket if
> any aspect of the assertion verification fails?
It seems reasonable to me to issue a bare AuthZ ticket if you lack a way to provide known-valid AuthN data, but see below.
> We had the KDC involved in the authorization process and I distinctly
> remember Sam Hartman's objection that this was a serious security
> problem as it was the KDC's intrinsic duty to always issue a properly
> formed ticket based only on the presentation of an authentication
> credential. I noted with interest when I read all the Moonshot
> documentation that Sam's Painless was engaged for Moonshot's
> feasibility analysis.
IIUC Sam's real position was that adding authorization data could create interoperability problems. Hopefully care is/will be taken so the problems are only DOS, and not incorrect authorization.
> I found it interesting that we now have, potentially, a Shibboleth
> server, an LDAP directory server, a radius server and a KDC involved
> in the authorization decision process. It seems, as an industry, we
> are still fighting complexity problems arising from not having a
> sufficiently refined definition for identity.
Yeah. I have concerns that an RP get the same answer independent of which protocol or interface is used to make an authorization query/decision. In a real deployment there are going to be pieces which can't do things the preferred way and will need to use an alternate interface.
This seems like a classic setup for a downgrade attack. Once the Shibboleth and PAD stuff gets a bit more mature, I think someone should do a BCP on the subject. (I think this is in scope for the authorization data item in the new charter, isn't it?)
>> -- Luke
>
> Best wishes for continued success in your efforts.
>
> }-- End of excerpt from Luke Howard
>
> As always,
> Greg Wettstein
>
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
