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

Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]



  For all the complaints about poor definition of terms (e.g. "system")
it seems surprising that a private definition of "unique" would guide
an objection to advancement of this draft.

  The protection against a man-in-the-middle is that the nonces are
random and _both_ are included in HASH(2) and HASH(3). Replay will not
work as long as the hashes are checked and the responder does not
allow the SAs to be used until HASH(3) has been received and processed
(whether he mallocs space and does a "pre-set-up" is not a useful point
to discuss). Replaying an old Responder-to-Initiator message (#2) back
to the Initiator will result in a failure because the Initiator will
assume it is message #1 in Quick Mode but the hash check will fail.
Replaying an old Initiator-to-Responder message (#1) back to the
Responder will result in the Responder sending an unexpected message #2
back to the Initiator which will fail the hash check (for the same
reason). The response will time out naturally and since the Responder
didn't actually create usable SAs all that's lost is some temporary
space.

  Provided that there are not 2 simultaneous Quick Modes taking place
with the same message ID your are not going to have problems. That, to
me, is the requirement. Granted, the term "unique" is not defined but
that does not mean that it is alright to use a private definition
which imposes an onerous, and unnecessary, burden on implementations.

  And I still don't see the security hole.

  Dan.

On Wed, 12 Jul 2000 17:01:00 PDT you wrote
> On Wed, 12 Jul 2000, D. Hugh Redelmeier wrote:
> >        Initiator                        Responder
> >       -----------                      -----------
> >        HDR*, HASH(1), SA, Ni
> >          [, KE ] [, IDi2, IDr2 ] -->
> >                                  <--    HDR*, HASH(2), SA, Nr
> >                                               [, KE ] [, IDi2, IDr2 ]
> >        HDR*, HASH(3)             -->
> > 
> > Broadly speaking, our major proposal is to use what
> > draft-jenkins-ipsec-rekeying-06.txt calls "Responder Pre-Set-Up" in
> > Quick Mode.  The Responder will set up the SA(s) inbound to it before
> > sending the reply to the first message from the Initiator.
> > 
> > draft-jenkins-ipsec-rekeying-06.txt describes fairly well the
> > advantages of RPSU.  But it vetoes this approach because it claims
> > that RPSU is vulnerable to a replay attack.  A man in the middle could
> > capture a Quick Mode first message from the Initiator and replay it to
> > the Responder, provoking the Initiator to set up useless inbound SAs.
> > Those useless SAs might even be no longer secure.
> > 
> > In fact, the replay attack cannot work if the Responder implements the
> > RFCs.  The RFCs stipulate that the Message IDs of Phase 2 exchanges must
> > be unique.
> 
> I don't remember for sure, but I thought message ID's were also supposed to
> be random. So unless a host saved a list of ALL messages ID's ever used or
> encountered, then you couldn't detect the replay! So you must either use a
> sequentially increasing message-id, which I was under the impression that
> this was a bad idea, or you need to add some sort of time-stamp to the
> packets so that they can be rejected in kerberos fashion...
> 
> So I'm not quite as confident as you that this is simply a matter of
> 'implementing the rfc's' properly.
> 
> I interpret 'unique' as meaning that they are unique in the sender's
> 'name-space'. It means that I can not send out two quick-modes with
> message-id == 5 AT THE SAME TIME. There's nothing from preventing me (or my
> bad random number generator) from sending out a quick mode with message-id 5
> now, and then again 10 minutes from now, after I'm long done with the old
> quick mode that used 5 (and completely oblivious to it, too, unless I keep a
> list of all previously used message-ids).
> 
> Can you elaborate on this some more?
> 
> Bottom line is that I don't think the intent of the message-id was to prevent
> replay attacks. It's simply an identifier to match up requests and replies.
> The Nonces fulfill the replay requirement, but if you use "Responder
> Pre-Set-Up", then you're not waiting to get QM3 (that proves that the remote
> has the right key) before setting up your SA and accepting traffic on it.
> 
> So I believe Tim is right in that there is a security hole here.
> 
> jan
> 
> 
> > A replayed message would not meet this requirement.  Since
> > the Message ID is authenticated, it cannot be forged by a man in the
> > middle.
> > 
> > The enforced uniqueness of Message IDs prevents replay attacks for
> > certain other exchanges such as Informational.
> > 
> > 
> > Enforcing Uniqueness of Message IDs
> > ===================================
> > 
> > We infer from some comments that some implementations do not enforce the
> > requirement that Message IDs be unique.  Although this isn't RFC
> > compliant, the suggestion is that the RFCs be changed!  The specific
> > suggestion is that "probably unique" is good enough.  We claim that
> > the cost of enforcing uniqueness of Message IDs is well repaid by the
> > advantages it affords:  simple robust rekeying and defence against some
> > replay attacks. 
> > 
> > Uniqueness of Message IDs over all messages seen by a system cannot
> > sensibly be enforced.  If a system communicates with two peers, each
> > may choose the same Message ID for an exchange with our system.
> > Forbidding this is silly.
> > 
> > Since each Message ID appears under the protection of an ISAKMP SA,
> > and only has meaning within that ISAKMP SA, uniqueness should only be
> > required within the scope of a particular ISAKMP SA.  (This needs to be
> > made explicit in the RFCs.)
> > 
> > One complaint about enforcing uniqueness of Message IDs is that it
> > appears to require an unbounded amount of state in an ISAKMP SA to
> > store all the used Message IDs.  Although the state for each Message
> > ID is small (4 octets), there might be a very large number of them.
> > 
> > It turns out that there is a simple way to prune this state:
> > negotiate a new ISAKMP SA and delete the old one.  At this point, none
> > of the state matters any more.  It was only used to enforce uniqueness
> > of future Message IDs for exchanges under the protection of the old
> > ISAKMP SA, and there will be none.
> > 
> > In practice, we have not noticed an inordinate build up of defunct
> > Message IDs, and so think that replacing ISAKMP SAs for this reason
> > will not normally be required.
> > 
> > 
> > The advantages of Responder Pre-Set-Up
> > ======================================
> > 
> > Many of the advantages are discussed in
> > draft-jenkins-ipsec-rekeying-06.txt.
> > 
> > If we can assume that all implementations use RPSU, no extra
> > handshaking is required to prevent race conditions in setting up an
> > IPSEC SA.
> > 
> > There is no need for the Initiator to delay using its new outbound SA,
> > because it is guaranteed to have been installed.  There is no need for the
> > Commit Bit (a flawed mechanism as it is).  There is no need to wait
> > for inbound traffic as a proxy for an ACK communicating that the
> > outbound SA ready.
> > 
> > The Responder knows that it may use its outbound SA as soon as it
> > receives the last Quick Mode message.
> > 
> > It all just works.  No Informational messages are required.  No
> > observation of IPsec traffic is required.  No timeouts are required
> > (except those for retransmission of the Quick Mode messages).
> > 
> > There is one flaw in this happy setup.  If the peer is not using RPSU,
> > but instead sets up its inbound SAs on reception of the last Quick
> > Mode message, then there is a race condition.  The race is between the
> > last Quick Mode message and the first outbound IPsec packet from the
> > Initiator.
> > 
> > Two reactions to this problem seem reasonable to us:
> > 
> > - consider the peer to be in error.  After all, we are RFC compliant
> >   so it should handle this case.
> > 
> > - consider the problem to be minor: IP protocols are supposed to
> >   recover from lost packets, so the occasional lost initial packet should
> >   not be a disaster.
> > 
> > We think that it would be a mistake to try to "paper over" the problem
> > by, for example, making the Initiator delay a fixed amount of time
> > between sending the last Quick Mode message and the first IPsec
> > message.  This would complicate all future implementations and reduce
> > their performance.
> > 
> > In this, we diverge from RPSU as described by
> > draft-jenkins-ipsec-rekeying-06.txt  In 2.2.1, that document states:
> > 
> >    Implicit acknowledgement of the reception of the third quick mode
> >    message by the responder is provided by use of the new SA in the
> >    initiator's inbound direction. The initiator should not use its new
> >    outbound SA before that time.
> > 
> > This implicit acknowledgement might well never come!  After all, the
> > conversation was initiated by the Initiator -- maybe it is the only
> > one with something to say.
> > 
> > 
> > Implementation Experience
> > =========================
> > 
> > We have implemented this technique in FreeS/WAN (www.freeswan.org).
> > 
> > The implementation as a whole is minimal: it leaves out large parts of IKE:
> > 
> > - no Informational Payloads are understood or generated
> > 
> > - the Commit Bit isn't implemented
> > 
> > - the IKE implementation knows nothing about actual traffic on the
> >   IPsec SAs
> > 
> > Even so, this implementation interoperates quite well with others.  It
> > rekeys successfully.
> > 
> > The one problematic case of which we are aware is with an
> > implementation which depends on Delete Payloads to switch between SAs.
> > We consider this a bug in that implementation, since Delete messages
> > are not acknowledged and hence their delivery is unreliable.
> > 
> > Hugh Redelmeier
> > hugh@mimosa.com
> > 
> > Henry Spencer
> > henry@spsystems.net
> > 
> > 
> 
>  --
> Jan Vilhuber                                            vilhuber@cisco.com
> Cisco Systems, San Jose                                     (408) 527-0847
> 


Follow-Ups: References: