[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]
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. 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
Follow-Ups: