Hi Sam: Besides Alex's comments, I believe I had provided some clarifications to these questions in:
http://www.ietf.org/mail-archive/web/abfab/current/msg01098.html Since there was no answer back, I thought it was clarified. Otherwise, I would suggest to read it to see if there is agreement on the comments. Having said that, we already sketched/discussed (http://www.ietf.org/mail-archive/web/abfab/current/msg00040.html) an EAP pre-authentication over KRB solution without using GSS-API, with the same goal: to define a flexible pre-authentication mechanism for Kerberos. If the WG considers more interesting to re-take this line of work providing an EAP pre-authentication in Kerberos, we can collaborate in defining it. Regarding your use case, our intention has not been to define any transport for EAP in the backend. Again, if the WG believes this should be considered as well (I hope we all agree that they are completely different goals), then people interested on it (maybe Josh and you) may contribute in defining it. Best regards. El 25/01/2012, a las 19:50, Sam Hartman escribió: >>>>>> "Alejandro" == Alejandro Perez Mendez <[email protected]> writes: > >>>> * Added motivation section indicating why this is required. >>> This is a definitely a good addition; however, I don't believe >>> that it is complete. Ideally I think it needs to consider the >>> questions that I raised previously in the context of the previous >>> discussion that Sam initiated about generic gss pre-auth versus >>> gss-eap pre-auth: >>> >>>> What are the practical benefits of a generic gss pre-auth >>>> mechanism when Kerberos pre-auth itself provides an extensible >>>> framework? I can see that there is value in the re-using >>>> deployed gss mechanisms if this avoids having to create >>>> functionally-equivalent but redundant pre-auth mechanisms in the >>>> case where an equivalent gss mechanism already exists, but are >>>> there really so many of these that this is a compelling >>>> argument? It sounds as though there is potentially a trade-off >>>> that we could make between complexity and generality. >>> >>> FWIW I haven't developed an opinion on these yet, but I would be >>> interested to hear if you have any... > > > Alejandro> since the principal final purpose of this draft (in > Alejandro> conjunction with the other one submitted to the ABFAB WG) > Alejandro> is to enable the KDC to authenticate users based on the > Alejandro> GSS-EAP mechanism, I don't see any advantage in > Alejandro> transporting GSS tokens on top of FAST. It adds an > Alejandro> additional an unnecessary layer, since nor GSS-API nor > Alejandro> EAP assume any kind of secure transport. > > Josh and I are not asking about FAST. > We're asking about whether GSS-API is the right layer for this. > > To me this is the big open question in whether I personally thing this > draft should be advanced and any discussion you can provide of the > issues I brought up buth in general and with regard to the use case of a > service wanting to obtain a service ticket regardless of client support > would be valuable in making my own determination about this draft. > > --Sam > _______________________________________________ > 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
