minor editorial suggestions for draft-jenkins-ipsec-rekeying-06.txt
"D. Hugh Redelmeier" <hugh@mimosa.com> Tue, 11 July 2000 22:37 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00831; Tue, 11 Jul 2000 15:37:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21115 Tue, 11 Jul 2000 16:30:22 -0400 (EDT)
Date: Tue, 11 Jul 2000 16:41:24 -0400
From: "D. Hugh Redelmeier" <hugh@mimosa.com>
Reply-To: hugh@mimosa.com
To: IPsec List <ipsec@lists.tislabs.com>
Subject: minor editorial suggestions for draft-jenkins-ipsec-rekeying-06.txt
Message-ID: <Pine.LNX.4.21.0007111639220.30259-100000@redshift.mimosa.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
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
- minor editorial suggestions for draft-jenkins-ips… D. Hugh Redelmeier