[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Final changes for AH/ESP documents
As you may know, there was some last-minute controversy over the AH/ESP
results, specifically over the Sequence Number and Anti-replay Server
issue, with a number of people requesting that we use option (C) instead
of option (B). After discussing the issues with the document editor
and the various involved parties, we've agreed to indeed use option (C).
The document editors asked me to send a message to the list reflecting
the final editing directions for these documents, which follow below.
My personal thanks for all of the work that people have placed into
editing, reviewing, and implementing these documents.
- Ted
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
RESOLUTION: Use option (C) and specifying a special case for manual
keying (where anti-reply is off)
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?
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.
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.