eap Mailing List: RE: Issue: Proposed Different organization for the keying d raft

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi,

I am not proposing any restructuring. As a consumer of the draft (just tried to 
read it last week), I like to suggest that the draft includes generic 
description of how the keys in the hierarchy are derived from each other, 
without requiring the reader to know all the key management details of TLS/ 
EAP-TLS/ 802.11i. I did try to go through appendices, but they rely too much on 
examples to describe the key derivation process. Examples are useful but after 
the generic method is described. That would make the spec more user-friendly. 
The name of the draft is "key management" after all. 

Thanks,

Madjid

-----Original Message-----
From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On 
Behalf Of Jari Arkko
Sent: Tuesday, October 19, 2004 3:59 AM
To: Joseph Salowey
Cc: eap [at] frascone.com
Subject: Re: [eap] Issue: Proposed Different organization for the keying draft


Joseph Salowey wrote:
> Submitter name: Joe Salowey
> Submitter email address: jsalowey [at] cisco.com
> Date first submitted: 10/18/2004
> Reference:
> Document: Keying Framework
> Comment type: E
> Priority: 1
> Section: All
> Rationale/Explanation of issue:
> 
> The current EAP keying framework contains a lot of good information, 
> however it is somewhat difficult to read and understand.  I believe 
> this is because it mixes issues that have to do with 802.11, handoff 
> schemes and EAP method internals without clearly explaining what is 
> expected of the external behavior of EAP methods.  In addition I think 
> some of the material would be good to have in a standards track 
> document.

Agreed.

> Requested change:
> 
> Section 1 - External behavior expected of EAP methods and Frameworks
> 
> 1.1 - Generated key material: MSK and EMSK
> 1.2 - Exported key material: MSK, AMSK and AAA-Key
> 1.3 - Derivation of AMSK from the EMSK
> 1.4 - Identifying an instance of EAP method execution and naming keys 
> 1.6 - MSK and EMSK lifetime 1.7 - Key Request Considerations
> 1.8 - Security Considerations

I think this looks good.

Would your 1.8 include current sections 5 and 6?  I'm asking because I'd still 
like to retain the "system level" nature of the document. Note: I don't think 
having a system viewpoint means the same thing as "mixing" that you mentioned 
above. As the document stands currently, there's a lot of detailed information 
about what particular methods or link layers do in the body of the document. I 
think we want to keep the general part of this -- such as the security 
requirements -- but move the details somewhere else.

> Section 2 - Internal key generation for EAP methods (informative) 
> Section 3 - Example using keys in ciphering applications such as 
> 802.11i
> (informative)
> Section 4 - Handoff schemes (informative)

These could be in appendix.

> Section 1 could be a document on its own or a normative section of a 
> larger document.

I think your structure looks pretty good, and in line with
what has been discussed earlier on the list.

> I will gladly help restructure the document or work on a separate 
> document along these lines if this is the direction the working group wants 
> to go.

Thanks!

--Jari
_______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap