Fwd: Delegation and Moonshot
g.w at hurderos.org
Tue Apr 5 14:44:41 EDT 2011
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.
>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?
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
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.
> -- Luke
Best wishes for continued success in your efforts.
}-- End of excerpt from Luke Howard
"Because the innovator has for enemies all those who have done well
under the old conditions, and lukewarm defenders in those who may do
well under the new."
-- Niccolo Machiavelli
_The Prince_, Chapter VI
More information about the krbdev