Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication

Yoav Nir <ynir@checkpoint.com> Wed, 11 November 2009 14:11 UTC

Return-Path: <ynir@checkpoint.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 3F8B328C187 for <ipsec@core3.amsl.com>; Wed, 11 Nov 2009 06:11:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 qAV3nvwzPzkL for <ipsec@core3.amsl.com>; Wed, 11 Nov 2009 06:11:47 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 00F003A687C for <ipsec@ietf.org>; Wed, 11 Nov 2009 06:11:47 -0800 (PST)
X-CheckPoint: {4AFAC31A-6-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B102429C004; Wed, 11 Nov 2009 16:12:14 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9449229C002; Wed, 11 Nov 2009 16:12:14 +0200 (IST)
X-CheckPoint: {4AFAC31A-0-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nABECDc6012140; Wed, 11 Nov 2009 16:12:14 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 11 Nov 2009 16:12:16 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "Srinivasu S R S Dhulipala (srinid)" <srinid@cisco.com>
Date: Wed, 11 Nov 2009 16:12:11 +0200
Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAPauthentication
Thread-Index: Acpi2PjABhslUgobT2munaiqCel1RQ==
Message-ID: <4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com>
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>
In-Reply-To: <3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-11-468657087"; protocol="application/pkcs7-signature"
MIME-Version: 1.0
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "Amjad Inamdar \(amjads\)" <amjads@cisco.com>
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: Wed, 11 Nov 2009 14:11:49 -0000

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:

> Hi Yoav,
> 
> Thanks for the quick response. Please see inline.
> 
> -----Original Message-----
> From: Yoav Nir [mailto:ynir@checkpoint.com] 
> Sent: Wednesday, November 11, 2009 7:23 PM
> To: Srinivasu S R S Dhulipala (srinid)
> Cc: Amjad Inamdar (amjads); ipsec@ietf.org
> Subject: Re: [IPsec] Clarification on identities involved in
> IKEv2EAPauthentication
> 
> 
> On Nov 11, 2009, at 3:39 PM, Srinivasu S R S Dhulipala (srinid) wrote:
>> 
>>> 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.
> 
> 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.
> 
> 
> 
> Scanned by Check Point Total Security Gateway.