[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: matching GW addr to ID payload (fwd)

Jan, 

Oops, your right, my mistake, (Tylor and I had talked earlier so I didn't
read what he wrote carefully enough) I agree that the authentication 
information is tied to the source IP of the packet, thus the policy must
be tied to the source IP of the packet.

Another question of Tylors that I would like to repeat is as follows:

If the authentication method is CERT based and the ID payload is IPV4_ADDR
what restrictions must we place on the source IP of the packet and why?

Second question:

If your phase 1 policy (crypto/hash/oakley group) is tied to your phase 1
identity. How do you handle the problem that your phase 1 parameters are
negotiated prior to knowing the phase 1 identity (In MM). 

Our current approach has two aspects. 

The first is whenever possible select the phase 1 parameters based on the
source IP of the ISAKMP packet. This is where we run into problems with
aliased address and multiple routes from the peer selecting different
interfaces out of the peer.

The second is when the remote peer address is not known in advance.  In 
this case we select the highest security level possible and
verify that the negotiated Phase 1 parameters meet the minimum requirements
of the policy.  If they don't we abort the negotiation.

Another approach might be to let the negotiation proceed to the point
of Phase 1 Identities being exchanged, then if the negotiated Phase 1 does
not meet the exact requriements, abort the negotiation and turn the responder
into the initiator (for phase 1), and initiate.  However, this could get one 
into an a never ending cycle if the two sides have conflicting Phase 1 
requirements.

Agressive mode does have it's advantages :)

Regards,
Michael Carney
 
> > 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.
> > >
> > > 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
> > > >
> > > >
> > 
> > 
> > 
> 
>
Follow-Ups: