eap Mailing List: Issue 262: MSK Naming

[Bernard Aboba (aboba]

Issue 262: MSK Naming
Submitter name: Florent Bersani
Submitter email address: florent.bersani [at] rd.francetelecom.fr
Date first submitted: 7/30/2004
Reference: http://mail.frascone.com/pipermail/eap/2004-July/002697.html
Document: Keying-03
Comment type: T
Priority: S
Section: 2.4, 6.1.1
Rationale/Explanation of issue
Section 2.4

*"This key is created between the EAP peer and EAP server, and is
uniquely named by the concatenation of the string "MSK", EAP Method
Type, EAP peer name, EAP server name, EAP peer nonce, and the EAP server
nonce."*

<>This imposes that all EAP methods exchange two nonces (one from the
peer and one from the server) and identify uniquely the parties (i.e.,
no "group key" for an EAP method). While this seems pretty natural, I do
not remember any text in RFC 3748 placing such requirements on EAP
methods. It is only recommended, e.g. in RFC 3748 section 7.10: "A
RECOMMENDED method is for each party to provide a nonce of at least 128
bits, used in the derivation of the MSK and EMSK.". Seems like we are
drifting from RECOMMENDED to MUST, aren't we? So as for the EAP state
machine, if the KMF is informative (which I believe because I read
"Category: informational" on the cover page of the KMF), we should make
sure that we don't (normatively) exclude EAP methods (e.g. those that
cannot name the MSK in the specified way). I bet this is worth more
discussion.

Section 6.1.1

"The EAP mechanism SHOULD provide a way of naming the EMSK"

What about the naming of the MSK?