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

Re: matching GW addr to ID payload (fwd)

To: Slava Kavsan <bkavsan@ire-ma.com>
Subject: Re: matching GW addr to ID payload (fwd)
From: Srinivasa Rao Addepalli <srao@ibondinc.com>
Date: Thu, 02 Dec 1999 13:30:33 -0800
CC: Jan Vilhuber <vilhuber@cisco.com>, Mike Carney <carney@securecomputing.com>, Tylor Allison <allison@securecomputing.com>, ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com
References: <Pine.SOL.3.96.991202113455.11132P-100000@jvilhube-ss20.cisco.com> <3846D7C2.58A34B8A@ire-ma.com>
Sender: owner-ipsec@lists.tislabs.com



Slava Kavsan wrote:

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

I guess it is possible. Why do you think it may not be legal?

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

Regards
Srini

References:

Re: matching GW addr to ID payload (fwd)

From: Jan Vilhuber <vilhuber@cisco.com>

Re: matching GW addr to ID payload (fwd)

From: Slava Kavsan <bkavsan@ire-ma.com>

Prev by Date: Re: IPSec SA DELETE in "dangling" implementation
Next by Date: Re: IPSec SA DELETE in "dangling" implementation
Prev by thread: Re: matching GW addr to ID payload (fwd)
Next by thread: Re: matching GW addr to ID payload (fwd)
Index(es):
- Main
- Thread