RE: Proposed Resolution of Issue 215: Comments on Section 3
From: Joseph Salowey (jsaloweycisco.com)
Date: Mon, 19 Jul 2004 00:38:03 -0400 (EDT)
eap-admin [at] frascone.com wrote:
> The body of Issue 215 and the associated discussion can be
> found at: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20215
> 
> The proposed resolution of is as follows.  Add the following
> text for Section 2.4, and replace Section 3 with the following:
> 
> "2.4.  Key Naming
> 
>    MSK Name
> 
>       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.  Here the EAP peer name and EAP
> server name
>       are the identifiers securely exchanged within the EAP method.
>       Since multiple MSKs may exist between an EAP peer and
> EAP server,
>       the EAP peer nonce and EAP server nonce allow MSKs to be
>       differentiated; at least one of these nonces is necessary. The
>       inclusion of the Method Type in the name ensures that each EAP
>       method has a distinct name space.
> 
>       Note that the components of the MSK Name are only known
> by the EAP
>       method. As a result, the MSK Name is exported from the
> method, and
>       no detailed format of the MSK Name can be specified without a
>       reference to a particular method.
> 

[Joe] With these definitions the key name length is highly variable.  I
think it would be better to have a constant length identifier for the key.
A length of 128 bits should be sufficient.  Perhaps it can be defined as the
SHA-1 hash of the data listed above (make it 160 bits for simplicity).



Results generated by Tiger Technologies using MHonArc.