[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: matching GW addr to ID payload (fwd)
And related question - is it "legal" to use non-IP Address ID types (e.g. UFQDN,
USER_FQDN, etc.) for the ID Type in the pre-shared keys authentication?
This could help overcome NAT-related complications when negotiating with IPSec gateway
behind it.
Jan Vilhuber wrote:
> 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
--
Bronislav Kavsan
IRE Secure Solutions, Inc.
100 Conifer Hill Drive Suite 513
Danvers, MA 01923
voice: 978-539-4816
http://www.ire.com
Follow-Ups:
References: