Subject: Re: [radext] Comments on draft-ietf-radext-nai-01

From: Alan DeKok <[email-masked]>
Date: Fri, 18 Jan 2013 15:22:00 -0500

Jim Schaad wrote:
> Some additional comments to be considered
> 
> 1.  I like the addition of the term "local" in section 1.1.  I wonder if the
> following text should be added
> 
> "AAA entities not under the control of the client that "know" the locale may
> have a different concept of that information than the client's locale."

  Sounds good to me.  That sounds a little convoluted to me.  I'll
rephrase it as:

The client which "knows" the locale may have a different concept of
this text than other AAA entities, which do not know the locale.

> 2.  In a follow up to my last set of comments:  Does the working group feel
> there is any need to remove the restriction that there be at least one dot
> in a utf8-realm.  Given the possibility of new top level domains being
> issued such as "Walmart", what are the odds that those people are going to
> want to be able to use a NAI of the form joe@walmart for an NAI?

  My $0.02 is that allowing top-level domains as the NAI is problematic,
and not in line with historical practice.

  But... I can see people asking for it.

> 3.  In section 2.8, if one is expected to use the utf8-realm with a
> byte-for-byte comparison, then one needs to specify a canonicalization of
> those sub-sections of the utf8-realm that are equivalent to A-labels.

  I am very wary of suggesting that.  The goal for the NAI is to be
agnostic as to A-label or U-label.  Those terms refer to DNS, and the
utf8-realm is defined independently of DNS.

>  That
> is "example.com" and "EXAMPLE.COM" should be routed to the same location
> because they are using A-Labels in the utf8-realm while "exαmple.com" and
> "EXΑMPLE.COM" (A and uppercase α have the same glyph) are not routed to the
> same location because they are using U-Labels in the utf8-realm.

  That is a good point, and one which should be clarified in the document.

  But my take is that "example.com" and "EXAMPLE.COM" should be treated
differently.  i.e. intermediate nodes don't know locale, and cannot do
canonicalization.  We might as well go with that everywhere, rather than
trying to make exceptions for ASCII.

> 4.  In section 2.10, my understanding of the DNS terminology is different
> than what is presented here.  In order for it to be a U-Label, the label
> must have a non-ASCII character.  If the section consists only of ASCII
> characters then it is an A-Label.  This means that the text in the first
> paragraph is incorrect when saying the utf8-realm is not composed of
> A-labels.

  Well.. the utf8-realm can be entirely U-labels, and does not need to
be A-labels.

>  I believe that the correct sentence would be "As defined above,
> the "utf8-realm" portion as transported within the RADIUS User-Name
> attribute can be composed of both U-labels and A-labels."

  It might be simpler just to say that the NAI is 8-bit clean, and
therefore avoids the U-label and A-label distinction.

  How about this:

The "utf8-realm" portion of the NAI is intended to be compatible with
Internationalized Domain Names [RFC5890].  As defined above, the
"utf8-realm" portion as transported within the RADIUS User-Name
attribute can transport any valid UTF8 character.  There is therefore
no reason for a NAS to apply the ToAscii function to the "utf8-realm"
portion of an NAI, prior to placing the NAI into a RADIUS User-Name
attribute.  Unlike DNS, the NAI does not make a distinction between
A-labels and U-labels.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 18 Jan 2013 13:09:48 -0800

> and not in line with historical practice.

[BA] I agree.  RFC 1536 is very clear that a single label has a locally defined meaning. 

That is, "walmart" in joe@walmart may be resolved via a search algorithm 
(e.g. looking up walmart.example.com) or via a different name resolution
protocol.  

Therefore including this would be dangerous.
 
> utf8-realm is defined independently of DNS.

[BA] Currently the document suffers from a lack of clarity that I believe was part of the reason for the RFC 4282 debacle. 

The "NAI" can have different representations depending on context.  RFC 4282 seemed to suffer from the delusion that there is a single unique encoding of the NAI that is valid in every protocol or circumstance.   This document needs to dispense with that misguided notion early on, and make it very clear what the ABNF applies to, exactly.

For example, an NAI realm contained in the RADIUS User-Name Attribute will have one representation (canonicalized U-labels on the wire) and an NAI realm as used to look up DNS RRs in RADIUS Dynamic Discovery will have another representation (e.g. A-labels).  It also will matter if a protocol is 8-bit clean (like EAP and RADIUS) or requires escaping (SIP or HTTP). 

> trying to make exceptions for ASCII.

[BA] The RADIUS Dynamic Discovery document seems to assert that in practice intermediate nodes MAY need to do some canonicalization.  I would like to understand the experience that lies behind that assertion a bit better.  For example, it is one thing to be referring to authentication mechanisms that are either only used locally or within EAP tunnel methods (e.g. MS-CHAP), it is another to be referring to widely deployed implementations that won't comply with the recommendations in this document.  For example, as far as I know, no existing EAP implementation applies NFC to the NAI prior to enclosing it in the EAP-Response/Identity.  As a result, it is not realistic to expect the User-Name to be canonicalized upon entering the AAA system, unless we are going to require the NAS to do the canonicalization (and have some expectation it will actually happen). 

> therefore avoids the U-label and A-label distinction.

[BA] Stating that the "NAI is 8-bit clean" is very confusing, because the NAI realm may be encoded with U-labels or A-labels depending on circumstance.  However, one can talk about "the representation of the NAI within an 8-bit clean protocol".    Let's make sure we do not repeat the mistakes of RFC 4282.  

> attribute.  Unlike DNS, the NAI does not make a distinction between

I think the above is still suffering from "RFC4282 disease":  confusion between the NAI and its representation within given protocols.  How about this?

> "utf8-realm" portion as transported within an 8-bit clean protocol
> such as RADIUS and EAP can contain any valid UTF8 character.  
>There is therefore no reason for a NAS to apply the ToAscii function to the "utf8-realm"
> attribute.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 18 Jan 2013 15:29:12 -0800

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]]
> Sent: Friday, January 18, 2013 12:22 PM
> To: Jim Schaad
> Cc: [email-masked]; [email-masked]
> Subject: Re: Comments on draft-ietf-radext-nai-01
> 
> Jim Schaad wrote:
> > 1.  I like the addition of the term "local" in section 1.1.  I wonder
> > if the following text should be added
> >
> > "AAA entities not under the control of the client that "know" the
> > locale may have a different concept of that information than the client's
> locale."
> 
>   Sounds good to me.  That sounds a little convoluted to me.  I'll rephrase it
> as:
> 
> The client which "knows" the locale may have a different concept of this text
> than other AAA entities, which do not know the locale.

Doesn't quite have the same meaning.  But yes it is better than what I wrote.  Perhaps add  

which do not "know" the same locale.

> 
> > 2.  In a follow up to my last set of comments:  Does the working group
> > feel there is any need to remove the restriction that there be at
> > least one dot in a utf8-realm.  Given the possibility of new top level
> > domains being issued such as "Walmart", what are the odds that those
> > people are going to want to be able to use a NAI of the form joe@walmart
> for an NAI?
> 
>   My $0.02 is that allowing top-level domains as the NAI is problematic, and
> not in line with historical practice.
> 
> > byte-for-byte comparison, then one needs to specify a canonicalization
> > of those sub-sections of the utf8-realm that are equivalent to A-labels.
> 
>   I am very wary of suggesting that.  The goal for the NAI is to be agnostic as
> to A-label or U-label.  Those terms refer to DNS, and the utf8-realm is
> defined independently of DNS.
> 
> >  That
> > is "example.com" and "EXAMPLE.COM" should be routed to the same
> > location because they are using A-Labels in the utf8-realm while
> > "example.com" and "EX?MPLE.COM" (A and uppercase a have the same
> > glyph) are not routed to the same location because they are using U-Labels
> in the utf8-realm.

Somewhere my Greek alphas seem to have gotten lost.
> trying to make exceptions for ASCII.

I am worried about this for two reasons, first I don't believe that it will conform to current practice.  I think that currently proxies would route based on a DNS version of the name - which would be agnostic relative to case.  Second, you are now having a major difference with e-mail addresses which will case-fold A-labels when doing MX record lookups and thus the  EXAMPLE.com and example.com are going to be the same.

You should have a better idea on the first worry, the second one needs to be documented if we are sticking with this.

> 
> > 4.  In section 2.10, my understanding of the DNS terminology is
> > different than what is presented here.  In order for it to be a
> > U-Label, the label must have a non-ASCII character.  If the section
> > consists only of ASCII characters then it is an A-Label.  This means
> > that the text in the first paragraph is incorrect when saying the
> > utf8-realm is not composed of A-labels.
> 
>   Well.. the utf8-realm can be entirely U-labels, and does not need to be A-
> labels.
> 
> >  I believe that the correct sentence would be "As defined above, the
>   It might be simpler just to say that the NAI is 8-bit clean, and therefore
> avoids the U-label and A-label distinction.
> 
>   How about this:
> 
> 
> Internationalized Domain Names [RFC5890].  As defined above, the "utf8-
> realm" portion as transported within the RADIUS User-Name attribute can
> transport any valid UTF8 character.  There is therefore no reason for a NAS to
> apply the ToAscii function to the "utf8-realm"
> attribute.  Unlike DNS, the NAI does not make a distinction between A-labels
> and U-labels.
> 
>   Alan DeKok.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 18 Jan 2013 15:42:27 -0800

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Friday, January 18, 2013 1:10 PM
To: Alan DeKok; Jim Schaad
Cc: [email-masked]; [email-masked]
Subject: RE: [radext] Comments on draft-ietf-radext-nai-01

> > 2. In a follow up to my last set of comments: Does the working group
feel
> and not in line with historical practice.

[BA] I agree.  RFC 1536 is very clear that a single label has a locally
defined meaning. 

[JLS] If we are saying this, then are we also saying that we never expect
joe@walmart to become a valid e-mail address as well.  With the advent of
issuing new TLDs it is quite possible that RFC 1536 needs to be updated to
reflect the new reality.
 
> > byte-for-byte comparison, then one needs to specify a canonicalization
of
> utf8-realm is defined independently of DNS.

[BA] Currently the document suffers from a lack of clarity that I believe
was part of the reason for the RFC 4282 debacle. 

The "NAI" can have different representations depending on context.  RFC 4282
seemed to suffer from the delusion that there is a single unique encoding of
the NAI that is valid in every protocol or circumstance.   This document
needs to dispense with that misguided notion early on, and make it very
clear what the ABNF applies to, exactly.

For example, an NAI realm contained in the RADIUS User-Name Attribute will
have one representation (canonicalized U-labels on the wire) and an NAI
realm as used to look up DNS RRs in RADIUS Dynamic Discovery will have
another representation (e.g. A-labels).  It also will matter if a protocol
is 8-bit clean (like EAP and RADIUS) or requires escaping (SIP or HTTP). 

[JLS]  Again - the language of canonicalized U-Label is incorrect.   Quoting
from  RFC 5890

A "U-label" is an IDNA-valid string of Unicode characters, in

      Normalization Form C (NFC) and including at least one non-ASCII

      character,

A more correct term is going to be it is an "IDNA-valid" label. (Also from
RFC 5890).

> trying to make exceptions for ASCII.

[BA] The RADIUS Dynamic Discovery document seems to assert that in practice
intermediate nodes MAY need to do some canonicalization.  I would like to
understand the experience that lies behind that assertion a bit better.  For
example, it is one thing to be referring to authentication mechanisms that
are either only used locally or within EAP tunnel methods (e.g. MS-CHAP), it
is another to be referring to widely deployed implementations that won't
comply with the recommendations in this document.  For example, as far as I
know, no existing EAP implementation applies NFC to the NAI prior to
enclosing it in the EAP-Response/Identity.  As a result, it is not realistic
to expect the User-Name to be canonicalized upon entering the AAA system,
unless we are going to require the NAS to do the canonicalization (and have
some expectation it will actually happen). 

[JLS] But even having the NAS do it may lead to problems.  My client and the
NAS might have different ideas of what the locale is and thus would
canonicalize it differently.  I think that this MUST be pushed onto the
clients and not the NAS in order to get it to work correctly.  

> therefore avoids the U-label and A-label distinction.

[BA] Stating that the "NAI is 8-bit clean" is very confusing, because the
NAI realm may be encoded with U-labels or A-labels depending on
circumstance.  However, one can talk about "the representation of the NAI
within an 8-bit clean protocol".    Let's make sure we do not repeat the
mistakes of RFC 4282.  

Say that the utf8-real is IDNA-valid avoids the U-label/A-label distinction
while making it clear that it is an 8-bit label.

> attribute. Unlike DNS, the NAI does not make a distinction between

I think the above is still suffering from "RFC4282 disease":  confusion
between the NAI and its representation within given protocols.  How about
this?

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 18 Jan 2013 16:01:47 -0800

[JLS] If we are saying this, then are we also saying that we never expect joe@walmart to become a valid e-mail address as well.  With the advent of issuing new TLDs it is quite possible that RFC 1536 needs to be updated to reflect the new reality.
[BA] As I understand it, ICANN is looking at drafting guidelines that would prohibit hosting of A/AAAA, SRV, etc. RRs in TLDs, so there is no need to go there. 
 \[JLS]  Again – the language of canonicalized U-Label is incorrect.   Quoting from  RFC 5890A "U-label" is an IDNA-valid string of Unicode characters, in      Normalization Form C (NFC) and including at least one non-ASCII      character, A more correct term is going to be it is an “IDNA-valid” label. (Also from RFC 5890).
[BA] OK.  The question remains whether an NAI realm received from an 8-bit clean client (e.g. an EAP supplicant) will necessarily contains "IDNA-valid" labels.  The RADIUS Dynamic Discovery document says "no" -- and AFAIK, no existing EAP implementations utilize NFC, so that is correct.  [JLS] But even having the NAS do it may lead to problems.  My client and the NAS might have different ideas of what the locale is and thus would canonicalize it differently.  I think that this MUST be pushed onto the clients and not the NAS in order to get it to work correctly.  

[BA] Assuming that the client converts the NAI to UTF-8 before sending it, does this problem really exist?  The NFC algorithm does not require knowledge of the locale, right? 

Say that the utf8-real is IDNA-valid avoids the U-label/A-label distinction while making it clear that it is an 8-bit label.
[BA] The problem that the NAI realm output by the client may not be IDNA-valid, even if it is in UTF-8, and adding "MUST" to this document won't make it so.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 18 Jan 2013 16:20:12 -0800

I am unsure that NFC is locale agnostic or not.  For some reason in the back
of my head there is a note that says it is not, but I don't have a reference
for this note at the current time. 

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Friday, January 18, 2013 4:02 PM
To: Jim Schaad; Alan DeKok
Cc: [email-masked]; [email-masked]
Subject: RE: [radext] Comments on draft-ietf-radext-nai-01

[BA] As I understand it, ICANN is looking at drafting guidelines that would
prohibit hosting of A/AAAA, SRV, etc. RRs in TLDs, so there is no need to go
there. 

 \

      character,

[BA] OK.  The question remains whether an NAI realm received from an 8-bit
clean client (e.g. an EAP supplicant) will necessarily contains "IDNA-valid"
labels.  The RADIUS Dynamic Discovery document says "no" -- and AFAIK, no
existing EAP implementations utilize NFC, so that is correct. 

[BA] Assuming that the client converts the NAI to UTF-8 before sending it,
does this problem really exist?  The NFC algorithm does not require
knowledge of the locale, right? 

[BA] The problem that the NAI realm output by the client may not be
IDNA-valid, even if it is in UTF-8, and adding "MUST" to this document won't
make it so.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 19 Jan 2013 09:51:58 -0500

> Therefore including this would be dangerous.

  Good point.  I'll add a note to that effect.

> The "NAI" can have different representations depending on context.  RFC
> 4282 seemed to suffer from the delusion that there is a single unique
> encoding of the NAI that is valid in every protocol or circumstance.  
> This document needs to dispense with that misguided notion early on, and
> make it very clear what the ABNF applies to, exactly.

  Yes.  The NAI is defined independently of any protocol.

> For example, an NAI realm contained in the RADIUS User-Name Attribute
> will have one representation (canonicalized U-labels on the wire) and an
> NAI realm as used to look up DNS RRs in RADIUS Dynamic Discovery will
> have another representation (e.g. A-labels).  It also will matter if a
> protocol is 8-bit clean (like EAP and RADIUS) or requires escaping (SIP
> or HTTP).

  The document contains a new section: Compatibility with other
protocols.  That section discusses the *transport* of the NAI within
other protocols.  The transported version must follow the requirements
of the other protocols.  e.g. "." --> %2E.  The resulting string is
*not* the NAI.

  Something similar should be said early in the document, too.

> [BA] The RADIUS Dynamic Discovery document seems to assert that in
> practice intermediate nodes MAY need to do some canonicalization.  I
> would like to understand the experience that lies behind that assertion
> a bit better.  For example, it is one thing to be referring to
> authentication mechanisms that are either only used locally or within
> EAP tunnel methods (e.g. MS-CHAP), it is another to be referring to
> widely deployed implementations that won't comply with the
> recommendations in this document.  For example, as far as I know, no
> existing EAP implementation applies NFC to the NAI prior to enclosing it
> in the EAP-Response/Identity.  As a result, it is not realistic to
> expect the User-Name to be canonicalized upon entering the AAA system,
> unless we are going to require the NAS to do the canonicalization (and
> have some expectation it will actually happen).

  I don't think that will happen.  But I *would* encourage the
canonicalization of the identity prior to it entering the AAA system.

  I've discussed the issue with implementors of EAP supplicants.  Their
consensus is largely to avoid the issue.  They want to treat the
identity as an opaque token that they are given.  They may not have
access to locale information in order to normalize it.

> [BA] Stating that the "NAI is 8-bit clean" is very confusing, because
> the NAI realm may be encoded with U-labels or A-labels depending on
> circumstance.  However, one can talk about "the representation of the
> NAI within an 8-bit clean protocol".    Let's make sure we do not repeat
> the mistakes of RFC 4282. 

  Text:

Where a protocol is 8-bit clean, it can likely transport the NAI
as-is, without further modification.

Where a protocol is not 8-bit clean, it MUST NOT affect the definition
or handling of the NAI.  That is, if a protocol escapes the '.'
character as "%2E", then the protocol may have an identifier
transported as "fred@example%2Ecom", whereas the NAI for that user is
"[email-masked]".  Any comparison, validation, or use of the NAI
MUST be done on its un-escaped (i.e. utf8-clean) form.

> between the NAI and its representation within given protocols.  How
> about this?
> 

  Looks good to me.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 19 Jan 2013 10:00:20 -0500

> which do not "know" the same locale.

  Done.

> Somewhere my Greek alphas seem to have gotten lost.

  Yes... highlighting the problem of i18n.

>> [ re: example.com != EXAMPLE.COM ]
>
> I am worried about this for two reasons, first I don't believe that it will conform to current practice.

  Some systems do case insensitive matching.  Others don't.  Some
explicitly reject wrong-case logins.

>  I think that currently proxies would route based on a DNS version of the name - which would be agnostic relative to case. 

  Yes, but (to be pedantic), that's a DNS problem.

	DNS (example.com) = X
	DNS (EXAMPLE.COM) = Y

  Maybe X==Y.  That's nice, but it's really an issue for the realm.

  I see this distinction as causing problems.  (i.e. I've seen similar
distinctions cause issues in other contexts).  To be very clear:

  The NAI is *input* to DNS.  The *output* of DNS may be the same, even
if a "bit compare" of input NAIs is different.  That *output* has no
bearing on the NAI.  It doesn't mean you can say comparisons of the NAI
are "case insensitive".

> Second, you are now having a major difference with e-mail addresses which will case-fold A-labels when doing MX record lookups and thus the  EXAMPLE.com and example.com are going to be the same.

  That's again a DNS issue.  The output of DNS doesn't affect the
definition of the NAI.  And email already allows for folding and
non-folding whitespace, which isn't allowed in the NAI.

> You should have a better idea on the first worry, the second one needs to be documented if we are sticking with this.

  It should be clarified, yes.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 19 Jan 2013 10:18:25 -0500

Bernard Aboba wrote:
> [BA] OK.  The question remains whether an NAI realm received from an
> 8-bit clean client (e.g. an EAP supplicant) will necessarily contains
> "IDNA-valid" labels.  The RADIUS Dynamic Discovery document says "no" --
> and AFAIK, no existing EAP implementations utilize NFC, so that is correct.

  The question now is: what do we want?  Do we want the NAI to have a
normal form?  Your previous messages indicated "yes".

> [BA] Assuming that the client converts the NAI to UTF-8 before sending
> it, does this problem really exist?  The NFC algorithm does not require

  I believe so.

> IDNA-valid, even if it is in UTF-8, and adding "MUST" to this document
> won't make it so.

  The current document says that NFC is RECOMMENDED.  It also says that

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

  Which also means it's an IDNA-valid label, containing U-labels in NFC.

  My $0.02 is that normalization should be done at the edges of the
network, where possible.  That means either the EAP supplicant, or the
system which feeds the identity into the EAP-supplicant.

  Doing it elsewhere is a nightmare.  Many authentication protocols
depend on cryptographic manipulation of the identity.  So AAA systems
would now have to track *two* identities.  The normalized form, and the
form as entered by the user.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 20 Jan 2013 13:39:07 -0500

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> Bernard Aboba wrote:
    >> [BA] OK.  The question remains whether an NAI realm received from
    >> an 8-bit clean client (e.g. an EAP supplicant) will necessarily
    >> contains "IDNA-valid" labels.  The RADIUS Dynamic Discovery
    >> document says "no" -- and AFAIK, no existing EAP implementations
    >> utilize NFC, so that is correct.

    Alan>   The question now is: what do we want?  Do we want the NAI to
    Alan> have a normal form?  Your previous messages indicated "yes".

We want people who are interpreting the NAI to do
normalization-insensitive and to the extent we can get it
input-method-insensitive operations on them.

One crue way to do that is to normalize the NAI. If you're going to look
something up in a database  that is just going to do an exact-match
search (DNS is a great example) then normalizing the NAI is the best you
can do.
DNS illustrates that the specific normalization/canonicalization is
often database specific.

However, if you have more control over the database, you probably just
want a normalization-insensitive search. Think of this is the 00's
version of case-insensitive comparison.

This tends to be an area where a lot of SHOULD language is appropriate
and no MUST language is appropriate.
Things like  the result SHOULD be the same regardless of what
normalization form the client submits.
Servers SHOULD perform comparisons that are insensitive to Unicode
normalization forms.

Also, note this is an area where advice will change over time and where
we'll get more requirements in the future.  Fortunately in what I've
said above the requirements are all on entities interpreting the NAI
(proxies making routing decisions; servers looking up users; etc), so
only one party needs to implement new requirements in order to provide
an enhanced e xperience.

The tricky bit comes in when hashes are involved.
Fortunately that seems rare with NAIs although not so rare
withmethod-specific  EAP
identities which may be related  to NAIs.
I think we can mostly avoid it in this document though.

--Sam

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 20 Jan 2013 11:20:58 -0800

[JLS]  So I just went and read the RADIUS Dynamic Discover document.  I
don't know that it says that the NAI realm will or will not be "IDNA-valid"
.  However, I believe that it really says what you get here may or may not
be an NAI at all.  It allows for, among other things,  multiple '@'
characters to be placed in the user name.  However, in the long run, caveat
what it says about local consortium mangling of names, it does expect that
it is an IDNA-valid realm that it will be able to do a DNS query with.
Indeed in section 2.3.1 it says that if you can't do the mapping, then you
get an error condition for the lookup..