RE: [Ipsec] IKEv2 identifier issue with EAP
"Charlie Kaufman" <charliek@microsoft.com> Tue, 17 August 2004 01:04 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26103 for <ipsec-archive@lists.ietf.org>; Mon, 16 Aug 2004 21:04:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwsDS-0004hQ-QS; Mon, 16 Aug 2004 20:52:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwsD2-0004SL-QK for ipsec@megatron.ietf.org; Mon, 16 Aug 2004 20:52:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25576 for <ipsec@ietf.org>; Mon, 16 Aug 2004 20:52:15 -0400 (EDT)
Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwsIw-0008Vf-JQ for ipsec@ietf.org; Mon, 16 Aug 2004 20:58:23 -0400
Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7H0mTg02890 for <ipsec@lists.tislabs.com>; Mon, 16 Aug 2004 20:48:29 -0400 (EDT)
Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7H0nN1C024698 for <ipsec@lists.tislabs.com>; Mon, 16 Aug 2004 20:49:23 -0400 (EDT)
Received: from mail1.microsoft.com(131.107.3.125) by nutshell.tislabs.com via csmap (V6.0) id srcAAA7kaapW; Mon, 16 Aug 04 20:49:21 -0400
Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 16 Aug 2004 17:52:10 -0700
Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 17:52:07 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ipsec] IKEv2 identifier issue with EAP
Date: Mon, 16 Aug 2004 17:52:12 -0700
Message-ID: <F5F4EC6358916448A81370AF56F211A50394C021@RED-MSG-51.redmond.corp.microsoft.com>
Thread-Topic: [Ipsec] IKEv2 identifier issue with EAP
Thread-Index: AcSDhIsjfE4A/v76TCu8+IkIn5ITngAbUgZw
From: Charlie Kaufman <charliek@microsoft.com>
To: Jari Arkko <jari.arkko@kolumbus.fi>, IPsec WG <ipsec@lists.tislabs.com>
X-OriginalArrivalTime: 17 Aug 2004 00:52:07.0798 (UTC) FILETIME=[6BDAD960:01C483F4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Content-Transfer-Encoding: quoted-printable
Cc: Bernard Aboba <aboba@internaut.com>
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable
I agree that this is likely to become a problem, that any of your 'possible solutions' could be used to fix it (except that I don't believe the first two 'define the problem away' were serious proposals), and that the community SHOULD agree on one standard approach to maximize interoperability. My favorite would be: o Go against the SHOULD NOT when the given NAI requires this. ...because this also addresses the identity type hint that you say might be coming. But others have argued heatedly that it is important to minimize the number of messages in an IKE exchange, and this would result in an eight message exchange while some of the other proposals work in six. I'm really glad it's not my job anymore to herd the cats towards one approach or the other. --Charlie p.s. If you are going to define a new ID type, it would need to be added to the IANA registry for IKEv2. The procedure for this is "expert review". It could probably be defined in some EAP RFC and ratified by some expert chosen by the security ADs, but I don't know. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Monday, August 16, 2004 4:17 AM To: IPsec WG Cc: Bernard Aboba Subject: [Ipsec] IKEv2 identifier issue with EAP First some background: In traditional EAP usage, the client's identifier has been determined through the EAP Identity Request/Response exchange. The identifier is typically a Network Access Identifier (NAI). Basically an identifier similar to an e-mail address, used to identify the user and to find the right home network in case of a roaming user. IKEv2-14 says the following: Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used. it also defines one of the identity type as follows: ID_RFC822_ADDR 3 A fully-qualified RFC822 email address string, An example of a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not contain any terminators. In the RADEXT and EAP WGs, we have recently discussed some problems that this causes. Here are the issues: 1. A revision of the NAI specification, RFC 2486bis, intends to extend the existing user@domain format in draft-arkko-roamops-rfc2486bis-02.txt, partially based on existing practise. This spec is currently in WGLC in the RADEXT WG. One of the extensions is to allow the client's identity to be hidden from the access server / IKEv2 gateway, if the used EAP method supports end-to-end encrypted tranmission of the identity. Syntactically, this happens through specifying an empty username, "@domain" but keeping the domain pawrt in order to make the AAA routing possible. The issue with IKEv2 is strictly speaking, this string would be illegal in RFC 822. Hence an IKEv2 implementation can not be relied upon to accept such "privacy" user names. 2. Another extension from this draft is internationalized NAIs. The domain parts are IDNs, i.e., converted to ASCII via a specific mapping, but the username part is UTF-8. Again, this is strictly speaking not conformant to RFC 822, so sending an internationalized username via IKEv2 might not be possible. For instance, someone might be assigned a username for WLAN access, but the usage of this username for IKEv2 purposes might not be possible if it contains international characters. Some of the possible solutions to avoid this problem include o Decide that support of privacy & international usernames is not necessary in IKEv2. o Remove the privacy and international username (not domain) parts from RFC 2486bis. o Change the international username part so that instead of UTF-8, it uses a IDN-like ASCII mapping which can represent non-ASCII characters but it looks like ASCII to the carrier. Either remove the privacy feature or just say it can not be used in all carrier protocols. o Define a new IKEv2 ID type to carry the new types NAIs. (If so, would this type be defined in the NAIbis, IKEv2 or some other draft?) o Rely on IKEv2 implementations to not check the contents of the identifier for RFC 822 compliance. o Go against the SHOULD NOT when the given NAI requires this. 3. Ongoing work (and some existing practise) provides some information through the EAP identity request. More specifically, the client can get a hint of what type of identifier it should offer. See draft-adrangi-eap-network-discovery-03.txt. This functionality does not appear to be present when running EAP over IKEv2. (I have not heard of any customer who wanted this functionality in this context, but I'd like to avoid special cases where possible.) Comments? --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec
- [Ipsec] IKEv2 identifier issue with EAP Jari Arkko
- RE: [Ipsec] IKEv2 identifier issue with EAP Charlie Kaufman