[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, Mike Carney wrote:
> >
> > On Fri, 3 Dec 1999, Tylor Allison wrote:
> > >
> <snip>
> > >
> > > 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?
>
> You can trust it because there is a private key associated with the
> cert that contains a match to the identity payload.
> You will be using the public key contained within that certificate in
> order to proceed with Main Mode.
>
But we're talking about pre-shared keys, not certs. For certs you are correct
(I think), but for pre-shared keys and main-mode you are wrong.
jan
> Regards,
> Michael Carney
>
> >
> > 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?!
>
> You don't have "My" private key
>
> >
> > 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
> >
> >
>
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
References: