Re: [IPsec] Clarification on identities involved in IKEv2EAP authentication

"Srinivasu S R S Dhulipala (srinid)" <srinid@cisco.com> Wed, 11 November 2009 13:39 UTC

Return-Path: <srinid@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 256E528C326 for <ipsec@core3.amsl.com>; Wed, 11 Nov 2009 05:39:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 RA2dNPyQRgHh for <ipsec@core3.amsl.com>; Wed, 11 Nov 2009 05:39:19 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4790428C324 for <ipsec@ietf.org>; Wed, 11 Nov 2009 05:39:19 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAH9N+kpAaHte/2dsb2JhbADEH5gZgjeCBQSBa3s
X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="103538734"
Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2009 13:39:47 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nABDdj0o025345; Wed, 11 Nov 2009 13:39:46 GMT
Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 19:09:45 +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: Wed, 11 Nov 2009 19:09:44 +0530
Message-ID: <3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.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 IKEv2EAP authentication
Thread-Index: Acph/T6sbxIgyziASaiLecrXjL4UOAA1qQFw
References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com>
From: "Srinivasu S R S Dhulipala (srinid)" <srinid@cisco.com>
To: "Yoav Nir" <ynir@checkpoint.com>, "Amjad Inamdar (amjads)" <amjads@cisco.com>
X-OriginalArrivalTime: 11 Nov 2009 13:39:45.0536 (UTC) FILETIME=[6E39F000:01CA62D4]
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAP authentication
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: Wed, 11 Nov 2009 13:39:20 -0000

Hi Yoav,

Please see inline for [SRINI].

Thanks,
Srinivas

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


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.

> 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

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


   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