Subject: Re: (radius) Zero-length strings (fwd)

From: MegaZone <[email-masked]>
Date: Wed, 24 Feb 1999 21:59:08 -0800 (PST)

Once upon a time Steven P. Crain shaped the electrons to say...
>Attribute not included:
>	attribute is not relevant, and any default behavior shoul be used.

Fine.

>Attribute included, length field=2:
>	integer/date types: not permitted, or possibly a shorthand for 0
>	string types: a zero-length string

My concern here is how existing implementations will handle it.  What if
a server sends a zero-length string to a client in say Framed-Route?  I
would expect it to ignore it - but will any today be confused?  So far
we've heard mostly form server folks that the servers should be ok.  Will
all clients gracefully handle zero-length strings?

>Attribute included, 0 value:
>	Set the attribute to 0.  *Not* just use the default on the client
>or whatever.  That should be implied by absense of the attribute, not some
>hacked in value.

Unfortunately this will break or change current behavior.  For example
Framed-IP-Address = 0.0.0.0 will, in my experience, result in default
behavior.  You wouldn't want a 0 value IP being assigned.  Of course, on
the other hand, I would like to see Idle-Timeout = 0 turn it off, as it
stands today you can't override a locally configured timer and turn it off.
So people are using the kludge of setting it to a huge value.

>	State, to cause an empty State to be passed back by the server to
>the client.

I don't understand what an empty State will accomplish.

-MZ
-- 
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<URL:mailto:[email-masked]> Gweep, Discordian, Author, Engineer, me..
Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
"A little nonsense now and then, is relished by the wisest men" 781-788-0130
<URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: MegaZone <[email-masked]>
Date: Fri, 26 Feb 1999 06:31:23 -0800 (PST)

Once upon a time Jeff Weisberg shaped the electrons to say...
>Username and <Some>-Password are required to be present.

I believe that in the newer drafts User-Name is not required under specific
circumstances, such as Call-Check and EAP.

As for X-Password - can't Signature be used in place of a password?  Or am
I misreading the intent of Signature?

In any case, you can encode a null password as User-Password - it is just all
padding.

-MZ

-

---

From: MegaZone <[email-masked]>
Date: Fri, 26 Feb 1999 06:39:05 -0800 (PST)

Once upon a time Carl Rigney shaped the electrons to say...
>I'm still unsure with regard to users just hitting return on the
>User-Name.  I'm not sure a zero-length username is valid from an
>authentication standpoint, and if authentication isn't being done, its
>not a matter for RADIUS.

I think that it could be - the server could consider a z-l u-n to indicate
authentication should fall back to a field like Calling-Station-Id.  Or
perhaps there is a public access port and it can allow z-l u-n based on 
the NAS and port, etc.  The basic point here is that you can't prove a
negative, and as long as there is the possibility of this being a valid
authentication under any usage model then it should be allowed.  The 
protocol should not force the business model - or we'll get kludges with
faked User-Name fields, or invite non-compliance.

Zero-Length User-Name is something I can see a justification for.  I'm still
not convinced that Z-L State or Class is meaningful.  If some vendor used it
as a signalling kludge in the past, I still don't see that as enough 
justification to include it.  Whereas a Z-L U-N means something - the user
hit Enter without entering a name, sent no name in PAP, etc - which is
different from no User-Name AVP at all (as in Call-Check), I don't see that
a Zero-Length State or Class are meaningful or differentiated from just not
being present.

-MZ