Hi Sam: Let me answer this one as well.
El 10/11/2011, a las 15:47, Sam Hartman escribió: >>>>>> "Alejandro" == Alejandro Perez Mendez <[email protected]> writes: > >>> > Alejandro> on the first place, to make the KDC Moonshot-enabled you > Alejandro> need it to support GSS preauth. >>> >>> Or define an EAP preauthentication fast factor. > > Alejandro> I guess you meant GSS-EAP preauthentication fast factor, > Alejandro> right? > > No. > Any preauth mechanism is a FAST factor. > So if there is a GSS preauth there is a GSS and thus GSS-EAP FAST > factor. > > I mean go back to a model where it's EAP between the RP and KDC not GSS. So indeed we would be defining a new type of backend transport protocol for EAP based on Kerberos > > I've been thinking more about this. It's obvious to me that we don't > want to use the same GSS-EAP context between the client and RP that we > do between the RP and KDC, even if we use the same EAP conversation. My > rationale is a bit complicated. One of the big reasons is that the > question of which enctype to use, what GSS-EAP features to use etc > should depend on the RP capabilities not on the KDC capabilities. Also, > (and perhaps this is what Nico's getting at) it simplifies GSS channel > binding between the client and RP. > > This doesn't mean we can't use GSS-PREAUTH; it just means using > GSS-PREAUTH is kind of complicated. > So, like Josh, I'm beginning to ask what GSS buys us in > preauthentication? Let me clarify one aspect about GSS-PREAUTH in Kerberos (http://tools.ietf.org/html/draft-perez-krb-wg-gss-preauth-00). The idea we had when designing GSS preauth in Kerberos is to provide a flexible pre-authentication mechanism for Kerberos based on the multiple mechanism that GSS-API could offer (in particular, the GSS-EAP mechanism can be used as we described in http://tools.ietf.org/html/draft-perez-abfab-eap-gss-preauth-00). In fact, this flexibility was one the advantages we mentioned with respect to the use of EAP packets directly as pre-authentication data in Kerberos, which, by the way, we also described some time ago (http://www.ietf.org/mail-archive/web/abfab/current/msg00040.html). Obviously, the goal of our work is to define a flexible pre-authentication mechanism for Kerberos, but not a transport for EAP in the backend side of the acceptor/authenticator. However, I understand that if the same concept might be used it would really nice but, as I said, goals are completely different under my point of view. Best regards. > _______________________________________________ > 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
