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

From: Jonathan Garini <[email-masked]>
Date: Tue, 22 Dec 1998 16:53:08 +0200

After Dale's comments in this matter we can now see that this not only a
problem in the RFC but actually in the fact that Merit and Livingston do not
comfort with the specification.

I would appreciate if someone from Merit and Lucent will comment on this
issue and notify whether they plan to fix this problem, as this is not
theoretical but a real life problem we are facing. 

Regards,
Jonathan.

> -----Original Message-----
> From: Dale E. Reed Jr. [mailto:[email-masked]]
> Sent: Tuesday, December 22, 1998 1:20 PM
> To: Jonathan Garini
> Cc: [email-masked]
> Subject: Re: (radius) Proxy state - String or Octets?
> 
> 
> Jonathan Garini wrote:
> > 
> > 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.
> 
> 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
> > Merit\Livingston.
> 
> Can you expand on this?  What doesn't work?
> 
> > 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: William Bulley <[email-masked]>
Date: Tue, 22 Dec 1998 10:55:32 -0500 (EST)

> theoretical but a real life problem we are facing. 

We are a little short staffed due to the holidays, etc.

I have not looked at this part of the code now or in the
recent past.  Can you give me a version number where this
is a "real life problem"?

We have an upcoming release (due out early next year) and
it would be easy to repair this in that version if it is
a real problem and one which we still have.

Regards,

web...

-- 
William Bulley                     Senior Systems Research Programmer
Merit Network, Inc.                Email: [email-masked]
4251 Plymouth Road, Suite C        Phone: (734) 764-9993
Ann Arbor, Michigan  48105-2785    Fax:   (734) 647-3185

If entropy is increasing, where is it coming from?
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.