tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5247

 
 
 

Extensible Authentication Protocol (EAP) Key Management Framework

Part 2 of 4, p. 20 to 41
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 20 
2.  Lower-Layer Operation

   On completion of EAP authentication, EAP keying material and
   parameters exported by the EAP method are provided to the lower layer
   and AAA layer (if present).  These include the Master Session Key
   (MSK), Extended Master Session Key (EMSK), Peer-Id(s), Server-Id(s),
   and Session-Id.  The Initialization Vector (IV) is deprecated, but
   might be provided.

   In order to preserve the security of EAP keying material derived
   within methods, lower layers MUST NOT export keys passed down by EAP
   methods.  This implies that EAP keying material passed down to a
   lower layer is for the exclusive use of that lower layer and MUST NOT
   be used within another lower layer.  This prevents compromise of one
   lower layer from compromising other applications using EAP keying
   material.

   EAP keying material provided to a lower layer MUST NOT be transported
   to another entity.  For example, EAP keying material passed down to
   the EAP peer lower layer MUST NOT leave the peer;  EAP keying
   material passed down or transported to the EAP authenticator lower
   layer MUST NOT leave the authenticator.

   On the EAP server, keying material and parameters requested by and
   passed down to the AAA layer MAY be replicated to the AAA layer on
   the authenticator (with the exception of the EMSK).  On the
   authenticator, the AAA layer provides the replicated keying material
   and parameters to the lower layer over which the EAP authentication
   conversation took place.  This enables mode independence to be
   maintained.

   The EAP layer, as well as the peer and authenticator layers, MUST NOT
   modify or cache keying material or parameters (including channel
   bindings) passing in either direction between the EAP method layer
   and the lower layer or AAA layer.

2.1.  Transient Session Keys

   Where explicitly supported by the lower layer, lower layers MAY cache
   keying material, including exported EAP keying material and/or TSKs;
   the structure of this key cache is defined by the lower layer.  So as
   to enable interoperability, new lower-layer specifications MUST
   describe key caching behavior.  Unless explicitly specified by the
   lower layer, the EAP peer, server, and authenticator MUST assume that

Top      Up      ToC       Page 21 
   peers and authenticators do not cache keying material.  Existing EAP
   lower layers and AAA layers handle the generation of transient
   session keys and caching of EAP keying material in different ways:

   IEEE 802.1X-2004
        When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X]
        does not support link-layer ciphersuites, and as a result, it
        does not provide for the generation of TSKs or caching of EAP
        keying material and parameters.  Once EAP authentication
        completes, it is assumed that EAP keying material and parameters
        are discarded; on IEEE 802 wired networks, there is no
        subsequent Secure Association Protocol exchange.  Perfect
        Forward Secrecy (PFS) is only possible if the negotiated EAP
        method supports this.

   PPP
        PPP, defined in [RFC1661], does not include support for a Secure
        Association Protocol, nor does it support caching of EAP keying
        material or parameters.  PPP ciphersuites derive their TSKs
        directly from the MSK, as described in [RFC2716] Section 3.5.
        This is NOT RECOMMENDED, since if PPP were to support caching of
        EAP keying material, this could result in TSK reuse.  As a
        result, once the PPP session is terminated, EAP keying material
        and parameters MUST be discarded.  Since caching of EAP keying
        material is not permitted within PPP, there is no way to handle
        TSK re-key without EAP re-authentication.  Perfect Forward
        Secrecy (PFS) is only possible if the negotiated EAP method
        supports this.

   IKEv2
        IKEv2, defined in [RFC4306], only uses the MSK for
        authentication purposes and not key derivation.  The EMSK, IV,
        Peer-Id, Server-Id or Session-Id are not used.  As a result, the
        TSKs derived by IKEv2 are cryptographically independent of the
        EAP keying material and re-key of IPsec SAs can be handled
        without requiring EAP re-authentication.  Within IKEv2, it is
        possible to negotiate PFS, regardless of which EAP method is
        negotiated.  IKEv2 as specified in [RFC4306] does not cache EAP
        keying material or parameters; once IKEv2 authentication
        completes, it is assumed that EAP keying material and parameters
        are discarded.  The Session-Timeout Attribute is therefore
        interpreted as a limit on the VPN session time, rather than an
        indication of the MSK key lifetime.

   IEEE 802.11
        IEEE 802.11 enables caching of the MSK, but not the EMSK, IV,
        Peer-Id, Server-Id, or Session-Id.  More details about the
        structure of the cache are available in [IEEE-802.11].  In IEEE

Top      Up      ToC       Page 22 
        802.11, TSKs are derived from the MSK using a Secure Association
        Protocol known as the 4-way handshake, which includes a nonce
        exchange.  This guarantees TSK freshness even if the MSK is
        reused.  The 4-way handshake also enables TSK re-key without EAP
        re-authentication.  PFS is only possible within IEEE 802.11 if
        caching is not enabled and the negotiated EAP method supports
        PFS.

   IEEE 802.16e
        IEEE 802.16e, defined in [IEEE-802.16e], supports caching of the
        MSK, but not the EMSK, IV, Peer-Id, Server-Id, or Session-Id.
        IEEE 802.16e supports a Secure Association Protocol in which
        TSKs are chosen by the authenticator without any contribution by
        the peer.  The TSKs are encrypted, authenticated, and integrity
        protected using the MSK and are transported from the
        authenticator to the peer.  TSK re-key is possible without EAP
        re-authentication.  PFS is not possible even if the negotiated
        EAP method supports it.

   AAA
        Existing implementations and specifications for RADIUS/EAP
        [RFC3579] or Diameter EAP [RFC4072] do not support caching of
        keying material or parameters.  In existing AAA clients, proxy
        and server implementations, exported EAP keying material (MSK,
        EMSK, and IV), as well as parameters and derived keys are not
        cached and MUST be presumed lost after the AAA exchange
        completes.

        In order to avoid key reuse, the AAA layer MUST delete
        transported keys once they are sent.  The AAA layer MUST NOT
        retain keys that it has previously sent.  For example, a AAA
        layer that has transported the MSK MUST delete it, and keys MUST
        NOT be derived from the MSK from that point forward.

2.2.  Authenticator and Peer Architecture

   This specification does not impose constraints on the architecture of
   the EAP authenticator or peer.  For example, any of the authenticator
   architectures described in [RFC4118] can be used.  As a result, lower
   layers need to identify EAP peers and authenticators unambiguously,
   without incorporating implicit assumptions about peer and
   authenticator architectures.

Top      Up      ToC       Page 23 
   For example, it is possible for multiple base stations and a
   "controller" (e.g., WLAN switch) to comprise a single EAP
   authenticator.  In such a situation, the "base station identity" is
   irrelevant to the EAP method conversation, except perhaps as an
   opaque blob to be used in channel binding.  Many base stations can
   share the same authenticator identity.  An EAP authenticator or peer:

      (a) can contain one or more physical or logical ports;
      (b) can advertise itself as one or more "virtual" authenticators
          or peers;
      (c) can utilize multiple CPUs;
      (d) can support clustering services for load balancing or
          failover.

   Both the EAP peer and authenticator can have more than one physical
   or logical port.  A peer can simultaneously access the network via
   multiple authenticators, or via multiple physical or logical ports on
   a given authenticator.  Similarly, an authenticator can offer network
   access to multiple peers, each via a separate physical or logical
   port.  When a single physical authenticator advertises itself as
   multiple virtual authenticators, it is possible for a single physical
   port to belong to multiple virtual authenticators.

   An authenticator can be configured to communicate with more than one
   EAP server, each of which is configured to communicate with a subset
   of the authenticators.  The situation is illustrated in Figure 3.

2.3.  Authenticator Identification

   The EAP method conversation is between the EAP peer and server.  The
   authenticator identity, if considered at all by the EAP method, is
   treated as an opaque blob for the purpose of channel binding (see
   Section 5.3.3).  However, the authenticator identity is important in
   two other exchanges - the AAA protocol exchange and the Secure
   Association Protocol conversation.

   The AAA conversation is between the EAP authenticator and the backend
   authentication server.  From the point of view of the backend
   authentication server, keying material and parameters are transported
   to the EAP authenticator identified by the NAS-Identifier Attribute.
   Since an EAP authenticator MUST NOT share EAP keying material or
   parameters with another party, if the EAP peer or backend
   authentication server detects use of EAP keying material and
   parameters outside the scope defined by the NAS-Identifier, the
   keying material MUST be considered compromised.

Top      Up      ToC       Page 24 
   The Secure Association Protocol conversation is between the peer and
   the authenticator.  For lower layers that support key caching, it is
   particularly important for the EAP peer, authenticator, and backend
   server to have a consistent view of the usage scope of the
   transported keying material.  In order to enable this, it is
   RECOMMENDED that the Secure Association Protocol explicitly
   communicate the usage scope of the EAP keying material passed down to
   the lower layer, rather than implicitly assuming that this is defined
   by the authenticator and peer endpoint addresses.

                     +-+-+-+-+
                     | EAP   |
                     | Peer  |
                     +-+-+-+-+
                       | | |  Peer Ports
                      /  |  \
                     /   |   \
                    /    |    \
                   /     |     \
                  /      |      \
                 /       |       \
                /        |        \
               /         |         \     Authenticator
            | | |      | | |      | | |   Ports
          +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
          |       |  |       |  |       |
          | Auth1 |  | Auth2 |  | Auth3 |
          |       |  |       |  |       |
          +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
               \        | \         |
                \       |  \        |
                 \      |   \       |
   EAP over AAA   \     |    \      |
     (optional)    \    |     \     |
                    \   |      \    |
                     \  |       \   |
                      \ |        \  |
                   +-+-+-+-+-+  +-+-+-+-+-+  Backend
                   |  EAP    |  |  EAP    |  Authentication
                   | Server1 |  | Server2 |  Servers
                   +-+-+-+-+-+  +-+-+-+-+-+

   Figure 3: Relationship between EAP Peer, Authenticator, and Server

   Since an authenticator can have multiple ports, the scope of the
   authenticator key cache cannot be described by a single endpoint
   address.  Similarly, where a peer can have multiple ports and sharing
   of EAP keying material and parameters between peer ports of the same

Top      Up      ToC       Page 25 
   link type is allowed, the extent of the peer key cache cannot be
   communicated by using a single endpoint address.  Instead, it is
   RECOMMENDED that the EAP peer and authenticator consistently identify
   themselves utilizing explicit identifiers, rather than endpoint
   addresses or port identifiers.

   AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
   a mechanism for the identification of AAA clients; since the EAP
   authenticator and AAA client MUST be co-resident, this mechanism is
   applicable to the identification of EAP authenticators.

   RADIUS [RFC2865] requires that an Access-Request packet contain one
   or more of the NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address
   attributes.  Since a NAS can have more than one IP address, the
   NAS-Identifier Attribute is RECOMMENDED for explicit identification
   of the authenticator, both within the AAA protocol exchange and the
   Secure Association Protocol conversation.

   Problems that can arise where the peer and authenticator implicitly
   identify themselves using endpoint addresses include the following:

   (a)  It is possible that the peer will not be able to determine which
        authenticator ports are associated with which authenticators.
        As a result, the EAP peer will be unable to utilize the
        authenticator key cache in an efficient way, and will also be
        unable to determine whether EAP keying material has been shared
        outside its authorized scope, and therefore needs to be
        considered compromised.

   (b)  It is possible that the authenticator will not be able to
        determine which peer ports are associated with which peers,
        preventing the peer from communicating with it utilizing
        multiple peer ports.

   (c)  It is possible that the peer will not be able to determine with
        which virtual authenticator it is communicating.  For example,
        multiple virtual authenticators can share a MAC address, but
        utilize different NAS-Identifiers.

   (d)  It is possible that the authenticator will not be able to
        determine with which virtual peer it is communicating.  Multiple
        virtual peers can share a MAC address, but utilize different
        Peer-Ids.

   (e)  It is possible that the EAP peer and server will not be able to
        verify the authenticator identity via channel binding.

Top      Up      ToC       Page 26 
   For example, problems (a), (c), and (e) occur in [IEEE-802.11], which
   utilizes peer and authenticator MAC addresses within the 4-way
   handshake.  Problems (b) and (d) do not occur since [IEEE-802.11]
   only allows a virtual peer to utilize a single port.

   The following steps enable lower-layer identities to be securely
   verified by all parties:

   (f)  Specify the lower-layer parameters used to identify the
        authenticator and peer.  As noted earlier, endpoint or port
        identifiers are not recommended for identification of the
        authenticator or peer when it is possible for them to have
        multiple ports.

   (g)  Communicate the lower-layer identities between the peer and
        authenticator within phase 0.  This allows the peer and
        authenticator to determine the key scope if a key cache is
        utilized.

   (h)  Communicate the lower-layer authenticator identity between the
        authenticator and backend authentication server within the NAS-
        Identifier Attribute.

   (i)  Include the lower-layer identities within channel bindings (if
        supported) in phase 1a, ensuring that they are communicated
        between the EAP peer and server.

   (j)  Support the integrity-protected exchange of identities within
        phase 2a.

   (k)  Utilize the advertised lower-layer identities to enable the peer
        and authenticator to verify that keys are maintained within the
        advertised scope.

2.3.1.  Virtual Authenticators

   When a single physical authenticator advertises itself as multiple
   virtual authenticators, if the virtual authenticators do not maintain
   logically separate key caches, then by authenticating to one virtual
   authenticator, the peer can gain access to the other virtual
   authenticators sharing a key cache.

Top      Up      ToC       Page 27 
   For example, where a physical authenticator implements "Guest" and
   "Corporate Intranet" virtual authenticators, an attacker acting as a
   peer could authenticate with the "Guest" virtual authenticator and
   derive EAP keying material.  If the "Guest" and "Corporate Intranet"
   virtual authenticators share a key cache, then the peer can utilize
   the EAP keying material derived for the "Guest" network to obtain
   access to the "Corporate Intranet" network.

   The following steps can be taken to mitigate this vulnerability:

   (a)  Authenticators are REQUIRED to cache associated authorizations
        along with EAP keying material and parameters and to apply
        authorizations to the peer on each network access, regardless of
        which virtual authenticator is being accessed.  This ensures
        that an attacker cannot obtain elevated privileges even where
        the key cache is shared between virtual authenticators, and a
        peer obtains access to one virtual authenticator utilizing a key
        cache entry created for use with another virtual authenticator.

   (b)  It is RECOMMENDED that physical authenticators maintain separate
        key caches for each virtual authenticator.  This ensures that a
        cache entry created for use with one virtual authenticator
        cannot be used for access to another virtual authenticator.
        Since a key cache entry can no longer be shared between virtual
        authentications, this step provides protection beyond that
        offered in (a).  This is valuable in situations where
        authorizations are not used to enforce access limitations.  For
        example, where access is limited using a filter installed on a
        router rather than using authorizations provided to the
        authenticator, a peer can gain unauthorized access to resources
        by exploiting a shared key cache entry.

   (c)  It is RECOMMENDED that each virtual authenticator identify
        itself consistently to the peer and to the backend
        authentication server, so as to enable the peer to verify the
        authenticator identity via channel binding (see Section 5.3.3).

   (d)  It is RECOMMENDED that each virtual authenticator identify
        itself distinctly, in order to enable the peer and backend
        authentication server to tell them apart.  For example, this can
        be accomplished by utilizing a distinct value of the NAS-
        Identifier Attribute.

2.4.  Peer Identification

   As described in [RFC3748] Section 7.3, the peer identity provided in
   the EAP-Response/Identity can be different from the peer identities
   authenticated by the EAP method.  For example, the identity provided

Top      Up      ToC       Page 28 
   in the EAP-Response/Identity can be a privacy identifier as described
   in "The Network Access Identifier" [RFC4282] Section 2.  As noted in
   [RFC4284], it is also possible to utilize a Network Access Identifier
   (NAI) for the purposes of source routing; an NAI utilized for source
   routing is said to be "decorated" as described in [RFC4282] Section
   2.7.

   When the EAP peer provides the Network Access Identity (NAI) within
   the EAP-Response/Identity, as described in [RFC3579], the
   authenticator copies the NAI included in the EAP-Response/Identity
   into the User-Name Attribute included within the Access-Request.  As
   the Access-Request is forwarded toward the backend authentication
   server, AAA proxies remove decoration from the NAI included in the
   User-Name Attribute; the NAI included within the
   EAP-Response/Identity encapsulated in the Access-Request remains
   unchanged.  As a result, when the Access-Request arrives at the
   backend authentication server, the EAP-Response/Identity can differ
   from the User-Name Attribute (which can have some or all of the
   decoration removed).  In the absence of a Peer-Id, the backend
   authentication server SHOULD use the contents of the User-Name
   Attribute, rather than the EAP-Response/Identity, as the peer
   identity.

   It is possible for more than one Peer-Id to be exported by an EAP
   method.  For example, a peer certificate can contain more than one
   peer identity; in a tunnel method, peer identities can be
   authenticated within both an outer and inner exchange, and these
   identities could be different in type and contents.  For example, an
   outer exchange could provide a Peer-Id in the form of a Relative
   Distinguished Name (RDN), whereas an inner exchange could identify
   the peer via its NAI or MAC address.  Where EAP keying material is
   determined solely from the outer exchange, only the outer Peer-Id(s)
   are exported; where the EAP keying material is determined from both
   the inner and outer exchanges, then both the inner and outer
   Peer-Id(s) are exported by the tunnel method.

Top      Up      ToC       Page 29 
2.5.  Server Identification

   It is possible for more than one Server-Id to be exported by an EAP
   method.  For example, a server certificate can contain more than one
   server identity; in a tunnel method, server identities could be
   authenticated within both an outer and inner exchange, and these
   identities could be different in type and contents.  For example, an
   outer exchange could provide a Server-Id in the form of an IP
   address, whereas an inner exchange could identify the server via its
   Fully-Qualified Domain Name (FQDN) or hostname.  Where EAP keying
   material is determined solely from the outer exchange, only the outer
   Server-Id(s) are exported by the EAP method; where the EAP keying
   material is determined from both the inner and outer exchanges, then
   both the inner and outer Server-Id(s) are exported by the EAP method.

   As shown in Figure 3, an authenticator can be configured to
   communicate with multiple EAP servers; the EAP server that an
   authenticator communicates with can vary according to configuration
   and network and server availability.  While the EAP peer can assume
   that all EAP servers within a realm have access to the credentials
   necessary to validate an authentication attempt, it cannot assume
   that all EAP servers share persistent state.

   Authenticators can be configured with different primary or secondary
   EAP servers, in order to balance the load.  Also, the authenticator
   can dynamically determine the EAP server to which requests will be
   sent; in the event of a communication failure, the authenticator can
   fail over to another EAP server.  For example, in Figure 3,
   Authenticator2 can be initially configured with EAP server1 as its
   primary backend authentication server, and EAP server2 as the backup,
   but if EAP server1 becomes unavailable, EAP server2 can become the
   primary server.

   In general, the EAP peer cannot direct an authentication attempt to a
   particular EAP server within a realm, this decision is made by AAA
   clients, nor can the peer determine with which EAP server it will be
   communicating, prior to the start of the EAP method conversation.
   The Server-Id is not included in the EAP-Request/Identity, and since
   the EAP server may be determined dynamically, it typically is not
   possible for the authenticator to advertise the Server-Id during the
   discovery phase.  Some EAP methods do not export the Server-Id so
   that it is possible that the EAP peer will not learn with which
   server it was conversing after the EAP conversation completes
   successfully.

   As a result, an EAP peer, on connecting to a new authenticator or
   reconnecting to the same authenticator, can find itself communicating
   with a different EAP server.  Fast reconnect, defined in [RFC3748]

Top      Up      ToC       Page 30 
   Section 7.2, can fail if the EAP server with which the peer
   communicates is not the same one with which it initially established
   a security association.  For example, an EAP peer attempting an
   EAP-TLS session resume can find that the new EAP-TLS server will not
   have access to the TLS Master Key identified by the TLS Session-Id,
   and therefore the session resumption attempt will fail, requiring
   completion of a full EAP-TLS exchange.

   EAP methods that export the Server-Id MUST authenticate the server.
   However, not all EAP methods supporting mutual authentication provide
   a non-null Server-Id; some methods only enable the EAP peer to verify
   that the EAP server possesses a long-term secret, but do not provide
   the identity of the EAP server.  In this case, the EAP peer will know
   that an authenticator has been authorized by an EAP server, but will
   not confirm the identity of the EAP server.  Where the EAP method
   does not provide a Server-Id, the peer cannot identify the EAP server
   with which it generated keying material.  This can make it difficult
   for the EAP peer to identify the location of a key possessed by that
   EAP server.

   As noted in [RFC5216] Section 5.2, EAP methods supporting
   authentication using server certificates can determine the Server-Id
   from the subject or subjectAltName fields in the server certificate.
   Validating the EAP server identity can help the EAP peer to decide
   whether a specific EAP server is authorized.  In some cases, such as
   where the certificate extensions defined in [RFC4334] are included in
   the server certificate, it can even be possible for the peer to
   verify some channel binding parameters from the server certificate.

   It is possible for problems to arise in situations where the EAP
   server identifies itself differently to the EAP peer and
   authenticator.  For example, it is possible that the Server-Id
   exported by EAP methods will not be identical to the Fully Qualified
   Domain Name (FQDN) of the backend authentication server.  Where
   certificate-based authentication is used within RADIUS or Diameter,
   it is possible that the subjectAltName used in the backend
   authentication server certificate will not be identical to the
   Server-Id or backend authentication server FQDN.  This is not
   normally an issue in EAP, as the authenticator will be unaware of the
   identities used between the EAP peer and server.  However, this can
   be an issue for key caching, if the authenticator is expected to
   locate a backend authentication server corresponding to a Server-Id
   provided by an EAP peer.

   Where the backend authentication server FQDN differs from the
   subjectAltName in the backend authentication server certificate, it
   is possible that the AAA client will not be able to determine whether
   it is talking to the correct backend authentication server.  Where

