idnits 2.17.1 draft-ietf-sidr-bgpsec-algs-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC6485, but the abstract doesn't seem to directly say this. It does mention RFC6485 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2014) is 3654 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) ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6090 ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing Working Group S. Turner 3 Internet-Draft IECA 4 Updates: 6485 (if approved) March 27, 2014 5 Intended Status: Standards Track 6 Expires: September 28, 2014 8 BGP Algorithms, Key Formats, & Signature Formats 9 draft-ietf-sidr-bgpsec-algs-06 11 Abstract 13 This document specifies the algorithms, algorithms' parameters, 14 asymmetric key formats, asymmetric key size and signature format used 15 in BGPSEC (Border Gateway Protocol Security). This document updates 16 the Profile for Algorithms and Key Sizes for use in the Resource 17 Public Key Infrastructure (RFC 6485). 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 This document specifies: 52 o the digital signature algorithm and parameters; 53 o the hash algorithm and parameters; 54 o the public and private key formats; and, 55 o the signature format 56 used by Resource Public Key Infrastructure (RPKI) Certification 57 Authorities (CA), and BGPSEC (Border Gateway Protocol Security) 58 speakers (i.e., routers). CAs use these algorithms when issuing 59 BGPSEC Router Certificates [ID.sidr-bgpsec-pki-profiles] and CRLs 60 [RFC6487]. BGPSEC routers use these when requesting BGPSEC 61 certificates [ID.sidr-bgpsec-pki-profiles], generating BGPSEC Update 62 messages [ID.sidr-bgpsec-protocol], and verifying BGPSEC Update 63 messages [ID.sidr-bgpsec-protocol]. 65 This document is referenced by the BGPSEC specification [ID.sidr- 66 bgpsec-protocol] and the profile for BGPSEC Router Certificates and 67 Certification Requests [ID.sidr-bgpsec-pki-profiles]. Familiarity 68 with these documents is assumed. Implementers are reminded, however, 69 that, as noted in Section 2 of [ID.sidr-bgpsec-pki-profiles], the 70 algorithms used to sign CA Certificates, BGPSEC Router Certificates, 71 and CRLs are found in [RFC6485]. 73 This document updates [RFC6485] to add support for a) a different 74 algorithm for BGPSEC certificate requests, which are only issued by 75 BGPSEC speakers; b) a different Subject Public Key Info format for 76 BGPSEC certificates, which is needed for the specified BGPSEC 77 signature algorithm; and, c) a different signature format for BGPSEC 78 signatures, which is needed for the specified BGPSEC signature 79 algorithm. The BGPSEC certificate are differentiated from other RPKI 80 certificates by the use of the BGPSEC Extended Key Usage defined in 81 [ID.sidr-bgpsec-pki-profiles]. 83 1.1. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in 88 [RFC2119]. 90 2. Algorithms 92 Four cryptographic algorithms are used to support BGPSEC: 94 o The signature algorithm used when issuing BGPSEC certificates and 95 CRLs, which would revoke BGPSEC certificates, MUST be as 96 specified in [RFC6485]. 98 o The signature algorithm used in certification requests and BGPSEC 99 Update messages MUST be Elliptic Curve Digital Signature 100 Algorithm (ECDSA) [RFC6090]. 102 o The hashing algorithm used when issuing certificates and CRLs 103 MUST be as specified in [RFC6485]. 105 o The hashing algorithm use when generating certification requests 106 and BGPSEC Update messages MUST be SHA-256 [SHS]. Hash 107 algorithms are not identified by themselves in certificates, or 108 BGPSEC Update messages instead they are combined with the digital 109 signature algorithm (see below). 111 NOTE: The exception to the above hashing algorithm is the use of 112 SHA-1 [SHS] when CAs generate authority and subject key 113 identifiers [RFC6487]. 115 To support BGPSEC, the algorithms are identified as follows: 117 o In certificates and CRLs, an Object Identifier (OID) is used. 118 The value and locations are as specified in section 2 of 119 [RFC6485]. 121 o In certification request, an OID is used. The ecdsa-with-SHA256 122 OID [RFC5480] MUST appear in the PKCS #10 signatureAlgorithm 123 field [RFC4211] or in Certificate Request Message Format (CRMF) 124 POPOSigningKey signature field [RFC2986]. 126 o In BGPSEC Update messages, the ECDSA with SHA-256 Algorithm Suite 127 Identifier from Section 7 is included in the Signature-Block 128 List's Algorithm Suite Identifier field. 130 3. Asymmetric Key Format 132 The RSA key pairs used to compute signatures on CA certificates, 133 BGPSEC Router Certificates, and CRLs are as specified in section 3 of 134 [RFC6485]. The remainder of this section addresses key formats found 135 in the BGPSEC router certificate requests and in BGPSEC Router 136 Certificates. 138 The ECDSA key pairs used to compute signatures for certificate 139 requests and BGPSEC Update messages MUST come from the P-256 curve 140 [RFC5480]. The public key pair MUST use the uncompressed form. 142 3.1. Public Key Format 144 The Subject's public key is included in subjectPublicKeyInfo 145 [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. 147 The values for the structures and their sub-structures follow: 149 o algorithm (which is an AlgorithmIdentifier type): The id- 150 ecPublicKey OID MUST be used in the algorithm field, as specified 151 in 2.1.1 of [RFC5480]. The value for the associated parameters 152 MUST be secp256r1, as specified in 2.1.1.1 of [RFC5480]. 154 o subjectPublicKey: ECPublicKey MUST be used to encode the 155 certificate's subjectPublicKey field, as specified in Section 2.2 156 of [RFC5480]. 158 3.2. Private Key Format 160 Local Policy determines private key format. 162 4. Signature Format 164 The structure for the certificate's and CRL's signature field MUST be 165 as specified in Section 4 of [RFC6485]. The structure for the 166 certification request's and BGPSEC Update message's signature field 167 MUST be as specified in Section 2.2.3 of [RFC3279]. 169 5. Additional Requirements 171 It is anticipated that BGPSEC will require the adoption of updated 172 key sizes and a different set of signature and hash algorithms over 173 time, in order to maintain an acceptable level of cryptographic 174 security to protect the integrity of BGPSEC. This profile should be 175 updated to specify such future requirements, when appropriate. 177 CAs and RPs SHOULD be capable of supporting a transition to allow for 178 the phased introduction of additional encryption algorithms and key 179 specifications, and also accommodate the orderly deprecation of 180 previously specified algorithms and keys. Accordingly, CAs and RPs 181 SHOULD be capable of supporting multiple RPKI algorithm and key 182 profiles simultaneously within the scope of such anticipated 183 transitions. The recommended procedures to implement such a 184 transition of key sizes and algorithms is not specified in this 185 document. 187 6. Security Considerations 189 The Security Considerations of [RFC3279], [RFC5480], [RFC6090], 190 [RFC6485], and [ID.sidr-bgpsec-pki-profiles] apply to certificates. 191 The security considerations of [RFC3279], [RFC6090], [RFC6485], 192 [ID.sidr-bgpsec-pki-profiles] apply to certification requests. The 193 security considerations of [RFC3279], [ID.sidr-bgpsec-protocol], and 194 [RFC6090] apply to BGPSEC Update messages. No new security 195 considerations are introduced as a result of this specification. 197 7. IANA Considerations 199 The Internet Assigned Numbers Authority (IANA) is requested to define 200 the "BGPSEC Algorithm Suite Registry" described below. 202 An algorithm suite consists of a digest algorithm and a signature 203 algorithm. This specification creates an IANA registry of one-octet 204 BGPSEC algorithm suite identifiers. Additionally, this document 205 registers a single algorithm suite which uses the digest algorithm 206 SHA-256 and the signature algorithm ECDSA on the P-256 curve 207 [RFC5480]. 209 BGPSEC Algorithm Suites Registry 211 Digest Signature Algorithm Suite Specification 212 Algorithm Algorithm Identifier Pointer 213 +----------------------------------------------------------------+ 214 | SHA-256 | ECDSA P-256 | TBD | RFC 5480 | 215 +----------------------------------------------------------------+ 217 Future assignments are to be made using either the Standards Action 218 process defined in [RFC5226], or the Early IANA Allocation process 219 defined in [RFC7120]. Assignments consist of a digest algorithm 220 name, signature algorithm name, and the algorithm suite identifier 221 value. 223 10. Acknowledgements 225 The author wishes to thank Geoff Huston for producing [RFC6485], 226 which this document is heavily based on. I'd also like to thank 227 Roque Gagliano for his review and comments. 229 11. References 231 11.1. Normative References 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, March 1997. 236 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 237 Request Syntax Specification Version 1.7", RFC 2986, 238 November 2000. 240 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 241 Identifiers for the Internet X.509 Public Key 242 Infrastructure Certificate and Certificate Revocation List 243 (CRL) Profile", RFC 3279, April 2002. 245 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 246 Certificate Request Message Format (CRMF)", RFC 4211, 247 September 2005. 249 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 250 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 251 2008. 253 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 254 Housley, R., and W. Polk, "Internet X.509 Public Key 255 Infrastructure Certificate and Certificate Revocation List 256 (CRL) Profile", RFC 5280, May 2008. 258 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 259 "Elliptic Curve Cryptography Subject Public Key 260 Information", RFC 5480, March 2009. 262 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 263 Curve Cryptography Algorithms", RFC 6090, February 2011. 265 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 266 Use in the Resource Public Key Infrastructure (RPKI)", 267 RFC 6485, February 2012. 269 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 270 X.509 PKIX Resource Certificates", RFC 6487, February 2012. 272 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 273 Points", BCP 100, RFC 7120, January 2014. 275 [SHS] National Institute of Standards and Technology (NIST), "FIPS 276 Publication 180-3: Secure Hash Standard", FIPS Publication 277 180-3, October 2008. 279 [ID.sidr-bgpsec-protocol] Lepinski, M., "BGPSEC Protocol 280 Specification", draft-ietf-sidr-bgpsec-protocol, work-in- 281 progress. 283 [ID.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile 284 for BGPSEC Router Certificates, Certificate Revocation 285 Lists, and Certification Requests", draft-ietf-sidr-bgpsec- 286 pki-profiles, work-in-progress. 288 11.1. Informative References 290 None. 292 Authors' Addresses 294 Sean Turner 295 IECA, Inc. 296 3057 Nutley Street, Suite 106 297 Fairfax, VA 22031 298 USA 300 EMail: turners@ieca.com