[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: matching GW addr to ID payload (fwd)
A more interesting question, perhaps, and one we've been struggling with
as well, is: If you ignore the ID_IPV4 payload altogether, pick your key
based on the source-ip-address (which may be different than the IPV4 ID!),
does this open a security hole?
I would argue that it doesn't and that you can safely ignore the ID payload
in the MM/pre-shared scenario, since it adds no value anyway.
Donning flame-proof suit,
jan
On Thu, 2 Dec 1999, Mike Carney wrote:
> > Hi,
> >
> > Tylor Allison wrote:
> >
> > > I have a question that I hope some of you out there can help me answer.
> > > The scenario is this: Say I have a host machine using IKE/IPSEC which has
> > > multiple aliases for the same interface (or multiple interfaces routable
> > > to the same remote peer). When I start a IKE negotiation to the remote peer
> > > the IKE implementation does not have control over which interface address
> > > gets inserted in the UDP packet. If I wish to use an IPV4 address in the
> > > identity payload, my IKE implementation will choose the IPV4 address to use
> > > in the ID payload based on the IKE implementations configured policy.
> > >
> > > My question is, what happens if the IPV4 address selected in the ID payload
> > > does not match the actual source address contained in the packet?
> > > I know for
> > > the pre-shared key case, this won't (or shouldn't) work (at least for Phase
> > > 1 using Main Mode), since the actual remote address used to send the packet
> > > is used to determine the pre-shared key used to authenticate the session.
>
> This is the question at hand ...
>
> > > But how should this be handled for signature based authentication? If the
> > > IPV4 address specified in the identity payload matches the IP address in
> > > the subjectAltName extension of the cert used for sig authentication and
> > > this matches the IKE local policy, does it need to match the actual
> > > address received from the packet?
>
> Any suggestions?
>
> > >
> > > And what if there is no ip address in the subject-alt name? Is it then
> > > a requirement that the actual gateway match the IPV4_ADDR identity?
> > >
> > > How would implementations out there handle this scenario? Has anyone
> > > else thought of how to handle multiple interface aliases so that ISAKMP
> > > does "the right thing".
> >
> > This problem can be solved if you use identification other than
> > IP address, in case of signature authentication mode.
>
> No fair changing the problem to one that is easier to solve :)
>
> >
> > In case of preshared key authentication, while configuring the
> > IKE policy, one should know the source IP adress and inform
> > other end.
> >
>
> Who should know the source IP address?
>
> Consider the case of a box with multiple network interface cards and
> perhaps aliased IP address on some of those interfaces. The route to
> the remote peer is what determines the interface used to send the UDP packets
> that are sent by ISAKMP. The OS uses some heuristic to determine the
> aliase IP that is used to set the source address of packets from a
> given interface.
>
> Both the route and aliase choice are subject to change.
>
> I admit this is somewhat of a rare case as most VPN gateways
> have but a single IP address for all of the VPN traffic. But in
> our implementation it is a situation we must consider.
>
> Regards,
> Michael Carney
>
>
> > >
> > >
> > > Thanks in advance.
> > >
> > > ---
> > > Tylor Allison tylor_allison@securecomputing.com
> > > Secure Computing Corporation
> >
> > Regards
> > Srini
> >
> >
>
>
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
Follow-Ups:
References: