[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE negotiation/rekeying problem with RSIP
Let's try to scope the problem.
- The reason that the two phase 1's are identical to C is because the identity
of the initiator can only be determined by the IP address of the
gateway (assuming preshared keys and main mode). This suggests
a number of work arounds:
1) Don't use pre-shared keys. Problem: many current implementations
only use pre-shared keys
2) Use aggressive rather than main mode. Problems: No group negotiation,
responders may not implement (or prefer) aggressive mode).
3) Allocate an IP address per initiator (RSA-IP method). Problem: If we
can do this, then RSIP itself may be overkill.
- It makes no sense to use preshared keys with RSIP/IPSEC in any case.
If we have n identities sharing the same IP address such that they
can only be differentiated by the port numbers that they use and/or
out of band authentication such as public keys, then *there is no way*
for the responder to tell these n identities apart. Since RSIP is meant to
be
used in situations where a roaming client plugs into a LAN and shares the
gateway's IP with other roaming clients, we need something other than
the gateway's IP for authentication.
- For phase 2, we can still negotiate on a port-by-port (socket-by-socket) basis
and
since gateway-side ports are tied to IDs, this should work.
This whole problem is a reiteration of the IPSEC remote access problem with
respect
to preshared keys. I think that the RSIP/IPSEC draft should document the issues
and
explain where RSIP / IPSEC will not work, but it is not in our scope to solve
this problem.
Yet another reason to speed the move from preshared keys and IP based
authentication to something better.
-Mike
"Saint-Hilaire, Ylian" <ylian.saint-hilaire@intel.com> on 11/14/99 06:39:34 PM
Sent by: "Saint-Hilaire, Ylian" <ylian.saint-hilaire@intel.com>
To: ipsec@lists.tislabs.com, "'gab @sun.com'" <gab@sun.com>, Mike
Borella/MW/US/3Com
cc:
Subject: IKE negotiation/rekeying problem with RSIP
There is a possible problem IKE initiation/rekeying over RSIP. If two inner
computers use an RSIP gateway to establish IPsec sessions to one
destination, the destination computers will see 2 IKE phase1's from the
gateway. If the destination computer ever needs to rekey a phase 2 or
negotiate a new phase 2, he may select an incorrect phase 1 to negotiate
with.
Here is an example:
A ---> +---------+
| Gateway | ---> C
B ---> +---------+
A negotiates a phase 1 with C using the gateway (called phase 1a)
A negotiates a phase 2 with C using the phase 1a (called phase 2a)
B negotiates a phase 1 with C using the gateway (called phase 1b)
B negotiates a phase 2 with C using the phase 1b (called phase 2b)
The lifetime of phase 2a is about to expire; C wants to negotiate a new SA
before phase 1a expires completely. Since phase 1a is established to G (the
gateway), C looks in his state table for a phase 1 he could re-use to G, he
finds Phase1b and uses it to negotiate.
The new phase2 negotiation is encrypted end-to-end from B to C. The gateway
cannot do anything about it, he forwards the packets based on the cookies in
the header. B will receive a negotiation intended to go to A and may or may
not accept it.
I would note that this example is likely to happen. In IKE the responder may
have a phase 2 SA lifetime lower than the initiator without the initiator
knowing. In this case, the responder will be the one re-keying and causing
the problem.
This problem could also occur frequently if the initiator only negotiates
SA's with very specific ports/protocols. The destination could be unable to
reply back since all it's SA's are negotiated to the wrong computer inside
the gateway.
I also note that the phase 1 selection process varies from an IKE
implementation to another.
I don't have any simple solution that come to mind, maybe this is out of
scope or we can live with this.
Ylian Saint-Hilaire
INTEL - Communication Architecture Labs