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

From: Jonathan Garini <[email-masked]>
Date: Tue, 22 Dec 1998 14:33:49 +0200

> 
> 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).
>
 
Exactly. Apparently Livingston\Merit does not work this way.
 
> > If we try to send the field as undistinguished octets it 
> does not work with
> > Merit\Livingston.
> 
> Can you expand on this?  What doesn't work?

What happens in Livingston\Merit is that they do not accept this attribute
as octets but rather as a string, and since the octets sent by us contain \0
(line terminator when used as a string), they (Livingston\Merit) truncate
this attribute, and the user  can not be authenticated.

> 
> > My thoughts are that:
> > 
> > 1. SHOULD is not good here as it does not allow 
> interoperability between
> > different Radius Servers.
> 
> I agree. 
> 
> > 2. The Merit\Livingston ASCII implementation should not be 
> the preferred
> > 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.
> 
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: David Bolen <[email-masked]>
Date: Tue, 22 Dec 98 10:19:39 EST

> Exactly. Apparently Livingston\Merit does not work this way.

Yup - from what I could tell all String attributes are treated as NUL
terminated information internally.  I ran into this when trying to
interoperate with a customer that was using one of the publically
available Merit releases a while back.

> this attribute, and the user  can not be authenticated.

What I did in my server is add a server based flag for proxying such
that if enabled for a given server, I "encoded" any Proxy-State
attributes to remove any NULs (just simple byte prefixing with 0xFF).
There's no other way that I know of to avoid the problem without
changing the code (throughout it I thought at the time if you want to
cover all String attributes) unless you can guarantee that your state
will never have an octet of 0 in it (mine represented an internal
state pointer, so it clearly could at times).

> > > different Radius Servers.

Well, except that I think the phrase about treating it as
undistinguished octets is more of a server implementation issue than
an interoperability one.  Earlier in the section is the phrase:

      This Attribute is available to be sent by a proxy server to
      another server when forwarding an Access-Request and MUST be
      returned unmodified in the Access-Accept, Access-Reject or
      Access-Challenge.

which it seems to me is enough of a statement to enforce
interoperability.  If a server wants to internally re-encode the value
in some way which isn't using undistinguished octets I don't care as
long as it gives it back to me unchanged as required by the above
phrase.  It's this MUST which the older Livingston/Merit code (I can't
speak for any of the later, non-PD versions) breaks.

-- David

/-----------------------------------------------------------------------\
 \               David Bolen              \  Internet: [email-masked]    /
  |        ANS Communications, Inc.         \   Phone: (914) 701-5327 |
 / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
\-----------------------------------------------------------------------/
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.