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

[Stefan Winter <[e-mail]>]

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, [e-mail] 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
> [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]