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

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 May 2005 19:54:40 -0700 (PDT)

At various points during the development of RFC 3748, we talked about the
"Principle of Equivalence" - that EAP methods operate the same way,
regardless of whether the authenticator is in "pass-through" mode or not.

One of the consequences of the Principle of Equivalence is that EAP key
management should be explainable without using terms that suggest that the
AAA server is required.  Terms such as "AAA-Key" are somewhat confusing
because they suggest that EAP requires a AAA server in order to do key
derivation.

So as an experiment, I have collected the material in the Key Management
framework document that relates directly to EAP (not lower layers) and
rewritten it without introducing AAA. The text follows.  If this
explanation seems more clear, this approach can be incorporated
into the Key Management framework.  Comments welcome.

---------------------------------------------------------------------------
EAP Key Hierarchy

   EAP, defined in [RFC3748] is a two-party protocol spoken between the
   EAP peer and server.  Within EAP, keying material is 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.

   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.

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

   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.

   Key-Lifetime

      While EAP itself does not support key lifetime negotiation, it is
      possible to specify methods that do.  However, systems that rely on
      such negotiation for exported keys would only function with these
      methods. As a result, it is NOT RECOMMENDED to use this approach as
      the sole way to determine key lifetimes.

   As illustrated in Figure 2,  keying material and parameters exported
   by EAP methods are passed down to the EAP peer or authenticator
   layers, which passes them to the EAP layer.  Keying material and
   related parameters MUST NOT be cached by the EAP peer or
   authenticator layers, or the EAP layer.  Based on the Method-ID
   exported by the EAP method, the EAP layer forms the EAP Session-ID by
   concatenating the EAP Expanded Type with the Method-ID.  Together
   with the MSK, EMSK, IV, Peer-ID, Server-ID, and Key-Lifetime, the EAP
   layer passes the Session-ID down to the lower layer.

   The Method-ID is exported by EAP methods rather than the Session-ID
   so as to prevent EAP methods from writing into each other's Session-
   ID space.  Lower layers MAY cache keying material and related
   parameters.  Lower Layer behavior is discussed in more detail in
   Section TBD.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   |                               |
   |          EAP method           |
   |                               |
   | MSK, EMSK, IV, Peer-ID,       |
   | Server-ID, Method-ID,         |
   | Key-Lifetime                  |
   |                               |
   |       V                       |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+
   |       !                       |
   |  EAP  ! Peer or Authenticator |
   |       ! layer                 |
   |       !                       |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+
   |       !                       |
   |  EAP  ! layer                 |
   |       !                       |
   |       ! Session-ID =          |
   |       ! Expanded-Type ||      |
   |       ! Method-ID             |
   |       !                       |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+
   |       !                       |
   | Lower ! layer                 |
   |       !                       |
   |       V                       |
   | MSK, EMSK, IV, Peer-ID,       |
   | Server-ID, Session-ID,        |
   | Key-Lifetime                  |
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2:  Flow of EAP keying material

Key Naming

   The naming of keys within the EAP key hierarchy is based on the EAP
   Session-ID.

   MSK Name

      This key is created between the EAP peer and EAP server, and can
      be referred to using the string "MSK:", concatenated with the EAP
      Session-ID.

   EMSK Name

      The EMSK can be referred to using the string "EMSK:", concatenated
      with the EAP Session-ID.

   IV Name

      Use of the IV is deprecated.  However, if necessary the IV can be
      referred to using the string "IV:" concatenated with the EAP
      Session-ID.

   PMK Name

      This document does not specify a naming scheme for the PMK.  The
      PMK is only identified by the key from which it is derived.

      Note: IEEE 802.11i names the PMKID for the purposes of being able
      to refer to it in the Secure Association protocol; this naming is
      based on a hash of the PMK itself as well as some other parameters
      (see Section 8.5.1.2 [IEEE-802.11i]).

   TEKs

      The TEKs may or may not be named. Their naming is specified in the
      EAP method.

EAP Invariants

   Certain basic characteristics, known as the "EAP Invariants" hold
   true for EAP implementations on all media:

   Mode independence
   Media independence
   Method independence
   Ciphersuite independence

   Mode Independence

   EAP as defined in [RFC3748] is a two party protocol spoken between
   the EAP peer and server.  A fundamental property of EAP is that the
   conversation between the EAP peer and server is unaffected by whether
   the EAP authenticator is operating in "pass-through" mode.

   The principle of Mode Independence extends to the operation of EAP
   methods, including key derivation.  EAP methods operate identically
   regardless of whether the authenticator is operating as a pass-
   through or not; this also applies to the derivation of keying
   material.

   Since EAP is a protocol spoken between two parties, the completion of
   an EAP method results in the derivation of keying material on the EAP
   peer and server.  Since the EAP peer is unaware of whether the EAP
   authenticator is operating in "pass-through" mode or not, key
   derivation is unaffected by this, and the parameters exported by EAP
   methods (MSK, EMSK, IV, Method-ID, Peer-ID, Server-ID, Key-Lifetime)
   are similarly unaffected.

   Within EAP, the primary function of the AAA protocol is to maintain
   the principle of Mode Independence, so that as far as the EAP peer is
   concerned, its conversation with the EAP authenticator, and all
   consequences of that conversation, are identical, regardless of the
   authenticator mode of operation.

   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.

   Method Independence

   By enabling pass-through, authenticators can support any method
   implemented on the peer and server, not just locally implemented
   methods.  This allows the authenticator to avoid implementing code
   for each EAP method required by peers.  In fact, since a pass-through
   authenticator is not required to implement any EAP methods at all, it
   cannot be assumed to support any EAP method-specific code.

   As a result, as noted in [RFC3748], authenticators must by default be
   capable of supporting any EAP method.  Since the Discovery and Secure
   Association exchanges are also method independent, an authenticator
   can carry out the three phase exchange without having an EAP method
   in common with the peer.

   This is useful where there is no single EAP method that is both
   mandatory-to-implement and offers acceptable security for the media
   in use.  For example, the [RFC3748] mandatory-to-implement EAP method
   (MD5-Challenge) does not provide dictionary attack resistance, mutual
   authentication or key derivation, and as a result is not appropriate
   for use in wireless LAN authentication [RFC4017].  However, despite

   this it is possible for the peer and authenticator to interoperate as
   long as a suitable EAP method is supported on the EAP server.

   Ciphersuite Independence

   While EAP methods may negotiate the ciphersuite used in protection of
   the EAP conversation, the ciphersuite used for the protection of the
   data exchanged after EAP authentication has completed is negotiated
   between the peer and authenticator out-of-band of EAP.  Since
   ciphersuite negotiation is assumed to occur out-of-band, there is no
   need for ciphersuite negotiation within EAP.  Since ciphersuite
   negotiation occurs outside of EAP, EAP methods generate keying
   material that is ciphersuite-independent.

   For example, within PPP, the ciphersuite is negotiated within the
   Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
   authentication is completed.  Within [IEEE-802.11i], the AP
   ciphersuites are advertised in the Beacon and Probe Responses prior
   to EAP authentication, and are securely verified during a 4-way
   handshake exchange after EAP authentication has completed.

   Advantages of ciphersuite-independence include:

Reduced update requirements
     If EAP methods were to specify how to derive transient session keys
     for each ciphersuite, they would need to be updated each time a new
     ciphersuite is developed.  In addition, backend authentication
     servers might not be usable with all EAP-capable authenticators,
     since the backend authentication server would also need to be
     updated each time support for a new ciphersuite is added to the
     authenticator.

Reduced EAP method complexity
     Requiring each EAP method to include ciphersuite-specific code for
     transient session key derivation would increase method complexity
     and result in duplicated effort.

Simplified configuration
     The ciphersuite is negotiated between the peer and authenticator
     out-of-band of EAP.  The backend authentication server is neither a
     party to this negotiation, nor is it an intermediary in the data
     flow between the EAP peer and authenticator.  The backend
     authentication server may not have knowledge of the ciphersuites
     and negotiation policies implemented by the peer and authenticator,
     or be aware of the ciphersuite negotiated between them.  This
     simplifies the configuration of the backend authentication server.
     For example, since ECP negotiation occurs after authentication,
     when run over PPP, the EAP peer, authenticator and backend
     authentication server may not anticipate the negotiated ciphersuite
     and therefore this information cannot be provided to the EAP
     method.

Appendix E - Key Names and Scope in Existing Methods

   This appendix specifies Method-ID, Peer-ID, Server-ID and Key-
   Lifetime for EAP methods that have been published prior to this
   specification.  Future EAP method specifications MUST include a
   definition of the Method-ID  Peer-ID, and Server-ID (could be the
   empty string) and MAY also define Key-Lifetime (assumed to not be
   exported if not described).

EAP-Identity

   The EAP-Identity method does not derive keys, and therefore does not
   define the Key-Lifetime or Method-ID. The Peer-ID exported by the
   Identity method is determined by the octets included within the EAP-
   Response/Identity.  The Server-ID is the empty string (zero length).

EAP-Notification

   The EAP-Notification method does not derive keys and therefore does
   not define the Key-Lifetime and Method-ID.  The Peer-ID and Server-ID
   are the empty string (zero length).

EAP-GTC

   The EAP-GTC method does not derive keys and therefore does not define
   the Key-Lifetime and Method-ID.  The Peer-ID and Server-ID are the
   empty string.

EAP-OTP

   The EAP-OTP method does not derive keys and therefore does not define
   the Key-Lifetime and Method-ID.  The Peer-ID and Server-ID are the
   empty string.

EAP-TLS

   The EAP-TLS Method-Id is the concatenation of the peer and server
   nonces.

   The Peer-ID and Server-ID are the contents of the altSubjectName in
   the peer and server certificates.

   EAP-TLS does not negotiate a Key-Lifetime.

EAP-AKA

   The EAP-AKA Method-Id is the contents of the RAND field from the
   AT_RAND attribute, followed by the contents of the AUTN field in the
   AT_AUTN attribute.

   The Peer-ID is the contents of the Identity field from the
   AT_IDENTITY attribute, using only the Actual Identity Length octets
   from the beginning, however.  Note that the contents are used as they
   are transmitted, regardless of whether the transmitted identity was a
   permanent, pseudonym, or fast reauthentication identity.  The Server-
   ID is an empty string.  EAP-AKA does not negotiate a key lifetime.

EAP-SIM

   The Method-Id is the contents of the RAND field from the AT_RAND
   attribute, followed by the contents of the NONCE_MT field in the
   AT_NONCE_MT attribute.

   The Peer-ID is the contents of the Identity field from the
   AT_IDENTITY attribute, using only the Actual Identity Length octets
   from the beginning, however.  Note that the contents are used as they
   are transmitted, regardless of whether the transmitted identity was a
   permanent, pseudonym, or fast reauthentication identity.  The Server-
   ID is an empty string.  EAP-SIM does not negotiate a key lifetime.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 May 2005 10:08:46 +0300

I think this looks like a useful simplification of the
document. There may be some smaller things to
think about, however. For instance,

>   authenticator mode of operation.
This seems true. Interestingly, it even seems true if
one imagines a fast handoff scenario where you start
off from a combined NAS-AAA device and handoff to
another NAS.

But its also interesting to note what the text above
does not say. I believe peers already can learn the
identities of both the authenticator and the server,
separately, and if channel bindings are provided peers
can also learn of potential discrepancies among the
properties claimed by the different parties. Of course,
such discrepancies can be learned even if all of this
is in the same box.

Secondly, the text does not say anything about
fast handoffs (and this may well be right). But in
fast handoffs peer would again be aware of changing
identities of the authenticator (even though in this
case you'd not really be running EAP again). And
keys for this would be created slightly differently. But
again, the peer has no real knowledge of whether
he handed off to a new box or just a different part of
the same box.

--Jari

---

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

> off from a combined NAS-AAA device and handoff to

Yes.

> such discrepancies can be learned even if all of this

Yes.  The Server-ID is exported by the EAP method, while the lower layer
may expose the NAS-Identifier.  These two identifiers may not be the same,
even where the authenticator and server are on the same box.

For example, the Server-ID exported by the EAP method may refer to the
name of the EAP server, while the NAS-Identifier might refer to the MAC
address of the box.

Since the exported keying material and parameters are pushed down to the
lower layer, it is really the lower layer that defines how the key cache
operates, if one exists at all.  For that purpose, it is typically the
authenticator identity exposed by the lower layer that matters.

For example, as the result of an EAP conversation the peer can know that
it has derived keying material with the EAP server identified by the
Server-ID.  That could be a AAA server handling hundreds of NASes.

However, once the lower layer receives the keying material, it needs to
organize its key cache.  Typically they do this by associating the keying
material passed down to them with an Authenticator Identity as defined by
the lower layer.  But in principle I think that the lower layer could
also advertise the Server-ID.

> he handed off to a new box or just a different part of

Right.  The lower layer is passed the keying material and parameters
(peer-ID, server-ID, method-ID, key-lifetime).  The lower layer can use
this information to organize its key cache in addition to any lower layer
information it might gather.

If there is no AAA server, fast handoff (e.g. authentication without EAP)
is still possible.  If the lower lower can identify a point of attachment
as being possessing keying material, then it can use the keying material
in the key cache to authenticate with it.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 15 May 2005 17:57:05 -0700 (PDT)

Here is some revised text which adds in support for Channel Bindings,
removes the dangling AAA references, and cleans up other miscellaneous
issues.  Next, I'll work on cleaning up the text relating to the lower
layer.

EAP Method Operation

   EAP, defined in [RFC3748] is a two-party protocol spoken between the
   EAP peer and server.  Within EAP, keying material is generated by EAP
   methods.  Part of this keying material may be used by EAP methods
   themselves and part of this material may be exported.  In addition
   to export of keying material, EAP methods may also export associated
   parameters, and may import and export Channel Bindings from the lower
   layer.

   As illustrated in Figure 1, the EAP method key derivation
   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.

    [1] Keys calculated locally by the EAP method but not exported
        by the EAP method, such as the TEKs.
    [2] Keying material exported by the EAP method: MSK, EMSK, IV.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
|                                                         |            ^
|                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,      | Channel   | MSK (64+B)      | IV (64B)    by   |
    | Method-ID,      | Bindings  | EMSK (64+B)     |             EAP  |
    | Key-Lifetime    | & Result  |                 |           Method |
    V                 V           V                 V                  V

     Figure 1:  EAP Parameter Import/Export

   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.   EAP methods
   MAY also support the import and export of Channel Bindings.
   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

   Server-ID

   Method-ID

   Session-ID

   Key-Lifetime

   Channel Bindings

      Channel Bindings include lower layer parameters that
      are verified for consistency between the EAP peer and server.
      In order to avoid introducing media dependencies, EAP
      methods MUST treat Channel Bindings as opaque octets.
      Typically the EAP method imports Channel Bindings from the
      lower layer on the peer, and transmits them securely to the
      EAP server, which exports them to the lower layer.  However,
      transport may occur from EAP server to peer, or may be
      bi-directional.  On the side of the exchange (peer or server)
      where Channel Bindings are verified, the lower layer passes
      the result of the verification (TRUE or FALSE) up to the
      EAP method.

Layering

   As illustrated in Figure 2,  keying material and parameters exported
   by EAP methods are passed down to the EAP peer or authenticator
   layers, which passes them to the EAP layer.  Keying material and
   related parameters (including Channel Bindings) MUST NOT be cached
   by the EAP peer or authenticator layers, or the EAP layer.

   Based on the Method-ID exported by the EAP method, the EAP layer
   forms the EAP Session-ID by concatenating the EAP Expanded Type with
   the Method-ID.  Together with the MSK, EMSK, IV, Peer-ID, Server-ID,
   and Key-Lifetime, the EAP layer passes the Session-ID down to the
   lower layer.

   The Method-ID is exported by EAP methods rather than the Session-ID
   so as to prevent EAP methods from writing into each other's Session-
   ID space.  Lower layers MAY cache keying material and related
   parameters, including Channel Bindings.  Lower Layer behavior is
   discussed in more detail in Section TBD.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                             |
   |                                             |
   |          EAP method                         |
   |                                             |
   | MSK, EMSK, IV,             Channel          |
   | Peer-ID, Server-ID,        Bindings         |
   | Method-ID,                                  |
   | Key-Lifetime                                |
   |                                             |
   |       V                       ^         ^   |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
   |       !                       !         !   |
   |  EAP  ! Peer or Authenticator !         !   |
   |       ! layer                 !         !   |
   |       !                       !         !   |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
   |       !                       !         !   |
   |  EAP  ! layer                 !         !   |
   |       !                       !         !   |
   |       ! Session-ID =          !         !   |
   |       ! Expanded-Type ||      !         !   |
   |       ! Method-ID             !         !   |
   |       !                       !         !   |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
   |       !                       !         !   |
   | Lower ! layer                 !         !   |
   |       !                       !         !   |
   |       V                       V         ^   |
   | MSK, EMSK, IV,             Channel   Result |
   | Peer-ID, Server-ID,        Bindings         |
   | Session-ID,                                 |
   | Key-Lifetime                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2:  Flow of EAP parameters

Key Naming

   MSK Name

   EMSK Name

   IV Name

   PMK Name

   TEKs

EAP Invariants

   Certain basic characteristics, known as "EAP Invariants", hold
   true for EAP implementations on all media:

   Mode independence
   Media independence
   Method independence
   Ciphersuite independence

   Mode Independence

   EAP as defined in [RFC3748] is a two party protocol spoken between
   the EAP peer and server.  A fundamental property of EAP is that at the
   EAP method layer, the conversation between the EAP peer and server is
   unaffected by whether the EAP authenticator is operating in
   "pass-through" mode.

   EAP methods operate identically in all aspects, including key
   derivation and parameter import/export, regardless of whether
   the authenticator is operating as a pass-through or not.

   The successful completion of an EAP method that supports key
   derivation results in the export of keying material on the
   EAP peer and server.  Even though the EAP peer or server may
   import Channel-Bindings that may include the identity
   of the EAP authenticator,  this information is treated as opaque
   octets.  As a result, within EAP the only relevant identities
   are the Peer-ID and Server-ID.  Channel Bindings are only
   interpreted by the lower layer.

   Media Independence

   In order to maintain media independence, it is necessary for EAP to
   avoid consideration 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 be restricted to identifiers
   associated with a particular usage environment (e.g. MAC addresses).

   Note that media independence may be retained within EAP methods that
   support Channel-Bindings 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.
   Channel-Bindings are treated as opaque octets by EAP methods, so
   that handling them does not require media-specific knowledge.

   Method Independence

   As a result, as noted in [RFC3748], authenticators must by default be
   capable of supporting any EAP method.  This is useful where there is
   no single EAP method that is both mandatory-to-implement and offers
   acceptable security for the media in use.  For example, the
   [RFC3748] mandatory-to-implement EAP method (MD5-Challenge) does not
   provide dictionary attack resistance, mutual authentication or key
   derivation, and as a result is not appropriate for use in wireless
   LAN authentication [RFC4017].  However, despite this it is possible
   for the peer and authenticator to interoperate as long as a suitable
   EAP method is supported on the EAP server.

   Ciphersuite Independence

   Ciphersuite Independence is a consequence of the principles of Mode
   Independence and Media Independence.

   While EAP methods may negotiate the ciphersuite used in protection of
   the EAP conversation, the ciphersuite used for the protection of the
   data exchanged after EAP authentication has completed is negotiated
   between the peer and authenticator within the lower layer, outside
   of EAP.  Since the ciphersuites used to protect data depend on the
   lower layer, requiring EAP methods have knowledge of lower layer
   ciphersuites would compromise the principle of Media Indepence.

   Since ciphersuite negotiation occurs in the lower layer, there is no
   need for ciphersuite negotiation within EAP, and EAP methods
   generate keying material that is ciphersuite-independent.

   handshake exchange.

Simplified configuration
     The ciphersuite is negotiated between the peer and authenticator
     outside of EAP.  Where the authenticator operates in "pass-through"
     mode, the EAP server is not a party to this negotiation, nor is
     it involved in the data flow between the EAP peer and authenticator.
     As a result, the EAP server may not have knowledge of the
     ciphersuites and negotiation policies implemented by the peer and
     authenticator, or be aware of the ciphersuite negotiated between
     them.  For example, since ECP negotiation occurs after authentication,
     when run over PPP, the EAP peer and server may not anticipate
     the negotiated ciphersuite and therefore this information cannot
     be provided to the EAP method.

Appendix E - Exported Parameters in Existing Methods

   This Appendix specifies Method-ID, Peer-ID, Server-ID and Key-
   Lifetime for EAP methods that have been published prior to this
   specification.  Future EAP method specifications MUST include a
   definition of the Method-ID,  Peer-ID, and Server-ID (could be the
   empty string) and MAY also define the Key-Lifetime (assumed to be
   indeterminate if not described).

EAP-Identity

EAP-Notification

EAP-GTC

EAP-OTP

EAP-TLS

EAP-AKA

EAP-SIM

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 17 May 2005 01:14:23 -0400

> issues.  Next, I'll work on cleaning up the text relating to the lower

(snip)

>    The naming of keys within the EAP key hierarchy is based on the EAP

I have a fundamental question on why we need to define a name to each
of key derived from a given SA.  This question has came up while I was
reviewing IEEE 802.16e document in which a bunch of key names are
defined.

For example, in RFC 2401, an IPsec SA is identified with three
parameters, i.e., an SPI, an Destination IP Address and a security
protocol(*).  What is the importance of concatenating those parameters
into a string?

Also, an IPsec SA has several ciphering keys such as encryption keys
and integriry keys, but once an SA is identified with the above
parameters, I don't see an importance to give a name to each ciphering
key within the SA.

It seems to me that defining, for each SA type, a set of parameters
that are needed to identifiy an SA among different SAs of the same
type, seems to be important and sufficient.  Giving a name to every
key that belongs to the same SA does not make much sense.

(*) In rfc2401bis, an IPsec SA is identified just with an SPI.

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 17 May 2005 00:47:44 -0700 (PDT)

> reviewing IEEE 802.16e document in which a bunch of key names are

The EAP Session-ID is effectively an SA name.  If the peer and
authenticator both have the same understanding of what the keys within the
SA are used for, then I think there is no need to name the keys
individually.

For example, if we were to meet and shake hands, I would only need to
greet you, I would not need to make up a name for each of your fingers :)

However, if it is possible that the keys within the SA will be used in
different ways, then it seems possible that naming them separately might
be needed.

For example, if it is possible that a given authenticator might have both
the MSK and an AMSK derived from the EMSK, both derived from a
conversation named by the same EAP Session-ID, and if the peer might be
able to choose between them, then it would need to have separate names.

However, the usefulness of a label is not clear.  For example, the peer
could say "I am selecting the MSK within the SA described by this EAP
Session-ID" in many ways.

Note that it is the lower layer that needs to name keys, not EAP.  Since
EAP does not cache keying material or parameters, it never needs to refer
to them once they are created and pushed down the lower layer.

> protocol(*).  What is the importance of concatenating those parameters

I do not think that is needed because there is never a need to refer to
the SA in that manner.  However, in key selection, a peer may need to
indicate which specific key it is attempting to select, in case there are
more than one.

> parameters, I don't see an importance to give a name to each ciphering

This isn't necessary in IPsec because it is clearly defined what is used
for what.  You can't use the encryption key for integrity or the integrity
key for encryption.  Therefore one only needs to be clear about which SA
is being used.

> key that belongs to the same SA does not make much sense.

I think this make sense, except for a situation in which it might be
necessary to select between multiple keys within an SA (as in selection
within a key cache).  Perhaps the right answer is to make sure such a
situation never occurs (no mixed key caches).

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 May 2005 00:54:04 -0400

On Tue, May 17, 2005 at 12:47:44AM -0700, Bernard Aboba wrote:
> The EAP Session-ID is effectively an SA name.  

I think naming the SA as a octetstring is over-specifying.  Isn't it
sufficient to say "the SA is identifed by Expanded EAP Type Code and
Method-ID"?

> If the peer and

I agree.

> Session-ID" in many ways.

I agree.  

> indicate which specific key it is attempting to select, in case there are

I agree and please see below for some examples.

> situation never occurs (no mixed key caches).

If a key caching is allowed, then I agree that we might need some
label for key versioning within an SA.  For example, PANA defines
Key-Id AVP for that purpose.  Similary, when an MSK is exported to a
particular EAP lower-layer session every time re-authentication is
performed for that session, each MSK for that session may be carried
with a key version information when it is carried from an EAP server
to an authenticator over a AAA protocol.

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 17 May 2005 23:06:46 -0700 (PDT)

> sufficient to say "the SA is identifed by Expanded EAP Type Code and

Since the SA section was somewhat confusing to people, I'd prefer to say
"the EAP conversation is identified by the Expanded EAP Type Code and
Method-ID".

I agree that defining the format is not required in the Key Framework
document, but presumably it is required in the documents that define
attribute carrying a key name or EAP session-ID.

Unfortunately, Diameter EAP does not define the format for the key-name
attribute, but references the EAP Key Framework draft for this
(non-normatively at that).

So if the Key Management framework document doesn't define the format,
then we would need to add this to the Diameter EAP document.  Since it's
now in AUTH48, that might force it to be recycled to the AAA WG.

> to an authenticator over a AAA protocol.

However, if it is clearly understood that the lower layer always uses the
MSK, then the EAP Session-ID should be sufficient.

Similarly, if an AMSK with a particular label is always used, then the EAP
Session-ID is also sufficient.

However, if *both* an MSK and AMSK could be used (as in the pre-emptive
keying proposal by Arbaugh), then it is possible that both an MSK and AMSK
might be present on the same authenticator, and then a means would be
necessary to differentiate them.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 May 2005 01:50:41 -0400

Yes.

> now in AUTH48, that might force it to be recycled to the AAA WG.

If I understand your comment correctly, even if the key Management
framework document defines EAP session-ID (or some other attribute
that servers as key versioning), if Diameter EAP needs to carry that
attribute, I think the attribute needs to be added in Diameter EAP
document and recycling would be needed anyways.  

I agree.

I agree.

> necessary to differentiate them.

Yes.  One means for that is to define a different type of
AVP/attribute for a AAA protocol to differenciate AMSK from MSK.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 May 2005 01:50:41 -0400

Yes.

I agree.

I agree.

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 18 May 2005 06:51:37 -0700 (PDT)

> document and recycling would be needed anyways.

Yes, I think that's true.

> AVP/attribute for a AAA protocol to differenciate AMSK from MSK.

I think this would require defining of a grouped AVP, since if there are
multiple keys to be sent it would be necessary to tie together the key,
session-ID and key-type AVPs.  It also might make sense to define AVPs for
the Peer-ID, Server-ID and Key-Lifetime within the same grouped AVP.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 May 2005 16:59:09 +0300

>Yes, I think that's true.
I believe key phrase above (no pun intended) is "if ...
needs to carry". Current usage of EAP does not really
use key names at this level for anything. My suspicision
is that we will only need the names when we go to the
more interesting scenarios, like fast handoffs, or application
usage of EAP keys. But these are likely to require new
AAA support anyway.

(Lets not delay Diameter EAP unless we really need to.)

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 18 May 2005 07:48:24 -0700 (PDT)

> (Lets not delay Diameter EAP unless we really need to.)

So I take it that you're in favor of keeping a definition of the Key-Name
field in the EAP Key management framework?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 May 2005 18:58:20 -0400

> usage of EAP keys. But these are likely to require new

In the case of Diameter EAP, since Diameter runs over reliable
transport, we can probably say that the authenticator can distinguish
old and new MSKs received from the EAP server without carrying a key
versioning information.

AMSK will need key names to be carried because the consumer of AMSK
may not be an authenticator, but this will require new AAA support as 
Jari mentioned above.

For the above reasons, I have personally no issue on moving forward
the Diameter EAP document if my observation is correct.

Yoshihiro Ohba