>>>>> "Alejandro" == Alejandro Perez Mendez <[email protected]> writes:
Alejandro> El 10/11/11 13:19, Josh Howlett escribió:
>>> All this is possible for GSS-EAP, but it's starting to look kind
>>> of complex in terms of generic gss-preauth:
>> 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.
Alejandro> Hi Josh,
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> You can consider the KDC
Alejandro> as another RP withing a realm. On the second place, the
Alejandro> use of FAST to protect the transport may result redundant
Alejandro> for many authentication mechanism (for example, EAP where
Alejandro> no assumptions are made on the security of the transport
Alejandro> layer), introducing unnecessary round trips and
Alejandro> computational effort (FAST requires a DH to be
Alejandro> performed).
FAST does not require a DH, especially if it is being used to secure
only the path between the RP and KDC.
Depending on how a client used it, FAST might require a DH if you run
the FAST tunnel from the KDC back to the client.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
