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

RE: IKE negotiation/rekeying problem with RSIP


Even if we get out of using pre-shared keys and start using certs, there is
no requirement in the IKE standard to choose one phase 1 over another. For
example, IKE standards don't require that a re-key of a phase 2 MUST be done
over the same phase 1 as the original SA. Even if we use certs, I would
guess that no IKE implementations will currently look at the cert of a phase
1 before selecting it for a phase 2.

Ylian Saint-Hilaire

-----Original Message-----
From: Mike Borella [mailto:Mike_Borella@mw.3com.com]
Sent: Monday, November 15, 1999 12:37 PM
To: Saint-Hilaire, Ylian
Cc: ipsec@lists.tislabs.com; 'gab@sun.com'; nat@livingston.com; David
Grabelsky
Subject: 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
Follow-Ups: