Subject: RE: [eap] Issue: Proposed Different organization for the keying d raft

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 19 Oct 2004 10:27:44 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Tuesday, October 19, 2004 3:59 AM
To: Joseph Salowey
Cc: [email-masked]
Subject: Re: [eap] Issue: Proposed Different organization for the keying draft

Joseph Salowey wrote:
> Submitter name: Joe Salowey
> Submitter email address: [email-masked]
> 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
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap