RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

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

As noted in the EAP Key Framework document, the EAP layer does not cache 
exported EAP keying material, either on the client or the server.  Caching 
is only permitted in the lower layer (AAA is a lower layer from the EAP 
perspective). 

Several proposed fast handoff schemes require caching on the AAA server, 
including pre-emptive handoff and key request. 

However, AAA servers today do not cache EAP keying parameters  -- they discard 
all EAP keying material (not just the transported keying material) once they 
send the MSK to the NAS.  So asking the AAA server to implement a key 
cache is a significant change from the existing architecture. 

This doesn't mean it can't or shouldn't be done -- but a change that 
substantial shouldn't be done on an adhoc basis.  Some open questions:

a. How does the peer know what AAA server it is dealing with?  The EAP Key 
Framework has added the Server-ID parameter to enable the peer to know 
this, but not all EAP methods define this parameter.  Do we want fast 
handoff to only be supported for methods with a defined Server-ID? 

b. How does the peer request that the NAS contact a particular AAA server 
(either for requesting a key or validating a ticket)?  Does it include the 
Server-ID in the message? 

c. How does the AAA server validate that the ticket is being used by the 
EAP peer that it granted access to?  Do we require that the peer NAI be 
the same as the Kerberos Principal name of the peer?  Do we require that 
the Server-ID be the same as the Kerberos Principal name of the AAA 
server? 

d. How does the peer know whether a particular NAS is configured to 
connect to a AAA server from whom it has received a ticket?  

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