Subject: [IPsec] Clarification on identities involved in IKEv2 EAP authentication

From: "Amjad Inamdar (amjads)" <[email-masked]>
Date: Tue, 10 Nov 2009 17:10:27 +0530

Hi,
 
With IKEv2 EAP authentication, there are 3 identities involved

1) IDi - IKEv2 initiator identity sent in msg-3
2) EAP identity that gateway (IKE2 responder) can request from the
client (IKEv2 initiator)
3) Authenticated EAP identity that third party EAP server provides to
the gateway (IKEv2 responder).

Could someone please clarify from RFC standpoint if 

1) The 3 identities mentioned above MUST/SHOULD be same
2) If not same, what purpose should each of the above identities serve
3) The mandatory/recommended format for each of the above identites 

Thanks,
-Amjad

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Nov 2009 13:59:19 +0200

> 1) The 3 identities mentioned above MUST/SHOULD be same

No, although they typically are.

> 2) If not same, what purpose should each of the above identities serve

   1) mainly used as a hint for the gateway as to which AAA server to  
choose
   2) It's the AAA server that may request the identity, and it's  
internal to AAA. It doesn't play in IKE
   3) That's the authenticated identity of the user. That is what the  
responder uses for policy decisions.

> 3) The mandatory/recommended format for each of the above identites

All the types in section 3.5 are acceptable, but the most used ones  
are ID_RFC822_ADDR and ID_DER_ASN1_DN

---

From: "Amjad Inamdar (amjads)" <[email-masked]>
Date: Tue, 10 Nov 2009 19:00:46 +0530

Hi Yaov,

Thanks for your reply. Please see my comments inline. 

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Tuesday, November 10, 2009 5:29 PM
To: Amjad Inamdar (amjads)
Cc: [email-masked]
Subject: Re: [IPsec] Clarification on identities involved in IKEv2
EAPauthentication

[Amjad]
Is there a use case for not having IDi same as EAP identity? Having them
same would simplify policy decisions.

[Amjad]
EAP authentication is typically used with remote access and IDi of type
IP_ADDR may not be very useful here as a hint for AAA server. So it will
help to have recommened ID types for such cases.

[Amjad]
Does it mean that if gateway is just acting as a pass-through, gateway
MUST-NOT request EAP identity from the client as per RFC? If AAA server
does not provide authenticated identity to the gateway (RFC does not
seem to mandate that), the only way for gateway is to request EAP
identity from the client, for policy decisions, unless IDi carries EAP
identity which again is not mandated by RFC.

> 3) The mandatory/recommended format for each of the above identites

All the types in section 3.5 are acceptable, but the most used ones are
ID_RFC822_ADDR and ID_DER_ASN1_DN
[Amjad]
Are IKEv2 identity types acceptable as EAP identity as well?

Thanks,
-Amjad

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Nov 2009 05:54:05 +0900

The identity types are local policy. We don't want to prohibit particular types, even if they are uncommon.

--Paul Hoffman, Director
--VPN Consortium

---

From: shaik abdulla <[email-masked]>
Date: Wed, 11 Nov 2009 09:06:18 +0530

Hi,
Is there any windows API for IKEV2.If so please send me link.

On Wed, Nov 11, 2009 at 2:24 AM, Paul Hoffman <[email-masked]> wrote:

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

-- 
Regards
Shaik Abdulla

---

From: Andreas Steffen <[email-masked]>
Date: Wed, 11 Nov 2009 08:04:32 +0100

Have a look at the following Windows 7 IKEv2 HOWTO:

http://wiki.strongswan.org/wiki/strongswan/Windows7

Best regards

Andreas Steffen

> Is there any windows API for IKEV2.If so please send me link.

======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

---

From: "Srinivasu S R S Dhulipala (srinid)" <[email-masked]>
Date: Wed, 11 Nov 2009 19:09:44 +0530

Hi Yoav,

Please see inline for [SRINI].

Thanks,
Srinivas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yoav Nir
Sent: Tuesday, November 10, 2009 5:29 PM
To: Amjad Inamdar (amjads)
Cc: [email-masked]
Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAP
authentication

