[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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