[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKEv2 issue in RFC2486bis
i am very much in favour of your proposal for adding new IKEv2 ID type.
i have sent the ikev2 folks a mail about this issue many months ago. no
i hope it will be different now.
ps: i also dislike the mentioned paragraph from section 3.16.
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:firstname.lastname@example.org]
> Sent: Sunday, August 29, 2004 7:12 PM
> To: email@example.com
> Subject: IKEv2 issue in RFC2486bis
> 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
> firstname.lastname@example.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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.