draft-ietf-hip-rfc5201-bis-08.txt   draft-ietf-hip-rfc5201-bis-09.txt 
Network Working Group R. Moskowitz, Ed. Network Working Group R. Moskowitz, Ed.
Internet-Draft Verizon Internet-Draft Verizon
Obsoletes: 5201 (if approved) T. Heer Obsoletes: 5201 (if approved) T. Heer
Intended status: Standards Track RWTH Aachen University, Intended status: Standards Track RWTH Aachen University,
Expires: September 13, 2012 Communication and Distributed Expires: January 17, 2013 Communication and Distributed
Systems Group Systems Group
P. Jokela P. Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
The Boeing Company The Boeing Company
March 12, 2012 July 16, 2012
Host Identity Protocol Version 2 (HIPv2) Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-08 draft-ietf-hip-rfc5201-bis-09
Abstract Abstract
This document specifies the details of the Host Identity Protocol This document specifies the details of the Host Identity Protocol
(HIP). HIP allows consenting hosts to securely establish and (HIP). HIP allows consenting hosts to securely establish and
maintain shared IP-layer state, allowing separation of the identifier maintain shared IP-layer state, allowing separation of the identifier
and locator roles of IP addresses, thereby enabling continuity of and locator roles of IP addresses, thereby enabling continuity of
communications across IP address changes. HIP is based on a SIGMA- communications across IP address changes. HIP is based on a SIGMA-
compliant Diffie-Hellman key exchange, using public key identifiers compliant Diffie-Hellman key exchange, using public key identifiers
from a new Host Identity namespace for mutual peer authentication. from a new Host Identity namespace for mutual peer authentication.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 13, 2012. This Internet-Draft will expire on January 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 20 skipping to change at page 5, line 20
11.4. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 109 11.4. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 109
11.5. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 110 11.5. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 110
11.6. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 111 11.6. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 111
11.7. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 111 11.7. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 111
11.8. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 113 11.8. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 113
11.9. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 113 11.9. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 113
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
12.1. Normative References . . . . . . . . . . . . . . . . . . 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 113
12.2. Informative References . . . . . . . . . . . . . . . . . 116 12.2. Informative References . . . . . . . . . . . . . . . . . 116
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 118 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 118
Appendix B. Generating a Public Key Encoding from an HI . . . . 119 Appendix B. Generating a Public Key Encoding from an HI . . . . 120
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 120 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 120
C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 121 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 121
C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 121 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 121
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 121 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 121
Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 122 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 122
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 122 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 122
1. Introduction 1. Introduction
This document specifies the details of the Host Identity Protocol This document specifies the details of the Host Identity Protocol
skipping to change at page 10, line 32 skipping to change at page 10, line 32
In this section, the properties of the Host Identity and Host In this section, the properties of the Host Identity and Host
Identity Tag are discussed, and the exact format for them is defined. Identity Tag are discussed, and the exact format for them is defined.
In HIP, the public key of an asymmetric key pair is used as the Host In HIP, the public key of an asymmetric key pair is used as the Host
Identity (HI). Correspondingly, the host itself is defined as the Identity (HI). Correspondingly, the host itself is defined as the
entity that holds the private key of the key pair. See the HIP entity that holds the private key of the key pair. See the HIP
architecture specification [I-D.ietf-hip-rfc4423-bis] for more architecture specification [I-D.ietf-hip-rfc4423-bis] for more
details on the difference between an identity and the corresponding details on the difference between an identity and the corresponding
identifier. identifier.
HIP implementations MUST support the Rivest Shamir Adelman (RSA) HIP implementations MUST support the Rivest Shamir Adelman (RSA)
[RFC3110] public key algorithm, and SHOULD support the Digital [RFC3110] public key algorithm and the Elliptic Curve Digital
Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve Signature Algorithm (ECDSA) for generating the HI as defined in
Digital Signature Algorithm (ECDSA) for generating the HI as defined Section 5.2.9. Additional algorithms MAY be supported.
in Section 5.2.9. Additional algorithms MAY be supported.
A hashed encoding of the HI, the Host Identity Tag (HIT), is used in A hashed encoding of the HI, the Host Identity Tag (HIT), is used in
protocols to represent the Host Identity. The HIT is 128 bits long protocols to represent the Host Identity. The HIT is 128 bits long
and has the following three key properties: i) it is the same length and has the following three key properties: i) it is the same length
as an IPv6 address and can be used in fixed address-sized fields in as an IPv6 address and can be used in fixed address-sized fields in
APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it
is computationally hard to find a Host Identity key that matches the is computationally hard to find a Host Identity key that matches the
HIT), and iii) the probability of a HIT collision between two hosts HIT), and iii) the probability of a HIT collision between two hosts
is very low, hence, it is infeasible for an attacker to find a is very low, hence, it is infeasible for an attacker to find a
collision with a HIT that is in use. For details on the security collision with a HIT that is in use. For details on the security
skipping to change at page 32, line 38 skipping to change at page 32, line 38
| | | | | |
| | If fail, stay at CLOSING | | | If fail, stay at CLOSING |
| | | | | |
| Receive CLOSE_ACK, | If successful, discard state and go to | | Receive CLOSE_ACK, | If successful, discard state and go to |
| process | UNASSOCIATED | | process | UNASSOCIATED |
| | | | | |
| | If fail, stay at CLOSING | | | If fail, stay at CLOSING |
| | | | | |
| Receive ANYOTHER | Drop and stay at CLOSING | | Receive ANYOTHER | Drop and stay at CLOSING |
| | | | | |
| Timeout | Increment timeout sum and reset timer. If | | Timeout | Increment timeout sum and reset timer. If |
| | timeout sum is less than UAL+MSL minutes, | | | timeout sum is less than UAL+MSL minutes, |
| | retransmit CLOSE and stay at CLOSING | | | retransmit CLOSE and stay at CLOSING |
| | | | | |
| | If timeout sum is greater than UAL+MSL | | | If timeout sum is greater than UAL+MSL |
| | minutes, go to UNASSOCIATED | | | minutes, go to UNASSOCIATED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 7: CLOSING - HIP association has not been used for UAL minutes Table 7: CLOSING - HIP association has not been used for UAL minutes
System behavior in state CLOSED, Table 8. System behavior in state CLOSED, Table 8.
skipping to change at page 33, line 47 skipping to change at page 33, line 47
| Timeout (UAL+2MSL) | Discard state, and go to UNASSOCIATED | | Timeout (UAL+2MSL) | Discard state, and go to UNASSOCIATED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary
System behavior in state E-FAILED, Table 9. System behavior in state E-FAILED, Table 9.
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
| Trigger | Action | | Trigger | Action |
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
| Wait for | Go to UNASSOCIATED. Re-negotiation is | | Wait for | Go to UNASSOCIATED. Re-negotiation is |
| implementation-specific | possible after moving to UNASSOCIATED | | implementation-specific | possible after moving to UNASSOCIATED |
| time | state. | | time | state. |
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
Table 9: E-FAILED - HIP failed to establish association with peer Table 9: E-FAILED - HIP failed to establish association with peer
4.4.4. Simplified HIP State Diagram 4.4.4. Simplified HIP State Diagram
The following diagram (Figure 2) shows the major state transitions. The following diagram (Figure 2) shows the major state transitions.
Transitions based on received packets implicitly assume that the Transitions based on received packets implicitly assume that the
packets are successfully authenticated or processed. packets are successfully authenticated or processed.
skipping to change at page 42, line 27 skipping to change at page 42, line 27
| | | numbers | | | | | numbers | |
| | | | | | | | | |
| HIP_MAC | 61505 | variable | HMAC-based message | | HIP_MAC | 61505 | variable | HMAC-based message |
| | | | authentication code, | | | | | authentication code, |
| | | | with key material | | | | | with key material |
| | | | from KEYMAT | | | | | from KEYMAT |
| | | | | | | | | |
| HIP_MAC_2 | 61569 | variable | HMAC based message | | HIP_MAC_2 | 61569 | variable | HMAC based message |
| | | | authentication code, | | | | | authentication code, |
| | | | with key material | | | | | with key material |
| | | | from KEYMAT. Unlike | | | | | from KEYMAT. Unlike |
| | | | HIP_MAC, the HOST_ID | | | | | HIP_MAC, the HOST_ID |
| | | | parameter is | | | | | parameter is |
| | | | included in | | | | | included in |
| | | | HIP_MAC_2 | | | | | HIP_MAC_2 |
| | | | calculation. | | | | | calculation. |
| | | | | | | | | |
| HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 |
| | | | packet | | | | | packet |
| | | | | | | | | |
| HIP_SIGNATURE | 61697 | variable | Signature of the | | HIP_SIGNATURE | 61697 | variable | Signature of the |
skipping to change at page 43, line 22 skipping to change at page 43, line 22
| | | | | |
| 1024 - 2047 | Reserved | | 1024 - 2047 | Reserved |
| | | | | |
| 2048 - 4095 | Parameters related to HIP transport formats | | 2048 - 4095 | Parameters related to HIP transport formats |
| | | | | |
| 4096 - 8191 | Signed parameters allocated through specification | | 4096 - 8191 | Signed parameters allocated through specification |
| | documents | | | documents |
| | | | | |
| 8192 - 32767 | Reserved | | 8192 - 32767 | Reserved |
| | | | | |
| 32768 - 49151 | Free for experimentation. Signed parameters. | | 32768 - 49151 | Free for experimentation. Signed parameters. |
| | | | | |
| 41952 - 61439 | Reserved | | 41952 - 61439 | Reserved |
| | | | | |
| 61440 - 64443 | Signatures and (signed) MACs | | 61440 - 64443 | Signatures and (signed) MACs |
| | | | | |
| 62464 - 63487 | Parameters that are neither signed nor MACed | | 62464 - 63487 | Parameters that are neither signed nor MACed |
| | | | | |
| 63488 - 64511 | Rendezvous and relaying | | 63488 - 64511 | Rendezvous and relaying |
| | | | | |
| 64512 - 65023 | Parameters that are neither signed nor MACed | | 64512 - 65023 | Parameters that are neither signed nor MACed |
skipping to change at page 50, line 43 skipping to change at page 50, line 43
1536-bit MODP group [RFC3526] HKDF [RFC5869] 3 1536-bit MODP group [RFC3526] HKDF [RFC5869] 3
3072-bit MODP group [RFC3526] HKDF [RFC5869] 4 3072-bit MODP group [RFC3526] HKDF [RFC5869] 4
DEPRECATED 5 DEPRECATED 5
DEPRECATED 6 DEPRECATED 6
NIST P-256 [RFC5903] HKDF [RFC5869] 7 NIST P-256 [RFC5903] HKDF [RFC5869] 7
NIST P-384 [RFC5903] HKDF [RFC5869] 8 NIST P-384 [RFC5903] HKDF [RFC5869] 8
NIST P-521 [RFC5903] HKDF [RFC5869] 9 NIST P-521 [RFC5903] HKDF [RFC5869] 9
SECP160R1 [SECG] HKDF [RFC5869] 10 SECP160R1 [SECG] HKDF [RFC5869] 10
The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH
groups 8 - 10 are defined in [RFC5903] and [RFC6090]. ECDH group 7 groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH group 10
is covered in Appendix D. is covered in Appendix D. Any ECDH used with HIP MUST have a co-
factor of 1.
The Group ID also defines the key derivation function that is to be The Group ID also defines the key derivation function that is to be
used for deriving the symmstric keys for the HMAC and symmetric used for deriving the symmstric keys for the HMAC and symmetric
encryption from the keying material from the Diffie Hellman key encryption from the keying material from the Diffie Hellman key
exchange (see Section 6.5). exchange (see Section 6.5).
A HIP implementation MUST implement Group ID 3. The 160-bit A HIP implementation MUST implement Group ID 3. The 160-bit
SECP160R1 group can be used when lower security is enough (e.g., web SECP160R1 group can be used when lower security is enough (e.g., web
surfing) and when the equipment is not powerful enough (e.g., some surfing) and when the equipment is not powerful enough (e.g., some
PDAs). Implementations SHOULD implement Group IDs 4 and 8. PDAs). Implementations SHOULD implement Group IDs 4 and 8.
skipping to change at page 51, line 36 skipping to change at page 51, line 37
Cipher ID defines the cipher algorithm to be used for Cipher ID defines the cipher algorithm to be used for
encrypting the contents of the ENCRYPTED parameter encrypting the contents of the ENCRYPTED parameter
The following Cipher IDs are defined: The following Cipher IDs are defined:
Suite ID Value Suite ID Value
RESERVED 0 RESERVED 0
NULL-ENCRYPT 1 ([RFC2410]) NULL-ENCRYPT 1 ([RFC2410])
AES-128-CBC 2 ([RFC3602]) AES-128-CBC 2 ([RFC3602])
3DES-CBC 3 ([RFC2451]) DEPRECATED 3
AES-256-CBC 4 ([RFC3602]) AES-256-CBC 4 ([RFC3602])
The sender of a HIP_CIPHER parameter MUST make sure that there are no The sender of a HIP_CIPHER parameter MUST make sure that there are no
more than six (6) Cipher IDs in one HIP_CIPHER parameter. more than six (6) Cipher IDs in one HIP_CIPHER parameter.
Conversely, a recipient MUST be prepared to handle received transport Conversely, a recipient MUST be prepared to handle received transport
parameters that contain more than six Cipher IDs by accepting the parameters that contain more than six Cipher IDs by accepting the
first six Cipher IDs and dropping the rest. The limited number of first six Cipher IDs and dropping the rest. The limited number of
transforms sets the maximum size of the HIP_CIPHER parameter. As the transforms sets the maximum size of the HIP_CIPHER parameter. As the
default configuration, the HIP_CIPHER parameter MUST contain at least default configuration, the HIP_CIPHER parameter MUST contain at least
one of the mandatory Cipher IDs. There MAY be a configuration option one of the mandatory Cipher IDs. There MAY be a configuration option
skipping to change at page 52, line 49 skipping to change at page 52, line 50
none included 0 none included 0
FQDN 1 FQDN 1
NAI 2 NAI 2
FQDN Fully Qualified Domain Name, in binary format. FQDN Fully Qualified Domain Name, in binary format.
NAI Network Access Identifier NAI Network Access Identifier
The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1.
The format for the NAI is defined in [RFC4282] The format for the NAI is defined in [RFC4282]
If there is no Domain Identifier, i.e., the DI-type field is zero, A host MAY optionally associate the Host Identity with a single
the DI Length field is set to zero as well. Domain Identifier in the HOST_ID parameter. If there is no Domain
Identifier, i.e., the DI-type field is zero, the DI Length field is
set to zero as well.
The following HI Algorithms have been defined: The following HI Algorithms have been defined:
Algorithm Algorithm
profiles Values profiles Values
RESERVED 0 RESERVED 0
DSA 3 [RFC2536] (RECOMMENDED) DSA 3 [FIPS 186-3] (RECOMMENDED)
RSA 5 [RFC3110] (REQUIRED) RSA 5 [RFC3447] (REQUIRED)
ECDSA 7 [RFC4754] (RECOMMENDED) ECDSA 7 [RFC4754] (REQUIRED)
ECDSA_LOW 9 [SECG] (RECOMMENDED) ECDSA_LOW 9 [SECG] (RECOMMENDED)
For DSA, RSA, and ECDSA key types, profiles containing at least 112
bits of security strength (as defined by [NIST.800-131A.2011]) should
be used. For RSA signature padding, the PSS method of padding
[RFC3447] MUST be used.
The Host Identity is derived from the DNSKEY format for RSA and DSA. The Host Identity is derived from the DNSKEY format for RSA and DSA.
For these, the Public Key field of the RDATA part from RFC 4034 For these, the Public Key field of the RDATA part from RFC 4034
[RFC4034] is used. For ECC we distinguish two different profiles: [RFC4034] is used. For ECC we distinguish two different profiles:
ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and
defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with
low computational capabilities and uses shorter curves from SECG low computational capabilities and uses shorter curves from SECG
[SECG]. [SECG]. Any ECDSA used with HIP MUST have a co-factor of 1.
For ECDSA and ECDSA_LOW Host Identities are represented by the For ECDSA and ECDSA_LOW Host Identities are represented by the
following fields: following fields:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECC Curve | / | ECC Curve | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Public Key | / Public Key |
skipping to change at page 71, line 23 skipping to change at page 71, line 23
enough precomputed R1 packets to supply each potential Initiator with enough precomputed R1 packets to supply each potential Initiator with
a different DH key, the Responder MAY send the same DH key to several a different DH key, the Responder MAY send the same DH key to several
Initiators, thereby creating the possibility of multiple legitimate Initiators, thereby creating the possibility of multiple legitimate
Initiators ending up using the same Responder-side public key. Initiators ending up using the same Responder-side public key.
However, as soon as the Responder knows that it will use a particular However, as soon as the Responder knows that it will use a particular
DH key, it SHOULD stop offering it. This design is aimed to allow DH key, it SHOULD stop offering it. This design is aimed to allow
resource-constrained Responders to offer services under I1 packet resource-constrained Responders to offer services under I1 packet
storms and to simultaneously make the probability of DH key re-use storms and to simultaneously make the probability of DH key re-use
both statistical and as low as possible. both statistical and as low as possible.
If a future version of this protocol is considered, we strongly If the Responder uses the same DH keypair for multiple handshakes.
recommend that these issues be studied again. Especially, the It must take care to avoid small subgroup attacks [RFC2785]. To
current design allows hosts to become potentially more vulnerable to avoid these attacks, when receiving the I2 message, the Responder
a statistical, low-probability problem during I1 packet storm attacks SHOULD validate the Initiators DH public key as described in
than what they are if no attack is taking place; whether this is [RFC2785] Section 3.1. In case the validation fails, the Responder
acceptable or not should be reconsidered in the light of any new MUST NOT generate a DH shared key and MUST silently abort the HIP
experience gained. BEX.
The HIP_CIPHER contains the encryption algorithms supported by the The HIP_CIPHER contains the encryption algorithms supported by the
Responder to encrypt the contents of the ENCRYPTED parameter, in the Responder to encrypt the contents of the ENCRYPTED parameter, in the
order of preference. All implementations MUST support AES [RFC3602]. order of preference. All implementations MUST support AES [RFC3602].
The HIT_SUITE_LIST parameter is an ordered list of the Responder's The HIT_SUITE_LIST parameter is an ordered list of the Responder's
preferred and supported HIT Suites. The list allows the Initiator to preferred and supported HIT Suites. The list allows the Initiator to
determine whether its own source HIT matches any suite supported by determine whether its own source HIT matches any suite supported by
the Responder. the Responder.
skipping to change at page 108, line 5 skipping to change at page 108, line 5
During the later stages of this document, when the editing baton was During the later stages of this document, when the editing baton was
transferred to Pekka Nikander, the input from the early implementors transferred to Pekka Nikander, the input from the early implementors
was invaluable. Without having actual implementations, this document was invaluable. Without having actual implementations, this document
would not be on the level it is now. would not be on the level it is now.
In the usual IETF fashion, a large number of people have contributed In the usual IETF fashion, a large number of people have contributed
to the actual text or ideas. The list of these people include Jeff to the actual text or ideas. The list of these people include Jeff
Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew
McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik
Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall, Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall,
and Jukka Ylitalo. Our apologies to anyone whose name is missing. Xin Gu, and Jukka Ylitalo. Our apologies to anyone whose name is
missing.
Once the HIP Working Group was founded in early 2004, a number of Once the HIP Working Group was founded in early 2004, a number of
changes were introduced through the working group process. Most changes were introduced through the working group process. Most
notably, the original document was split in two, one containing the notably, the original document was split in two, one containing the
base exchange and the other one defining how to use ESP. Some base exchange and the other one defining how to use ESP. Some
modifications to the protocol proposed by Aura, et al., [AUR03] were modifications to the protocol proposed by Aura, et al., [AUR03] were
added at a later stage. added at a later stage.
11. Changes from RFC 5201 11. Changes from RFC 5201
skipping to change at page 114, line 20 skipping to change at page 114, line 20
draft-ietf-hip-rfc4843-bis-00 (work in draft-ietf-hip-rfc4843-bis-00 (work in
progress), August 2010. progress), August 2010.
[I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P., [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P.,
and J. Melen, "Using the Encapsulating and J. Melen, "Using the Encapsulating
Security Payload (ESP) Transport Format Security Payload (ESP) Transport Format
with the Host Identity Protocol (HIP)", with the Host Identity Protocol (HIP)",
draft-ietf-hip-rfc5202-bis-00 (work in draft-ietf-hip-rfc5202-bis-00 (work in
progress), September 2010. progress), September 2010.
[NIST.800-131A.2011] National Institute of Standards and
Technology, "Transitions: Recommendation
for Transitioning the Use of
Cryptographic Algorithms and Key
Lengths", NIST 800-131A, January 2011, <h
ttp://csrc.nist.gov/publications/
nistpubs/800-131A/sp800-131A.pdf>.
[RFC0768] Postel, J., "User Datagram Protocol", [RFC0768] Postel, J., "User Datagram Protocol",
STD 6, RFC 768, August 1980. STD 6, RFC 768, August 1980.
[RFC1035] Mockapetris, P., "Domain names - [RFC1035] Mockapetris, P., "Domain names -
implementation and specification", implementation and specification",
STD 13, RFC 1035, November 1987. STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate Requirement Levels", BCP 14, to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997. RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of [RFC2404] Madson, C. and R. Glenn, "The Use of
HMAC-SHA-1-96 within ESP and AH", HMAC-SHA-1-96 within ESP and AH",
RFC 2404, November 1998. RFC 2404, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL [RFC2410] Glenn, R. and S. Kent, "The NULL
Encryption Algorithm and Its Use With Encryption Algorithm and Its Use With
IPsec", RFC 2410, November 1998. IPsec", RFC 2410, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-
Mode Cipher Algorithms", RFC 2451,
November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet [RFC2460] Deering, S. and R. Hinden, "Internet
Protocol, Version 6 (IPv6) Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the
Domain Name System (DNS)", RFC 2536, Domain Name System (DNS)", RFC 2536,
March 1999. March 1999.
[RFC2785] Zuccherato, R., "Methods for Avoiding the
"Small-Subgroup" Attacks on the Diffie-
Hellman Key Agreement Method for S/MIME",
RFC 2785, March 2000.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based [RFC2898] Kaliski, B., "PKCS #5: Password-Based
Cryptography Specification Version 2.0", Cryptography Specification Version 2.0",
RFC 2898, September 2000. RFC 2898, September 2000.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA
KEYs in the Domain Name System (DNS)", KEYs in the Domain Name System (DNS)",
RFC 3110, May 2001. RFC 3110, May 2001.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key
Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1",
RFC 3447, February 2003.
[RFC3484] Draves, R., "Default Address Selection [RFC3484] Draves, R., "Default Address Selection
for Internet Protocol version 6 (IPv6)", for Internet Protocol version 6 (IPv6)",
RFC 3484, February 2003. RFC 3484, February 2003.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular [RFC3526] Kivinen, T. and M. Kojo, "More Modular
Exponential (MODP) Diffie-Hellman groups Exponential (MODP) Diffie-Hellman groups
for Internet Key Exchange (IKE)", for Internet Key Exchange (IKE)",
RFC 3526, May 2003. RFC 3526, May 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, [RFC3602] Frankel, S., Glenn, R., and S. Kelly,
 End of changes. 21 change blocks. 
35 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/