idnits 2.17.1 draft-moskowitz-hip-00.txt: ** The Abstract section seems to be numbered -(183): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(209): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** Bad filename characters: the document name given in the document, 'draft-moskowitz-HIP-00', contains other characters than digits, lowercase letters and dash. == Mismatching filename: the document gives the document name as 'draft-moskowitz-HIP-00', but the file name used is 'draft-moskowitz-hip-00' == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 478 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([FIPS-186], [Thayer97a], [AH], [ESP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 296 has weird spacing: '... or Rnm host...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 1999) is 9113 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IKE' is mentioned on line 61, but not defined == Missing Reference: 'FIPS-180' is mentioned on line 165, but not defined == Missing Reference: 'RFC 2065' is mentioned on line 286, but not defined ** Obsolete undefined reference: RFC 2065 (Obsoleted by RFC 2535) == Unused Reference: 'FIPS-180-1' is defined on line 368, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186' ** Obsolete normative reference: RFC 2411 (ref. 'Thayer97a') (Obsoleted by RFC 6071) ** Obsolete normative reference: RFC 2407 (ref. 'DOI') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2535 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 R. Moskowitz, ICSA, Inc. 3 Internet Draft 4 Document: May 1999 6 The Host Identity Payload 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 1. Abstract 31 This memo describes the Host Identity Payload, HIP, which is 32 designed to carry a trustable host identity based on public key 33 cryptography like DSA [FIPS-186]. It can be used to provide the DSA 34 key and parameters for DSS auth [AUTH_DSS] within the IPsec 35 Encapsulating Security Payload [ESP] and the IPsec Authentication 36 Header [AH]. When used with ESP, NULL encryption is assumed except 37 as defined in [HIP_ENC]. 39 Further information on the other components necessary for ESP and AH 40 implementations is provided by [Thayer97a]. 42 2. Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in [RFC-2119]. 48 3. Introduction 50 Moskowitz 1 52 The Host Identity Payload May 1999 54 IP was never designed for a trustless environment. It lacks 55 trustable host identities that can be used in the datagrams to 56 supply various services. The Host Identity Payload or HIP is 57 designed to carry a trustable host identity based on public key 58 cryptography. It can be used to provide datagram authenticity, and 59 provide defense from certain classes of protocol attacks. 61 HIP is not a replacement for IKE [IKE]. HIP is designed to be 62 lightweight in packet, thus latency overhead. Little attempt is 63 made to gain the computational advantage of shared secret over 64 public key cryptography. Some attention has been given to packet 65 size growth caused by HIP. HIP should be used over IKE for low- 66 bandwidth protocols like MALLOC that would benefit from the packet 67 reduction or when public key cryptography becomes very cheap, 68 computationally. HIP and IKE should be viewed as a balanced pair of 69 keying systems that deliver IP authentication and optionally privacy 70 by enabling IPsec. 72 4. Background 74 With the advent of PPP, IP addresses stopped being effective host 75 identifiers. This loss of identity for IP was further degraded with 76 Private addresses, and DHCP. Additionally, even when an IP address 77 is assigned to a single host interface, there is no assurance to a 78 receiving host that a packet with a given Source IP address really 79 came from that host. 81 Finally, IP addresses are at best an interface label, not a host 82 identity. Thus some protocols exhibit strange to broken behavior on 83 multihomed hosts. 85 The goal of the Host Identity Payload or HIP is to provide for a 86 trustable host identity in every IP datagram. This identity can be 87 used to enable IPsec to provide authenticity and privacy. In fact, 88 HIP MUST be used with IPsec to bind its identity to the datagram. 89 HIP can be NAT friendly if uses ESP. There is nothing in HIP that 90 is tied to an IP address. Of course the ESP payload can have 91 imbedded IP addresses that, since authenticated, cannot be altered 92 by a NAT. 94 5. HIP format 96 0 1 2 3 97 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 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Next Header | Payload Len | Algorithm # | RESERVED | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Public Key Hash (PKH) | 102 | | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | | 106 Moskowitz 2 108 The Host Identity Payload May 1999 110 + HIP Key payload (opt) | 111 | | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | AH or ESP followed by IP payload | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 5.1. HIP Algorithm Number 118 Each HIP algorithm is assigned a number by IANA. The HIP algorithm 119 specifies the public key technology used. Since any HIP algorithm 120 can be used with IPsec, the HIP Algorithm Numbers MUST be identical 121 to corresponding algorithms in the IP Security Domain of 122 Interpretation [DOI]. These are the IPSEC Security Association 123 Attributes in section 4.5 of the DOI. 125 Note that not all of the IPSEC Security Association Attributes can 126 be used with HIP. See the HIP encryption document [HIP_ENC] for 127 producing secret keying material for ESP encryption and keyed 128 attributes. 130 5.1.1. HIP Algorithms 132 HIP-DSA (Algorithm #s 6) 134 DSA is the MANDITORY to implement algorithm for HIP. With HIP-DSA, 135 the authentication process for AH or ESP consists of a DSS signing 136 of the packet [AUTH_DSS]. The common key length for HIP-DSS is 320 137 bits, thus its Authentication Data is the same length. This is 138 compared to 96 bits for AH HMAC-SHA1-96 [HMAC-SHA-1-96]. Thus AH or 139 ESP with HIP-DSA is 40 bytes larger than with HMAC-SHA1-96. 141 5.2. Public Key Hash (PKH) 143 The Public Key Hash (PKH) functions much like the SPI does in IPsec. 144 However, instead of being an arbitrary 32-bit value that, in 145 combination with the destination IP address and security protocol 146 (AH), uniquely identifies the Security Association for a datagram, 147 the PKH identifies the public key that can validate the packet 148 authentication. The PKH may not be unique in the whole IP universe. 149 If there is more than one public key for a PHK, the PKH acts as a 150 hint for the correct public key to use. The IP source address (when 151 the source address is flagged immutable) can be used to further 152 refine the public key selection method. 154 64 bits are used for the PKH to allow for enough public keys for the 155 foreseeable future. The birthday paradox sets a bound for the 156 expectation of collisions. It is based on the square root of the 157 number of values. A 64-bit hash, then, would put the chances of a 158 collision at 50-50 with 2^32 hosts (4 billion). 160 Moskowitz 3 162 The Host Identity Payload May 1999 164 For HIP-DSA, the PKH is derived from the least significant 64 bits 165 of the SHA-1 [FIPS-180] hash of the DSA public key. 167 5.3. HIP Key Payload 169 The HIP Key Payload is primarily used to carry the public key 170 associated with the PKH. The format of the HIP Key Payload is a DNS 171 message [DNS]. The resource records will either be a NULL or a KEY 172 [DNSSEC] record. 174 NULL RR is used when the hosts have the public keys statically 175 configured, or when the receiving host can be expected to query the 176 DNS for a KEY record. The name in the RR is used as the key to the 177 storage table (required since it is possible to have duplicate PKHs) 178 or for the DNS query. If a DNS query is used to get the KEY record, 179 A SIG record is needed as well to establish the authenticity of the 180 KEY record. 182 KEY RR is used when the receiving host is not expected to have the 183 sending host�s public key, nor access to DNS. For HIP-DSA, DSA KEYS 184 [DSA_RR] are used to carry the DSA parameters along with the public 185 key. 187 The full DNS message format is used, not just a single DNS answer 188 format, as multiple RRs may be needed in some cases. 190 6. IPsec with HIP 192 6.1. Security Parameters Index (SPI) 194 The SPI for IPsec when used with HIP is assigned by IANA and is a 195 value of 2. The function of the SPI in IPsec has been subsumed by 196 the PKH. This does result in a per host-pair SPI, and a decrease of 197 policy granularity over other KMPs like IKE. 199 6.2. Sequence Number 201 The Sequence Number field is MANDATORY for the sender and provides 202 replay and clogging protection. Processing the Sequence Number is 203 OPTIONAL for the receiver. The Sequence Number is used in Replay 204 protection. 206 This unsigned 32-bit field contains a monotonically increasing 207 counter value. Since AH or ESP with HIP does not use a KMP to 208 create a SPI, the Sequence Number cannot be reset to zero with each 209 KMP negotiation. The following �coarse timer� method is to be used 210 for setting or re-setting the sequence number to an initial value. 212 Moskowitz 4 214 The Host Identity Payload May 1999 216 Each host MUST maintain a Host Peer State entry. Each is identified 217 by the peer's PKH. Until the PKH is obtained, the peer's IP address 218 MAY be used. Since there can be duplicate PKHs, the best approach 219 would be to use BOTH the IP address and the PKH. 221 The two fields in this table are: Sender Sequence Number and 222 Receiver Sequence Number. When a host is sending its first packet 223 to a host, or receives the first packet to a host, these fields are 224 set to ZERO. The first packet from a host has its Sequence Number 225 set by the following procedure. 227 AND 55555555 with the system time represented as a 32 bit 228 value. This will allow for at least 2,863,311,530 packets (in 229 the year 2036) before Sequence Number reset. This algorithm 230 ensures a large number of packets before rekeying for any start 231 date for the system 32 bit timer. 233 If the receiving peer�s Receiver Sequence Number is ZERO the 234 following check is performed on the Sequence Number. 236 The two numbers that are plus and minus N seconds from the 237 receiver�s system time represented as a 32 bit value are ANDed 238 with 55555555. If the Sequence Number is between these two 239 numbers, this packet is a valid start of state. The receiving 240 peer sets its Receiver Sequence Number to the value in the 241 packet. Otherwise it can be assumed that the receiver had 242 rebooted, and the sender had historical state with the 243 receiver. The receiver sends an authenticated ICMP Parameter 244 Problem (Type 12) packet (Pointer to the Sequence Number�s 245 first octet) to force the sender to reinitialize its Sequence 246 Number and resend the packet. 248 Note that since the systems are out of sync, the 249 receiver is also setting its Sender�s Sequence Number 250 to initial state, so the ICMP message is a start of 251 state as described above so there is no race condition 252 on constructing the HIP authenticated ICMP message. 253 The choice of AH or ESP for the ICMP message is a local 254 host decision. 256 The smaller the value of N, the harder it is to launch a replay 257 attack, the default for N is 600 seconds, or 10 minutes. This 258 value can be made much smaller, particularly if both systems 259 are using NTP. However, it should not be made so small that 260 network latency results in the appearance of a replay attack. 262 If the Sequence Number is not within the IPsec replay window, the 263 above range check is made. If the value is outside of the range, it 264 can be considered a replay attack. Otherwise the assumption is the 265 sender is restarting state, either because it rebooted, or the 266 Sequence Number had reached 2^32-1 and the Sequence Number had to be 267 reset to avoid rollover. 269 Moskowitz 5 271 The Host Identity Payload May 1999 273 If a host has not sent or received a packet for a peer host for a 274 set period of time, the Sequence Numbers are reset to ZERO. The 275 Quite Time Period is a matter of local policy. It can be set on a 276 per peer level. The recommended default value is 15 minutes. 278 Hosts have to handle Sequence Number rollover after 2^32 packets. 279 For peer initialization efficiency and to reduce the impact of 280 random clogging, the sending system MUST identify start of state by 281 including a HIP Key Payload as follows whenever the Sequence Number 282 is set based on the above time algorithm. 284 The HIP Key Payload MUST contain the sender�s public key and 285 appropriate parameter values. The format of the HIP Key 286 Payload SHOULD be that of the DNS KEY RR [RFC 2065]. With this 287 information, the receiver MUST be able to authenticate the 288 packet without any additional information. The receiver MAY 289 still perform any lookup based on the PKH that is necessary. 291 6.3. Sequence Number State Machine 293 Ioo Initiator at no packets sent, none received 294 Roo Responder at no packets sent, none received 295 It or Rt Initial packet from Host 296 Inm or Rnm host sent packet n, and received packet m 298 +---------+ 299 | Ioo,Roo | 300 +---------+ 301 | 302 | It->R 303 | 304 v +---------+ 305 +---------+ +---| Iot,Rto | 306 | Ito,Rot |<--------------+ | +---------+ 307 +---------+ | | ^ 308 | | | | R retransmits 309 | Rt->I +---------|---+ | with init seq# 310 | | | | 311 v | It->R | +---------+ 312 +---------+ | | | Ioo,Roo | 313 | Itt,Rtt |<----+ | +---------+ 314 +---------+ | ^ 315 | | | 316 | | It->R | Rm+1 -> I 317 | more packets | Forces R | I detects 318 | | to reset | seq# error 319 | | state | Sends ICMP error 320 | | | 322 Moskowitz 6 324 The Host Identity Payload May 1999 326 | | | 327 v | | 328 +---------+ I reboots +---------+ | 329 | Inm,Rnm |---------->| Ioo,Rnm |------+ 330 +---------+ +---------+ 331 | 332 | quite 333 | n minutes 334 v 335 +---------+ 336 | Ioo,Roo | 337 +---------+ 339 7. Security Considerations 341 Since the public keys in HIP will potentially be used in billions of 342 signature operations, there might be a potential to brute-strength 343 attack the public key. The maximum length public key possible, 344 weighed against packet length (length of signature) and performance, 345 should be used. 347 7.1. Changes to the ICV for AH and ESP with HIP 349 For the Integrity Check Value Calculation in AH and ESP, HIP is 350 treated as immutable in transit and MUST be included in the ICV. 351 Without this, at substitution attack is possible against HIP. 353 8. IANA Considerations 355 The IANA will assign a value of 2 for IPsec with HIP. Also each 356 algorithm will be assigned a value by the IANA. This assignment is 357 actually done in the DOI for IKE, and HIP uses those Security 358 Authentication numbers that are appropriate for it. 360 9. References 362 [ESP], Kent, S., and R. Atkinson, "IP Encapsulating Security 363 Payload", RFC 2406, November 1998. 365 [AH], Kent, S., and R. Atkinson, "IP Authentication Header", RFC 366 2402, November 1998. 368 [FIPS-180-1], NIST, FIPS PUB 180-1: Secure Hash Standard, April 369 1995. http://csrc.nist.gov/fips/fip180-1.txt (ascii) 370 http://csrc.nist.gov/fips/fip180-1.ps (postscript) 372 [FIPS-186], US National Bureau of Standards, "Digital Signature 373 Standard (DSS)", Federal Information Processing Standard (FIPS) 374 Publication 186, May 1994, 375 http://www.itl.nist.gov/div897/pubs/fip186.htm. 377 Moskowitz 7 379 The Host Identity Payload May 1999 381 [Thayer97a], Thayer, R., Doraswamy, N., and R. Glenn, "IP Security 382 Document Roadmap", RFC 2411, November 1998. 384 [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate 385 Requirement Levels", RFC 2119, Harvard University, March 1997 387 [HMAC-SHA-1-96], Madson, C., and R. Glenn, "The Use of HMAC-SHA-1 388 within ESP and AH", RFC 2404, November 1998. 390 [DOI], Piper, D., "The Internet IP Security Domain of Interpretation 391 for ISAKMP", RFC 2407, November 1998. 393 [AUTH_DSS], Moskowitz, R., "The Use of DSS within ESP and AH", 394 draft-ietf-moskowitz-auth-dss-00.txt, May 1999. 396 [HIP_ENC], Moskowitz, R., "ESP Encryption support in HIP", draft- 397 ietf-moskowitz-HIP-ENC-00.txt, May 1999. 399 [DNS], Mockapetris, P., "Domain Names - Implementation And 400 Specification", RFC 1035, November 1987. 402 [DNSSEC], Eastlake, D., "Domain Name System Security Extensions", 403 RFC 2535, March 1999. 405 [DSA_RR], Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 406 (DNS)", RFC 2536, March 1999. 408 10. Acknowledgments 410 The drive to create HIP came to being after attending the MALLOC 411 meeting at IETF 43. It is distilled from many conversations from the 412 IPsec mailing list and the IPsec workshops. Particularly Rodney 413 Thayer should be mentioned for giving this protocol its initial 414 push. Steve Bellovin assisted on some of the public key and replay 415 concerns. Baiju Patel and Hilarie Orman gave extensive comments on 416 the intial format, resulting in the present document. Hugh Daniels 417 and IPsec implementers have kept after me to see that HIP moved 418 beyond concept to spec. 420 11. Author's Addresses 422 Robert Moskowitz 423 ICSA, Inc. 424 1200 Walnut Bottom Rd. 425 Carlisle, PA 17013 426 Email: rgm@icsa.net 428 Moskowitz 8