[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AH/ESP Last Call Results
Hi All,
As you know, Bob Mosckowitz and I started a working group last
call on a series of documents, including the AH/ESP drafts, on October
6, 1997. This last call period ended on October 17, 1997. These are
the results of the last call.
During this period, a number of issues were brought up; most of
them were non-controversial, and those suggestions were adopted
without. There were three issues, however, which were did attract a
fair amount of discussion. Those three issues have been identified
below, with a proposed resolution, which was based on what seemed to
represent most amount of consensus.
If you have strong feelings with one of these proposed
resolutions to these issues below (and ideally if you have strongs and
new technical arguments which for some reason didn't reach the working
group during the last call period), please state them now. If we hear
no objections, though, this is how we plan to proceed towards making the
final adjustments before these two drafts are declared to be done and
ready to be shipped to the IESG.
Many thanks to Karen Seo who was invaluable to us in helping to
prepare this document.
- Ted
===============================================================================
PENDING
Both AH and ESP
---------------
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
PROPOSED RESOLUTION: Use option (b), leaving text as is.
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?
PROPOSED 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.
PROPOSED 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.
===============================================================================
RESOLVED
Both AH and ESP
---------------
1. Add reference to RFC 2119 for definitions of keywords.
Added the following paragraph at the end of the Introduction:
"The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they
appear in this document, are to be interpreted as described in
RFC 2119 [Bra97]."
Added the following text to the References:
"[Bra97] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Level," RFC-2119, March 1997."
2. Change text for Sequence Number Verification:
AH:
From: (3.4.3 Sequence Number Verification)
All AH implementations MUST support the anti-replay service,
though its use may be enabled or disabled on a per-SA basis.
To:
All AH implementations MUST support the anti-replay service,
though its use may be enabled or disabled by the receiver on a
per-SA basis.
ESP:
From: (3.4.3 Sequence Number Verification)
All ESP implementations MUST support the anti-replay service,
though its use may be enabled or disabled on a per-SA basis.
To:
All ESP implementations MUST support the anti-replay service,
though its use may be enabled or disabled by the receiver on a
per-SA basis.
3. Modify text on ICV re:
o length and truncation -- clarify that 96 bits is appropriate
for the default HMAC algorithms, but is not the general case.
o clarify that inbound checking of ICV is algorithm dependent
AH
From: (2.6 Authentication Data)
This is a variable-length field that contains the Integrity
Check Value (ICV) for this packet. The field must be an
integral multiple of 32 bits in length. The details of the
ICV computation are described in Section 3.3.3 below. This
field may include explicit padding. This padding is included
to ensure that the length of the AH header is an integral
multiple of 32 bits (IPv4) or 64 bits (IPv6). All
implementations MUST support such padding. Details of how to
compute the required padding length are provided below.
To:
This is a variable-length field that contains the Integrity
Check Value (ICV) for this packet. The field must be an
integral multiple of 32 bits in length. The details of the
ICV computation are described in Section 3.3.3 below. This
field may include explicit padding. This padding is included
to ensure that the length of the AH header is an integral
multiple of 32 bits (IPv4) or 64 bits (IPv6). All
implementations MUST support such padding. Details of how to
compute the required padding length are provided below. The
authentication algorithm specification MUST specify the length
of the ICV and the comparison rules and processing steps to
use for validation.
From: (3.2 Authentication Algorithms)
The authentication algorithm employed for the ICV computation
is specified by the SA. For point-to-point communication,
suitable authentication algorithms include keyed Message
Authentication Codes (MACs) based on symmetric encryption
algorithms (e.g., DES) or on one-way hash functions (e.g., MD5
or SHA-1). For multicast communication, one-way hash
algorithms combined with asymmetric signature algorithms are
appropriate, though performance and space considerations
currently preclude use of such algorithms. The
mandatory-to-implement authentication algorithms are described
in Section 5 "Conformance Requirements". Other algorithms MAY
be supported. Note: Where an algorithm yields more than 96
bits, the output of the computation is truncated to the
leftmost 96 bits.
To:
The authentication algorithm employed for the ICV computation
is specified by the SA. For point-to-point communication,
suitable authentication algorithms include keyed Message
Authentication Codes (MACs) based on symmetric encryption
algorithms (e.g., DES) or on one-way hash functions (e.g., MD5
or SHA-1). For multicast communication, one-way hash
algorithms combined with asymmetric signature algorithms are
appropriate, though performance and space considerations
currently preclude use of such algorithms. The
mandatory-to-implement authentication algorithms are described
in Section 5 "Conformance Requirements". Other algorithms MAY
be supported.
From: (3.4.4 Integrity Check Value Verification, 3rd paragraph)
Begin by saving the ICV value and replacing it (but not any
Authentication Data padding) with zero. Zero all other fields
that may have been modified during transit. (See section
3.3.3.1 for a discussion of which fields are zeroed before
performing the ICV calculation.) Check the overall length of
the packet, and if it requires implicit padding based on the
requirements of the authentication algorithm, append
zero-filled bytes to the end of the packet as required. Now
perform the ICV computation and compare the result with the
saved value. Note that if the output of the authentication
algorithm is greater than 96 bits, the output should be
truncated to the leftmost 96 bits. (If a digital signature
and one-way hash are used for the ICV computation, the
matching process is more complex and will be described in the
algorithm specification.)
To: Begin by saving the ICV value and replacing it (but not any
Authentication Data padding) with zero. Zero all other fields
that may have been modified during transit. (See section
3.3.3.1 for a discussion of which fields are zeroed before
performing the ICV calculation.) Check the overall length of
the packet, and if it requires implicit padding based on the
requirements of the authentication algorithm, append
zero-filled bytes to the end of the packet as required.
Perform the ICV computation and compare the result with the
saved value, using the comparison rules defined by the
algorithm specification. (For example, if a digital signature
and one-way hash are used for the ICV computation, the
matching process is more complex.)
ESP
From: (2.7 Authentication Data)
The Authentication Data is a variable-length field containing
an Integrity Check Value (ICV) computed over the ESP packet
minus the Authentication Data. The length of the field
depends upon the authentication function selected. However,
where the algorithm yields more than 96 bits, the output of
the computation is truncated to the leftmost 96 bits. The
Authentication Data field is optional, and is included only if
the authentication service has been selected for the SA in
question.
To:
The Authentication Data is a variable-length field containing
an Integrity Check Value (ICV) computed over the ESP packet
minus the Authentication Data. The length of the field
depends upon the authentication function selected. The
Authentication Data field is optional, and is included only if
the authentication service has been selected for the SA in
question. The authentication algorithm specification MUST
specify the length of the ICV and the comparison rules and
processing steps to use for validation.
From: (3.2.2 Authentication Algorithms)
The authentication algorithm employed for the ICV computation
is specified by the SA. For point-to-point communication,
suitable authentication algorithms include keyed Message
Authentication Codes (MACs) based on symmetric encryption
algorithms (e.g., DES) or on one-way hash functions (e.g., MD5
or SHA-1). For multicast communication, one-way hash
algorithms combined with asymmetric signature algorithms are
appropriate, though performance and space considerations
currently preclude use of such algorithms. Note: Where an
algorithm yields more than 96 bits, the output of the
computation is truncated to the leftmost 96 bits.
To:
The authentication algorithm employed for the ICV computation
is specified by the SA. For point-to-point communication,
suitable authentication algorithms include keyed Message
Authentication Codes (MACs) based on symmetric encryption
algorithms (e.g., DES) or on one-way hash functions (e.g., MD5
or SHA-1). For multicast communication, one-way hash
algorithms combined with asymmetric signature algorithms are
appropriate, though performance and space considerations
currently preclude use of such algorithms.
From: (3.4.4 Integrity Check Value Verification, paragraph 3)
Begin by removing and saving the ICV value (Authentication
Data field). Next check the overall length of the ESP packet
minus the Authentication Data. If implicit padding is
required, based on the blocksize of the authentication
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. Note
that if the output of the authentication algorithm is greater
than 96 bits, the output should be truncated to the leftmost
96 bits. (If a digital signature and one-way hash are used
for the ICV computation, the matching process is more complex
and will be described in the algorithm specification.)
To:
Begin by removing and saving the ICV value (Authentication
Data field). Next check the overall length of the ESP packet
minus the Authentication Data. If implicit padding is
required, based on the blocksize of the authentication
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.
(For example, if a digital signature and one-way hash are used
for the ICV computation, the matching process is more
complex.)
AH Only
-------
1. Modify AH section on ICV calculation to make clear what value should
reside in the IP base header for Protocol or Next Header.
Specifically, change:
From: (3.3.3.1.1.1 Base Header Fields)
The IPv4 base header fields are classified as follows:
Immutable
.....
Protocol
.....
To:
The IPv4 base header fields are classified as follows:
Immutable
.....
Protocol (This should be the value for the next header,
e.g., AH or ESP.)
.....
From: (3.3.3.1.2.1 Base Header Fields)
The IPv6 base header fields are classified as follows:
Immutable
.....
Next Header
.....
To:
The IPv6 base header fields are classified as follows:
Immutable
.....
Next Header (This should be the value for the next
extension header, e.g., AH, ESP,
Destination Options, etc.)
.....
ESP Only
--------
1. [Sch94] was not referenced. Delete the following text from the
Reference Section:
"[Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons,
New York, NY, 1994. ISBN 0-471-59756-2"
2. Clarify how inbound processing of encryption "Padding" field is
handled. Change...
From: (3.4.5 Packet Decryption)
The receiver:
......
2. removes/ignores any padding
......
To:
The receiver:
......
2. processes any padding as specified in the encryption
algorithm specification. The default action is to remove/ignore
any padding.
......
3. Clarify that Padding is calculated using only the "to be encrypted
portion of the Payload Data." Change...
From: (2.4 "Padding (for Encryption)")
The transmitter MAY add 0-255 bytes of padding. Inclusion of
the Padding field in an ESP packet is optional, but all
implementations MUST support generation and consumption of
padding.
To: The transmitter MAY add 0-255 bytes of padding. Inclusion
of the Padding field in an ESP packet is optional, but all
implementations MUST support generation and consumption of
padding. The padding computation applies to the plaintext
portion of the Payload Data, exclusive of the IV (if present).
4. Provide rationale for terminating Pad Length and Next Header fields
on 4-byte boundary... Change...
From: (2.4 "Padding (for Encryption)")
Padding also may be required, irrespective of encryption
algorithm requirements, to ensure that the resulting
ciphertext terminates on a 4-byte boundary. Specifically, the
Pad Length and Next Header fields must be right aligned within
a 4-byte word, as illustrated in the ESP packet format figure
above.
To:
Padding also may be required, irrespective of encryption
algorithm requirements, to ensure that the resulting
ciphertext terminates on a 4-byte boundary. Specifically, the
Pad Length and Next Header fields must be right aligned within
a 4-byte word, as illustrated in the ESP packet format figure
above, to ensure that the Authentication Data field (if
present) is aligned on a 4-byte boundary.
5. Add the following note to (2.3 "Payload Data"):
Note that with regard to ensuring the alignment of the (real)
ciphertext in the presence of an IV:
o For some IV-based modes of operation, the receiver treats the
IV as the start of the ciphertext, feeding it into the
algorithm directly. In these modes, alignment of the start of
the (real) ciphertext is not an issue at the receiver.
o In some cases, the receiver reads the IV in separately from
the ciphertext. In these cases, the algorithm specification
MUST address how alignment of the (real) ciphertext is to be
handled."
6. Change 3.3.4 "Integrity Check Value Calculation", paragraph 2 --
clarify placement of implicit padding.
From:
For some authentication algorithms, the byte string over which
the ICV computation is performed must be a multiple of a
blocksize specified by the algorithm. If the length of this
byte string does not match the blocksize requirements for the
algorithm, implicit padding MUST be appended to the end of the
ESP packet prior to ICV computation. ...
To:
For some authentication algorithms, the byte string over which
the ICV computation is performed must be a multiple of a
blocksize specified by the algorithm. If the length of this
byte string does not match the blocksize requirements for the
algorithm, implicit padding MUST be appended to the end of the
ESP packet, (after the Next Header field) prior to ICV
computation. ...
7. Clarify Section 3.4.5 -- if run in parallel, verification must be
*completed* before decryption.
From:
If authentication has been selected, ICV verification SHOULD
be performed before decryption. This order of processing
facilitates rapid detection and rejection of replayed or bogus
packets by the receiver, prior to decrypting the packet, hence
potentially reducing the impact of denial of service attacks.
Note: The receiver MAY start decryption in parallel with
authentication, but care must be taken to avoid possible race
conditions with regard to packet access and reconstruction of
the decrypted packet.
To:
If authentication has been selected, verification and
decryption MAY be done serially or in parallel. If done
serially, then ICV verification SHOULD be performed first. If
done in parallel, verification SHOULD be completed before the
decrypted packet is passed on for further processing. This
order of processing facilitates rapid detection and rejection
of replayed or bogus packets by the receiver, prior to
decrypting the packet, hence potentially reducing the impact
of denial of service attacks. Note: If the receiver does
decryption in parallel with authentication, care must be taken
to avoid possible race conditions with regard to packet access
and reconstruction of the decrypted packet.
Follow-Ups: