eap Mailing List: RE: Key derivation and the principle of equivalence

[Salowey, Joe (jsalowey]

Hi Bernard,

I think this is a good approach. Comments inline approach 

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba [at] internaut.com] 
> Sent: Wednesday, May 11, 2005 7:55 PM
> To: eap [at] frascone.com
> Subject: [eap] Key derivation and the principle of equivalence

<snip>
 -------------
> EAP Key Hierarchy
> 
>    EAP, defined in [RFC3748] is a two-party protocol spoken 
> between the
>    EAP peer and server.  Within EAP, keying material is 

[Joe] I need some help with terminology here.  Isn't it that EAP is
spoken between the EAP peer and authenticator unless the authenticator
is running in pass-through mode in which case it is spoken between the
EAP peer and an EAP server?   If this is the case then we probably have
to adjust some of the terminology used below.  


> generated by EAP
>    methods.  Part of this keying material may be used by EAP methods
>    themselves and part of this material may be exported.
> 
>    The EAP Key Hierarchy, illustrated in Figure 1, has at the root the
>    long term credential utilized by the selected EAP method.   If
>    authentication is based on a pre-shared key, the parties store the
>    EAP method to be used and the pre-shared key.  The EAP server also
>    stores the peer's identity and/or other information necessary to
>    decide whether access to some service should be granted.  The peer
>    stores information necessary to choose which secret to use 
> for which
>    service.
> 

[Joe] I have been thinking that the EAP-Server itself just contains
enough information to get the authentication done.  I don't think of the
EAP Server knowing about authorization to services for specific
identities, I thought this would be handled by the entity hosting an
EAP-Server which understood services.  I would expect the same for a
peer.  


>    If authentication is based on proof of possession of the 
> private key
>    corresponding to the public key contained within a certificate, the
>    parties store the EAP method to be used and the trust 
> anchors used to
>    validate the certificates.  The EAP server also stores the peer's
>    identity and/or other information necessary to decide 
> whether access
>    to some service should be granted.  The peer stores information
>    necessary to choose which certificate to use for which service.
> 
>    Based on the long term credential established between the peer and
>    the server, EAP derives two types of keys:
> 
>     [1] Keys calculated locally by the EAP method but not exported
>         by the EAP method, such as the TEKs.
>     [2] Keys exported by the EAP method: MSK, EMSK, IV.
> 
>    As noted in [RFC3748] Section 7.10, EAP methods generating keys are
>    required to calculate and export the MSK and EMSK, which must be at
>    least 64 octets in length.  EAP methods also may export the IV;
>    however, the use of the IV is deprecated.
> 

[Joe] I think we want to limit the discussion of the EMSK to the
extensions document.  Currently in this document the EMSK serves no
purpose.   

> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
>       ---+
> |                                                         |   
>          ^
> |                EAP Method                               |   
>          |
> |                                                         |   
>          |
> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+   |   
>          |
> | |                                 |   |             |   |   
>          |
> | |       EAP Method Key            |<->| Long-Term   |   |   
>          |
> | |         Derivation              |   | Credential  |   |   
>          |
> | |                                 |   |             |   |   
>          |
> | |                                 |   +-+-+-+-+-+-+-+   |  
> Local to  |
> | |                                 |                     |   
>     EAP  |
> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     |   
>   Method |
> |   |             |               |                       |   
>          |
> |   |             |               |                       |   
>          |
> |   |             |               |                       |   
>          |
> |   |             |               |                       |   
>          |
> |   |             |               |                       |   
>          |
> |   |           +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |   
>          |
> |   |           | TEK       | |MSK, EMSK  | |IV         | |   
>          |
> |   |           |Derivation | |Derivation | |Derivation | |   
>          |
> |   |           +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |   
>          |
> |   |                             |                 |     |   
>          |
> |   |                             |                 |     |   
>          V
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
>       ---+
>     |                             |                 |         
>          ^
>     | Peer-ID,                    |                 |         
>  Exported|
>     | Server-ID,                  | MSK (64+B)      | IV 
> (64B)    by   |
>     | Method-ID,                  | EMSK (64+B)     |         
>     EAP  |
>     | Key-Lifetime                |                 |         
>   Method |
>     V                             V                 V         
>          V
> 
>      Figure 1:  EAP Key Hierarchy
> 

