Fwd: Delegation and Moonshot
Henry B. Hotz
hotz at jpl.nasa.gov
Wed Apr 6 15:11:13 EDT 2011
On Apr 6, 2011, at 9:06 AM, krbdev-request at mit.edu wrote:
> Date: Tue, 5 Apr 2011 13:44:41 -0500
> From: g.w at hurderos.org
> Subject: Re: Fwd: Delegation and Moonshot
> To: Luke Howard <lukeh at padl.com>, krbdev at mit.edu
> Message-ID: <201104051844.p35Iifkq032067 at 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)
>> 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 at jpl.nasa.gov, or hbhotz at oxy.edu
More information about the krbdev