>>>>> "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

Reply via email to