draft-ietf-hip-esp-01.txt   draft-ietf-hip-esp-02.txt 
Network Working Group P. Jokela Network Working Group P. Jokela
Internet-Draft Ericsson Research NomadicLab Internet-Draft Ericsson Research NomadicLab
Expires: April 27, 2006 R. Moskowitz Expires: September 3, 2006 R. Moskowitz
ICSAlabs, a Division of TruSecure ICSAlabs, a Division of TruSecure
Corporation Corporation
P. Nikander P. Nikander
Ericsson Research NomadicLab Ericsson Research NomadicLab
October 24, 2005 March 2, 2006
Using ESP transport format with HIP Using ESP transport format with HIP
draft-ietf-hip-esp-01 draft-ietf-hip-esp-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2006. This Internet-Draft will expire on September 3, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo specifies an Encapsulated Security Payload (ESP) based This memo specifies an Encapsulated Security Payload (ESP) based
mechanism for transmission of user data packets, to be used with the mechanism for transmission of user data packets, to be used with the
Host Identity Protocol (HIP). Host Identity Protocol (HIP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 6 3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 6
3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 6 3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 6
3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 6 3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 6
3.2.1. Semantics of the Security Parameter Index (SPI) . . . 7 3.2.1. Semantics of the Security Parameter Index (SPI) . . . 7
3.3. Security Association Establishment and Maintenance . . . . 7 3.3. Security Association Establishment and Maintenance . . . . 7
3.3.1. ESP Security Associations . . . . . . . . . . . . . . 7 3.3.1. ESP Security Associations . . . . . . . . . . . . . . 8
3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.3. Security Association Management . . . . . . . . . . . 9 3.3.3. Security Association Management . . . . . . . . . . . 9
3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 9 3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 9
3.3.5. Supported Transforms . . . . . . . . . . . . . . . . . 9 3.3.5. Supported Transforms . . . . . . . . . . . . . . . . . 9
3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 9 3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 10
3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 10 3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 10
4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Setting up an ESP Security Association . . . . . . . . 11 4.1.1. Setting up an ESP Security Association . . . . . . . . 11
4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 12 4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 12
5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 13 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 13
5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 13 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14 5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14
5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 15 5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 15
5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 16 5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 16
5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 16 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 16
5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 17 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 17 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 18
5.3.2. Responding to the Rekeying Initialization . . . . . . 18 5.3.2. Responding to the Rekeying Initialization . . . . . . 18
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 18 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 19
5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 18 5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 19 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Processing Outgoing Application Data . . . . . . . . . . . 19 6.1. Processing Outgoing Application Data . . . . . . . . . . . 20
6.2. Processing Incoming Application Data . . . . . . . . . . . 19 6.2. Processing Incoming Application Data . . . . . . . . . . . 20
6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 20 6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 21
6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 20 6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 21
6.5. Processing Incoming Initialization Reply (I2) . . . . . . 21 6.5. Processing Incoming Initialization Reply (I2) . . . . . . 22
6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 21 6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 22
6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 21 6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 22
6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 21 6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 22
6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 23 6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 24
6.9.1. Processing UPDATE Packet: No Outstanding Rekeying 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying
Request . . . . . . . . . . . . . . . . . . . . . . . 23 Request . . . . . . . . . . . . . . . . . . . . . . . 24
6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 24 6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25
6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 25 6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26
7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 26 7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative references . . . . . . . . . . . . . . . . . . . 29 10.1. Normative references . . . . . . . . . . . . . . . . . . . 30
10.2. Informative references . . . . . . . . . . . . . . . . . . 29 10.2. Informative references . . . . . . . . . . . . . . . . . . 30
Appendix A. A Note on Implementation Options . . . . . . . . . . 30 Appendix A. A Note on Implementation Options . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33
1. Introduction 1. Introduction
In the Host Identity Protocol Architecture [7], hosts are identified In the Host Identity Protocol Architecture [7], hosts are identified
with public keys. The Host Identity Protocol [5] base exchange with public keys. The Host Identity Protocol [5] base exchange
allows any two HIP-supporting hosts to authenticate each other and to allows any two HIP-supporting hosts to authenticate each other and to
create a HIP association between themselves. During the base create a HIP association between themselves. During the base
exchange, the hosts generate a piece of shared keying material using exchange, the hosts generate a piece of shared keying material using
an authenticated Diffie-Hellman exchange. an authenticated Diffie-Hellman exchange.
skipping to change at page 6, line 40 skipping to change at page 6, line 40
The HIP ESP packet looks exactly the same as the IPsec ESP transport The HIP ESP packet looks exactly the same as the IPsec ESP transport
format packet. The semantics, however, are a bit different and are format packet. The semantics, however, are a bit different and are
described in more detail in the next subsection. described in more detail in the next subsection.
3.2. Conceptual ESP Packet Processing 3.2. Conceptual ESP Packet Processing
ESP packet processing can be implemented in different ways in HIP. ESP packet processing can be implemented in different ways in HIP.
It is possible to implement it in a way that a standards compliant, It is possible to implement it in a way that a standards compliant,
unmodified IPsec implementation [4] can be used. unmodified IPsec implementation [4] can be used.
When a standards compliant IPsec implementation is used, the packet When a standards compliant IPsec implementation that uses IP
processing may take the following steps: For outgoing packets, the addresses in the SPD and SAD is used, the packet processing may take
the following steps. For outgoing packets, assuming that the upper
layer pseudoheader has been built using IP addresses, the
implementation recalculates upper layer checksums using HITs and, implementation recalculates upper layer checksums using HITs and,
after that, changes the packet source and destination addresses to after that, changes the packet source and destination addresses back
corresponding IP addresses. The packet is sent to the IPsec ESP for to corresponding IP addresses. The packet is sent to the IPsec ESP
transport mode handling and from there the encrypted packet is sent for transport mode handling and from there the encrypted packet is
to the network. When an ESP packet is received, the packet is first sent to the network. When an ESP packet is received, the packet is
put to the IPsec ESP transport mode handling, and after decryption, first put to the IPsec ESP transport mode handling, and after
the source and destination IP addresses are replaced with HITs and decryption, the source and destination IP addresses are replaced with
finally, upper layer checksums are recalculated. HITs and finally, upper layer checksums are verified before passing
the packet to the upper layer.
An alternative way to implement the packet processing is the BEET An alternative way to implement the packet processing is the BEET
(Bound End-to-End Tunnel) [11] mode. In BEET mode, the ESP packet is (Bound End-to-End Tunnel) [11] mode. In BEET mode, the ESP packet is
formatted as a transport mode packet, but the semantics of the formatted as a transport mode packet, but the semantics of the
connection are the same as for tunnel mode. The "outer" addresses of connection are the same as for tunnel mode. The "outer" addresses of
the packet are the IP addresses and the "inner" addresses are the the packet are the IP addresses and the "inner" addresses are the
HITs. For outgoing traffic, after the packet has been encrypted, the HITs. For outgoing traffic, after the packet has been encrypted, the
packet's IP header is changed to a new one, containing IP addresses packet's IP header is changed to a new one, containing IP addresses
instead of HITs and the packet is sent to the network. When ESP instead of HITs and the packet is sent to the network. When ESP
packet is received, the SPI value, together with the integrity packet is received, the SPI value, together with the integrity
skipping to change at page 8, line 10 skipping to change at page 8, line 15
3.3.1. ESP Security Associations 3.3.1. ESP Security Associations
In HIP, ESP Security Associations are setup between the HIP nodes In HIP, ESP Security Associations are setup between the HIP nodes
during the base exchange [5]. Existing ESP SAs can be updated later during the base exchange [5]. Existing ESP SAs can be updated later
using UPDATE messages. The reason for updating the ESP SA later can using UPDATE messages. The reason for updating the ESP SA later can
be e.g. need for rekeying the SA because of sequence number rollover. be e.g. need for rekeying the SA because of sequence number rollover.
Upon setting up a HIP association, each association is linked to two Upon setting up a HIP association, each association is linked to two
ESP SAs, one for incoming packets and one for outgoing packets. The ESP SAs, one for incoming packets and one for outgoing packets. The
Initiator's incoming SA corresponds with the Responder's outgoing Initiator's incoming SA corresponds with the Responder's outgoing
one, and vice versa. The Initiator defines the SPI for the former one, and vice versa. The Initiator defines the SPI for its incoming
association, as defined in Section 3.2.1. This SA is called SA-RI, association, as defined in Section 3.2.1. This SA is herein called
and the corresponding SPI is called SPI-RI. Respectively, the SA-RI, and the corresponding SPI is called SPI-RI. Respectively, the
Responder's incoming SA corresponds with the Initiator's outgoing SA Responder's incoming SA corresponds with the Initiator's outgoing SA
and is called SA-IR, with the SPI being called SPI-IR. and is called SA-IR, with the SPI being called SPI-IR.
The Initiator creates SA-RI as a part of R1 processing, before The Initiator creates SA-RI as a part of R1 processing, before
sending out the I2, as explained in Section 6.4. The keys are sending out the I2, as explained in Section 6.4. The keys are
derived from KEYMAT, as defined in Section 7. The Responder creates derived from KEYMAT, as defined in Section 7. The Responder creates
SA-RI as a part of I2 processing, see Section 6.5. SA-RI as a part of I2 processing, see Section 6.5.
The Responder creates SA-IR as a part of I2 processing, before The Responder creates SA-IR as a part of I2 processing, before
sending out R2; see Section 6.5. The Initiator creates SA-IR when sending out R2; see Section 6.5. The Initiator creates SA-IR when
skipping to change at page 9, line 16 skipping to change at page 9, line 20
for the new outgoing SA, SPI-R'I', is specified in the received for the new outgoing SA, SPI-R'I', is specified in the received
ESP_INFO parameter in the UPDATE packet. For the new incoming SA, R' ESP_INFO parameter in the UPDATE packet. For the new incoming SA, R'
generates the new SPI value, SPI-I'R', and includes it in the generates the new SPI value, SPI-I'R', and includes it in the
response UPDATE packet. response UPDATE packet.
When I' receives a response UPDATE from R', it generates new SAs, as When I' receives a response UPDATE from R', it generates new SAs, as
described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the
new outgoing SA immediately. new outgoing SA immediately.
R' starts using the new outgoing SA when it receives traffic on the R' starts using the new outgoing SA when it receives traffic on the
new incoming SA. After this, R' can remove the old SAs. Similarly, new incoming SA or when it receives the UPDATE ACK confirming
when the I' receives traffic from the new incoming SA, it can safely completion of rekeying. After this, R' can remove the old SAs.
remove the old SAs. Similarly, when the I' receives traffic from the new incoming SA, it
can safely remove the old SAs.
3.3.3. Security Association Management 3.3.3. Security Association Management
An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote
HITs since a system can have more than one HIT). An inactivity timer HITs since a system can have more than one HIT). An inactivity timer
is RECOMMENDED for all SAs. If the state dictates the deletion of an is RECOMMENDED for all SAs. If the state dictates the deletion of an
SA, a timer is set to allow for any late arriving packets. SA, a timer is set to allow for any late arriving packets.
3.3.4. Security Parameter Index (SPI) 3.3.4. Security Parameter Index (SPI)
skipping to change at page 17, line 41 skipping to change at page 17, line 41
The HIP parameters for the R2 packet: The HIP parameters for the R2 packet:
IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) ) IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) )
5.3. HIP ESP Rekeying 5.3. HIP ESP Rekeying
In this section, the procedure for rekeying an existing ESP SA is In this section, the procedure for rekeying an existing ESP SA is
presented. presented.
Conceptually, the process can be represented by the following message
sequence using the host names I' and R' defined in Section 3.3.2.
For simplicity, HMAC and HIP_SIGNATURE are not depicted, and
DIFFIE_HELLMAN keys are optional. The UPDATE with ACK_I need not be
piggybacked with the UPDATE with SEQ_R; it may be acked separately
(in which case the sequence would include four packets).
I' R'
UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN])
<-----------------------------------
UPDATE(ACK_R)
----------------------------------->
Below, the first two packets in this figure are explained.
5.3.1. Initializing Rekeying 5.3.1. Initializing Rekeying
When HIP is used with ESP, the UPDATE packet is used to initiate When HIP is used with ESP, the UPDATE packet is used to initiate
rekeying. The UPDATE packet MUST carry an ESP_INFO and MAY carry a rekeying. The UPDATE packet MUST carry an ESP_INFO and MAY carry a
DIFFIE_HELLMAN parameter. DIFFIE_HELLMAN parameter.
Intermediate systems that use the SPI will have to inspect HIP Intermediate systems that use the SPI will have to inspect HIP
packets for those that carry rekeying information. The packet is packets for those that carry rekeying information. The packet is
signed for the benefit of the intermediate systems. Since signed for the benefit of the intermediate systems. Since
intermediate systems may need the new SPI values, the contents cannot intermediate systems may need the new SPI values, the contents cannot
skipping to change at page 22, line 43 skipping to change at page 23, line 43
parameter. In addition, the host may include the optional parameter. In addition, the host may include the optional
DIFFIE_HELLMAN parameter. If the UDPATE contains the DIFFIE_HELLMAN parameter. If the UDPATE contains the
DIFFIE_HELLMAN parameter, the Keymat Index in the ESP_INFO DIFFIE_HELLMAN parameter, the Keymat Index in the ESP_INFO
parameter MUST be zero, and the Diffie-Hellman group ID must be parameter MUST be zero, and the Diffie-Hellman group ID must be
unchanged from that used in the initial handshake. If the UPDATE unchanged from that used in the initial handshake. If the UPDATE
does not contain DIFFIE_HELLMAN, the ESP_INFO Keymat Index MUST does not contain DIFFIE_HELLMAN, the ESP_INFO Keymat Index MUST
be greater or equal to the index of the next byte to be drawn be greater or equal to the index of the next byte to be drawn
from the current KEYMAT. from the current KEYMAT.
3. The system sends the UPDATE packet. For reliability, the 3. The system sends the UPDATE packet. For reliability, the
underlying UPDATE retransmission mechanism SHOULD be used. underlying UPDATE retransmission mechanism MUST be used.
4. The system MUST NOT delete its existing SAs, but continue using 4. The system MUST NOT delete its existing SAs, but continue using
them if its policy still allows. The rekeying procedure SHOULD them if its policy still allows. The rekeying procedure SHOULD
be initiated early enough to make sure that the SA replay be initiated early enough to make sure that the SA replay
counters do not overflow. counters do not overflow.
5. In case a protocol error occurs and the peer system acknowledges 5. In case a protocol error occurs and the peer system acknowledges
the UPDATE but does not itself send an ESP_INFO, the system may the UPDATE but does not itself send an ESP_INFO, the system may
not finalize the outstanding ESP SA update request. To guard not finalize the outstanding ESP SA update request. To guard
against this, a system MAY re-initiate the ESP SA update against this, a system MAY re-initiate the ESP SA update
skipping to change at page 23, line 18 skipping to change at page 24, line 18
implementation-dependent time. The system MUST NOT keep an implementation-dependent time. The system MUST NOT keep an
oustanding ESP SA update request for an indefinite time. oustanding ESP SA update request for an indefinite time.
To simplify the state machine, a host MUST NOT generate new UPDATEs To simplify the state machine, a host MUST NOT generate new UPDATEs
while it has an outstanding ESP SA update request, unless it is while it has an outstanding ESP SA update request, unless it is
restarting the update process. restarting the update process.
6.9. Processing Incoming UPDATE Packets 6.9. Processing Incoming UPDATE Packets
When a system receives an UPDATE packet, it must be processed if the When a system receives an UPDATE packet, it must be processed if the
following conditions hold: following conditions hold (in addition to the generic conditions
specified for UPDATE processing in Section 6.12 of [5]):
1. A corresponding HIP association must exist. This is usually 1. A corresponding HIP association must exist. This is usually
ensured by the underlying UPDATE mechanism. ensured by the underlying UPDATE mechanism.
2. The state of the HIP association is ESTABLISHED or R2-SENT. 2. The state of the HIP association is ESTABLISHED or R2-SENT.
If the above conditions hold, the following steps define the If the above conditions hold, the following steps define the
conceptual processing rules for handling the received UPDATE packet: conceptual processing rules for handling the received UPDATE packet:
1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the 1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the
skipping to change at page 24, line 5 skipping to change at page 25, line 6
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
handling a received UPDATE packet with ESP_INFO parameter: handling a received UPDATE packet with ESP_INFO parameter:
1. The system consults its policy to see if it needs to generate a 1. The system consults its policy to see if it needs to generate a
new Diffie-Hellman key, and generates a new key (with same Group new Diffie-Hellman key, and generates a new key (with same Group
ID) if needed. The system records any newly generated or ID) if needed. The system records any newly generated or
received Diffie-Hellman keys, for use in KEYMAT generation upon received Diffie-Hellman keys, for use in KEYMAT generation upon
finalizing the ESP SA update. finalizing the ESP SA update.
2. If the system generated new Diffie-Hellman key in the previous 2. If the system generated a new Diffie-Hellman key in the previous
step, or it received a DIFFIE_HELLMAN parameter, it sets ESP_INFO step, or if it received a DIFFIE_HELLMAN parameter, it sets
Keymat Index to zero. Otherwise, the ESP_INFO Keymat Index MUST ESP_INFO Keymat Index to zero. Otherwise, the ESP_INFO Keymat
be greater or equal to the index of the next byte to be drawn Index MUST be greater or equal to the index of the next byte to
from the current KEYMAT. In this case, it is RECOMMENDED that be drawn from the current KEYMAT. In this case, it is
the host use the Keymat Index requested by the peer in the RECOMMENDED that the host use the Keymat Index requested by the
received ESP_INFO. peer in the received ESP_INFO.
3. The system creates an UPDATE packet, which contains an ESP_INFO 3. The system creates an UPDATE packet, which contains an ESP_INFO
parameter, and the optional DIFFIE_HELLMAN parameter. parameter, and the optional DIFFIE_HELLMAN parameter. This
UPDATE would also typically acknowledge the peer's UPDATE with an
ACK parameter, although a separate UPDATE ACK may be sent.
4. The system sends the UPDATE packet and stores any received 4. The system sends the UPDATE packet and stores any received
ESP_INFO, and DIFFIE_HELLMAN parameters. At this point, it only ESP_INFO, and DIFFIE_HELLMAN parameters. At this point, it only
needs to receive an acknowledgement for the sent UPDATE to finish needs to receive an acknowledgement for the newly sent UPDATE to
ESP SA update. In the usual case, the acknowledgement is handled finish ESP SA update. In the usual case, the acknowledgement is
by the underlying UPDATE mechanism. handled by the underlying UPDATE mechanism.
6.10. Finalizing Rekeying 6.10. Finalizing Rekeying
A system finalizes rekeying when it has both received the A system finalizes rekeying when it has both received the
corresponding UPDATE acknowledgement packet from the peer and it has corresponding UPDATE acknowledgement packet from the peer and it has
successfully received the peer's UPDATE. The following steps are successfully received the peer's UPDATE. The following steps are
taken: taken:
1. If the received UPDATE messages contains a new Diffie-Hellman 1. If the received UPDATE messages contains a new Diffie-Hellman
key, the system has a new Diffie-Hellman key from initiating ESP key, the system has a new Diffie-Hellman key due to initiating
SA update, or both, the system generates new KEYMAT. If there is ESP SA update, or both, the system generates new KEYMAT. If
only one new Diffie-Hellman key, the old existing key is used as there is only one new Diffie-Hellman key, the old existing key is
the other key. used as the other key.
2. If the system generated new KEYMAT in the previous step, it sets 2. If the system generated new KEYMAT in the previous step, it sets
Keymat Index to zero, independent on whether the received UPDATE Keymat Index to zero, independent of whether the received UPDATE
included a Diffie-Hellman key or not. If the system did not included a Diffie-Hellman key or not. If the system did not
generate new KEYMAT, it uses the greater Keymat Index of the two generate new KEYMAT, it uses the greater Keymat Index of the two
(sent and received) ESP_INFO parameters. (sent and received) ESP_INFO parameters.
3. The system draws keys for new incoming and outgoing ESP SAs, 3. The system draws keys for new incoming and outgoing ESP SAs,
starting from the Keymat Index, and prepares new incoming and starting from the Keymat Index, and prepares new incoming and
outgoing ESP SAs. The SPI for the outgoing SA is the new SPI outgoing ESP SAs. The SPI for the outgoing SA is the new SPI
value received in an ESP_INFO parameter. The SPI for the value received in an ESP_INFO parameter. The SPI for the
incoming SA was generated when the ESP_INFO was sent to the peer. incoming SA was generated when the ESP_INFO was sent to the peer.
The order of the keys retrieved from the KEYMAT during rekeying The order of the keys retrieved from the KEYMAT during rekeying
process is similar to that described in Section 7. Note, that process is similar to that described in Section 7. Note, that
only IPsec ESP keys are retrieved during rekeying process, not only IPsec ESP keys are retrieved during rekeying process, not
the HIP keys. the HIP keys.
4. The system cancels any timers protecting the UPDATE. 4. The system starts to send to the new outgoing SA and prepares to
start receiving data on the new incoming SA. Once the system
5. The system starts to send to the new outgoing SA and prepares to receives data on the new incoming SA it may safely delete the old
start receiving data on the new incoming SA. SAs.
6.11. Processing NOTIFY Packets 6.11. Processing NOTIFY Packets
The processing of NOTIFY packets is described in the HIP base The processing of NOTIFY packets is described in the HIP base
specification. specification.
7. Keying Material 7. Keying Material
The keying material is generated as described in the HIP base The keying material is generated as described in the HIP base
specification. During the base exchange, the initial keys are drawn specification. During the base exchange, the initial keys are drawn
skipping to change at page 29, line 21 skipping to change at page 30, line 21
[2] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP [2] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
and AH", RFC 2404, November 1998. and AH", RFC 2404, November 1998.
[3] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [3] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September 2003. Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[4] Kent, S., "IP Encapsulating Security Payload (ESP)", [4] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005. draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005.
[5] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 [5] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-04
(work in progress), June 2005. (work in progress), October 2005.
[6] Schiller, J., "Cryptographic Algorithms for use in the Internet [6] Schiller, J., "Cryptographic Algorithms for use in the Internet
Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05 Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05
(work in progress), April 2004. (work in progress), April 2004.
[7] Moskowitz, R. and P. Nikander, "Host Identity Protocol [7] Moskowitz, R. and P. Nikander, "Host Identity Protocol
Architecture", draft-ietf-hip-arch-03 (work in progress), Architecture", draft-ietf-hip-arch-03 (work in progress),
August 2005. August 2005.
[8] Schneier, B., "Applied Cryptography Second Edition: protocols [8] Schneier, B., "Applied Cryptography Second Edition: protocols
skipping to change at page 29, line 44 skipping to change at page 30, line 44
10.2. Informative references 10.2. Informative references
[9] Kent, S. and K. Seo, "Security Architecture for the Internet [9] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress),
April 2005. April 2005.
[10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[11] Nikander, P., "A Bound End-to-End Tunnel (BEET) mode for ESP", [11] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET)
draft-nikander-esp-beet-mode-03 (work in progress), June 2005. mode for ESP", draft-nikander-esp-beet-mode-04 (work in
progress), November 2005.
[12] Nikander, P., "End-Host Mobility and Multihoming with the Host [12] Nikander, P., "End-Host Mobility and Multihoming with the Host
Identity Protocol", draft-ietf-hip-mm-02 (work in progress), Identity Protocol", draft-ietf-hip-mm-02 (work in progress),
July 2005. July 2005.
Appendix A. A Note on Implementation Options Appendix A. A Note on Implementation Options
It is possible to implement this specification in multiple different It is possible to implement this specification in multiple different
ways. As noted above, one possible way of implementing is to rewrite ways. As noted above, one possible way of implementing is to rewrite
IP headers below IPsec. In such an implementation, IPsec is used as IP headers below IPsec. In such an implementation, IPsec is used as
skipping to change at page 32, line 41 skipping to change at page 33, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 26 change blocks. 
74 lines changed or deleted 100 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/