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

Re: Remaining open issues for RFC-2401bis



 

> Mohan,
> 
> I'm sorry.  It's my fault that you didn't get a prompt reply.  I 
> wrote up something and then got distracted by other tasks.  Reply 
> below....
> 
> 
> >  > 4.  selector name clarification (issue #93)
> >>
> >>          Seems straightforward, and there has been no disagreement on the
> >>          mailing list.  If any disagree with the text suggested by Karen
> >>          on February 25th, please make your conerns known by the end of
> >>          the week.
> >>
> >I asked for a clarification for which i got no response. For one of the cases,
> >
> >d. a user's name in a local system context
> >    (this corresponds to ID_KEY_ID in IKEv2)
> >
> >ID_KEY_ID carries opque octet stream. So, why limit this to user's name ?
> >It looks like RFC 2401 supported OPAQUE values but i could be reading
> >it wrongly.
> >
> Well, if we allow this to be any octet string,
> then it presents complications for the user/management
> interface.  So we'd like to limit it to a text string
> containing alphanumeric characters, but not a binary
> string, etc.
> 
The value itself may be generated dynamically and added to the PAD before
the IKE exchange starts. All you need is an exact match of this content with
the content of the ID payload. If an UI cannot support certain strings, then
it won't be used automatically. Why do you have to limit them explicitly ?
It might be simpler to leave it as "opaque octet stream" specifying an
example e.g. user name.

-mohan

> Karen