Subject: [eap] EAP key naming

From: [email-masked] (Walker, Jesse)
Date: Thu, 10 Jul 2003 08:10:26 -0700

Joe:

> > In the case of 802.11, what is important is the right key 
> > gets delivered to the right AP, and never to any other party 
> > whatsoever. Vis-a-vis the binding discussion, this translates 
> > into a requirement for the EAP Server to be able assert that 
> > the key is bound to the pair <STA MAC Address, AP MAC 
> > Address>, because that is the only meaningful key identifier 
> > at the MAC layer. This is what the Bindings field is for in 
> > the Archie Response and Confirm messages. An alternate 
> > approach might be to modify EAP directly to convey this 
> > information instead, since your standard run-of-the-mill EAP 
> > method does not have this exchange built in like Archie does.
> > 
> > For other cases besides 802.11, mileage will vary; how to do 
> > the binding will be protocol specific.
> > 
> 
> [Joe] This is one area where chaining of additional messages after an
> EAP method can be really useful.  Instead of having each method having
> to define channel bindings and other bindings for n different
> environments you define an EAP extension (for example an 
> EAP-TLV message
> with a Channel-Binding TLV) to carry this information.  It is
> authenticated and possibly encrypted using keys derived from the EMSK
> (shared only between the EAP-Peer and EAP-Server).  This 
> extension could
> be used with any key deriving EAP method.  These two drafts 
> provide some
> of the framework for this:
> 
> http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt
> http://www.ietf.org/internet-drafts/draft-salowey-eap-protecte
> dtlv-02.tx
> t
>
> What is left is to define a channel-binding-TLV (I think Jose may have
> one in his binding problem draft, if not I have one sketched out based
> on archie) and resolve the chaining issue (this requires a little bit
> more work).

I can live with a chained EAP method that is just to establish bindings, if we can work out the security.

If the original EAP method meets the synchronization requirement, then it will not complete successfully if a man-in-the-middle between the EAP Peer and EAP Server disrupts it. So the binding information between the EAP Peer and EAP Server can be protected by the derived MK.

What is not clear in this scheme is how the NAS is protected when the bindings are decoupled from the original authentication. Perhaps the NAS always should send its view of the bindings with every EAP method. If the EAP Server is checking for bindings inconsistencies, then these will either match the later chained method or it will not, and the EAP Server will be able to make an appropriate assertion at that time. I don't know; I haven't thought it through. The requirement is the EAP Server should be able to assert that the MSK is bound to identities the EAP Peer and NAS will verify as part of MSK usage.

-- Jesse

---

From: [email-masked] (Joseph Salowey)
Date: Thu, 10 Jul 2003 09:54:55 -0700

Hi Jesse

<snip>
> 
> I can live with a chained EAP method that is just to 
> establish bindings, if we can work out the security.
> 
> If the original EAP method meets the synchronization 
> requirement, then it will not complete successfully if a 
> man-in-the-middle between the EAP Peer and EAP Server 
> disrupts it. So the binding information between the EAP Peer 
> and EAP Server can be protected by the derived MK.
> 
> What is not clear in this scheme is how the NAS is protected 
> when the bindings are decoupled from the original 
> authentication. Perhaps the NAS always should send its view 
> of the bindings with every EAP method. If the EAP Server is 
> checking for bindings inconsistencies, then these will either 
> match the later chained method or it will not, and the EAP 
> Server will be able to make an appropriate assertion at that 
> time. I don't know; I haven't thought it through. The 
> requirement is the EAP Server should be able to assert that 
> the MSK is bound to identities the EAP Peer and NAS will 
> verify as part of MSK usage.

I think I see what you are getting at, but I'm nto sure I completely
follow it. As you mention the binding information is protected by a key
that is derived from the MK from the authentication exchange.  When the
binding is run the verification is checked and should fail immediately
if the varification fails. However I agree that there is some more
thought that needs to go into this.  A diagram might help I'll try to
get something together 

Some of the difficulty has to do with the intracacies of chaining.  If
the chaining appears as one EAP conversation then the NAS information is
typically provided in every RADIUS message in the called and calling
station IDs which should be consistent trought the conversation.   In
the case that chaining is achieved as two separate eap conversations
then there must be a way to associate one conversation from another.
This is where naming would be really important! 

> 
> -- Jesse
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>