Re: IKEv2 issue in RFC2486bis

[Jari Arkko <jari.arkko@piuha.net>]

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/>