eap Mailing List: Issue 256: Miscellaneous NITs

[Bernard Aboba (aboba]

Issue 256: Miscellaneous NITs
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date first submitted: 8/20/2004
Reference:
Document: NetSel-03
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue

Boilerplate:

I think that the boilerplate is not right.  My understanding is that the
conformance required is to RFC 3668, not RFC 3667:

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

Abstract

"This solution is especially" -> "This is especially"
"so a mediating" -> "so that a mediating"

Section 1

"can have several roaming relationship" -> "can have several roaming
relationships"

referred to as peer -> referred to as the peer

The first sentence of paragraph 1 seems a bit out of place.  I'd put it
later on, and would move the implementation-specific information into
Section 2 as follows:

"1. Introduction

   An EAP peer (hereafter, also referred to as the peer) can have
   several sets of credentials, and its home network may have roaming
   relationships with several mediating networks.  As a result, the peer
   may be unclear about the appropriate Network Access Identity (NAI) to
   include in an EAP-Response/Identity.

   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.  This information is
   sent to the peer in an EAP Identity/Request message by appending it
   after the displayable message and a NUL character.

   Exactly how the identity hint is used by the EAP peer depends
   largely on the peer's local policy and configuration, and is outside
   the scope of this document.

   In many roaming situations, an access network can have several
   roaming relationship, either with several home networks, or 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 [1] 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 [6] for more detailed discussion about this
   problem space.

   Section 2 describes the required behavior of implementations of this
   specification, as well as the packet format for structuring and presenting
   identity hint information to an EAP peer.  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.

2. Implementation requirements

   An EAP peer implementing this specification MUST be able to receive
   an identity hint in an initial EAP Identity/Request, or in a
   subsequent EAP Identity/Request.

   The EAP authenticator MAY send an identity hint to the peer in the
   initial EAP Identity/Request.  If the identity hint is not sent
   initially (such as when the authenticator does not support this
   specification), then if the EAP server receives an EAP Identity/
   Response with an unacceptable NAI Realm, EAP servers implementing
   this specification SHOULD reply with an EAP Identity/Request
   containing an identity hint.

   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.

   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.

2.1 Packet Format

   The identity hint is placed after the displayable string and
   a NUL character in the EAP-Request/Identity.  The following ABNF [4]
   defines a "NAIRealms" attribute for presenting the identity hint
   information.  The attribute's value consists of a set of realm names
   separated by a semicolon.

      identity-request-data = [ displayable-string ]
                              [ %x00 "NAIRealms=" realm-list  ]
      displayable-string    = *OCTET
      realm-list            = realm /
                              ( realm-list ";" realm )

   The "OCTET" rule is defined in [4] and the "realm" rule is defined in
   [1].

   A sample hex dump of an EAP Identity Request packet is shown below.

      01                        ; Code: Request
      00                        ; Identifier: 0
      00 43                     ; Length: 67 octets
      01                        ; Type: Identity
      48 65 6c 6c 6f 21 00 4e   ; "Hello\0NAIRealms=example.com;mnc014.
      41 49 52 65 61 6c 6d 73   ; mcc310.3gppnetwork.org"
      3d 69 73 70 2e 65 78 61
      6d 70 6c 65 2e 63 6f 6d
      3b 6d 6e 63 30 31 34 2e
      6d 63 63 33 31 30 2e 33
      67 70 70 6e 65 74 77 6f
      72 6b 2e 6f 72 67

   Some existing systems are known to use EAP Identity/Request messages
   to send proprietary information to the peer.  This proprietary
   information is considered to be part of the displayable-string in the
   ABNF shown above.  In other words, the NUL character followed by the
   NAIRealms list MUST be placed at the end."

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
   that does not override any local policies at the peer."

I think you need to say a bit more about what an attacker could do with
this and the potential counter-measures.  The main threat seems to be
discovery of the potential peer identities. If the peer is using a weak
EAP method for some identities, this might be used by an attacker to
steal credentials for that identity.

So you might refer to specific local policies that cannot be overriden,
such as requiring mutual authentication, strong keys, etc.  Also, the peer
may choose to restrict the hints to which it will respond -- a given
identity might be locked down to a particular SSID and not given out to
another one, regardless of the hint.

Appendix

"   The RADIUS proxy/server is EAP aware.  It acts only on the RADIUS
   UserName(1) attribute and does not have to parse the EAP-Message
   attribute."

I think you mean to say "The RADIUS proxy need not be EAP aware.  It acts
only on the RADIUS User-Name attribute and does not have to parse the
EAP-Message attribute."