Fwd: Delegation and Moonshot

[Henry B. Hotz]

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)
>> 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 at jpl.nasa.gov, or hbhotz at oxy.edu