Subject: [eap] Issue: Proposed Different organization for the keying draft

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 18 Oct 2004 21:30:07 -0700

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.

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

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)

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

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.  

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Oct 2004 11:58:34 +0300

> good to have in a standards track document.

Agreed.

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

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

> along these lines if this is the direction the working group wants to go.  

Thanks!

--Jari