Subject: RE: RADIUS User-Name versus EAP Identity

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 13 Oct 2008 10:26:35 -0700

RFC 3579 Section 2.1 states:

   In order to permit non-EAP aware RADIUS proxies to forward the
   Access-Request packet, if the NAS initially sends an
   EAP-Request/Identity message to the peer, the NAS MUST copy the
   contents of the Type-Data field of the EAP-Response/Identity received
   from the peer into the User-Name attribute and MUST include the
   Type-Data field of the EAP-Response/Identity in the User-Name
   attribute in every subsequent Access-Request.

So RFC 3579 does require the User-Name field and EAP-Response/Identity
fields to be identical at the NAS originating the Access-Request.  

However, after that it is possible that RADIUS proxies will modify the
User-Name attribute, so that by the time the RADIUS Access-Request
arrives at the RADIUS server, the EAP-Response/Identity and User-Name
Attribute will no longer match.  For example,  the initial  
EAP-Response/Identity could have included NAI source-routing which was
subsequently stripped off.  For example, the EAP-Response/Identity
might have been [email-masked]; by the time
this arrives at the RADIUS server, the example.com proxy will have
transformed it into [email-masked] within the User-Name
Attribute, although the contents of the EAP-Message/EAP-Response/Identity
Attribute will have remained [email-masked]. 

The RADIUS server determines how to proceed with the authentication
based on the User-Name attribute, rather than the EAP-Response/Identity. 
Unless the EAP method somehow incorporates the EAP-Response/Identity into
its calculations, there might not even be reason for the EAP method to
examine it (as opposed to say, the method-specific Peer-Id).  For
example, RFC 3748 Section 5.1 states:

      It is RECOMMENDED that the Identity Response be used primarily for
      routing purposes and selecting which EAP method to use.  EAP
      Methods SHOULD include a method-specific mechanism for obtaining
      the identity, so that they do not have to rely on the Identity
      Response.  Identity Requests and Responses are sent in cleartext,
      so an attacker may snoop on the identity, or even modify or spoof
      identity exchanges.  To address these threats, it is preferable
      for an EAP method to include an identity exchange that supports
      per-packet authentication, integrity and replay protection, and
      confidentiality.  The Identity Response may not be the appropriate
      identity for the method; it may have been truncated or obfuscated
      so as to provide privacy, or it may have been decorated for
      routing purposes.  Where the peer is configured to only accept
      authentication methods supporting protected identity exchanges,
      the peer MAY provide an abbreviated Identity Response (such as
      omitting the peer-name portion of the NAI [RFC2486]).  For further
      discussion of identity protection, see Section 7.3.

My understanding is that the WMF v1.0 specification does include some
unique (e.g. non RFC 4282) User-Name mangling.  However, I don't recall
any mangling of the EAP-Response/Identity. 

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Monday, October 13, 2008 8:44 AM
To: Bernard Aboba
Subject: RADIUS User-Name versus EAP Identity

  RFC 3579 doesn't require these two fields to be the same, so far as I
can tell.  Yet every AAA server I've checked (tested and/or asked
around) requires that these fields *are* the same.

  Does this make sense?  Is it an issue with existing implementations?

  The question has come up because of issues with RADIUS routing &&
proxying.  The traditional dial-up prefix/suffix mangling && editing
doesn't work for EAP.  It defines edits for the User-Name, not for EAP
identity.  And then the fields differ...

  Some people I've talked to say that the WiMAX NWG requires User-Name
mangling, *and* that it also requires similar edits to be done to the
EAP Identity.  But I can't find that in the 400+ pages of NWG
specifications.

  Comments?

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 17 Oct 2008 16:47:28 +0200

> fields to be identical at the NAS originating the Access-Request.  

  Most RADIUS servers seem to enforce this.

> Attribute will no longer match.

  This is causing problems in real-world pre-deployment systems.

  Maybe a solution would be to require that implementations ignore the
contents of the EAP-Response/Identity field.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 17 Oct 2008 15:17:48 -0700

[BA] Yes, in most cases the implementation should use the RADIUS
User-Name Attribute instead.  There might be a few cases where the
EAP method calculations depend on the EAP-Response/Identity
(RFC 3748-defined methods such as EAP-MD5).  Are you seeing problems
only with those methods, or with other ones as well?

BTW, RFC 5113 Section 2.3 does talk a bit about this issue:

   As noted in [RFC4284], it is also possible to utilize an NAI for the
   purposes of source routing.  In this case, the client provides
   guidance to the AAA infrastructure as to how it would like the access
   request to be routed.  An NAI including source-routing information is
   said to be "decorated"; the decoration format is defined in
   [RFC4282].

   When decoration is utilized, the EAP peer provides the decorated NAI
   within the EAP-Response/Identity, and as described in [RFC3579], the
   NAS copies the decorated NAI included in the EAP-Response/Identity
   into the User-Name attribute included within the access request.  As
   the access request transits the roaming relationship path, AAA
   proxies determine the next hop based on the realm included within the
   User-Name attribute, in the process, successively removing decoration
   from the NAI included in the User-Name attribute.  In contrast, the
   decorated NAI included within the EAP-Response/Identity encapsulated
   in the access request remains untouched.  As a result, when the
   access request arrives at the AAA home server, the decorated NAI
   included in the EAP-Response/Identity may differ from the NAI
   included in the User-Name attribute (which may have some or all of
   the decoration removed).  For the purpose of identity verification,
   the EAP server utilizes the NAI in the User-Name attribute, rather
   than the NAI in the EAP-Response/Identity.

   Over the long term, it is expected that the need for NAI "decoration"
   and source routing will disappear.  This is somewhat analogous to the
   evolution of email delivery.  Prior to the widespread proliferation
   of the Internet, it was necessary to gateway between SMTP-based mail
   systems and alternative delivery technologies, such as Unix-to-Unix
   CoPy Protocol (UUCP) and FidoNet.  Prior to the implementation of
   email gateways utilizing MX RR routing, email address-based source-
   routing was used extensively.  However, over time the need for email
   source-routing disappeared.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 18 Oct 2008 07:43:10 +0200

> only with those methods, or with other ones as well?

  The problems are across all EAP methods.

> BTW, RFC 5113 Section 2.3 does talk a bit about this issue:
...
>    and source routing will disappear

  The solution that has been proposed in vendor forums removes the need
for source routing.  Even if we ignore the User-Name versus EAP-Identity
issues (which exist), the manual updates of routes in RADIUS proxy
infrastructures is becoming prohibitive.

  Alan DeKok.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sat, 18 Oct 2008 10:04:37 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Friday, October 17, 2008 10:43 PM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: RADIUS User-Name versus EAP Identity
> 
> Bernard Aboba wrote:
> > User-Name Attribute instead.  There might be a few cases 
> where the EAP 
> > method calculations depend on the EAP-Response/Identity (RFC 
> > 3748-defined methods such as EAP-MD5).  Are you seeing 
> problems only 
> > with those methods, or with other ones as well?
> 
[Joe]This is strange, many EAP methods do not rely upon the
EAP-Response/Identity.  What are the problems you are seeing?   

>   The solution that has been proposed in vendor forums 
> removes the need for source routing.  Even if we ignore the 
> User-Name versus EAP-Identity issues (which exist), the 
> manual updates of routes in RADIUS proxy infrastructures is 
> becoming prohibitive.
> 
>   Alan DeKok.
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 18 Oct 2008 19:26:03 +0200

> EAP-Response/Identity.  What are the problems you are seeing?   

  The home RADIUS server is rejecting the request because
EAP-Response/Identity does not match the RADIUS User-Name.  This is
happening for most (if not all) RADIUS servers we've tested.

  The common interpretation is that if the fields disagree, then the NAS
is doing something strange.  One problem seen in the past is where the
User-Name in the first EAP packet is set from the EAP-Response/Identity,
but later User-Names are... something else.  This happens without
intermediate proxies, and is a function of a buggy NAS.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 18 Oct 2008 10:48:43 -0700

Alan DeKok said:

"  The home RADIUS server is rejecting the request because
EAP-Response/Identity does not match the RADIUS User-Name.  This is
happening for most (if not all) RADIUS servers we've tested.

intermediate proxies, and is a function of a buggy NAS."

Is the RADIUS server returning a User-Name attribute in say, an
Access-Challenge?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 20 Oct 2008 08:38:44 +0200

> Is the RADIUS server returning a User-Name attribute in say, an

  No.  Even if it does, the User-Name in the Access-Request *isn't* the
same as in a previous Access-Challenge.

  I've put this kind of behavior into my "broken NAS" bin, along with
other "inventive" behavior, like echoing an Access-Challenge back to the
RADIUS server when it has (... Message-Authenticator, State) instead of
the preferred (... State, Message-Authenticator)

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 20 Oct 2008 11:08:21 +0200

To follow up on a separate item:

Bernard Aboba wrote:
> ... For example,  the initial  
> Attribute,

  The problem is that this isn't common practice.  The existing roaming
providers don't do this.  Many AAA servers don't do this.

  Where did this text come from?  Why is it there?

  I've discussed this && the i18n issues with roaming providers && AAA
implementors.  They all agree that the existing text in 4282 relating to
i18n and bang-path routing is wrong.  They are starting to see other
standards rely on the "RFC4282" behavior, and it's causing them
problems.  There's a big push to come up with fixes.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 20 Oct 2008 10:40:21 -0700

Alan DeKok said:

"  The problem is that this isn't common practice.  The existing roaming
providers don't do this.  Many AAA servers don't do this.

  Where did this text come from?  Why is it there?"

[BA] The push came from 3GPP.  A discussion of some of the scenarios that
were
envisaged can be found in RFC 5113.  However, at this point there seems
to be more interest in this in Diameter than in RADIUS:
http://www.ietf.org/internet-drafts/draft-korhonen-dime-nai-routing-01.txt

Alan DeKok also said:

"I've discussed this && the i18n issues with roaming providers && AAA
implementors.  They all agree that the existing text in 4282 relating to
i18n and bang-path routing is wrong.  They are starting to see other
standards rely on the "RFC4282" behavior, and it's causing them
problems.  There's a big push to come up with fixes."

I agree that there is an urgent need to fix the i18n issues in RFC 4282. 
One way to address this would be to write an "NAI Internationalization"
document that would update RFC 4282, stating that the NAI should be sent
in UTF-8 and that translation to punycode should only occur when looking
up a realm in the DNS. 

With respect to bang-path routing, is there a concern that goes beyond the
usefulness of it?  For example, is there a concern that two implementers who
thought it useful would be unable to interoperate based on RFC 4282 for 
reasons other than those relating to i18n? 

My recollection is that support for bang-path routing is optional, so that
an implementer believing that it is unnecessary/useless/silly should not
feel compelled to implement it.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 20 Oct 2008 23:10:18 +0200

> http://www.ietf.org/internet-drafts/draft-korhonen-dime-nai-routing-01.txt

  Hmm... OK.

> in UTF-8 and that translation to punycode should only occur when looking

  I've looked at 4282, and I think that the issues are larger than that.
 The ABNF for the NAI defines the NAI *after* the punycode encoding.  It
says *nothing* about the NAI before the punycode encoding.  So an update
to 4282 would involve revving the ABNF, too.

  Once the NAI && i18n text is changed, the text relating to
compatibility with email && DNS needs to be updated.

> reasons other than those relating to i18n? 

  The concern is that it's being pushed as a "standard" because it's in
4282.  Nearly every RADIUS vendor / implementor I've talked to doesn't
like it.  The operators who run WiFi networks don't like it.  But
because it's a "standard" in 4282, there is a strong push in some
circles to push it on everyone.

> feel compelled to implement it.   

  The "optional" part seems to have been missed by some standards bodies
that are referencing 4282.

  Seeing that the text was there only for 3GPP, and not for traditional
(or currently deployed) RADIUS systems, it would seem useful to delete
it.  If 3GPP wants that format, they can define it themselves.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 20 Oct 2008 14:38:57 -0700

Alan DeKok said:

"  I've looked at 4282, and I think that the issues are larger than that."

Yes, there are a large number of issues in RFC 4282, particularly Section
2.4:

Here are just a few: 

2.4.  International Character Sets

   This specification allows both international usernames and realms.
   International usernames are based on the use of Unicode characters,
   encoded as UTF-8 and processed with a certain algorithm to ensure a
   canonical representation.  Internationalization of the realm portion
   of the NAI is based on "Internationalizing Domain Names in
   Applications (IDNA)" [RFC3490].

   In order to ensure a canonical representation, characters of the
   username portion in an NAI MUST fulfill the ABNF in this
   specification as well as the requirements specified in [RFC4013].
   These requirements consist of the following:

   o  Mapping requirements, as specified in Section 2.1 of [RFC4013].
      Mapping consists of mapping certain characters to others (such as
      SPACE) in order to increase the likelihood of correctly performed
      comparisons.

[BA] Unfortunately, as pointed out in RFC 4690, these mappings can be
language specific, and so are not easily defined.  In fact, they may
vary by registry.  So it would seem to make more sense to specify that
realms need to conform to IDNAbis and registry requirements and leave
it at that.  

   o  Normalization requirements, as specified in Section 2.2 of
      [RFC4013], are also designed to assist in comparisons.

[BA] This assumes that the NAI is being entered by a user, rather than
being automatically configured, which is often the case.  Why should
normalization be required for an automatically configured NAI? 

   o  Prohibited output.  Certain characters are not permitted in
      correctly formed strings that follow Section 2.3 of [RFC4013].
      Ensuring that NAIs conform to their ABNF is not sufficient; it is
      also necessary to ensure that they do not contain prohibited
      output.

[BA] It seems that the set of prohibited characters should be the same
within IDNAbis as within a realm that is also an FQDN.  However, this
statement ensures that they will be different since RFC 4013 and IDNAbis
are not in sync. Why not just cite IDNAbis?

   o  Bidirectional characters are handled as specified in Section 2.4
      of [RFC4013].

[BA] Given that the bidi rules are being revised in IDNAbis, this would
also appear to be out of date.  Better to cite the IDNAbis bidi document.

   o  Unassigned code points are specified in Section 2.5 of [RFC4013].
      The use of unassigned code points is prohibited.

[BA] Doesn't this effectively prohibit support for new scripts?  The
IDNAbis approach seems more sensible.  

   The mapping, normalization, and bidirectional character processing
   MUST be performed by end systems that take international text as
   input.  In a network access setting, such systems are typically the
   client and the Authentication, Authorization, and Accounting (AAA)
   server.  NAIs are sent over the wire in their canonical form, and
   tasks such as normalization do not typically need to be performed by
   nodes that just pass NAIs around or receive them from the network.
   End systems MUST also perform checking for prohibited output and
   unassigned code points.  Other systems MAY perform such checks, when
   they know that a particular data item is an NAI.

[BA] IDNAbis does not require end systems to do this kind of
checking, because presumably these checks are done when the user name
and realm is created in the first place.  If the user name/realm was
never created on the AAA server, then presumably the name also can't
be used on the client, so periodic compliance checks are unnecessary. 

Can't we just say that the realm is required to be registerable as an 
FQDN, and that registry and IDNAbis restrictions must be obeyed? This
would leave sufficient flexibility for registry-specific restrictions. 

   The realm name is an "IDN-unaware domain name slot" as defined in
   [RFC3490].  That is, it can contain only ASCII characters.  An
   implementation MAY support Internationalized Domain Names (IDNs)
   using the ToASCII operation; see [RFC3490] for more information.

[BA] Given that EAP and RADIUS specifications specifically mandate 
UTF-8 usage, this appears wrong.  

   The responsibility for the conversion of internationalized domain
   names to ASCII is left for the end systems, such as network access
   clients and AAA servers.  Similarly, we expect domain name
   comparisons, matching, resolution, and AAA routing to be performed on
   the ASCII versions of the internationalized domain names.  This
   provides a canonical representation, ensures that intermediate
   systems such as AAA proxies do not need to perform translations, and
   can be expected to work through systems that are unaware of
   international character sets.

[BA] A more sensible approach would be to require conversion of UTF-8
to punycode as specified in IDNAbis.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 20 Oct 2008 14:44:36 -0700

Alan DeKok said:

"  The concern is that it's being pushed as a "standard" because it's in
4282.  Nearly every RADIUS vendor / implementor I've talked to doesn't
like it.  The operators who run WiFi networks don't like it.  But
because it's a "standard" in 4282, there is a strong push in some
circles to push it on everyone."

Ugh.  RFC 5113 (which is Informational) points out a number of issues
with bang-path routing as well as RFC 4284.  BTW, aside from 3GPP and
WiMAX, who else is pushing bang-path routing?

"  The "optional" part seems to have been missed by some standards bodies
that are referencing 4282.

  Seeing that the text was there only for 3GPP, and not for traditional
(or currently deployed) RADIUS systems, it would seem useful to delete
it.  If 3GPP wants that format, they can define it themselves."

They specifically requested the IETF to define it so as to enable a
single approach.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 21 Oct 2008 07:59:59 +0200

> WiMAX, who else is pushing bang-path routing?

  No one.

  Historical users of prefix/suffix routing in the WiFi / Dial-up
roaming space want to get rid of it.  Everyone has realized that it's
expensive, fragile, unmaintainable, and inflexible.

  This is a significant change from even a year ago.

> They specifically requested the IETF to define it so as to enable a

  With... who?  WiMAX can already reference the 3GPP specs.  There's no
need for this in IETF documents if no one else wants it.

  Many WiFi operators have WiMAX spectrum.  And they are pushing
strongly for the same solution to apply to both arenas.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 21 Oct 2008 08:28:48 +0200

Hi,

>   This is a significant change from even a year ago.

