Hi Sam: I have some comments below.
El 09/11/2011, a las 21:53, Sam Hartman escribió: > > [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. What kind of ticket would the RP request? The ticket is for the RP right?. So some trust between the KDC and the RP is required. > > 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. At first sight, the Microsoft's model sounds reasonable to me. The reason is that the RP belongs to the same domain as the resource controller. Unless you consider them in two different domains or there is an assumption where the RP might be attacked or may be impersonated in some easy way. On the other hand, I was wondering why the RP is trusted to receive any information about the user even when a different party (home AAA server) tells the KDC that user is authenticated. The only thing I believe you avoid with this alternative way is that a RP out of control requests authorization information for non-present or non-authenticated users. Is that what you want to avoid? > > 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). Basically what it is described here is a protocol to transport EAP between the RP and the KDC. am I correct?. Moreover it seems that the KDC is acting as a AAA proxy where the transport between the RP and KDC is based on Kerberos. Btw, who is the EAP authenticator here? Apparently, it is still the RP however the MSK does not arrive to the authenticator but to another entity different to the authenticator. AFAIK, RFC 5247 assumes that MSK will reach the authenticator. > > 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. Another possibility is that the key you do not want to export to RP is based on some key derived from the EMSK and allow the MSK to reach the RP. > > 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. Under my point of view (maybe wrong) this imply the definition of a new backend protocol to transport EAP, despite in general we already have RADIUS and Diameter for that purpose. > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] ------------------------------------------------------- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
