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

[Alan DeKok <[e-mail]>]

Stefan Winter wrote:
>>   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.
> 
> Not quite. Section 2.1 states:
> 
> See [RFC5198] for a discussion of normalization; the use of Normal
>    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.

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

  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.

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

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

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

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