Subject: (radius) More detail on Proxy

From: Carl Rigney <[email-masked]>
Date: Fri, 26 Feb 1999 09:25:54 -0800 (PST)

I'm planning to include the following detailed description of Proxy under
the Operations section in the new Draft (now only hours away).
Comments welcome.

With proxy RADIUS, one RADIUS server forwards an authentication (or
accounting) request to a remote RADIUS server, and returns its reply to
the network access server (NAS).  A common use for proxy RADIUS is
roaming.  Roaming permits two or more administrative entities to allow
each other's users to dial in to either entity's network for service.

The NAS sends its RADIUS access-request to the "forwarding server"
which forwards it to the "remote server."  The remote server sends a
response (Access-Accept, Access-Reject, or Access-Challenge) back to
the forwarding server, which sends it back to the NAS.  The choice of
which server to forward the request to is based on the authentication
"realm."  A realm can either be based on part of the User-Name, for
example the part following an at ("@") sign (a "named realm"), or a
Called-Station-Id (a "numbered realm"), or using whatever other
criteria the forwarding server is configured to use.  Frequently, a
fully qualified domain name is used as the named realm to provide
uniqueness.

A RADIUS server can function as both a forwarding server and a remote
server, serving as a forwarding server for some realms and a remote
server for other realms.  One forwarding server can forward to any
number of remote servers.  A remote server can have any number of
servers forwarding to it and can provide authentication for any number
of realms.  One forwarding server can forward to another forwarding
server to create a chain of proxies, although care must be taken to
avoid introducing loops.

The following scenario illustrates the communication between a NAS and
the forwarding and remote RADIUS servers:

1.  A NAS sends its access-request to the forwarding server.

2.  The forwarding server forwards the access-request to the remote
server.

3.  The remote server sends an access-accept, access-reject or
    access-challenge back to the forwarding server.  For this example,
    an access-accept is sent.

4.  The forwarding server sends the access-accept to the NAS.

A forwarding server may either perform its forwarding function in a
pass through manner, where it sends retransmissions on as soon as it
gets them, or it may take responsibility for retransmissions, for
example in cases where the network link between forwarding and remote
server has very different characteristics than the link between NAS and
forwarding server.

Extreme care should be used when implementing a proxy server that takes
responsibility for retransmissions so that its retransmission policy is
robust and scalable.

We now examine each step in more detail.

1.  A NAS sends its access-request to the forwarding server.  The
forwarding server unencrypts the User-Password, if present, using the
shared secret it knows for the NAS.  If a CHAP-Password attribute is
present in the packet
 and no CHAP-Challenge attribute is present, the forwarding server MUST
leave the Request-Authenticator untouched or copy it to a
CHAP-Challenge attribute.

The forwarding server MAY add one Proxy-State attribute to the packet.
If it does, the Proxy-State MUST appear after any other Proxy-States in
the packet.  The forwarding server MUST NOT modify any other
Proxy-States that were in the packet and MUST NOT change the order of
any attributes of the same type, including Proxy State.

2. The forwarding server encrypts the User-Password, if present, using
the secret it shares with the remote server, sets the Identifier as
needed, and forwards the access-request to the remote server.

3. The remote server (if the final destination) verifies the user using
User-Password, CHAP-Password, or such method as future extensions may
dictate, and returns an access-accept, access-reject or
access-challenge back to the forwarding server.  For this example, an
access-accept is sent.  The remote server MUST copy all Proxy-State
attributes (and only the Proxy-State attributes) in order from the
access-request to the response packet, without modifying them.

4.  The forwarding server verifies the Response Authenticator using the
secret it shares with the remote server, and silently discards the
packet if it fails verification.  If the packet passes verification,
the forwarding server removes the last Proxy-State (if it attached
one), signs the Response Authenticator using the secret it shares with
the NAS, restores the Identifier to match the one in the original
request by the NAS, and sends the access-accept to the NAS.

A forwarding server may need to modify attributes to enforce local
policy.  Such policy is outside the scope of this document, with the
following restrictions.  A forwarding server MUST not modify existing
Proxy-State, State, or Class attributes present in the packet.

Implementers of forwarding servers should consider carefully which
values it is willing to accept for Service-Type.  Careful consideration
must be given to the effects of passing along Service-Types of
NAS-Prompt or Administrative in a proxied access-accept, and
implementers may wish to provide mechanisms to block those or other
service types, or other attributes.  Such mechanisms are outside the
scope of this document.

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

---

From: MARC DE VRIES WE41/KT <[email-masked]>
Date: Mon, 01 Mar 1999 13:55:24 +0200 (MET-DST)

[snipped a lot]
>Proxy-State, State, or Class attributes present in the packet.

The above contains a number of proxy implementation guidelines whereas RADIUS
should only care about the interface (RADIUS) between clients, proxies and
servers.

Example 1: Proxy-State

RADIUS requirement:
A server must reply to a client with the same Proxy-State attributes (and in
the same order?) as it received in the request.

Server implementation:
1. as in the proposed text
2. the server stores the received Proxy-States but does not forward them to the
next hop server. The server retrieves the Proxy-States when replying to the
client.
3. ?

Example 2: Class

RADIUS requirement:
A client must send the same Class attributes (and in the same order?) in
Accounting-Requests as it received in Access-Accept.

Client implementation:
1. similar to propsed text (forward all to next-hop client)
2. the client stores the received Classes but does not forward them to the
next-hop client. The client retrieves the Classes when  forwarding
Accounting-Requests to the next-hop server.
3. ?

Requiring the Class and Proxy-State attributes to be passed on end-to-end is
something that was discussed in the ROAMOPS workgroup long ago, and had to do
with auditing in roaming environments. As far as I know, this was recommended
in such roaming environments as a policy, but should not be a RADIUS protocol
requirement.

regards,

Marc.

-

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Mon, 01 Mar 1999 10:39:51 -0800

> the same order?) as it received in the request.

I'd like to see some added clarity on order here.  There are some
current
interoperatability issues with whether Proxy-State must be returned
before the other attributes or not.  I know this is a RADIUS RFC and
not proxy, but people still base Proxy implementations soley on this
RFC and a little extra definition goes a long way...
 
> next hop server. The server retrieves the Proxy-States when replying to the

I don't think either are incorrect. 

> Accounting-Requests to the next-hop server.

I don't think this is the same. A client doesn't proxy a request, a 
server does.  I would assume that in proxy, receiving a CLASS attribute
in the Accounting Request means that is MUST be forwarded.

-- 

Dale E. Reed Jr.      Emerald and RadiusNT
__________________________________________
IEA Software, Inc.    www.iea-software.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: MARC DE VRIES WE41/KT <[email-masked]>
Date: Tue, 02 Mar 1999 11:11:31 +0200 (MET-DST)

>RFC and a little extra definition goes a long way...

Implementations currently relying on preservation of Proxy-State ordering are
making assumptions that lead to interop issues. 
However, something may need to be added to RADIUS to allow multiple
Proxy-States to go end-to-end. What I mean is, that each proxy in the chain
should be able to identify its own Proxy-State. This can be done by disallowing
re-ordering of the Proxy-States, or by imposing a structured value containing a
NAS-Id (FQDN if you like). I like the ordering best.

Requiring the Proxy-State attribute to be placed at the front, back or
up-side-down-bent-over does not seem useful, as the relative position of
different-type attributes has never been guaranteed (this even forced TAG
format attributes to be invented...), and should not be unless it is the only
way to make the protocol work.

>in the Accounting Request means that is MUST be forwarded.

Replacing 'client' with 'proxy' and 'next-hop-client' with 'NAS'  will probably
make more sense.

If we define closer-to-NAS as downstream, the example becomes:

A proxy server stores the Class values received from the upstream proxy/server,
and removes them from the Access-Accept when forwarding to the downstream
nas/proxy. 
The proxy then adds the Class values to the Accounting-Request when forwarding
to the upstream proxy/server.

Anyway, the point is: the proposed text specifies server implementation
requirements and enforces a specific policy (end-to-end passing), two things I
would not expect to see in a protocol specification unless it is the only way
to make the protocol work.

regards,

Marc.

-

---

From: "Steven P. Crain" <[email-masked]>
Date: Tue, 2 Mar 1999 14:05:15 -0500 (EST)

> accounting) request to a remote RADIUS server, and returns its reply to
                                                             ^^^
unclear antecedant.  I think you mean the remote server's reply.

Also, this downplays the proxy server's role as gatekeeper.  It doesn't
necessarily send the reply it got back to the NAS.  It is likely to at
least tweak it a little, SHOULD do sanity checking on the attributes, and
might send back a completely different responce if it likes.  Something
like "With proxy RADIUS, one RADIUS server forwards an authentication (or
accounting) request to a remote RADIUS server, and bases its reply to the
network access server (NAS) on the reply it got from the remote RADIUS
server" might be more correct.

> fully qualified domain name is used as the named realm to provide

This could be misleading.  In my operation, different customers have
password entries on different hosts.  E.g.

User                    Host
[email-masked]      apple
[email-masked]         orange
[email-masked]        apple
[email-masked]         orange
[email-masked]		radius.another.net

The choice of remote server in our case is based on looking up the host
associated with the whole User-Name, not some portion of it.

I would change "A realm can either be based on part of the User-Name" to
"A realm can either be based on all or part of the User-Name."

> The forwarding server MAY add one Proxy-State attribute to the packet.

Though it probbaly isn't useful, I would think it could add more than one
if the need arose?

> any attributes of the same type, including Proxy State.

Hmmm, I recall hearing of implementations that *didn't* work like this.
One did something to encode the existing Proxy-States, something like
"state" -> "nas1.somewhere.org:state" with some provision for handling a
state that was too long for the prefix.  Isn't the important part that it
be able to restore the Proxy-State attributes to their original state in
whatever replies it sends back to the NAS?  Do we need to make such strict
rules when they aren't really necessary for interoperability?

> attributes (and only the Proxy-State attributes) in order from the
                  ^^^^
This is unclear.  Do you mean "the remote server MUST NOT copy any other
attributes" or "the remote server is not required to copy any other
attributes?"

> one), signs the Response Authenticator using the secret it shares with

Or otherwise restores the Proxy-State to what was received from the NAS.

> Proxy-State, State, or Class attributes present in the packet.

A forwarding server might need to do other, more complex manipulations as
well.  E.g. if the Access-Accept contains unacceptable avps it might want
to return a NAK to the NAS.  If it gets a NAK it might want to forward the
request to another remote server, and so forth.   Also, if it changes the
response from ACK to NAK, it doesn't make as much sense for it to be
required to keep the State & Class attributes intact.

I also disagree with the "MUST" re modifying Class and possibly State.  In
our case, we proxy auth requests to customers, but we do not proxy
accounting requests to them.  We use the Class attribute to record which
account to bill for the session.  Obviously, we don't want the customer to
be able to send a Class attribute that would conflict with that.  Perhaps
something similar is needed here as my comments regarding Proxy-State
above.  Class should not be messed with in an irreversible manner, if the
accounting messages will also be proxied.

-- 
Steven P. Crain, Development
http://www.shore.net/~scrain
Shore.Net: Local Ties... World Class Connections

-

---

From: "Steven P. Crain" <[email-masked]>
Date: Tue, 2 Mar 1999 14:18:37 -0500 (EST)

> in the Accounting Request means that is MUST be forwarded.

As far as the remote server is concerned, the proxy is an NAS.  The only
requirement on sending Class attributes should be that the remote server
requested them in the Access-Accept.  So, in general if you add a Class to
the Access-Accept, you could safely remove that same Class (and any others
that the remote server had not requested) from Accounting messages.

That brings up another point -- is a NAS allowed to send Class attributes
in Accounting messages that were not requested at Authentication time?
That would seem to be an abuse of the intended purpose of the Class
attribute, but is basically equivalent to a proxy server not cleaning up
after itself and removing Class attributes it had requested from
accounting messages it forwards.

-

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 5 Mar 1999 07:51:44 -0800

Steven P. Crain shaped the electrons thusly: 

> Also, this downplays the proxy server's 
> role as gatekeeper.  It doesn't necessarily 
> send the reply it got back to the NAS.  

Indeed. This is how proxys implement policy,
as described in draft-ietf-roamops-auth-10.txt. 
As part of that policy function, MERIT defined
Acct-Status-Type=Proxy-Stop (6). This is used 
when an Access-Reject is sent to the NAS
despite getting an Access-Accept from the
RADIUS server. This should be included in the
proxy section. 
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.