[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Wed, 10 Nov 1999, Scott G. Kelly wrote:
> Sara Bitan wrote:
> > Here is the charter that was presented in yesterday's meeting.
> Thanks, Sara. I think most of my concerns were covered in comments made
> by others at the meeting yesterday. Additional comments below...
> > 2) IPsec makes it difficult to support dynamic resource assignment,
> > particularly addresses, based on authenticated user identity, from
> > within a private address space behind an IPsec security gateway. This is
> > an operational property of the current IKE specification, and
> > implementations.
> I strongly disagree with this statement. IPsec (or perhaps more
> correctly, RFC 2401) supplies mechanisms for providing strictly
> controlled access (based upon authenticated user identities) to a dhcp
> server within the protected network, and it has yet to be demonstrated
> that dhcp does not meet the (infrastructure-related) configuration
> requirements for remote access scenarios. Does anyone know of any
> examples which refute this assertion?
Let me give this a shot:
dhcp obviously doesn't address the user-authentication at all. It's not an
authentication mechanism. What is does is provide host configuration to a
host. I'm no dhcp expert, so bear with me.
The information provided by dhcp is limited, i.e. does not match the wealth
of information provided by general AAA Authorization mechanisms (ip
addresses, dns and wins, just like dhcp, but access-lists for the interface
on the GW as well as static routes for the GW and so on). It also limits you
to a single place to get this information, which I do not like. What if your
local policy says to get the ip address information from a local pool
configured on the GW? The dhcp proposal limits you to ONLY dhcp. Maybe
there's something I'm missing. As I said, I'm not dhcp savvy.
In short, one of the things not spelled out in the charter is that when we
say 'legacy user authentication', we are really talking about people's AAA
infrastructure. At least I believe so. Anything that does not let customers
reuse their eisting radius databases, will simply not work. The whole point
of this working group is that customers do NOT want to throw away their
well-established AAA infrastructure, and replace it with something new, like
CAs. So far, we've only really talked about authentication, but
authorization is just as important. So you need to be able to do all 3 A's in
AAA. The dhcp proposal is too limiting to only the IP address (and dns and
wins) aspect of this.
Both l2tp and config-mode/xauth address this nicely. L2tp via PPP, which is
well-established and works. xauth integrates well with AAA authentication
(I've implemented this, but don't take that as saying I like it), and
config-mode also maps well onto authorization.
Jan Vilhuber vilhuber@xxxxxxxxx
Cisco Systems, San Jose (408) 527-0847