Top      Up      ToC       Page 31 
   the Server-Id and backend authentication server FQDN differ, it is
   possible that the combination of the key scope (Peer-Id(s), Server-
   Id(s)) and EAP conversation identifier (Session-Id) will not be
   sufficient to determine where the key resides.  For example, the
   authenticator can identify backend authentication servers by their IP
   address (as occurs in RADIUS), or using a Fully Qualified Domain Name
   (as in Diameter).  If the Server-Id does not correspond to the IP
   address or FQDN of a known backend authentication server, then it may
   not be possible to locate which backend authentication server
   possesses the key.

3.  Security Association Management

   EAP, as defined in [RFC3748], supports key derivation, but does not
   provide for the management of lower-layer security associations.
   Missing functionality includes:

   (a)  Security Association negotiation.  EAP does not negotiate
        lower-layer unicast or multicast security associations,
        including cryptographic algorithms or traffic profiles.  EAP
        methods only negotiate cryptographic algorithms for their own
        use, not for the underlying lower layers.  EAP also does not
        negotiate the traffic profiles to be protected with the
        negotiated ciphersuites; in some cases the traffic to be
        protected can have lower-layer source and destination addresses
        different from the lower-layer peer or authenticator addresses.

   (b)  Re-key.  EAP does not support the re-keying of exported EAP
        keying material without EAP re-authentication, although EAP
        methods can support "fast reconnect" as defined in [RFC3748]
        Section 7.2.1.

   (c)  Key delete/install semantics.  EAP does not synchronize
        installation or deletion of keying material on the EAP peer and
        authenticator.

   (d)  Lifetime negotiation.  EAP does not support lifetime negotiation
        for exported EAP keying material, and existing EAP methods also
        do not support key lifetime negotiation.

   (e)  Guaranteed TSK freshness.  Without a post-EAP handshake, TSKs
        can be reused if EAP keying material is cached.

   These deficiencies are typically addressed via a post-EAP handshake
   known as the Secure Association Protocol.

Top      Up      ToC       Page 32 
3.1.  Secure Association Protocol

   Since neither EAP nor EAP methods provide for establishment of
   lower-layer security associations, it is RECOMMENDED that these
   facilities be provided within the Secure Association Protocol,
   including:

   (a)  Entity Naming.  A basic feature of a Secure Association Protocol
        is the explicit naming of the parties engaged in the exchange.
        Without explicit identification, the parties engaged in the
        exchange are not identified and the scope of the EAP keying
        parameters negotiated during the EAP exchange is undefined.

   (b)  Mutual proof of possession of EAP keying material.  During the
        Secure Association Protocol, the EAP peer and authenticator MUST
        demonstrate possession of the keying material transported
        between the backend authentication server and authenticator
        (e.g., MSK), in order to demonstrate that the peer and
        authenticator have been authorized.  Since mutual proof of
        possession is not the same as mutual authentication, the peer
        cannot verify authenticator assertions (including the
        authenticator identity) as a result of this exchange.
        Authenticator identity verification is discussed in Section 2.3.

   (c)  Secure capabilities negotiation.  In order to protect against
        spoofing during the discovery phase, ensure selection of the
        "best" ciphersuite, and protect against forging of negotiated
        security parameters, the Secure Association Protocol MUST
        support secure capabilities negotiation.  This includes the
        secure negotiation of usage modes, session parameters (such as
        security association identifiers (SAIDs) and key lifetimes),
        ciphersuites and required filters, including confirmation of
        security-relevant capabilities discovered during phase 0.  The
        Secure Association Protocol MUST support integrity and replay
        protection of all capability negotiation messages.

   (d)  Key naming and selection.  Where key caching is supported, it is
        possible for the EAP peer and authenticator to share more than
        one key of a given type.  As a result, the Secure Association
        Protocol MUST explicitly name the keys used in the proof of
        possession exchange, so as to prevent confusion when more than
        one set of keying material could potentially be used as the
        basis for the exchange.  Use of the key naming mechanism
        described in Section 1.4.1 is RECOMMENDED.

        In order to support the correct processing of phase 2 security
        associations, the Secure Association (phase 2) protocol MUST
        support the naming of phase 2 security associations and

Top      Up      ToC       Page 33 
        associated transient session keys so that the correct set of
        transient session keys can be identified for processing a given
        packet.  The phase 2 Secure Association Protocol also MUST
        support transient session key activation and SHOULD support
        deletion so that establishment and re-establishment of transient
        session keys can be synchronized between the parties.

   (e)  Generation of fresh transient session keys (TSKs).  Where the
        lower layer supports caching of keying material, the EAP peer
        lower layer can initiate a new session using keying material
        that was derived in a previous session.  Were the TSKs to be
        derived solely from a portion of the exported EAP keying
        material, this would result in reuse of the session keys that
        could expose the underlying ciphersuite to attack.

        In lower layers where caching of keying material is supported,
        the Secure Association Protocol phase is REQUIRED, and MUST
        support the derivation of fresh unicast and multicast TSKs, even
        when the transported keying material provided by the backend
        authentication server is not fresh.  This is typically supported
        via the exchange of nonces or counters, which are then mixed
        with the keying material in order to generate fresh unicast
        (phase 2a) and possibly multicast (phase 2b) session keys.  By
        not using exported EAP keying material directly to protect data,
        the Secure Association Protocol protects it against compromise.

   (f)  Key lifetime management.  This includes explicit key lifetime
        negotiation or seamless re-key.  EAP does not support the
        re-keying of EAP keying material without re-authentication, and
        existing EAP methods do not support key lifetime negotiation.
        As a result, the Secure Association Protocol MAY handle the
        re-key and determination of the key lifetime.  Where key caching
        is supported, secure negotiation of key lifetimes is
        RECOMMENDED.  Lower layers that support re-key, but not key
        caching, may not require key lifetime negotiation.  For example,
        a difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that
        in IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the
        SA is responsible for enforcing its own lifetime policy on the
        SA and re-keying the SA when necessary.

   (g)  Key state resynchronization.  It is possible for the peer or
        authenticator to reboot or reclaim resources, clearing portions
        or all of the key cache.  Therefore, key lifetime negotiation
        cannot guarantee that the key cache will remain synchronized,
        and it may not be possible for the peer to determine before
        attempting to use a key whether it exists within the
        authenticator cache.  It is therefore RECOMMENDED for the EAP
        lower layer to provide a mechanism for key state

Top      Up      ToC       Page 34 
        resynchronization, either via the SAP or using a lower layer
        indication (see [RFC3748] Section 3.4).  Where the peer and
        authenticator do not jointly possess a key with which to protect
        the resynchronization exchange, secure resynchronization is not
        possible, and alternatives (such as an initiation of EAP
        re-authentication after expiration of a timer) are needed to
        ensure timely resynchronization.

   (h)  Key scope synchronization.  To support key scope determination,
        the Secure Association Protocol SHOULD provide a mechanism by
        which the peer can determine the scope of the key cache on each
        authenticator and by which the authenticator can determine the
        scope of the key cache on a peer.  This includes negotiation of
        restrictions on key usage.

   (i)  Traffic profile negotiation.  The traffic to be protected by a
        lower-layer security association will not necessarily have the
        same lower-layer source or destination address as the EAP peer
        and authenticator, and it is possible for the peer and
        authenticator to negotiate multiple security associations, each
        with a different traffic profile.  Where this is the case, the
        profile of protected traffic SHOULD be explicitly negotiated.
        For example, in IKEv2 it is possible for an Initiator and
        Responder to utilize EAP for authentication, then negotiate a
        Tunnel Mode Security Association (SA), which permits passing of
        traffic originating from hosts other than the Initiator and
        Responder.  Similarly, in IEEE 802.16e, a Subscriber Station
        (SS) can forward traffic to the Base Station (BS), which
        originates from the Local Area Network (LAN) to which it is
        attached.  To enable this, Security Associations within IEEE
        802.16e are identified by the Connection Identifier (CID), not
        by the EAP peer and authenticator MAC addresses.  In both IKEv2
        and IEEE 802.16e, multiple security associations can exist
        between the EAP peer and authenticator, each with their own
        traffic profile and quality of service parameters.

   (j)  Direct operation.  Since the phase 2 Secure Association Protocol
        is concerned with the establishment of security associations
        between the EAP peer and authenticator, including the derivation
        of transient session keys, only those parties have "a need to
        know" the transient session keys.  The Secure Association
        Protocol MUST operate directly between the peer and
        authenticator and MUST NOT be passed-through to the backend
        authentication server or include additional parties.

   (k)  Bi-directional operation.  While some ciphersuites only require
        a single set of transient session keys to protect traffic in
        both directions, other ciphersuites require a unique set of

Top      Up      ToC       Page 35 
        transient session keys in each direction.  The phase 2 Secure
        Association Protocol SHOULD provide for the derivation of
        unicast and multicast keys in each direction, so as not to
        require two separate phase 2 exchanges in order to create a
        bi-directional phase 2 security association.  See [RFC3748]
        Section 2.4 for more discussion.

3.2.  Key Scope

   Absent explicit specification within the lower layer, after the
   completion of phase 1b, transported keying material, and parameters
   are bound to the EAP peer and authenticator, but are not bound to a
   specific peer or authenticator port.

   While EAP keying material passed down to the lower layer is not
   intrinsically bound to particular authenticator and peer ports, TSKs
   MAY be bound to particular authenticator and peer ports by the Secure
   Association Protocol.  However, a lower layer MAY also permit TSKs to
   be used on multiple peer and/or authenticator ports, provided that
   TSK freshness is guaranteed (such as by keeping replay counter state
   within the authenticator).

   In order to further limit the key scope, the following measures are
   suggested:

   (a)  The lower layer MAY specify additional restrictions on key
        usage, such as limiting the use of EAP keying material and
        parameters on the EAP peer to the port over which the EAP
        conversation was conducted.

   (b)  The backend authentication server and authenticator MAY
        implement additional attributes in order to further restrict the
        scope of keying material.  For example, in IEEE 802.11, the
        backend authentication server can provide the authenticator with
        a list of authorized Called or Calling-Station-Ids and/or SSIDs
        for which keying material is valid.

   (c)  Where the backend authentication server provides attributes
        restricting the key scope, it is RECOMMENDED that restrictions
        be securely communicated by the authenticator to the peer.  This
        can be accomplished using the Secure Association Protocol, but
        also can be accomplished via the EAP method or the lower layer.

3.3.  Parent-Child Relationships

   When an EAP re-authentication takes place, new EAP keying material is
   exported by the EAP method.  In EAP lower layers where EAP
   re-authentication eventually results in TSK replacement, the maximum

Top      Up      ToC       Page 36 
   lifetime of derived keying material (including TSKs) can be less than
   or equal to that of EAP keying material (MSK/EMSK), but it cannot be
   greater.

   Where TSKs are derived from or are wrapped by exported EAP keying
   material, compromise of that exported EAP keying material implies
   compromise of TSKs.  Therefore, if EAP keying material is considered
   stale, not only SHOULD EAP re-authentication be initiated, but also
   replacement of child keys, including TSKs.

   Where EAP keying material is used only for entity authentication but
   not for TSK derivation (as in IKEv2), compromise of exported EAP
   keying material does not imply compromise of the TSKs.  Nevertheless,
   the compromise of EAP keying material could enable an attacker to
   impersonate an authenticator, so that EAP re-authentication and TSK
   re-key are RECOMMENDED.

   With respect to IKEv2, Section 5.2 of [RFC4718], "IKEv2
   Clarifications and Implementation Guidelines", states:

      Rekeying the IKE_SA and reauthentication are different concepts in
      IKEv2.  Rekeying the IKE_SA establishes new keys for the IKE_SA
      and resets the Message ID counters, but it does not authenticate
      the parties again (no AUTH or EAP payloads are involved)...  This
      means that reauthentication also establishes new keys for the
      IKE_SA and CHILD_SAs.  Therefore while rekeying can be performed
      more often than reauthentication, the situation where
      "authentication lifetime" is shorter than "key lifetime" does not
      make sense.

   Child keys that are used frequently (such as TSKs that are used for
   traffic protection) can expire sooner than the exported EAP keying
   material on which they are dependent, so that it is advantageous to
   support re-key of child keys prior to EAP re-authentication.  Note
   that deletion of the MSK/EMSK does not necessarily imply deletion of
   TSKs or child keys.

   Failure to mutually prove possession of exported EAP keying material
   during the Secure Association Protocol exchange need not be grounds
   for deletion of keying material by both parties; rate-limiting Secure
   Association Protocol exchanges could be used to prevent a brute force
   attack.

Top      Up      ToC       Page 37 
3.4.  Local Key Lifetimes

   The Transient EAP Keys (TEKs) are session keys used to protect the
   EAP conversation.  The TEKs are internal to the EAP method and are
   not exported.  TEKs are typically created during an EAP conversation,
   used until the end of the conversation and then discarded.  However,
   methods can re-key TEKs during an EAP conversation.

   When using TEKs within an EAP conversation or across conversations,
   it is necessary to ensure that replay protection and key separation
   requirements are fulfilled.  For instance, if a replay counter is
   used, TEK re-key MUST occur prior to wrapping of the counter.
   Similarly, TSKs MUST remain cryptographically separate from TEKs
   despite TEK re-keying or caching.  This prevents TEK compromise from
   leading directly to compromise of the TSKs and vice versa.

   EAP methods MAY cache local EAP keying material (TEKs) that can
   persist for multiple EAP conversations when fast reconnect is used
   [RFC3748].  For example, EAP methods based on TLS (such as EAP-TLS
   [RFC5216]) derive and cache the TLS Master Secret, typically for
   substantial time periods.  The lifetime of other local EAP keying
   material calculated within the EAP method is defined by the method.
   Note that in general, when using fast reconnect, there is no
   guarantee that the original long-term credentials are still in the
   possession of the peer.  For instance, a smart-card holding the
   private key for EAP-TLS may have been removed.  EAP servers SHOULD
   also verify that the long-term credentials are still valid, such as
   by checking that certificate used in the original authentication has
   not yet expired.

3.5.  Exported and Calculated Key Lifetimes

   The following mechanisms are available for communicating the lifetime
   of keying material between the EAP peer, server, and authenticator:

      AAA protocols  (backend authentication server and authenticator)
      Lower-layer mechanisms (authenticator and peer)
      EAP method-specific negotiation (peer and server)

   Where the EAP method does not support the negotiation of the lifetime
   of exported EAP keying material, and a key lifetime negotiation
   mechanism is not provided by the lower layer, it is possible that
   there will not be a way for the peer to learn the lifetime of keying
   material.  This can leave the peer uncertain of how long the
   authenticator will maintain keying material within the key cache.  In
   this case the lifetime of keying material can be managed as a system
   parameter on the peer and authenticator; a default lifetime of 8
   hours is RECOMMENDED.

Top      Up      ToC       Page 38 
3.5.1.  AAA Protocols

   AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be
   used to communicate the maximum key lifetime from the backend
   authentication server to the authenticator.

   The Session-Timeout Attribute is defined for RADIUS in [RFC2865] and
   for Diameter in [RFC4005].  Where EAP is used for authentication,
   [RFC3580] Section 3.17, indicates that a Session-Timeout Attribute
   sent in an Access-Accept along with a Termination-Action value of
   RADIUS-Request specifies the maximum number of seconds of service
   provided prior to EAP re-authentication.

   However, there is also a need to be able to specify the maximum
   lifetime of cached keying material.  Where EAP pre-authentication is
   supported, cached keying material can be pre-established on the
   authenticator prior to session start and will remain there until
   expiration.  EAP lower layers supporting caching of keying material
   MAY also persist that material after the end of a session, enabling
   the peer to subsequently resume communication utilizing the cached
   keying material.  In these situations it can be desirable for the
   backend authentication server to specify the maximum lifetime of
   cached keying material.

   To accomplish this, [IEEE-802.11] overloads the Session-Timeout
   Attribute, assuming that it represents the maximum time after which
   transported keying material will expire on the authenticator,
   regardless of whether transported keying material is cached.

   An IEEE 802.11 authenticator receiving transported keying material is
   expected to initialize a timer to the Session-Timeout value, and once
   the timer expires, the transported keying material expires.  Whether
   this results in session termination or EAP re-authentication is
   controlled by the value of the Termination-Action Attribute.  Where
   EAP re-authentication occurs, the transported keying material is
   replaced, and with it, new calculated keys are put in place.  Where
   session termination occurs, transported and derived keying material
   is deleted.

   Overloading the Session-Timeout Attribute is problematic in
   situations where it is necessary to control the maximum session time
   and key lifetime independently.  For example, it might be desirable
   to limit the lifetime of cached keying material to 5 minutes while
   permitting a user once authenticated to remain connected for up to an
   hour without re-authenticating.  As a result, in the future,
   additional attributes can be specified to control the lifetime of
   cached keys; these attributes MAY modify the meaning of the
   Session-Timeout Attribute in specific circumstances.

Top      Up      ToC       Page 39 
   Since the TSK lifetime is often determined by authenticator
   resources, and the backend authentication server has no insight into
   the TSK derivation process by the principle of ciphersuite
   independence, it is not appropriate for the backend authentication
   server to manage any aspect of the TSK derivation process, including
   the TSK lifetime.

3.5.2.  Lower-Layer Mechanisms

   Lower-layer mechanisms can be used to enable the lifetime of keying
   material to be negotiated between the peer and authenticator.  This
   can be accomplished either using the Secure Association Protocol or
   within the lower-layer transport.

   Where TSKs are established as the result of a Secure Association
   Protocol exchange, it is RECOMMENDED that the Secure Association
   Protocol include support for TSK re-key.  Where the TSK is taken
   directly from the MSK, there is no need to manage the TSK lifetime as
   a separate parameter, since the TSK lifetime and MSK lifetime are
   identical.

3.5.3.  EAP Method-Specific Negotiation

   As noted in [RFC3748] Section 7.10:

      In order to provide keying material for use in a subsequently
      negotiated ciphersuite, an EAP method supporting key derivation
      MUST export a Master Session Key (MSK) of at least 64 octets, and
      an Extended Master Session Key (EMSK) of at least 64 octets.  EAP
      Methods deriving keys MUST provide for mutual authentication
      between the EAP peer and the EAP Server.

   However, EAP does not itself support the negotiation of lifetimes for
   exported EAP keying material such as the MSK, EMSK, and IV.

   While EAP itself does not support lifetime negotiation, it would be
   possible to specify methods that do.  However, systems that rely on
   key lifetime negotiation within EAP methods would only function with
   these methods.  Also, there is no guarantee that the key lifetime
   negotiated within the EAP method would be compatible with backend
   authentication server policy.  In the interest of method independence
   and compatibility with backend authentication server implementations,
   management of the lifetime of keying material SHOULD NOT be provided
   within EAP methods.

Top      Up      ToC       Page 40 
3.6.  Key Cache Synchronization

   Key lifetime negotiation alone cannot guarantee key cache
   synchronization.  Even where a lower-layer exchange is run
   immediately after EAP in order to determine the lifetime of keying
   material, it is still possible for the authenticator to purge all or
   part of the key cache prematurely (e.g., due to reboot or need to
   reclaim memory).

   The lower layer can utilize the Discovery phase 0 to improve key
   cache synchronization.  For example, if the authenticator manages the
   key cache by deleting the oldest key first, the relative creation
   time of the last key to be deleted could be advertised within the
   Discovery phase, enabling the peer to determine whether keying
   material had been prematurely expired from the authenticator key
   cache.

3.7.  Key Strength

   As noted in Section 2.1, EAP lower layers determine TSKs in different
   ways.  Where exported EAP keying material is utilized in the
   derivation, encryption or authentication of TSKs, it is possible for
   EAP key generation to represent the weakest link.

   In order to ensure that methods produce EAP keying material of an
   appropriate symmetric key strength, it is RECOMMENDED that EAP
   methods utilizing public key cryptography choose a public key that
   has a cryptographic strength providing the required level of attack
   resistance.  This is typically provided by configuring EAP methods,
   since there is no coordination between the lower layer and EAP method
   with respect to minimum required symmetric key strength.

   Section 5 of BCP 86 [RFC3766] offers advice on the required RSA or DH
   module and DSA subgroup size in bits, for a given level of attack
   resistance in bits.  The National Institute for Standards and
   Technology (NIST) also offers advice on appropriate key sizes in
   [SP800-57].

Top      Up      ToC       Page 41 
3.8.  Key Wrap

   The key wrap specified in [RFC2548], which is based on an MD5-based
   stream cipher, has known problems, as described in [RFC3579] Section
   4.3.  RADIUS uses the shared secret for multiple purposes, including
   per-packet authentication and attribute hiding, considerable
   information is exposed about the shared secret with each packet.
   This exposes the shared secret to dictionary attacks.  MD5 is used
   both to compute the RADIUS Response Authenticator and the
   Message-Authenticator Attribute, and concerns exist relating to the
   security of this hash [MD5Collision].

   As discussed in [RFC3579] Section 4.3, the security vulnerabilities
   of RADIUS are extensive, and therefore development of an alternative
   key wrap technique based on the RADIUS shared secret would not
   substantially improve security.  As a result, [RFC3579] Section 4.2
   recommends running RADIUS over IPsec.  The same approach is taken in
   Diameter EAP [RFC4072], which in Section 4.1.3 defines the
   EAP-Master-Session-Key Attribute-Value Pair (AVP) in clear-text, to
   be protected by IPsec or TLS.



(page 41 continued on part 3)

Next RFC Part