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

Re: Issue: Treatment of null Identity Response

jouni.korhonen@teliasonera.com wrote:


I believe the CUI was to be a single byte of 0-bits, thus NUL rather
than NULL and not a violation.

I don't believe so.  The intent of the "hint" flavor of CUI was not to
change the underlying base type from printable-string to binary-string. 
Sending a single byte of value zero would only be permissible for a
binary-string and not a UTF-8 printable-string.


The text in the CUI draft indicates that the NUL CUI includes a single
'NUL' character.

"...
For the initial authentication, the CUI attribute will include a
single NUL character (referred to as a nul CUI).  And, during re-
authentication, the CUI attribute will include a previously received
..."


Right. This is correct, and we do not have a problem
with the empty string rule.


The CUI type is defined as: "The string identifies the CUI of the
end-user and is of type UTF8String." Of course, type UTF8String is not 
a recognized data type in RFC 2865.  Can anyone point me to a formal
definition of this, within a RADIUS RFC? 

I recall that representation originates from Diameter specs. As at some
early phases of the CUI there was direct linkage to Diameter CC
Subscription-Id-data, which is defined as UTF8String. A definition for
UTF8String is in RFC3588 (using UTF-8 transformation format as described
in RFC2279) -- not in RADIUS RFCs though.

I would prefer fixing the type to a RADIUS type (string).

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