RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

On Fri, 26 Aug 2005, Bernard Aboba wrote:

>> 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)
>
> This scheme allows for reuse of the initial Kerberos ticket, at the
> expense of a round-trip between the NAS and AAA server on each handoff.
>
> However, the Kerberos session key is no longer bound to a
> particular NAS -- this is the "Key binding" requirement in
> draft-housley-aaa-key-mgmt-00.txt.
>
> Also, the AAA server now needs to keep a cache of Kerberos session keys.

The Kerberos session key and consequently MK is bound to the EAP server, 
as the Kerberos is terminated at the EAP server, right?  It's a service 
ticket for the EAP server, not a particular NAS, so that would seem 
logical.  The MSKs can be bound to the individual NASes.  Should the NAI 
(or some other identifier) of the NAS be explicitly included in the PRF?

Personally, I don't see how this is any different than any other EAP 
method, once you generate the MK.  Fast handoff in an EAP method, and not 
at the link layer, would have to involve AAA.  Otherwise you would need 
Diffie-Hellman to provide the forward secrecy.  Without it, any NAS 
through which a client roamed would be able to derive their future keys 
and decrypt their sessions.

As for maintaining a cache -- the AAA server would have to maintain a 
cache of MKs for authenticated clients, presumably with some associated 
lifetime.  I'd think any fast reconnect scheme would require something 
similar, unless you were going to authenticate from scratch.

Or, am I missing the point?

[ 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