Re: [radext] Review of draft-ietf-radext-nai-03

[Bernard Aboba <[e-mail]>]

> Bernard Aboba wrote:
> > For example, the document recognizes that existing network access
> > client implementations don't normalize the NAI (e.g. don't use NFC), so
> > that normalization by a AAA proxy MAY be required. 
> >  
> > At the same time, it insists that byte-by-byte comparisons be done on
> > NAI realms.
> 
>   It uses SHOULD, not MUST.
 
[BA] If you can't depend on the contents of the User-Name attribute being normalized, then I don't think you can recommend byte-by-byte comparison, because it won't work reliably.   Perhaps the only reason we haven't been bitten by this already is because there are so many internationalization problems in existing implementations that internationalized NAIs aren't used that often. 


>   Part of the issue here is that (a) the existing uses of user
> identifiers are gratuitously incompatible, and (b) no one can agree on
> how to fix it.
 
[BA] While you're probably right about that, I don't think we need to bite off all of the problem in this document.  All we are really trying to do is address the misconceptions of RFC 4282, to prevent it from doing further damage.   The document is very close to accomplishing that, but it is simultaneously also trying to fight other dragons. 
 
My personal preference would be for us to remove material not related to the NAI into a (separate) document, which could also describe what existing implementations do and make some recommendations for network access and RADIUS implementations.     


>   As the document says, all RADIUS systems seem to have ignored 4282's
> recommendations for proxies to normalize the NAI.  The world hasn't
> ended.  In fact, these methods have been proven to be wildly successful.

[BA] It is indeed cheerful to consider how widely ignored RFC 4282 is.  But I wonder whether it is ignored because people realized it was nonsense, or because they hadn't encountered enough internalized NAIs to notice how nonsensical it was. 

>   When data is transported in a protocol like HTTP, it is escaped as per
> the requirements of that protocol.  When the same data exits the
> protocol, it is un-escaped.  i.e. the escaping matters only for HTTP
> transport.  It is *transparent* to the data being transported.

[BA]  My question was whether "escaped"  NAIs ever show up in the RADIUS User-Name attribute, say in RFC 5090 implementations.  Reading the RFC 5090 examples, the User-Name attribute seems to have a bogus value (e.g. "12345678"), so it's not clear to me what is going on.   
 
Speaking of which, are there any RFC 5090 implementations?  
 
The other place this could potentially come up is in other application-layer usages (e.g. ABFAB).  But I don't know enough about how those do (or should) work. 

>   The name of the file exists outside of HTTP.  Any HTTP encoding of
> that filename must stay within the HTTP protocol.

[BA]  Re-reading RFC 5090, it isn't clear to me whether the HTTP or SIP encoding will leak into RADIUS or not.  But I guess the only place where the leak would be relevant is the User-Name attribute, because attributes like the "Digest-Realm" Attribute don't contain an NAI realm (and aren't used for routing).  

>   In fact, the document tries to make clear that the "HTTP escaped NAI"
> MUST NOT be used anywhere.  It's not the NAI.
 
[BA] I agree that it isn't an NAI.  And in reading RFC 5090 it seems like HTTP/SIP input wouldn't affect the User-Name attribute where an NAI would be expected to be.  But I'm not sure, because I've never seen an RFC 5090 implementation to know for certain. 
 
>   Sort of.  The NAI can be transported in other protocols.  It is hoped
> that protocols will share common user identifiers.  Where they don't, we
> have potential for accounting problems, security breaches, etc.
 
Aside from network access protocols (e.g. PPP, EAP, IKEv2, L2TP, etc.) and AAA protocols (RADIUS, Diameter) what other protocols can transport NAIs?  
 
Also, if an application layer protocol uses an identifier that isn't an NAI, I am wondering whether we shouldn't require that this identifier NOT be placed in the RADIUS User-Name attribute so that it won't confuse things further.  Reading RFC 5090, I'm half convinced that we missed a bullet there (particularly if it wasn't implemented).  

>   It has to occur somewhere.  End hosts don't do it.  AAA proxies don't
> do it.  *Any* place we pick is arguably wrong.

[BA] I don't think it's a question of "wrong", but more of a question of "what is easiest to deploy?"  Getting changes made to old clients is really, really hard.   Similarly, trying to get a patch to a NAS is gonna be tough.  AAA proxies probably aren't that easy to fix either but there are typically fewer of them than clients or NASen. 

>   Do you have suggested text?
 
[BA] I can find some, assuming we agree on the scope and direction.