Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication
"Amjad Inamdar (amjads)" <amjads@cisco.com> Fri, 13 November 2009 07:00 UTC
Return-Path: <amjads@cisco.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 5221C3A681F for <ipsec@core3.amsl.com>; Thu, 12 Nov 2009 23:00:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Level:
X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4]
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 wOUHvwBb0zND for <ipsec@core3.amsl.com>; Thu, 12 Nov 2009 23:00:16 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2A2CE3A67BD for <ipsec@ietf.org>; Thu, 12 Nov 2009 23:00:16 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAPuS/EqrR7H+/2dsb2JhbAC9GJgjgjeCBQSBbX4
X-IronPort-AV: E=Sophos;i="4.44,735,1249257600"; d="scan'208";a="431600374"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 13 Nov 2009 07:00:46 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAD70gl5010624; Fri, 13 Nov 2009 07:00:45 GMT
Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 12:30:43 +0530
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 12:30:40 +0530
Message-ID: <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E687F@XMB-BGL-417.cisco.com>
In-Reply-To: <2E13B90533934A499FD727F9B353613C51563E@zin33exm29.fsl.freescale.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAPauthentication
Thread-Index: AcpjJy+IbwOddBiQS5iIcvnXvUEoawAElh4gAAlcq7AADktBsAAlbamg
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>
From: "Amjad Inamdar (amjads)" <amjads@cisco.com>
To: Murthy N Srinivas-B22237 <B22237@freescale.com>, Tero Kivinen <kivinen@iki.fi>, Yoav Nir <ynir@checkpoint.com>
X-OriginalArrivalTime: 13 Nov 2009 07:00:43.0321 (UTC) FILETIME=[04615A90:01CA642F]
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 07:00:17 -0000
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
- [IPsec] Clarification on identities involved in I… Amjad Inamdar (amjads)
- Re: [IPsec] Clarification on identities involved … Yoav Nir
- Re: [IPsec] Clarification on identities involved … Amjad Inamdar (amjads)
- Re: [IPsec] Clarification on identities involved … Paul Hoffman
- Re: [IPsec] Clarification on identities involved … shaik abdulla
- Re: [IPsec] Clarification on identities involved … Andreas Steffen
- Re: [IPsec] Clarification on identities involved … Srinivasu S R S Dhulipala (srinid)
- Re: [IPsec] Clarification on identities involved … Yoav Nir
- Re: [IPsec] Clarification on identities involved … Srinivasu S R S Dhulipala (srinid)
- Re: [IPsec] Clarification on identities involved … Yoav Nir
- Re: [IPsec] Clarification on identities involved … Tero Kivinen
- Re: [IPsec] Clarification on identities involved … Raj Singh
- Re: [IPsec] Clarification on identities involved … Yoav Nir
- Re: [IPsec] Clarification on identities involved … Amjad Inamdar (amjads)
- Re: [IPsec] Clarification on identities involved … Murthy N Srinivas-B22237
- Re: [IPsec] Clarification on identities involved … Murthy N Srinivas-B22237
- Re: [IPsec] Clarification on identities involved … Frederic Detienne
- Re: [IPsec] Clarification on identities involved … Amjad Inamdar (amjads)
- Re: [IPsec] Clarification on identities involved … Murthy N Srinivas-B22237
- Re: [IPsec] Clarification on identities involved … Frederic Detienne