Subject: [eap] Re: Issue 215: Comments on Section 3 of Key Framework

From: Bernard Aboba <[email-masked]>
Date: Sat, 3 Apr 2004 16:52:42 -0800 (PST)

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: [email-masked]
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.  "
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Sun, 4 Apr 2004 14:15:12 -0700

[email-masked] wrote:
> On part 1, I tend to agree with the comments.  However, to
> make the change we need proposed replacement text.
> 
[Joe] OK, I will work on some text for this. Are you planning on submitting
revisions to section 3 as you did for 1 and 2? if so we should coordinate on
the modifications. 

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

[Joe] That is not what I intended to suggest.  The way the MSK and the EMSK
are generated is method specific. The only thing that is currently specified
in EAP is the length of the key material.  From these keys application
specific master keys can be derived.  The applications must determine how
the application master key is derived from the MSK and/or EMSK, how the key
is transported to where it is used (if this is required) and how the key is
used in the application.  For example there is existing behavior for layer 2
encryption applications:

1. The application specific master key for layer 2 encryption is the MSK
2. The key is transported to the NAS using the RADIUS MS-MPPE-SEND and RECV
key attributes
3. The key is either used as the PMK in 802.11i or directly as the
encryption key in dynamic WEP

Other applications should derive keys from the EMSK to avoid conflicts with
the current MSK usage.  The EMSK is not used directly by applications rather
a standardized key derivation method is used to derive the application
specific master key using parameters specified by the application.  How the
key is transported and used should also be determined by the application.  

It useful to name keys so that two parties can agree upon which key to use.
I think it is best if the key is named by the method that generates it.  The
suggestion is that in addition to the MSK and EMSK the method also exports
an octet string used to name the MSK and EMSK.  Applications may use this
name as the basis to derive names for their keys derived from the MSK or the
EMSK.  

> Document: Keying Framework Comment type: 'E'ditorial
> Priority: '1' Should fix
> Section: Section 3
> 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.
> 
> 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.
> 
> 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
> 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.  "

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 4 Apr 2004 15:39:24 -0700 (PDT)

> revisions to section 3 as you did for 1 and 2? if so we should coordinate on

I will go ahead and post what I have so far for Section 3.  It is quite
rough, but this may help improve it.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap