[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: matching GW addr to ID payload (fwd)
On Fri, 3 Dec 1999, Stephen Kent wrote:
> I hate to jump in late to this discussion, as I may have lost the
> context. There is a big difference between asserting an address as an
> identity in the IP header, vs. asserting it in an IKE exchange, IF
> one uses certificates to authenticate the asserted identity in IKE.
> One can imagine several PKI scenarios that would enable one to have
> reasonable confidence in a cert issued for an address.
>
> Steve
This seems to be getting back to my original questions which started all
this. The basis of these questions was what decisions (if any) can be
made based on the source address from the IP header. For pre-shared
password authentication in Main Mode, it's evident that this source IP
address drives the authentication by determining which key to select. I
would argue that the actual ID payload should still drive any policy
decisions. Whether or not the ID payload needs to be an IPV4_ADDR which
matches the source address is still unclear to me.
What interests me more, however: can any decisions be made based on the
packet's source IP address for cert-based policies? For instance, for
signature authentication in main mode where certificates are not available
online, when responding to a remote request, one needs to either assume
that the remote cert is not locally available (and a certificate request
must always be made), or one can use the source IP address to look up
policy info for the remote host and determine if the remote cert is locally
available (and if not, then send a certificate request). This must be done
in the exchange prior to receiving the remote side's identity payload...
since the identity payload is received in the last round of the exchange,
and a certificate request cannot be made it this time, since it would
extend the exchange.
Along these same lines, if you set up a static VPN policy and you know what
the remote IP address is, when you receive the first payload of a main mode
exchange from that remote IP address, can you immediately fail the exchange
if attributes in the SA payload do not match the attributes that you have
set in your policy?
Also, going back to Steve's message (and one of my original questions)...
Given a certificate which is assigned a specific IP address (e.g. in
subjectAltName extension), I think it's clear that if I use a IPV4_ADDR as
the identity payload for the exchange, that it needs to match the one
presented in the cert. Is anyone checking to see if this matches the source
IP address from the packet? Or if I use a DN of the cert as the identity,
but the cert contains the IP address, does anyone check the cert's asserted
IP address with the packet?
All of this then goes back to, what breaks if there can be multiple IP
addresses associated with the remote host (e.g. aliased addresses for
the interface, or multiple interfaces). This clearly breaks the pre-shared
key case (unless you set the same key for each of the aliased addresses).
If vendors are using the source IP address for other purposes (initial
policy checks, cert lookup, etc.), this may break other authentication
methods as well. I know this isn't a very likely occurance, but it is
still a concert for us. I'm just wondering if other vendors out there have
addressed this issue, and can provide any insight on how they plan to
handle it.
Thanks!
Tylor
---
Tylor Allison tylor_allison@securecomputing.com
Secure Computing Corporation
Follow-Ups:
References: