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.
------------------------------------------------------------
------------------------------------------------------------
------------
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 may
Aboba, 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.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
