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