eap Mailing List: Issue 392: Authorization Issues

[Bernard Aboba (bernard_aboba]

Issue 392: Authorization Issues
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date Submitted: February 3, 2007
Reference:
Document: KEYING-17
Comment type: Technical
Priority: S
Section: 5.6, 5.7, 5.9
Rationale/Explanation of issue:

Section 5 does not include a sub-section on authorization issues; rather, 
discussion of authorization
is sprinkled throughout.  Also, there is not a crisp discussion of the 
distinction
between mutual authentication and mutual proof of possession within the 
Secure Association Protocol
exchange. The organization of the section is somewhat illogical; 
impersonation and
Channel Binding need to be discussed prior to getting into authorization. 
There is considerable
repetition, so some consolidation is required.  To provide clarity, more 
examples are needed.

The proposed resolution is to move the Impersonation and
Channel Binding sections up to Section 5.4 and 5.5,
and to change Sections 5.6, 5.7 and 5.9 to the following:

"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.

[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.

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.4)
enables the backend authentication server to determine that the
tranported EAP keying material has been provided to the correct
authenticator. When utilized along with impersonation prevention,
Channel Binding (described in Section 5.5) 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.7. Authorization

Keying material MUST be bound to the appropriate context. 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
and 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.

Within EAP, 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. However, not all EAP
methods support authenticated server identities (see Appendix A).

Within the AAA protocol, the authorization attributes provide the
information binding the transported keying material to the
appropriate context. For example, 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. 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.

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. Consistently identifying 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. 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.9. Key Freshness

A session key should be considered compromised if it remains in use
too long. As noted in [I-D.housley-aaa-key-mgmt]], 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 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."