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

I guess you meant GSS-EAP preauthentication fast factor, right?


     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.

But I was talking about using Moonshot as the authentication mechanism for the KDC (as we did in draft-perez-abfab-gss-eap-preauth), thus, you would need anonymous PKINIT to establish an ad-hoc securized channel between the user and the KDC.

Regards,
Alejandro


_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab

Reply via email to