Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01

From: <[email-masked]>
Date: Mon, 20 Jul 2015 09:13:48 +0000

Hi,

During this "call for adoption" period, a lot of support was received and it was considered that it is an important work to move forward. The only remaining issue was to ensure that RADEXT was the best place for such activity, as it is not strictly in the remit of RADEXT. So the result was somehow dependent on the adoption of the new RADEXT charter, in which the objective to work on the encoding of the EAP identities was included. It was the opportunity for IETF people to raise concerns about doing this work in RADEXT, that was not the case.

The new charter was approved two weeks ago and I think that it is now OK to adopt this document as working group document. A mail was also sent to other interested WGs (DIME, EMU, EAP) to make them aware of this work in RADEXT.
We will discuss this point during the RADEXT session this afternoon and we will later confirm the adoption on the mailing list.

Regards,

Lionel 

-----Message d'origine-----
De : Alan DeKok [mailto:[email-masked]] 
Envoyé : mercredi 1 avril 2015 14:04
À : MORAND Lionel IMT/OLN
Cc : Aboba Bernard; Sam Hartman; [email-masked]; [email-masked]
Objet : Re: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01

On Apr 1, 2015, at 5:30 AM, <[email-masked]> <[email-masked]> wrote:
> Adopting this work will mean adopting the new charter that will be anyway discussed at the AD/IESG level. Along this process, we will notify DIME, EMU and EAP mailing lists to let them know that we are working on this issue and they will be invited to comment the document on RADEXT mailing list and during RADEXT sessions. If there is any concern raised during this process, we will manage it at this stage.
> 
> Does it sound acceptable for everyone?

  I'm OK with that.

  Alan DeKok.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Jul 2015 04:12:40 -0700

One of the fundamental assumptions of this document is that the EAP-Response/Identity is somehow determined from the method-specific identities.  This is not correct, as RFC 3748 Section 5.1 makes clear: 
 
      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.
 
The above text makes it clear that the EAP-Response/Identity and method-specific Identities used within individual EAP methods are separate and distinct.  The method-specific identities need not be in NAI format, or encoded in UTF-8.  Therefore attempts to convert them to NAI format can frequently fail.  Also, the EAP-Response/Identity is frequently anonymous and is used to prevent a snooping attacker from obtaining the method-specific identities, which are typically encrypted.  For this reason and others described below, it is not advisable for EAP implementations to determine the EAP-Response/Identity based on the method-specific identities. 
 
Most EAP methods created subsequent to RFC 3748 have incorporated their own Identity Exchanges, and those methods are therefore not influenced by the EAP-Response/Identity.   Since the EAP-Response/Identity is distinct from the method-specific identity, the recommendations of Section 4 will not have an effect on EAP authentication, other than perhaps forcing the selection of a different EAP server:   
 
   If an EAP authentication gets rejected, the EAP peer SHOULD re-try the authentication using a
   different EAP-Response/Identity than before.  The EAP peer SHOULD try
   all user identifiers from the entire set of configured EAP types
   before declaring final authentication failure.
 
The advice has a number of major downsides.  Since most authentication failures will be due to mistyping the password, responding to an authentication failure by retrying all conceivable user identities will lead to major delays and very high levels of user annoyance.  By responding to an authentication failure by trying method-specific identities, implementations would divulge identity information that was designed to be kept secret, compromising privacy. Also, an implementation following this advice would utilize method-specific identities that may not be in the appropriate format or character encoding for an EAP-Response/Identity.  
 
   EAP peers need to maintain state on the encoding of the user
   identifiers which are used in their locally configured EAP types.
   When constructing an EAP-Response/Identity from that user identifier,
   they MUST (re-)encode that user identifier as UTF-8 and use the
   resulting value for the EAP-Response/Identity.  If the EAP type is
   configured for the use of anonymous outer identities, the desired
   outer identity MUST also be (re-)encoded in UTF-8 encoding before
   being put into the EAP-Response/Identity.
 
Since RFC 3748 makes it clear that the EAP-Response/Identity is not related to the method-specific identity, constructing the EAP-Response/Identity from the method-specific one is inadvisable.   The re-encoding described above may not be possible for a variety of reasons, including the fact that the method-specific identity need not be in NAI form at all.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Jul 2015 07:29:48 -0400

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:

    Bernard>    One of the fundamental assumptions of this document is
    Bernard> that the EAP-Response/Identity is somehow determined from
    Bernard> the method-specific identities.  This is not correct, as
    Bernard> RFC 3748 Section 5.1 makes clear:

Hi.  I was very confused to read this paragraph, because we've discussed
this issue several times and I think we're all in agreement that the
method-specific identities are not directly related to the eap
response/identity.  I think that as the text you cite from RFC 3748
points out, the EAP response is often used for routing, so in many
deployments there is some relation.

I stopped reading your review after this first paragraph, because I
think that this disconnect colors the entire review.  I'd really
appreciate it if you would explain why you think the document is
assuming that the eap-response/identity is determined from method
identities.
I know that was not our intent.

I do think it's true that implementations sometimes derive both the eap
response/identity and the method-specific identities from a common
principal.
Other implementations request both identities from the user.
However, I don't know anything that tries to map back from a method
identity to an eap response.

--Sam

---

From: <[email-masked]>
Date: Mon, 20 Jul 2015 12:06:15 +0000

Hi Bernard,

I tend to agree with Sam. I will review again the draft based on your comment. However I understand that the point is WHEN "Identity Response be used primarily for routing purposes ", there is some considerations to take into account to use it as user-name identity in RADIUS and Diameter. Everything else related to method-specific EAP identity (format, use, etc.) is out of scope of this document. At least it is my current understanding.

Lionel

-----Message d'origine-----
De : radext [mailto:[email-masked]] De la part de Sam Hartman
Envoyé : lundi 20 juillet 2015 13:30
À : Bernard Aboba
Cc : [email-masked]
Objet : Re: [radext] Review of draft-winter-radext-populating-eapidentity-01

Hi.  I was very confused to read this paragraph, because we've discussed this issue several times and I think we're all in agreement that the method-specific identities are not directly related to the eap response/identity.  I think that as the text you cite from RFC 3748 points out, the EAP response is often used for routing, so in many deployments there is some relation.

I stopped reading your review after this first paragraph, because I think that this disconnect colors the entire review.  I'd really appreciate it if you would explain why you think the document is assuming that the eap-response/identity is determined from method identities.
I know that was not our intent.

I do think it's true that implementations sometimes derive both the eap response/identity and the method-specific identities from a common principal.
Other implementations request both identities from the user.
However, I don't know anything that tries to map back from a method identity to an eap response.

--Sam

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Jul 2015 14:16:31 +0200

The point is that the document's recommendations are based on using method specific identities to determine the EAP-Response/Identity. This is fundamentally broken because those identities are unrelated and the two identities  need not use the same formats or encodings - and as a result the advice based on this incorrect assumption would result in authentication failures, unacceptable delays and worse.

The document itself points this out - but does not recognize that the problem itself results from a false assumption.

> On Jul 20, 2015, at 14:06, [email-masked] wrote:
> 
> Hi Bernard,
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Jul 2015 14:23:21 +0200

On Jul 20, 2015, at 13:29, Sam Hartman <[email-masked]> wrote:

> I stopped reading your review after this first paragraph,
 
[BA] If you had read further you would have learned the specific paragraphs in Section 4 that direct the EAP-Response/Identity to be determined from the method specific ones.

Your loss.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Jul 2015 08:24:57 -0400

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:

    Bernard> The point is that the document's recommendations are based
    Bernard> on using method specific identities to determine the
    Bernard> EAP-Response/Identity. This is fundamentally broken because
    Bernard> those identities are unrelated and the two identities need
    Bernard> not use the same formats or encodings - and as a result the
    Bernard> advice based on this incorrect assumption would result in
    Bernard> authentication failures, unacceptable delays and worse.

Bernard, at this point  I'm getting somewhat frustrated, because you're
repeating yourself.
Asserting the same thing doesn't make it true.
Your understanding of the document differs from mine.
Repeating your understanding of the document will not convince me you
are right.
Instead, I'm asking you to quote the sections of the document you
believe are based on this.

--Sam

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Jul 2015 14:33:58 +0200

> identity to an eap response.

[BA] Neither do I - it's a bad idea.  That's why Section 4's advice seems so strange:

[BA] "all user identities" appears to imply using method-specific identities to construct the EAP-Response/Identity.

[BA] Again, this seems to imply using method-specific identities to construct the EAP-Response/Identity.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Jul 2015 08:38:50 -0400

>> method identity to an eap response.

    Bernard> [BA] Neither do I - it's a bad idea.  That's why Section
    Bernard> 4's advice seems so strange:

    Bernard>     If an EAP authentication gets rejected, the EAP peer
    Bernard> SHOULD re-try the authentication using a different
    Bernard> EAP-Response/Identity than before.  The EAP peer SHOULD try
    Bernard> all user identifiers from the entire set of configured EAP
    Bernard> types before declaring final authentication failure.

    Bernard> [BA] "all user identities" appears to imply using
    Bernard> method-specific identities to construct the
    Bernard> EAP-Response/Identity.

Ah, that's not how I read it at all.
I read that as saying that you try all the identities you have.
If you're an implementation that stores outer identities separately from
inner identities, then try all your outer identities.
If you're an implementation that maps both from a common principal, do
that for all your principals.

    Bernard>    EAP peers need to maintain state on the encoding of the
    Bernard> user identifiers which are used in their locally configured
    Bernard> EAP types.  When constructing an EAP-Response/Identity from
    Bernard> that user identifier,

    Bernard> [BA] Again, this seems to imply using method-specific
    Bernard> identities to construct the EAP-Response/Identity.

I see what you're saying now.
I think what the text is trying to talk about there is constructing both
from some common principal/idea about an account.  However it could be
read as constructing one from another.
And also, it doesn't deal as well with the case where they are separate.

---

From: <[email-masked]>
Date: Mon, 20 Jul 2015 12:39:07 +0000

Hi bernard,

after a quick review, I think I understand your concerns.
I really think that the point is not to make any assumption on the method-specific ID that could be used in EAP-Response.
I think we can update the text to make it clear.

To sum-up, I would say that the intention of the draft is to:

- clarify that the EAP-Response can be used for routing
- When it is the case, two consequences:
    -  it may be needed to use different ids to reach different EAp servers, when a single EAP server cannot be used to support all the methods supported by the peer.
    - a specific encoding of the id encapsulated in the EAP-Response is required to ensure a correct use over RADIUS/Diameter

Do we agree?

Lionel

-----Message d'origine-----
De : Bernard Aboba [mailto:[email-masked]] 
Envoyé : lundi 20 juillet 2015 14:17
À : MORAND Lionel IMT/OLN
Cc : Sam Hartman; [email-masked]
Objet : Re: [radext] Review of draft-winter-radext-populating-eapidentity-01

> Envoyé : lundi 20 juillet 2015 13:30 À : Bernard Aboba Cc : 
> [email-masked] Objet : Re: [radext] Review of 
> draft-winter-radext-populating-eapidentity-01
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Jul 2015 14:57:47 +0200

> after a quick review, I think I understand your concerns.

[BA] Thanks. 

> I really think that the point is not to make any assumption on the method-specific ID that could be used in EAP-Response.

[BA] Right. The method-specific identity might be in a different format that is not convertible to an NAI (REDMOND\bernarda versus [email-masked]). It might be in a different encoding (e.g. Not UTF-8).  The method-specific ID could identify the user while the EAP-Response/Identity might be anonymous. So you can't assume the method-specific ID is a valid NAI suitable for the EAP-Response/Identity or even can be transformed into one.

>    - a specific encoding of the id encapsulated in the EAP-Response is required to ensure a correct use over RADIUS/Diameter

[BA] Those things make sense. You can also point out the bad things that can happen by using method-specific identities in the EAP-Response/Identity (if that is something implementations have gotten into trouble with). 

One other potential relevant point is how RADIUS servers are configured to deal with realms they aren't configured to natively handle. Most of the time those realms are rejected but sometimes the RADIUS server can proxy.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 21 Jul 2015 21:22:00 +0200

Hi,

> that for all your principals.

Thanks both for taking this thread so far - now I see the shortcomings
in my formulation.

FWIW, the intention of the wording was Sam's POV and I will re-phrase it
to be clearer.

> And also, it doesn't deal as well with the case where they are separate.

I had a specific example in my head when thinking about this, it's a
Redmond one :-)

The Win 7 PEAP config allows to configure the method inner identity.
There's also a separate place for the outer identity.
However: you can't type a NAI realm in the outer ID box, only a non-NAI
string.

What happens when you type "anonymous" as outer ID, and
"[email-masked]" as the inner ID, is that the supplicant will send an
EAP-Response/Identity of "[email-masked]".

Just like Bernard says, yes, this is using (parts of) a method-specific
(inner) identity to construct the EAP-Response/Identity.

That is, the config options for inner vs. outer are different, yet
related. The supplicant blends two different config items into one
resulting string. Hopefully, both are in the same encoding, and
hopefully, the encoding is UTF-8. If not, both parts of it need to be
converted to a common encoding before concat'ing them, and the result be
converted to UTF-8 before sending.

Source: MSDN EAP Team Blog
http://blogs.msdn.com/b/eapteam/archive/2009/01/16/peap-identity-privacy-support-in-windows7.aspx

The draft's intention is exactly to move implementations towards UTF-8
for the EAP-Response/Identity *no matter where they take the string
from, be it from an inner identity, explicit configuration of an outer
identity, or a blend of the two*. It is not the intention to spill inner
identities to EAP-Response/Identity if an outer identity is configured.

Greetings,

Stefan Winter

---

From: Stefan Winter <[email-masked]>
Date: Tue, 21 Jul 2015 21:34:55 +0200

Hi,

croping to the remaining bits...

> Also, the EAP-Response/Identity is frequently anonymous and is used
> to prevent a snooping attacker from obtaining the method-specific
> identities, which are typically encrypted.  For this reason and others
> described below, it is not advisable for EAP implementations to
> determine the EAP-Response/Identity based on the method-specific
> identities.

And yet, this is what pretty much every supplicant I've seen does.
Inner ID: [email-masked]
Outer ID: (not configured)
EAP-Response/Identity: [email-masked]

(again, an example: this is what Windows 7 does if you do not configure
Identity Privacy)

That may be a bad idea (but what's the alternative? Bail out with
"config error, need outer ID"?). The draft does not take any position on
whether that's a good or bad thing to do. It merely states that if an
implementation does that, it needs to be cautious to convert the inner
ID to UTF-8 before sending at as outer ID.

> Most EAP methods created subsequent to RFC 3748 have incorporated
> their own Identity Exchanges, and those methods are therefore not
> influenced by the EAP-Response/Identity.   Since the
> EAP-Response/Identity is distinct from the method-specific identity,
> the recommendations of Section 4 will not have an effect on EAP
> authentication, other than perhaps forcing the selection of a
> different EAP server:  
>  

>  The advice has a number of major downsides.  Since most
> authentication failures will be due to mistyping the password,
> responding to an authentication failure by retrying all conceivable
> user identities will lead to major delays

... in the order of magnitude of several hundred milliseconds ...
> and very high levels of user annoyance.
... or user joy and happiness, if going that extra mile turned a DoS
into a successful authentication.

> By responding to an authentication failure by trying method-specific
> identities, implementations would divulge identity information that
> was designed to be kept secret, compromising privacy. Also, an
> implementation following this advice would utilize method-specific
> identities that may not be in the appropriate format or character
> encoding for an EAP-Response/Identity. 

That's exactly why the draft states that a conversion to UTF-8 needs to
be done before sending as EAP-Response/Identity. True, if the format is
not what is needed on the routing level, the authentication still won't
succeed. However, in the absence of an actual outer ID config, there's
nothing an RFC can do to fix this; the user needs to fix his config then.

>  Since RFC 3748 makes it clear that the EAP-Response/Identity is not
> related to the method-specific identity, constructing the
> EAP-Response/Identity from the method-specific one is inadvisable.  
> The re-encoding described above may not be possible for a variety of
> reasons, including the fact that the method-specific identity need not
> be in NAI form at all. 

Encoding (as in: to UTF-8) should always be possible (the EAP peer
hopefully knows the original encoding). Again, if the resulting string
is not a NAI but a NAI would be needed to route the authentication -
time to give up.

Greetings,

Stefan Winter

---

From: Stefan Winter <[email-masked]>
Date: Tue, 21 Jul 2015 21:38:42 +0200

Hi,

> The document itself points this out - but does not recognize that the problem itself results from a false assumption.

The "assumption" comes from observing the implemented reality of a vast
multitude of supplicants, be those fundamentally broken or not. Since
we're aiming at a BCP document, I think we should take reality into account.

Greetings,

Stefan Winter

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Jul 2015 00:54:59 +0200

> EAP-Response/Identity of "[email-masked]".

[BA] That is bad behavior for sure in both cases. 

> hopefully, the encoding is UTF-8.

[BA] As they say, "hope is not a strategy". 

> from,

[BA] that is a fine goal, well supported by RFC 3748.

> be it from an inner identity, explicit configuration of an outer

[BA] Blending the two does not seem like a practice to be encouraged, nor do I recall any one else doing something like that. So pointing at out the potential ill effects as well as the right thing to do seems appropriate.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Jul 2015 01:11:18 +0200

