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

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Jun 2013 18:15:11 -0700

While the document now seems to recognize reality in several places, the recognition has not reflected itself uniformly in the normative statements.  So, overall, the draft contradicts itself in multiple places. 
 
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. 
 
Those two points of view aren't compatible with each other.   If we can't rely on normalization by clients or NAS devices then AAA proxies doing realm comparisons need to do normalization first or the comparisons won't be reliable.   
 
Another contradiction relates to the format of user identifiers used in non-network access protocols like SIP and HTTP. 
 
The document admits that they could use escaping, and won't normalize the NAI as recommended prior to sending it. 
 
This of course implies that the escaped characters need to be converted prior to comparison, which the document does note.  
 
But this contradicts the byte-by-byte comparison statements (as well as the "normalize before sending" statement).  
 
It also seems to contradict the "use NAI in other protocols" recommendation, since we can't have an expectation that all protocols using AAA will have user identities that conform to the NAI. 
 
Overall, my suggestion is that the document needs to re-think the approach. 
 
While it is OK to require the NAI to be provided in UTF-8 form,  normalization via NFC is so uncommon that requiring it to occur on the end host does not pass the smell test. 
 
Since it is unlikely that network access clients or NAS devices will change their behavior, it seems to me that AAA proxies making realm comparisons (e.g. for realm routing) need to be prepared to normalize the realms first.  The steps involved in doing this should be described in the document. 
 
Also, while I don't disagree with the statements made about "NAI decoration" the term "deprecation" isn't explicitly used, though that seems clearly to be what is meant.  So if we are really trying to put the decoration practice to bed, we should say so (like obsoleting the relevant documents).

---

From: Alan DeKok <[email-masked]>
Date: Sat, 08 Jun 2013 22:22:51 -0400

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

  It uses SHOULD, not MUST.

> Those two points of view aren't compatible with each other.   If we
> can't rely on normalization by clients or NAS devices then AAA proxies
> doing realm comparisons need to do normalization first or the
> comparisons won't be reliable.  

  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.

  This document tries to address the incompatibilities by suggesting the
format and use of a user identifier.  It builds on world-wide
deployments of NAI-like systems.  e.g. Eduroam.

  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.

> Another contradiction relates to the format of user identifiers used in
> non-network access protocols like SIP and HTTP.
>  
> The document admits that they could use escaping, and won't normalize
> the NAI as recommended prior to sending it.

  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.

  When I go to http://example.com/%69ndex.html, I may get served a file
off of the disk called "index.html".  By no means do I get server
"%69ndex.html"

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

> This of course implies that the escaped characters need to be converted
> prior to comparison, which the document does note. 
>  
> But this contradicts the byte-by-byte comparison statements (as well as
> the "normalize before sending" statement). 

  No.  The "HTTP escaped NAI" is a blob of data being transported via
HTTP.  The NAI is the data that comes out of HTTP.  The only requirement
is that HTTP can transport the NAI.  There is no required that the "HTTP
escaped NAI" be used anywhere.

  In fact, the document tries to make clear that the "HTTP escaped NAI"
MUST NOT be used anywhere.  It's not the NAI.

> It also seems to contradict the "use NAI in other protocols"
> recommendation, since we can't have an expectation that all protocols
> using AAA will have user identities that conform to the NAI.

  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.

> Overall, my suggestion is that the document needs to re-think the approach.

  The approach the document takes is not the one you're describing.

> While it is OK to require the NAI to be provided in UTF-8 form, 
> normalization via NFC is so uncommon that requiring it to occur on the
> end host does not pass the smell test.

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

  Therefore, we need to find reasons to pick one place over another.
The document describes it's current reasons.

> Since it is unlikely that network access clients or NAS devices will
> change their behavior, it seems to me that AAA proxies making realm
> comparisons (e.g. for realm routing) need to be prepared to normalize
> the realms first.  The steps involved in doing this should be described
> in the document.

  I'm fine with that.  If there's WG consensus, we can change the document.

  Do you have suggested text?

> Also, while I don't disagree with the statements made about "NAI
> decoration" the term "deprecation" isn't explicitly used, though that
> seems clearly to be what is meant.  So if we are really trying to put
> the decoration practice to bed, we should say so (like obsoleting the
> relevant documents).

  I'm fine with that.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Jun 2013 19:54:43 -0700

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

> identifiers are gratuitously incompatible, and (b) no one can agree on
 
[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.     

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

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

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

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

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

---

From: Alan DeKok <[email-masked]>
Date: Sun, 09 Jun 2013 09:12:08 -0400

Bernard Aboba wrote:
> [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.

  The document is consistent in that it suggests end hosts should
normalize the NAI.  Proxies can then do byte-by-byte comparisons.

  And I agree that i18n issues largely haven't come up.  Where I've seen
them occur, people use non-UTF8 character sets, and don't do roaming.

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

  It's a bit pointless to define an NAI without suggested uses.

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

  A bit of both, I think.

> [BA]  My question was whether "escaped"  NAIs ever show up in the RADIUS
> User-Name attribute,

  Never never never never never.  I hope I'm being clear on that. :)

> Speaking of which, are there any RFC 5090 implementations? 

  I've heard of one from a minor switch vendor.

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

  The point for me is "user identifier" is a separate concept from "how
user identifier is transported in a protocol".  For RADIUS, they're the
same, because it's UTF8-clean.  HTTP isn't, so it escapes characters
during transport.

> Aside from network access protocols (e.g. PPP, EAP, IKEv2, L2TP, etc.)
> and AAA protocols (RADIUS, Diameter) what other protocols can transport
> NAIs? 

  IMHO, any protocol which requires user identifiers.

  It's ridiculous that each protocol has its own format for user
identifiers.

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

  Spreading the rot from other protocols into RADIUS isn't a good idea.
 If the other protocol thinks it's a user identifier, it should go into
the RADIUS User-Name attribute.

  It's then up to the RADIUS server to decide it's not an NAI, and then
to do whatever ad-hoc nonsense is necessary in order to authenticate the
users.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Jun 2013 10:00:14 -0400

For what it's worth, I continue to believe that Bernard may have a point
and that we need to engage with the apps community to resolve the
question of normalization.

I'm not particularly worried about the HTTP/SIP/etc points Bernard
raises.  I think that there is some semantic ambiguity there, and I'm
not against improvements in the text, but I don't see that as a blocking
concern.  I think that the ambiguity is unlikely to result in problems
in practice that do not already exist.

--Sam