Subject: [radext] Comments on draft-ietf-radext-nai-00

From: "Jim Schaad" <[email-masked]>
Date: Thu, 3 Jan 2013 20:05:02 -0800

In section 2.3, is there still an absolute limit to the length of the NAI
with the possibility of using the Radius fragmentation draft to extend them
longer?  While it would not be generally reasonable, it might remove the
restriction.

In Section 2.11, Given the  potential registration of new top level domains,
do you still want to keep fred@example as an invalid NAI?  What if somebody
succeeds in getting example as a top level domain?  (Which I sincerely hope
could never happen.)

In Section 2.7, Two issues:
a) I am unclear if one should do the comparison and routing based on the
entire utf8-realm portion of the name, or if one can (and perhaps should be
able to) do the routing based on the set of labels that occur in the
utf8-realm.  As part of this one wonders about doing any matching of
utf8-realm names and if that needs to be discussed as well

b)  I find the last paragraph to be very confusing.  The use of or would
make it appear that it would be one of the items listed, however based on
what I would expect it could be any or all of the elements listed.
Grammatically this is very fuzzy.  Additionally, do you want to pre-view
section 2.9 and make the DNS Host name be an explicit  ASCII version of the
DNS host name rather than allowing people to think it might be the
internalized version?

Jim

---

From: Sam Hartman <[email-masked]>
Date: Fri, 04 Jan 2013 08:19:56 -0500

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> In section 2.3, is there still an absolute limit to the length
    Jim> of the NAI with the possibility of using the Radius
    Jim> fragmentation draft to extend them longer?  While it would not
    Jim> be generally reasonable, it might remove the restriction.

More generally, to what extent is NAI a RADIUS concept and to what
extent is it an AAA concept and potentially broader.
Perhaps it's better to say that NAIs that MAY be transported over RADIUS
have this limitation?

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 Jan 2013 07:00:47 -0800

> Perhaps it's better to say that NAIs that MAY be transported over RADIUS

[BA] This raises the question of what the definition of NAI is for the purpose of this document. 

RFC 2486 defines the NAI as follows:

      The Network Access Identifier (NAI) is the userID submitted
      by the client during PPP authentication.  

The definition was changed in RFC 4282:

      The Network Access Identifier (NAI) is the user identity submitted
      by the client during network access authentication.

I am not sure that the above definition is still usable, because since RFC 4282 was published, RADIUS has been 
extended to handle authentication for more than just network access.  For example, RFC 5090 defines how to use 
RADIUS for Digest Authentication (HTTP, SIP, etc.) 

As a result, is it still valid to assume that the RADIUS User-Name Attribute contains an NAI?

I am not sure. 

For example, RFC 5090 Section 2.2.1 includes the following statement:

   Correlation between User-Name and SIP-AOR AVP values is required just
   to avoid any user from registering or misusing a SIP-AOR that has
   been allocated to a different user.

In the above statement, it would appear that the RADIUS User-Name Attribute is to be "correlated" with the SIP AOR.  

Does the ABNF provided in this document apply to the contents of the RADIUS User-Name in this case?  Is a User-Name Attribute
"correlated" with a SIP AOR an NAI?

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 Jan 2013 10:29:51 -0800

> The NAI has been around for a decade.  What the heck is the issue with just using it?

[BA] The NAI definition in RFC 2486 and 4282 applies to network access (PPP, EAP, etc.).   Since network access was the only application of RADIUS at the time those documents were written, it could be assumed that the RADIUS User-Name Attribute also contained an NAI. 

However, where RADIUS is used for application-layer authentication (e.g. in SIP or HTTP),  it isn't clear to me that the User-Name will necessarily contain an NAI, or that statements about normalization will necessarily apply. 

For example, can RADEXT impose a normalization requirement on SIP UACs?

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 4 Jan 2013 10:54:12 -0800

Sam,

This text is in the context of RADIUS limitations.  It says that for
Diameter the length limitation is much longer

Jim

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Friday, January 04, 2013 5:20 AM
> To: Jim Schaad
> Cc: Alan DeKok; [email-masked]
> Subject: Re: [radext] Comments on draft-ietf-radext-nai-00
> 
> More generally, to what extent is NAI a RADIUS concept and to what extent
> is it an AAA concept and potentially broader.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Jan 2013 15:27:55 -0500

> purpose of this document.

  Perhaps it's becoming more of an authorization identifier.

> RADIUS for Digest Authentication (HTTP, SIP, etc.) 

  I think it's a less useful definition.

> As a result, is it still valid to assume that the RADIUS User-Name Attribute contains an NAI?

  I think so.  It's widely used that way in practice.

> In the above statement, it would appear that the RADIUS User-Name Attribute is to be "correlated" with the SIP AOR.  

  Which gets into all kinds of issues.  I18n, among others.

  The RFC 5090 comment about correlation seems to me like they've punted
on interoperability issues.  If the identities are the same, then there
should ideally be only one, or they should be required to be identical.
 If the identities are different, then "correlation" would need to be
well-defined.

> "correlated" with a SIP AOR an NAI?

  I would say "yes" to the first one, and "not my problem" to the second
one.  The NAI has been around for a decade.  What the heck is the issue
with just using it?

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Jan 2013 15:34:44 -0500

Bernard Aboba wrote:
> [BA] The NAI definition in RFC 2486 and 4282 applies to network access
> (PPP, EAP, etc.).   Since network access was the only application of
> RADIUS at the time those documents were written, it could be assumed
> that the RADIUS User-Name Attribute also contained an NAI.

  Sure.

> However, where RADIUS is used for application-layer authentication (e.g.
> in SIP or HTTP),  it isn't clear to me that the User-Name will
> necessarily contain an NAI, or that statements about normalization will
> necessarily apply.

  That is likely true.

> For example, can RADEXT impose a normalization requirement on SIP UACs?

  I would say no.  But if the SIP credentials go into a RADIUS packet, I
would *hope* that the two standards are compatible.

  The expectation of the end user is that they have a "username" and
"password" which is tied to their identity.  It is *not* tied to the
individual protocol used.  The user may not even know *which* protocol
is being used for network or application access.

  I see us having two choices  (1) give up on the problem, and say that
*every* protocol has unique user identifiers which have *no* meaning
outside of that protocol.  Or (2) try to meet the end user expectations
where identities are across protocols.

  Here, if the SIP UAC is gratuitously different from the common RADIUS
practice, then SIP would seem to be incompatible with RADIUS
authentication.  If they're similar, then the common practice would be
to use the *subset* of identifiers that are acceptable to both protocols.

  My $0.02 is that an authentication protocol should define a standard
format for identifiers.  We should encourage other working groups to use
that standard.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Jan 2013 20:45:12 -0500

> longer?  While it would not be generally reasonable, it might remove the

  The fragmentation draft applies to the "long" extended attributes.  So
new attributes can have a long NAI.  The User-Name is still limited to
253 octets.

  It may be worth adding a note that other protocols have other limitations.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Jan 2013 20:56:25 -0500

The ABNF says:

utf8-realm     =  1*( label "." ) label

  So the issue is with the lack of a '.', not the "example" TLD.

> utf8-realm names and if that needs to be discussed as well

  I would suggest that routing be done on the entirety of the
utf8-realm.  That's the easiest process to follow.

  I'll add some text suggesting that routing can be done on labels, too.
 But it should again be done as binary comparison:

...
It is RECOMMENDED to use the entirety of the "utf8-realm" for the
routing decisions.  However, systems MAY use a portion of the
"utf8-realm" portion, so long as that portion is a valid "utf8-realm",
and that portion is handled as above.  For example, routing
"[email-masked]" to a "com" destination is forbidden, because "com"
is not a valid "utf8-realm".  However, routing
"[email-masked]" to the "example.com" destination is
permissible.
...

> Grammatically this is very fuzzy.

  OK.  I'll clarify that:

This "next hop" information may be any of, or all of, the following
information: IP address; port; RADIUS shared secret; TLS certificate;
DNS host name; or instruction to use dyanmic DNS discovery (i.e. look
up a record in the "utf8-realm" domain)

>  Additionally, do you want to pre-view

  I'd prefer to avoid that issue, if possible.  A statically configured
DNS host name should be in a form that's acceptable to all parties, and
works.  It only needs to be an ASCII version if the i18n version is
non-normalized, and the parties can't for normalization / ASCII
conversion.  The goal of modern DNS systems would seem to be to allow
i18n domains, so we should allow that, too.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Jan 2013 12:59:08 -0500

Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Jan 2013 08:34:30 -0500

I think it is strongly desirable that we say the username attribute
always contains a NAI.
I think this is close enough to true for SIP and HTTP and is definitely
what ABFAB needs.
I think that if we do anything else proxies need to know far more about
the application than is desirable.
In my mind one major advantage of RADIUS over Diameter is that RADIUS
doesn't have applications.
It's also a disadvantage if you need that complexity.

--Sam

---

From: Stefan Winter <[email-masked]>
Date: Mon, 07 Jan 2013 15:10:21 +0100

Hi,

> I think it is strongly desirable that we say the username attribute

Very often, the User-Name attribute is constructed from outside of
RADIUS, and often by direct user input. E.g. for EAP passthrough
authenticators, where the RADIUS client has no chance but to literally
copy whatever it got as EAP-Respsonse/Identity. And users are creative.

It is very difficult to enforce "User-Name always contains a NAI". It
would basically boil down to enforce on every RADIUS-backed application
that it refuses to accept user input which is not a valid NAI. In the
example above, the EAP supplicant would need to stop the user from
trying to fill in a non-NAI identifier into the "Username" box.

I believe RADIUS will always have to cope with contents of User-Name
which are not valid NAIs. Maybe "cope with" can turn out to mean
"reject" or "silently discard". But if that's supposed to be the case
for all incoming User-Names, irrespective of the deployment, the
document would need to state this very explicitly (and I didn't find
that yet).

Greetings,

Stefan Winter

> _______________________________________________
> radext mailing list
> [email-masked]
> 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: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Mon, 07 Jan 2013 10:00:16 -0500

> trying to fill in a non-NAI identifier into the "Username" box.

  Sure.  RADIUS already has many cases where the User-Name doesn't
contain an NAI.  We can't *require* it to be an NAI.

  We can, however, RECOMMEND it.  And similarly recommend that other
protocols use it.

  Again, having each protocol invent a user identifier is *ridiculous*.
 It's 2013.  Many protocols back-end into AAA systems already.  So if
the identifier is going to be used in RADIUS with roaming, just make the
identifier an NAI.  Don't try to be smart and invent something incompatible.

> document would need to state this very explicitly (and I didn't find

  I strongly oppose any suggestion to say "the User-Name MUST contain an
NAI".

  This document defines the NAI, and suggests how it is used in other
protocols.  It adds *no* normative requirements to RADIUS.

  Alan DeKok.