[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]
On Wed, 12 Jul 2000, D. Hugh Redelmeier wrote:
> The "last call" on draft-jenkins-ipsec-rekeying-06.txt has galvanized
> us into writing up what we think is a better approach to certain parts
> of the rekeying problem.
>
> draft-jenkins-ipsec-rekeying-06.txt is a very important document.
> It has plainly laid out key problems with the implementation of IPsec.
> It has proposed useful approaches to surmounting them.
>
> We think that certain parts of the proposed solutions are overly
> complex. In software, complexity is the enemy. In security software,
> this is doubly true.
>
> Key advantages of our approach:
>
> - no extensions to RFCs are required
>
> - few optional features are required
>
> - simplicity and robustness
>
>
> For ease of reference, here is what Quick Mode looks like:
>
> 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: