Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication

"Murthy N Srinivas-B22237" <B22237@freescale.com> Fri, 13 November 2009 09:10 UTC

Return-Path: <B22237@freescale.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A31C3A67C1 for <ipsec@core3.amsl.com>; Fri, 13 Nov 2009 01:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.756
X-Spam-Level:
X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_82=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEe2+RrxjboV for <ipsec@core3.amsl.com>; Fri, 13 Nov 2009 01:10:29 -0800 (PST)
Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 1FAC13A6859 for <ipsec@ietf.org>; Fri, 13 Nov 2009 01:10:29 -0800 (PST)
Received: from de01smr02.am.mot.com (de01smr02.freescale.net [10.208.0.151]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id nAD9AgEB009211 for <ipsec@ietf.org>; Fri, 13 Nov 2009 02:10:48 -0700 (MST)
Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by de01smr02.am.mot.com (8.13.1/8.13.0) with ESMTP id nAD9EkFe020226 for <ipsec@ietf.org>; Fri, 13 Nov 2009 03:14:48 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Nov 2009 14:40:42 +0530
Message-ID: <2E13B90533934A499FD727F9B353613C5156CB@zin33exm29.fsl.freescale.net>
In-Reply-To: <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E687F@XMB-BGL-417.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAPauthentication
Thread-Index: AcpjJy+IbwOddBiQS5iIcvnXvUEoawAElh4gAAlcq7AADktBsAAlbamgAASMWYA=
References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com><4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com><39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com><4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com> <19195.18766.767555.230392@fireball.kivinen.iki.fi> <2E13B90533934A499FD727F9B353613C5155A7@zin33exm29.fsl.freescale.net> <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E66F5@XMB-BGL-417.cisco.com> <2E13B90533934A499FD727F9B353613C51563E@zin33exm29.fsl.freescale.net> <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E687F@XMB-BGL-417.cisco.com>
From: Murthy N Srinivas-B22237 <B22237@freescale.com>
To: "Amjad Inamdar (amjads)" <amjads@cisco.com>, Tero Kivinen <kivinen@iki.fi>, Yoav Nir <ynir@checkpoint.com>
X-Brightmail-Tracker: AAAAAQAAAWE=
X-Brightmail-Tracker: AAAAAQAAAWE=
X-Mailman-Approved-At: Sat, 14 Nov 2009 13:56:21 -0800
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2009 09:10:30 -0000

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:amjads@cisco.com] 
Sent: Friday, November 13, 2009 12:31 PM
To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir
Cc: ipsec@ietf.org
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

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:B22237@freescale.com]
Sent: Thursday, November 12, 2009 6:35 PM
To: Amjad Inamdar (amjads); Tero Kivinen; Yoav Nir
Cc: ipsec@ietf.org
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication


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:amjads@cisco.com]
Sent: Thursday, November 12, 2009 4:09 PM
To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir
Cc: ipsec@ietf.org
Subject: RE: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication

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:B22237@freescale.com]
Sent: Thursday, November 12, 2009 7:30 AM
To: Tero Kivinen; Yoav Nir
Cc: ipsec@ietf.org; 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: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
Of Tero Kivinen
Sent: Thursday, November 12, 2009 5:01 AM
To: Yoav Nir
Cc: ipsec@ietf.org; 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. 
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec