Issue 350: Requirements Confusion

Issue 350: Requirements Confusion
Submitter name: Bernard Aboba
Submitter email address: abobainternaut.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]."


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

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