idnits 2.17.1 draft-ietf-hip-cert-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- == The document has an IETF Trust Provisions of 28 Dec 2009, Section 6.c(i) Publication Limitation clause. 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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (April 28, 2010) is 5104 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) ** Obsolete normative reference: RFC 2255 (Obsoleted by RFC 4510, RFC 4516) ** 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: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: October 30, 2010 Varjonen 6 Helsinki Institute for Information 7 Technology 8 April 28, 2010 10 HIP Certificates 11 draft-ietf-hip-cert-03 13 Abstract 15 This document specifies a certificate parameter called CERT for the 16 Host Identity Protocol (HIP). The CERT parameter is a container for 17 X.509.v3 certificates and for Simple Public Key Infrastructure (SPKI) 18 certificates. It is used for carrying these certificates in HIP 19 control packets. Additionally, this document specifies the 20 representations of Host Identity Tags in X.509.v3 and in SPKI 21 certificates. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. This document may not be modified, 33 and derivative works of it may not be created, except to format it 34 for publication as an RFC or to translate it into languages other 35 than English. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 30, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 1. Introduction 66 Digital certificates bind a piece of information to a public key by 67 means of a digital signature, and thus, enable the holder of a 68 private key to generate cryptographically verifiable statements. The 69 Host Identity Protocol (HIP)[RFC5201] defines a new cryptographic 70 namespace based on asymmetric cryptography. Each host's identity is 71 derived from a public key, allowing hosts to digitally sign data with 72 their private key. This document specifies a CERT parameter that is 73 used to transmit digital signatures in HIP. It fills the placeholder 74 specified in Section 5.2 of [RFC5201]. 76 2. CERT Parameter 78 The CERT parameter is a container for a certain types of digital 79 certificates. It may either carry SPKI certificates or X.509.v3 80 certificates. It does not specify any certificate semantics. 81 However, it defines some organizational parameters that help HIP 82 hosts to transmit semantically grouped parameters in a more 83 systematic way. 85 The CERT parameter may be covered by the HIP SIGNATURE field and is a 86 non-critical parameter. 88 The CERT parameter can be used in all HIP packets but using CERT in 89 I1 is NOT RECOMMENDED. Each allowed HIP control packet may contain 90 multiple CERT parameters. These parameters may be related or 91 unrelated. Related certificates are managed in Cert groups. A Cert 92 group specifies a group of related CERT parameters that should be 93 interpreted in a certain order (e.g. for expressing certificate 94 chains). For grouping CERT parameters, the Cert group and the Cert 95 count field must be set. Ungrouped certificates exhibit a unique 96 Cert group field and set the Cert count to 1. CERT parameters with 97 the same Cert group number in the group field indicate a logical 98 grouping. The Cert count field indicates the number of CERT 99 parameters in the group. 101 CERT parameters that belong to the same Cert group may be contained 102 in multiple sequential HIP control packets. This is indicated by a 103 higher Cert count than the amount of CERT parameters with matching 104 Cert group fields in a HIP control packet. The CERT parameters must 105 be placed in ascending order, within a HIP control packet, according 106 to their Cert group field. Cert groups may only span multiple 107 packets if the Cert group does not fit the packet. Only one Cert 108 group may span two subsequent packets. 110 The Cert ID acts as a sequence number to identify the certificates in 111 a Cert group. The numbers in the Cert ID field must start from 1 up 112 to Cert count. 114 0 1 2 3 115 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 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Type | Length | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Cert group | Cert count | Cert ID | Cert type | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Certificate / 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 / | Padding | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 Type 768 127 Length Length in octets, excluding Type, Length, and Padding 128 Cert group Group ID grouping multiple related CERT parameters 129 Cert count Total count of certificates that are sent, possibly 130 in several consecutive HIP control packets. 131 Cert ID The sequence number for this certificate 132 Cert Type Describes the type of the certificate 133 Padding Any Padding, if necessary, to make the TLV a multiple 134 of 8 bytes. 136 The following certificate types are defined: 138 +--------------------------------+-------------+ 139 | Cert format | Type number | 140 +--------------------------------+-------------+ 141 | X.509.v3 | 1 | 142 | SPKI | 2 | 143 | URL of X.509.v3 | 3 | 144 | URL of SPKI | 4 | 145 | Hash of X.509.v3 | 5 | 146 | Hash of SPKI | 6 | 147 | LDAP URL of X.509.v3 | 7 | 148 | LDAP URL of SPKI | 8 | 149 | Distinguished Name of X.509.v3 | 9 | 150 | Distinguished Name of SPKI | 10 | 151 +--------------------------------+-------------+ 153 Next sections outline the use of HITs in X.509.v3 and in SPKI 154 certificates. X.509.v3 certificates are defined in [RFC3280]. The 155 Wire format for X.509.v3 is Distinguished Encoding Rules format as 156 defined in [X.690]. The SPKI and its formats are defined in 157 [RFC2693]. 159 Hash and URL encodings (3 to 6) are used as defined in [RFC4306]. 160 Using hash and URL encodings results in smaller HIP control packets, 161 but requires the receiver to resolve the URL or check local cache 162 against the hash. 164 LDAP URL encoding (7 and 8) is used as defined in [RFC2255]. Using 165 LDAP URL encoding results in smaller HIP control packets, but 166 requires the receiver to retrieve the certificate or check local 167 cache against the URL. 169 Distinguished name (DN) encoding (9 and 10) is used as defined in 170 [RFC1779]. Using LDAP URL encoding results in smaller HIP control 171 packets, but requires the receiver to retrieve the certificate or 172 check local cache against the DN. 174 3. X.509.v3 Certificate Object and Host Identities 176 HITs need to be enclosed within the certificates, when using X.509.v3 177 certificates to transmit information related to HIP hosts. HITs can 178 represent an issuer, a subject, or both. In X.509.v3 HITs are 179 represented as issuer and subject alternative name extensions as 180 defined in [RFC2459]. If only HIP information is presented as either 181 the issuer or the subject the HIT is also placed into the respective 182 entity's DNs Common Name (CN) section in a colon delimited 183 presentation format. Inclusion of CN is not necessary if DN contains 184 any other information. It is RECOMMENDED to use FQDN/NAI from the 185 hosts HOST_ID parameter in DN if one exists. Full HIs are presented 186 in the public key entries of X.509.v3 certificates. 188 As an example, in a case where the issuer and the subject are both 189 HIP enabled, the HITs are expressed as follows: 191 Format: 192 Issuer: CN=hit-of-host 193 Subject: CN=hit-of-host 195 X509v3 extensions: 196 X509v3 Issuer Alternative Name: 197 IP Address:HIT-OF-HOST 198 X509v3 Subject Alternative Name: 199 IP Address:HIT-OF-HOST 201 Example: 202 Issuer: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 203 Subject: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 205 X509v3 extensions: 206 X509v3 Issuer Alternative Name: 207 IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 208 X509v3 Subject Alternative Name: 209 IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 211 Appendix B shows a full example X.509.v3 certificate with HIP 212 content. 214 4. SPKI Cert Object and Host Identities 216 HITs need to be enclosed within the certificates, when using SPKI 217 certificates to transmit information related to HIP hosts. HITs can 218 represent an issuer, a subject, or both. In the following we define 219 the representation of those identifiers for SPKI given as 220 S-expressions. Note that the S-expressions are only the human- 221 readable representation of SPKI certificates. Full HIs are presented 222 in the public key sequences of SPKI certificates. 224 As an example the Host Identity Tag of a host is expressed as 225 follows: 227 Format: (hash hit hit-of-host) 228 Example: (hash hit 2001:13:724d:f3c0:6ff0:33c2:15d8:5f50) 230 Appendix A shows a full example SPKI certificate with HIP content. 232 5. Revocation of Certificates 234 Revocation of SPKI certificates is handled as defined in Section 5. 235 in [RFC2693] Revocation of X.509.v3 certificates is handled as 236 defined in Section 5 in [RFC2459]. 238 6. Signaling 240 HIP end-hosts and HIP-aware middleboxes need to inform, the initiator 241 or the responder, of the need for a certificate or need for a chain 242 of certificates. They also need a way to inform about failing to 243 meet required conditions. HIP services [HIP.service] describes the 244 signaling. Signaling for the requirements and failures with 245 certificates is described in Section 4.1 of [HIP.service]. 247 7. IANA Considerations 249 This document defines the CERT parameter for the Host Identity 250 Protocol [RFC5201]. This parameter is defined in Section 2 with type 251 768. The parameter type number is also defined in [RFC5201]. The 252 Cert Group and Cert ID namespaces are managed locally by each host 253 that sends CERT parameters in HIP control packets. 255 8. Security Considerations 257 Certificate grouping allows the certificates to be sent in multiple 258 consecutive packets. This might allow similar attacks as IP-layer 259 fragmentation allows, i.e. sending of fragments in wrong order and 260 skipping some fragments to delay or stall packet processing by the 261 victim in order to use resources (e.g. CPU or memory). 263 It is not recommended to use grouping or hash and URL encodings when 264 HIP-aware middleboxes are anticipated to be present on the 265 communication path between peers because fetching remote certificates 266 require the middlebox to buffer the packets and to request remote 267 data. This makes these devices prone to denial of service (DoS) 268 attacks. Moreover, middleboxes and responders that request remote 269 certificates can be used as deflectors for distributed denial of 270 service attacks. 272 9. Acknowledgements 274 The authors would like to thank M. Komu and T. Henderson of fruitful 275 conversations on the subject. 277 10. References 279 10.1. Normative References 281 [HIP.service] 282 Heer, T., Wirtz, H., and S. Varjonen, "Service Identifiers 283 for HIP", . 285 [RFC1779] Kille, S., "A String Representation of Distinguished 286 Names", RFC 1779, March 1995. 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, 292 December 1997. 294 [RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 295 X.509 Public Key Infrastructure Certificate and CRL 296 Profile", RFC 2459, January 1999. 298 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 299 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 300 September 1999. 302 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 303 X.509 Public Key Infrastructure Certificate and 304 Certificate Revocation List (CRL) Profile", RFC 3280, 305 April 2002. 307 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 308 RFC 4306, December 2005. 310 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 311 "Host Identity Protocol", RFC 5201, April 2008. 313 10.2. Informative References 315 [X.690] ITU-T, "Recommendation X.690 Information Technology - 316 ASN.1 encoding rules: Specification of Basic Encoding 317 Rules (BER), Canonical Encoding Rules (CER) and 318 Distinguished Encoding Rules (DER)", July 2002, . 322 Appendix A. SPKI certificate example 324 This section shows a self-signed SPKI certificate of HIT 2001:14:6cf: 325 fae7:bb79:bf78:7d64:c056. The example has been indented for 326 readability. 328 (sequence 329 (public_key 330 (rsa-pkcs1-sha1 331 (e #010001#) 332 (n |n1CheoELqYRSkHYMQddub2TpILl+6H9wC/as6zFCZqOY43hsZgAjG0F 333 GoQwtyOyQjzO2Ykb2TmUCZemTYui/sR0zIbdwg1xafKl7ggZDkhk5an 334 PtGDxJxFalTYo6/A5ZQv8uatbaJgB/G7VM8G+O9HLucadad2zQUXpQf 335 gbK3S8=| 336 ) 337 ) 338 ) 339 (cert 340 (issuer 341 (hash hit 2001:0014:06cf:fae7:bb79:bf78:7d64:c056) 342 ) 343 (subject 344 (hash hit 2001:0014:06cf:fae7:bb79:bf78:7d64:c056) 345 ) 346 (not-before "2008-07-12_22:11:07") 347 (not-after "2008-07-22_22:11:07") 348 ) 349 (signature 350 (hash sha1 |kfElDhagiK0Bsqtj32Gq3t/1mxgA|) 351 |HiIqjjZIUzypvoxQyO0UovPm5uC4Xte0scEcBnENDIfn2DNy/bAtxGEdKq4O 352 dW80vTCmkF8/HXclgXLLVch3DxRNdSbYiiks000HpQt/OKqlTH+uUHBcHOAo 353 E42LmDskM9T5KQJoC/CH7871zfvojPnpkl2dUngOWv4q0r/wSJ0=| 354 ) 355 ) 357 Appendix B. X.509.v3 certificate example 359 This section shows a self-signed X.509.v3 certificate of HIT 2001:14: 360 6cf:fae7:bb79:bf78:7d64:c056. 362 Certificate: 363 Data: 364 Version: 3 (0x2) 365 Serial Number: 0 (0x0) 366 Signature Algorithm: sha1WithRSAEncryption 367 Issuer: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 368 Validity 369 Not Before: Jul 12 18:58:38 2008 GMT 370 Not After : Jul 22 18:58:38 2008 GMT 371 Subject: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 372 Subject Public Key Info: 373 Public Key Algorithm: rsaEncryption 374 RSA Public Key: (1024 bit) 375 Modulus (1024 bit): 376 00:9f:50:a1:7a:81:0b:a9:84:52:90:76:0c:41:d7: 377 6e:6f:64:e9:20:b9:7e:e8:7f:70:0b:f6:ac:eb:31: 378 42:66:a3:98:e3:78:6c:66:00:23:1b:41:46:a1:0c: 379 2d:c8:ec:90:8f:33:b6:62:46:f6:4e:65:02:65:e9: 380 93:62:e8:bf:b1:1d:33:21:b7:70:83:5c:5a:7c:a9: 381 7b:82:06:43:92:19:39:6a:73:ed:18:3c:49:c4:56: 382 a5:4d:8a:3a:fc:0e:59:42:ff:2e:6a:d6:da:26:00: 383 7f:1b:b5:4c:f0:6f:8e:f4:72:ee:71:a7:5a:77:6c: 384 d0:51:7a:50:7e:06:ca:dd:2f 385 Exponent: 65537 (0x10001) 386 X509v3 extensions: 387 X509v3 Basic Constraints: 388 CA:TRUE 389 X509v3 Issuer Alternative Name: 390 IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 391 X509v3 Subject Alternative Name: 392 IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 393 Signature Algorithm: sha1WithRSAEncryption 394 19:32:0b:72:a8:6c:f9:65:20:5b:1d:9a:e1:c7:39:97:c7:8a: 395 4d:d1:01:f9:7d:0b:0d:6f:61:a2:e3:2c:62:30:28:f6:36:db: 396 62:bc:7f:d1:9b:6d:cc:da:e3:9b:90:e7:53:9e:55:28:51:7e: 397 39:de:23:24:f5:a9:97:7a:ba:ce:54:3e:cf:8b:68:04:f6:be: 398 78:94:9f:d3:20:62:96:14:84:51:af:c7:ba:30:ae:b1:d6:7e: 399 7f:32:42:9c:f6:f5:76:27:0a:28:58:8b:b5:85:e7:e9:5a:ff: 400 aa:4c:57:55:95:09:33:ac:0b:8c:fd:05:4a:5e:60:e7:7f:d7: 401 42:f0 403 Appendix C. Change log 405 Changes from version 00 to 01: 407 o Revised text about DN usage. 409 o Revised text about Cert group usage. 411 Changes from version 01 to 02: 413 o Revised the type numbers. 415 o Added a section about signaling. 417 Changes from version 02 to 03: 419 o Revised text about CERT use in control packets. 421 Authors' Addresses 423 Tobias Heer 424 Distributed Systems Group, RWTH Aachen University 425 Ahornstrasse 55 426 Aachen 427 Germany 429 Phone: +49 241 80 214 36 430 Email: heer@cs.rwth-aachen.de 431 URI: http://ds.cs.rwth-aachen.de/members/heer 433 Samu Varjonen 434 Helsinki Institute for Information Technology 435 Metsnneidonkuja 4 436 Helsinki 437 Finland 439 Fax: +35896949768 440 Email: samu.varjonen@hiit.fi 441 URI: http://www.hiit.fi