On Jul 21, 2015, at 21:35, Stefan Winter <[email-masked]> wrote:
> (again, an example: this is what Windows 7 does if you do not configure Identity Privacy)
> 
> That may be a bad idea (but what's the alternative?

[BA] One thought might be to configure identity privacy by default both on clients and RADIUS servers. Now that we are more privacy aware, why not try to move things in this direction? 

> True, if the format is not what is needed on the routing level, the authentication still won't succeed. However, in the absence of an actual outer ID config, there's nothing an RFC can do to fix this; the user needs to fix his config then.

[BA] Having valid outer config would help too. 

> Encoding (as in: to UTF-8) should always be possible (the EAP peer hopefully knows the original encoding). Again, if the resulting string is not a NAI but a NAI would be needed to route the authentication - time to give up.

[BA] The EAP implementation needs to provide an NAI for the outer identity because the standard requires it. No need to sugar code it - not doing so is broken.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2015 05:21:06 -0400

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:

    Bernard>    [BA] Having valid outer config would help too.

    Bernard>      Encoding (as in: to UTF-8) should always be possible
    Bernard> (the EAP peer hopefully knows the original
    Bernard> encoding). Again, if the resulting string is not a NAI but
    Bernard> a NAI would be needed to route the authentication - time to
    Bernard> give up.

    Bernard>    [BA] The EAP implementation needs to provide an NAI for
    Bernard> the outer identity because the standard requires it. No
    Bernard> need to sugar code it - not doing so is broken.
    Bernard> _______________________________________________ radext
    Bernard> mailing list [email-masked]
    Bernard> https://www.ietf.org/mailman/listinfo/radext

I agree that the implementation MUST provide an outer identity.
I do want to permit mapping from some common idea of an account.
Especially for things like RFC 7055 where you're integrating EAP into
something else, you may only have space in the involved APIs for a
single concept of identity.
There you almost certainly want to do a privacy-based outer ID, and
you'll need to have specific knowledge of the methods you use, and there
may be some configurations you don't work with.
It's not fully general, but it is more intuitive than an iterface that
prompts for a lot of identities.

ONe thing to clarify in this document is which identities are we talking
about.  There are:

* The outer identity carried in an EAP response in RADIUS/Diameter.  I
  know we're talking about that one.  That's the primary point of the
  document.

* The Inner identity (if you have a tunnel method) often carried in an
  EAP response/identity in the tunnel.  You could argue this one is
  either in or out of scope.  You could argue this is an internal
  identifier of the tunnel method.

* The method specific identifier of the EAP method within the tunnel.
  In case of password authentication in something like TEAP this
  identity may be carried and the classic inner identity may not.  I
  think this identity is clearly out of scope for this document.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Fri, 24 Jul 2015 06:51:10 -0400

Sam and I had extensive conversations about it this week.  I think his summary below is critical to get everyone talking about the same thing.

  We also need to discuss where these identities are derived from.  For example, wpa_supplicant allows you to configure the outer identity, and the inner identity, though it gives them different names.  I can't see where the method-specific identify is configured.

  From looking at the code, the method-specific identity is just a copy of the inner identity.

  This process is different in windows.  The inner and outer identities can be configured via the 802.1X GUI.  The method-specific identify cannot be configured.  And it is NOT the same as the inner identity.  Instead, some (essentially magic) process is used to transform one into the other.  In typical cases, the inner identity "[email-masked]" gets transformed to an EAP-MSCHAPv2 identity "EXAMPLE\user".

  I would suggest that such processes should be discouraged.  It is difficult enough to analyze the security of EAP without introducing 3 potentially unrelated identities.

  What does it mean when the inner identity is "[email-masked]", and the method identity is "CORP/bob"  ?  Who is being authenticated here?

  I don't think anyone knows.

  In the case of Windows, it would be good for an EAP server to check via an API that "[email-masked]" gets transformed to "EXAMPLE\user".  The server can then verify that the method identity, while opaque, is transformationally equivalent to the inner identity.  This verification would likely prevent some attacks.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 24 Jul 2015 13:20:53 +0200

>  What does it mean when the inner identity is "[email-masked]", and the method identity is "CORP/bob"  ?  Who is being authenticated here?

[BA] It means that the example.com RADIUS server is being asked to authenticate user bob in the CORP domain. In practice, this typically means that CORP is within the example.com Forrest (e.g. Corp.example.com), otherwise the authentication would not succeed.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 24 Jul 2015 07:25:33 -0400

> [BA] It means that the example.com RADIUS server is being asked to authenticate user bob in the CORP domain. In practice, this typically means that CORP is within the example.com Forrest (e.g. Corp…

  I'm happy to make that assumption, but I'm not sure it's always true.

  On a similar note, what about:

outer: [email-masked]

inner: [email-masked]

  *and* where the example.org server is a proxy, and can proxy to example.com.  Should the .org server de-capsulate the outer session, and send only the inner session to the .com site?

  These problems don't have clear solutions to me.  The simplest response is to forbid cross-domain identities.  That may not be practical, but we know it's safe.

  Alan DeKok.