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

[Joseph Salowey (jsalowey]

eap-admin [at] frascone.com 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.  


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