Subject: [eap] EAP key naming

From: [email-masked] (Tschofenig Hannes)
Date: Thu, 10 Jul 2003 11:53:43 +0200

hi joe, 

if i look at russ's requirements and then look at your draft 
http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-02.txt
then i am not sure whether the requirements are met / are applicable. 

in your proposal you use the keying material based on the previous eap
exchange to create this protected tlv. if you compare this with the
handshake done in the ieee 802.11i 4 way handshake then there is some
difference there. 

for me that is just fine. currently the requirements address the following
protocols: 
a) the eap exchange itself 
b) the aaa protocol and
c) the protocol which uses the keying material afterwards ((this is probably
the most difficult part which was not discussed in detail so far) 

the characteristics of the protocol where eap should provide keying material
will most likely vary a lot. 
hence i would like to better understand the requirements with regard to the
different protocols that utilize the eap derived keying material.

some examples of protocols which use the eap established keying material
are: 
- ieee wlan environment
- your protected tlv or the
http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt
- pana
- pana dhcp bootstrapping
- pana ipsec establishment, 
- etc. 

ciao
hannes

btw, i never fully understood your draft
http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt. a
number of protocol in the past proposed (e.g. pana, sip, some proposals in
the 3gpp, pic, etc. etc.) to use eap to create keying material. since these
protocols vary (as argued above) in their characteristics and requirements
it will not work to define a single key derivation function for all of them.

an example: jesse proposed to include certain identities into the key
derivation. these identities heavily depend on the underlying protocol (e.g.
sip uses different identities than wlans)

should the draft be seen as a guidance?

ciao
hannes

> -----Original Message-----
> From: Joseph Salowey [mailto:[email-masked]]
> Sent: Thursday, July 10, 2003 8:05 AM
> To: 'Walker, Jesse'; 'Bernard Aboba'; [email-masked]
> Subject: RE: [eap] EAP key naming
> 
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > On Behalf Of Walker, Jesse
> > Sent: Wednesday, July 09, 2003 1:52 PM
> > To: Bernard Aboba; [email-masked]
> > Subject: RE: [eap] EAP key naming
> > 
> > 
> <snip>
> 
> > 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).

> <snip>
> 
> That's my two cents, for what it is worth.
> 
> -- Jesse
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 

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

---

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

Hi Hannes,

Thanks for taking a look at this, comments below.

> From: Tschofenig Hannes [mailto:[email-masked]] 
> Sent: Thursday, July 10, 2003 2:54 AM
> To: 'Joseph Salowey'; 'Walker, Jesse'; 'Bernard Aboba'; 
> [email-masked]
> dtlv-02.txt
[Joe] I may have misled you here. The protected TLV is an application of
cryptographic key material established through the EAP authentication
process.  Its scope is much smaller than the general EAP key
distribution problem.  It is useful in extending the EAP exchange in a
consistent way.  

> in your proposal you use the keying material based on the 
> previous eap exchange to create this protected tlv. if you 
> compare this with the handshake done in the ieee 802.11i 4 
> way handshake then there is some difference there. 
> 
[Joe] true, but it is solving a different problem.

> c) the protocol which uses the keying material afterwards 
> ((this is probably the most difficult part which was not 
> discussed in detail so far) 
> 
[Joe] Protected-TLV has to do with c, it is a usage of EAP derived
keying material.

> the characteristics of the protocol where eap should provide 
> keying material will most likely vary a lot. 
> hence i would like to better understand the requirements with 
> regard to the different protocols that utilize the eap 
> derived keying material.
> 

[Joe] The EAP key derivation draft has much broader applicability than
protected-TLV. It is mostly focused on derivation of keys from the EMSK.
There are several reasons for using the EMSK:

1. There is no guarantee on how the MSK will be used currently so
deriving keys from it is a dangerous game. The original WEP
specification is a case in point.
2. The MSK is known by the NAS so anything derived from it is known to
the NAS.  This does not provide separation between the NAS and other
consumers of EAP key material.

I think it is reasonable to use the EMSK for all applications that are
not link layer ciphering.  

> http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deri
> v-01.txt. a number of protocol in the past proposed (e.g. 
> pana, sip, some proposals in the 3gpp, pic, etc. etc.) to use 
> eap to create keying material. since these protocols vary (as 
> argued above) in their characteristics and requirements it 
> will not work to define a single key derivation function for 
> all of them.
> 

[Joe] So while I agree that the needs of all applications are not met by
a single KDF, I think the KDFs for applications need to be coordinated.
This coordination is needed to eliminate the possibility of deriving
keys that do not have good cryptographic separation.  Fundamentally all
of these applications require some shared key material to start with.
The key derivation draft describes how you arrive at a shared key that
is unique for an application and has a some independence from other keys
derived for other applications.  Once you have this application master
session key (AMSK) you can use it to derive other keys for various uses
(TSKs).  This derivation is application specific and not defined in the
draft so it can meet a wide variety of needs. 

> an example: jesse proposed to include certain identities into 
> the key derivation. these identities heavily depend on the 
> underlying protocol (e.g. sip uses different identities than wlans)
> 

[Joe] This can be accomplished in one of two ways.  Either derivation of
AMSK from the EMSK can take the application specific data (this is
partially specified in the draft).  Or when the TSKs for the application
are derived from the AMSK the can use a key derivation that incorporates
this information. 

> should the draft be seen as a guidance?

[Joe] The draft is more than a guidance, but it does not specify every
thing need to derive keys for an application.  The draft specifies how
to get one or more AMSKs from the EMSK in a way that maintains the
secrecy of the EMSK and provides separation between each of the AMSKs
(and the MSK as well if the EMSK and MSK are independent).  This is
important so that if any of the application keys are compromised it does
not directly lead to the compromise of any of the AMSKs or MSK.
Applications are then free to derive there own TSKs from the AMSK in any
way the see fit, and use them is any way they want.      

This is not to say that what is in the drafts cannot be improved upon.
We are looking for feedback on how they can be improved to meet security
and application requirements.

Hope this helps,

joe

> > environments you define an EAP extension (for example an EAP-TLV 
> > message with a Channel-Binding TLV) to carry this 
> information.  It is
> http://www.ietf.org/internet-drafts/draft->
salowey-eap-key-deriv-01.txt
> 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).
> 
> > <snip>
> > 
> > [email-masked] http://mail.frascone.com/mailman/listinfo/eap
> > 
>