Subject: [IPsec] Fwd: Issue : Regarding EAP identity

From: Raj Singh <[email-masked]>
Date: Wed, 3 Feb 2010 11:15:00 +0530

Hi Paul, Ticket Issue#174 opened for it. Regards, Raj

---------- Forwarded message ----------
From: Paul Hoffman <[email-masked]>
Date: Wed, Feb 3, 2010 at 9:41 AM
Subject: Re: Issue : Regarding EAP identity
To: Raj Singh <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>

 At 9:09 AM +0530 2/3/10, Raj Singh wrote:

Hi Paul,

In ikev2bis07
  -----* ikev2-bis-07 section 2.16, last
paragraph*-------------------------------------------
 When the initiator authentication uses EAP, it is possible that the
 contents of the IDi payload is used only for AAA routing purposes and
 selecting which EAP method to use.  This value may be different from
 the identity authenticated by the EAP method.  It is important that
 policy lookups and access control decisions use the actual
 authenticated identity.  Often the EAP server is implemented in a
 separate AAA server that communicates with the IKEv2 responder.  *In
 this case, the authenticated identity has to be sent from the AAA
 server to the IKEv2 responder.*
---------------------------------------------------------------------
------------------------------------------
It says the autheticated EAP identity "has to" be send from AAA server, our
iterpretation is "has to" is obvious MUST.

I believe that is correct.

If AAA doesn't send the authenticated EAP identity, what should be
the behavior?

I would assume "everything stops"

Also, what if AAA server EAP server is not AAA server?

Good question.

Can i open a ticket for it?

Yes, please!

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 3 Feb 2010 07:52:48 +0200

The authenticated identity needs to be sent by the AAA server to the IKE responder in some cases only. For example, in EAP-SIM/AKA people often use “temporary” (anonymized) identities in IDi. But in other cases, like EAP-MSCHAPv2 or (God forbid!) EAP-GTC, there’s no need for a separate “authenticated identity”. In these cases the IKE responder should simply use the original IDi for policy lookup.

Thanks,
                Yaron

From: [email-masked] [mailto:[email-masked]] On Behalf Of Raj Singh
Sent: Wednesday, February 03, 2010 7:45
To: ipsec
Subject: [IPsec] Fwd: Issue : Regarding EAP identity

---------- Forwarded message ----------
From: Paul Hoffman <[email-masked]<mailto:[email-masked]>>
Date: Wed, Feb 3, 2010 at 9:41 AM
Subject: Re: Issue : Regarding EAP identity
To: Raj Singh <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>

In ikev2bis07
  ----- ikev2-bis-07 section 2.16, last paragraph -------------------------------------------
 When the initiator authentication uses EAP, it is possible that the
 contents of the IDi payload is used only for AAA routing purposes and
 selecting which EAP method to use.  This value may be different from
 the identity authenticated by the EAP method.  It is important that
 policy lookups and access control decisions use the actual
 authenticated identity.  Often the EAP server is implemented in a
 separate AAA server that communicates with the IKEv2 responder.  In
 this case, the authenticated identity has to be sent from the AAA
 server to the IKEv2 responder.
---------------------------------------------------------------------------------------------------------------
It says the autheticated EAP identity "has to" be send from AAA server, our iterpretation is "has to" is obvious MUST.

I believe that is correct.
If AAA doesn't send the authenticated EAP identity, what should be the behavior?

Good question.

Yes, please!

--Paul Hoffman, Director
--VPN Consortium

---

From: Raj Singh <[email-masked]>
Date: Wed, 3 Feb 2010 11:51:56 +0530

Hi Yaron,

The question is more towards when EAP identity is needed and
is different from IDi. But AAA server doesn't send it, we will fail.
But draft doesn't have any say for this scenario. So it becomes mandatory
for AAA server to send identity.

Regards,
Raj

On Wed, Feb 3, 2010 at 11:22 AM, Yaron Sheffer <[email-masked]>wrote:

>  The authenticated identity needs to be sent by the AAA server to the IKE
> responder in some cases only. For example, in EAP-SIM/AKA people often use
> “temporary” (anonymized) identities in IDi. But in other cases, like
> EAP-MSCHAPv2 or (God forbid!) EAP-GTC, there’s no need for a separate
> “authenticated identity”. In these cases the IKE responder should simply use
> the original IDi for policy lookup.
>
>
>
> Thanks,
>
>                 Yaron
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Raj Singh
> *Sent:* Wednesday, February 03, 2010 7:45
> *To:* ipsec
> *Subject:* [IPsec] Fwd: Issue : Regarding EAP identity
>
>
>
> From: *Paul Hoffman* <[email-masked]>
>   -----* ikev2-bis-07 section 2.16, last paragraph*-------------------------------------------

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Feb 2010 10:43:26 +0200

Hi Raj

I don’t think we can specify MUST requirements for the AAA servers, because we’re not specifying RADIUS or DIAMETER here.

For example in RADIUS, the VPN gateway sends an Access-Request to the server, which contains the user-name, presumably the same user-name from the IDi payload.

If the server authenticates the user successfully, and has not sent an user-name attribute, then I guess we can assume that it has authenticated the identity sent in the access-request payload (= the identity in the IDi payload). For example, if I pass the identifier “ynir” (which is unique at my company) or “[email-masked]”, which is globally unique, this is good enough for policy updates, even if the EAP server did not send another identity.

Of course, in some cases the IDi could be an anonymized identity, and then if the server doesn’t give us a real identity, then something is wrong. But this distinction is a matter for local policy, which I don’t think we can specify in ikev2bis. In any case, policy lookups have to be done using the authenticated identity, either the one in IDi or the one supplied by the AAA server. I think the line “It is important that policy lookups and access control decisions use the actual authenticated identity.” conveys that. 

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Raj Singh
Sent: Wednesday, February 03, 2010 8:22 AM
To: Yaron Sheffer
Cc: ipsec
Subject: Re: [IPsec] Fwd: Issue : Regarding EAP identity

Hi Yaron,

The question is more towards when EAP identity is needed and is different from IDi. But AAA server doesn't send it, we will fail.
But draft doesn't have any say for this scenario. So it becomes mandatory for AAA server to send identity.

Regards,
Raj
On Wed, Feb 3, 2010 at 11:22 AM, Yaron Sheffer <[email-masked]> wrote:
The authenticated identity needs to be sent by the AAA server to the IKE responder in some cases only. For example, in EAP-SIM/AKA people often use “temporary” (anonymized) identities in IDi. But in other cases, like EAP-MSCHAPv2 or (God forbid!) EAP-GTC, there’s no need for a separate “authenticated identity”. In these cases the IKE responder should simply use the original IDi for policy lookup.
 
Thanks,
                Yaron

---------- Forwarded message ----------
From: Paul Hoffman <[email-masked]>
Date: Wed, Feb 3, 2010 at 9:41 AM
Subject: Re: Issue : Regarding EAP identity
To: Raj Singh <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>

In ikev2bis07
  ----- ikev2-bis-07 section 2.16, last paragraph -------------------------------------------

 
 
Good question.
 
Yes, please!

--Paul Hoffman, Director
--VPN Consortium

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 4 Feb 2010 15:39:37 +0200

Hello,

Why would the IKEv2 responder need to know the real identity?
There can be privacy reasons for hiding it from any entity other than the
AAA/authentication server.

