[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, Tylor Allison wrote:
> 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.

Why? How can you trust it?

Say that *you* are allowed to access top-secret documents. I, being of lower
rank, am not allowed to see anything CLOSE to top-secret.

Now I stick in the ID payload with YOUR name, and voila! I can now read all
top-secret documents. How do you prevent this?!

If you want to select policy via ID you MUST link it to whatever selected the
key. Either you have a table linking ID_FQDN or ID_USER_FQDN to the
source-ip-address (hopefully the NAT'd one, if you're coming through NAT), or
you have a table linking ID_IPV4 to the source-ip-address (again, hopefully
the NAT'd one, which could lead to a table like: ID_IPV4=1.1.1.1 ==
source-ip-address 199.100.111.222, which seems pretty silly to me).

jan


> 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
> 
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847
Follow-Ups: References: