RE: IKEv2 issue in RFC2486bis

[Tschofenig Hannes <[e-mail]>]

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:[e-mail]] 
> Sent: Sunday, August 29, 2004 7:12 PM
> To: [e-mail]
> 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 
> [e-mail] 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 [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>