[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IKECFG and DHCP (was Getting the Feature Chart going)
You are asking many good questions about how it is proposed that IKECFG
will interact with DHCP. There are a number of reasons that it is vital that
IKECFG integrate
well with DHCP. The IKECFG draft does not say much about this
but as I will describe I think that there are a number of issues here
to be explored. As a result, I am cc:'ing Ralph Droms (chair of DHCP WG)
and Bill Arbaugh, co-author of the DHCP authentication draft.
>Does this mean the IPSEC security gateway (sgw) also runs a dhcp server?
No, I hope it dos not mean that. You probably want
a sgw machine to only perform that function.
>Does it mean that we embed a dhcp (bootp) relay spoofer within the isakmp
code?
I do think that the sgw will end up running as a DHCP relay. If the address
is assigned by the pure DHCP method, then this will be the only involvement
that the sgw will have in the DHCP process. If the address is assigned
within
IKECFG, the interaction becomes somewhat more complex as described below. If
IKECFG *only* handles addressing, then I think that the sgw will serve as a
relay for DHCP INFORM packets, used for configuration.
Since the IKE negotiation will have completed by the
time the INFORM is sent, I don't think that the IKE code will need to be
involved in the INFORM per se. However, as noted below, the sgw role
with respect to address assignment is somewhat more complicated, as
described below.
The way address assignment would work is presumably similar to the
way NAS devices handle address allocation within PPP today. This is
typically by one of two methods: allocating out of an assigned pool,
or making a DHCP request on behalf of the user.
In allocating out of an assigned pool, there is typically an assumption that
the sgw "owns" the address space with an infinite lease and that users
connected
to it get to use the address for as long as the session/tunnel remains up.
So you do not get into the issue of leases and renewal.
However, this model can be complicated by the fact that often there is more
than one address pool, so that there needs to be a selection of what pool
the address is assigned from. Since some networks use the pool in order
to differentiate beween users for things like QoS, it can be important
to be able to get this right. The pool can be negotiated between the user
and
sgw or the sgw can select it based on information it gleans from the IKE
phase 1 negotiation, such as the identity. One question is whether most
current implementations offer enough information to make this decision
or whether additional IKECFG attributes are needed. In DHCP this kind of
issue is handled via the User-Class option. I think that such an option
will be needed in IKECFG for reasons that follow.
When making a DHCP request on behalf of the user, it is necessary for IKE
to be able to receive the same kind of address that the user would have
gotten for himself. This implies that the sgw must be able to impersonate
the user if DHCP authentication is in force, or must be able to request
a DHCP address with the proper User-Class option so that the user is
assigned
out of the right pool. Since User-Class cannot necessarily be ascertained
from the user identity, I think that this will be needed in IKECFG.
Impersonation of the user in DHCP authentication is an interesting issue.
Right now the IKECFG proposal does not address this, which is a
shortcoming. Networks concerned enough about security to deploy IPSEC are
probably among those who will care about DHCP authentication. In order
to be able to impersonate the user context for DHCP authentication, the
sgw must be able to verify integrity/auth options returned by the server,
as well as to sign these options on behalf of the user. This implies that
the sgw must either proxy between the user and DHCP server in a full fledged
DHCP conversation, *or* must have access to the appropriate secrets to
act on the user's behalf.
I'm copying Bill Arbaugh on this thread, since he is the author of DHCP
authentication. Bill -- any idea how this would work?
I wasn't referring to the assignment of IP addresses. I was referring to
the complexity of the sgw, the ike code, etc., and to the fact that as
the complexity increases, the analyzability decreases rapidly. At the
same time, the probability of the presence of an exploitable hole
increases. I think that the most secure sgw is (probably) the simplest
possible implementation, and that's what I was driving at.
Scott
Follow-Ups:
References: