eap Mailing List: Re: [Issue ] Comments on section 3 of keying draft

[John Vollbrecht (jrv]

--On Wednesday, January 21, 2004 2:11 PM -0800 Joseph Salowey 
<jsalowey [at] cisco.com> wrote:

> Submitter name: Joe Salowey
> Submitter email address: jsalowey [at] cisco.com
> 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.

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.

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

> "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
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap