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

[Stefan Winter <[e-mail]>]

Hi,

>   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.

Okay.

>   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.

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."


>> 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.
> 
>   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.

>> 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.
> 
>   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.

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

>> 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.
> 
>   That's blaming the messenger.
> 
>   The problem is really the supplicants that inject multiple versions of
> the same domain.

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 :-(

>> 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.
> 
>   I'm OK with proxies doing deeper inspection or normalization of the
> 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
> requires it.  Requiring non-NFS from the supplicants means that proxies
> are required to massage the NAI before they use it.
> 
>   Alan DeKok.
> _______________________________________________
> radext mailing list
> [e-mail]
> 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: [phone]
Fax: [phone]