idnits 2.17.1 draft-varjonen-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 262. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 286. 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 (February 18, 2008) is 5883 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 2 errors (**), 0 flaws (~~), 2 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: August 21, 2008 Varjonen 6 Helsinki Institute for Information 7 Technology 8 February 18, 2008 10 HIP Certificates 11 draft-varjonen-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 August 21, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 This document specifies a certificate parameter called CERT for the 48 Host Identity Protocol (HIP). The CERT parameter is a container for 49 Simple Public Key Infrastructure (SPKI) and X.509 certificates. It 50 is used for carrying these certificates in HIP control messages. 51 Additionally, this document specifies the representations of Host 52 Identity Tags in SPKI certificates. 54 Requirements Language 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [RFC2119]. 60 1. Introduction 62 Digital certificates bind a piece of information to a public key by 63 means of a digital signature, and thus, enable the holder of a 64 private key to generate cryptographically verifiable statements. The 65 Host Identity Protocol (HIP)[I-D.ietf-hip-base] defines a new 66 cryptographic namespace based on asymmetric cryptography. Each 67 host's identity is derived from a public key, allowing hosts to 68 digitally sign data with their private key. This document specifies 69 the CERT parameter that is used to transmit digital signatures in 70 HIP. It corresponds to the placeholder specified in 71 [I-D.ietf-hip-base]. 73 2. CERT Parameter 75 The CERT parameter is a container for a certain types of digital 76 certificates. It may either carry SPKI certificates or X.509.v3 77 certificates. It does not specify any certificate semantics. 78 However, it defines organizational parameters that help HIP hosts to 79 transmit semantically grouped parameters. 81 The CERT parameter may be covered by the HIP SIGNATURE field and is a 82 non-critical parameter. 84 Each HIP packet may contain multiple CERT parameters. If these 85 parameters are related in a way that requires several parameters to 86 be handled in sequence, the Cert group and the Cert count field must 87 be set. Ungrouped certificates exhibit a unique Cert group field and 88 set the Cert count to 1. CERT parameters with the same Cert group 89 number in the group field indicate a logical grouping. The Cert 90 count field indicates the number of grouped CERT parameters. 92 CERT parameters that belong to the same CERT group may be contained 93 in multiple sequential packets. This is indicated by a higher Cert 94 count than the amount of CERT parameters with matching Cert group 95 fields in a packet. Within a HIP packet, CERT parameters must be 96 placed in ascending order of their Cert group field. Cert groups may 97 only span multiple packets if the cert group does not fit the packet. 98 Only one Cert group may span two subsequent packets. 100 The Cert ID acts as a sequence number to identify the certificates in 101 a Cert group. The numbers in the Cert ID field must start from 1 up 102 to Cert count. 104 The CERT parameter can be used in I1, R1, I2, R2, and UPDATE 105 messages. 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 +-------------+-------------+ 138 All implementations MUST support SPKI. The next section outlines the 139 use of HITs in SPKI. The wire formats for SPKI are defined in 140 [SEXP].The encoding format for X.509.v3 certificate is defined 141 elsewhere [RFC3280]. 143 3. SPKI cert object and Host Identities 145 When using SPKI certificates to transmit information relating to HIP 146 hosts, HITs need to be enclosed within the certificates. In the 147 following we define the representation of those identifiers for SPKI 148 given as S-expressions. Note that S-expressions are only the human- 149 readable representation of SPKI certificates. 151 The Host Identity Tag of a host is expressed as follows: 153 Format: (hash hit hit-of-host) 154 Example: (hash hit 2001:13:724d:f3c0:6ff0:33c2:15d8:5f50) 156 Below is a simple example of SPKI cert object with HIP content. 158 (cert 159 (issuer (hash hit 2001:14:fd64:ca3b:9ef2:8374:ec80:4f20)) 160 (subject (hash hit 2001:13:724d:f3c0:6ff0:33c2:15d8:5f50)) 161 (tag (arg ) 162 ... 163 (tag (arg ) 164 (propagate) 165 (online crl http://www.issuersdomain.net/crl) 166 (not before 1/1/2008) 167 (not after 12/31/2008) 168 ) 170 The certificate object has HITs encoded into issuer and subject 171 fields. Otherwise it is as defined in [SPKI.structure] and [RFC2693] 173 4. IANA Considerations 175 This document defines the CERT parameter for the Host Identity 176 Protocol [I-D.ietf-hip-base]. This parameter is defined in Section 2 177 with type 768. The parameter type number is also defined in 178 [I-D.ietf-hip-base]. The Cert Group and Cert ID namespaces are 179 managed locally by each peer that sends CERT parameters in HIP 180 packets. 182 5. Security Considerations 184 Certificate grouping allows the certificates to be sent in multiple 185 consecutive packets. This might allow similar attacks that 186 fragmentation allows, i.e. sending of fragments in wrong order and 187 skipping some fragments in order to leave the recipient waiting 188 something that never comes. This problem can be alleviated by rate 189 limiting HIP control packets 191 Using CERT parameter in I1 is not recommended, because it may lead to 192 workload on the responder. This workload may lead to a denial-of- 193 service attack. 195 6. Acknowledgements 197 The authors would like to thank M. Komu and T. Henderson of fruitful 198 conversations on the subject. 200 7. Normative References 202 [I-D.ietf-hip-base] 203 Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 204 "Host Identity Protocol", draft-ietf-hip-base-10 (work in 205 progress), October 2007. 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 211 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 212 September 1999. 214 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 215 X.509 Public Key Infrastructure Certificate and 216 Certificate Revocation List (CRL) Profile", RFC 3280, 217 April 2002. 219 [SEXP] Rivest, R., "Code and description of S-expressions", 220 . 222 [SPKI.structure] 223 Ellison, C., "Simple Public Key Certificate", 224 . 226 Authors' Addresses 228 Tobias Heer 229 Distributed Systems Group, RWTH Aachen University 230 Ahornstrasse 55 231 Aachen 232 Germany 234 Phone: +49 241 80 214 36 235 Email: heer@cs.rwth-aachem.de 236 URI: http://ds.cs.rwth-aachen.de/members/heer 238 Samu Varjonen 239 Helsinki Institute for Information Technology 240 Metsnneidonkuja 4 241 Helsinki 242 Finland 244 Fax: +35896949768 245 Email: samu.varjonen@hiit.fi 246 URI: http://www.hiit.fi 248 Full Copyright Statement 250 Copyright (C) The IETF Trust (2008). 252 This document is subject to the rights, licenses and restrictions 253 contained in BCP 78, and except as set forth therein, the authors 254 retain all their rights. 256 This document and the information contained herein are provided on an 257 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 258 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 259 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 260 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 261 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 262 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 264 Intellectual Property 266 The IETF takes no position regarding the validity or scope of any 267 Intellectual Property Rights or other rights that might be claimed to 268 pertain to the implementation or use of the technology described in 269 this document or the extent to which any license under such rights 270 might or might not be available; nor does it represent that it has 271 made any independent effort to identify any such rights. Information 272 on the procedures with respect to rights in RFC documents can be 273 found in BCP 78 and BCP 79. 275 Copies of IPR disclosures made to the IETF Secretariat and any 276 assurances of licenses to be made available, or the result of an 277 attempt made to obtain a general license or permission for the use of 278 such proprietary rights by implementers or users of this 279 specification can be obtained from the IETF on-line IPR repository at 280 http://www.ietf.org/ipr. 282 The IETF invites any interested party to bring to its attention any 283 copyrights, patents or patent applications, or other proprietary 284 rights that may cover technology that may be required to implement 285 this standard. Please address the information to the IETF at 286 ietf-ipr@ietf.org. 288 Acknowledgment 290 Funding for the RFC Editor function is provided by the IETF 291 Administrative Support Activity (IASA).