Re: IKEv2 issue in RFC2486bis

[Jari Arkko <jari.arkko@piuha.net>]

Bernard Aboba wrote:
> > o  Define the new IKEv2 ID type as Yoshihiro suggests
> >   below.
>
>
> I'd support this alternative.  IKEv2 is already incompatible with RFC
> 2486, so this would need to be done anyway.

Question: Would this be part of the NAIbis RFC, or a
separate RFC?

> > Finally, does anyone have a full list of places where the
> > NAI can appear? Either because the protocol specs say that
> > a particular field is a NAI, or because people take a
> > particular application identifier and put it into a place
> > which traditionally carries a NAI (such as RADIUS User-Name).
> > I think we are talking about PPP, EAP, RADIUS, Diameter,
> > SIP and Mobile IPv4, but is this all? What do these specifications
> > say about non-RFC822 compliant names?
>
>
> In PPP, EAP, RADIUS and Diameter the structure of the NAI is not
> constrained, so I don't think there is an issue.
>
> In RFC 2794, it defines the NAI field as "A string in the NAI format
> defined in [1]." So I don't think there is an issue there either.

Ok. Thanks for the info.

> I didn't know that SIP utilized the NAI.  Where is this usage defined?

It is not defined directly as a NAI. It falls into the class of
fields that get copied into a place that traditionally carries
a NAI. When using HTTP digest with SIP, a system implementing
either the RADIUS or Diameter SIP application will put the
"username" field from the Digest headers into the AAA User-Name
AVP.

Here's the syntax of the "username" field from RFC 2616-2617:

       username         = "username" "=" username-value
       username-value   = quoted-string
       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
       qdtext         = <any TEXT except <">>
       quoted-pair    = "\" CHAR
       TEXT           = <any OCTET except CTLs,
                        but including LWS>
       CTL            = <any US-ASCII control character
                        (octets 0 - 31) and DEL (127)>
       CR             = <US-ASCII CR, carriage return (13)>
       LF             = <US-ASCII LF, linefeed (10)>
       SP             = <US-ASCII SP, space (32)>
       HT             = <US-ASCII HT, horizontal-tab (9)>
       CRLF           = CR LF
       LWS            = [CRLF] 1*( SP | HT )

My interpretation is that this allows any type of text
(even non-ASCII), except ASCII control characters. There's
also a special treatment for " and \. So it seems that we
can carry an internationalized username here, or even a
privacy NAI (but the latter would not make sense with
current Digest algorithms).

--Jari

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