| Resolution: Rewrite of Security Considerations Section | <– Date –> <– Thread –> |
From: Bernard Aboba (bernard_aboba hotmail.com)
|
|
| Date: Mon, 24 Oct 2005 03:07:40 -0400 (EDT) | |
Here is the proposed rewrite of the Security Considerations Section,
addressing Issues 279, 294 and 302.
5.1. Terminology
5.2. Threat Model
[6] An attacker may replay packets.
5.3. Authenticator Compromise
5.4. Spoofing
5.5. Downgrade Attacks
5.6. Unauthorized Disclosure
5.7. Replay Protection
5.8. Key Freshness
5.9. Elevation of Privilege
5.10. Man-in-the-middle Attacks
5.11. Denial of Service Attacks
5.12. Impersonation
5.13. Channel Binding
------------------------------------------------------------------------------------------- 5. Security Considerations
In order to analyze whether the EAP conversation achieves it security goals, it is first necessary to state those goals as well as the underlying security assumptions.
The overall goal of the EAP conversation is to derive fresh session keys between the EAP peer and authenticator that are known only to those parties, and for both the EAP peer and authenticator to demonstrate that they are authorized to perform their roles either by each other or by a trusted third party (the AAA server).
The principals of the authentication phase are the EAP peer and server. Completion of an EAP method exchange supporting key derivation results in the derivation of EAP keying material (MSK, EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID) and server (identified by the Server-ID). Both the EAP peer and EAP server know the exported keying material to be fresh.
The principals of the AAA Key transport exchange are the EAP authenticator and the EAP server. Completion of the AAA exchange results in the transport of EAP keying material from the EAP server (identified by the Server-ID) to the EAP authenticator (identified by the NAS-Identifier) without disclosure to any other party. Both the EAP server and EAP authenticator know this keying material to be fresh.
The principals of the Secure Association Protocol are the EAP peer (identified by the Peer-ID) and authenticator (identified by the NAS- Identifier). Completion of the Secure Association Protocol results in the derivation of TSKs known only to the EAP peer and authenticator. Both the EAP peer and authenticator know the TSKs to be fresh.
5.1. Terminology
"Cryptographic binding", "Cryptographic separation", "Key strength" and "Mutual authentication" are defined in [RFC3748] and are used with the same meaning here.
5.2. Threat Model
The EAP threat model is described in [RFC3748] Section 7.1. The security properties of EAP methods (known as "security claims", described in [RFC3784] Section 7.2.1), address these threats. EAP method requirements for applications such as Wireless LAN authentication are described in [RFC4017]. The RADIUS threat model is described in [RFC3579] Section 4.1, and responses to these threats are described in [RFC3579] Sections 4.2 and 4.3.
However, in addition to threats against EAP and AAA, there are other system-level threats worth discussing. These include:
[1] An attacker may compromise or steal an EAP authenticator, in an
attempt to gain access to other EAP authenticators or obtain long-
term secrets.[2] An attacker may compromise an EAP authenticator in an effort to
commit fraud. For example, a compromised authenticator may provide
incorrect information to the EAP peer and/or server via out-of-band
mechanisms (such as via a AAA or lower layer protocol). This
includes impersonating another authenticator, or providing
inconsistent information to the peer and EAP server.[3] An attacker may try to modify or spoof packets, including Discovery
or Secure Association Protocol frames, EAP or AAA packets.[4] An attacker may attempt a downgrade attack in order to exploit
known weaknesses in an authentication method or cryptographic
transform.[5] An attacker may attempt to induce an EAP peer, authenticator or
server to disclose keying material to an unauthorized party, or
utilize keying material outside the context that it was intended
for.[6] An attacker may replay packets.
[7] An attacker may cause an EAP peer, authenticator or server to reuse
an stale key. Use of stale keys may also occur unintentionally. For example, a poorly implemented AAA server may provide stale
keying material to an authenticator, or a poorly implemented
authenticator may reuse nonces.[8] An authenticated attacker may attempt to obtain elevated privilege
in order to access information that it does not have rights to.In order to address these threats, [Housley] provides a description of mandatory system security properties. Issues relating system security requirements are discussed in the sections that follow.
5.3. Authenticator Compromise
In the event that an authenticator is compromised or stolen, an attacker may gain access to the network via that authenticator, or may obtain the credentials required for that authenticator/AAA client to communicate with one or more AAA servers. However, this should not allow the attacker to compromise other authenticators or the AAA server, or obtain long-term user credentials.
The implications of this requirement are many, but some of the more important are as follows:
No Key Sharing
An EAP authenticator MUST NOT share any keying material with
another EAP authenticator, since if one EAP authenticator were
compromised, this would enable the compromise of keying material on
another authenticator. In order to be able to determine whether
keying material has been shared, it is necessary for the identity
of the EAP authenticator to be defined and understood by all
parties that communicate with it.No AAA Credential Sharing
AAA credentials (such as RADIUS shared secrets, IPsec pre-shared
keys or certificates) MUST NOT be shared between AAA clients, since
if one AAA client were compromised, this would enable an attacker
to impersonate other AAA clients to the AAA server, or even to
impersonate a AAA server to other AAA clients.No Compromise of Long-Term Credentials
An attacker obtaining TSKs, TEKs or EAP keying material such as the
MSK MUST NOT be able to obtain long-term user credentials such as
pre-shared keys, passwords or private-keys without breaking a
fundamental cryptographic assumption.5.4. Spoofing
The use of per-packet authentication and integrity protection provides protection against spoofing attacks. Diameter [RFC3588] provides support for per-packet authentication and integrity protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides for per-packet authentication and integrity protection via use of the Message-Authenticator attribute.
[RFC3748] Section 7.2.1 describes the "integrity protection" security claim and [RFC4017] requires use of EAP methods supporting this claim.
In order to prevent forgery of Secure Association Protocol frames, per-frame authentication and integrity protection is RECOMMENDED on all messages. [IEEE-802.11i] supports per-frame integrity protection and authentication on all messages within the 4-way handshake except the first message. An attack leveraging this ommission is described in [Analysis].
5.5. Downgrade Attacks
The ability to negotiate the use of a particular cryptographic algorithm provides resilience against compromise of a particular cryptographic algorithm. This is usually accomplished by including an algorithm identifier in the protocol, and by specifying the algorithm requirements in the protocol specification. In order to prevent downgrade attacks, secure confirmation of the "best" ciphersuite is required.
[RFC3748] Section 7.2.1 describes the "protected ciphersuite negotiation" security claim that refers to the ability of an EAP method to negotiate the ciphersuite used to protect the EAP conversation, as well as to integrity protect the negotiation. [RFC4017] requires EAP methods satisfying this security claim.
Diameter [RFC3588] provides support for cryptographic algorithm negotiation via use of IPsec or TLS. RADIUS [RFC3579] does not support the negotiation of cryptographic algorithms, and relies on MD5 for integrity protection, authentication and confidentiality, despite known weaknesses in the algorithm [MD5Attack]. This issue can be addressed via use of RADIUS over IPsec, as described in [RFC3579] Section 4.2.
As a result, EAP methods and AAA protocols are capable of addressing downgrade attacks. To ensure against downgrade attacks within lower layer protocols, algorithm independence is REQUIRED with lower layers using EAP for key derivation. For interoperability, at least one suite of mandatory-to-implement algorithm MUST be selected. Lower layer protocols supporting EAP for key derivation SHOULD also support secure ciphersuite negotiation. As described in [RFC1968], PPP ECP does not provide support for secure ciphersuite negotiation. However, [IEEE-802.11i] does support secure ciphersuite negotiation.
5.6. Unauthorized Disclosure
While preserving algorithm independence, confidentiality of all keying material MUST be maintained. To prevent unauthorized disclose of keys, each party in the EAP conversation MUST be authenticated to the other parties with whom it communicates. Keying material MUST be bound to the appropriate context.
[RFC3748] Section 7.2.1 describes the "mutual authentication" and "dictionary attack resistance" claims, and [RFC4017] requires EAP methods satisfying these claims. EAP methods complying with [RFC4017] therefore provide for mutual authentication between the EAP peer and server. Binding of EAP keying material (MSK, EMSK) to the appropriate context is provided by the Peer-ID and Server-ID which are exported along with the keying material.
Diameter [RFC3588] provides for per-packet authentication and integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also provides for per-packet authentication and integrity protection. Where the NAS/authenticator and AAA server communicate directly and credible keywrap is used (see Section 3.7), this ensures that the AAA Key Transport phase achieves its security objectives: mutually authenticating the AAA client/authenticator and AAA server and providing EAP keying material to the EAP authenticator and to no other party.
As noted in Section 3.1, the Secure Association Protocol does not by itself provide for mutual authentication between the EAP peer and authenticator, even if mutual possession of EAP keying material is proven. However, where the NAS/authenticator and AAA server communicate directly, the AAA server can verify the correspondence between NAS identification attributes, the source address of packets sent by the NAS, and the AAA credentials. As long as the NAS has not shared its AAA credentials with another NAS, this allows the AAA server to authenticate the NAS. Using Channel Bindings, the EAP peer can then determine whether the NAS/authenticator has provided the same identifying information to the EAP peer and AAA server.
Peer and authenticator authorization MUST be performed. Authorization is REQUIRED whenever a peer associates with a new authenticator. Authorization checking prevents an elevation of privilege attack, and ensures that an unauthorized authenticator is detected. Authorizations SHOULD be synchronized between the EAP peer, server, authenticator. Once the EAP conversation exchanges are complete, all of these parties should hold the same view of the authorizations associated the other parties. If peer authorization is restricted, then the peer SHOULD be made aware of the restriction.
The AAA exchange provides the EAP authenticator with authorizations relating to the EAP peer. However, neither the EAP nor AAA exchanges provides authorizations to the EAP peer. In order to ensure that all parties hold the same view of the authorizations it is RECOMMENDED that the Secure Association Protocol enable communication of authorizations between the EAP authenticator and peer.
In order to enable key binding and authorization of all parties, it is RECOMMENDED that the parties use a set of identities that are consistent between the conversation phases. RADIUS [RFC2865] and Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator identify itself by including one or more identification attributes within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS- IPv6-Address).
Since the AAA server provides EAP keying material for use by the EAP authenticator as identified by these attributes, where an EAP authenticator may have multiple ports, it is RECOMMENDED for the EAP authenticator to identify itself using NAS identification attributes during the Secure Association Protocol exchange with the EAP peer. This enables the EAP peer to determine whether EAP keying material has been shared between EAP authenticators as well as to confirm with the AAA server that an EAP authenticator proving possession of EAP keying material during the Secure Association Protocol was authorized to obtain it. Typically, the NAS-Identifier attribute is most convenient for this purpose, since a NAS/authenticator may have multiple IP addresses.
Similarly, the AAA server authorizes the EAP authenticator to provide access to the EAP peer identified by the Peer-ID, securely verified during the EAP authentication exchange. In order to determine whether EAP keying material has been shared between EAP peers, where the EAP peer has multiple ports it is RECOMMENDED for the EAP peer to identify itself using the Peer-ID during the Secure Association Protocol exchange with the EAP authenticator.
5.7. Replay Protection
Replay protection allows a protocol message recipient to discard any message that was recorded during a previous legitimate dialogue and presented as though it belonged to the current dialogue. [RFC3748] Section 7.2.1 describes the "replay protection" security claim and [RFC4017] requires use of EAP methods supporting this claim.
Diameter [RFC3588] provides support for replay protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] protects against replay of keying material via the Request Authenticator. However, some RADIUS packets are not replay protected. In Accounting, Disconnect and CoA-Request packets the Request Authenticator contains a keyed MAC rather than a Nonce. The Response Authenticator in Accounting, Disconnect and CoA Response packets also contains a keyed MAC whose calculation does not depend on a Nonce in either the Request or Response packets. Therefore unless an Event-Timestamp attribute is included or IPsec is used, the recipient may not be able to determine whether these packets have been replayed.
In order to prevent replay of Secure Association Protocol frames, replay protection is REQUIRED on all messages. [IEEE-802.11i] supports replay protection on all messages within the 4-way handshake.
5.8. Key Freshness
A session key should be considered compromised if it remains in use too long. As noted in [Housley], session keys MUST be strong and fresh, while preserving algorithm independence. A fresh cryptographic key is one that is generated specifically for the intended use. Each session deserves an independent session key; disclosure of one session key MUST NOT aid the attacker in discovering any other session keys.
Fresh keys are required even when a long replay counter (that is, one that "will never wrap") is used to ensure that loss of state does not cause the same counter value to be used more than once with the same session key.
EAP, AAA and the lower layer each bear responsibility for ensuring the use of fresh, strong session keys:
EAP EAP methods need to ensure the freshness and strength of EAP keying
material provided as an input to session key derivation. [RFC3748]
Section 7.10 states that "EAP methods SHOULD ensure the freshness
of the MSK and EMSK, even in cases where one party may not have a
high quality random number generator. A RECOMMENDED method is for
each party to provide a nonce of at least 128 bits, used in the
derivation of the MSK and EMSK." The contribution of nonces
enables the EAP peer and server to ensure that exported EAP keying
material is fresh. [RFC3748] Section 7.2.1 describes the "key strength" and "session
independence" security claims, and and [RFC4017] requires use of
EAP methods supporting these claims as well as being capable of
providing an equivalent key strength of 128 bits or greater.AAA The AAA protocol needs to ensure that transported keying material
is fresh and is not utilized outside its recommended lifetime.
Replay protection is necessary for key freshness, but an attacker
can deliver a stale (and therefore potentially compromised) key in
a replay-protected message, so replay protection is not sufficient. The EAP Session-ID, derived from the EAP Type and Method-ID (based
on the nonces contributed by the peer and server) enables the EAP
peer, authenticator and server to distinguish EAP conversations.
However, unless the authenticator keeps track of EAP Session-IDs,
the authenticator cannot use the Session-ID to guarantee the
freshness of EAP keying material. As described in [RFC3580] Section 3.17, When sent in an Access-
Accept along with a Termination-Action value of RADIUS-Request, the
Session-Timeout attribute specifies the maximum number of seconds
of service provided prior to re-authentication. [IEEE-802.11i]
also utilizes the Session-Timeout attribute to limit the maximum
time that EAP keying material may be cache. Therefore the use of
the Session-Timeout attribute enables the AAA server to limit the
exposure of EAP keying material.Lower Layer
The lower layer Secure Association Protocol MUST generate a fresh
session key for each session, even if the keying material and
parameters provided by EAP methods are cached, or the peer or
authenticator lacks a high entropy random number generator. A
RECOMMENDED method is for the peer and authenticator to each
provide a nonce or counter of at least 128 bits, used in session
key derivation.5.9. Elevation of Privilege
Parties MUST NOT have access to keying material that is not needed to perform their own role. A party has access to a particular key if it has access to all of the secret information needed to derive it. If a post-EAP handshake is used to establish session keys, the post-EAP handshake MUST specify the scope for session keys.
Transported EAP keying material is permitted to be accessed by the EAP peer, authenticator and server. The EAP peer and server derive the transported keying material during the process of mutually authenticating each other using the selected EAP method. During the Secure Association Protocol, the EAP peer utilizes the transported EAP keying material to demonstrate to the authenticator that it is the same party that authenticated to the EAP server and was authorized by it. The EAP authenticator utilizes the transported EAP keying material to prove to the peer not only that the EAP conversation was transported through it (this could be demonstrated by a man-in-the-middle), but that it was uniquely authorized by the EAP server to provide the peer with access to the network. Unique authorization can only be demonstrated if the EAP authenticator does not share the transported keying material with a party other than the EAP peer and server.
TSKs are permitted to be accessed only by the EAP peer and authenticator. Since the TSKs can be determined from the transported EAP keying material and the cleartext of the Secure Association Protocol exchange, the AAA server will have access to the TSKs unless it deletes the transported EAP keying material after sending it.
5.10. Man-in-the-middle Attacks
As described in [I-D.puthenkulam-eap-binding], EAP method sequences and compound authentication mechanisms may be subject to man-in-the- middle attacks. When such attacks are successfully carried out, the attacker acts as an intermediary between a victim and a legitimate authenticator. This allows the attacker to authenticate successfully to the authenticator, as well as to obtain access to the network.
In order to prevent these attacks, [I-D.puthenkulam-eap-binding] recommends derivation of a compound key by which the EAP peer and server can prove that they have participated in the entire EAP exchange. Since the compound key must not be known to an attacker posing as an authenticator, and yet must be derived from quantities that are exported by EAP methods, it may be desirable to derive the compound key from a portion of the EMSK. In order to provide proper key hygiene, it is recommended that the compound key used for man-in- the-middle protection be cryptographically separate from other keys derived from the EMSK.
5.11. Denial of Service Attacks
Key caching may result in vulnerability to denial of service attacks. For example, EAP methods that create persistent state may be vulnerable to denial of service attacks on the EAP server by a rogue EAP peer.
To address this vulnerability, EAP methods creating persistent state may wish to limit the persistent state created by an EAP peer. For example, for each peer an EAP server may choose to limit persistent state to a few EAP conversations, distinguished by the EAP Session- ID. This prevents a rogue peer from denying access to other peers.
Similarly, to conserve resources an authenticator may choose to limit the persistent state corresponding to each peer. This can be accomplished by limiting each peer to persistent sttate corresponding to a few EAP converations, distinguished by the EAP Session-ID.
Depending on the media, creation of new TSKs may or may not imply deletion of previously derived TSKs. Where there is no implied deletion, the authenticator may choose to limit the number of TSKs and associated state that can be stored for each peer.
5.12. Impersonation
Both the RADIUS and Diameter protocols are potentially vulnerable to impersonation by a rogue authenticator.
While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588] support mutual authentication between the authenticator (known as the AAA client) and the backend authentication server (known as the AAA server), the security mechanisms vary according to the AAA protocol.
In RADIUS, the shared secret used for authentication is determined by the source address of the RADIUS packet. As noted in [RFC3579] Section 4.3.7, it is highly desirable that the source address be checked against one or more NAS identification attributes so as to detect and prevent impersonation attacks.
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or NAS-IPv6-Address attributes may not correspond to the source address. Since the NAS-Identifier attribute need not contain an FQDN, it also may not correspond to the source address, even indirectly. [RFC2865] Section 3 states:
A RADIUS server MUST use the source IP address of the RADIUS
UDP packet to decide which shared secret to use, so that
RADIUS requests can be proxied.This implies that it is possible for a rogue authenticator to forge NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within a RADIUS Access-Request in order to impersonate another authenticator. Among other things, this can result in messages (and transorted keying material) being sent to the wrong authenticator. Since the rogue authenticator is authenticated by the RADIUS proxy or server purely based on the source address, other mechanisms are required to detect the forgery. In addition, it is possible for attributes such as the Called-Station-Id and Calling-Station-Id to be forged as well.
As recommended in [RFC3579] Section 4.3.7, this vulnerability can be mitigated by having RADIUS proxies check NAS identification attributes against the source address.
While [RFC3588] requires use of the Route-Record AVP, this utilizes FQDNs, so that impersonation detection requires DNS A/AAAA and PTR RRs to be properly configured. As a result, it appears that Diameter is as vulnerable to this attack as RADIUS, if not more so. To address this vulnerability, it is necessary to allow the backend authentication server to communicate with the authenticator directly, such as via the redirect functionality supported in [RFC3588].
5.13. Channel Binding
It is possible for a compromised or poorly implemented EAP authenticator to communicate incorrect information to the EAP peer and/or server. This may enable an authenticator to impersonate another authenticator or communicate incorrect information via out- of-band mechanisms (such as via AAA or the lower layer).
Where EAP is used in pass-through mode, the EAP peer does not verify the identity of the pass-through authenticator. Within the Secure Association Protocol, the EAP peer and authenticator only demonstrate mutual possession of the transported EAP keying material. This creates a potential security vulnerability, described in [RFC3748] Section 7.15.
[RFC3579] Section 4.3.7 describes how an EAP pass-through authenticator acting as a AAA client can be detected if it attempts to impersonate another authenticator (such by sending incorrect Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA protocol). However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the AAA server while communicating misleading information to the EAP peer via the lower layer.
For example, a compromised authenticator can utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via the lower layer, or for a pass-through authenticator acting as a AAA client to provide an incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA protocol.
As noted in [RFC3748] Section 7.15, this vulnerability can be addressed by EAP methods that support a protected exchange of channel properties such as endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. For example, see [I- D.arkko-eap-service-identity-auth].
It is also possible to achieve Channel Bindings without transporting data over EAP. For example, see [draft-ohba-eap-aaakey-binding]. In this approach the authenticator informs the backend server about the Channel Binding parameters using AAA, and the backend server calculates transported keying material based on this parameter set, making it impossible for the peer and authenticator to complete the Secure Association Protocol if there was a mismatch in the parameters.
The main difference between these approaches is that Channel Binding support within an EAP method may require upgrading or changing the EAP method, impacting both the peer and the server. Where Channel Bindings are implemented in AAA, the peer, authenticator and the backend server need to be upgraded, but the EAP method need not be modified.
-
Resolution: Rewrite of Security Considerations Section Bernard Aboba, October 24 2005
- Re: Resolution: Rewrite of Security Considerations Section Jari Arkko, October 24 2005
Results generated by Tiger Technologies using MHonArc.