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

[Joseph Salowey (jsalowey]

eap-admin [at] frascone.com <mailto:eap-admin [at] frascone.com> scribbled on :

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

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