Re: IKEv2 issue in RFC2486bis
Jari Arkko <jari.arkko@piuha.net> Sat, 14 August 2004 07:46 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Sat, 14 Aug 2004 07:48:04 +0000
Message-ID: <411DC36A.4070307@piuha.net>
Date: Sat, 14 Aug 2004 10:46:50 +0300
From: Jari Arkko <jari.arkko@piuha.net>
Reply-To: jari.arkko@piuha.net
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316
MIME-Version: 1.0
To: Yoshihiro Ohba <yohba@tari.toshiba.com>
Cc: radiusext@ops.ietf.org
Subject: Re: IKEv2 issue in RFC2486bis
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thanks for bringing this issue up, Yoshihiro. I think this problem is serious and we need to decide what to do about it. >From the 10.000 ft point of view, I see the following possibilities: 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 the new IKEv2 ID type as Yoshihiro suggests below. Finally, does anyone have a full list of places where the NAI can appear? Either because the protocol specs say that a particular field is a NAI, or because people take a particular application identifier and put it into a place which traditionally carries a NAI (such as RADIUS User-Name). I think we are talking about PPP, EAP, RADIUS, Diameter, SIP and Mobile IPv4, but is this all? What do these specifications say about non-RFC822 compliant names? --Jari Yoshihiro Ohba wrote: > Hi, > > I had a discussion with Jari, Bernard and Pasi on an IKEv2 issue of > RFC2486bis and the following is the summary of the discussion > (please correct if I am wrong): > > Section 3.16 of draft-ietf-ipsec-ikev2-14.txt says: > > " > 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. > " > > This means that an RFC2486bis NAI may be carried in an IKEv2 Identity > Payload when EAP is used in IKEv2. In this case, there is an issue of > which ID Type of IKEv2 Identification Payload is appropriate to carry > the RFC2486bis NAI. > > One possibility is using ID_RFC822_ADDR, but RFC822 address is not > compatible with RFC2486bis NAI at least in that (i) RFC822 address > does NOT allow the characters preceding "@" (i.e., local-part) to be > null and (ii) RFC822 address does NOT allow ASCII control characters > to appear in local-part without being quoted as quoted-string (thus a > UTF-8 encoded username with containing ASCII control characters is not > compatible with local-part of RFC822 address.) > > Since IKEv2 specification does not prohibit an implementation to > perform strict check against RFC 822 format and returns an error > Notification with "INVALID_SYNTAX" when the strict check fails, I > think using ID_RFC822_ADDR for RFC2486bis NAI has an interoperability > problem. Using ID_KEY_ID is not appropriate to carry RFC2486bis > either, since it is used for carrying certain proprietary types of > identification. > > To solve the problem, I would suggest defining a new IKEv2 > Identification Payload Type to carry RFC2486bis NAI. > > Also, draft-ietf-ipsec-ikev2-iana-02.txt says: > > " > 7.1 Amending formula for IKEv2 Identification Payload ID Types > > IKEv2 Identification Payload ID Types may be allocated by > Specification Required. > " > > So I think RFC2486bis could be the Specification where the new IKEv2 > ID Type is defined. > > This was not discussed, but when a given RFC2486bis NAI also conforms > to RFC822 address, I think such an NAI can also be carried as > ID_RFC822_ADDR ID type. > > Best regards, > > Yoshihiro Ohba > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://psg.com/lists/radiusext/> > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>
- RE: IKEv2 issue in RFC2486bis Tschofenig Hannes
- Re: IKEv2 issue in RFC2486bis Jari Arkko
- Re: IKEv2 issue in RFC2486bis Bernard Aboba
- Re: IKEv2 issue in RFC2486bis Jari Arkko
- Re: IKEv2 issue in RFC2486bis Bernard Aboba
- Re: IKEv2 issue in RFC2486bis Jari Arkko
- Re: IKEv2 issue in RFC2486bis Jari Arkko
- IKEv2 issue in RFC2486bis Yoshihiro Ohba