RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

On Fri, 26 Aug 2005, Josh Howlett wrote:

> --On Thursday, August 25, 2005 23:40:04 -0700 Bernard Aboba 
> <aboba@internaut.com> wrote:
>> 
>> In all the EAP Kerberos proposals I've seen the method is terminated on
>> either the NAS or AAA server, but not both.  But in any scenario, the
>> NAS still needs to support Kerberos, in order to validate the "network
>> access" service ticket.
>
> Just to clarify - it would be possible for the AAA server to authenticate 
> against the KDC and return an EAP-Success to the NAS as per other EAP types, 
> without the NAS needing to understand Kerberos. However, the NAS would need 
> to understand Kerberos in order to allow a service ticket to be used for, ie, 
> fast reconnect (...which is undesirable for secret hygene).

Using NAS-terminated Kerberos for fast handoff/reconnect is probably not a 
good idea due to the round trips, unless the NAS service ticket could be 
preemptively acquired.

I think EAP-Kerberos should be terminated at the AAA server.  Your service 
ticket is for "network access", not a particular NAS.  The key contained 
within the service ticket could be used to bootstrap the traditional EAP 
keying.  If you wanted fast reconnect or fast handoff, you could build it 
into the method by computing something like:

   initial key generation:
     MK = PRF(service key, "master key", nonces)
     MSK_1 = PRF(MK, "master session key", nonces)

   handoff:
     MSK_2 = PRF(MK, "new master session key", MSK_1 + nonces)

Then the NAS doesn't need to know anything about Kerberos.

[ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

_______________________________________________
SECMECH mailing list
SECMECH@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/secmech