Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt

From: Stefan Winter <[email-masked]>
Date: Mon, 18 Mar 2013 14:31:27 +0100

Hi,

I have one comment about section 2.8 of the document.

Imagine
* an end-user device which produces valid UTF-8 NAIs; they are not in
NFC form though; in particular, the realm portion is interspersed with
U+FEFF characters ("zero-width, non-breaking space", i.e "nothing").
* his EAP server knows about this "strange" representation of the
identity and configures the corresponding byte sequence as a realm he is
willing to authenticate (i.e. terminate EAP for)

As per the draft, this will work nicely; both ends of EAP know each
other's representation of the username, and act accordingly.

In a AAA routing scenario as described in 2.8, forwarding of the
authentication will break unless all intermediate proxies are /also/
provided with the knowledge that this one realm can have the
non-normalised appearance in question.

This requires either signalling of numerous representations of the same
realm throughout all concerned proxies (which doesn't scale well), or
will lead to a "sorry, use a more sane representation" DoS.

I find both alternatives rather unfortunate.

How about the following tweak to the routing decision algorithm in 2.8:

Old text:

"Intermediate nodes MUST use the "utf8-realm" portion of the NAI
   without modification to perform this lookup.  Comparisons between the
   NAI as given in a AAA packet, and as provisioned in a logical AAA
   routing table SHOULD be done as a byte-for-byte equality test."

New text:

"Intermediate nodes MUST use the "utf8-realm" portion of the NAI
   to perform this lookup.  Comparisons between the NAI as given in a
   AAA packet, and as provisioned in a logical AAA routing table SHOULD
   be done as a byte-for-byte equality test of the normalized form (NFC)
   of the NAI and the normalized form (NFC) of the entry in the AAA
   routing table."

Note that this does not manipulate the realm representation in the
packet; it merely changes the logical handling of realms in proxies.

Greetings,

Stefan Winter

On 28.01.2013 16:50, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the RADIUS EXTensions Working Group of the IETF.
> 
> 	Title           : The Network Access Identifier
> 	Author(s)       : Alan DeKok
> 	Filename        : draft-ietf-radext-nai-02.txt
> 	Pages           : 22
> 	Date            : 2013-01-28
> 
> Abstract:
>    In order to provide inter-domain authentication services, it is
>    necessary to have a standardized method that domains can use to
>    identify each others users.  This document defines the syntax for the
>    Network Access Identifier (NAI), the user identity submitted by the
>    client prior to accessing network resources. This document is a
>    revised version of RFC 4282 [RFC4282], which addresses issues with
>    international character sets, as well as a number of other
>    corrections to the previous document.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-radext-nai
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-radext-nai-02
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-02
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
> 

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Mar 2013 09:46:32 -0400

New text:

"Intermediate nodes MUST use the "utf8-realm" portion of the NAI
   to perform this lookup.  Comparisons between the NAI as given in a
   AAA packet, and as provisioned in a logical AAA routing table SHOULD
   be doneusing a normalization-insensitive comparison function."

Rationale: consistent with what the filesystem community and other parts
of the apps community (especially outside the IETF) are doing.  One
obvious normalization-insensitive comparison function is what you
propose: normalize both sides.  However, the important thing in terms of
implementing this is to be normalization insensitive. We want to
encourage people to call into their unicode library, not roll their own.

--Sam

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 Mar 2013 09:29:48 -0700

I would not support this change.

I would suggest that in this case that the AAA client should be the one that
does the required normalization or mapping into the normal form as part of
its "I know where this is supposed to be going" work.

I don't see any reason to impose this onto the middle proxies rather than
the injecting system.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stefan Winter
> Sent: Monday, March 18, 2013 6:31 AM
> To: [email-masked]
> Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt
> 
> Hi,
> 
> * an end-user device which produces valid UTF-8 NAIs; they are not in NFC
> form though; in particular, the realm portion is interspersed with
> * his EAP server knows about this "strange" representation of the identity
> and configures the corresponding byte sequence as a realm he is willing to
> authenticate (i.e. terminate EAP for)
> 
other's
> representation of the username, and act accordingly.
> 
provided
> with the knowledge that this one realm can have the non-normalised
> appearance in question.
> 
> realm throughout all concerned proxies (which doesn't scale well), or will
> lead to a "sorry, use a more sane representation" DoS.
> 
> Note that this does not manipulate the realm representation in the packet;
it
> merely changes the logical handling of realms in proxies.
> 
> Greetings,
> 
> Stefan Winter
> 
> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de
> la Recherche 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
> 
> Tel: +352 424409 1
> Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Mar 2013 13:21:39 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> I would not support this change.  I would suggest that in this
    Jim> case that the AAA client should be the one that does the
    Jim> required normalization or mapping into the normal form as part
    Jim> of its "I know where this is supposed to be going" work.

    Jim> I don't see any reason to impose this onto the middle proxies
    Jim> rather than the injecting system.

We have a lot of experience in the i18n space that suggests you're much
better off normalizing as late as possible.  When you normalize at
injection you can lose information and collapse things together that a
later party may wish you had not.  The person using the information is
in a much better position to know what options they need to distinguish
between and thus is in a better position to know what normalization is
appropriate.

The major exceptions to this rule are when you're forced to normalize
before hashing/encrypting or when you have a legacy system like the DNS.

--Sam

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 Mar 2013 11:57:12 -0700

Sam,

In the descriptive text that Stefan provided, he said that the AAA client
was configured with the fact that the names were the same.  Thus there is no
reason for it not to do the mapping on that information rather than
normalization.

If we are talking about delaying the normalization, then we are looking at
what the AAA client as oppose to the AAA server is looking for in the
un-normalized name.   AAA proxies are always going to want to see the
normalized version of the name.  

There may be other issues in non-AAA systems, but again we are looking at
three different entities, the initial client, any proxies in the middle and
the final destination server.  We are imposing work on the middle proxies in
order to get something that is not necessarily a strong benefit for the
final server.

Jim

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Monday, March 18, 2013 10:22 AM
> To: Jim Schaad
> Cc: 'Stefan Winter'; [email-masked]
injection
> you can lose information and collapse things together that a later party
may
> wish you had not.  The person using the information is in a much better
> position to know what options they need to distinguish between and thus is
in
> a better position to know what normalization is appropriate.
> 
before
> hashing/encrypting or when you have a legacy system like the DNS.
> 
> --Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Mar 2013 15:17:58 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> Sam, In the descriptive text that Stefan provided, he said that
    Jim> the AAA client was configured with the fact that the names were
    Jim> the same.  Thus there is no reason for it not to do the mapping
    Jim> on that information rather than normalization.

    Jim> If we are talking about delaying the normalization, then we are
    Jim> looking at what the AAA client as oppose to the AAA server is
    Jim> looking for in the un-normalized name.  AAA proxies are always
    Jim> going to want to see the normalized version of the name.

Yeah, I agree his example is not the best.  However, I suspect that both
aaa-servers and aaa-proxies will perform better if given the
un-normalized name.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Mar 2013 15:34:04 -0400

I agree with Jim here.

  As I write RADIUS servers instead of supplicants, I think the
normalization work should be pushed off onto supplicants.

  The document already says that realm names MUST be registrable as
names within DNS.  DNS requires NFC.  Therefore, realms are NFC.  Any
supplicant injecting non-NFC names is wrong.

  re: Sam's comments on i18n space, I'm not sure it's relevant to have
the home server normalize the realm name.  I'm curious to know what
information is in the non-NFC form which is needed by the home server.

  The home server knows who it's users are, and can just use names,
without a realm portion.  If it gets a realm, it verifies that it owns
the realm, but that verification is largely site-specific.  e.g.
EXAMPLE\foo versus [email-masked].

  So the main use for realms is proxies.  They don't care about the
*content* of the realm.  They just want to use it as an opaque token.
Realm A goes to RADIUS server for Realm A, etc.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 19 Mar 2013 08:52:11 +0100

Hi,

> supplicant injecting non-NFC names is wrong.

Not quite. Section 2.1 states:

See [RFC5198] for a discussion of normalization; the use of Normal
   Form Composed (NFC) is RECOMMENDED.

RECOMMENDED means that some ill-thinking supplicant implementers might
decide that they don't have to pay attention to normalisation.

If this statement were a MUST; plus a discussion what to do if an
incoming string is not in NFC (discard?) would make the whole thing a
lot more deterministic.

> information is in the non-NFC form which is needed by the home server.

It may be that the home server does not "need" the non-normalised junk
:-) It may just be that a supplicant thinks it's wise to send it; and
since the contents of the attribute can't be altered in-flight, this
junk will stay in the packet until it arrives at the home server.

My argument was that it may not even reach the home server if proxies
aren't allowed to do some sort of "sane" lookup of the packet content
vs. their local configuration.

> EXAMPLE\foo versus [email-masked].

That verification may ultimately require normalisation by the home
server. It's true that this is site-specific; but in the presence of
proxies the problematic bit is to reach that home site in the first place.

> Realm A goes to RADIUS server for Realm A, etc.

My issue is: does realm A', which is extremely similar to A in that it
differs only in string representation, also go to server A? Or is it
discarded by the proxy due to being unknown (i.e. not byte-wise equal to
the configured realm A)? Or sent to a "last resort"? If NFC(A') = A, and
if that is looked up in the routing table, a lot good is done in terms
of forwardability, IMHO.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Mar 2013 09:31:12 -0400

>    Form Composed (NFC) is RECOMMENDED.

  Yes.  Keep reading.  It also says that realm names MUST be registrable
as names within DNS.  Which (eventually) means NFC.

  The text you quote is left over from an earlier version of the draft,
before I worked through the DNS documents.  It will be updated in the
next rev.

> incoming string is not in NFC (discard?) would make the whole thing a

  I vote a "hell no" to discarding packets with malformed NAI.

  For me, a malformed NAI only means that it's not an NAI.  EXAMPLE\user
 is a perfectly valid RADIUS User-Name.  It should *not* be forbidden by
the NAI document.

> junk will stay in the packet until it arrives at the home server.

  That's not what I got from his message, but OK.

> vs. their local configuration.

  They are allowed.  They do this today.  Proxy routing can be done on
EXAMPLE\user.

  The point of the NAI draft is to (a) fix RFC 4282, (b) define the NAI
correctly, and (c) encourage people to use it instead of broken
alternatives.

  There are no plans for a RADIUS police force who will shut down
non-complaint implementations.  They just won't get the benefit of
standardization.

> proxies the problematic bit is to reach that home site in the first place.

  That's blaming the messenger.

  The problem is really the supplicants that inject multiple versions of
the same domain.

> if that is looked up in the routing table, a lot good is done in terms

  I'm OK with proxies doing deeper inspection or normalization of the
NAI.  I'm against the *requirement* that they do this.  RFC 4282
requires it.  Requiring non-NFS from the supplicants means that proxies
are required to massage the NAI before they use it.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 19 Mar 2013 16:20:15 +0100

Hi,

> before I worked through the DNS documents.  It will be updated in the

Okay.

>  is a perfectly valid RADIUS User-Name.  It should *not* be forbidden by

Then I'd suggest making this very explicit. E.g. replace the previous
sentence with

"See [RFC5198] and section 2.6 of this specification for a discussion of
normalization. Strings which are not in Normal Form Composed (NFC) are
not valid NAIs and SHOULD NOT be treated as such."

>   That's not what I got from his message, but OK.

You mean my initial mail with the hypothetical example? Well it was
about that; I had the assumption in my mind that these multiple
representations of the realm are imposed by stubborn supplicants; so if
a server wants to authenticate users using this supplicant, it has to
negotiate that this is a recognised representation of the string and add
it to its server-side config. Not the other way around; sorry if that
was unclear.

I don't think servers are the main problem when it comes to
normalisation (or just valid UTF-8 in the first place). I have much more
concerns about ignorant supplicants.

> non-complaint implementations.  They just won't get the benefit of

Okay; well it's already good that NAI => NFC is indeed hard-wired into
the spec.

>   The problem is really the supplicants that inject multiple versions of

With the multitude of end-user computing devices in the wild, and the
varying amounts of care firmware writers spend into their supplicant
code, I'm sure there'll be a whole zoo of representations of
internationalised domain names on the supplicant side :-(

> NAI.  I'm against the *requirement* that they do this.

Well if it's a NAI it does not need to be noramlised any more :-)

Would it be okay to *RECOMMEND* that UTF-8 which is not in NFC should be
normalised prior to "doing something" in terms of lookup in the config?

Greetings,

Stefan Winter

>  RFC 4282

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Mar 2013 13:57:15 -0400

> not valid NAIs and SHOULD NOT be treated as such."

  Looks good to me.

> concerns about ignorant supplicants.

  I agree.  It would be nice to support feedback in one of the EAP
methods (e.g. TEAP).  A server could say "Thanks for using DOMAIN', but
next time please use DOMAIN".

> internationalised domain names on the supplicant side :-(

  Yes.  Which is why I'd like to get the NAI document published.  RFC
4282 is distressingly broken.  Being able to point to a *good* document
would be useful.

> normalised prior to "doing something" in terms of lookup in the config?

  Yes.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Wed, 20 Mar 2013 09:32:41 +0100

Hi,

>> normalised prior to "doing something" in terms of lookup in the config?

Great. I think an extra sentence in addition to the above should make
this fit nicely:

"See [RFC5198] and section 2.6 of this specification for a discussion of
 normalization. Strings which are not in Normal Form Composed (NFC) are
 not valid NAIs and SHOULD NOT be treated as such.

 Implementations which expect to receive a NAI, but get non-normalised
 (but otherwise valid) UTF-8 strings instead SHOULD attempt to normalise
 the input to NFC for local processing."

?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Emile van Bergen <[email-masked]>
Date: Wed, 20 Mar 2013 09:40:53 +0100

Hi,

>  the input to NFC for local processing."

I read these as two slightly conflicting clauses, both written from the
receiver's viewpoint. 

I've often found the way that IETF documents dissect 'validity' into
separate requirements for senders and receivers. How about:

 "See [RFC5198] and section 2.6 of this specification for a discussion of
  normalization. Strings which are not in Normal Form Composed (NFC) are
  not valid NAIs and MUST NOT be sent by compliant implementations.

Following Jon Postel's "be conservative in what you send, be liberal in
what you accept"?

Kind regards,

Emile van Bergen.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 20 Mar 2013 09:00:14 -0400

>   the input to NFC for local processing."

  That text is ambiguous about whether or not you re-write the NAI in
the packet.  People will read it incorrectly.  How about this:

  Implementations which expect to receive a NAI, but get non-normalised
  (but otherwise valid) UTF-8 strings instead SHOULD attempt to create a
  local version of the NAI, which is normalized from the input
  identifier.  This local version can then be used for local processing.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Wed, 20 Mar 2013 14:07:40 +0100

Hi,

>   identifier.  This local version can then be used for local processing.

Sounds good to me.

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Mar 2013 09:12:08 -0400

With regard to the i18n issues, having asked others to look at it, I'm
withdrawing my objection.  I simply don't have time to be a driving
force behind confirming that my concerns are real and going through a
joint education process here as I learn Alan's side and try and explain
my concerns.  If people from the apps area look at the document and
choose to raise their own concerns, that's fine. However I want to make
it clear to the chairs and WG that in terms of judging consensus on the
document I'm not objecting.

--Sam