Re: [IPsec] Clarification on identities involved in IKEv2 EAPauthentication

"Amjad Inamdar (amjads)" <amjads@cisco.com> Tue, 10 November 2009 13:30 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 44F4D3A6805 for <ipsec@core3.amsl.com>; Tue, 10 Nov 2009 05:30:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3JarL81bUUTU for <ipsec@core3.amsl.com>; Tue, 10 Nov 2009 05:30:23 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 68B773A672F for <ipsec@ietf.org>; Tue, 10 Nov 2009 05:30:23 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAGv5+EqrR7Ht/2dsb2JhbADFY5gVgjmCBQSBaHg
X-IronPort-AV: E=Sophos;i="4.44,716,1249257600"; d="scan'208";a="268842973"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 10 Nov 2009 13:30:50 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAADUniX001747; Tue, 10 Nov 2009 13:30:50 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); Tue, 10 Nov 2009 19:00:48 +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: Tue, 10 Nov 2009 19:00:46 +0530
Message-ID: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F1074@XMB-BGL-417.cisco.com>
In-Reply-To: <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IPsec] Clarification on identities involved in IKEv2 EAPauthentication
Thread-Index: Acph/T6sbxIgyziASaiLecrXjL4UOAACRCUg
References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com>
From: "Amjad Inamdar (amjads)" <amjads@cisco.com>
To: "Yoav Nir" <ynir@checkpoint.com>
X-OriginalArrivalTime: 10 Nov 2009 13:30:48.0666 (UTC) FILETIME=[03D053A0:01CA620A]
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Clarification on identities involved in IKEv2 EAPauthentication
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: Tue, 10 Nov 2009 13:30:24 -0000

Hi Yaov,

Thanks for your reply. Please see my comments inline. 

-----Original Message-----
From: Yoav Nir [mailto:ynir@checkpoint.com] 
Sent: Tuesday, November 10, 2009 5:29 PM
To: Amjad Inamdar (amjads)
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Clarification on identities involved in IKEv2
EAPauthentication


On Nov 10, 2009, at 1:40 PM, Amjad Inamdar (amjads) wrote:

> 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

No, although they typically are.

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

> 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

[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.

   2) It's the AAA server that may request the identity, and it's
internal to AAA. It doesn't play in IKE

[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) 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
[Amjad]
Are IKEv2 identity types acceptable as EAP identity as well?

Thanks,
-Amjad