Subject: [eap] Issue 350: Requirements Confusion

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 12 Apr 2006 18:27:47 -0700

Issue 350: Requirements Confusion
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date Submitted: April 12, 2006
Reference:
Document: Keying-11
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Lower layer identities are not securely verified in phase 2a, they are just 
exchange.  Secure verification requires Channel Bindings.

In Section 2.2.1, change:

"Securely verify the lower layer identities within phase 2a;"

To:

"Supporting the integrity-protected exchange of identities within phase 2a;"

Section 3.1 states:

"As part of secure capabilities
negotiation, the Secure Association Protocol MUST support integrity
and replay protection of all messages."

This contradicts Section 5.3, which states:

"   In order to prevent forgery of Secure Association Protocol frames,
   per-frame authentication and integrity protection is RECOMMENDED on
   all messages."

It is also redundant with Section 5.6, which states:

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

Recommendation is to change:

"As part of secure capabilities
negotiation, the Secure Association Protocol MUST support integrity
and replay protection of all messages."

To:

"The Secure Association Protocol MUST
support integrity and replay protection of all capability
negotiation messages."

In Section 3.8 (Key Wrap), material is included that is more relevant to
Section 5.4 (Unauthorized Disclosure):

"  Where an untrusted 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 untrusted intermediary.  Possession of transported
   keying material enables decryption of data traffic sent between the
   peer and a specific authenticator.  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 an untrusted AAA intermediary can be mitigated by
   implementation of redirect functionality, as described in [RFC3588]
   and [RFC4072]."

Recommendation is to delete this material from Section 3.8 and insert the 
following text in
Section 5.4:

"  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 relates to the EAP peer identified by the Peer-ID, User-
   Name [RFC2865] or CUI [RFC4372] attributes.

  [RFC2607] Section 7 describes the security issues ocurring when the
   authenticator and backend authentication server do not communicate
   directly.  Where an untrusted 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 untrusted 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 a specific
   authenticator.  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 an untrusted AAA intermediary can be mitigated by
   implementation of redirect functionality, as described in [RFC3588]
   and [RFC4072]."

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

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