[I think this is a Kerberos discussion mostly, but consider keeping abfab in your reply if your discussion fits the abfab list.]
A month or so ago, I promised to write up a use case in response to an abfab discussion having to do with obtaining a Kerberos ticket as a side effect of a gss-eap preauthentication. As background, Microsoft has a Kerberos mechanism called protocol transition. The idea is that a service authenticates someone using a non-Kerberos means. However, that service still wants to know what the authorization characteristics of that user are. In the Microsoft model, the KDC/directory are always responsible for domain level authorization. In order to obtain authorization information you need a security token; to get one of those in a domain you generally need a Kerberos PAC. There's a lot going for this model. It centralizes policy for the RP organization in one place: the domain controller for the resource domain. We had several discussions at the MIT Kerberos Consortium's conference last year about how valuable this is, and about how if we can maintain this in the federated context, Kerberos could be an important policy mechanism for the cloud. I'd like Moonshot (the GSS-EAP implementation I'm working on) to be able to support this model. One thing we can do is just use protocol transition as it's specified in Microsoft's extensions today. You do a GSS-EAP authentication to the RP, the RP asks the KDC for a ticket, life goes on. The problem with this is that protocol transition is relatively weak from a security standpoint. The service makes an assertion to the KDC that authentication happened. This can be a privacy exposure to a certain extent: the service needs to be trusted to obtain authorization information for any user who might authenticate to it regardless of whether they have. Microsoft has accepted this; some environments may not. Another problem is that the resource domain controller may not have the information needed to construct authorization information in a GSS-EAP federation. SAML or RADIUS or Diameter information may be necessary. Now, the KDC could trust the service to disclose the information, or could possibly rely on SAML signatures. Trusting the service that much seems a big stretch. Relying on SAMl signatures viloates the one-trust-infrastructure design principle. In particular, it's generally a bad idea for a security system to force deployers to set up more than one trust infrastructure because those are very expensive. If we're using GSS-EAP we already have AAA trust. We should use that. so, somehow, we need to get the KDC as a trusted intermediary in the GSS-EAP authentication. Note that we don't want to depend on any particular initiator functionality. the RP needs to interact with the KDC for its own purposes regardless of whether the initiator has ever heard of Kerberos. I had originally thought about an EAP pre-authentication mechanism to accomplish this goal. The idea is that gss-eap would take EAP packets out of its incoming tokens and send them to the KDC as part of a fast-armored AS-request. The client would be ambiguous--somehow determined by preauth and the service would be the RP. The service would not learn the MSK, but could be told the GMSK (GSS-EAP key). If I could figure out a way to do this with gss-preauth and gss-eap then I'd support gss-preauth. Conceptually, I guess what's going on here is that you want to export a context from the KDC and import it on the RP. However, we don't want to expose the MSK to the RP so that if we are doing something that exposes a TGT to the initiator we have a key to use. So, this involves probably some changes to GSS-EAP and to the preauth type. GSS-EAP probably needs to gain a standardized exported context and the GSS preauth needs to gain a way to transfer an exported context token if the mechanism supports the appropriate attribute. Or something like that. I'd appreciate comments on this use case and once we understand the use case I'd like to talk about mechanisms for getting there. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
