Subject: [eap] Proposed Resolution of Issue 254: Key Lifetime Issues

From: Bernard Aboba <[email-masked]>
Date: Thu, 17 Feb 2005 19:57:29 -0800 (PST)

The text of Issue 254 is available here:
http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue 254

The proposed resolution is to gather all key management-related material
into Section 4, which reads as follows:

4.  Key Management

   The EAP peer, authenticator and backend server may support key
   caching.  Since EAP supports key derivation, but not key management,
   this functionality needs to be provided by the Secure Association
   Protocol.  Key management support includes:

[a]  Key lifetime determination.  EAP does not support negotiation of
     key lifetimes, nor does it support rekey without reauthentication.
     As a result, the Secure Association Protocol is responsible for
     rekey and determination of the key lifetime.  Where key caching is
     supported, secure negotiation of key lifetimes is RECOMMENDED.
     Lower layers that support rekey, but not key caching may not
     require key lifetime negotiation.  To take an example from IKE, the
     difference between IKEv1 and IKEv2 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 rekeying the SA
     when necessary.

[b]  Key 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 the peer
     may not be able to determine before attempting to use a AAA-Key
     whether it exists within the authenticator cache.  It is therefore
     RECOMMENDED for the Secure Association Protocol to provide a
     mechanism for key state resynchronization.  Since in this situation
     one or more of the parties initially do not possess a key with
     which to protect the resynchronization exchange, securing this
     mechanism may be difficult.

[c]  Key selection.  Where key caching is supported, it may be possible
     for the EAP peer and authenticator to share more than one key of a
     given type.  As a result, the Secure Association Protocol needs to
     support key selection, using the EAP Key Naming scheme described in
     this document.

[d]  Key scope determination.  Since the Discovery phase is handled out-
     of-band, EAP does not provide a mechanism by which the peer can
     determine the authenticator identity.  As a result, where the
     authenticator has multiple ports and AAA-Key caching is supported,
     the EAP peer may not be able to determine the scope of validity of
     a AAA-Key.  Similarly, where the EAP peer has multiple ports, the
     authenticator may not be able to determine whether a peer has
     authorization to use a particular AAA-Key.  To allow key scope
     determination, the lower layer SHOULD provide a mechanism by which
     the peer can determine the scope of the AAA-Key cache on each
     authenticator, and by which the authenticator can determine the
     scope of the AAA-Key cache on a peer.

4.1.  Key Caching

   Key caching may be supported on the EAP peer, authenticator and
   backend server.  Where explicitly supported by the lower layer, the
   EAP peer and authenticator MAY cache the AAA-Key and/or TSKs.  The
   structure of the key cache on the peer and authenticator is defined
   by the lower layer.  Unless specified by the lower layer, the EAP
   peer, authenticator and server MUST assume that peers and
   authenticators do not cache the AAA-Key or TSKs.

   The EAP peer and server MAY cache keys exported by the EAP method as
   well as keys derived from them, subject to the following
   restrictions:

[1]  In order to avoid key reuse, on the EAP server, transported keys
     are deleted once they are sent.  An EAP server MUST NOT retain keys
     that it has previously sent to the authenticator.  For example, an
     EAP server that has transported a AAA-Key based on the MSK MUST
     delete both the AAA-Key and the MSK, and no keys may be derived
     from either the AAA-Key or the MSK from that point forward.

[2]  Keys which are not transported, such as the EMSK, MAY be cached on
     the EAP server.  While AMSKs calculated from the EMSK MUST be
     deleted from the EAP server once they are transported, the parent
     EMSK may remain in the EAP server cache.

4.2.  Parent-Child Relationships

   When keying material exported by EAP methods expires,  all keying
   material derived from the exported keying material expires, including
   the AAA-Key, AMSKs and TSKs.

   When an EAP reauthentication takes place, new keying material is
   derived and exported by the EAP method, which eventually results in
   replacement of calculated keys, including the AAA-Key, AMSKs, and
   TSKs.

   As a result,  while the lifetime of calculated keys can be less than
   or equal that of the exported keys they are derived from, it cannot
   be greater.  For example, TSK rekey may occur prior to EAP
   reauthentication.

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

4.3.  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 may rekey TEKs during a 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 rekey MUST occur prior to wrapping of the counter.
   Similarly, TSKs MUST remain cryptographically separate from TEKs
   despite TEK rekeying or caching. This prevents TEK compromise from
   leading directly to compromise of the TSKs and vice versa.

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

4.4.  Exported and Calculated Key Lifetimes

   All EAP methods generating keys are required to generate the MSK and
   EMSK, and may optionally generate the IV.  However, EAP, defined in
   [RFC3748], does not support the negotiation of lifetimes for exported
   keying material such as the MSK, EMSK and IV.

   Several mechanisms exist for managing key lifetimes:

[a]  AAA attributes.  AAA protocols such as RADIUS [RFC2865] and
     Diameter [DiamEAP] support the Session-Timeout attribute.  The
     Session-Timeout value represents the maximum lifetime of the
     exported keys, and all keys calculated from it.  If the AAA server
     caches exported keys, then it MUST expire the exported keys and all
     keys calculated from them, no later than the future time indicated
     by Session-Timeout.

     On the authenticator,  where EAP is used for authentication, the
     Session-Timeout value represents the maximum session time prior to
     re-authentication, as described in [RFC3580].  Where EAP is used
     for pre-authentication, the session may not start until some future
     time, or may never occur.  Nevertheless, the Session-Timeout value
     represents the time after which the AAA-Key, and all keys
     calculated from it, will have expired on the authenticator.  If the
     session subsequently starts, re-authentication will be initiated
     once the Session-Time has expired.  If the session never started,
     or started and ended, the AAA-Key and all keys calculated from it
     will be expired by the authenticator prior to the future time
     indicated by Session-Timeout.

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

[b]  Lower layer mechanisms.  While AAA attributes can communicate the
     maximum exported key lifetime, this only serves to synchronize the
     key lifetime between the backend authentication server and the
     authenticator.  Lower layer mechanisms can then be used to enable
     the lifetime of exported and calculated keys to be negotiated
     between the peer and authenticator.

     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 resynchronization. Where the TSK
     is taken from the AAA-Key, there is no need to manage the TSK
     lifetime as a separate parameter, since the TSK lifetime and AAA-
     Key lifetime are identical.

[c]  System defaults.  Where the EAP method does not support the
     negotiation of the exported key lifetime, and a key lifetime
     negotiation mechanism is not provided by the lower lower, there may
     be no way for the peer to learn the exported key liftime.  In this
     case it is RECOMMENDED that the peer assume a default value of the
     exported key lifetime; 8 hours is suggested.  Similarly, the
     lifetime of calculated keys can also be managed as a system
     parameter on the authenticator.

4.5.  Key cache synchronization

   Issues arise when attempting to synchronize the key cache on the peer
   and authenticator.  Lifetime negotiation alone cannot guarantee key
   cache synchronization.

   One problem is that the AAA protocol cannot guarantee synchronization
   of key lifetimes between the peer and authenticator.  Where the
   Secure Association Protocol is not run immediately after EAP
   authentication, the exported and calculated key lifetimes will not be
   known by the peer during the hiatus.  Where EAP pre-authentication
   occurs, this can leave the peer uncertain whether a subsequent
   attempt to use the exported keys will prove successful.

   However, even where the Secure Association Protocol is run
   immediately after EAP, it is still possible for the authenticator to
   reclaim resources if the created key state is not immediately
   utilized.

   The lower layer may utilize Discovery mechanisms to assist in this.
   For example, the authenticator manages the AAA-Key cache by deleting
   the oldest AAA-Key first (LIFO), the relative creation time of the
   last AAA-Key to be deleted could be advertised with the Discovery
   phase, enabling the peer to determine whether a given AAA-Key had
   been expired from the authenticator key cache prematurely.

4.6.  Key Scope Issues

   As described in Section 2.3, the AAA-Key is calculated from the EMSK
   and MSK by the EAP peer and server, and is used as the root of the
   ciphersuite-specific key hierarchy.  Where a backend authentication
   server is present, the AAA-Key is transported from the EAP server to
   the authenticator; where it is not present, the AAA-Key is calculated
   on the authenticator.

   Regardless of how many sessions are initiated using it, the AAA-Key
   scope is between the EAP peer that calculates it, and the
   authenticator that either calculates it (where no backend
   authenticator is present) or receives it from the server (where a
   backend authenticator server is present).

   It should be understood that an authenticator or peer:

   [a] may contain multiple physical ports;
   [b] may advertise itself as multiple "virtual" authenticators
       or peers;
   [c] may utilize multiple CPUs;
   [d] may support clustering services for load balancing or failover.

   As illustrated in Figure 1, an EAP peer with multiple ports may be
   attached to one or more authenticators, each with multiple ports.
   Where the peer and authenticator identify themselves using a port
   identifier such as a link layer address, it may not be obvious to the
   peer which authenticator ports are associated with which
   authenticators.  Similarly, it may not be obvious to the
   authenticator which peer ports are associated with which peers.  As a
   result, the peer and authenticator may not be able to determine the
   scope of the AAA-Key.

   When a single physical authenticator advertises itself as multiple
   "virtual authenticators", the EAP peer and authenticator also may not
   be able to agree on the scope of the AAA-Key, creating a security
   vulnerability.  For example, the peer may assume that the "virtual
   authenticators" are distinct and do not share a key cache, whereas,
   depending on the architecture of the physical AP, a shared key cache
   may or may not be implemented.

   Where the AAA-Key is shared between "virtual authenticators" an
   attacker acting as a peer could authenticate with the "Guest"
   "virtual authenticator" and derive a AAA-Key.  If the virtual
   authenticators share a key cache, then the peer can utilize the AAA-
   Key derived for the "Guest" network to obtain access to the
   "Corporate Intranet" virtual authenticator.

   Several measures are recommended to address these issues:

[a]  Authenticators are REQUIRED to cache associated authorizations
     along with the AAA-Key and apply authorizations consistently.  This
     ensures that an attacker cannot obtain elevated privileges even
     where the AAA-Key cache is shared between "virtual authenticators".

[b]  It is RECOMMENDED that physical authenticators maintain separate
     AAA-Key caches for each "virtual authenticator".

[c]  It is RECOMMENDED that each "virtual authenticator" identify itself
     distinctly to the AAA server, such as by utilizing a distinct NAS-
     identifier attribute.  This enables the AAA server to utilize a
     separate credential to authenticate each "virtual authenticator".

[d]  It is RECOMMENDED that Secure Association Protocols identify peers
     and authenticators unambiguously, without incorporating implicit
     assumptions about peer and authenticator architectures.  Using
     port-specific MAC addresses as identifiers is NOT RECOMMENDED where
     peers and authenticators may support multiple ports.

[e]  The AAA server and authenticator MAY implement additional
     attributes in order to further restrict the AAA-Key scope.  For
     example, in 802.11, the AAA server may provide the authenticator
     with a list of authorized Called or Calling-Station-Ids and/or
     SSIDs for which the  AAA-Key is valid.

[f]  Where the AAA server provides attributes restricting the key scope,
     it is RECOMMENDED that restrictions be securely communicated by the
     authenticator to the peer.  This is typically accomplished using
     the Secure Association Protocol,  but also can be accomplished via
     the EAP method or the lower layer.

4.7.  Key Strength

   In order to guard against brute force attacks, EAP methods deriving
   keys need to be capable of generating keys with an appropriate
   effective symmetric key strength.  In order to ensure that key
   generation is not the weakest link, it is RECOMMENDED that EAP
   methods utilizing public key cryptography choose a public key that
   has a cryptographic strength meeting the symmetric key strength
   requirement.

   As noted in [RFC3766] Section 5, this results in the following
   required RSA or DH module and DSA subgroup size in bits, for a given
   level of attack resistance in bits:

        Attack Resistance     RSA or DH Modulus     DSA subgroup
           (bits)              size (bits)          size (bits)
        -----------------     -----------------     ------------
        70                          947                 128
        80                         1228                 145
        90                         1553                 153
        100                        1926                 184
        150                        4575                 279
        200                        8719                 373
        250                       14596                 475

4.8.  Key Wrap

   As described in [RFC3579] Section 4.3, known problems exist in the
   key wrap specified in [RFC2548].  Where the same RADIUS shared secret
   is used by a PAP authenticator and an EAP authenticator, there is a
   vulnerability to known plaintext attack.  Since RADIUS uses the
   shared secret for multiple purposes, including per-packet
   authentication, 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
   some concerns exist relating to the security of this hash
   [MD5Attack].

   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, [RFC3759] Section 4.2
   recommends running RADIUS over IPsec.  The same approach is taken in
   Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key
   attributes, to be protected by IPsec or TLS.

   Where an untrusted AAA intermediary is present (such as a RADIUS
   proxy or a Diameter agent), and data object security is not used, the
   AAA-Key may be recovered by an attacker in control of the untrusted
   intermediary.  Possession of the AAA-Key enables decryption of data
   traffic sent between the peer and a specific authenticator; however
   where key separation is implemented, compromise of the AAA-Key does
   not enable an attacker to impersonate the peer to another
   authenticator, since that requires possession of the EMSK, which is
   not transported by the AAA protocol.  This vulnerability may be
   mitigated by implementation of redirect functionality, as provided in
   [RFC3588].
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Feb 2005 14:29:56 +0200

>      from either the AAA-Key or the MSK from that point forward.

s/forward/forward by the server/ (we still want to allow the
NAS to derive keys from MSK...)

>    may have been removed. EAP servers should verify that the long-term

s/should/SHOULD also/

>    been expired from the authenticator key cache prematurely.

Should we talk about the potential use of the EAP channel (with
things like draft-arkko-eap-service-identity-auth) to deliver
lifetime information? I'm not proposing that we need to do that --
in fact I'm quite happy with the "system default" approach -- but
sounds like it is something might be mentioned.

>            (bits)              size (bits)          size (bits)

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 18 Feb 2005 10:33:02 -0800 (PST)

> NAS to derive keys from MSK...)

Change made.

> s/should/SHOULD also/

Change made.

> sounds like it is something might be mentioned.

Yes, I think we should discuss this.  Can you file an issue on that
subject?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Sun, 20 Feb 2005 23:15:22 +0200

> Yes, I think we should discuss this.  Can you file an issue on that

Yes. Here goes:

Description of issue
Submitter name: Jari Arkko
Submitter email address: [email-masked]
Date first submitted: Feb 20, 2004
Reference: -
Document: Keying Framework
Comment type: T
Priority: 1 - Should fix
Section: 4.4 and 4.5

Requested change:

Add text to the end of Section 4.4:

   [d] Method specific negotiation within EAP. While EAP
       itself does not support lifetime negotiation,
       it would be 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.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap