Delegation and Moonshot

[Nico Williams]

On Sat, Apr 2, 2011 at 6:47 AM, Luke Howard <lukeh at padl.com> wrote:
> 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.
>
> So, delegation is useful when you have ono service that needs to contact another on behalf of a client, and you want to do end-to-end authentication. For example, consider a webmail service that gateways to an IMAP server. I'm sure there are more interesting examples.

I don't mean to take anything away from this amazing work you've done,
but, credential delegation writ large is simply scary.  Better to
design services that don't require it.  For example, in the particular
case you mention of web gateways to mail services just trust the web
service fully and be done -- incredibly undesirable if the two
services are not run by the same organization, but then, would you
really delgate access to your mailboxes to a party other than the one
that runs them?!

THAT said... I would be particularly interested in your model of
attribute delegation coupled with MAC (Mandatory Access Controls).
Indeed, if the KDC (or whatever) can enforce policies to limit what
attributes can be delegated to services, then you have everything that
you need to call it MAC (well, almost: you still need access controls
performed by the back-end services to disallow the user the ability to
modify MAC controls).

That is, if credential delegation is at all necessary, then I'd like
it to be subject to MAC-like constraints.

Note that when I say "MAC" I don't mean MLS (multi-leve security)
necessarily -- I have Smack in mind in particular.  (In Smack label
dominance is policy driven rather than algorithmic.)

> [...]
>
> What happens if the client authenticated with another protocol, such as GSS EAP? (For example, Moonshot in Firefox.) Well, it turns out there's a solution for this, too: protocol transition. This allows a service, trusted by the KDC to have authenticated a client by some other means, to acquire a ticket to itself; that ticket can then be used for constrained delegation to another service. The protocol is a variation on the normal ticket request protocol, including an additional field indicating the client on whose behalf the service is acting.

Note that "a service, trusted by the KDC to have authenticated a
client by some other means" is a stunningly large degree of trust --
larger even than traditional Kerberos credential delegation.  However,
if the protocol transition involved signed SAML attributes...  I know,
that's where you're going with this :)

> This is all very well, but protocol transition only provides a ticket with the client's name; the rich authorisation semantics provided by SAML in Moonshot are lost. Here's a proposal to allow protocol transition with "assertion transition". Apart from a couple of bugfixes, it doesn't require any source-level changes to MIT Kerberos (and the bugfixes are in the libraries only, not the KDC). The remainder is provided by two plugins: a library plugin that runs on the services, and a KDC plugin.

Very cool.  (Also, a complete vindication of pluggable architectures!)

> 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.

Right, so the XML signatures are key to constraining the degree of
trust the KDC must have in the services in question.  Excellent.

> [...]
> The delegating service will receive a ticket from the client to the delegatee, which it submits in its application protocol (for example, IMAP). The backend-server can thus make authorisation decisions based on the attributes in the original assertion sent by the AAA server. In the IMAP example, this might determine which folders you're allowed to access.

It'd be useful if the attributes delegated in this way could be
winnowed according to policy at the AAA server.  Is that possible?

> The service itself just needs to do the following:

Right, quite simple.  BTW, do we want to be able to gss_store_cred()
impersonation credentials?  I believe some will.  E.g., if you need to
use secure NFS, AFS, ... as the client, then you have no way to pass
the desired credential handle to the NFS or AFS client.  Being able to
create a PAG or keyring, or whatever, then store the credential there,
where the NFS or AFS client will find it, is a very good thing.  Where
the impersonation credential is a Kerberos one this is already taken
care of.  For other mechs it'll be something to think about.

> The backend-service then does:
>
>        // authenticate Kerberos client
>        do {
>            gss_accept_sec_context(&client_name); // establish GSS EAP security context
>        } while (status == GSS_S_CONTINUE_NEEDED);
>
>        gss_get_name_attribute(client_name, "some attribute");
>        gss_get_name_attribute(client_name, "some other attribute");

This reminds me.  In my original naming exts proposal I had an API for
"mapping" the attributes that appear explicitly to other attributes.
My goal was to export to the app the signed attribute payloads (PAC,
...) and then probide a way to extract the individual attributes'
values that are of interest to the app (SIDs, ...) and even map them
to other things that are locally meaningful (UIDs, GIDs, ...).

Given the raw attribute payloads, there's no reason for the mapping
API to be part of the GSS-API.  Except it'd be convenient to have one
family of specs (GSS) and one implementation provide both, the GSS-API
and the attribute mapping API.  Thoughts?  Should we revive that
mapping API?

> If the delegating service wants to use anonymous names, then it's a few more lines of code (because you need to create a new name and copy the assertion explicitly), but if this was a common pattern we could probably do something (maybe overload the credential usage flags in gss_acquire_cred_impersonate_name(), or add a pseudo-mech to gss_canonicalize_name() that anonymised then canonicalised).

Agreed.  Not a big deal (either way).

> The observant reader will notice that there is some overlap with the fast reauthentication support provided by Moonshot, where the service mints a ticket to itself for use in subsequent authentication. This ticket cannot be used for constrained delegation, because it is not signed by the KDC. It is true that the service could use protocol transition to generate this ticket. I'm not sure at this stage whether this confers any advantages though (it requires changes to the Moonshot mechanism, and it requires a round trip to the KDC even if delegation is not desired). Sam will probably have more to say on this.

That additional round-trip is not desirable, IMO.

Awesome work Luke!

Nico
--