RE: Radius access from provider to internal MS ISA Server

["Ben Nagy" <ben () iagu net>]

> -----Original Message-----
> From: Paul Robertson [mailto:proberts () patriot net] 
[...]
> On Fri, 5 Jul 2002, Ben Nagy wrote:
>
> > Your ISP sniffing the CHAP process doesn't lose you the 
> game straight 
> > away. CHAP is designed to be fairly resistant to that sort 
> of thing. 
> > If
>
> It was my impression that the ISP was performing the CHAP 
> authentication, 
> then relaying that to the RADIUS server- if that's not the 
> case, then I'd 
> be less worried, but if it is, then surely the ISP has the 
> CHAP secret[...]

OK, I was originally thinking about L2TP, or some similar protocol. I
don't know if that's the case here or if it's just simple per-user
RADIUS forwarding. If it's just RADIUS forwarding then there are some
nasty RADIUS problems that we have to worry about (good RADIUS security
summary here [1]) but for CHAP it's mostly OK. The worst that can happen
is that the ISP chooses the CHAP challenge, and I deal with the risks of
that below. I believe that you can force many RADIUS servers to
re-challenge the user.

For L2TP, it's quite complicated, so bear with me. You can get
background, Cisco style, from their site[2], or you can read the RFC.[3]

L2TP is designed, in concept, to make it exactly as if the PPP session
was being established with the remote home router (LNS). So, LCP is
supposed to occur at the local ISP (LAC) and all the rest with the LNS.
By default, though, I think that the CHAP challenge is sent by the LAC,
to partially authenticate the user so that the LAC can work out what to
do with the call. The response is sent to the LNS once the LAC has
figured out that it's a L2TP/VPDN (Virtual Private Dialup Network)
session.

For that default situation, if you're worried about a hostile LAC then
this is bad. Just off the top of my head I can see an easy CHAP replay
attack to gain an authenticated session, and there are probably others.
The LAC does _not_ have direct access to the CHAP secret, though. 

BUT! You can also configure your LNS to re-authenticate each user
"locally" (in other words with a locally generated challenge) which
solves this problem. The downside is that some clients may barf on the
second CHAP challenge (which is anti-RFC, I believe).

So, off the top of my head, I think I was more or less on target with my
assessment below, if I was talking about L2TP or some other VPDN. I
can't offhand see anything much that a hostile LAC can do to you except
for setting up bogus tunnels (DoS, maybe) or sniffing or active
manipulation of all the traffic inside the L2TP tunnel, which you'd
presumably be addressing in a different manner.

I'm still thinking that the only significant benefit of this solution is
that is forces the traffic all to come in through the LNS, which avoids
the problem of being connected to the 'net and the VPN at one time
(didn't someone call this "fire-doors" once? ;) However, a hostile LAC
could certainly inject traffic into the tunnel after authentication, so
maybe it's not so good after all.

Can anyone else see a benefit to doing a VPDN instead of just having a
VPN client or security policy (which you can do in W2K) that will never
send traffic to the Internet when the VPN is connected (which still
isn't perfect)? The only thing I can think of is one less authentication
step for the user.

It may be different if you're prepared to trust your telco, but is that
always wise?

> > your Radius box is giving the challenges then as long as they're 
> > "unique in space and time" and not predictable then you're probably 
> > safe from everything but a password guessing attack (modulo MD5 
> > attacks). [...]
>
> IMO, strong passwords are dead- dictionaries are too good 
> now, if you're 
> using reusable passwords, you should assume compromised 
> credentials at 
> some level, esepcially if a third party gets to participate.

I can't buy that without being shown more numbers. A space/time attack
may be possible, since md5 is so damn fast, but I think we're still
looking at incredible power being required here. 

I'm not good at this sort of stuff, but for the space required for the
md5sums of typeable passwords at 12 characters I get 5.94e24 bytes, not
counting line separation. For time,with the 4.1e6 ops/second figure you
quoted elsewhere for md5, I took a million processors and came out at
about 6000 years for the mean for brute force. That's enough for me to
retain some hope. Have I screwed up completely somewhere? Did you mean
to say "memorable" instead of "reusable" ?

[...] 
> Paul

Phew.

Cheers,

[1] http://www.untruth.org/~josh/security/radius/radius-auth.html
[2]
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft
/120t/120t1/l2tpt.htm
(watch out for wrap)
[3] http://www.ietf.org/rfc/rfc2661.txt
--
Ben Nagy
Network Security Specialist
Mb: TBA  PGP Key ID: 0x1A86E304 

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards