idnits 2.17.1 draft-ietf-hip-cert-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 416. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2008) is 5659 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Host Identity Protocol Heer 3 Internet-Draft Distributed Systems Group, RWTH 4 Intended status: Informational Aachen University 5 Expires: April 24, 2009 Varjonen 6 Helsinki Institute for Information 7 Technology 8 October 21, 2008 10 HIP Certificates 11 draft-ietf-hip-cert-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 This document may not be modified, and derivative works of it may not 20 be created, except to publish it as an RFC and to translate it into 21 languages other than English. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 24, 2009. 41 Abstract 43 This document specifies a certificate parameter called CERT for the 44 Host Identity Protocol (HIP). The CERT parameter is a container for 45 Simple Public Key Infrastructure (SPKI) and X.509.v3 certificates. 46 It is used for carrying these certificates in HIP control messages. 47 Additionally, this document specifies the representations of Host 48 Identity Tags in SPKI and X.509.v3 certificates. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 1. Introduction 58 Digital certificates bind a piece of information to a public key by 59 means of a digital signature, and thus, enable the holder of a 60 private key to generate cryptographically verifiable statements. The 61 Host Identity Protocol (HIP)[RFC5201] defines a new cryptographic 62 namespace based on asymmetric cryptography. Each host's identity is 63 derived from a public key, allowing hosts to digitally sign data with 64 their private key. This document specifies the CERT parameter that 65 is used to transmit digital signatures in HIP. It corresponds to the 66 placeholder specified in Section 2 of [RFC5201]. 68 2. CERT Parameter 70 The CERT parameter is a container for a certain types of digital 71 certificates. It may either carry SPKI certificates or X.509.v3 72 certificates. It does not specify any certificate semantics. 73 However, it defines some organizational parameters that help HIP 74 hosts to transmit semantically grouped parameters in a more 75 systematic way. 77 The CERT parameter may be covered by the HIP SIGNATURE field and is a 78 non-critical parameter. 80 Each HIP packet may contain multiple CERT parameters. If these 81 parameters must be handled in certain sequence, the Cert group and 82 the Cert count field must be set. Ungrouped certificates exhibit a 83 unique Cert group field and set the Cert count to 1. CERT parameters 84 with the same Cert group number in the group field indicate a logical 85 grouping. The Cert count field indicates the number of grouped CERT 86 parameters. 88 CERT parameters that belong to the same CERT group may be contained 89 in multiple sequential packets. This is indicated by a higher Cert 90 count than the amount of CERT parameters with matching Cert group 91 fields in a packet. Within a HIP packet, CERT parameters must be 92 placed in ascending order according to their Cert group field. Cert 93 groups may only span multiple packets if the Cert group does not fit 94 the packet. Only one Cert group may span two subsequent packets. 96 The Cert ID acts as a sequence number to identify the certificates in 97 a Cert group. The numbers in the Cert ID field must start from 1 up 98 to Cert count. 100 The CERT parameter can be used in R1, I2, R2, UPDATE and NOTIFY 101 messages. When CERT parameter is used in R1 message it is NOT 102 recommended to use grouping or hash and URL encodings. Initiator and 103 Responder can detect middleboxes on the path after R1 message is sent 104 by checking if control packets contain ECHO_REQUEST_M parameters as 105 defined in [HIP.middle_auth]. 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Type | Length | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Cert group | Cert count | Cert ID | Cert type | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Certificate / 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 / | Padding | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 Type 768 120 Length Length in octets, excluding Type, Length, and Padding 121 Cert group Group ID grouping multiple related CERT parameters 122 Cert count Total count of certificates that are sent, possibly 123 in several consecutive HIP control packets. 124 Cert ID The sequence number for this certificate 125 Cert Type Describes the type of the certificate 126 Padding Any Padding, if necessary, to make the TLV a multiple 127 of 8 bytes. 129 The following certificate types are defined: 131 +--------------------------+-------------+ 132 | Cert format | Type number | 133 +--------------------------+-------------+ 134 | SPKI | 1 | 135 | X.509.v3 | 2 | 136 | Hash and URL of SPKI | 3 | 137 | Hash and URL of X.509.v3 | 4 | 138 +--------------------------+-------------+ 140 All implementations MUST support SPKI. The next section outlines the 141 use of HITs in SPKI. The SPKI and its formats are defined in 142 [RFC2693]. X.509.v3 certificates are defined in [RFC3280]. Wire 143 format for X.509.v3 is Distinguished Encoding Rules format as defined 144 in [X.690]. 146 Hash and URL encodings (3 and 4) are used as defined in [RFC4306]. 147 Using hash and URL encodings results in smaller HIP control packets, 148 but requires the receiver to resolve the URL or check local cache 149 against the hash. 151 It is not recommended to use hash and URL encodings when HIP-aware 152 middleboxes are present on the communication path between peers 153 because fetching remote certificates requires the middlebox to buffer 154 the packets and to request remote data. This makes these devices 155 prone to denial of service (DoS) attacks. Moreover, middleboxes and 156 responders that request remote certificates can be used as deflectors 157 for distributed denial of service attacks. 159 3. SPKI Cert Object and Host Identities 161 When using SPKI certificates to transmit information related to HIP 162 hosts, HITs need to be enclosed within the certificates. In the 163 following we define the representation of those identifiers for SPKI 164 given as S-expressions. Note that the S-expressions are only the 165 human-readable representation of SPKI certificates. 167 As an example the Host Identity Tag of a host is expressed as 168 follows: 170 Format: (hash hit hit-of-host) 171 Example: (hash hit 2001:13:724d:f3c0:6ff0:33c2:15d8:5f50) 173 Appendix A shows a full example SPKI certificate with HIP content. 175 4. X.509.v3 Certificate Object and Host Identities 177 When using X.509.v3 certificates to transmit information related to 178 HIP hosts, HITs need to be enclosed within the certificates. HITs 179 are represented as issuer and subject alternative name X.509.v3 180 extensions as defined in [RFC2459]. Because the Distinguished Name 181 (DN) in X.509.v3 certificate cannot be empty HITs are also placed 182 into the Common Name (CN) in a colon delimited presentation format. 184 As an example the HIT of a host is expressed as follows: 186 Format: 187 Issuer: CN=hit-of-host 188 Subject: CN=hit-of-host 190 X509v3 extensions: 191 X509v3 Issuer Alternative Name: 192 IP Address:HIT-OF-HOST 193 X509v3 Subject Alternative Name: 194 IP Address:HIT-OF-HOST 196 Example: 197 Issuer: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 198 Subject: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 200 X509v3 extensions: 201 X509v3 Issuer Alternative Name: 202 IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 203 X509v3 Subject Alternative Name: 204 IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 206 Appendix B shows a full example X.509.v3 certificate with HIP 207 content. 209 5. Revocation of Certificates 211 Revocation of SPKI certificates is handled as defined in Section 5. 212 in [RFC2693] Revocation of X.509.v3 certificates is handled as 213 defined in Section 5 in [RFC2459]. 215 6. IANA Considerations 217 This document defines the CERT parameter for the Host Identity 218 Protocol [RFC5201]. This parameter is defined in Section 2 with type 219 768. The parameter type number is also defined in [RFC5201]. The 220 Cert Group and Cert ID namespaces are managed locally by each peer 221 that sends CERT parameters in HIP packets. 223 7. Security Considerations 225 Certificate grouping allows the certificates to be sent in multiple 226 consecutive packets. This might allow similar attacks as IP-layer 227 fragmentation allows, i.e. sending of fragments in wrong order and 228 skipping some fragments to delay or stall packet processing by the 229 victim in order to use resources (e.g. CPU or memory). 231 8. Acknowledgements 233 The authors would like to thank M. Komu and T. Henderson of fruitful 234 conversations on the subject. 236 9. References 238 9.1. Normative References 240 [HIP.middle_auth] 241 Heer, T., "End-Host Authentication for HIP Middleboxes", 242 . 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, March 1997. 247 [RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 248 X.509 Public Key Infrastructure Certificate and CRL 249 Profile", RFC 2459, January 1999. 251 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 252 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 253 September 1999. 255 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 256 X.509 Public Key Infrastructure Certificate and 257 Certificate Revocation List (CRL) Profile", RFC 3280, 258 April 2002. 260 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 261 RFC 4306, December 2005. 263 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 264 "Host Identity Protocol", RFC 5201, April 2008. 266 9.2. Informative References 268 [X.690] ITU-T, "Recommendation X.690 Information Technology - 269 ASN.1 encoding rules: Specification of Basic Encoding 270 Rules (BER), Canonical Encoding Rules (CER) and 271 Distinguished Encoding Rules (DER)", July 2002, . 275 Appendix A. SPKI certificate example 277 This section shows a self-signed SPKI certificate of HIT 2001:14:6cf: 278 fae7:bb79:bf78:7d64:c056. The example has been indented for 279 readability. 281 (sequence 282 (public_key 283 (rsa-pkcs1-sha1 284 (e #010001#) 285 (n |n1CheoELqYRSkHYMQddub2TpILl+6H9wC/as6zFCZqOY43hsZgAjG0F 286 GoQwtyOyQjzO2Ykb2TmUCZemTYui/sR0zIbdwg1xafKl7ggZDkhk5an 287 PtGDxJxFalTYo6/A5ZQv8uatbaJgB/G7VM8G+O9HLucadad2zQUXpQf 288 gbK3S8=| 289 ) 290 ) 291 ) 292 (cert 293 (issuer 294 (hash hit 2001:0014:06cf:fae7:bb79:bf78:7d64:c056) 295 ) 296 (subject 297 (hash hit 2001:0014:06cf:fae7:bb79:bf78:7d64:c056) 298 ) 299 (not-before "2008-07-12_22:11:07") 300 (not-after "2008-07-22_22:11:07") 301 ) 302 (signature 303 (hash sha1 |kfElDhagiK0Bsqtj32Gq3t/1mxgA|) 304 |HiIqjjZIUzypvoxQyO0UovPm5uC4Xte0scEcBnENDIfn2DNy/bAtxGEdKq4O 305 dW80vTCmkF8/HXclgXLLVch3DxRNdSbYiiks000HpQt/OKqlTH+uUHBcHOAo 306 E42LmDskM9T5KQJoC/CH7871zfvojPnpkl2dUngOWv4q0r/wSJ0=| 307 ) 308 ) 310 Appendix B. X.509.v3 certificate example 312 This section shows a self-signed X.509.v3 certificate of HIT 2001:14: 313 6cf:fae7:bb79:bf78:7d64:c056. 315 Certificate: 316 Data: 317 Version: 3 (0x2) 318 Serial Number: 0 (0x0) 319 Signature Algorithm: sha1WithRSAEncryption 320 Issuer: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 321 Validity 322 Not Before: Jul 12 18:58:38 2008 GMT 323 Not After : Jul 22 18:58:38 2008 GMT 324 Subject: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 325 Subject Public Key Info: 326 Public Key Algorithm: rsaEncryption 327 RSA Public Key: (1024 bit) 328 Modulus (1024 bit): 329 00:9f:50:a1:7a:81:0b:a9:84:52:90:76:0c:41:d7: 330 6e:6f:64:e9:20:b9:7e:e8:7f:70:0b:f6:ac:eb:31: 331 42:66:a3:98:e3:78:6c:66:00:23:1b:41:46:a1:0c: 332 2d:c8:ec:90:8f:33:b6:62:46:f6:4e:65:02:65:e9: 333 93:62:e8:bf:b1:1d:33:21:b7:70:83:5c:5a:7c:a9: 334 7b:82:06:43:92:19:39:6a:73:ed:18:3c:49:c4:56: 335 a5:4d:8a:3a:fc:0e:59:42:ff:2e:6a:d6:da:26:00: 336 7f:1b:b5:4c:f0:6f:8e:f4:72:ee:71:a7:5a:77:6c: 337 d0:51:7a:50:7e:06:ca:dd:2f 338 Exponent: 65537 (0x10001) 339 X509v3 extensions: 340 X509v3 Basic Constraints: 341 CA:TRUE 342 X509v3 Issuer Alternative Name: 343 IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 344 X509v3 Subject Alternative Name: 345 IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 346 Signature Algorithm: sha1WithRSAEncryption 347 19:32:0b:72:a8:6c:f9:65:20:5b:1d:9a:e1:c7:39:97:c7:8a: 348 4d:d1:01:f9:7d:0b:0d:6f:61:a2:e3:2c:62:30:28:f6:36:db: 349 62:bc:7f:d1:9b:6d:cc:da:e3:9b:90:e7:53:9e:55:28:51:7e: 350 39:de:23:24:f5:a9:97:7a:ba:ce:54:3e:cf:8b:68:04:f6:be: 351 78:94:9f:d3:20:62:96:14:84:51:af:c7:ba:30:ae:b1:d6:7e: 352 7f:32:42:9c:f6:f5:76:27:0a:28:58:8b:b5:85:e7:e9:5a:ff: 353 aa:4c:57:55:95:09:33:ac:0b:8c:fd:05:4a:5e:60:e7:7f:d7: 354 42:f0 356 Authors' Addresses 358 Tobias Heer 359 Distributed Systems Group, RWTH Aachen University 360 Ahornstrasse 55 361 Aachen 362 Germany 364 Phone: +49 241 80 214 36 365 Email: heer@cs.rwth-aachem.de 366 URI: http://ds.cs.rwth-aachen.de/members/heer 368 Samu Varjonen 369 Helsinki Institute for Information Technology 370 Metsnneidonkuja 4 371 Helsinki 372 Finland 374 Fax: +35896949768 375 Email: samu.varjonen@hiit.fi 376 URI: http://www.hiit.fi 378 Full Copyright Statement 380 Copyright (C) The IETF Trust (2008). 382 This document is subject to the rights, licenses and restrictions 383 contained in BCP 78, and except as set forth therein, the authors 384 retain all their rights. 386 This document and the information contained herein are provided on an 387 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 388 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 389 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 390 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 391 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 392 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 394 Intellectual Property 396 The IETF takes no position regarding the validity or scope of any 397 Intellectual Property Rights or other rights that might be claimed to 398 pertain to the implementation or use of the technology described in 399 this document or the extent to which any license under such rights 400 might or might not be available; nor does it represent that it has 401 made any independent effort to identify any such rights. Information 402 on the procedures with respect to rights in RFC documents can be 403 found in BCP 78 and BCP 79. 405 Copies of IPR disclosures made to the IETF Secretariat and any 406 assurances of licenses to be made available, or the result of an 407 attempt made to obtain a general license or permission for the use of 408 such proprietary rights by implementers or users of this 409 specification can be obtained from the IETF on-line IPR repository at 410 http://www.ietf.org/ipr. 412 The IETF invites any interested party to bring to its attention any 413 copyrights, patents or patent applications, or other proprietary 414 rights that may cover technology that may be required to implement 415 this standard. Please address the information to the IETF at 416 ietf-ipr@ietf.org.