Subject: (radius) Proxy state - String or Octets?

From: Jonathan Garini <[email-masked]>
Date: Tue, 22 Dec 1998 12:48:25 +0200

The RFC states the the proxy state SHOULD be treated as undistinguished
octets.
Merit and Livingstom implementations treat it as an NULL terminated ASCII
string field.
If we try to send the field as undistinguished octets it does not work with
Merit\Livingston.
 
My thoughts are that:
 
1. SHOULD is not good here as it does not allow interoperability between
different Radius Servers.
2. The Merit\Livingston ASCII implementation should not be the preferred
method as it is less flexible.
 
Regards,
Jonathan.
-- 
Jonathan  Garini - CEO 
mailto:[email-masked] <mailto:[email-masked]>  

-- 
Extent Technologies Ltd. 
3, Habonim St. 
Ramat Gan  52462 
Israel 
Phone: +972-3-7513333    Fax: +972-3-7515858 
mailto:[email-masked] <mailto:[email-masked]>        
http://www.extent.com <http://www.extent.com/>  (US)

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Tue, 22 Dec 1998 03:20:04 -0800

> Merit and Livingstom implementations treat it as an NULL terminated ASCII

First of all, strings are NOT null terminated in the RADIUS protocol,
since we have a length specifier.  Any implementation relying on NULL
terminated strings is broken. IMHO. This has nothing to do with how they
are stored by the server, just how they are tranmitted over the wire.
However, with undistringuied octets it is possible to include a 0 byte
at the end as as NULL (which should not cause a problem, since its not
a string and you shouldn't be using string functions on the data 
portion).
 
> If we try to send the field as undistinguished octets it does not work with

Can you expand on this?  What doesn't work?

> different Radius Servers.

I agree. 

> method as it is less flexible.

AFAIK, it isn't.   Since the RFC says "should be supported as
undistinguished
octets" that means that is the "preferred method".

-- 
Dale E. Reed Jr.  ([email-masked])
_________________________________________________________________
       IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQs
 Internet Solutions for Today  |   http://www.iea-software.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 22 Dec 1998 09:50:44 -0500

"Dale E. Reed Jr." <[email-masked]> writes:
> terminated strings is broken. IMHO.

  Like Ascend?  Their NAS boxes send strings with a trailing '\0', a
zero-length STATE on an initial Access-Request (i.e. 0x18 0x02), and
password attributes which are *not* 18+16n octets long.

  It's simple to work around these problems, but quite frustrating.

  Will there be a bakeoff and/or a suite of verification tests for
Radius in the coming year?  I'm uncomfortable with the idea of
approving a standard when it's ambiguous enough to support multiple
incompatible implementations.

  Alan DeKok.
-

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Tue, 22 Dec 1998 10:50:41 -0800

> incompatible implementations.

I still have a lot of the testing stuff from the previous bakeoff.
We don't have a problem supporting a site to test RADIUS over the
internet.  We use to have an open site that anyone could use to
test with RadiusNT.  If there is interest in it, I can put the testing
site back up after the first of the year, that would allow the vendors
to register thier information on where to test and who is testing.  It
would all be a closed site that you would have to pre-register for and
you could only see your results.