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

[Alan DeKok <[e-mail]>]

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.