I'm thinking that mandating AAA server to reveal that value is not necessary
and also problematic.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yoav Nir
> Sent: Wednesday, February 03, 2010 10:43 AM
> To: 'Raj Singh'; Yaron Sheffer
> Cc: ipsec
> I don’t think we can specify MUST requirements for the AAA servers,
> because we’re not specifying RADIUS or DIAMETER here.
> 
> For example in RADIUS, the VPN gateway sends an Access-Request to the
> server, which contains the user-name, presumably the same user-name
> from the IDi payload.
> 
> If the server authenticates the user successfully, and has not sent an
> user-name attribute, then I guess we can assume that it has
> authenticated the identity sent in the access-request payload (= the
> identity in the IDi payload). For example, if I pass the identifier
> “ynir” (which is unique at my company) or “[email-masked]”, which
> is globally unique, this is good enough for policy updates, even if the
> EAP server did not send another identity.
> 
> Of course, in some cases the IDi could be an anonymized identity, and
> then if the server doesn’t give us a real identity, then something is
> wrong. But this distinction is a matter for local policy, which I don’t
> think we can specify in ikev2bis. In any case, policy lookups have to
> be done using the authenticated identity, either the one in IDi or the
> one supplied by the AAA server. I think the line “It is important that
> authenticated identity.” conveys that.
> 
> 
> But draft doesn't have any say for this scenario. So it becomes
> mandatory for AAA server to send identity.
> 
> Regards,
> Raj
> The authenticated identity needs to be sent by the AAA server to the
> IKE responder in some cases only. For example, in EAP-SIM/AKA people
> often use “temporary” (anonymized) identities in IDi. But in other
> cases, like EAP-MSCHAPv2 or (God forbid!) EAP-GTC, there’s no need for
> a separate “authenticated identity”. In these cases the IKE responder
> should simply use the original IDi for policy lookup.
> 
> Thanks,
>                 Yaron
> 
> It says the autheticated EAP identity "has to" be send from AAA server,
> our iterpretation is "has to" is obvious MUST.
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 4 Feb 2010 15:45:23 +0200

The IKEv2 responder enforces policy, so it has to know the identity, both for enforcement and auditing. Suppose [email-masked] is allowed to access server X, while [email-masked] is not, then the IKEv2 responder needs to both block your attempts to access server X (perhaps by failing the CREATE_CHILD_SA exchange), and to log that you tried this.

If auditing is not required, it's possible to work with some kind of pseudo-identity, but in that case, for the IKEv2 responder, this is the authenticated identity.

Unless there is a single policy for all authenticated users, you do need the user identity.

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Thursday, February 04, 2010 3:40 PM
To: Yoav Nir; 'Raj Singh'; Yaron Sheffer
Cc: 'ipsec'
Subject: RE: [IPsec] Fwd: Issue : Regarding EAP identity

Hello,

Alper

> Of Raj Singh
> Of Raj Singh

Scanned by Check Point Total Security Gateway.

---

From: Raj Singh <[email-masked]>
Date: Thu, 4 Feb 2010 22:26:19 +0530

Hi Yoav,

According to RFC-3579 [Appendix-A] RADIUS (Remote Authentication Dial In
User Service) Support For Extensible Authentication Protocol (EAP) shows
that NAS (IKEv2 Gateway) sends an EAP-Request/Identity as the initial packet
to IKEv2 initiator. Here IKEv2 will come to know EAP identity and apply
policy based on authenticated identity.

We can add text at end of section 2.16 that if authenticated identity is not
sent by AAA server to IKEv2 responder, the IKEv2 responder can begin EAP
authentication by sending EAP-Request/Identity as the initial packet to
IKEv2 initiator.

Regards,
Raj

2010/2/4 Yoav Nir <[email-masked]>

> The IKEv2 responder enforces policy, so it has to know the identity, both
> for enforcement and auditing. Suppose [email-masked] is allowed to
> access server X, while [email-masked] is not, then the IKEv2
> responder needs to both block your attempts to access server X (perhaps by
> failing the CREATE_CHILD_SA exchange), and to log that you tried this.
>
> If auditing is not required, it's possible to work with some kind of
> pseudo-identity, but in that case, for the IKEv2 responder, this is the
> authenticated identity.
>

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 4 Feb 2010 13:17:30 -0800 (PST)

Hi Raj,

  RFC 3748 (the RFC defining EAP) says:

      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.

In other words, the identity the IKEv2 gateway receives is worthless
for authentication purposes and authentication is what IKE does. That
identity is just to decide what EAP method to use with the peer. It is
not an "authenticated identity" as you suggest. RFC 3748 further
recommends:

      [F]or an EAP method to include an identity exchange that supports
      per-packet authentication, integrity and replay protection, and
      confidentiality.

So the identity that is used for _authentication of the peer_ is something
that is just passed through the IKEv2 gateway and may even be encrypted by
a key that the IKEv2 gateway does not have access to.

  Imagine the next time some guard at a building or in an airport says,
"let me see your ID please" when you attempt to gain entry and you say,
"sorry you're not in a position to see that but our shared friend here
can vouch for me." How do you think that's gonna fly? Not too well, I'd
imagine.

  regards,

  Dan.

On Thu, February 4, 2010 8:56 am, Raj Singh wrote:
>> >   ----- ikev2-bis-07 section 2.16, last paragraph
>> ---------------------
>> > ----------------------

---

From: Raj Singh <[email-masked]>
Date: Fri, 5 Feb 2010 06:45:44 +0530

Hi Dan,

>      per-packet authentication, integrity and replay protection, and

That sounds quite reasonable and suggests each EAP method SHOULD have
identity exchange for EAP authentication with IKEv2. Current draft doesn't
say
like that. That's my concern.

> On a lighter note: It will be like flying without passport. :-)

With Regards,
Raj

> >> > On Wed, Feb 3, 2010 at 11:22 AM, Yaron Sheffer <[email-masked]
> >
> >> > wrote:

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 8 Feb 2010 11:41:47 +0200

Yoav,

When the IKEv2 responder offloads the Authentication, Authorization, and
Accounting (AAA) responsibilities to a centralized AAA server, it is no
longer in the business of figuring out who the peer is, if the peer is
really who it claims it is, what policies to apply to the peer. These are
the things handled by the AAA server, and communicated to the IKEv2
responder. "Policy" needs to be enforced by the IKEv2 responder, but the
policy is determined by and communicated to the responder by the AAA server.

Alper

> From: Yoav Nir [mailto:[email-masked]]
> Sent: Thursday, February 04, 2010 3:45 PM
> To: 'Alper Yegin'; 'Raj Singh'; Yaron Sheffer
> Cc: 'ipsec'
> The IKEv2 responder enforces policy, so it has to know the identity,
> both for enforcement and auditing. Suppose [email-masked] is
> allowed to access server X, while [email-masked] is not, then
> the IKEv2 responder needs to both block your attempts to access server
> X (perhaps by failing the CREATE_CHILD_SA exchange), and to log that
> you tried this.
> 
> > On Wed, Feb 3, 2010 at 11:22 AM, Yaron Sheffer
> <[email-masked]>
> > wrote:
> >   ----- ikev2-bis-07 section 2.16, last paragraph -------------------
> --
> > ----------------------

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 8 Feb 2010 10:12:41 -0800 (PST)

Hi Alper,

  What document describes how a AAA server communicates selector and
SPD information for this authenticated peer to an IKEv2 responder?

  Dan.

On Mon, February 8, 2010 1:41 am, Alper Yegin wrote:
>> > ----------------------------------------

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Feb 2010 14:16:38 -0500

>policy is determined by and communicated to the responder by the AAA server.

AN IPsec implementation enforces access controls based on SPD 
entries, creating SAD entries for approved traffic flows. I can 
imagine that an AAA server may  authenticate a user and advise the 
IKE component of that action. But, there needs to be a way for IKE to 
know what ID is being asserted and to use that in the SPD lookup. The 
PAD normally governs such actions, so maybe the AAA server
is off loading part of that processing.  It that clearly defined anywhere?

Steve

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 9 Feb 2010 12:53:41 +0200

Dan,

I'm not aware of any such document.

Alper

> From: Dan Harkins [mailto:[email-masked]]
> Sent: Monday, February 08, 2010 8:13 PM
> To: Alper Yegin
> Cc: 'Yoav Nir'; 'Raj Singh'; 'Yaron Sheffer'; 'ipsec'
> >> There can be privacy reasons for hiding it from any entity other
> than
> >> the
> >> > If the server authenticates the user successfully, and has not
> sent
> >> an
> >> > is globally unique, this is good enough for policy updates, even
> if
> >> the

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 9 Feb 2010 09:13:35 -0800 (PST)

Hi Alper,

  In that case there is no standard way for the AAA server to inform the
IKEv2 responder of this "policy" that it needs to enforce. So that sounds
unworkable.

  The IKEv2 responder already has the mechanisms in place to enforce a
policy based on the authenticated identity of the IKEv2 initiator. So if
EAP is being used then all we need is a way to get that authenticated
identity from the AAA server to the IKEv2 responder.

  I'm not aware of a document to allows a AAA server to export the
authenticated identity to the AAA client (maybe such an attribute already
exists, I just don't know) but surely it would be easier to define that
then to define a standard way to send some "policy" from AAA server to
IKEv2 responder. Right?

  regards,

  Dan.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 10 Feb 2010 12:14:00 +0200

Dan,

> IKEv2 responder of this "policy" that it needs to enforce. So that

I guess it can be specified.

> identity from the AAA server to the IKEv2 responder.

Isn't IDi what IKE deals with? 

> exists, I just don't know) 

I'm not aware, either. 
In other uses of AAA (such as with WiFi, WiMAX, 3GPP2, etc.) I know that the
subscriber ID is hidden from the NAS. There are even specific methods
deployed for that purpose. So, disclosing that ID would not be acceptable
there. I'm just not sure if the same privacy concerns apply to the VPN
deployments.

> but surely it would be easier to define that

If you don't do that, then you have to maintain "per subscriber policy" on
each one of the VPN gateways. Now that starts defeating some of the purpose
that AAA was offloaded to a centralized/dedicated server.

Regards,

Alper

> >> > When the IKEv2 responder offloads the Authentication,
> Authorization,
> >> and
> >> > Accounting (AAA) responsibilities to a centralized AAA server, it
> is
> >> no
> >> > longer in the business of figuring out who the peer is, if the
> peer
> >> is
> >> > really who it claims it is, what policies to apply to the peer.
> These
> >> are
> >> > responder. "Policy" needs to be enforced by the IKEv2 responder,
> but
> >> the
> >> > policy is determined by and communicated to the responder by the
> AAA
> >> > server.
> >> >
> >> > Alper
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >> pseudo-identity, but in that case, for the IKEv2 responder, this
> is
> >> the
> >> >> authenticated identity.
> >> >>
> >> >> Unless there is a single policy for all authenticated users, you
> do
> >> >> need the user identity.
> >> >>
> >> >> I'm thinking that mandating AAA server to reveal that value is
> not
> >> >> necessary
> >> >> and also problematic.
> >> >>
> >> >> Alper
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> > For example in RADIUS, the VPN gateway sends an Access-Request
> to
> >> the
> >> >> > authenticated the identity sent in the access-request payload
> (=
> >> the
> >> >> > “ynir” (which is unique at my company) or
> “[email-masked]”,
> >> >> which
> >> >> > Of course, in some cases the IDi could be an anonymized
> identity,
> >> and
> >> >> > then if the server doesn’t give us a real identity, then
> something
> >> is
> >> >> > wrong. But this distinction is a matter for local policy, which
> I
> >> >> don’t
> >> >> > think we can specify in ikev2bis. In any case, policy lookups
> have
> >> to
> >> >> > be done using the authenticated identity, either the one in IDi
> or
> >> >> the
> >> >> > one supplied by the AAA server. I think the line “It is
> important
> >> >> that
> >> >> > The authenticated identity needs to be sent by the AAA server
> to
> >> the
> >> >> > cases, like EAP-MSCHAPv2 or (God forbid!) EAP-GTC, there’s no
> need
> >> >> for
> >> >> >   ----- ikev2-bis-07 section 2.16, last paragraph -------------
> ---
> >> ---
> >> >> --
> >> >> > ----------------------
> >> >> >  When the initiator authentication uses EAP, it is possible
> that
> >> the
> >> >> >  contents of the IDi payload is used only for AAA routing
> purposes
> >> >> and
> >> >> >  selecting which EAP method to use.  This value may be
> different
> >> from
> >> >> >  separate AAA server that communicates with the IKEv2
> responder.
> >>  In
> >> >> > ---------------------------------------------------------------
> ---
> >> ---
> >> >> --

---

From: Raj Singh <[email-masked]>
Date: Wed, 10 Feb 2010 16:00:17 +0530

On Wed, Feb 10, 2010 at 3:44 PM, Alper Yegin <[email-masked]> wrote:

> I am not able to see these privacy concerns in VPN deployments using IKEv2.
As EAP packets are inside IKEv2 packet which is encrypted.
IKEv2 Responder asking the EAP identity before EAP authentication and IKEv2
initiator
can give provide the EAP identity which its going to use.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Feb 2010 10:37:09 -0500

>Isn't IDi what IKE deals with?

not always. See the discussion in 4301 re the PAD.

>there. I'm just not sure if the same privacy concerns apply to the VPN

There is a difference here in that the IPsec device normally performs
peer auth and access control, independent of an AAA server.

>that AAA was offloaded to a centralized/dedicated server.

Maybe. I thought the principle argument for AAA (really RADIUS) use 
here was that enterprise IT folks already managed user authentication 
via these servers and wanted to use that aspect of their investment 
in the IPsec context. If one wants to rely on these servers for more 
than just user authentication, a more complex solution is needed.

Steve

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 10 Feb 2010 08:42:19 -0800 (PST)

Hi Alper,

> I guess it can be specified.

  Well yes it can. But it will be much more complicated than just
specifying a way to get the authenticated identity.

> Isn't IDi what IKE deals with?

  We're talking about a case where there is no linkage between the two.
The initiator asserts an identity but the identity used for authentication
is unknown.

> there. I'm just not sure if the same privacy concerns apply to the VPN

  It's not "hidden" it's just unavailable because there is no way to
get it (see above) and, in the case of WiFi (and I suspect WiMAX) it's
just a binary decision anyway.

  The notion that there could be some privacy concerns does not sound
serious. You're going to give the NAS the power to impersonate the client,
inspect all the client's packets, forge packets to and from the client,
tamper with all the client's packets in an undetectable manner, yet for
"privacy concerns" the NAS can't be told the real identity of the client?
That's sort of like someone eating 4 chocolate cakes but washing it all
down with a diet soda because of "weight concerns".

  regards,

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 10 Feb 2010 08:58:33 -0800 (PST)

Hi Raj,

> On Wed, Feb 10, 2010 at 3:44 PM, Alper Yegin <[email-masked]>
<snip>
> can give provide the EAP identity which its going to use.

  It can. And it does. But that identity is not used for authentication
purposes because "it may have been truncated or obfuscated so as to
provide privacy, or it may have been decorated for routing purposes"
(see RFC 3748-- the Extensible Authentication Protocol). So depending on
how the client "decorates" the identity he provides to the IKEv2
responder's EAP identity request, the AAA server may forward it off to
some other AAA server to do "real" authentication and that server may
process it or may forward it off. And so on. And the client can provide
anything as IDi. And there lies the problem.

  regards,

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 11 Feb 2010 08:16:00 +0200

Hi.

This is an interesting subject, and perhaps could be a good candidate for discussion at Anaheim. However, from the narrow perspective of a VPN vendor, I don't think this issue is very complicated:

- In the first IKE_AUTH request the initiator provides *an* identity. This could be something meaningful like "ynir", or something less meaningful, like "@checkpoint.com", or something really unique like "[email-masked]"

- The responder uses this info to decide on using the EAP/RADIUS server (perhaps running on an LDAP server).

- The RADIUS protocol is really out of scope for this document, so we won't discuss its details, but in any case, eventually this AAA server returns an EAP success and RADIUS access-accept.  Now we have two possibilites:

 #1) The AAA server passed an authenticated identity, perhaps UID=ynir,OU=People,O=intranet,DC=checkpoint,DC=com. (No, I don't know why I work for the "intranet" organization). In this case, the IKE responder will enforce policy according to what the PAD and SPD say about this identity. Where this policy comes from does not matter - maybe it's also passed from the AAA server, maybe it's specially configured and maybe it's stored on the LDAP server. How IKE gets its policy is out of scope while we're discussing IKEv2bis.

 #2) The AAA server did not pass an authenticated identity. In this case, the authenticated identity is exactly what you had in the ID payload. If this is "ynir", than we can expect the IKE responder to have policy based on this name. If it's "@checkpoint.com" - a name that everybody uses, then either the policy is the same for all defined users (a valid policy and very common) or you have a misconfiguration here - the combination of obfuscated identity and an AAA server that does not provide the authenticated identity is a configuration mistake, and it's entirely correct for the IKE responder to treat packets from this user as if they come from an unauthenticated source (in our product - only firewall rules apply)

I don't think this behavior is specified anywhere, but to me it's just the obvious thing for an IKE responder to do.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 10 Feb 2010 23:06:49 -0800 (PST)

Hi Yoav,

  First of all, IDi is not sent in response to an EAP Identity Request.
Every NAS will, when it comes time to initiate EAP authentication,
request an identity. That's how EAP works. The IKEv2 responder "knows"
to send an EAP Identity Request because the IKEv2 initiator has
indicated its "desire to use extensible authentication by leaving out
the AUTH payload from message 3." So the IDi in message 3 of the exchange
in 2.16 of RFC 4306 will not be an identity from an EAP identity response.
It's going to be anything the initiator decides to use and has no bearing
on reality. The NAS, in message 4, will do an EAP Identity Request. And
now the client, in a subsequent message, will provide it's decorated or
obfuscated identity which is used to find a suitable AAA server that will
actually determine what the real and authenticated identity of this thing
is.

  So what we have is:
     1) IDi, whatever the client decides to use.
     2) the identity in the EAP Identity response to message 4 which can
        be decorated or obfuscated and is useless for authentication.
     3) the real identity that was used to authenticate the client
        at the EAP server.

Now, what identity are you saying is used by the IKEv2 responder to
enforce policy and how and why?

  regards,

  Dan.

On Wed, February 10, 2010 10:16 pm, Yoav Nir wrote:
> Hi.
>
> This is an interesting subject, and perhaps could be a good candidate for
> discussion at Anaheim. However, from the narrow perspective of a VPN
> vendor, I don't think this issue is very complicated:
>
> - In the first IKE_AUTH request the initiator provides *an* identity. This
> could be something meaningful like "ynir", or something less meaningful,
> like "@checkpoint.com", or something really unique like
> "[email-masked]"
>
> - The RADIUS protocol is really out of scope for this document, so we
> won't discuss its details, but in any case, eventually this AAA server
> returns an EAP success and RADIUS access-accept.  Now we have two
> possibilites:
>
>  #1) The AAA server passed an authenticated identity, perhaps
> UID=ynir,OU=People,O=intranet,DC=checkpoint,DC=com. (No, I don't know why
> I work for the "intranet" organization). In this case, the IKE responder
> will enforce policy according to what the PAD and SPD say about this
> identity. Where this policy comes from does not matter - maybe it's also
> passed from the AAA server, maybe it's specially configured and maybe
> it's stored on the LDAP server. How IKE gets its policy is out of scope
> while we're discussing IKEv2bis.
>
>  #2) The AAA server did not pass an authenticated identity. In this case,
> the authenticated identity is exactly what you had in the ID payload. If
> this is "ynir", than we can expect the IKE responder to have policy based
> on this name. If it's "@checkpoint.com" - a name that everybody uses,
> then either the policy is the same for all defined users (a valid policy
> and very common) or you have a misconfiguration here - the combination of
> obfuscated identity and an AAA server that does not provide the
> authenticated identity is a configuration mistake, and it's entirely
> correct for the IKE responder to treat packets from this user as if they
> come from an unauthenticated source (in our product - only firewall rules
> apply)
>
> I don't think this behavior is specified anywhere, but to me it's just the
> obvious thing for an IKE responder to do.
>

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 12 Feb 2010 11:36:30 +0200

> > I'm not aware, either.
> > In other uses of AAA (such as with WiFi, WiMAX, 3GPP2, etc.) I know
> that
> > the

:-)

Mobile/wireless networks support roaming, and one operator's subscriber may
visit a NAS that belongs to another operator (or even a WiFi AP in a coffee
shop). Subscribers are concerned about location privacy, and they don't want
to leave a trace at every location they visit (which can get into the wrong
hands).
Secondly, the operators don't want their roaming partners to know the ID of
their subscribers (especially if it is also an email address), because that
can be used for switching (luring) customers. 

Alper