FWIW, in eduroam we also considered (for a _very_ short time) source
routing options, and also bang-path routing (multiple .edu participants,
physically located in different .ccTLD spaces proved to be a challenge)
but quickly came to the same conclusion as Alan.

That being said, I have no strong feelings regarding expunging of the
wording. After all use of bang-path is optional. And even the RFC makes
clear that the presence of ! in itself does not necessarily make it a
routing hint - it is more a question of interpretation: "The '!'
character may appear in the username  portion of an NAI for other
purposes as well, and in those cases, the rules outlined here do not apply"

Greetings,

Stefan Winter

-- 
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: Thu, 23 Oct 2008 11:52:15 +0200

> Yes, there are a large number of issues in RFC 4282, particularly Section

  Ok.  I'll take a look at writing up some comments on the document.

> normalization be required for an automatically configured NAI? 

  Perhaps normal form when multiple encodings are possible?  RFC 5198
defines a "normalization form NFC", which could apply here.

> are not in sync. Why not just cite IDNAbis?

  Ok... is there a draft with ABNF for internationalized domain names,
*before* the punycode encoding?  The closest I've found is email
internationalization (RFC5234), which is "experimental".

> be used on the client, so periodic compliance checks are unnecessary. 

  I agree.

> would leave sufficient flexibility for registry-specific restrictions. 

  That might be simplest.

> UTF-8 usage, this appears wrong.  

  I think it's referring to the punycode version of the realm.  In which
case I'm left wondering where the ABNF is for the *non* punycode version
of the realm.

>    international character sets.

  This is completely and totally wrong, for a host of reasons.  For one,
no one does this.  (AAA implementors or roaming providers).  For two,
systems that are unaware of international character sets need only to
*route* on the realm name.  They don't need to *interpret* it, or to
*print* it.  As a result, simple checks for equality are good enough.
i.e. "is the realm in this packet identical to the realm an
administrator preconfigured?"

> to punycode as specified in IDNAbis.  

  Only when the realm name is used to perform DNS lookups.  In that
case, the DNS resolving library will Do the Right Thing.  Within the AAA
system, the realm MUST be left as UTF-8.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 23 Oct 2008 08:58:00 -0700

> defines a "normalization form NFC", which could apply here.

I think the issue is *when* the NAI is normalized.  For example is the
RADIUS server expected to do the normalization, or is it the client?  If
the server has the responsibility (or if it can guarantee that the client
is always automatically configured), then client normalization isn't
needed. 

> internationalization (RFC5234), which is "experimental".

That is the closest document, I believe.  While the extensions specified
in the document are experimental, the encoding isn't -- it's been in use
for quite some time. 
 
> > would leave sufficient flexibility for registry-specific restrictions. 

Some references to John Klensin's RFCs on registry behavior would probably
be appropriate. 

> of the realm

What's wierd is that the ABNF actually includes support for UTF-8 characters. 
Last time I looked, this appeared to be supported for *both* the username and
the realm. 
 
> administrator preconfigured?"

One might want to normalize the realm prior to doing the lookup in the
realm table.  But I agree that this paragraph packs a lot of error into
a small space. 
 
> system, the realm MUST be left as UTF-8.

Yes, only when DNS lookups are needed. 

Unfortunately, not *all* DNS libraries do the right thing.  For example,
GetAddrInfoW() currently sends UTF-8 queries on the wire, not punycode. 
On *NIX systems, I've seen applications use libidn to do the conversion
prior to calling name resolution APIs.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 24 Oct 2008 10:55:12 +0200

Bernard Aboba wrote:
> RADIUS server expected to do the normalization, or is it the client?

  I don't think anyone other than the client has access to locale
information.  I think the client must convert the NAI to normalized
UTF-8.  I don't think this is too hard.  It only needs to be done once,
when the user name && realm are entered (or when the locale changes).

> Some references to John Klensin's RFCs on registry behavior would probably

  OK.

> Last time I looked, this appeared to be supported for *both* the

  Nope.  Only for the User-Name, from 4282:

   realm       =  1*( label "." ) label
   label       =  let-dig *(ldh-str)
   ldh-str     =  *( alpha / digit / "-" ) let-dig
   let-dig     =  alpha / digit
   alpha       =  %x41-5A  ; 'A'-'Z'
   alpha       =/ %x61-7A  ; 'a'-'z'
   digit       =  %x30-39  ; '0'-'9'

  Characters with the high bit set are forbidden in realm names.

> realm table.

  Normalize... to what?  How can the intermediate nodes know what
normalization rules to apply?

> prior to calling name resolution APIs.

  Ugh.  I guess this needs to be mentioned, too.

  Alan DeKok.