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

revised ID -- IP Encapsulating Security Payload (ESP)



Title: revised ID -- IP Encapsulating Security Payload (ESP)
Folks,

A revision of the ESP ID has been submitted to the IETF secretariat.  This email contains 2 lists describing:
        1. changes to the previous draft
        2. issues that reviewers raised that did not result
           in changes.

Please let us know if you have any questions, comments, etc.  Thank you,
Karen

The new draft of the ESP ID has the following changes (not counting fixes to typos and grammatical errors)  All page numbers refer to the previous draft, not the new one.

1. All 3 of the following sentences should be consistent with the idea
   that encryption-only service MAY be offered.

    On Page 4, paragraph 4, first sentence:
     "An implementation MAY offer confidentiality independent of
        all other services...."
                This whole paragraph has been modified per item 2 below.

    On Page 5, paragraph 2, first bullet:
        "-- confidentiality-only (SHOULD be supported)"
                Changed "SHOULD" to "MAY"

    On Page 33, section 7, first bullet:
        "Confidentiality-only service -- now a SHOULD, not a MUST
                Changed "SHOULD" to "MAY"

2. Page 4, Introduction, paragraph 4, has been changed (to make a
   stronger recommendation against using encryption without
   integrity) from:

        "An implementation MAY offer confidentiality independent
        of all other  services.  Use of confidentiality without
        integrity (either in ESP or   separately in AH) may subject
        traffic to certain forms of active   attacks that could
        undermine the confidentiality service (see   [Bel96]).
        ESP allows confidentiality-only SAs because this may offer
        considerably better performance and still provide adequate
        security, e.g., when higher layer authentication/integrity
        protection is offered independently. However, this standard
        does not require all  ESP implementations to offer this
        service separately."

   to:
        "Using encryption-only for confidentiality is allowed by
        ESP. However, it should be noted that in general, this
        will provide defense only against passive attackers.  Using
        encryption without a strong integrity mechanism on top of
        it (either in ESP or separately in AH) may render the
        confidentiality service insecure against active attackers
        [Bel96, Kra01].  Moreover, an underlying integrity service,
        such as AH, applied before encryption does not necessarily
        protect the encryption-only confidentiality against active
        attackers [Kra01]. ESP allows encryption-only SAs because
        this may offer considerably better performance and still
        provide adequate security, e.g., when higher layer
        authentication/integrity protection is offered independently.
        However, this standard does not require all ESP
        implementations to offer thi service separately."

   and the reference [Kra01] has been added

        [Kra01]   Krawczyk, H., "The Order of Encryption and
        Authentication for Protecting Communications (Or: How
        Secure Is SSL?)", CRYPTO' 2001.

   This paper can be found at: http://eprint.iacr.org/2001/045


3. Page 7, A note has been added before Figure 2, that clarifies that
   this diagram is for a bits-on-the-wire format...

        "(Note: This diagram shows bits-on-the-wire.  So even if
        extended sequence numbers are being used, only 32 bits of
        the Sequence Number will be transmitted (see Section
        2.2.1).)"

4. Clarification on Page 14, Section 2.4, first bullet on page
   has been changed from:

      o For the purpose of ensuring that the bits to be encrypted
         ...... If a combined algorithm mode requires transmission
         of the SPI and Sequence Number to effect integrity, then
         these data items, and any associated, ICV-equivalent data,
         are included in the computation....

   to:
       o For the purpose of ensuring that the bits to be encrypted
         ...... If a combined algorithm mode requires transmission
         of the SPI and Sequence Number to effect integrity, e.g.,
         replication of the SPI and Sequence Number in the Payload
         Data, then the replicated versions of these data items,
         and any associated, ICV-equivalent data, are included in
         the computation...

5. Page 23. Section 3.3.2.2 the following item has been changed
   from:

          "2. adds any necessary padding -- includes optional
              TFC padding and Padding."
   to:
          "2. adds any necessary padding -- includes optional
              TFC padding and (encryption) Padding."

6. An Appendix on "Extended (64-bit) Sequence Numbers" has been added.


The following issues/questions were raised, but did not result in changes to the spec.


A. Page 32, Section 5 "Conformance Requirements".  For "AES in CBC   mode", should there be a default key size (128/192/256/etc)?

        We will adopt 128 as the default key size, as recently
        discussed on the list, unless we hear otherwise.

B. Page 32, Section 5 "Conformance Requirements". Should 3DES be
   required for compatibility with existing implementations?

        The previous version of ESP required DES, not 3DES, so not
        all compliant existing implementations would offer 3DES.
        In practice, it is likely to be true that most folks do
        offer 3DES CBC, but making this a mandatory mode removes
        the incentive to go to AES CBC, which will be faster.  So,
        this version of ESP does not include 3DES CBC as a
        mandatory mode.

C. Page 32, Section 5 -  What should the draft say about a counter
   mode standard?

        There are several counter mode proposals floating around
        as IDs, but it is too early to put anything in the draft
        yet.  The WG will have to select a counter mode standard
        and decide if it will be a mandatory mode and thus
        included in the ESP spec,  or if it will be an optional
        mode and thus not part of the ESP spec.

D. Page 12, Section 2.2.1 "Extended Sequence Number" -- both ends must
   know when this feature is used for an SA; however the text says
   "Use of an Extended Sequence Number (ESN) SHOULD be negotiated
   by an SA management protocol, although it could also be part of
   the configuration data for a manually configured SA."

        The draft says "SHOULD" vs. "MUST" in case someone wants
        to go with manual configuration of this feature. However,
        we propose to change this to "MUST" if the WG concurs.