El 25/01/12 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.
Hi Sam,
I don't see why the applicability of this proposal to a very specific
use case should influence on its adoption.
The draft proposes a pre-authentication mechanism based on GSS-API. It
may be useful for many use cases other than the one you proposed.
Specifically, it is required for the use case proposed in
draft-perez-abfab-eap-gss-preauth.
If it does not correctly address the requirements of the use case you
have in mind, I can agree it may not be the most adequate selection for
that specific use case. But as I see it, it does not directly convert it
into unusable, as other use cases can still be satisfied using it.
Best regards,
Alejandro
--Sam
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
