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

Fwd: IPsec ESP-bis -- Last Call revisions

Title: Fwd: IPsec ESP-bis -- Last Call revisions
Apologies if this is a repeat -- it seems to have hit a mail snag of some sort, so I'm resending it.

X-Sender: kseo@po2.bbn.com
Date: Tue, 15 Jul 2003 18:44:37 -0400
To: "Angelos D. Keromytis" <angelos@cs.columbia.edu>
From: Karen Seo <kseo@bbn.com>
Subject: IPsec ESP-bis -- Last Call revisions
Cc: Barbara Fraser <byfraser@cisco.com>, tytso@mit.edu, skent@bbn.com,
   clynn@bbn.com, kseo@bbn.com
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.

===============================================================================