Subject: (radius) RADIUS proxy

From: "Dmitry Goncharenko(at Crimea)" <[email-masked]>
Date: Mon, 15 Mar 1999 10:41:24 -0800

Hi,

I've got some questions after reading draft-ietf-radius-radius-v2-00.txt.

*   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.

How can I find out whether the packet was already forwarded by my server?
Proxy-state doesn't have defined structure (it's implementation dependent),
so I can use for example a vendor specific attribute, but can I add my VSA
to the Access-Request that is being forwarded? Will it be reliable to use
Request-Authenticator field to match requests?

*   1.    A NAS sends its access-request to the forwarding server.  The
*         forwarding server decrypts 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.

So, it looks like I can leave Request-Authenticator untouched in any case,
right?

*   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.

Does it mean that I should generate my own Identifier and replace the one in
the packet that I received from a RADIUS client? Why was it decided to do?
May be it's better (more secure?) to generate my own Request-Authenticator
too?

Thank you,
Dmitry.

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

---

From: Aydin Edguer <[email-masked]>
Date: Mon, 15 Mar 1999 15:38:32 -0500 (EST)

> How can I find out whether the packet was already forwarded by my server?

You check for a Proxy-State attribute with a value you recognize.

> so I can use for example a vendor specific attribute, but can I add my
> VSA to the Access-Request that is being forwarded?

No, you should not add a Vendor-Specific attribute - you should use the
Proxy-State attribute.

Yes, you should add the Proxy-State attribute to the Access-Request before
forwarding it.  Yes, the server could add a Vendor-Specific attribute, but
adding a Vendor-Specific attribute for this purpose is not necessary or
desirable.

> it looks like I can leave Request-Authenticator untouched in any case,
> right?

No, the Request-Authenticator should be regenerated by the proxy server.

  The value SHOULD be unpredictable and unique over the lifetime of
  a secret (the password shared between the client and the RADIUS server),
  since repetition of a request value in conjunction with the same secret
  would permit an attacker to reply with a previously intercepted response.

  -- RFC 2138 RADIUS

Regeneration is the best way to guarantee that the Request-Authenticator
is unique over the lifetime of the shared secret between the proxy server
and the home server.

> Does it mean that I should generate my own Identifier and replace the
> one in the packet that I received from a RADIUS client?

Yes, you should.  This is because there can only be a single example of
request tuple (IP addr, UDP port, Identifier) active at one time between
the proxy server and the home server and the best way to guarantee this
is to regenerate an Identifier, since two or more NAS may be using the
same Identifier at one time.

-

---

From: Aydin Edguer <[email-masked]>
Date: Mon, 15 Mar 1999 17:42:54 -0500 (EST)

> But the attribute is implementation dependent so any other server anywhere
> in the loop could add the same Proxy-State as I did.

Yes, that is theoretically possible.  It is, however, very unlikely to be
true, if you are judicious in choosing the format of your Proxy-State values.

For instance - you could use:
    "Vendor OID [774] : src.ip.ad.dr : srcport"
It is unlikely that someone will use the same string by chance.

> Is the anything that prohibits to add a Proxy-State with the same value
> to the request?

Sure.  Because the software should look into the packet for Proxy-State and 
if it sees that the Access-Request already has a Proxy-State that it thinks
it added, it should log an error message saying: "hey admin, I think this
packet is stuck in a loop" and possibly drop the packet.

-

---

From: David Bolen <[email-masked]>
Date: Mon, 15 Mar 99 18:12:51 EST

> packet is stuck in a loop" and possibly drop the packet.

Except that you're assuming a packet that might loop back to you as
another request would still have the Proxy-State you inserted, a
semantic which is not guaranteed, and a semantic which the recent
discussion on this list showed that some implementations would not
produce.

The inserted Proxy-State is only required to be returned unchanged by
the server you forwarded it to within it's response, and not
necessarily preserved during other forwarding hops of the request.

If you want to do loop detection based on an attribute (other than
peer address, identifier, or other items) then I think the only
guaranteed way to do it is with a VSA which is going to have to be
preserved along any forwarding hops.

-- David

/-----------------------------------------------------------------------\
 \               David Bolen              \  Internet: [email-masked]    /
  |        UUNET Technologies, 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.

---

From: Aydin Edguer <[email-masked]>
Date: Mon, 15 Mar 1999 18:27:40 -0500 (EST)

> Except that you're assuming a packet that might loop back to you...

No, I am not assuming anything.  I was answering a specific question.
The question was "Is the anything that prohibits to add a Proxy-State
with the same value to the request?".  The answer is yes.

The fact that some downstream RADIUS implementer is trying to filter out
Proxy-State attributes, has no bearing on the answer to the question.

> necessarily preserved during other forwarding hops of the request.

Correct according to RFC 2138 but possibly not correct (depending upon
interpretation) according to the new draft document that will become
the new Draft Standard for RADIUS:

                                            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.

   ...
                          A forwarding server MUST not modify existing
   Proxy-State, State, or Class attributes present in the packet.

   -- draft-ietf-radius-radius-v2-00.txt

The question is whether deleting an attribute is a subset of modifying
an attribute.  Either way, since there may always be older servers in
a stream, you cannot absolutely count on Proxy-State for loop detection.

But the specific question I was answering was not about loop detection,
it was whether you could have a packet with the same Proxy-State in it
twice.  My answer remains "no", since the server *should* not allow that
to happen, because it is a definite symptom of a loop, even if loops cannot
always be detected.

> preserved along any forwarding hops.

Excuse me, but how is that guaranteed?  A proxy server can filter out
Vendor-Specific attributes just as easily as it can filter out the
Proxy-State.  In fact, some RADIUS servers, for better or for worse,
will filter out any unknown Vendor-Specific attribute automatically.

-

---

From: "Dmitry Goncharenko(at Crimea)" <[email-masked]>
Date: Tue, 16 Mar 1999 01:47:27 -0800

>to happen, because it is a definite symptom of a loop, even if loops cannot

May be it makes sense to rewrite the paragraph about a proxy like this:

    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 add
    a Proxy-State attribute with a value that already exists in the packet
for another Proxy-State.
    The forwarding server MUST NOT modify or delete 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.

Dmitry.

-

---

From: "Dmitry Goncharenko(at Crimea)" <[email-masked]>
Date: Tue, 16 Mar 1999 01:47:21 -0800

>It is unlikely that someone will use the same string by chance.

It's unlikely but possible.

>packet is stuck in a loop" and possibly drop the packet.

But the Proxy-State from your example could be added by any downstream
server in the chain and in this case I'd drop a correct request.

Dmitry.

-

---

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

> From: Alan DeKok <[email-masked]>
> Date: Tue, 16 Mar 1999 14:58:02 -0500
> 
>   So the Proxy-State field is mostly useless, especially since many
> RADIUS servers expect to parse it in a particular
> implementation-defined format.

I don't disagree on the worth of the attribute.  But any server that
tries to parse proxy-state is making a serious error.  It's supposed
to be opaque, interpretable only by the thing that generated it.  A
NAS or proxy that needs to communicate non-standard info to a server
should be using the VS attribute, not misusing proxy-state.

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