RE: rfc2486bis

[<Pasi.Eronen@nokia.com>]

Hi,

My interpretation of 2486 (which anyone is of course free to
disagree with :-) is that it specifies a syntax for identifying
users with three important aspects:

  1) the NAI (usually) consists of two parts, username and realm,
     separated by "@"

  2) the "right" to use some realm is tied to obtaining a FQDN 
     (that is, registering DNS name).

  3) the username part is allocated by the "owner" of the realm
     in whatever manner the owner wishes.

Item 2 means that "user@foo" is not a valid NAI (at least
as long as we don't have "foo" TLD).

Item 3 means that "intermediary.com!user@example.com" must be
interpreted as username "intermediary.com!user" in realm 
"example.com" _except_ if the node processing it has specific
knowledge about how example.com realm allocates usernames 
(typically example.com's AAA server would have this knowledge).

I know that syntaxes such as "ipass/user@example.com" and 
"user@foo" are commonly used, but IMHO they are not NAIs as 
defined by RFC 2486. This, of course, does not prevent them from 
working just fine in many protocols e.g. PPP CHAP or RADIUS 
User-Name attribute, but this does not make them 2486-compliant...
(otherwise, "domain+user", "//domain/user" and even 
"example.com@user" would be equally valid NAIs).

However, since especially the "intermediary selection" 
seems to have many useful applications, I agree that 2486bis
should specify how it is done. The current 2486bis-00 tries
to do in a backward-compatible way that was already hinted
in RFC 2486 ("home.example.com!user@intermediary.example.com").

Another possibility would be "ipass/user@example.com", but this
would mean a major change to RFC2486. First, it creates a new
namespace ("ipass" is not a valid realm name). Second, it breaks
compatibility with RFC 2486 because in effect it prevents the
use of usernames with "/" character.

I am not so sure what would be the advantage of creating 
a non-FQDN namespace for "realms". Presumably, this namespace
has to be managed somehow, and obtaining a DNS name is IMHO
not an unreasonable requirement. Of course, IETF is not
a protocol police: if someone uses "user@foo" and it works
for him/her, we can't prevent that--but it's not NAI as
specified in RFC2486 but something else.

Best regards,
Pasi

> -----Original Message-----
> From: Blair T. Bullock
> Sent: Monday, March 22, 2004 10:01 PM
> To: jari.arkko@piuha.net
> Cc: radiusext@ops.ietf.org
> Subject: RE: rfc2486bis
> 
> 
> This raises some very good questions:  
> 
> In the roaming world, while the 'private' peering of RADIUS
> servers would allow for a non-FQDN to be used for the purposes
> of routing, i.e.  user@foo or even user@XZY, the common
> practice is to use a FQDN i.e.  user@foo.com or foo.bar.com or
> foo.org,etc.  However, there is no reasonable expectation that
> the FQDN be actually registered or owned by the home network
> and placed in DNS.  Since the peering is ambiguous and often
> private, I could just as well claim coke.com for my users or
> use some semblance of a FQDN, registered or not.  Obviously
> using a private IP would be bad, but using non DNS methods
> like blair@216.239.97.170 is valid, right?  So why not a
> non-FQDN blair@myhome if the private RADIUS peering recognizes
> it.  Any thoughts on guidelines for this?
> 
> Another question in regards to the current conversation...
> 
> In a roaming application where there is a mediating network
> whose RADIUS exchange must be selected and transited in order
> to resolve private peering, is there any qualification which
> requires a FQDN?  We all know that the use of a prefix to
> select and exchange i.e.  IPASS/user@foo.com and or chained
> suffix to do so, i.e. user@foo.com@IPASS or
> user@foo.com@ipass.com is common practice... Can the '%' or
> '!' be used in combination with a non-FQDN as an alternative
> method for this NAI construction without applying an invalid
> syntax? i.e.  IPASS%user@foo.com or ipass!user@foo.com rather
> than using a non-reserved delimiter such as '/' or 'chaining'
> the suffix which is described as illegal in the previous
> articles?  Again, use of non-FQDNs for the purposes of
> navigating private RADIUS exchanges is absolutely necessary,
> but the current (and past) NAI examples don't reflect these
> emerged models very well.
> 
> And a question in regards to the latest NAI proposals...
> 
> What is the basis for the 'position' swapping in the latest
> draft?  Changing ...  user@foo.com to
> "foo.com!user@intermediary.com"
> 
> ...breaks today's practice and would significantly impact the
> way in which networks peer today.  Is there a compelling
> reason for this or is it merely a proposal to once and for all
> formalize the inter-network NAI construction.  There are some
> significant issues with this approach, particularly in
> reflecting today's business models and practices of NAI
> construction.
> 
> Thank you for your consideration.
> 
> Best Regards, 
> 
> Blair

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>