[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
minor editorial suggestions for draft-jenkins-ipsec-rekeying-06.txt
This document suggests minor editorial changes to
draft-jenkins-ipsec-rekeying-06.txt.
We currently intend to send two messages with more substantive
comments on the draft before the last call expires.
All notes are on lines starting with ">> ".
These notes are embedded in chunks of the original document to give
context. Appropriate subsection headings are included to give context
to the context :-)
Internet Engineering Task Force Tim Jenkins
IP Security Working Group Catena Networks
Internet Draft May 3, 2000
IPsec Re-keying Issues
<draft-jenkins-ipsec-rekeying-06.txt>
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
1. Introduction
This document discusses issues associated with the use of protocols
developed in the IETF's IPsec working group, specifically, RFC 2409
[IKE] and RFC 2408 [ISAKMP]. It is expected that the reader is
familiar with those documents.
>> Also draft-ietf-ipsec-ike-01.txt.
>> (Perhaps draft-ietf-ipsec-ike-hash-revised-00.txt?)
>> In the sequel, these will be refered to as the "IPsec documents".
The first objective is to illustrate problems and issues associated
with re-keying within the confines of the current set of IPsec
documents. For a number of reasons, re-keying in IPsec has become
>> ^^^^^^^^^^is
problematic, such that IPsec implementations can drop packets during
re-keying. Worse, there exists the possibility that IPsec
implementations from different vendors may not be interoperable
because of the way they re-key.
2. Phase 2 SA Re-keying
It also does not assume that the implementation has specific
knowledge about the peer's behaviour. In other words, the peer's
behaviour is assumed to be any of those that may be potentially
allowed by the documents.
>> ^ IPsec
2.1 Phase 2 Re-keying Issues
The issues associated with phase 2 re-keying are listed below. Some
of the points are expanded upon later.
1) There is no specification explicitly defining how the transfer
of traffic from old to new SAs is to be done.
2) The existing drafts appear contradictory in their
recommendations on the usage of multiple phase 2 SAs.
3) Some implementations have shipped with a method of re-keying
>> ^^ ^s
that will not perform reliably under real world network
conditions.
4) The use of the DELETE notification is not required.
>> Reword:
>> 4) The DELETE notification is optional: an implentation need not
>> send it and an implementation need not pay attention to it.
>> Furthermore, a DELETE notification is not authenticated
>> nor is it reliably delivered.
5) A variety of re-keying behaviours have been observed, some of
which are incompatible.
6) The commit bit is not yet widely implemented, and its use as
described is confusing. Further, while the documentation
requires its support, its use is not required.
>> The Commit Bit is not authenticated.
7) A race condition exists at SA set up, exacerbating re-keying
issues.
2.1.1 Inconsistent SA Use Recommendation
This interpretation of [ISAKMP] is in direct conflict with the usage
implied by [IKE], resulting in potential problems.
>> This isn't clearly a contradiction.
>> SAs negotiated in one QM exchange are all the same age, there is no
>> newer/older distinction among them.
2.1.2 Observed Behaviours
All of these behaviours are permitted under the current documents.
>> ^ IPsec
2.1.4 Commit Bit Interaction
3) Its use may make implementations susceptible to a denial of
service attack by forcing initiators to wait for a CONNECTED
notification that may never come. While this is only one of a
number of possible denial of service attacks on IKE, this is
not an excuse to leave the existing implementation as it is.
>> Alternate wording:
>> 3) The Commit bit is not authenticated, so a man-in-the-middle can
>> modify it without detection. The result would be a serious denial
>> of service.
Point 3 happens because the commit bit is in the ISAKMP header, and
the ISAKMP header is not authenticated, so the commit bit is
susceptible to undetectable modification.
>> This paragraph is now redundant.
2.2 Solution Examination
This section details the operation of some possible behaviours, with
the intent of arriving at a best possible phase 2 re-keying
mechanism under the constraints of the existing documents.
>> ^ IPsec
2.2.1.1 Normal Conditions
3) Responder sends second quick mode message.
4) Responder sets up new inbound SA. This is to handle the case
where the initiator starts transmitting on the new SA
immediately after sending the third quick mode message.
>> I think it would appear safer if 3) and 4) were reversed.
2.2.2.1 Dropped Quick Mode 3 Message
This implies that implementations must be able to respond to the re-
>> ^^^^^^^^^^^^^^^Initiators
transmission of the second quick mode message even after having sent
the third quick mode message.
2.2.2.3 Compatibility With Observed Behaviours
When responders use the proposed method and the initiator is an
implementation that uses the new SA immediately, there is no
difference in SA transfer performance compared to the responder also
using the new SA immediately. This is because the proposed method
tries to use the new SA immediately on inbound, so it will be ready
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> immediately enables input on the new SA
to receive on the new SA just as fast as an implementation that
starts using the new immediately under all conditions. However,
since the initiator is also using the new SA immediately, there is a
possibility that packets will arrive at the responder on the new SA
before the responder has time to set up the new SA.
2.2.2.4 Compatibility with Commit Bit
The recommended proposal does not allow built-in support of the
>> ^^^^^^^^^^^^^^^^^^^^^^
>> What does this mean?
commit bit. It does allow responders that use the commit bit to
detect reception of the CONNECTED notification by the initiator due
to the presence of traffic on its new inbound SA. However, this
works only if there is traffic, so it cannot be considered a useful
method to perform this function.
3.1 Phase 1 SA Re-keying Requirements
Two reasons for re-keying a phase 1 SA are for freshness (time or
other) of the phase 1 SA keying material (affecting its ability to
protect phase 2 SA negotiations and to generate phase keying
>> ^2
material) and for re-authentication (and therefore authorisation) of
the encrypting devices.
3.3 A Note About Overlapping Phase 1 SAs
A specific application for this model that provides distinct
advantages is with the use of token cards. For example, if a userĘs
>> ^'
>> [That character shows up as an AE dipthong on my xterm.]
phase 1 authentication and authorisation is bound by the presence of
a token card in a reader, the removal of the card should result in
all SAs being torn down. Since there exists a continuous channel,
delete notifications (acknowledged or not) can be sent for all SAs
when the token card is removed from the system. However, if the
phase 1 SA was allowed to be deleted without being re-keyed, the
local end can only unilaterally delete its SAs, leaving the two end
points out of sync with each other. (It cannot send delete
notifications since the absence of the card makes it unable to re-
establish a phase 1 SA.)
Finally, it must be aware of implementations that do not want or
>> ^^
>> What does "it" refer to? "A system implementing the Continuous
>> Channel Model"?
need phase 1 SAs that are continuously available.
3.3.1 Identity Perfect Forward Secrecy
Allowing the use of only a single phase 2 negotiation in a phase 1
SA is how identity PFS is done. This is controlled by the deletion
>> ^^^^^^^^^^accomplished
of the phase 1 SA after a phase 2 negotiation.
>> Proposed replacement for first sentence:
>> Identity PFS requires that only a single Quick Mode negotiation
>> may be performed under the protection of a Phase 1 SA, and that
>> the Phase 1 SA must be destroyed after the negotiation.
In implementations that do not wish to delete all phase 1 SAs, this
can be done by creating two phase 1 SAs before the first phase 2
negotiation is done. The first of these SAs is assigned the role of
channel management, and thus performs SA deletion and notification
transfer. The second SA is used to perform phase 2 negotiations, and
is immediately deleted.
Since Identity PFS is not negotiated, it may not be possible to
>> ^^^^^^^^^^^^^^neither negotiated nor announced
guarantee that the peer knows Identity PFS is being used. In this
case, the initiator may be required to delete its channel management
SA and create a new one if the peer uses that phase 1 SA to re-key a
phase 2 SA.
>> How does the peer find out about the deletion?
4.1 Re-transmission Rules
In the modes with an odd number of packets, the request-response
>> ^^^^^^^^^^^^^^^^^^^^^
>> For this to apply there must be more than one packet.
pair must be applied across the odd number of packets. This means
that at least one packet must be considered the response to the
previous packet, and must also be considered the request of the next
request-response pair.
4.2 Acknowledged SA Deletion
Note that re-transmission rules apply to the request-acknowledge
pair. That is, if the initiator of the delete mode does not get the
>> ^^^^ informational exchange
delete acknowledgement, the delete request should be re-transmitted.
Similarly, if the responder of the delete request receives multiple
copies, multiple copies of the delete acknowledgement should be
sent.
Note that there is a race condition for the delete request and
delete acknowledgement packets if an implementation sends them
immediately after sending a packet on one of the SAs to be deleted.
The race occurs if the packet order gets changed in the network and
the delete mode packets arrive before packets sent on the SAs to
>> ^^^^informational exchange
which the deletes refer.
The use of the Acknowledged Informational does not eliminate the use
for the existing DELETE notification. It could still be used if an
>> ^^^^^^^^unacknowledged
implementation determines it needs to immediately (and impolitely)
delete an SA. Implementations must still recognise that it is sent
over UDP and may be dropped.
4.5.2 ALLOW_USAGE Notify Payload
The initiator of the exchange must start usage of the inbound SA of
>> ^^^^^^^^^^^^^^enable
the pair when sending the first packet of the exchange. Usage of the
>> ^^^^before
initiator's outbound SA must wait until reception of the
acknowledgement packet of the exchange.
The responder of the exchange must start usage of its inbound SA of
>> ^^^^^^^^^^^^^^enable
the pair before sending the acknowledgement, and may start usage of
>> ^^^^^^^^using
its outbound SA of the pair any time after receiving the first
packet of the exchange.
Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253