[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKEv2 issue in RFC2486bis
hi yoshi,
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
reply.
i hope it will be different now.
ciao
hannes
ps: i also dislike the mentioned paragraph from section 3.16.
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> Sent: Sunday, August 29, 2004 7:12 PM
> To: radiusext@ops.ietf.org
> Subject: IKEv2 issue in RFC2486bis
>
> 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/>