[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Review of RFC 2486bis
Thanks for your review Bernard. I have adopted your
suggestions and placed an editor's revision of the
draft at
http://www.arkko.com/publications/nai/naibis.txt
http://www.arkko.com/publications/nai/naibisdiff.txt
Can you check if you like the text that I provided
for the "authoritative" realm issue?
Another thing that we still need to work on is the international
NAI support. I do not know the answer to your questions,
and we have also a design decision of SASLPrep+IDN vs. IEN
to make. But I think I can get someone who knows about this
to help out... or input from the list would also be
appreciated.
Some more comments inline:
Bernard Aboba wrote:
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."
Your text sounds good, thanks. I changed
the draft.
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."
Ok. Changed.
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."
Right.
Change "IPSEC tunnel mode" to "IPsec tunnel mode."
Done.
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]."
Yes.
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."
Sounds better.
In Section 2.1, change:
" c = < a character as specified in
Section 2.4
>"
To:
" c = < a character as specified in Section 2.4 >"
Hmm... a bug in xml2rfc. Oh well, substituting with
hardcoded section number text...
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."
This is better, and makes it possible to retain conformance
in older devices while at the same time recommending a longer
length to be supported.
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?
I don't think it means that. It simply means that if you are the
RADIUS proxy for FOO.COM you shouldn't mess with the username part
if the domain part is BAR.COM. But I'm not sure how to express this
in exact technical terms. How about this:
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 a part of the
authoritative domain (in the sense of Section 4) for that realm.
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
The intention was to have the SASL-Prep be the authority for the
username part and IDN handle the domain part. The other option is
of course to make the whole thing an IEN. This is an open
issue. See also below...
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?
We probably do. I certainly don't know enough about the matter.
In fact, I have some one in mind who knows and has promised to
assist... I'll register this as an issue.
Section 2.8 does not list "eng%nancy@bigu.edu" 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.
Yes. Others have reported these as well. Due to the need to
use official example DNS names, it doesn't say @howard.edu
etc anymore, but my editor's version has these examples as
valid NAIs:
@privatecorp.example.net
eng%nancy@example.net
Author's addresses: for this purpose my email should be:
bernarda@microsoft.com.
Done.
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.
Very good. Thanks.
--Jari
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>