Subject: (radius) Re: tunnel-password brouhaha

From: Barney Wolff <[email-masked]>
Date: Fri, 10 Dec 1999 16:26 EST

I'd like to comment on Pat's implication that Tunnel-Password contains
"my" password - as though a nasty proxy that steals it has something of
enduring value.

We're talking Radius here.  The Radius server (or more generally, the
node inserting Tunnel-Password in the Access-Accept) knows the NAS from
the Access-Request, and knows the tunnel destination, which it is
telling the NAS.  So it SHOULD generate an ephemeral password and
communicate it to the tunnel destination.  The password is then useful
only from that specific NAS and only for a limited time.

If your tunnel server has a long-term password which it accepts from all
initiators, you're already in such trouble that Tunnel-Password won't
hurt you any more.

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

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 10 Dec 1999 14:39:52 -0800

Perhaps my reading of the document was incorrect, but it was my assumption
that the Tunnel-Password was a long lived secret.

Let's make the assumption that the LNS does NOT have a long lived secret that
is made available in the Tunnel-Password attribute. A user dials into a LAC
and a request is issued to the home RADIUS server. If the server generates
a short lived key (used for tunneling), which is returned back to the LAC,
how would the LNS get the key? There is no spi, or key identifier, that the
LNS can send to the now stateful RADIUS server.

So, as far as I can tell, the existing scheme assumes a long lived secret
that the LNS has, which is going to be issued to pretty much any LAC that
has a valid user connect to.

Is this incorrect?

PatC

-

---

From: Barney Wolff <[email-masked]>
Date: Fri, 10 Dec 1999 18:32 EST

> From: Patrice Calhoun <[email-masked]>
> Date: Fri, 10 Dec 1999 14:39:52 -0800
> 

The Radius server and the LNS are certainly under the same administration,
or else how does the server know a password for the LNS?  Secure
communication between them can either be assumed or assured with IPSEC
or something like it.  (In the case I'm working on now, the LNS is
in the same host as a Radius proxy, so communication between them is 
not difficult.)

> has a valid user connect to.

Radius itself, at least in its example implementation, does NOT use a
single secret, but has a client table.  I don't believe the draft makes
any assumption about the promiscuity or lifetime of the tunnel-password.
(Obviously, the password lasts as long as the particular tunnel.)
After all, if the secret is long-lasting and used by all LACs, it can
be distributed by courier (if you're a cockeyed optimist) or just
published, if you're a realist.  For Heaven's sake, if you don't trust
a proxy, why would you trust the NAS to keep a secret?

Let's not conflate "hop-by-hop security model" with "every router gets
to see it in the clear."  Crossing an untrusted network is very
different from stopping off in an untrusted proxy.  Does anybody actually
have a threat mechanism by which Radius can be attacked by a malicious
router through which the packets pass?  So far as I know, the router
can block, modify or forge packets, but cannot get a bogus Accept to
be taken by the NAS, or decrypt the Tunnel-Password in it.