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

IPsec AH and ESP drafts



Folks,

Here's a summary of IPsec AH and ESP edits/questions.  This is based on
the drafts distributed in 11/97 and subsequent email (up until 1/31).  It
does not include minor edits (typos), the addition of the new copyright
text required by the RFC format instructions, updating of the reference
section, etc.  The issues have been divided into 3 groups:
	AH-ONLY
	ESP-ONLY
	AH AND ESP		

We have submitted the AH and ESP drafts to the IETF secretariat for
distribution.  Per direction from the working group chairs, we are also
sending copies directly to the list to get them into folks' hands as
soon as possible.

Thank you for all the feedback/help both on the list and in private
email.

Karen


AH-ONLY
============================================================================
===
1. Per email from Dave Mason (12/29-30) -- For IPv4, need to discuss how
   to handle the bytes of IP header after the last option.  RFC 791 (IP)
   and RFC 1122 (Host Requirements) specify only that an "End of Options
   List" option is placed after the last option.  "This might not
   coincide with the end of the internet header according to the
   internet header length.... and need only be used if the end of the
   options would not otherwise coincide with the end of the internet
   header."  They do not say to insert "End of Options List" options
   until the IP header is 4-byte aligned or up to the end of the IP
   header.

	*Changed AH Appendix A.1 IPv4 Options -- added the following note
	 at the end of the table.

		End of Options List options SHOULD be repeated as
		necessary to ensure that the IP header ends on a 4 byte
		boundary in order to ensure that there are no
		unspecified bytes which could be used for a covert
		channel.


ESP-ONLY
============================================================================
===
1. Section 3.1 -- Per summary from IPsec document reading party, "3.1
   Say that tunnel mode *MUST* be used."

	* Sorry, but could someone provide more context?  There are
	  several places where this statement might apply.

2. Section 3.3.3  Sequence Number Generation -- Add pointer to Section
   5 to provide explanation for comment on manual key management.

	* Changed last paragraph of this section from:
		If anti-replay has been disabled, the sender does not
		need to monitor or reset the counter, e.g., in the case
		of manual key management.
	  to:
		If anti-replay has been disabled, the sender does not
		need to monitor or reset the counter, e.g., in the case
		of manual key management (see Section 5).

3. Section 3.3.5 -- Per summary from IPsec document reading party,
   "3.3.5 I'm not convinced that the description of how to do
   fragmentation is correct.  I'm especially concerned that transport
   and tunnel modes require different processing.  The interaction of
   the rules here with IPv6 fragmentation is especially worthy of
   attention.  (See the discussion of fragmentation in Wagner and
   Bellovin's "A Bump in the Stack Encryptor for MS-DOS"....)

	* Modified the existing Section	"3.3.5  Fragmentation":

		If necessary, fragmentation is performed after ESP
		processing within an IPsec implementation.  Thus,
		transport mode ESP is applied only to whole IP datagrams
		(not to IP fragments).  An IP packet to which ESP has
		been applied may itself be fragmented by routers en
		route, and such fragments must be reassembled prior to
		ESP processing at a receiver.  In tunnel mode, ESP is
		applied to an IP packet, the payload of which may be a
		fragmented IP packet.  For example, a security gateway
		or a "bump-in-the-stack" or "bump-in-the-wire" IPsec
		implementation (as defined in the Security Architecture
		document) may apply tunnel mode ESP to such fragments.

	  by adding the following two notes:

		NOTE: For transport mode -- As mentioned at the
		beginning of Section 3.1, bump-in-the-stack and
		bump-in-the-wire implementations may have to first
		reassemble a packet fragmented by the local IP layer,
		then apply IPsec, and then fragment the resulting
		packet.
		
		NOTE: For IPv6 -- For bump-in-the-stack and
		bump-in-the-wire implementations, it will be necessary
		to walk through all the extension headers to determine
		if there is a fragmentation header and hence that the
		packet needs reassembling prior to IPsec processing.


4. Section 3.4.5 -- Per summary from IPsec document reading party, need
   to correct the text to indicate additional ways in which decryption
   can "fail".

	* Changed Section 3.4.5 Packet Decryption, paragraph 4 (counting
	  the indented steps 1,2,3 taken by the receiver as one
	  paragraph) from:

		Note that there are two ways in which the decryption can
		"fail".
		        o The selected SA may not be correct.
		        o The encrypted ESP packet could be corrupted.

		The latter case would be detected if authentication is
		selected for the SA, as would tampering with the SPI.
		However, an SA mismatch might still occur due to
		tampering with the IP Destination Address.  In either
		case, the erroneous result of the decryption operation
		(an invalid IP datagram or transport-layer frame) will
		not necessarily be detected by IPsec, and is the
		responsibility of later protocol processing.

	to:

		Note that there are several ways in which the decryption
		can "fail":

		        a. The selected SA may not be correct -- The SA
			   may be mis-selected due to tampering with the
			   SPI, destination address. or IPsec protocol
			   type fields. Such errors, if they map the
			   packet to another extant SA, will be
			   indistinguishable from a corrupted packet,
			   (case c).  Tampering with the SPI can be
			   detected by use of authentication.  However,
			   an SA mismatch might still occur due to
			   tampering with the IP Destination Address or
			   the IPsec protocol type field.

			b. The pad length or pad values could be
			   erroneous -- Bad pad lengths or pad values
			   can be detected irrespective of the use of
			   authentication.

			c. The encrypted ESP packet could be corrupted
			   -- This can be detected if authentication is
			   selected for the SA.,

		In case (a) or (c), the erroneous result of the
		decryption operation (an invalid IP datagram or
		transport-layer frame) will not necessarily be detected
		by IPsec, and is the responsibility of later protocol
		processing.

		

AH AND ESP
============================================================================
===
1. Section 2 -- Define "IV" (ESP-only) and "ICV" (AH and ESP)
   before/when using these terms.

	* In AH -- Changed the text following the header format diagram
	  from:

		The following subsections define the fields that
		comprise the AH format.  All the fields described here
		are mandatory, i.e., they are always present in the AH
		format and are included in the ICV computation.
	  to:
		The following subsections define the fields that
		comprise the AH format.  All the fields described here
		are mandatory, i.e., they are always present in the AH
		format and are included in the Integrity Check Value
		(ICV) computation (see Sections 2.6 and 3.3.3).

	* In ESP -- Changed text following header format diagram from:

	     * If included in the Payload field, cryptographic
	       synchronization data, e.g., an IV, usually is not
	       encrypted per se, although it often is referred to as
	       being part of the ciphertext.

	    The following subsections define the fields in the header
	    format.  "Optional" means that the field is omitted if the
	    option is not selected, i.e., it is present in neither the
	    packet as transmitted nor as formatted for computation of an
	    ICV....

	  to:
	     * If included in the Payload field, cryptographic
	       synchronization data, e.g., an Initialization Vector (IV,
	       see Section 2.3), usually is not encrypted per se,
	       although it often is referred to as being part of the
	       ciphertext.

	    The following subsections define the fields in the header
	    format.  "Optional" means that the field is omitted if the
	    option is not selected, i.e., it is present in neither the
	    packet as transmitted nor as formatted for computation of an
	    Integrity Check Value (ICV, see Section 2.7)......


2. Section 3.1 -- Per summary from IPsec document reading party, need to
   reconcile AH (Section 3.1) and ESP (Section 3.1) descriptions of
   support for combinations of SAs with the Architecture's description
   of support for combinations of SAs.
	
	*The Architecture document has been changed to more clearly
	 reflect the 4 cases that the community agreed needed to be
	 supported and remove some errors and inconsistencies.  The AH
	 and ESP text has been changed to point to the Architecture
	 document.  We removed the following text from AH and ESP
	 Sections 3.1:

		If more than one IPsec header/extension is required,
		then starting with packet [IP1][upper], the following 5
		cases plus any combination of one of the Tunnel cases
		followed by one of the Transport cases (i.e., 4 then 1,
		4 then 2, 4 then 3, 5 then 1, 5 then 2, 5 then 3.)  MUST
		be supported.

	        Transport                       Tunnel
	        -----------------               ---------------------
	        1. [IP1][AH][upper]             4. [IP2][AH][IP1][upper]
	        2. [IP1][ESP][upper]            5. [IP2][ESP][IP1][upper]
	        3. [IP1][AH][ESP][upper]

		Support for additional combinations of AH and ESP is
		optional.  Use of other, optional combinations may
		adversely affect interoperability.

	and replaced it with:

		ESP and AH headers can be combined in a variety of
		modes.  The IPsec Architecture document describes the
		combinations of security associations that must be
		supported.
	
3. Section 3.3.4 (ESP) and 3.3.3.2.2 (AH) -- Per discussion re:
   "implicit padding for authentication" (1/7-25), need to clarify that
   the input "block size" for MD5 and SHA-1 is such that no padding is
   needed even though their internal algorithms have an internal "block
   size" of 64 bytes.

	* Changed AH and ESP documents to clarify the above.  This
	involved changing AH Section "3.3.3.2.2 Implicit Packet
	Padding":

		For some authentication algorithms, the byte string over
		which the ICV computation is performed must be a
		multiple of a blocksize specified by the algorithm.  If
		the IP packet length (including AH) does not match the
		blocksize requirements for the algorithm, implicit
		padding MUST be appended to the end of the packet, prior
		to ICV computation.  The padding octets MUST have a
		value of zero.  The blocksize (and hence the length of
		the padding) is specified by the algorithm
		specification.  This padding is not transmitted with the
		packet.

	by adding the following sentence at the end:

		Note that MD5 and SHA-1 are viewed as having a 1-byte
		blocksize because of their internal padding conventions.

	and changing ESP Section "3.3.4 Integrity Check Value
	Calculation", paragraph 2:

		For some authentication algorithms, the byte string over
		which the ICV computation is performed must be a
		multiple of a blocksize specified by the algorithm.  If
		the length of this byte string does not match the
		blocksize requirements for the algorithm, implicit
		padding MUST be appended to the end of the ESP packet,
		(after the Next Header field) prior to ICV computation.
		The padding octets MUST have a value of zero.  The
		blocksize (and hence the length of the padding) is
		specified by the algorithm specification.  This padding
		is not transmitted with the packet.

	by adding the following sentence at the end:

		Note that MD5 and SHA-1 are viewed as having a 1-byte
		blocksize because of their internal padding conventions.

4. Section 3.4.1 -- Per summary from IPsec document reading party, need
   to clarify that the appearance of a "fragment" for ESP processing can
   result not just from a bug in the code but because the current IPv4
   spec does NOT require (upon reassembly) the zero'ing of the OFFSET
   field or the clearing of the MORE FRAGMENTS flag.

        *Modified the following text in AH and ESP:

                3.4.1  Reassembly

                If required, reassembly is performed prior to AH
                processing.  If a packet offered to AH for processing
                appears to be an IP fragment, i.e., the OFFSET field is
                non-zero or the MORE FRAGMENTS flag is set, the receiver
                MUST discard the packet; this is an auditable event. The
                audit log entry for this event SHOULD include the SPI
                value, date/time, Source Address, Destination Address,
                and (in IPv6) the Flow ID.

                3.4.1  Reassembly

                If required, reassembly is performed prior to ESP
                processing.  If a packet offered to ESP for processing
                appears to be an IP fragment, i.e., the OFFSET field is
                non-zero or the MORE FRAGMENTS flag is set, the receiver
                MUST discard the packet; this is an auditable event. The
                audit log entry for this event SHOULD include the SPI
                value, date/time, Source Address, Destination Address,
                and (in IPv6) the Flow ID.

        by the addition of the following text:

                NOTE: For packet reassembly, the current IPv4 spec does
                NOT require either the zero'ing of the OFFSET field or
                the clearing of the MORE FRAGMENTS flag.  In order for a
                reassembled packet to be processed by IPsec (as opposed
                to discarded as an apparent fragment), the IP code must
                do these two things after it reassembles a packet.

5. Section 3.4.3 -- Per suggestion from Dan McDonald (1/7), need to
   modify the documents to clarify that anti-replay is not supportable
   in the case of multiple senders to a single SA, irrespective of
   whether the destination address is unicast, broadcast, or multicast.

	*Changed AH and ESP documents to clarify the above.  This
	involved changing AH Section "3.4.3 Sequence Number
	Verification" from:

		All AH implementations MUST support the anti-replay
		service, though its use may be enabled or disabled by
		the receiver on a per-SA basis.  (Note that there are no
		provisions for managing transmitted Sequence Number
		values among multiple senders directing traffic to a
		single, multicast SA.  Thus the anti-replay service
		SHOULD NOT be used in a multi-sender multicast
		environment that employs a single, multicast SA.)
	to: 
		All AH implementations MUST support the anti-replay
		service, though its use may be enabled or disabled by
		the receiver on a per-SA basis.  (Note that there are no
		provisions for managing transmitted Sequence Number
		values among multiple senders directing traffic to a
		single SA (irrespective of whether the destination
		address is unicast, broadcast, or multicast).  Thus the
		anti-replay service SHOULD NOT be used in a multi-sender
		environment that employs a single SA.)

	and changing ESP Section "3.4.3 Sequence Number Verification"
	from:

		All ESP implementations MUST support the anti-replay
		service, though its use may be enabled or disabled by
		the receiver on a per-SA basis.  This service MUST NOT
		be enabled unless the authentication service also is
		enabled for the SA, since otherwise the Sequence Number
		field has not been integrity protected.  (Note that
		there are no provisions for managing transmitted
		Sequence Number values among multiple senders directing
		traffic to a single, multicast SA.  Thus the anti-replay
		service SHOULD NOT be used in a multi-sender multicast
		environment that employs a single, multicast SA.)
	to:
		All ESP implementations MUST support the anti-replay
		service, though its use may be enabled or disabled by
		the receiver on a per-SA basis.  This service MUST NOT
		be enabled unless the authentication service also is
		enabled for the SA, since otherwise the Sequence Number
		field has not been integrity protected.  (Note that
		there are no provisions for managing transmitted
		Sequence Number values among multiple senders directing
		traffic to a single SA (irrespective of whether the
		destination address is unicast, broadcast, or
		multicast).  Thus the anti-replay service SHOULD NOT be
		used in a multi-sender environment that employs a single
		SA.)