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

Hi,

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

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.

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

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.

>   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 foo@example.com.

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.

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

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

> 
>   Alan DeKok.
> _______________________________________________
> radext mailing list
> radext@ietf.org
> 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

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

Attachment: signature.asc