[Joe] Instead of key hierarchy I look at this as an exported context
which contains keys as well as other info.  The exported context would
include MSK (leave EMSK exportation, if necessary, to extensions),
Peer-ID, Server-ID, Method-ID, and Authenticated attributes.
Authenticated attributes are data that is exchanged during the method
such as EAP Channel-Bindings.  They are not evaluated by the method, but
are part of the context. Note that the means to export this context data
is outside EAP.  


>    EAP methods also MAY export method-specific peer and server
>    identifiers (peer-ID and server-ID), a method-specific EAP
>    conversation identifier known as the Method-ID, and the lifetime of
>    the exported keys, known the Key-Lifetime.  New EAP method
>    specifications MUST define the Peer-ID, Server-ID and 
> Method-ID.  The
>    combination of the Peer-ID and Server-ID uniquely specifies the
>    endpoints of the EAP method exchange.
> 
>    Peer-ID
> 
>       As described in [RFC3748] Section 7.3, the identity provided in
>       the EAP-Response/Identity, may be different from the 
> peer identity
>       authenticated by the EAP method.  Where the EAP method
>       authenticates the peer identity, that identity is 
> exported by the
>       method as the Peer-ID.  A suitable EAP peer name may 
> not always be
>       available.  Where an EAP method does not define a 
> method-specific
>       peer identity, the Peer-ID is the null string.   The Peer-ID for
>       existing EAP methods is defined in Appendix E.
> 
>    Server-ID
> 
>       Where the EAP method authenticates the server identity, that
>       identity is exported by the method as the Server-ID.  A suitable
>       EAP server name may not always be available.  Where an 
> EAP method
>       does not define a method-specific peer identity, the 
> Server-ID is
>       the null string.  The Server-ID for existing EAP methods is
>       defined in Appendix E.
> 
>    Method-ID
> 
>       EAP method specifications deriving keys MUST specify a 
> temporally
>       unique method identifier known as the Method-ID.  The 
> EAP Method-
>       ID uniquely identifies an EAP session of a given Type between an
>       EAP peer and server.  The Method-ID is typically 
> constructed from
>       nonces or counters used within the EAP method exchange.  The
>       Method-ID for existing EAP methods is defined in Appendix E.
> 
>    Session-ID
> 
>       The Session-ID uniquely identifies an EAP session between an EAP
>       peer (as identified by the Peer-ID) and server (as identified by
>       the Server-ID).  The EAP Session-ID consists of the 
> concatenation
>       of the Expanded EAP Type Code (including the Type, Vendor-ID and
>       Vendor-Type fields defined in [RFC3748] Section 5.7) and the
>       Method-ID.
> 

<snip>

>    Media Independence
> 
>    One of the goals of EAP is to allow EAP methods to function on any
>    lower layer meeting the criteria outlined in [RFC3748], 
> Section 3.1.
>    For example, as described in [RFC3748], EAP authentication 
> can be run
>    over PPP [RFC1661],  IEEE 802 wired networks 
> [IEEE-802.1X], and IEEE
>    802.11 wireless LANs [IEEE-802.11i].
> 
>    In order to maintain media independence, it is necessary for EAP to
>    avoid inclusion of media-specific elements.  For example, 
> EAP methods
>    cannot be assumed to have knowledge of the lower layer over which
>    they are transported, and cannot utilize identifiers 
> associated with
>    a particular usage environment (e.g. MAC addresses).
> 
>    The need for media independence has also motivated the 
> development of
>    the three phase exchange.  Since discovery is typically media-
>    specific, this function is handled outside of EAP, rather 
> than being
>    incorporated within it.  Similarly, the Secure Association Protocol
>    often contains media dependencies such as negotiation of media-
>    specific ciphersuites or session parameters, and as a result this
>    functionality also cannot be incorporated within EAP.
> 
>    Note that media independence may be retained within EAP 
> methods that
>    support channel binding or method-specific identification.  An EAP
>    method need not be aware of the content of an identifier 
> in order to
>    use it.  This enables an EAP method to use media-specific 
> identifiers
>    such as MAC addresses without compromising media independence. 
>  To
>    support channel binding, an EAP method can pass binding 
> parameters to
>    the AAA server in the form of an opaque blob, and receive
>    confirmation of whether the parameters match, without requiring
>    media-specific knowledge.
> 

[Joe] Remove the AAA server terminology and say the the EAP method may
export authenticated attributes (or channel binding parameters) as an
opaque blob which is part of the context.  Also does the method actually
receive confirmation of whther parameters match?