eap Mailing List: [Issue 280]: Nits on Identity Selection -05

[Bernard Aboba (aboba]

Issue 280: Nits on Identity Selection-05
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date first submitted: 11/16/2004
Reference:
Document: IDSEL-05
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue

Abstract:

"  This document defines a mechanism that allows an access network to
   provide identity selection hints to an EAP client.  The purpose is to
   help the client in selecting the most appropriate identity and NAI
   decoration to use.  This is especially useful when the access network
   does not have a direct roaming relationship with the client's home
   network, so that a mediating network, such as a roaming consortium or
   broker, is used."

->

"The Extensible Authentication Protocol (EAP) is defined in RFC 3748.
This document defines a mechanism that allows an access network to
provide identity selection hints to an EAP peer.
The purpose is to assist the EAP peer in selecting an appropriate
Network Access Identifier (NAI).  This is especially useful when
the access network does not have a direct roaming relationship with
the peer's home network, so that a mediating network, such as a
roaming consortium or broker, is used."

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Implementation requirements  . . . . . . . . . . . . . . . . .  3
     2.1   Packet format  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
   4.  Security considerations  . . . . . . . . . . . . . . . . . . .  5
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  Appendix (informative) - Delivery Options  . . . . . . . . . .  6
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.1   Normative references . . . . . . . . . . . . . . . . . . . .  9
   7.2   Informative references . . . . . . . . . . . . . . . . . . . 10
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
       Intellectual Property and Copyright Statements . . . . . . . . 12

Please indent Section 7.1. and 7.2.  Also Intellectual Property,
Disclaimer of Validity, Copyright, etc. are separate sections.

1. Introduction

"This document defines a mechanism that allows the access network to
provide identity selection hints, and more specifically information
about its roaming relationships, to an EAP peer."

->

"The Extensible Authentication Protocol (EAP) is defined in [RFC3748].
This document defines a mechanism that allows the access network to
provide identity selection hints, including information
about its roaming relationships, to an EAP peer."

"   In many roaming situations, an access network can have several
   roaming relationships, either with several home networks, or
   mediating networks such as roaming consortiums and brokers, or both."

->

"   In many roaming situations, an access network can have several
   roaming relationships, either with several home networks, or with
   mediating networks such as roaming consortiums and brokers, or both."

"  One possible application for this mechanism is to help in selecting
   what kind of NAI decoration [rfc2486bis] must be applied to allow
   proper routing of AAA messages to the home AAA server.  If there are
   several possible mediating networks, the peer can choose which one to
   use.  However, exactly how the selection is made is beyond the scope
   of this document.  See [netsel-problem] for more detailed discussion
   about this problem space."

The terms NAI, NAI decoration and NAI realm are not defined in the
document.
I think you need to define these terms or reference a definition somewhere
else.  Perhaps in a  terminology section?

"  The appendix in
   section 6 describes the delivery options that can be implemented by
   an access network to deliver identity hint information to an EAP
   peer."

->

"  Appendix A describes the delivery options that can be implemented by
   an access network to deliver identity hint information to an EAP
   peer."

Section 2

Delete the extra line break prior to Section 2.

Change "EAP Identity/Request" to "EAP-Request/Identity" and
"EAP IdentityResponse" to "EAP-Response/Identity" everywhere in the
document.

"   If after the EAP server sends an EAP Identity/Request containing an
   identity hint, the peer responds with an EAP Identity/Response
   containing an unacceptable NAI Realm, then the EAP server MAY respond
   immediately with an EAP Failure packet, or it MAY first send an
   EAP-Notification providing information on the reason for the failure."

->

"  If after the EAP server sends an EAP-Request/Identity containing an
   identity hint, the peer responds with an EAP-Response/Identity
   containing an unacceptable NAI realm, then the EAP server MAY respond
   immediately with an EAP Failure packet, or it MAY first send an
   EAP-Notification providing the reason for the failure."

"   EAP does not support fragmentation for Identity/Request messages, so
   the size of identity hint information is limited by the link MTU.
   The exact limit depends on the lower layer in question, but it is at
   least 1020 octets."

->

"As noted in [RFC3748], Section 3.1, the minimum EAP MTU size is 1020
octets.  EAP does not support fragmentation of EAP-Request/Identity
messages, so
that the maximum length of the identity hint information is limited
by the link MTU."

Section 2.1

"defines a "NAIRealms" attribute"  -> "defines an NAIRealms attribute"

Section 4

"   Identity hint information is delivered inside an EAP Identity Request
   before the user authenticates to the network, and before the network
   is authenticated to the user.  This information can be modified by an
   attacker.  Therefore, it MUST be considered an unauthenticated hint."

->

"  Identity hint information is delivered inside an EAP-Request/Identity
   before the authentication conversation begins, and therefore can
   be modified by an attacker.  The NAIRealms attribute therefore MUST
   be treated as a hint by the peer.

"   Unauthenticated hints may result in peers inadvertently revealing
   other or additional identities than they intended to, leading to a
   privacy vulnerability.  Note that in EAP, the identity the peer wants
   to use is in general carried in a cleartext message, so this is only
   a variation of an existing vulnerability.  Method-specific identity
   protection is one of the ways that this vulnerability can be
   addressed.

   Similarly, in a situation where the peer has multiple identities to
   choose from, an unauthenticated hint can lead to a situation where an
   attacker convinces the peer to choose an identifier that is bound to
   the weakest EAP method.  To guard against this vulnerability, the use
   of as strong EAP methods as possible is recommended.  Note that this
   vulnerability is similar to an existing vulnerability where link
   layers advertise network names (such as 802.11 SSIDs) without
   authenticating these advertisements either at all or only at the end
   of the authentication process.

   In case the identity hint information is used to select a mediating
   network for NAI decoration, it should be noted that at least with
   some EAP methods, there is no way for the home network AAA server to
   verify that the mediating network used was actually the same one that
   the peer had requested."

->

"  Unauthenticated hints may result in peers inadvertently revealing
   additional identities, compromising privacy.  Since the EAP-Response/
   Identity is sent in the clear,  this vulnerability already exists.
   This vulnerability can be addressed via method-specific identity
   exchanges.

   Similarly, in a situation where the peer has multiple identities to
   choose from, an attacker can use a forged hint to convince the
   peer to choose an identity bound to a weak EAP method.  Requiring
   the use of strong EAP methods can protect against this.  A similar
   issue already exists with respect to unprotected link layer
   advertisements such as 802.11 SSIDs.

   Where the identity hint is used to select a mediating
   network, with existing EAP methods there may not be a way for the
   home AAA server to verify that the mediating network selected by
   the peer was actually used."