Final changes for AH/ESP documents

"Theodore Y. Ts'o" <tytso@MIT.EDU> Mon, 17 November 1997 01:23 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA07855 for ipsec-outgoing; Sun, 16 Nov 1997 20:23:26 -0500 (EST)
Date: Sun, 16 Nov 1997 20:33:58 -0500
Message-Id: <199711170133.UAA25845@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: ipsec@tis.com
Subject: Final changes for AH/ESP documents
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

As you may know, there was some last-minute controversy over the AH/ESP
results, specifically over the Sequence Number and Anti-replay Server
issue, with a number of people requesting that we use option (C) instead
of option (B).   After discussing the issues with the document editor
and the various involved parties, we've agreed to indeed use option (C).

The document editors asked me to send a message to the list reflecting
the final editing directions for these documents, which follow below.

My personal thanks for all of the work that people have placed into
editing, reviewing, and implementing these documents.  

						- Ted

1. Sequence Number and Anti-replay Service -- 3 options have been
   proposed over the past several months.  (B) was chosen over (A) back
   about 2 months ago.  (B) is what's in the text at present.  (B) is
   a perhaps bit better than (C) but both are pretty similar.  It seems
   simplest at present to stick with (B).
	
	S = Sender	AR = anti-replay
	R = Receiver	Seq# = sequence number
	
   Sender   
   Default  To initiate AR	Pro			Con
   -------  ------------------	-----------------------	-----------------------
 A) AR OFF  S negotiates AR ON,	- Deterministic, reli-	Have to change Oakley/
	    R accepts/rejects	  able way for S & R to	ISAKMP
				  know AR status
				- Handles manual keying

 B) AR OFF  R SHOULD notify S	- Handles manual keying	- NOTIFY is unreliable,
	    that AR is ON	- No changes to Oakley/	  so S may continue to
				  ISAKMP		  send while R rejects


 C) AR ON   R MAY notify S that	- No changes to Oakley/	- NOTIFY is unreliable,
	    AR is ON or OFF	  ISAKMP		  so S may stop sending
				- Does not rely on 	  when didn't need to
				  unreliable NOTIFY to	- Requires special case
				  get S to monitor Seq#	  for manual keying


   RESOLUTION: Use option (C) and specifying a special case for manual
		keying (where anti-reply is off)


2. Nesting of IPsec headers -- several issues have been raised during
   working group last call.

 A) How does OAKLEY/ISAKMP support specification of the ordering of
    nested IPsec headers, e.g., AH + ESP vs ESP + AH?  

 B) Should IPsec support arbitrary nesting or a limited set of ordered
    combinations of AH and ESP, in tunnel and transport modes?  If not,
	- how do we propose to support the IPv6's requirement that
	  systems accept arbitrary combinations of extension headers?
	- how do we propose to handle the situation of a BITW
	  implementation adding additional IPsec headers after the host
	  implementation (native or BITS) has added IPsec headers?
	- should we address arbitrary nesting in IPsecond?

 C) Do we need to add text clarifying how to handle nested headers by
    iteratively processing them -- discarding consumed headers,
    adjusting the mutable fields of the outer header, etc.  

    NOTE: The following text is in the Architecture document not in the
    AH/ESP document.  It was included as a warning to the reader in the
    AH/ESP draft announcement, but not in the drafts.
    
	Support for arbitrary nesting requires that implementations
        ensure that any mutable "AH protected" fields outside/above the
        AH header, i.e., IP length, IP Next Protocol and any IPsec
        headers, are appropriately handled by Outbound and Inbound
        processing as the headers are nested and unnested.  To ensure
        interoperability, the implementation should ignore the existence
        (i.e., neither zero the contents nor try to predict the contents) of
        IPsec headers to be applied later when
          o constructing an IPsec header
          o adjusting the IP length and IP Next Protocol in the IP
            header or immediately preceding IP extension header

        This will apply to:
             [IP][ESP or AH][ESP or AH]...[ESP or AH] [AH][upper]

        Nesting involving only ESP headers should not be problematic:
             [IP][ESP][ESP]...[ESP][upper]

 D) Do we need to add text clarifying that these issues apply to
    multiple nested headers for a single tunnel?  

  RESOLUTION: 
	  i. Define a small set of mandatory cases that must be supported.
	     Starting with a packet [IP1][upper]....

	     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]

	     Plus any combination of one of the above Tunnel cases
	     followed by one the above Transport cases, i.e., 4 then 1,
	     4 then 2, 4 then 3, 5 then 1, 5 then 2, 5 then 3.

   	 ii. Postpone figuring out how to handle other cases (mods to
	     Oakley/ISAKMP, clarifications for processing, etc.) to
	     IPsecond:
	iii. Address (C), and (D) above as appropriate given this resolution.

3.  HMAC-MD5 and HMAC-SHA --- which is mandatory, and which is strongly
    suggested.  There is a discrepancy between the various drafts as to 
    which the above two algorithms are mandotory, and which are
    "strongly suggested".  

    A) The DOI lists 1 mandatory authentication algorithm:
		- HMAC with MD5 
       and 1 "strongly encouraged" authentication algorithm:
	        - HMAC with SHA-1

    B) The AH and ESP specs list 2 mandatory authentication algorithms:
	        - HMAC with MD5 
	        - HMAC with SHA-1

    There was quite a bit of discussion of this on the list, with the
    last message coming from Hugo who stated that he felt that HMAC-SHA
    *was* stronger than HMAC-MD5, and that while the current (partial)
    attacks on MD5 do not affect HMAC-MD5, HMAC-SHA was definitely
    stronger, and he only felt comfortable suggesting the use of
    HMAC-MD5 if it was also possible to "quickly switch" to HMAC-SHA if
    further cryptographic advances made this advisable.  

    Given that nearly all the vendors had implemented both in their
    implementations, either choice did not appear to make much real
    difference to implementors.  

    RESOLUTION: That the AH and ESP specs require both HMAC-MD5 and
    HMAC-SHA to be required, and that the DOI be changed to also state
    that both algorithms are required.