Fwd: IPsec ESP-bis -- Last Call revisions

[Karen Seo <[e-mail]>]

Apologies if this is a repeat -- it seems to have hit a mail snag of 
some sort, so I'm resending it.

>X-Sender: [e-mail]
>Date: Tue, 15 Jul 2003 18:44:37 -0400
>To: "Angelos D. Keromytis" <[e-mail]>
>From: Karen Seo <[e-mail]>
>Subject: IPsec ESP-bis -- Last Call revisions
>Cc: Barbara Fraser <[e-mail]>, [e-mail], [e-mail],
>    [e-mail], [e-mail]
>X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
>Status:  
>
>Angelos,
>
>Here are the comments and their status for ESP....  Revisions have 
>been made to address the comments and the changes have been either 
>approved by the commenter (1-12) or sent to the commenter for 
>approval (13, 14) .  These cover all the tickets for ESP-bis.
>
>I think 13 and 14 look likely to be approved but am going to wait 
>for Russ to reply before submitting the revised draft to the IETF.
>
>Karen
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03
>Status:		change approved by Russ on 7/15/03
>
>>1.  Please delete the last line of the Abstract.  In my opinion, 
>>pointers to subsequent sections belong in the Introduction, not the 
>>Abstract.
>
>	Moved to end of Introduction.
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03
>Status:		change approved by Russ on 7/15/03
>
>>2.  Please move the last two paragraphs of the Introduction to the 
>>beginning.  This will tell the reader the material that the 
>>expected to be understood before they get too deep, and it will 
>>define MAY. SHOULD, MUST, and so on before they are used.
>
>	Done.
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03
>Status:		change approved by Russ on 7/15/03
>
>>3.  The last paragraph on page 4 includes:
>>
>>    Typically this binding is effected through the use of a shared,
>>    symmetric key, but an asymmetric cryptographic algorithm also may be
>>    employed, e.g., to sign a hash.)
>>
>>Digitally signing individual packets should not be encouraged.  The 
>>performance ramifications, both computational and packet bloat, are 
>>extreme.  I suggest dropping the second half of the sentence.  Just 
>>do not bring it up.
>
>	Done.
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03
>Status:		change approved by Russ on 7/15/03
>
>>4.  The first full paragraph at the top of page 5 includes:
>>
>>    Although confidentiality and integrity can be offered independently,
>>    most ESP use typically will employ both services, i.e., packets will
>>    be protected with regard to confidentiality and integrity.
>>
>>s/use/uses/
>
>	Changed to: Although confidentiality and integrity can be
>	offered independently, ESP typically will employ....
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03
>Status:		change approved by Russ on 7/15/03
>
>>5.  The following paragraph appears on the second half of page 7:
>>
>>    When any combined mode algorithm is employed, the algorithm itself is
>>    expected to return both decrypted plaintext and a pass/fail
>>    indication for the integrity check. For combined mode algorithms, the
>>    ICV that would normally appear at the end of the ESP packet (when
>>    integrity is selected) is omitted. It is the responsibility of the
>>    combined mode algorithm to encode within the payload data an ICV-
>>    equivalent means of verifying the integrity of the packet.
>>
>>I consider CCM (see draft-ietf-ipsec-ciph-aes-ccm-03) to be a 
>>combined mode.  The referenced specification makes use of the ICV 
>>field.  Therefore, I propose two changes:
>>
>>    - Please replace "is omitted" to "may be omitted"
>
>	Done.
>
>>
>>    - Please change "It is the responsibility of the combined mode 
>>algorithm ..." to "When the ICV is omitted and integrity is 
>>selected, it is the responsibility of the combined mode algorithm 
>>..."
>
>	Done.
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03
>Status:		change approved by Russ on 7/15/03
>
>>6.  Figure 2 include "IV (optional]. "
>>s/]/)/
>
>	Done.
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03
>Status:		change approved by Russ on 7/15/03
>
>>7.  Below Figure 2, the following paragraph appears:
>>
>>    If a combined algorithm mode is employed, the explicit ICV shown in
>>    Figures 1 and 2 is omitted (see Section 3.3.2.2 below). Since
>>    algorithms and modes are fixed when an SA is established, the
>>    detailed format of ESP packets for a given SA (including the Payload
>>    Data substructure) is fixed, for all traffic on the SA.
>>
>>s/is omitted/may be omitted/
>
>	Done.
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03
>Status:		change approved by Russ on 7/15/03
>
>>8.  In Table 2, the ICV row should be "O" in the "Requ'd" column.
>
>	Changed the ICV row and added a footnote:
>
>                                      What    What    What
>                     # of     Requ'd  Encrypt Integ    is
>                     bytes      [1]   Covers  Covers  Xmtd
>                     ------   ------  ------  ------  ------
>       ICV           variable   O [6]                 plain
>
>            [6] The algorithm spec determines whether this field is
>                 present
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03
>Status:		change approved by Russ on 7/15/03
>
>>9.  The first sentence in section 2.2.1, has the flavor of a new 
>>option that is under development, rather than one that is ready to 
>>be finalized.  I propose an alternative:
>>
>>    To support high-speed IPsec implementations, extended sequence
>>    numbers SHOULD be implemented.
>
>	Done.
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03
>Status:		change approved by Russ on 7/15/03
>
>>10.  At the beginning of section 2.4, the following sentence is 
>>followed by two bullets.  Something is not quite right.
>>
>>    Three factors require or motivate use of the Padding field.
>
>	Changed to "Two primary factors require....."
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03
>Status:		change approved by Russ on 7/15/03
>
>>11.  Please reword the paragraph in section 2.8 to permit the ICV 
>>field to be present when a combined mode is employed, which is 
>>consistent with the wording used in section 3.2.3.
>
>	Changed:
>    From:
>	The ICV field is optional; it is present only if the integrity
>	service is selected and a separate (not combined mode)
>	integrity algorithm is employed.
>
>    To:
>	The ICV field is optional.  It is present only if integrity
>	service is selected and is provided by either a separate
>	integrity algorithm or a combined mode algorithm that uses
>	an ICV.
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03
>Status:		change approved by Russ on 7/15/03
>
>>12. Please reword the 4th bullet following the paragraph numbered 3 
>>in section 3.3.2.2 to permit the ICV field to be present when a 
>>combined mode is employed.
>
>	Changed:
>
>    From:
>	The (explicit) ICV field is NOT part of the ESP packet
>	format when a combined mode algorithm is employed,
>	although an analogous field usually will a part of
>	the ciphertext payload.
>
>    To:
>	The (explicit) ICV field MAY be a part of the ESP
>	packet format when a combined mode algorithm is
>	employed. If one is not used, an analogous field usually
>	will be a part of the ciphertext payload.
>
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/16/03 and 7/15/03
>Status:		sent following proposed change to Russ on 7/15/03
>
>>13. I am confused by "DISCUSSION" in section 3.4.4.1.
>
>	We asked for clarification on 7/4/03 and received the feedback
>	below:
>
>>It says:
>>
>>                DISCUSSION:
>>
>>                Begin by removing and saving the ICV field. Next check the
>>                overall length of the ESP packet minus the ICV field. If
>>                implicit padding is required, based on the blocksize of the
>>                integrity algorithm, append zero-filled bytes to the end of
>>                the ESP packet directly after the Next Header
>>                field. Perform the ICV computation and compare the result
>>                with the saved value, using the comparison rules defined by
>>                the algorithm specification.
>>
>>My issue is that there is no context provided.
>>
>>I think this would be better structured as an Implementation Note.  Like:
>>
>>         Implementation Note:  Implementations can use any set of steps
>>         that results in the same result as the following set of steps.  Begin
>>         by ...
>>
>
>    Changed to:
>
>	Implementation Note:
>
>	Implementations can use any set of steps that results in the
>	same result as the following set of steps.  Begin by removing
>	and saving the ICV field. Next check the overall length of the
>	ESP packet minus the ICV field. If implicit padding is
>         required, based on the blocksize of the integrity algorithm,
>	append zero-filled bytes to the end of the ESP packet directly
>	after the Next Header field. Perform the ICV computation and
>	compare the result with the saved value, using the comparison
>	rules defined by the algorithm specification.
>
>===============================================================================
>
>Commenter:	Russ Housley
>Date:		6/17/03
>Status:		sent following proposed change to Russ on 7/15/03
>
>>14.  The references need to be divided in to normative and informative.
>
>	We changed the References to:
>
>    References
>
>
>    Normative
>
>	[Bra97] Bradner, S., "Key words for use in RFCs to
>	Indicate Requirement Level", BCP 14, RFC 2119, March
>	1997.
>
>	[KA98] Kent, S., and R. Atkinson, "Security
>	Architecture for the Internet Protocol", RFC 2401,
>	November 1998.
>
>     Informative
>
>	[Bel96] Steven M. Bellovin, "Problem Areas for the IP
>	Security Protocols", Proceedings of the Sixth Usenix
>	Unix Security Symposium, July, 1996.
>
>	[HC03]	Holbrook, H., and Cain, B., "Source Specific
>	Multicast for IP", Internet Draft,
>	draft-ietf-ssm-arch-01.txt, November 3, 2002.
>
>	[HC98] Harkins, D., and D. Carrel, "The Internet Key
>	Exchange (IKE)", RFC 2409, November 1998.
>
>	[Ken03] Kent, S., "IP Authentication Header", RFC ???,
>	??? 2003.
>
>	[Kra01] Krawczyk, H., "The Order of Encryption and
>	Authentication for Protecting Communications (Or: How
>	Secure Is SSL?)", CRYPTO' 2001.
>
>===============================================================================