[Ipsec] IKEv2 identifier issue with EAP
Jari Arkko <jari.arkko@kolumbus.fi> Mon, 16 August 2004 11:30 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 HAA27346 for <ipsec-archive@lists.ietf.org>; Mon, 16 Aug 2004 07:30:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwfbd-0007sp-He; Mon, 16 Aug 2004 07:24:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwfV6-0007Dn-Rn for ipsec@megatron.ietf.org; Mon, 16 Aug 2004 07:18:04 -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 HAA26971 for <ipsec@ietf.org>; Mon, 16 Aug 2004 07:18:04 -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 1Bwfat-0007b5-CN for ipsec@ietf.org; Mon, 16 Aug 2004 07:24:03 -0400
Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7GBEJg15971 for <ipsec@lists.tislabs.com>; Mon, 16 Aug 2004 07:14:19 -0400 (EDT)
Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7GBFAw4011621 for <ipsec@lists.tislabs.com>; Mon, 16 Aug 2004 07:15:10 -0400 (EDT)
Received: from p2.piuha.net(131.160.192.2) by nutshell.tislabs.com via csmap (V6.0) id srcAAAqTa4Pw; Mon, 16 Aug 04 07:15:06 -0400
Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id D85EE89868; Mon, 16 Aug 2004 14:17:52 +0300 (EEST)
Message-ID: <412097C9.7080206@kolumbus.fi>
Date: Mon, 16 Aug 2004 14:17:29 +0300
From: Jari Arkko <jari.arkko@kolumbus.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IPsec WG <ipsec@lists.tislabs.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Content-Transfer-Encoding: 7bit
Cc: Bernard Aboba <aboba@internaut.com>
Subject: [Ipsec] IKEv2 identifier issue with EAP
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: 7bit
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