Re: [Ipsec] IKEv2 identifier issue with EAP

[Jari Arkko <[e-mail]>]

Copying the RADEXT list on my question to the IPsec WG
and Charlie Kaufman's response:

Charlie Kaufman wrote:
> 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: [e-mail] [mailto:[e-mail]] 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, "[e-mail]".  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.)


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>