eap Mailing List: Issue 350: Requirements Confusion

[Bernard Aboba (bernard_aboba]

Issue 350: Requirements Confusion
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
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]."