[SRINI] Does this imply that gateway SHOULD not send EAP identity
request to the client,
            we see that one 3rd party IKEv2 client is sending IP address
as IDi, from which we can't
            take any hints. Moreover, the same client is expecting an
EAP-ID request to be sent,
            else EAP is failing.
            I've started another thread about why did we demote "SHOULD"
to "should" if the gateway is
            Not supposed to send EAP-identity request to the client. I
think we should promote it back.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 Nov 2009 15:53:02 +0200

> think we should promote it back.

The gateway never sends any EAP identity requests at all. If such a request exists, it is sent by the AAA server. The gateway serves only as a pass-through.

For that reason, there is typically no reason for the gateway to inspect the contents of the EAP payload.

---

From: "Srinivasu S R S Dhulipala (srinid)" <[email-masked]>
Date: Wed, 11 Nov 2009 19:35:35 +0530

Hi Yoav,

Thanks for the quick response. Please see inline.

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Wednesday, November 11, 2009 7:23 PM
To: Srinivasu S R S Dhulipala (srinid)
Cc: Amjad Inamdar (amjads); [email-masked]
Subject: Re: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

> think we should promote it back.

The gateway never sends any EAP identity requests at all. If such a
request exists, it is sent by the AAA server. The gateway serves only as
a pass-through.

[SRINI] Text below from sec 3.16 of the bis hints that responder may
send, but it says
            It should not. In RFC 4306, it was "SHOULD NOT", in the bis
it is "should not".
            
   {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an
   indication of initiator identity in message 3 of the protocol, the
   responder should not send EAP Identity requests.  The initiator may,
   however, respond to such requests if it receives them.

Thanks,
Srinivas

For that reason, there is typically no reason for the gateway to inspect
the contents of the EAP payload.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 Nov 2009 16:12:11 +0200

The text is a little vague here, because the draft only describes the use of EAP, and does not mandate anything for an AAA server.

If the gateway is also the EAP authenticator, then it makes no sense to send the identity request, because the reply has already been received in packet #3.

If the EAP authenticator is separate, it still does not make sense, as the gateway could have passed the identity hint to the authenticator. But some AAA servers always begin a session by requesting an identity. We don't want to make their use a SHOULD NOT. We don't want to mandate anything for them. So we accept that some servers may send an identity request even though the hint is already given.

Since the gateway acts as a pass-through, the requirement here is more for the client, which is typically more integrated. The client should be prepared to give an identity hint both in IKE and later in the EAP session.

On Nov 11, 2009, at 4:05 PM, Srinivasu S R S Dhulipala (srinid) wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Nov 2009 01:31:26 +0200

Yoav Nir writes:
> Since the gateway acts as a pass-through, the requirement here is
> more for the client, which is typically more integrated. The client
> should be prepared to give an identity hint both in IKE and later in
> the EAP session.

And in that case the identities should really be same, and if they
differ then the authenticated identity needs to be used for policy
lookups, meaning that the EAP identity needs to be used. So the
gateway needs to get that authenticated identity from the AAA server
so it can do policy lookups based on it. 
-- 
[email-masked]

---

From: Raj Singh <[email-masked]>
Date: Thu, 12 Nov 2009 09:04:32 +0530

The selection of AAA server will be based on IDi then EAP will happen.
The gateway will get EAP authenticated ID from the AAA server.
If EAP identity is different from IDi and no policy is found for EAP
identity.
The gateway should initiate deletion of the SA.
Also, if policy is found based on EAP identity, but its different from IDi,
EAP identity should be given priority and its attributes should be applied
on that SA.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Nov 2009 10:32:24 +0200

On Nov 12, 2009, at 5:34 AM, Raj Singh wrote:

> If EAP identity is different from IDi and no policy is found for EAP identity.

Actually, the gateway doesn't need to delete the SA. The gateway receives the EAP identity before the end of the IKE_AUTH exchanges, so it can terminate with an AUTHENTICATION_FAILED. No need for DELETE

---

From: "Amjad Inamdar (amjads)" <[email-masked]>
Date: Thu, 12 Nov 2009 16:09:02 +0530

Hi Murthy,

As per the RFC, with EAP authentication, policy lookups and access
control decisions should be based on EAP identity, so the gatway needs
to know the EAP identity.

The source of EAP identity for gateway is either IDi (when IDi is same
as EAP identity) or AAA server providing authenticated EAP identity
neither of which is mandated by RFC, and in case client(via IDi) and AAA
server do not provide EAP identity, the only way gateway can get EAP
identity is via EAP identity request to the client.

----- Ikev2-bis-05 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.
----------------------------------------------------------

Thanks,
-Amjad

-----Original Message-----
From: Murthy N Srinivas-B22237 [mailto:[email-masked]] 
Sent: Thursday, November 12, 2009 7:30 AM
To: Tero Kivinen; Yoav Nir
Cc: [email-masked]; Amjad Inamdar (amjads)
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

 Policy lookups are selected by Authenticator based on Authorization
information received from AAA server after successful Authentication.
The AAA sever uses an attribute(radius) to send a reference to the
Authorization information specific for the specific client.The
Authenticator need not know the EAP identitity of the client, if it is
different from IKE identity.  

The Authenticator requires to know the EAP identity only if it
implements the AAA server functionality.
 
ns murthy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tero Kivinen
Sent: Thursday, November 12, 2009 5:01 AM
To: Yoav Nir
Cc: [email-masked]; Amjad Inamdar (amjads)
Subject: Re: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

Yoav Nir writes:
> Since the gateway acts as a pass-through, the requirement here is more

> for the client, which is typically more integrated. The client should 
> be prepared to give an identity hint both in IKE and later in the EAP 
> session.

And in that case the identities should really be same, and if they
differ then the authenticated identity needs to be used for policy
lookups, meaning that the EAP identity needs to be used. So the gateway
needs to get that authenticated identity from the AAA server so it can
do policy lookups based on it. 
--
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Murthy N Srinivas-B22237" <[email-masked]>
Date: Thu, 12 Nov 2009 07:29:47 +0530

ns murthy

---

From: "Murthy N Srinivas-B22237" <[email-masked]>
Date: Thu, 12 Nov 2009 18:35:08 +0530

Amjad,

If the Authenticator includes the AAA server implementation,it should no
the EAP identity to enforce policies.If AAA server is separate,we can
add an attribute to AAA server for this purpose and in which case
Authenticator does not have to know the EAP identity.It will use the
attribute to select the policies.

Thanks
-ns murthy 

-----Original Message-----
From: Amjad Inamdar (amjads) [mailto:[email-masked]] 
Sent: Thursday, November 12, 2009 4:09 PM
To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir
Cc: [email-masked]
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

Hi Murthy,

----- Ikev2-bis-05 section 2.16, last paragraph -----

Thanks,
-Amjad

-----Original Message-----
From: Murthy N Srinivas-B22237 [mailto:[email-masked]]
Sent: Thursday, November 12, 2009 7:30 AM
To: Tero Kivinen; Yoav Nir
Cc: [email-masked]; Amjad Inamdar (amjads)
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

 
ns murthy

---

From: Frederic Detienne <[email-masked]>
Date: Thu, 12 Nov 2009 23:32:19 +0100

> For that reason, there is typically no reason for the gateway to inspect the contents of the EAP payload.

This is the gist of the question. It is tempting for the client implementation to send just a dummy IDi (like an IP address) that prevents proper selection of the AAA server for subsequent authentication. The client rationale being that the proper ID will be passed during EAP. As such inspecting the ID_request is also tempting to circumvent the client's behavior.

It would be a good idea to recommend IDi to be meaningful for AAA selection and avoid drama's. Something like:

--8<--
IDi SHOULD be meaningful enough for the responder to select an adequate authentication and authorization profile. The IDi SHOULD be unique in the authentication domain, constant over time and structured. ID_FQDN, ID_DER_ASN1_DN, ID_RFC822_ADDR are good candidates for an IDi. Other ID types are good if they match the above criteria.
--8<--

This is something that is not immediately obvious to the client developers and will help server developers to convey their point.

	fred

---

From: "Amjad Inamdar (amjads)" <[email-masked]>
Date: Fri, 13 Nov 2009 12:30:40 +0530

Hi Murthy,

IKEv2 gatway even when acting as a pass-through would need the
authenticated EAP identity for local policy decisions. For instance,
gateway can group remote users based on the authenticated EAP-id (e.g.
based on the domain/realm part of the ID). Further, with PSK and PKI
auth methods, it is the authenticated ID that is used for policy
decisions and that should be same even with EAP auth.

Thanks,
-Amjad 

-----Original Message-----
From: Murthy N Srinivas-B22237 [mailto:[email-masked]] 
Sent: Thursday, November 12, 2009 6:35 PM
To: Amjad Inamdar (amjads); Tero Kivinen; Yoav Nir
Cc: [email-masked]
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

Amjad,

Thanks
-ns murthy 

-----Original Message-----
From: Amjad Inamdar (amjads) [mailto:[email-masked]]
Sent: Thursday, November 12, 2009 4:09 PM
To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir
Cc: [email-masked]
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

Hi Murthy,

----- Ikev2-bis-05 section 2.16, last paragraph -----

Thanks,
-Amjad

-----Original Message-----
From: Murthy N Srinivas-B22237 [mailto:[email-masked]]
Sent: Thursday, November 12, 2009 7:30 AM
To: Tero Kivinen; Yoav Nir
Cc: [email-masked]; Amjad Inamdar (amjads)
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

 
ns murthy

---

From: "Murthy N Srinivas-B22237" <[email-masked]>
Date: Fri, 13 Nov 2009 14:40:42 +0530

Amjad,

AAA Server (Radius server) is configured with
1.domain/realm part of the EAP Identity as the "user name".
2.Along with this we can configure a radius attribue with a unique
identifier.This identifier is sent by AAA server to Authenticator along
with Authention success packet.
3.This identifier is known to the Authenticator which controls
policies.Multiple users can be configured at AAA server with the same
identifier.
4.This way,Authenticator is not required to know the EAP-identity.

Thanks
-nsmurthy

-----Original Message-----
From: Amjad Inamdar (amjads) [mailto:[email-masked]] 
Sent: Friday, November 13, 2009 12:31 PM
To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir
Cc: [email-masked]
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

Hi Murthy,

Thanks,
-Amjad 

-----Original Message-----
From: Murthy N Srinivas-B22237 [mailto:[email-masked]]
Sent: Thursday, November 12, 2009 6:35 PM
To: Amjad Inamdar (amjads); Tero Kivinen; Yoav Nir
Cc: [email-masked]
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

Amjad,

Thanks
-ns murthy 

-----Original Message-----
From: Amjad Inamdar (amjads) [mailto:[email-masked]]
Sent: Thursday, November 12, 2009 4:09 PM
To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir
Cc: [email-masked]
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

Hi Murthy,

----- Ikev2-bis-05 section 2.16, last paragraph -----

Thanks,
-Amjad

-----Original Message-----
From: Murthy N Srinivas-B22237 [mailto:[email-masked]]
Sent: Thursday, November 12, 2009 7:30 AM
To: Tero Kivinen; Yoav Nir
Cc: [email-masked]; Amjad Inamdar (amjads)
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

 
ns murthy

---

From: Frederic Detienne <[email-masked]>
Date: Mon, 16 Nov 2009 14:24:59 +0100

> 4.This way,Authenticator is not required to know the EAP-identity.

the problem is that the RADIUS ACCESS-ACCEPT and the ID would be sent at the end of the EAP exchange -- at this point, it is too late for some operations.

Some characteristics like for instance allowing the use of EAP for a given identity have to be known BEFORE EAP is complete. We do not want to waste time failing the EAP exchange if we can know from the beginning that EAP can't be used for a given identity. An other example is if the domain portion of an RFC822 ID should be used to pick a AAA server from a list of possible servers.

It is reasonable to recommend passing "a sensible" identity from the beginning.

thanks,

	fred