Subject: [eap] Issue 392: Authorization Issues

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 03 Feb 2007 18:54:07 -0800

Issue 392: Authorization Issues
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
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

---

From: "M. Vanderveen" <[email-masked]>
Date: Tue, 6 Feb 2007 12:54:34 -0800 (PST)

I have read the new text and agree with most of them.
 
1. Here is one change that I disagre with ("should not" turned into "must not", and no basis from the Guidelines BCP-to-be that I can see): Section 5.1: 
Text of -17.txt: " 
[.. ]this should not allow the attacker to compromise other
authenticators or the backend authentication server"
New text: 
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
 
2. Compromise of Peer in section 5.1: hopefully this does not invalidate the idea of Group keys for multicast (if a Peer's group key is compromised, so will the group keys of other peers in his multicast group - can't be helped).
 
3. Last paragraph of Section 5.8 "
the backend authentication server can impersonate the authenticator ". Not really necessary to say this, especially since the guidelines say that the backend authentication server is a trusted party, yes? 

Some nits: page 43 bottom: "an stale key" -> "a stale key". 
Section 5.7, 3rd paragraph starts with "EAP EAP", 4th paragraph contains "and and", 5th paragraph starts with "AAA The AAA".

Best regards,
Michaela

----- Original Message ----
<too long to be included w/o moderator approval>

____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 06 Feb 2007 13:31:15 -0800

>1. Here is one change that I disagre with ("should not" turned into "must 
>not", and no basis from the Guidelines BCP-to-be that I can see): Section 
>5.1:
>Text of -17.txt: "

The MUST NOT appears to come from Section 3 of 
draft-housley-aaa-key-mgmt-06.txt:

      Prevent the Domino effect

         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.  Likewise, compromise of a single
         authenticator MUST NOT compromise keying material held by any
         other authenticator within the system.  In the context of a key
         hierarchy, this means that 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 this requirement; 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.

>2. Compromise of Peer in section 5.1: hopefully this does not invalidate 
>the idea of Group keys for multicast (if a Peer's group key is compromised, 
>so will the group keys of other peers in his multicast group - can't be 
>helped).

Right. We should add: "with the possible exception of group keys".

>the backend authentication server can impersonate the authenticator ". Not 
>really necessary to say this, especially since the guidelines say that the 
>backend authentication server is a trusted party, yes?

Right.  We can delete this.

>Section 5.7, 3rd paragraph starts with "EAP EAP", 4th paragraph contains 
>"and and", 5th paragraph starts with "AAA The AAA".

Thanks.  We should fix these.

---

From: "M. Vanderveen" <[email-masked]>
Date: Wed, 7 Feb 2007 10:40:29 -0800 (PST)

Sounds fine to me, thanks for your effort.

----- Original Message ----
From: Bernard Aboba <[email-masked]>
To: [email-masked]; [email-masked]
Sent: Wednesday, February 7, 2007 10:29:29 AM
Subject: Re: [eap] Issue 392: Authorization Issues

Here is some revised text:

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.  Similarly, if a peer is compromised or
   stolen, an attacker may obtain credentials required to
   communicate with one or more authenticators.  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, with
   the possible exception of group keys.  Likewise, compromise of a
   single authenticator MUST NOT compromise keying material held by any
   other authenticator within the system.  In the context of a key
   hierarchy, this means that 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 this requirement;
   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.

>From: "M. Vanderveen" <[email-masked]>
>To: Bernard Aboba <[email-masked]>, [email-masked]
>Subject: Re: [eap] Issue 392: Authorization Issues
>Date: Tue, 6 Feb 2007 13:48:46 -0800 (PST)
>
>I guess part of the confusion is between compromise of a key vs. compromise 
>of an entity. The latter probably includes the former (for keys that the 
>compromised entity holds).
>
>Compromise of an authenticator must not lead to compromise of another 
>authenticator. But here it seems that what we are saying is that compromise 
>of an authenticator must not lead to compromise of a key held by another 
>authenticator (who is still holding up and is not compromised). Perhaps the 
>guidelines should be clarified, e.g. compromise of a key must not lead to 
>compromise of another key (held by a different entity). This is what the 
>hierarchy discussion is applicable.
>
>Michaela

____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL