Subject: [radext] Call for WG Adoption for draft-dekok-radext-nai-02; The Network Access Identifier

From: Jouni Korhonen <[email-masked]>
Date: Thu, 13 Dec 2012 09:47:36 +0200

Folks,

As discussed in Atlanta, we are ready to ask for the WG adoption of draft-dekok-radext-nai-02 (The Network Access Identifier "bis") starting today. The plan is that once we have had the adoption call finished we can move the document straight into WGLC (knowing there are already reviews done).

The WG adoption call ends 20th Dec. This is a quick one week call since we have had the document around quite long already. If you have concerns against the document, raise them in the mailing list. Silence will be counted as acceptance. Of course folks are encouraged to endorse the document in the mailing list.

- Jouni & Mauricio

---

From: Alan DeKok <[email-masked]>
Date: Sat, 15 Dec 2012 18:16:35 +0100

> The WG adoption call ends 20th Dec. This is a quick one week call since we have had the document around quite long already. If you have concerns against the document, raise them in the mailing list…

  As discusses early, the document should be split in two.

  My $0.02 is to accept the document as-is, rename it to
draft-ietf-radext-naibis-00.txt, and then split it.

  All of the RADIUS / Diameter text will then be removed, and placed
into a second document: draft-iet-radext-naiusage-00.txt

  The goal is to get the NAI-bis document published quickly.  Then,
discuss the usage of NAI within RADIUS as a slightly longer-term project.

  Alan DeKok.

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 15 Dec 2012 16:49:33 -0800

Are you suggesting this due to people who are using the NAI in protocols
other than RADIUS/Diameter?  

If you don't believe that there are a large number of people doing so, then
I don't see the point of the split.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alan DeKok
> Sent: Saturday, December 15, 2012 9:17 AM
> To: Jouni Korhonen
> Cc: Benoit Claise; [email-masked]; [email-masked]
> Subject: Re: [radext] Call for WG Adoption for draft-dekok-radext-nai-02;
> The Network Access Identifier
> 
> Jouni Korhonen wrote:
> > Folks,
> >
> > As discussed in Atlanta, we are ready to ask for the WG adoption of
draft-
> dekok-radext-nai-02 (The Network Access Identifier "bis") starting today.
> The plan is that once we have had the adoption call finished we can move
the
> document straight into WGLC (knowing there are already reviews done).
> >
> > The WG adoption call ends 20th Dec. This is a quick one week call since
we
> have had the document around quite long already. If you have concerns
> against the document, raise them in the mailing list. Silence will be
counted
> as acceptance. Of course folks are encouraged to endorse the document in
> the mailing list.
> 
draft-ietf-radext-
> naibis-00.txt, and then split it.
> 
>   All of the RADIUS / Diameter text will then be removed, and placed into
a
> second document: draft-iet-radext-naiusage-00.txt
> 
discuss the
> usage of NAI within RADIUS as a slightly longer-term project.
> 
>   Alan DeKok.
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Benoit Claise <[email-masked]>
Date: Thu, 20 Dec 2012 17:17:22 +0100

>    As discusses early, the document should be split in two.
Have we discussed this at the last meeting? I don't recall.
And the meeting minutes don't indicate this: 
http://www.ietf.org/proceedings/85/minutes/minutes-85-radext
We just rechartered to include THIS document, and the next thing is that 
we need to split it???

Regards, Benoit

---

From: Alan DeKok <[email-masked]>
Date: Thu, 20 Dec 2012 12:00:09 -0500

> Have we discussed this at the last meeting? I don't recall.

  I thought we had...

> We just rechartered to include THIS document, and the next thing is that

  I'm OK with leaving it as one document.

  Alan DeKok.

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 22 Dec 2012 12:01:35 +0200

Folks,

The deadline for the adoption call has completed. As there was no
opposition to adopt the document, we will take it into WG process.

@Alan: resubmit the current document as a draft-ietf-* as soon as
possible.

We will continue pursuing the one document approach (based on the
current charter). Of course WG is now free to decide anything on
the content as long as there is consensus and it fits to the 
charter.

- Jouni & Mauricio

> Folks,
>
> As discussed in Atlanta, we are ready to ask for the WG adoption
> of draft-dekok-radext-nai-02 (The  Network Access Identifier "bis")
> starting today. The plan is that once we have had the adoption call
> finished we can move the document straight into WGLC (knowing there
> are already reviews done).

> The WG adoption call ends 20th Dec. This is a quick one week call
> since we have had the document around quite long already. If you
> have concerns against the document, raise them in the mailing list.
> Silence will be counted as acceptance. Of course folks are encouraged
> to endorse the document in the mailing list.
>
> - Jouni & Mauricio

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 22 Dec 2012 05:24:29 -0800

> the content as long as there is consensus and it fits to the 

[BA]  When re-submitting the document as draft-ietf-*, please utilize the pre-5378 boilerplate, since the document contains text from RFC 4282 and RFC 2486.

Also, some notes:

Section 1.4
   The motivation to revise [RFC4282] began with internationalization
   concerns raised in the context of [EDUROAM].  Section 2.1 of
   [RFC4282] defines ABNF for realms which limits the realm grammar to
   English letters, digits, and the hyphen "-" character.  The intent
   appears to have been to encode, compare, and transport realms with
   the ToASCII operation defined in [RFC5890].  There are a number of
   problems with this approach:
[BA] One big problem with the RFC 4282 ABNF, is that it is not aligned 
with internationalization of the DNS.  You might note this in the first
bullet since it is referred to elsewhere. 

Section 2.1

   See [RFC5198] for a discussion of normalization; implementations of
   this specification MUST use the Normal Form Composed (NFC) for NAIs.

[BA] I would recommend carrying over the text from RFC 5335:

   See [RFC5198] for a discussion of normalization; the use of
   normalization form NFC is RECOMMENDED.

Section 2.3 

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

[BA] It should be pointed out that when using UTF-8 that the NAI
octet length constraint may result in a more severe constraint on the
number of UTF-8 characters.

Section 2.4

   Omitting the username part is RECOMMENDED over using a fixed username
   part, such as "anonymous", since it provides an unambiguous way to
   determine whether the username is intended to uniquely identify a
   single user.  

[BA] I might consider changing (or deleting) this sentence, since in
practice, I believe that use of a fixed username part is more popular
than omitting the username part.  

Section 2.5

   o  Realms MUST be of the form that can be registered as a
      Fully Qualified Domain Name (FQDN) within the DNS name system.

[BA] Delete "name system". 

Section 2.6 

   All normalization MUST be performed by end systems that take "local"
   text as input.  That is, text that is in an encoding other than
   UTF-8, or that has locale-specific variations.  In a network access
   setting, such systems are typically the client (e.g. EAP supplicant)
   and the Authentication, Authorization, and Accounting (AAA) server.

[BA] As used in this section, "normalization" appears to go beyond the 
conversion of Unicode characters to canonical form.  I might rewrite
this to say "Conversion to Unicode as well as normalization 
is expected to be performed by end systems that take "local" text
as input." 

   All other AAA systems (proxies, etc.)  MUST NOT perform
   normalization.  These other systems do not have access to locale and
   character set information that is available to end systems.

[BA] Suggest rewriting to say "Since AAA proxies do not have access to 
locale and character set information that is available to end systems, 
they are typically incapable of converting local input to Unicode." 

   EAP supplicants MUST normalize user names that get placed in the EAP-
   Response/Identity field.  They MUST NOT copy localized text into that
   field.  This normalization SHOULD be performed once, and then cached
   for subsequent use.

[BA] Since RFC 4282 was published, RADIUS has been extended to cover application protocols such as in
RFC 5090 (SIP and HTTP) and ABFAB.  As a result, the advice needs to be generalized. 

