Subject: [eap] [Issue ] Comments on section 3 of keying draft

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 21 Jan 2004 14:11:36 -0800

Submitter name: Joe Salowey
Submitter email address: [email-masked]
Date first submitted: 1/21/2004
Reference: 
Document: Keying Framework
Comment type: 'E'ditorial
Priority: '1' Should fix 
Section: Section 3
Rationale/Explanation of issue:

1.  Use of term "security Association":

In section 3 the use of term security association is somewhat
non-standard.  A security association is typically something that is
generated dynamically and valid for a length of time.

[1] The EAP-SA is more of a static relationship such as a trusted root
key.
[2] The EAP-Method SA is more along the lines of standard SA
terminology.  It is not visible outside the EAP-method.
[3] The EAP-Key SA I do not think is really an SA.  There are
EAP-Key(s), but they must be managed outside the EAP protocol since EAP
provides no key management functionality other than establishment.
These EAP-Seeded SAs are managed by some other application separate from
EAP.  Examples of EAP Seeded SA are in section 3.5
[4] The AAA-SA is similar to [1] above in that there is a trusted root
key.

There are also "EAP-Seeded" SAs of which 3.5 is an example

Recommended Changes:

Use a different term than security association for other relationships
or don't discuss them in this section. 

I'm not sure that so much detail is needed for the EAP-Method SA since
it is not visible outside a method.

Create  section on EAP-Seeded SAs which describes Unicast SA and other
possible SA based on the exchanged EAP keys.

DO not use the term EAP SA as it confusing as to what is being
discussed.  

I'm not sure that multicast security association needs to be discussed
as it is usually is derived from a unicast security association and not
directly involved with EAP.

2. Key Naming (Section 3.7)

I think the only thing that needs to be named within the scope of EAP is
the MSK and the EMSK resulting from a particular EAP exchange.  This
needs to be defined by the method. Here is some suggested test

"EAP methods are responsible for defining and exporting a key name.  The
base EAP key name is an octet string between 15 and 31 octets.  To name
the MSK a M is prepended to the base name and for the EMSK a 'E' is
prepended to the base name.   The method for generating a base name is
specific to the method, but it must be unique to each exchange and
cryptographically bound to the exchange.  An example for EAP-TLS is to
take MD5 hash of the two finished messages in the TLS handshake in the
order that they appear.  It is NOT RECOMMENDED that a static function of
the MSK or EMSK be used as publically known name. Other applications may
use the EAP key name to derive names for their purposes that have
additional meaning.  "

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

---

From: John Vollbrecht <[email-masked]>
Date: Thu, 22 Jan 2004 14:12:48 -0500

> possible SA based on the exchanged EAP keys.

I like the approach described here.  I do have a question about whether the 
SA, which is used by 802.11, should be described in an EAP spec.  Perhaps 
it should because EAP is spelling out requirements for EAP methods. 
Perhaps it should because there is no place else.  My question is though, 
if no use of EMSK is included, why include use of MSK?  Also, is there a 
reason, if multiple AMSKs can be derived from the EMSK that the MSK could 
not also be derived from it?

I am not an expert in this area, so this may well be fine.

> needs to be defined by the method. Here is some suggested test
Perhaps some indication of which Server as well as which method would be 
appropriate?   I am not sure exactly what the key name supports, so this 
may be inappropriate.

---

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 22 Jan 2004 15:28:53 -0800

[email-masked] <mailto:[email-masked]> scribbled on :

>> [1] The EAP-SA is more of a static relationship such as a trusted
>> root key. [2] The EAP-Method SA is more along the lines of standard
>> SA terminology.  It is not visible outside the EAP-method.
>> EAP-Key(s), but they must be managed outside the EAP protocol since
>> EAP provides no key management functionality other than
>> establishment. These EAP-Seeded SAs are managed by some other
>> application separate from EAP.  Examples of EAP Seeded SA are in
>> section 3.5 [4] The AAA-SA is similar to [1] above in that there is
>> a trusted root key. 
>> 
>> 
>> Use a different term than security association for other
>> relationships or don't discuss them in this section.
>> 
>> I'm not sure that so much detail is needed for the EAP-Method SA
>> since it is not visible outside a method.
>> 
>> Create  section on EAP-Seeded SAs which describes Unicast SA and
>> other possible SA based on the exchanged EAP keys.
>> 
> 

[Joe] I'm agree that the SA used specifically by 802.11 is a bit too
specific.  I think we need to discuss that there are SAs outside the
scope of EAP that are seeded by EAP.  An example of this is a unicast
security association seeded by the MSK. 802.11 is an example of this,
but I don't think we need to get itno the details. 

Two keys the MSK and EMSK are defined for interoperability with existing
solutions, so the MSK can't really be derived from the EMSK altough an
EAP method could do this internally if it wanted. 

>> I'm not sure that multicast security association needs to be
>> discussed as it is usually is derived from a unicast security
>> association and not directly involved with EAP.
>> 
>> 
>> I think the only thing that needs to be named within the scope of EAP
>> is the MSK and the EMSK resulting from a particular EAP exchange.
>> This needs to be defined by the method. Here is some suggested test
>> 
[Joe] SO I think the name just needs to identify keys created by EAP.
If additional scoping of the name outside of EAP to a particular server
or somethingelse then this should be handled outside EAP in the
application that requires it.  I think the same applies to a method,
although I don't have a particular use case in mind.

>> "EAP methods are responsible for defining and exporting a key name.
>> The base EAP key name is an octet string between 15 and 31 octets. 
>> To name the MSK a M is prepended to the base name and for the EMSK a
>> 'E' is prepended to the base name.   The method for generating a
>> base name is specific to the method, but it must be unique to each
>> exchange and cryptographically bound to the exchange.  An example
>> for EAP-TLS is to take MD5 hash of the two finished messages in the
>> TLS handshake in the order that they appear.  It is NOT RECOMMENDED
>> that a static function of the MSK or EMSK be used as publically
>> known name. Other applications may use the EAP key name to derive
>> names for their purposes that have additional meaning.  "
>> 
>> 
>> [email-masked] http://mail.frascone.com/mailman/listinfo/eap
> 
>