Subject: Re: (radius) RADIUS proxy

From: Barney Wolff <[email-masked]>
Date: Tue, 16 Mar 1999 11:53 EST

> From: Alan DeKok <[email-masked]>
> Date: Tue, 16 Mar 1999 08:40:09 -0500
> 
>   What exactly is Proxy-State for, then?  Is it simply a tag to make
> it easier to implement simple proxy servers?  So far as I can see, the
> Proxy-State attribute is *informational*, and should not be use to
> make any sort of decisions on the proxy server.

The original intent was to make a stateless proxy possible.  That is,
the proxy could encode all its state into the attribute, keeping none.
I don't know how the proxy was supposed to choose the ID field if it
truly kept no state, but that was the idea, anyway.

I would object to language denying the proxy the right to strip proxy-
state and keep it internally, to send back in its response.  My proxy
has to deal with a server that does not understand proxy-state, so
that's what I do.  If anybody objects, I would claim that I'm not
really a proxy, but a server that happens to use RADIUS as a way to
communicate with its database.  Surely that cannot be forbidden, as
a proxy from RADIUS to TACACS or some other auth protocol would be
faced with the same issue.

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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 16 Mar 1999 14:58:02 -0500

> the proxy could encode all its state into the attribute, keeping none.

  That's what I thought.  But subject to recent discussions, probably
impossible.

  So the Proxy-State field is mostly useless, especially since many
RADIUS servers expect to parse it in a particular
implementation-defined format.

> that's what I do.

  I hope that this behaviour is configurable.

>  If anybody objects, I would claim that I'm not really a proxy, but
> a server that happens to use RADIUS as a way to communicate with its
> database.  Surely that cannot be forbidden, as a proxy from RADIUS
> to TACACS or some other auth protocol would be faced with the same
> issue.

  Hey, it can't be any worse than other implementation-specific RADIUS
decisions I've seen.

  Alan DeKok.
-