Suggest rewriting to "Copying of localized text into fields that can subsequently be placed into
the RADIUS User-Name attribute is problematic since this can result in a AAA proxy encountering non-UTF8
characters within what it expects to be an NAI, resulting in potential difficulties in realm routing.  
As an example, RFC 3579 Section 2.1 states:

   the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received
   from the peer into the User-Name attribute

As a result, AAA proxies expect the contents of the EAP-Response/Identity sent by an EAP supplicant to consist
of UTF-8 characters, not localized text."

Section 2.9

   The "realm" portion of the NAI is intended to be compatible with
   domain names used in DNS systems.  However, the "realm" portion
   within AAA systems is intended to be a UTF-8 string, not an ASCII
   string as with the DNS protocol.  Therefore, AAA systems transporting
   NAIs in an AAA protocol MUST NOT encode the "utf8-realm" portion
   using the ToAscii function.  That function creates strings that may
   be transported over DNS, and it is not appropriate for use within an
   AAA protocol.

[BA] Since the DNS protocol is 8-bit clean, I suggest the above text be modified as follows:

   'The "realm" portion of the NAI is intended to be compatible with
   Internationalized Domain Names [RFC5890]. Since the "realm" portion
   as transported within the RADIUS User-Name attribute is composed of 
   U-labels, not A-labels, there is no reason for a NAS to apply the
   ToAscii function to the "realm" portion of an NAI prior to placing
   the NAI into a RADIUS User-Name attribute.'

   When the realm portion of the NAI is used as the basis for name
   lookups within the DNS system, the ToASCII operation defined in
   [RFC5890] MAY be used to convert internationalized realm names to
   ASCII.  This function is normally handled by a DNS resolver library
   on the local system.  When this function is not handled by a DNS
   resolver library, the AAA system MAY perform the ToAscii conversion
   itself, before passing the modified realm name to the DNS resolver
   library.

[BA] As noted in RFC 6055, resolver APIs are not DNS-specific. 
So I would use the term "resolver API" rather than DNS resolver
library. Recommend the following text:

   When the realm portion of the NAI is used as the basis for name
   resolution, it may be necessary to convert internationalized
   realm names to ASCII using the ToASCII operation defined in
   [RFC5890].  As noted in [RFC6055] Section 2, resolver APIs are not necessarily
   DNS-specific, so that the ToASCII operation needs to be applied
   carefully:

     Applications that convert an IDN to A-label form before calling
     getaddrinfo() will result in name resolution failures if the Punycode
     name is directly used in such protocols.  Having libraries or
     protocols to convert from A-labels to the encoding scheme defined by
     the protocol (e.g., UTF-8) would require changes to APIs and/or
     servers, which IDNA was intended to avoid.

     As a result, applications that assume that non-ASCII names are
     resolved using the public DNS and blindly convert them to A-labels
     without knowledge of what protocol will be selected by the name
     resolution library, have problems.  

Section 2.10.1

   o  Re-writing of the User-Name in AAA servers means that it may not
      match the EAP-Response/Identity fields.  This mismatch may cause
       the home AAA server to reject the request as being malformed.

[BA[ AAA servers should not be comparing the RADIUS User-Name attribute
to the EAP-Response/Identity field, so I would suggest that this bullet
be deleted.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 22 Dec 2012 08:30:23 -0500

Bernard Aboba wrote:
> [BA]  When re-submitting the document as draft-ietf-*, please utilize
> the pre-5378 boilerplate, since the document contains text from RFC 4282
> and RFC 2486.

  OK.  I'll address the rest of your comments in a -02 rev of the
document.  That makes change tracking easier.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 22 Dec 2012 11:17:23 -0500

> the pre-5378 boilerplate, since the document contains text from RFC 4282

  I've updated the draft as per your comments, with some minor edits.
I'll upload the new version as soon as the -00 is approved.

  Unless there are pending concerns, we should probably do a last call
on it in early January.

  Alan DeKok.