Hi Sam: Thanks for these clarifications. My comments inline again.
El 06/09/2011, a las 17:38, Sam Hartman escribió: >>>>>> "Rafa" == Rafa Marin Lopez <[email protected]> writes: > > Rafa> Hi Sam: Please see my comments/questions inline. > > Rafa> El 06/09/2011, a las 15:52, Sam Hartman escribió: > >>> >>> Hi. At the mic in Quebec I raised the following issue about GSS >>> preauth and ABFAB. >>> >>> I want to be able to use GSS preauth between the RP and the KDC >>> even if the initiator knows nothing about it. > > Rafa> Could you elaborate a little bit about the motivation related > Rafa> to this and what is the associated issue? > > Sure. > The idea is that you have some resource domain of servers. > You'd like to use GSS-EAP (ABFAB) to access them. > However you want a central place to define policy, perform > authorizations, etc. > You've decided that Kerberos works well for that. > All authentications into the domain must go through the KDC. Only the > KDC can create authorizations. > > You want the initiator to be able to take advantage of a TGT for fast > reauthentication within a domain if the initiator understands how. May we assume that TGT will be involved in a Kerberos exchange later on?. I mean I think that TGT will have to be provided to the initiator somehow ( within GSS-EAP exchange? ) I assume that initiator will have some Kerberos source code implemented to handle the TGT and to request service tickets. Otherwise, having a TGT is useless as you mention. Thus I would assume that initiator has Kerberos source code implemented. is it so unreal that initiator would have a kerberos client?. Another question would be how the TGT will be used by the initiator and how everything will operate... where the keys will be distributed and how etc... > However, you want to work with any initiator. So, depending on > gss-preauth-specific changes to the ininitiator isn't acceptable. Mmmmm this seems to contradict your sentence "You'd like to use GSS-EAP (ABFAB) to access them." no?. At least it is assumed that the initiator has to implement GSS-EAP. So "any" initiator would not work. Also, it would be interesting to know why it may not be acceptable. After all, we are doing changes to include new technology :). > In > particular you don't want to have to bypass the KDC for old initiators. > Services are not trusted to make authorization decisions. Well, if they are old initiators most probably they will implement legacy mechanisms for authenticating services (not even GSS-EAP except, perhaps, Kerberos GSS-API mechanism, for example). On the other hand, services will need to be updated to support this (so no support for old services). Apart from this interesting scenario you mention, I would also like to suggest to analyze another possible case for fast re-authentication, when the initiator has to go through the RP. The idea is simple if we can assume GSS-API pre-authentication mechanism in the initiator and IAKERB. As evident, GSS-EAP would be a potential mechanism to perform the GSS-API pre-authentication as it has been already discussed. Then the initiator will have a TGT and can request service tickets. Initiator (GSS-API pre-authentication mech + IAKERB) --- RP (IAKERB proxy) --- KDC (Acceptor) Here, KDC is also the central point of authentication and authorization. Certainly the assumptions/requirements differ a little bit in both cases but they seem interesting. In any case, I believe it would be good to have a clearer picture of the general goal (e.g. to achieve fast re-authentication in GSS-EAP or so...). Then define requirements for a potential solution and needs. Best regards. > > > >>> >>> That is: gss-eap initiator <-> RP FAST(rp armor key, >>> gss-preauth(gss-eap)) RP <->KDC When that happens: > > Rafa> Before going into detail I would like to understand this flow > Rafa> (at first sight, it vaguely reminded me the use of IAKERB > Rafa> where the RP is IAKERB proxy. But it seems you are pursuing a > Rafa> different thing). It seems that the RP is acting as Kerberos > Rafa> client that uses a GSS-API based pre-authentication mechanism > Rafa> and the content of the gss-api token contains the gss-eap > Rafa> token provided by the user. Is that right? > > Your understanding is correct. > > --Sam ------------------------------------------------------- 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
