Subject: Re: [radext] Internationalization in the real world

From: Bernard Aboba <[email-masked]>
Date: Sun, 26 Aug 2012 13:26:36 -0700

The message below was posted on the PRECIS mailing list.  Since the RADEXT
WG has an 

internationalization work item which relates to these issues, I am
responding on this list instead. 

A commonly encountered problem in RADIUS and EAP implementation is a
misunderstanding of the role of the 

RADIUS User-Name attribute, the EAP-Response/Identity and method-specific
identities.   Since these identities

serve different functions, they need not be "equivalent" in any sense. As a
result, comparing these identities is

inherently problematic and will result in bugs that will affect features
such as roaming, anonymity and support 

for some EAP methods.  

RFC 3579 Section 2.1 describes the relationship between the RADIUS User-Name
attribute and the EAP-Response/Identity

at the NAS:

   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.  

However, while the RADIUS User-Name attribute and the EAP-Response/Identity
should be the same in the RADIUS

packet sent by the NAS, proxies can modify the RADIUS User-Name attribute,
so that by the time the RADIUS User-Name

attribute gets to the RADIUS server it can differ from the
EAP-Response/Identity.   As noted in RFC 5113 Section 2.3:

   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.

As a result, a RADIUS server implementation which compares the RADIUS
User-Name attribute and EAP-Response/Identity

cannot support NAI decoration. 

RFC 3748 describes the purpose of the EAP-Response/Identity as distinguished
from the method-specific

identity:

      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.

Since the EAP-Response/Identity is primarily used for routing, it need not
be the same as the

method-specific identity.  For example, EAP Identity Privacy depends on the
ability of the 

EAP-Response/Identity and method-specific identity to be different from each
other.  Also,

individual EAP methods are free to define their own forms for the user
identity, and need

not conform to the NAI format. 

For example, when EAP identity privacy is desired, the EAP-Response/Identity
may contain an 

anonymous  NAI such as "[email-masked]" whereas the method-specific
identity 

would contain the actual user-name, which need not be provided in the form
of an NAI.  

Therefore not only may the two identities not be equivalent, they may not
even be provided in the

same format or encoding. 

As a result, RADIUS/EAP server implementations that compare the
EAP-Response/Identity

and method-specific identities are incapable of supporting identity privacy
and also may not

be able to support all EAP methods. 

========================================

Alan DeKok said:

  One nice effect of i18n issues is the ability to play different

protocols off against each other.  In my area (RADIUS), there are

multiple layers of protocols.  Each layer has the ability to choose

different encodings for the "same" data.

  For 802.1X, this means there's a RADIUS "name", another copy of the

name in EAP, and another copy of the name in MS-CHAP.  For security,

we've required that they're all the same.  The alternative is to allow

conflicting claims for identity.

  Well, that bit me today.  I got the following message from a customer.

---

  The supplicant makes a request the way User-Name and MSCHAP name are

encoded differently. For User-Name it uses UTF-8, while MSCHAP name is

sent in internationalized encoding (e.g. CP-1251 for Russian).  The

strings are clearly different, so the names are rejected as being different.

---

  RFC 2865 (RADIUS) says that the User-Name is UTF-8.  RFC 3748 (EAP)

says that the identity should be UTF-8.  RFC 2433 (MS-CHAP) is silent on

the encoding of the name field.  The given example is (of course) ASCII.

RFC 2759 (MSCHAPv2) says explicitly that the name is ASCII.

  I find it worrying that different encodings are used by the same

software.  This kind of thing makes it nearly impossible for the other

side of the protocol to do *anything* sane with the data.

  The kicker (of course) is that the MS-CHAP name is sent as CP-1251.

Different countries will use different encodings, all of which are

incompatible.  And there's no provision in MS-CHAP for telling the other

end which encoding is being used.

  Does anyone have a good suggestion for what to do here?

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 27 Aug 2012 11:31:26 +0200

Bernard Aboba wrote:
> RADIUS User-Name attribute, the EAP-Response/Identity and
> method-specific identities.   Since these identities
> serve different functions, they need not be "equivalent" in any sense.
> As a result, comparing these identities is
> such as roaming, anonymity and support for some EAP methods.  

  The issue I have with that is knowing *who* is being authenticated?
The ability to claim different, unrelated identities in the *same*
transaction seems to be a security vulnerability.

  Many security attacks involve untracked differences in protocols.
i.e. the protocols expect consistency but don't validate it.  The wily
attacker can leverage this lack of validation by presenting inconsistent
data.

> cannot support NAI decoration.

  Exactly.   Experience with WiFi roaming and 3G roaming (EAP-SIM) shows
that User-Name decoration and mangling is *not* done for EAP.

> Since the EAP-Response/Identity is primarily used for routing, it need
> not be the same as the 
> method-specific identity.  For example, EAP Identity Privacy depends on
> the ability of the 
> EAP-Response/Identity and method-specific identity to be different from
> each other.  Also,

  Sure.  The question then becomes what does the identity *mean*.  What
happens when one authentication session claims multiple identities?

> For example, when EAP identity privacy is desired, the
> EAP-Response/Identity may contain an
> anonymous  NAI such as "[email-masked]" whereas the
> method-specific identity
> would contain the actual user-name, which need not be provided in the
> form of an NAI. 

  The context of the original question was PEAP.  In it, we have 3
identities:

- outer EAP identity.  Usually "[email-masked]"
- inner EAP identity.  Most often the "[email-masked]"
- EAP method identity: ???

  It's OK for the outer identity to be anonymous, and of a different
form from the inner identity.  As you said, the outer identity is only
used for routing.

  The inner identity is *not* used for routing.  It can be different
from the outer one. e.g. [email-masked] versus [email-masked].
 These differences can be used to perform certain kinds of attacks.

  FreeRADIUS has specific checks for these attacks.  Many other servers
do not, for various reasons.

> Therefore not only may the two identities not be equivalent, they may
> not even be provided in the same format or encoding.

  i.e. the two inner identities.

  And not the outer / inner identities.  The two EAP identities are both
EAP, which means UTF-8.  Having different encodings would be madness.

> and method-specific identities are incapable of supporting identity
> privacy and also may not

  I disagree with the statement "incapable of support identity privacy".
 The issue here is comparing the two inner identities.  It is unrelated
to the outer anonymous identity.

  RADIUS/EAP servers *do* check inner identities.  In a roaming
scenario, the outer User-Name is used to route a request to a home
server.  This home server checks that the realm in the request matches
realms it is authoritative for.  Where NAI decoration is forbidden (as
noted above), it can also check that the User-Name matches the
EAP-Identity.  Both are UTF-8, and compliant AP implementations should
copy the EAP-Identity to the RADIUS User-Name.

  A RADIUS/EAP server also looks at the inner EAP-Identity.  This is
either a just a user name, or has a user@realm form.  NAI decorations
and mangling are impossible, as the inner identity is protected by a TLS
tunnel.  Where a realm exists, the server checks that the realm matches
a realm it is authoritative for.

  It *may* also check that the inner realm matches the outer realm.
Having them different could be cause for concern.  But generally this
doesn't seem to be done.

  The sticking point is what to do with the inner EAP-Identity and the
EAP method identity.  IIRC, the checks for identity were put into
FreeRADIUS because of experience in the field.  Attackers were putting
different information in the two fields.  The goal was apparently to
perform attacks on the inner tunnel by replaying old MS-CHAP data.

  I see the point that the two inner identities don't have to match.  I
would like a large discussion around the security implications of
allowing them to be *completely* different.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 27 Aug 2012 14:34:29 +0200

The short version:

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Aug 2012 11:29:02 -0700

The following cases were mentioned in the longer message:

a. Differences between the RADIUS User-Name and the EAP-Response/Identity
b. Differences in realm between the RADIUS User-Name and the method-specific identity. 
c. Differences between method-specific identities (e.g., within a tunneling protocol)

With respect to a), there are potential transformations that can occur in the RADIUS User-Name
attribute other than just removal of "decoration".  For example, a proxy within an enterprise could look up
the username and then adjust the realm.  For example, [email-masked] could be expanded to 
[email-masked].  Given this, I believe that it makes sense to have the RADIUS server 
examine the User-Name attribute to make sure that it is authoritative for the realm, but if proxies can
be adjusting the realm names, it should not necessarily to expect the realm to be 
identical to that in the EAP-Response/Identity. 

With respect to b, it is possible that the method-specific identity can take a different form.  For example,
when I connect to the corpnet, "[email-masked]" could be used within the RADIUS User-Name, while
"redmond\bernarda" may be used in MS-CHAP.   

With respect to c,  if multiple authentications are done within a tunnel method, then this does raise the question

of what identity is associated with the produced keys.  RFC 5247 Section 1.4 does note that the "Peer-Id" could have multiple

values, and Section 2.4  states:

   It is possible for more than one Peer-Id to be exported by an EAP
   method.  For example, a peer certificate can contain more than one
   peer identity; in a tunnel method, peer identities can be
   authenticated within both an outer and inner exchange, and these
   identities could be different in type and contents.  For example, an
   outer exchange could provide a Peer-Id in the form of a Relative
   Distinguished Name (RDN), whereas an inner exchange could identify
   the peer via its NAI or MAC address.  Where EAP keying material is
   determined solely from the outer exchange, only the outer Peer-Id(s)
   are exported; where the EAP keying material is determined from both
   the inner and outer exchanges, then both the inner and outer
   Peer-Id(s) are exported by the tunnel method.

> Date: Mon, 27 Aug 2012 14:34:29 +0200
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: [radext] Internationalization in the real world
> 
>   The short version:
> 
> Alan DeKok wrote:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Tue, 28 Aug 2012 09:57:41 +0200

Bernard Aboba wrote:
> [email-masked].

  I don't see much evidence of that happening in practice.  And if it
did, it's an internal decision, and doesn't affect the wider net.

>  Given this, I believe that it makes sense
> to have the RADIUS server

  That's a SHOULD NOT be treated as identical, I think.  But again in
practice, I see few situations where they are different.

  Checking for them being identical is a security decision taken by the
home server.  When they are different, the home server has *no way* of
knowing if the differences are because of proxies re-writing the data,
or because an attacker is gaming the system.

  That is the crux of the problem for me.

> "redmond\bernarda" may be used in MS-CHAP.  

  Yes.  Again, how does this affect security?  That example seems to be
OK.  What about "[email-masked]" in EAP, and then "redmond\bernarda"
for MS-CHAP?

  This is allowing one authentication session to claim multiple
credentials.  The only secure way to allow that practice is
cryptographic binding.  i.e. both identities claim knowledge of each
other in a provable way.

> With respect to c,  if multiple authentications are done within a tunnel
> method, then this does raise the question
> of what identity is associated with the produced keys.  RFC 5247 Section
> 1.4 does note that the "Peer-Id" could have multiple

  But it's silent on the subject of security.  And what does it *mean*
when one authentication session has two different identities being
claimed?  Are the identities related?  Unrelated?  Replays?

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 28 Aug 2012 09:33:51 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   This is allowing one authentication session to claim
    Alan> multiple credentials.  The only secure way to allow that
    Alan> practice is cryptographic binding.  i.e. both identities claim
    Alan> knowledge of each other in a provable way.

Actually, though, you're not claiming multiple credentials, only using
multiple identities, only one of which is authenticated.

The way I think about this is that the RADIUS server should act on the
identity it actually authenticates--the method identity for most
methods.  If the RADIUS server discloses no user-name attribute, in the
response, the RADIUS server is not claiming which identity is
authenticated to any other party.  A party assuming without policy
knowledge that the user-name that was sent has any connection to what
was authenticated is foolish.

If the RADIUS server discloses a user-name attribute it's making an
assertion that it has mapped whatever identity it authenticated to that
name.

Obviously there are ways to mis-implement this.
A RADIUS server needs to confirm that the method identity maps to the
username (or even better internally rewrite the username) before doing
any authorization on it.

I agree with bernard that thinking about this in terms of mapping rather
than multiple credentials makes more sense.
Identity mapping  tends to be fairly common in a lot of deployments and
is something we should take into account.
I suspect it will become more common with RADIUS.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 28 Aug 2012 16:24:38 +0200

> multiple identities, only one of which is authenticated.

  Then I'm left wondering why the other identities exist.

  We can't ignore the other identities completely.  In some cases, the
EAP identity is used to find the users credentials.  We then use those
credentials to authenticate a *completely different* identity.

  How many security systems have that property?  User "bob" logs in, but
we check his password against the password for user "doug".  It's
ridiculous.

  Going back to the original example, the users "name" was UTF-8 in one
protocol, and CP-1251 in another.  What do you do when the backend
credential system indexes users via UTF-8?

  Say you use the CP-1251 form to look up the users credentials in the
DB.  Do you use "inconv" to convert it to UTF-8?  And *hope* that you
know the character encoding?

  What do you do if some users are CP-1251, and other use ISO 8859-5?
You're pretty much SOL.

> methods.

  But you can't separate identity from credentials.  And if you have two
identities, which one do you use for credential lookups?  Why?

> username (or even better internally rewrite the username) before doing

  Sure.  That's done already in many places.  But how does it do
rewriting of usernames if it doesn't know the character encoding?

  The solution in practice seems to be (a) use UTF-8 everywhere, or (b)
use whatever magic encoding you want and NOTHING ELSE.

> I suspect it will become more common with RADIUS.

  If you don't know the character encoding, you can't really do identity
mapping.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 28 Aug 2012 12:07:51 -0400

Alan> Sam Hartman wrote:
    >> Actually, though, you're not claiming multiple credentials, only
    >> using multiple identities, only one of which is authenticated.

    Alan>   Then I'm left wondering why the other identities exist.

Well, in RADIUS, generally for two reasons:

1)  because one of them is really a routing identity and the user
portion will get ignored.

2) Because some inner methods have crappy method identities and you
really do need the outer identity in some situations.

In broader systems including RADIUS this tends to come up when some of
your credentials have identifiers that really aren't very
convenient. Examples include  smart cards and X.509 credentials.

    Alan>   We can't ignore the other identities completely.  In some
    Alan> cases, the EAP identity is used to find the users credentials.
    Alan> We then use those credentials to authenticate a *completely
    Alan> different* identity.

    Alan>   How many security systems have that property?  User "bob"
    Alan> logs in, but we check his password against the password for
    Alan> user "doug".  It's ridiculous.

Kerberos has very similar properties.  For example with RFc 4556, you
can use the c=US,o=Somecompany,sn=2309921abe credential to log into
[email-masked].
The KDC is responsible for deciding that mapping is appropriate.
The rest of the Kerberos system uses the [email-masked]
identity unless it's even more complicated and it uses SIDs in a PAC in
a ticket.
With the Kerberos OTP spec we have similar issues sometimes.

You see similar issues between the form of authentication identities and
authorization identities in SASL.

so, actually I think this problem is relatively common.

---

From: Avi Lior <[email-masked]>
Date: Tue, 28 Aug 2012 15:30:42 -0400

Probably already mentioned but…

As  I see things….

When EAP is being used the RADIUS server does not authenticate the user, the EAP server authenticates the user using the appropriate EAP identities and probably not the User Name attribute.

The problem comes with the authorization part.  The EAP server does not provide the authorization attributes the RADIUS server does.  What identity is used by the RADIUS server to fetch the authorization attributes?

There is no "formal" binding between the RADIUS identity (used to fetch the authorization attributes) and the EAP Identity used to authenticate the user.  

In tightly coupled scenarios where the RADIUS Server and the EAP Server are the "same" (collocated or owned by the same administrative domains) then this is not a problem.  Or when the identities used by the each (RADIUS and EAP) are somehow bound, then we are okay.

Where the EAP Server and RADIUS server is decoupled then we are missing some guidelines around how to "match" the identities

On the otherhand I don't think anything is busted.  The issues as summarized by Bernard are well understood and documented.  If a RADIUS server was to compare the identity in the Username with the identity in the EAP Identity it would have to "de-decorate" the EAP Identity payload - that may not always work because some User-Name decoration go beyond just routing decoration.    

It is very hard to implement a generic RADIUS server that will support all deployment scenarios.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Aug 2012 13:40:27 -0700

Alan said:

"How many security systems have that property?"

[BA]  Some of the same issues arise in application-layer protocols including
SMTP and SIP. 

For example, in SIP we have the From: field, the identity used in Digest
Authentication, the P-Asserted-Identity, the identities used in media
authentication (e.g., DTLS/SRTP), etc. 

Each of these identities has a slightly different purpose and meaning.  For
example, in third-party call control, the party that is originating the call
(included in the From: field) may not end up being one of the parties
exchanging media.  Also, the identity used with the SIP service provider
account (used in Digest Authentication) may not be the same identity that is
placed in the From: field or the P-Asserted-Identity, because a single SIP
service provider account could be used to route outbound calls from multiple
phone numbers. 

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2012 7:25 AM
To: Sam Hartman
Cc: Bernard Aboba; [email-masked]
Subject: Re: [radext] Internationalization in the real world

  We can't ignore the other identities completely.  In some cases, the EAP
identity is used to find the users credentials.  We then use those
credentials to authenticate a *completely different* identity.

  How many security systems have that property?  User "bob" logs in, but we
check his password against the password for user "doug".  It's ridiculous.

  Say you use the CP-1251 form to look up the users credentials in the DB.
Do you use "inconv" to convert it to UTF-8?  And *hope* that you know the
character encoding?

> username (or even better internally rewrite the username) before doing 

  Sure.  That's done already in many places.  But how does it do rewriting
of usernames if it doesn't know the character encoding?

  The solution in practice seems to be (a) use UTF-8 everywhere, or (b) use
whatever magic encoding you want and NOTHING ELSE.

> I agree with bernard that thinking about this in terms of mapping 
> rather than multiple credentials makes more sense.
> Identity mapping  tends to be fairly common in a lot of deployments 
> and is something we should take into account.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 28 Aug 2012 23:22:17 +0200

> portion will get ignored.

  Except that's the *outer* identity for the TLS-enabled EAP methods.
I'm already clear that it doesn't matter much.

> really do need the outer identity in some situations.

  I'm still not sure we're all talking about the same thing.

  There are the following identities in PEAP / MS-CHAPv2:

- outer RADIUS User-Name
- outer EAP identity.  (usually similar to the outer User-Name)
- inner EAP identity
- inner method-specific EAP identification

  They can all be substantially different.  If there are no requirements
that they be in any way related... OK.  I guess it means that RADIUS
systems can't really offer much security against certain attacks.

> convenient. Examples include  smart cards and X.509 credentials.

  Yes.

> so, actually I think this problem is relatively common.

  It seems then that the recommended approach is to ignore the issue of
inconsistencies.  Oh well.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 28 Aug 2012 23:25:01 +0200

> The problem comes with the authorization part.  The EAP server does not provide the authorization attributes the RADIUS server does.  What identity is used by the RADIUS server to fetch the authori…

  Exactly.

> In tightly coupled scenarios where the RADIUS Server and the EAP Server are the "same" (collocated or owned by the same administrative domains) then this is not a problem.  Or when the identities u…

  It can still be a problem with the identities are different.  "bob"
authenticates, but gets "doug's" authorization credentials.

  That concerns me.

> Where the EAP Server and RADIUS server is decoupled then we are missing some guidelines around how to "match" the identities

  The same issue applies when they're tightly coupled.

