| Re: Proposed Resolution of Issue 254: Key Lifetime Issues | <– Date –> <– Thread –> |
From: Jari Arkko (jari.arkko piuha.net)
|
|
| Date: Fri, 18 Feb 2005 07:31:30 -0500 (EST) | |
Looks OK to me. A few nits inline:
s/should/SHOULD also/
--Jari
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.
s/forward/forward by the server/ (we still want to allow the NAS to derive keys from MSK...)
[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
s/should/SHOULD also/
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.
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.
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].
--Jari
-
Proposed Resolution of Issue 254: Key Lifetime Issues Bernard Aboba, February 17 2005
- Re: Proposed Resolution of Issue 254: Key Lifetime Issues Jari Arkko, February 18 2005
-
Re: Proposed Resolution of Issue 254: Key Lifetime Issues Bernard Aboba, February 18 2005
- Re: Proposed Resolution of Issue 254: Key Lifetime Issues Jari Arkko, February 20 2005
Results generated by Tiger Technologies using MHonArc.