| Re: Issue 392: Authorization Issues | <– Date –> <– Thread –> |
From: Bernard Aboba (bernard_aboba hotmail.com)
|
|
| Date: Tue, 6 Feb 2007 00:18:20 -0800 (PST) | |
OK. I've gone through the -06 "Guidelines" document and attempted to sync
up the requirements with those in this document. In some cases, the
"Guidelines" requirements text has changed significantly from earlier drafts
(e.g. the context binding text is much more explicit).
In doing the sync, I noticed that Section 5 did not include a section on Key Naming, so I added a small section on that. Since the purpose of Section 5 was to describe how the requirements are met, each second-level section now includes a Requirements statement, and all the requirements of the "Guidelines" document Section 3 are now included.
Find below an updated Section 5. Hopefully this re-organization more clearly delineates the requirements and their relationship to the explanatory text.
In doing the sync, I noticed that Section 5 did not include a section on Key Naming, so I added a small section on that. Since the purpose of Section 5 was to describe how the requirements are met, each second-level section now includes a Requirements statement, and all the requirements of the "Guidelines" document Section 3 are now included.
Find below an updated Section 5. Hopefully this re-organization more clearly delineates the requirements and their relationship to the explanatory text.
------------------------------------------------------------------------------------------------------------------------------------ 5. Security Considerations
The EAP threat model is described in [RFC3748] Section 7.1. The security properties of EAP methods (known as "security claims") are described in [RFC3748] Section 7.2.1. 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. In developing the threat model, it is assumed that:
All traffic is visible to the attacker. The attacker can alter, forge or replay messages. The attacker can reroute messages to another principal. The attacker may be a principal or an outsider. The attacker can compromise any key that is sufficiently old.
Threats arising from these assumptions include:
(a) An attacker may compromise or steal an EAP peer or authenticator,
in an attempt to gain access to other EAP peers or authenticators
or to obtain long-term secrets.(b) An attacker may attempt a downgrade attack in order to exploit
known weaknesses in an authentication method or cryptographic
algorithm.(c) An attacker may try to modify or spoof packets, including Discovery
or Secure Association Protocol frames, EAP or AAA packets.(d) 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.(e) An attacker may alter, forge or replay packets.
(f) 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 backend authentication server mayAboba, et al. Standards Track [Page 43]
INTERNET-DRAFT EAP Key Management Framework 6 February 2007
provide stale keying material to an authenticator, or a poorly implemented authenticator may reuse nonces.
(g) An authenticated attacker may attempt to obtain elevated privilege
in order to access information that it does not have rights to.(h) An attacker may attempt a man-in-the-middle attack in order to gain
access to the network.(i) 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.(j) An attacker may launch a denial of service attack against the EAP
peer, authenticator or backend authentication server.In order to address these threats, [I-D.housley-aaa-key-mgmt] Section 3 provides a description of mandatory system security properties. These requirements are discussed in the sections that follow.
5.1. Peer and Authenticator Compromise
Requirement: In the event that an authenticator is compromised or stolen, an attacker may gain access to the network through that authenticator, or may obtain the credentials required for the authenticator/AAA client to communicate with one or more backend authentication servers. Compromise of a single authenticator MUST NOT compromise keying material held by any other authenticator within the system, and SHOULD NOT allow the attacker to compromise the backend authentication server or obtain long-term user credentials. Compromise of a single peer MUST NOT compromise keying material held by any other peer within the system, including session keys and long- term keys. In the context of a key hierarchy, the compromise of one node in the key hierarchy MUST NOT disclose the information necessary to compromise other branches in the key hierarchy. Obviously, the compromise of the root of the key hierarchy will compromise all of the keys; however, a compromise in one branch MUST NOT result in the compromise of other branches. There are many implications of these requirements; however, two implications deserve highlighting. First, the scope of the keying material must be defined and understood by all parties that communicate with a party that holds that keying material. Second, a party that holds keying material in a key hierarchy MUST NOT share that keying material with parties that are associated with other branches in the key hierarchy.
Some of the implications of the requirement 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. Similarly, an EAP peer MUST NOT
share any keying material with another EAP peer.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 backend authentication
server, or even to impersonate a backend authentication 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.2. Cryptographic Negotiation
Requirement: The ability to negotiate cryptographic algorithms resilience against compromise of a particular algorithm. This is usually accomplished by including an algorithm identifier and parameters in the protocol, and by specifying the algorithm requirements in the protocol specification. While highly desirable, the ability to negotiate key derivation functions (KDFs) is not required. For interoperability, at least one suite of mandatory-to- implement algorithms MUST be selected. The selection of the "best" cryptographic algorithm SHOULD be securely confirmed. The mechanism SHOULD detect attempted roll back attacks.
EAP methods satisfying [RFC4017] requirements and AAA protocols utilizing transmission layer security are capable of addressing downgrade attacks. [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 method conversation, as well as to integrity protect the ciphersuite negotiation. [RFC4017] requires EAP methods satisfying this security claim. However, EAP methods may not enable the negotiation of all cryptographic algorithms, such as Key Distribution Functions (KDFs).
Diameter [RFC3588] provides support for cryptographic algorithm negotiation via use of IPsec [RFC4301] or TLS [RFC4346]. 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 [MD5Collision]. This issue can be addressed via use of RADIUS over IPsec, as described in [RFC3579] Section 4.2. However, TLS and IKEv2 currently do not enable negotiation of the Key Distribution Function (KDF).
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. While [IEEE-802.16e] and [IEEE-802.11i] support selection of ciphersuites for protection of data, they do not support negotiation of the cryptographic primitives used within the Secure Association Protocol, such as message integrity checks (MICs) and KDFs.
5.3. Confidentiality and Authentication
Requirement: Each party in the EAP, AAA and Secure Association Protocol conversations MUST be authenticated to the other parties with whom they communicate. Authentication mechanisms MUST maintain the confidentiality of any secret values used in the authentication process. When a Secure Association Protocol is used to establish session keys, the parties involved in the secure association protocol MUST identify themselves using identities that are meaningful in the lower layer protocol environment that will employ the session keys. While preserving algorithm independence, confidentiality and integrity of all keying material MUST be maintained.
5.3.1. Spoofing
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. IKEv2 [RFC4306] supports per-frame integrity protection and authentication, as does [IEEE-802.16e]. [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 omission is described in [Analysis].
5.3.2. Impersonation
Both the RADIUS [RFC2865] and Diameter [RFC3588] protocols are potentially vulnerable to a rogue authenticator impersonating another authenticator. While both protocols support mutual authentication between the AAA client/authenticator and the backend authentication server, the security mechanisms vary.
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 Network Access Server (NAS) client identification attributes so as to detect and prevent impersonation attacks.
When RADIUS Access-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 transported 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.
[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). 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 Fully Qualified Domain Names (FQDNs), so that impersonation detection requires DNS A, AAAA and PTR Resource Records (RRs) to be properly configured. As a result, 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.3.3. 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 EAP conversation. Within the Secure Association Protocol, the EAP peer and authenticator only demonstrate mutual possession of the transported EAP keying material; they do not mutually authenticate. This creates a potential security vulnerability, described in [RFC3748] Section 7.15.
As described in the previous section, it is possible for a AAA proxy to detect a AAA client attempting 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 backend authentication 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. Also, a pass-through authenticator acting as a AAA client can provide an incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the backend authentication 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. Typically the EAP method imports Channel Binding parameters from the lower layer on the peer, and transmits them securely to the EAP server, which exports them to the lower layer or AAA layer. However, transport may occur from EAP server to peer, or may be bi-directional. On the side of the exchange (peer or server) where Channel Binding is verified, the lower layer or AAA layer passes the result of the verification (TRUE or FALSE) up to the EAP method. While the verification can be done either by the peer or the server, typically only the server has the knowledge to determine the correctness of the values, as opposed to merely verifying their equality. For further discussion, see [I- D.arkko-eap-service-identity-auth].
It is also possible to perform Channel Binding without transporting data over EAP. For example, see [I-D.draft-ohba-eap-channel- binding]. In this approach the EAP method includes Channel Binding parameters in the calculation of exported EAP keying material, making it impossible for the peer and authenticator to complete the Secure Association Protocol if there is a mismatch in the Channel Binding parameters. However, this approach can only be applied where EAP methods generating key material are used along with lower layers that utilize the keying material. For example, this mechanism would not enable verification of Channel Binding on wired IEEE 802 networks using [IEEE 802.1X].
5.3.4. Mutual Authentication
[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.
[RFC3748] Section 7.2.1 also describes the "Cryptographic binding" security claim, and [RFC4017] requires support for this claim. 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.
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 authenticator/AAA client and backend authentication server communicate directly and credible keywrap is used (see Section 3.8), this ensures that the AAA Key Transport (phase 1b) achieves its security objectives: mutually authenticating the AAA client/authenticator and backend authentication server and providing EAP keying material to the EAP authenticator and to no other party.
[RFC2607] Section 7 describes the security issues occurring when the authenticator/AAA client and backend authentication server do not communicate directly. Where a AAA intermediary is present (such as a RADIUS proxy or a Diameter agent), and data object security is not used, transported keying material may be recovered by an attacker in control of the intermediary. As discussed in Section 2.1, unless the TSKs are derived independently from EAP keying material (as in IKEv2), possession of transported keying material enables decryption of data traffic sent between the peer and the authenticator to whom the keying material was transported. It also allows the AAA intermediary to impersonate the authenticator or the peer. Since the peer does not authenticate to a AAA intermediary it has no ability to determine whether it is authentic or authorized to obtain keying material.
However, as long as EAP keying material or keys derived from it are only utilized by a single authenticator, compromise of the transported keying material does not enable an attacker to impersonate the peer to another authenticator. Vulnerability to compromise of a AAA intermediary can be mitigated by implementation of redirect functionality, as described in [RFC3588] and [RFC4072].
The Secure Association Protocol does not provide for mutual authentication between the EAP peer and authenticator, only mutual proof of possession of transported EAP keying material. In order for the peer to verify the identity of the authenticator, mutual proof of possession needs to be combined with impersonation prevention and Channel Binding. Impersonation prevention (described in Section 5.3.2) enables the backend authentication server to determine that the transported EAP keying material has been provided to the correct authenticator. When utilized along with impersonation prevention, Channel Binding (described in Section 5.3.3) enables the EAP peer to verify that the EAP server has authorized the authenticator to possess the transported EAP keying material. Completion of the Secure Association Protocol exchange demonstrates that the EAP peer and the authenticator possess the transported EAP keying material.
5.4. Key Binding
Requirement: Keying material MUST be bound to the appropriate context. Any party with legitimate access to keying material can determine its context. In addition, the protocol MUST ensure that all parties with legitimate access to keying material have the same context for the keying material. This requires that the parties are properly identified and authenticated, so that all of the parties that have access to the keying material can be determined. The context includes the following:
o The manner in which the keying material is expected to be used.
o The other parties that are expected to have access to the keying
material. o The maximum lifetime of the keying material. The maximum
lifetime of a child key SHOULD NOT be greater than the maximum
lifetime of its parent in the key hierarchy.Within EAP, keying material (MSK, EMSK) is bound to the Peer-Id and Server-Id which are exported along with the keying material. However, not all EAP methods support authenticated server identities (see Appendix A).
Within the AAA protocol, transported keying material is destined for the EAP authenticator identified by the NAS-Identifier attribute within the request, and is for use by the EAP peer identified by the Peer-Id, User-Name [RFC2865] or Chargeable User Identity (CUI) [RFC4372] attributes. The maximum lifetime of the transported keying material may be provided, as discussed in Section 3.5.1. Key usage restrictions may also be included as described in Section 3.2. Key lifetime issues are discussed in Sections 3.3, 3.4 and 3.5.
5.5. Authorization
Requirement: Peer and authenticator authorization MUST be performed. These entities MUST demonstrate possession of the appropriate keying material, without disclosing it. Authorization is REQUIRED whenever a peer associates with a new authenticator. The authorization checking prevents an elevation of privilege attack, and it ensures that an unauthorized authenticator is detected. Authorizations SHOULD be synchronized between the EAP peer, server, and authenticator. Once all protocol exchanges are complete, all of these parties should hold a common view of the authorizations associated the other parties. The Secure Association Protocol (phase 2) conversation may utilize different identifiers from the EAP conversation (phase 1a), so that binding between the EAP and Secure Association Protocol identities is REQUIRED.
As described in Section 2.2.1, consistent identification of the EAP authenticator enables the EAP peer to determine whether EAP keying material has been shared between EAP authenticators as well as to confirm with the backend authentication server that an EAP authenticator proving possession of EAP keying material during the Secure Association Protocol was authorized to obtain it.
Within the AAA protocol, the authorization attributes are bound to the transported keying material. While the AAA exchange provides the AAA client/authenticator with authorizations relating to the EAP peer, 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 lower layers where the authenticator consistently identifies itself to the peer and backend authentication server and the EAP peer completes the Secure Association Protocol exchange with the same authenticator through which it completed the EAP conversation, authorization of the authenticator is demonstrated to the peer by mutual authentication between the peer and authenticator as discussed in the previous section. Identification issues are discussed in Section 2.2 and key scope issues are discussed in Section 3.2.
Where the EAP peer utilizes different identifiers within the EAP method and Secure Association Protocol conversations, peer authorization may be difficult to demonstrate to the authenticator without additional restrictions. This problem does not exist in IKEv2 where the Identity Payload is used for peer identification both within IKEv2 and EAP, and where the EAP conversation is cryptographically protected within IKEv2 packets, binding the EAP and
Secure Association Protocol/IKEv2 exchanges. However within [IEEE-802.11i] the EAP peer identity is not used within the 4-way handshake, so that it is necessary for the authenticator to require that the EAP peer utilize the same MAC address for EAP authentication as for the 4-way handshake.
5.6. Replay Protection
Requirement: Exchanges MUST be replay protected, including AAA, EAP and Secure Association Protocol exchanges. 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; IKEv2 [RFC4306] also supports this.
5.7. Key Freshness
Requirement: While preserving algorithm independence, session keys MUST be strong and fresh. A session key SHOULD be considered compromised if it remains in use beyond its authorized lifetime. 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. A fresh cryptographic key is one that is generated specifically for the intended use. In this situation, a secure association protocol is used to establish session keys. The AAA protocol and EAP method MUST ensure that the keying material supplied as an input to session key derivation is fresh, and the secure association protocol MUST generate a separate session key for each session, even if the keying material provided by EAP is cached.
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 EAP
methods supporting these claims as well as methods capable of
providing equivalent key strength of 128 bits or greater. See
Section 3.7 for more information on key strength.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.
As discussed in Section 3.5, the Session-Timeout attribute enables
the backend authentication server to limit the exposure of
transported EAP keying material. The EAP Session-Id, described in Section 1.4, 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.Lower Layer
The Secure Association Protocol, described in Section 3.1, MUST
generate a fresh session key for each session, even if the keying
material and parameters provided by EAP methods are cached, or
either the peer or authenticator lack a high entropy random number
generator. A RECOMMENDED method is for the peer and authenticator
to each provide a nonce or counter used in session key derivation.
If a nonce is used, it is RECOMMENDED that it be at least 128 bits. While [IEEE-802.11i] and IKEv2 [RFC4306] satisfy this requirement,
[IEEE-802.16e] does not, since randomness is only contributed from
the Base Station.5.8. Key Scope Limitation
Requirement: Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role. A party has access to a particular key if it has access to all of the secret information needed to derive it. Any protocol that is used to establish session keys, MUST specify the scope for session keys, clearly identifying the parties to whom the session key is available.
Transported EAP keying material is permitted to be accessed by the EAP peer, authenticator and server. The EAP peer and server derive EAP keying material during the process of mutually authenticating each other using the selected EAP method. During the Secure Association Protocol exchange, the EAP peer utilizes derived 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 (see Section 1.5); TSK derivation is discussed in Section 2.1. Since demonstration of authorization within the Secure Association Protocol exchange depends on possession of transported EAP keying material, the backend authentication server can impersonate the authenticator and possibly to obtain the TSKs unless the backend server deletes the transported EAP keying material after sending it.
5.9. Key Naming
Requirement: A robust key naming scheme is REQUIRED, particularly where key caching is supported. The key name provides a way to refer to a key in a protocol so that it is clear to all parties which key is being referenced. Objects that cannot be named cannot be managed. All keys MUST be uniquely named, and the key name MUST NOT directly or indirectly disclose the keying material. If the key name is not based on the keying material, then one can be sure that it cannot be used to assist in a search for the key value.
EAP key names (defined in Section 1.4.1), along with the Peer-Id and Server-Id, uniquely identify EAP keying material, and do not directly or indirectly expose the keying material.
Existing AAA server implementations do not distribute key names along with the transported EAP keying material, although Diameter EAP [RFC4072], provides the EAP-Key-Name AVP for this purpose. Since the EAP-Key-Name AVP is defined within the RADIUS attribute space, it may be used either with RADIUS or Diameter.
Since the authenticator is not provided with the name of the transported keying material by existing backend authentication server implementations, existing Secure Association Protocols do not utilize EAP key names. For example, [IEEE-802.11i] supports PMK caching; to enable the peer and authenticator to determine the cached PMK to utilize within the 4-way handshake the PMK needs to be named. For this purpose [IEEE-802.11i] utilizes a PMK naming scheme which is based on the key. Since IKEv2 [RFC4306] does not cache transported EAP keying material, it does not need to refer to transported keying material.
5.10. 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 state corresponding to a few EAP conversations, 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.
-
Re: Issue 392: Authorization Issues Bernard Aboba, February 5 2007
- Re: Issue 392: Authorization Issues Bernard Aboba, February 6 2007
- Re: Issue 392: Authorization Issues M. Vanderveen, February 6 2007
- Re: Issue 392: Authorization Issues Bernard Aboba, February 6 2007
-
Re: Issue 392: Authorization Issues M. Vanderveen, February 6 2007
- Re: Issue 392: Authorization Issues Bernard Aboba, February 7 2007
Results generated by Tiger Technologies using MHonArc.