[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.