> On the otherhand I don't think anything is busted.  The issues as summarized by Bernard are well understood and documented.  If a RADIUS server was to compare the identity in the Username with the…

  OK.  So the solution really is to ignore it.

> It is very hard to implement a generic RADIUS server that will support all deployment scenarios.

  Oh, yes.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 28 Aug 2012 19:31:18 -0400

Alan> Avi Lior wrote:
    >> When EAP is being used the RADIUS server does not authenticate
    >> the user, the EAP server authenticates the user using the
    >> appropriate EAP identities and probably not the User Name
    >> attribute.
    >> 
    >> The problem comes with the authorization part.  The EAP server
    >> does not provide the authorization attributes the RADIUS server
    >> does.  What identity is used by the RADIUS server to fetch the
    >> authorization attributes?

    Alan>   Exactly.

I would expect that as part of defining how a losely bound EAP server
interacts with an AAA server you'd need to define how the EAP server
passed back the method identity, just as how  you'd need to pass forward
(or back) i1/i2 for EAP channel binding.

The reality is that  the interface between EAP server and RADIUS server
has gotten and is continuing to get more complex over the years and more
authorization is required from the EAP server.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 29 Aug 2012 08:54:23 +0200

> (or back) i1/i2 for EAP channel binding.

  That would be wonderful.

  There's still an issue about encoding, though.  Say EAP-MS-CHAPv2
passes a CP-1251 blob back to the RADIUS server.  What does the RADIUS
server do with it?

> authorization is required from the EAP server.

  Which is why I'd like to get these problems worked out now.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 29 Aug 2012 14:51:30 +0200

Sam Hartman wrote:
> Seriously, I don't think there is general advice we can give here.  I
> can give you advice for Active Directory (although even that is not
> perfect). I can give you advice for Redhat Linux especially if you're
> using their directory product.  General advice? Haven't found it for
> Kerberos or SASL yet either.

  I'd like consensus such as "use UTF-8 instead of random encoding
schemse".  That wouldn't solve the problem.  But it would mean that the
problem becomes more solvable.

> One possible start is to configure what character set you expect if it's
> not UTF-8.  Convert from that and then do a normalization-insensitive
> fuzzy search against your database.  Hope for at most one match; become
> very sad if you get more than one.  Even this assumes you can do a
> normalization insensitive search.

  Exactly.  Or give up and run away screaming.  It's what I do with most
i18n issues.

> I guess there are areas where we can focus effort.
> One is to figure out whether when communicating method identitifiers we
> want to convert to UTF-8 before sending back over RADIUS or whether we
> want to keep unmodified as long as possible.
> We may have (probably do for things like MS-CHAP) better knowledge about
> what's going on in the method and thus may be able to do a better
> conversion.
> OTOH, if we don't convert we have more options with the
> comparison/search when do the database lookup.

  Both are pretty nasty options.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Wed, 29 Aug 2012 10:50:34 -0400

> authenticates, but gets "doug's" authorization credentials.
Not in a tightly coupled implementation where the EAP Server is in the AAA server.  You would think that a properly coded AAA server would know exactly which identity was authenticated.  It would not get Doug's authorization credentials when Bob is authenticated - unless of course bob is Doug.

>  That concerns me.
It would concern me as well and I would want my money back from the AAA vendor.

>  The same issue applies when they're tightly coupled.
No - I don't agree.  Please explain why in a tightly coupled case the AAA server would get it wrong or be confused?

>  OK.  So the solution really is to ignore it.

I think what possibly needs fixing or work is the loosely coupled case where the EAP-Server needs to communicate to the RADIUS Server what was authenticated so that the RADIUS server can deliver the correct authorization attributes.  The interface between these entities is not defined.

I am not aware of any implementations/SDO standards where  the EAP Server and AAA is decoupled - so perhaps we don't need to define this interface.

---

From: Avi Lior <[email-masked]>
Date: Wed, 29 Aug 2012 10:54:32 -0400

I

> authorization is required from the EAP server.

I agree with the complexity - but I am not aware of any deployments/implementation where the two are decoupled.