RE: Radius access from provider to internal MS ISA Server

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

> -----Original Message-----
> From: firewall-wizards-admin () honor icsalabs com 
> [mailto:firewall-wizards-admin () honor icsalabs com] On Behalf 
> Of Paul Robertson
> Sent: Friday, July 05, 2002 12:56 AM
> To: Christoph Steigmeier
> Cc: firewall-wizards () honor icsalabs com
> Subject: Re: [fw-wiz] Radius access from provider to internal 
> MS ISA Server
>
>
> On Thu, 4 Jul 2002, Christoph Steigmeier wrote:
>
> > Hello
> >
> > Our network-engineers are planing a vpn. The access should be done 
> > through a selected local internet provider. The 
> authentication for the 
> > ppp-connection to the provider should be authenticated 
> using the chap 
> > protocol which is then forwarded from the isp's dialin to 
> our radius 
> > server in our corporate network to validate uid/pw. After this the 
> > vpn-connection can be initialized through our vpn-gateways.

So, this sounds like you're doing some sort of PPTP/L2TP/L2F type thing
with the actual layer-2 dialup stuff. Normally that stuff comes in on a
private link, I've seen it most when it's aggregated into a single
frame-relay link the from ISP concerned.

That has big advantages, in your situation, in that users cannot access
the Internet directly and also concurrently access your internal
network. (I don't need to go into why that's a good thing, I presume..)

The only reason I type all this out is that the bit you mention later
about the engineers claiming that the firewall offers enough protection
raised a doubt in my mind as to whether the forwarded connections really
were getting tunneled or whether it was just some strange authentication
only forwarding scheme, which wouldn't appear to have much value. If the
users can directly access the Internet from the ISP they're connected
to, then IMO you're really wasting your time and you should just use the
VPN gateway to do all your auth - it's stronger, better, faster and all
that jazz.

> > My question: I am not sure if it is good to allow the providers 
> > radius-proxys to access our radiusservers (MS ISA) in our 
> internal net 
> > without an additional radiusproxy in our dmz.[...]

As to the Radius proxy idea, I can't really see _all_ that much value in
it, except for the worry that you're exposing an MS box to a small part
of the Internet, which worries some people on principle. If you're super
worried about malformed, spoofed AAA packets crashing your RADIUS server
(which is possible, I guess, since they're only UDP) then go ahead and
put a proxy in the path. You probably can't definitively stop DoS,
either, because of the same spoofing risk. If your ISA server also does
important internal stuff then this may be a risk.
 
> I prefer to keep internal and external authentication realms 
> different, so 
> that compromise of the credentials is limited in scope (your 
> ISP will be 
> able to sniff the CHAP authentication.)[...]

I'm just going to clarify the risks here. I completely agree with Paul
about having separate credentials for Internal and External
authentication realms/domains. (More people should do that for standard
VPN access, as well).

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
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). In other
words, use good passwords - but you probably didn't need to be told
that. 

(CHAP also has some other attack vectors; if you're interested then you
should read RFC 1994. It's worth noting that the RFC suggests that CHAP
secrets never be symmetric because of a trivial attack (you challenge
me, I send the same challenge to you, you respond, I'm in clover) but
I've never seen an implementation that _doesn't_ use symmetric secrets.
The problem is worked around by the server never responding to a
challenge from an unauthenticated person (which also stops differential
crypto "oracle" attacks). Also, remember that all of the normal attacks
against CHAP just get you authenticated - they don't get you the secret.
This may be relevant if you need to re-authenticate later.)
 
> Paul

Cheers,

--
Ben Nagy
Network Security Specialist
(In Geneva? Hire me!)
Mb: TBA  PGP Key ID: 0x1A86E304 

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