[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Internet Drafts -- AH and ESP specs
Folks,
We just submitted drafts of the AH and ESP specs to the IETF Secretariat
for posting for working group Last Call. The following list is a
summary/guide to the changes we've made in response to the group's
feedback on the end of July drafts. (This does not include fixes for
minor typos, etc.) Note that items 1-7 apply to both AH and ESP, items
8-9 apply to only AH, and items 10-11 apply to only ESP.
Thank you,
Karen
-------------------------------------------------------------------------------
AH and ESP
==========
1. Re-organized processing section of the documents:
- to have an Algorithms section
- so that Outbound and Inbound processing sections are more parallel.
Outbound Inbound
--------- -------
SA Lookup Reassembly (if needed)
Encryption (if ESP) SA Lookup
Seq Number Generation Sequence Number Verification
ICV Calculation ICV Verification
Fragmentation (if needed) Decryption (if ESP)
AH -- Changed from (some lower level sections are not shown):
3. Authentication Header Processing...........................6
3.1 Authentication Header Location........................6
3.2 Outbound Packet Processing............................8
3.2.1 Security Association Lookup......................8
3.2.2 Sequence Number Generation.......................8
3.2.3 Integrity Check Value Calculation................9
3.2.3.1 Handling Mutable Fields.....................9
3.2.3.2 Padding....................................11
3.2.3.3 Authentication Algorithms..................12
3.2.4 Fragmentation...................................12
3.3 Inbound Packet Processing............................13
3.3.1 Reassembly......................................13
3.3.2 Security Association Lookup.....................13
3.3.3 Sequence Number Verification....................13
3.3.4 Integrity Check Value Verification..............14
to (some lower level sections are not shown):
3. Authentication Header Processing...........................6
3.1 Authentication Header Location........................6
3.2 Authentication Algorithms.............................8
3.3 Outbound Packet Processing............................9
3.3.1 Security Association Lookup......................9
3.3.2 Sequence Number Generation.......................9
3.3.3 Integrity Check Value Calculation...............10
3.3.3.1 Handling Mutable Fields....................10
3.3.3.2 Padding....................................12
3.3.4 Fragmentation...................................13
3.4 Inbound Packet Processing............................14
3.4.1 Reassembly......................................14
3.4.2 Security Association Lookup.....................14
3.4.3 Sequence Number Verification....................14
3.4.4 Integrity Check Value Verification..............15
ESP -- Changed from:
3. Encapsulating Security Protocol Processing.................7
3.1 ESP Header Location...................................7
3.2 Outbound Packet Processing...........................10
3.2.1 Security Association Lookup.....................10
3.2.2 Sequence Number Generation......................10
3.2.3 Packet Encryption...............................10
3.2.3.1 Scope of Encryption.........................10
3.2.3.2 Encryption Algorithms.......................11
3.2.4 Integrity Check Value Calculation...............11
3.2.4.1 Scope of Authentication Protection.........11
3.2.4.2 Authentication Padding.....................11
3.2.4.3 Authentication Algorithms..................12
3.2.5 Fragmentation...................................12
3.3 Inbound Packet Processing............................12
3.3.1 Pre-ESP Processing Overview.....................12
3.3.2 Security Association Lookup.....................12
3.3.3 Sequence Number Verification....................13
3.3.4 Integrity Check Value Verification..............14
3.3.5 Packet Decryption...............................15
to:
3. Encapsulating Security Protocol Processing.................7
3.1 ESP Header Location...................................7
3.2 Algorithms...........................................10
3.2.1 Encryption Algorithms...........................10
3.2.2 Authentication Algorithms.......................10
3.3 Outbound Packet Processing...........................11
3.3.1 Security Association Lookup.....................11
3.3.2 Packet Encryption...............................11
3.3.3 Sequence Number Generation......................12
3.3.4 Integrity Check Value Calculation...............12
3.3.5 Fragmentation...................................13
3.4 Inbound Packet Processing............................13
3.4.1 Reassembly......................................13
3.4.2 Security Association Lookup.....................13
3.4.3 Sequence Number Verification....................14
3.4.4 Integrity Check Value Verification..............15
3.4.5 Packet Decryption...............................15
-------------------------------------------------------------------------------
2. Reworded definition of SPI.
AH -- Section "2.4 Security Parameters Index (SPI), changed from:
"The SPI is an arbitrary 32-bit value that uniquely identifies
the Security Association for this datagram, relative to the
destination IP address contained in the IP header with which
this security header is associated, and relative to the security
protocol employed."
to:
The SPI is an arbitrary 32-bit value that, in combination with
the destination IP address and security protocol, uniquely
identifies the Security Association for this datagram.
ESP -- Section "2.1 Security Parameters Index", changed from:
"The SPI is an arbitrary 32-bit value that uniquely identifies
the Security Association for this datagram, relative to the
destination IP address contained in the IP header with which
this security header is associated, and relative to the security
protocol employed."
to:
The SPI is an arbitrary 32-bit value that, in combination with
the destination IP address and security protocol, uniquely
identifies the Security Association for this datagram.
-------------------------------------------------------------------------------
3. Changed AH and ESP diagrams to more closely conform with the IPv6
spec (see July 1997 version, page 8)
AH -- Section "3.1 Authentication Header Location", changed:
AFTER APPLYING AH
------------------------------------------------------------
IPv6 | |hxh,rtg,frag| dest | | dest | | |
|orig IP hdr |if present**| opt* | AH | opt* | TCP | Data |
------------------------------------------------------------
|<---- authenticated except for mutable fields ----------->|
* = if present, could be before AH, after AH, or both
** = hop by hop, routing, fragmentation headers
to:
AFTER APPLYING AH
------------------------------------------------------------
IPv6 | |hop-by-hop, dest*, | | dest | | |
|orig IP hdr |rtg, fragmentation | AH | opt* | TCP | Data |
------------------------------------------------------------
|<---- authenticated except for mutable fields ----------->|
* = if present, could be before AH, after AH, or both
ESP -- Section "3.1 ESP Header Location", changed:
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hxh,rtg,frag|dest|ESP|dest| | | ESP | ESP|
|IP hdr|if present**|opt*|Hdr|opt*|TCP|Data|Trailer|Auth|
---------------------------------------------------------
|<---- encrypted ---->|
to: |<---- authenticated ---->|
AFTER APPLYING ESP
-----------------------------------------------------------
IPv6 | orig |hop-by-hop, dest*, | |dest| | | ESP | ESP|
|IP hdr|rtg, fragmentation |ESP|opt*|TCP|Data|Trailer|Auth|
-----------------------------------------------------------
|<---- encrypted ---->|
|<---- authenticated ---->|
* = if present, could be before ESP, after ESP, or both
-------------------------------------------------------------------------------
4. Clarified AH and ESP explanation for zero SPI....
AH -- Section "2.4 Security Parameters Index", changed:
(A zero value may be used for local debugging purposes, but no
AH packets should be transmitted with a zero SPI value.)
to:
The SPI value of zero (0) is reserved for local,
implementation-specific use and MUST NOT be sent on the wire.
For example, a key management implementation MAY use the
zero SPI value to mean "No Security Association Exists" during
the period when the IPsec implementation has requested that its
key management entity establish a new SA, but the SA has not yet
been established.
ESP -- Section "2.1 Security Parameters Index"
(A zero value may be used for local debugging purposes, but no
AH packets should be transmitted with a zero SPI value.)
to:
The SPI value of zero (0) is reserved for local,
implementation-specific use and MUST NOT be sent on the wire.
For example, a key management implementation MAY use the
zero SPI value to mean "No Security Association Exists" during
the period when the IPsec implementation has requested that its
key management entity establish a new SA, but the SA has not yet
been established.
-------------------------------------------------------------------------------
5. For *transport* mode, changed the AH and ESP documents to state that
with regard to nesting of AH and ESP headers:
o Security policy determines the order of application.
o The following 3 cases MUST be supported:
1. [IP][AH][upper]
2. [IP][ESP][upper]
3. [IP][AH][ESP][upper]
o Arbitrary nesting is allowed -- it is a MAY generate for
senders and a SHOULD accept for receivers.
*WARNING*: The flexibility to have arbitrary nesting was requested by
several folks on the WG list but will require extra care by
implementors. Specifically, arbitrary nesting will require the
implementors to 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. Implementations
also will need to take into account the rules for IPv6 header
extension processing. This complexity will apply to:
4. [IP][ESP or AH][ESP or AH]...[ESP or AH] [AH][upper]
Nesting involving only ESP headers should not be problematic:
5. [IP][ESP][ESP]...[ESP][upper]
At present, the following changes have been made to the AH and ESP
specs.
For AH -- Section "3.1 Authentication Header Location", paragraph 2,
changed from:
In transport mode, AH is inserted after the IP header and before
an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before
any other IPsec headers that have already been inserted, e.g.,
ESP. In the context of IPv4, this calls for placing AH after
the IP header (and any options that it contains), but before the
upper layer protocol....
to:
In transport mode, AH is inserted after the IP header and before
an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before
(outside of) any other IPsec headers that have already been
inserted. In the context of IPv4, this calls for placing AH
after the IP header (and any options that it contains), but
before the upper layer protocol...
The following text has been added after the diagram of applying
AH in transport mode to an IPv6 packet:
If more than one IPsec header/extension is required:
o the order of application of the security headers MUST be
defined by security policy
o The following 3 cases MUST be supported:
1. [IP][AH][upper]
2. [IP][ESP][upper]
3. [IP][AH][ESP][upper]
o arbitrary nesting is allowed -- Senders MAY generate
arbitrary nestings of IPsec headers and Receivers SHOULD
accept arbitrary nestings of IPsec headers.
Also in Section "3.2 Outbound Packet Processing" (now called 3.3),
added the following as a second paragraph.
If there is more than one IPsec header/extension required, the
order of the application of the security headers MUST be defined
by security policy. For simplicity of processing, each IPsec
header SHOULD ignore the existence (i.e., not zero the contents
or try to predict the contents) of IPsec headers to be applied
later. (While a native IP or bump-in-the-stack implementation
could predict the contents of later IPsec headers that it
applies itself, it won't be possible for it to predict any IPsec
headers added by a bump-in-the-wire implementation between the
host and the network.)
Also, in Section "3.3 Inbound Packet Processing" (now called 3.4),
added the following as a first paragraph to the section.
If there is more than one IPsec header/extension present, the
processing for each one ignores (does not zero, does not use)
any IPsec headers applied subsequent to the header being
processed.
For ESP -- Section "3.1 ESP Header Location", paragraph 2, changed
from:
In transport mode, ESP is inserted after the IP header and
before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or
before any other IPsec headers that have already been inserted,
e.g., AH. In the context of IPv4, this translates to placing
ESP after the IP header (and any options that it contains), but
before the upper layer protocol....
to:
In transport mode, ESP is inserted after the IP header and
before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or
before any other IPsec headers that have already been inserted.
In the context of IPv4, this translates to placing ESP after the
IP header (and any options that it contains), but before the
upper layer protocol.
The following text has been added after the diagram of applying
ESP in transport mode to an IPv6 packet:
If more than one IPsec header/extension is required:
o the order of application of the security headers MUST be
defined by security policy
o The following 3 cases MUST be supported:
1. [IP][AH][upper]
2. [IP][ESP][upper]
3. [IP][AH][ESP][upper]
o arbitrary nesting is allowed -- Senders MAY generate
arbitrary nestings of IPsec headers and Receivers SHOULD
accept arbitrary nestings of IPsec headers.
Also in Section "3.2 Outbound Packet Processing", (now called
section 3.3) added the following sentence at the end of the first
paragraph:
"If there is more than one IPsec header/extension required by
security policy, the order of the application of the security
headers MUST be defined by security policy."
-------------------------------------------------------------------------------
6. Modified Sequence Number text in the following sections. (The left
section numbers are from after the re-organization mentioned above.
The "was" numbers are the section numbers from the versions
distributed to the working group in July.)
Section AH was ESP was
---------------------------- ----- ----- ----- -----
Sequence Number 2.5 2.2
Sequence Number Generation 3.3.2 3.2.2 3.3.3 3.2.2
Sequence Number Verification 3.4.3 3.3.3 3.4.3 3.3.3
to convey to the reader that:
For Sender:
- If anti-replay has been enabled, the transmitted Sequence
Number must never be allowed to cycle. In this case, the
sender's counter and the receiver's counter MUST be reset (by
establishing a new SA (with a new SPI and a new key)) prior to
the transmission of the 2^32nd packet on an SA.
- Only if anti-replay has been enabled, is a counter overflow an
auditable event for the sender.
- If anti-replay has not been enabled, the sender does not need
to monitor or reset the counter, e.g., in the case of manual
key management. Text has been included saying:
"NOTE: If the receiver does NOT notify the sender that
anti-replay is enabled, then the sender may overflow the
counter and may send packets that the receiver will
reject."
For Receiver:
- Receiver SHOULD notify sender if anti-replay is enabled.
- Receiver does NOT notify sender of window size.
- Default (required minimum) receive window-size is 32,
recommended is 64, other sizes >32 are allowed. The
following text was chosen:
"A MINIMUM window size of 32 MUST be supported; but a
window size of 64 is preferred and SHOULD be employed as
the default. Another window size (larger than the
MINIMUM) MAY be chosen by the receiver."
-------------------------------------------------------------------------------
7. Updated the references on mandatory-to-implement algorithms; changed
all previous mentions of these algorithms to point to Section 5.
"Conformance Requirements." As a result also had to change the text
that explained about truncation to the leftmost 96 bits since it
originally mentioned the default algorithms.
AH:
3.2 Authentication 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.
Other sections were changed too.
5. Conformance Requirements..... A compliant AH implementation
MUST support the following mandatory-to-implement algorithms:
- HMAC with MD5 [MG97a]
- HMAC with SHA-1 [MG97b]
Added references:
"[MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96
within ESP and AH", Internet Draft, 7/2/97."
"[MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96
within ESP and AH", Internet Draft, 7/2/97."
ESP:
Changed the mandatory-to-implement encryption algorithms from
DES-CBC with implicit IV generation to DES-CBC with explicit IV;
updated the reference; changed all previous references to these
algorithms to point to Section 5. "Conformance Requirements."
Other sections were changed too.
3.2 Algorithms....."The mandatory-to-implement algorithms are
described in Section 5, "Conformance Requirements". Other
algorithms MAY be supported."
3.2.2 Authentication Algorithms... Note: Where an algorithm
yields more than 96 bits, the output of the computation is
truncated to the leftmost 96 bits.
In Section "5. Conformance Requirements"..... "A compliant ESP
implementation MUST support the following mandatory-to-implement
algorithms:
- DES in CBC mode [MD97]
- HMAC with MD5 [MG97a]
- HMAC with SHA-1 [MG97b]
Deleted:
"[MS97] Perry Metzger & W.A. Simpson, "The ESP DES-CBC
Transform", RFC-xxxx, August 1997."
Added:
"[MD97] C. Madson & N. Doraswamy, "The ESP DES-CBC
Cipher Algorithm With Explicit IV", 07/02/1997."
"[MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96
within ESP and AH", Internet Draft, 7/2/97."
"[MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96
within ESP and AH", Internet Draft, 7/2/97."
-------------------------------------------------------------------------------
AH only
=======
8. Clarified explanation for how Payload Length is calculated.
Section "2.2 Payload Length", changed from:
This 8-bit field specifies the length of AH, in 32-bit words
(4-byte units), minus "2," i.e., the fixed portion (as defined
in the original AH spec) of AH is not counted. (Since the
Sequence Number field is always present, the fixed portion of AH
is now three 32-bit words. However, the "minus 2" length
adjustment has been retained for backwards compatibility.)
to:
This 8-bit field specifies the length of AH in 32-bit words
(4-byte units), minus "2". (All IPv6 extension headers, as per
RFC 1883, encode the "Hdr Ext Len" field by first subtracting 1
(64-bit word) from the header length (measured in 64-bit words).
AH is an IPv6 extension header. However, since its length is
measured in 32-bit words, the "Payload Length" is calculated by
subtracting 2 (32 bit words).)
-------------------------------------------------------------------------------
9. Clarified that the AH ICV covers the header itself.
Inserted the following text after 3.3.3 "Integrity Check Value
Calculation":
"The AH ICV is computed over:
o IP header fields that are either immutable in transit
or that are predictable in value upon arrival at the
endpoint for the AH SA
o the AH header (Next Header, Payload Len, Reserved,
SPI, Sequence Number, and the Authentication Data
(which is set to zero for this computation))
o the upper level protocol data, which is assumed to be
immutable in transit
Deleted the first two sentences of 3.3.3.1 Handling Mutable Fields,
paragraph 1, leaving:
If a field may be modified during transit, the value of the
field is set to zero for purposes of the ICV computation. If a
field is mutable, but its value at the (IPsec) receiver is
predictable, then that value is inserted into the field for
purposes of the ICV calculation. The Authentication Data field
is also set to zero in preparation for this computation. Note
that by replacing each field's value with zero, rather than
omitting the field, alignment is preserved for the ICV
calculation. Also, the zero-fill approach ensures that the
length of the fields that are so handled cannot be changed
during transit, even though their contents are not explicitly
covered by the ICV.
-------------------------------------------------------------------------------
ESP only
========
10. Made section "3.3.1 Pre-ESP Processing Overview" (now called "3.4.1
Reassembly") parallel to the AH section "3.3.1 Reassembly" (now
called 3.4.1 Reassembly"), by changing:
"If required, reassembly is performed prior to ESP processing."
to:
"If required, reassembly is performed prior to ESP processing.
If a packet offered to ESP for processing appears to be an IP
fragment, i.e., the OFFSET field is non-zero or the MORE
FRAGMENTS flag is set, the receiver MUST discard the packet;
this is an auditable event. The audit log entry for this event
SHOULD include the SPI value, date/time, Source Address,
Destination Address, and (in IPv6) the Flow ID."
-------------------------------------------------------------------------------
11. Made discussion of 3.2.3 Packet Encryption (now called 3.3.2) more
parallel to the discussion of 3.3.5 Packet Decryption (now called
3.4.5).