Issue 392: Authorization Issues

Issue 392: Authorization Issues
Submitter name: Bernard Aboba
Submitter email address: abobainternaut.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."


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap