eap Mailing List: Re: Issue 215: Comments on Section 3 of Key Framework

[Bernard Aboba (aboba]

On part 1, I tend to agree with the comments.  However, to make the change
we need proposed replacement text.

On part 2, I don't believe that the exported portion of the EAP key
hierarchy can be method-specific (MSK, EMSK, IV and keys derived from
them). That would introduce method dependencies into both the AAA and
Secure Association Protocol, which would violate one of the EAP
invariants -- method independence.

----------------------------------------------------------------------
Issue 215: Comments on Section 3 of Key Framework
Submitter name: Joe Salowey
Submitter email address: jsalowey [at] cisco.com
Date first submitted: 1/21/2004
Reference:
http://mail.frascone.com/pipermail/public/eap/2004-January/002170.html
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.  "