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