Subject: (radius) Re: one iesger's review of draft-ietf-radius-radius-v2-04.txt

From: Randy Bush <[email-masked]>
Date: Wed, 23 Feb 2000 17:59:22 -0800

we will now get a tour through one of the iesg's fads of the season,
character sets and representations.

the least pain will be to

  o come up with specific and clear responses to the issues which are
    actually already covered but need to be explained to someone whose
    reading of the draft was for review purposes, i.e. they never have
    and never will use or implement radius.

  o for those issues which warrant document changes, make those changes
    once and well, and get this thing outta here.

randy

------------

> String is also used in RADIUS to encode binary data, which does NOT use
> UTF-8.

Oh...

> Operation of the RADIUS protocol itself does not depend on the
> content of attribute fields whose codification is not specified.  Where
> the RADIUS protocol's operation does depend on the contents of a field,
> the codification IS specified in the document.

Does this mean that the attribute field is not used by the radius protocol
itself, but it might be the case that the content of the field is passed
through the layers which uses Radius, and in the end be displayed to a
user? Either directly in a dialogue/error message or in a logfile?

> If text is encoded, UTF-8 is supposed to be used, but various mays and
> shoulds are there to reflect the reality that many RADIUS
> implementations still use ASCII (a subset of UTF-8) and backwards
> compatibility is useful for interoperability.

Ok. Does this work in practice as one ISP (for example) or otherwise
"island of Radius usage" checks and defines whether UTF-8 is in use or just
ASCII?

>> I think all of the issues can be solved by an introduction stating that
>> every time the term "text" or "string" (or such) is used, UTF-8 encoded
>> ISO 10646 MUST be used.
> 
> It already states:
> 
>   Note that a "string" in RADIUS does not terminate with a NUL
>   (hex 00).  The Attribute has a length field and does not use
>   a terminator.  Strings may contain UTF-8 characters or 8-bit
>   binary data and servers and servers and clients MUST be able to deal
>   with embedded nulls.
> 
> I can up that MAY to a MUST, but if I do, it should probably go back
> to working group last call.

Here "string" is defined but not "text", and other things which then should
be "string", or? I.e. in the text below this definition of string, you use
all different kind of terms, and maybe then all of them should be "string".
Or, you should define "text" being a "string" which contains characters
which should be UTF-8 encoded. The you can use string or text in the I-Ds
for the two cases.

>>> 4.3.  Access-Reject
>>> 
>>>    Description
>>> 
>>>       If any value of the received Attributes is not acceptable, then
>>>       the RADIUS server MUST transmit a packet with the Code field set
>>>       to 3 (Access-Reject).  It MAY include one or more Reply-Message
>>>       Attributes with a text message which the NAS MAY display to the
>>>       user.
>> 
>> It "just" mentiones a "test message"...
> 
> S/he seems to have misread "text message" as "test message"?

No, I read the correct thing, but typed the wrong one :-) Issue is still
there. What is a "text message"? Is that a "string" and therefore defined
by the text above?
 
>>>       simple    Consisting only of printable UTF-8 [6] characters.
>> 
>> It is unclear to me what a "printable UTF-8" character is.
> 
> I could remove "printable" and "displayable"; in practice most people
> are using monolithic or network access identifiers, not simple,
> anyway.  Please let me know if that's what you want; I could turn
> around that change in under an hour.

I just want "simple" to be defined being something which is defined earlier
in the document, or something which is defined in what you reference. [6]
doesn't talk about "printable UTF-8 characters". Do you mean that "simple"
is a subset of "string"? In that case, what differs a "string" from
"simple"?

>>> 5.30.  Called-Station-Id
>>> 5.31.  Calling-Station-Id
>>> The codification of the range of allowed usage of this field
>>> is outside the scope of this specification.
> 
>> Even more "confusing" for me :-)
> 
> Since the contents of these fields depend on whatever the ISDN PRI or
> equivalent sends to the NAS for these values, it would have to
> reference ITU standards.  We discussed detailing these in a working
> group meeting, and it turns out that their codification is potentially
> complex, but irrelevant to the operation of the RADIUS protocol itself,
> which is just transporting the data for the benefit of the server.
> 
> Note that of the hundreds of questions I've had emailed to me over the
> years as Author, none have ever concerned these two attributes.

So? What will you define the content being in these attributes? "string"?
Same as above. I just want the I-D to use the same definitions in all
places you talk about the same thing.

>>>    Strings should use UTF-8 instead of US-ASCII and should be handled as
>>>    8-bit data.
>> 
>> Is "should" enough as one go from 7 to 8 bits? I.e. two implementations
>> can be completely incompatible if one doesn't support 8-bit data in
>> textual strings, and I see in 2119 that one might have an implementation
>> which is noy 8-bit clean for some weird reasons and still that is ok, or?
> 
> If I increase should to MUST, I break most of the existing RADIUS
> implementations, to what benefit?  The point to the working group was
> to document existing RADIUS servers, which used ASCII, and at the step
> to proposed draft the IESG requested that we use UTF-8 instead of
> ASCII, so it was added as should to indicate to implementers that they
> should add support for UTF-8 but also be backwards compatible with
> ASCII.  If we now say ASCII should not be handled, we break "be
> generous in what you accept", a cardinal virtue of internet protocols.

Understood.

Do you have multiple interoperable implementations of (client and server)
radius which uses UTF-8?
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.