Subject: [eap] Review of RFC 2486bis

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Mar 2004 17:38:37 -0800 (PST)

Abstract

The original RFC 2486 contained the following text:

"In order to enhance the interoperability of roaming and tunneling
services, it is desirable to have a standardized method for
identifying users.  This document proposes syntax for the Network
Access Identifier (NAI), the userID submitted by the client during
PPP authentication. It is expected that this will be of interest for
support of roaming as well as tunneling."

In RFC 2486bis, this was changed to:

"In order to provide roaming services, it is necessary to have a
standardized method for identifying users.  This document defines the
syntax for the Network Access Identifier (NAI), the user identity
submitted by the client during, for instance,  PPP and wireless LAN
authentication.

This paragraph appears to deprecate use of the NAI in tunneling
services as well as to generalize the use of the NAI beyond network
access.  Recommend changing to:

"In order to provide roaming services, it is necessary to have a
standardized method for identifying users.  This document defines the
syntax for the Network Access Identifier (NAI), the user identity
submitted by the client during network authentication."

Section 1 says:

"   Considerable interest exists for a set of features that fit within
   the general category of "roaming capability" for dialup Internet
   users, wireless LAN authentication, and other applications."

Propose changing to:

"   Considerable interest exists for a set of features that fit within
   the general category of "roaming capability" for network access,
   including dialup Internet users, VPN usage, wireless LAN
   authentication, and other applications."

In Section 1.1, change:

"The Network Access Identifier (NAI) is the userID submitted by the
client during PPP authentication.  In roaming, the purpose of the
NAI is to identify the user as well as to assist in the routing of
the authentication request.  Please note that the NAI may not
necessarily be the same as the user's e-mail address or the userID
submitted in an application layer authentication.

   Network Access Server
             The Network Access Server (NAS) is the device that clients
             dial in order to get access to the network. In PPTP
             terminology this is referred to as the PPTP Access
             Concentrator (PAC), and in L2TP terminology, it is referred
             to as the L2TP Access Concentrator (LAC).
"

To:

"The Network Access Identifier (NAI) is the user identity submitted by the
client during network access authentication.  In roaming, the purpose of
the NAI is to identify the user as well as to assist in the routing of
the authentication request.  Please note that the NAI may not
necessarily be the same as the user's e-mail address or the user identity
submitted in an application layer authentication.

Network Access Server
The Network Access Server (NAS) is the device that clients
connect to in order to get access to the network. In PPTP
terminology this is referred to as the PPTP Access
Concentrator (PAC), and in L2TP terminology, it is referred
to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it
is referred to as an Access Point."

Change "IPSEC tunnel mode" to "IPsec tunnel mode."

In Section 1.2, change:

"   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [3]."

To:

"   In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
   "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [3]."

In Section 1.3, change:

"   As described in [8], there are a number of services implementing
   dialup roaming, and the number of Internet Service Providers involved
   in roaming consortia is increasing rapidly."

To:

"As described in [8], there are a number of providers offering
network access services, and the number of Internet Service Providers
involved in roaming consortia is increasing rapidly."

In Section 2.1, change:

"   c           = < a character as specified in
   Section 2.4
    >"

To:

"   c           = < a character as specified in Section 2.4 >"

Section 2.2 states:

"   Devices handling NAIs MUST support an NAI length of at least 253
   octets.  However, the following interoperability considerations
   should be noted:

   o  RFC 2486 required the support of NAIs only up to the length of 72
      octets.  As a result, it can generally not be assumed that all
      devices can support 253 octets.

   o  NAIs are often transported in the User-Name attribute of RADIUS
      [10].  Unfortunately, RADIUS requires devices to support content
      lengths of only 63 octets for this attribute.  As a result, it may
      not be possible to transfer NAIs beyond 63 octets through all
      devices.  In addition, due to its message structure, RADIUS is
      unable to support content lengths beyond 253 octets"

Effectively, this section admits that RFC 2486bis renders existing devices
non-compliant;  moreover, due to a variety of limitations it is not clear
that devices could be compliant even if they wanted to.  This seems
problematic.

It might make more sense to say:

"   Devices handling NAIs MUST support an NAI length of at least 72
   octets.  Support for an NAI length of 253 octets is RECOMMENDED.
   However, the following implementation issues should be considered:

   o  NAIs are often transported in the User-Name attribute of RADIUS
      [10].  Unfortunately, [RFC2865] Section 5.1 states that
      "the ability to handle at least 63 octets is recommended."
      As a result, it may not be possible to transfer NAIs
      beyond 63 octets through all devices.  In addition, since
      only a single User-Name attribute may be included in a RADIUS
      message and the maximum attribute length is 253 octets,
      RADIUS is unable to support NAI lengths beyond 253 octets."

Section 2.3 states:

"  Interpretation of the "username" part of the NAI depends on the realm
   in question.  Therefore, the "username" part SHOULD be treated as
   opaque data when processed by nodes that are not authoritative (in
   some sense) for that realm."

I am not sure what "authoritative for that realm" means here.  This is
DNS terminology.  Does it imply that the NAS or RADIUS server supports
dynamic DNS client udpate or is running a DNS server itself?

Section 2.4 says:

"
   Characters of the username portion in a NAI MUST fulfill the
   requirements specified in [6]."

Is SASL-Prep the relevant authority here, or is this IEN?  In the
same vein:

Section 2.5 states:

"   As proposed in this document, the Network Access Identifier is of the
   form user@realm.  Please note that while the user portion of the NAI
   is based on the BNF described in [7], it has been extended for
   internationalization support as well as for purposes of Section 2.7,
   and is not necessarily compatible with the usernames used in e-mail.
   Note also that the internationalization requirements for NAIs and
   e-mail addresses are different, since the former need to be typed in
   only by the user himself and his own operator, not by others."

On the other hand, RFC 2486 states:

"Please note that while the user portion of the NAI conforms to the
BNF described in [5]"

[5] References RFC 822, the SMTP specification.  At the same time,
Section 4 indicates that there is no requirement that the NAI
represent a valid email address.  Perhaps we need to get a technical
advisor to assist us relating to these internationalization issues?

Section 2.8 does not list "[email-masked]" as a valid NAI, and
lists "@howard.edu" as an invalid NAI.  I'd restore the former example,
and given the privacy issues, the latter looks like it should be
valid now.

Author's addresses:  for this purpose my email should be:
[email-masked].

Section 4 says:

"   Note that the use of an FQDN as the realm name does not imply use of
   the DNS for location of the authentication server or for
   authentication routing.  Since to date roaming has been implemented
   on a relatively small scale, existing implementations typically
   handle location of authentication servers within a domain and perform
   authentication routing based on local knowledge expressed in proxy
   configuration files.  The implementations described in [8] have not
   found a need for use of DNS for location of the authentication server
   within a domain, although this can be accomplished via use of the DNS
   SRV record, described in [2].  Similarly, existing implementations
   have not found a need for dynamic routing protocols, or propagation
   of global routing information.  Note also that there is no
   requirement that the NAI represent a valid email address."

Note that roaming has been widely implemented at this point. I'd revise
this to say:

"  Note that the use of an FQDN as the realm name does not imply use of
   the DNS for location of the authentication server or for
   authentication routing.  Existing implementations typically
   handle location of authentication servers within a domain and perform
   authentication routing based on local knowledge expressed in proxy
   configuration files.  The implementations described in [8] have not
   found a need for use of DNS for location of the authentication server
   within a domain, although this can be accomplished via use of the DNS
   as described in [13].  Similarly, existing implementations
   have not found a need for dynamic routing protocols, or propagation
   of global routing information.  Note also that there is no
   requirement that that the NAI represent a valid email address."

Delete reference 2.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap