Subject: RE: [eap] Key derivation and the principle of equivalence

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 12 May 2005 17:39:35 -0700

Hi Bernard,

I think this is a good approach. Comments inline approach 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, May 11, 2005 7:55 PM
> To: [email-masked]
> 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?  

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 13 May 2005 06:24:39 +0300

>receive confirmation of whther parameters match? 
Up to us to decide, I guess. But it isn't clear to me what the
answer should be.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 May 2005 23:06:09 -0700 (PDT)

> to adjust some of the terminology used below.

As defined in RFC 3748, the term "EAP server" applies in both the
pass-through and non-pass-through cases.  Where there is no pass-through,
the "EAP server" and "EAP authenticator" are the same entity.

> EAP-Server which understood services.  I would expect the same for a

While it is possible for an EAP method to support authorization exchanges,
most methods don't do this.  So typically this is a lower
layer function (AAA can be considered a lower layer of EAP).

Here I'm assuming that "authorizations" refers to something different from
Channel Bindings or Key Context.

> extensions document.  Currently in this document the EMSK serves no

I think the document says that the MSK, EMSK and (optionally) the IV are
generated and passed down to the lower layer by the EAP peer and server.
AMSKs are generated within the lower layer based on the exported keying
material.

From the perspective of the Principle of Equivalence, this creates an
interesting issue.  In the non-passthrough case, it can be assumed that
both the EAP peer and authenticator lower layers obtain the MSK and
EMSK.  As a result, both lower layers can calculate AMSKs.

In the pass-through case, AAA does not fulfill the "Principle of
Equivalence" in that only a portion of the key hierarchy present on the
EAP server is replicated to the authenticator.  For example, in RADIUS/EAP
and Diameter/EAP only the MSK is replicated.  In EAP extensions, other
portions of the key hierarchy may be replicated, such as the AMSK and
possibly the MSK as well.

So we have a situation where the key hierarchy may be partially
replicated and the EAP peer needs to understand what has occurred so
that it can know how to calculate the TSKs.  This seems like information
that needs to be securely synchronized between the EAP peer, authenticator
and server, but this is not something that can be accomplished within EAP
itself.  It is therefore an obligation of the EAP lower layer - to make
it clear to the authenticator and peer how the TSKs are to be
calculated, and of AAA, to replicate the required portion of the key
hierarchy between the EAP server and authenticator.

> are part of the context. Note that the means to export this context data

Perhaps Key Hierarchy is not the right term here.  The EMSK is mentioned
as one of the exports because RFC 3748 says that it is generated (though
it doesn't describe usage).  I agree that Channel Bindings need to be
added.

> receive confirmation of whether parameters match?

Yes, removing the AAA server terminology will improve clarity.  I think we
need to  say that the EAP method may export or import Channel Bindings as
an opaque blob.

For example, in some cases it appears that Channel Bindings are passed to
the EAP method layer from the lower layer (e.g. on the EAP peer) and in
some cases, they may be passed from the EAP method layer to the lower
layer (e.g. on the EAP server).  However, the discussion relating to the
Service Authentication draft disclosed some uncertainty on exactly how
this works.  Perhaps we could fudge it for now by including a
bi-directional arrow for Channel Bindings.

As to confirmation, I think that on the side where the bindings are
verified, the lower layer passes to the EAP method a confirmation
on whether they were verified or not.  Presumably the EAP method
communicates this to the other side.  So if the Channel Bindings
are sent by the peer to the server for verification, then the server
sends the peer an indication of whether they matched.

I'll work on modifying the figures and text to describe this.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Fri, 13 May 2005 10:30:48 +0300

>possibly the MSK as well.
Perhaps this discrepancy can be explained by considering
that we are talking of both physical objects (a box) and
logical objects (a layer or a module). It isn't clear to me
that in an integrated case the "NAS" module gets all
the information that the "EAP method" module has...

>it doesn't describe usage).  I agree that Channel Bindings need to be
I like Joe's "exported context" term.

>bi-directional arrow for Channel Bindings.
Works for me. This is at least the most general approach,
and the framework needs to support that, even if we
decide to have just one direction in an actual method
enhancement.

>sends the peer an indication of whether they matched.
Perhaps you can make this optional in the figure.
I still haven't figured out whether you really need
this or not in the actual methods. You could rely on
access-reject if its the server that verifies (even if
you get less info on why you didn't get in).

>I'll work on modifying the figures and text to describe this.
Thanks.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 17 May 2005 00:41:52 -0400

> the "EAP server" and "EAP authenticator" are the same entity.

Since the EAP authenticator is the entity that does timer-based
retransmission of EAP-Requests, it is pretty strange to me to hear
that the EAP server is one end of the EAP protocol.

My understanding of RFC 3748 is:

- EAP is a two-party protocol defined between a peer and an
authenticator.

- An EAP method is defined between a peer and a server.

- It is possible to implement the authenticator and the server in
different physical entities.

Yoshihiro Ohba