< draft-ietf-sidr-bgpsec-algs-09.txt   draft-ietf-sidr-bgpsec-algs-10.txt >
Secure Inter-Domain Routing Working Group S. Turner Secure Inter-Domain Routing Working Group S. Turner
Internet-Draft IECA, Inc. Internet-Draft IECA, Inc.
Updates: 6485 (if approved) January 21, 2015 Updates: 6485 (if approved) July 20, 2015
Intended status: BCP Intended status: BCP
Expires: July 25, 2015 Expires: January 21, 2016
BGP Algorithms, Key Formats, & Signature Formats BGPsec Algorithms, Key Formats, & Signature Formats
draft-ietf-sidr-bgpsec-algs-09 draft-ietf-sidr-bgpsec-algs-10
Abstract Abstract
This document specifies the algorithms, algorithms' parameters, This document specifies the algorithms, algorithms' parameters,
asymmetric key formats, asymmetric key size and signature format used asymmetric key formats, asymmetric key size and signature format used
in BGPSEC (Border Gateway Protocol Security). This document updates in BGPsec (Border Gateway Protocol Security). This document updates
the Profile for Algorithms and Key Sizes for use in the Resource the Profile for Algorithms and Key Sizes for use in the Resource
Public Key Infrastructure (RFC 6485). Public Key Infrastructure (RFC 6485).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
skipping to change at page 2, line 13 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
1. Introduction 1. Introduction
This document specifies: This document specifies:
o the digital signature algorithm and parameters; o the digital signature algorithm and parameters;
o the hash algorithm and parameters; o the hash algorithm and parameters;
o the public and private key formats; and, o the public and private key formats; and,
o the signature format o the signature format
used by Resource Public Key Infrastructure (RPKI) Certification used by Resource Public Key Infrastructure (RPKI) Certification
Authorities (CA), and BGPSEC (Border Gateway Protocol Security) Authorities (CA), and BGPsec (Border Gateway Protocol Security)
speakers (i.e., routers). CAs use these algorithms when issuing speakers (i.e., routers). CAs use these algorithms when issuing
BGPSEC Router Certificates [ID.sidr-bgpsec-pki-profiles] and CRLs BGPsec Router Certificates [ID.sidr-bgpsec-pki-profiles] and CRLs
[RFC6487]. BGPSEC routers use these when requesting BGPSEC [RFC6487]. BGPsec routers use these when requesting BGPsec
certificates [ID.sidr-bgpsec-pki-profiles], generating BGPSEC Update certificates [ID.sidr-bgpsec-pki-profiles], generating BGPsec Update
messages [ID.sidr-bgpsec-protocol], and verifying BGPSEC Update messages [ID.sidr-bgpsec-protocol], and verifying BGPsec Update
messages [ID.sidr-bgpsec-protocol]. messages [ID.sidr-bgpsec-protocol].
This document is referenced by the BGPSEC specification [ID.sidr- This document is referenced by the BGPsec specification [ID.sidr-
bgpsec-protocol] and the profile for BGPSEC Router Certificates and bgpsec-protocol] and the profile for BGPsec Router Certificates and
Certification Requests [ID.sidr-bgpsec-pki-profiles]. Familiarity Certification Requests [ID.sidr-bgpsec-pki-profiles]. Familiarity
with these documents is assumed. Implementers are reminded, however, with these documents is assumed. Implementers are reminded, however,
that, as noted in Section 2 of [ID.sidr-bgpsec-pki-profiles], the that, as noted in Section 2 of [ID.sidr-bgpsec-pki-profiles], the
algorithms used to sign CA Certificates, BGPSEC Router Certificates, algorithms used to sign CA Certificates, BGPsec Router Certificates,
and CRLs are found in [RFC6485]. and CRLs are found in [RFC6485].
This document updates [RFC6485] to add support for a) a different This document updates [RFC6485] to add support for a) a different
algorithm for BGPSEC certificate requests, which are only issued by algorithm for BGPsec certificate requests, which are only issued by
BGPSEC speakers; b) a different Subject Public Key Info format for BGPsec speakers; b) a different Subject Public Key Info format for
BGPSEC certificates, which is needed for the specified BGPSEC BGPsec certificates, which is needed for the specified BGPsec
signature algorithm; and, c) a different signature format for BGPSEC signature algorithm; and, c) a different signature format for BGPsec
signatures, which is needed for the specified BGPSEC signature signatures, which is needed for the specified BGPsec signature
algorithm. The BGPSEC certificate are differentiated from other RPKI algorithm. The BGPsec certificate are differentiated from other RPKI
certificates by the use of the BGPSEC Extended Key Usage defined in certificates by the use of the BGPsec Extended Key Usage defined in
[ID.sidr-bgpsec-pki-profiles]. [ID.sidr-bgpsec-pki-profiles].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Algorithms 2. Algorithms
Four cryptographic algorithms are used to support BGPSEC: Four cryptographic algorithms are used to support BGPsec:
o The signature algorithm used when issuing BGPSEC certificates and o The signature algorithm used when issuing BGPsec certificates and
CRLs, which would revoke BGPSEC certificates, MUST be as CRLs, which would revoke BGPsec certificates, MUST be as
specified in [RFC6485]. specified in [RFC6485].
o The signature algorithm used in certification requests and BGPSEC o The signature algorithm used in certification requests and BGPsec
Update messages MUST be Elliptic Curve Digital Signature Update messages MUST be Elliptic Curve Digital Signature
Algorithm (ECDSA) [RFC6090]. Algorithm (ECDSA) [RFC6090].
o The hashing algorithm used when issuing certificates and CRLs o The hashing algorithm used when issuing certificates and CRLs
MUST be as specified in [RFC6485]. MUST be as specified in [RFC6485].
o The hashing algorithm use when generating certification requests o The hashing algorithm use when generating certification requests
and BGPSEC Update messages MUST be SHA-256 [SHS]. Hash and BGPsec Update messages MUST be SHA-256 [SHS]. Hash
algorithms are not identified by themselves in certificates, or algorithms are not identified by themselves in certificates, or
BGPSEC Update messages instead they are combined with the digital BGPsec Update messages instead they are combined with the digital
signature algorithm (see below). signature algorithm (see below).
NOTE: The exception to the above hashing algorithm is the use of NOTE: The exception to the above hashing algorithm is the use of
SHA-1 [SHS] when CAs generate authority and subject key SHA-1 [SHS] when CAs generate authority and subject key
identifiers [RFC6487]. identifiers [RFC6487].
To support BGPSEC, the algorithms are identified as follows: To support BGPsec, the algorithms are identified as follows:
o In certificates and CRLs, an Object Identifier (OID) is used. o In certificates and CRLs, an Object Identifier (OID) is used.
The value and locations are as specified in section 2 of The value and locations are as specified in section 2 of
[RFC6485]. [RFC6485].
o In certification request, an OID is used. The ecdsa-with-SHA256 o In certification request, an OID is used. The ecdsa-with-SHA256
OID [RFC5480] MUST appear in the PKCS #10 signatureAlgorithm OID [RFC5480] MUST appear in the PKCS #10 signatureAlgorithm
field [RFC2986] or in Certificate Request Message Format (CRMF) field [RFC2986] or in Certificate Request Message Format (CRMF)
POPOSigningKey algoirthm field [RFC4211]. POPOSigningKey algoirthm field [RFC4211].
o In BGPSEC Update messages, the ECDSA with SHA-256 Algorithm Suite o In BGPsec Update messages, the ECDSA with SHA-256 Algorithm Suite
Identifier from Section 7 is included in the Signature-Block Identifier from Section 7 is included in the Signature-Block
List's Algorithm Suite Identifier field. List's Algorithm Suite Identifier field.
3. Asymmetric Key Format 3. Asymmetric Key Format
The RSA key pairs used to compute signatures on CA certificates, The RSA key pairs used to compute signatures on CA certificates,
BGPSEC Router Certificates, and CRLs are as specified in section 3 of BGPsec Router Certificates, and CRLs are as specified in section 3 of
[RFC6485]. The remainder of this section addresses key formats found [RFC6485]. The remainder of this section addresses key formats found
in the BGPSEC router certificate requests and in BGPSEC Router in the BGPsec router certificate requests and in BGPsec Router
Certificates. Certificates.
The ECDSA key pairs used to compute signatures for certificate The ECDSA key pairs used to compute signatures for certificate
requests and BGPSEC Update messages MUST come from the P-256 curve requests and BGPsec Update messages MUST come from the P-256 curve
[RFC5480]. The public key pair MUST use the uncompressed form. [RFC5480]. The public key pair MUST use the uncompressed form.
3.1. Public Key Format 3.1. Public Key Format
The Subject's public key is included in subjectPublicKeyInfo The Subject's public key is included in subjectPublicKeyInfo
[RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey.
The values for the structures and their sub-structures follow: The values for the structures and their sub-structures follow:
o algorithm (which is an AlgorithmIdentifier type): The id- o algorithm (which is an AlgorithmIdentifier type): The id-
ecPublicKey OID MUST be used in the algorithm field, as specified ecPublicKey OID MUST be used in the algorithm field, as specified
skipping to change at page 4, line 40 skipping to change at page 4, line 40
of [RFC5480]. of [RFC5480].
3.2. Private Key Format 3.2. Private Key Format
Local Policy determines private key format. Local Policy determines private key format.
4. Signature Format 4. Signature Format
The structure for the certificate's and CRL's signature field MUST be The structure for the certificate's and CRL's signature field MUST be
as specified in Section 4 of [RFC6485]. The structure for the as specified in Section 4 of [RFC6485]. The structure for the
certification request's and BGPSEC Update message's signature field certification request's and BGPsec Update message's signature field
MUST be as specified in Section 2.2.3 of [RFC3279]. MUST be as specified in Section 2.2.3 of [RFC3279].
5. Additional Requirements 5. Additional Requirements
It is anticipated that BGPSEC will require the adoption of updated It is anticipated that BGPsec will require the adoption of updated
key sizes and a different set of signature and hash algorithms over key sizes and a different set of signature and hash algorithms over
time, in order to maintain an acceptable level of cryptographic time, in order to maintain an acceptable level of cryptographic
security to protect the integrity of BGPSEC. This profile should be security to protect the integrity of BGPsec. This profile should be
updated to specify such future requirements, when appropriate. updated to specify such future requirements, when appropriate.
CAs and RPs SHOULD be capable of supporting a transition to allow for CAs and RPs SHOULD be capable of supporting a transition to allow for
the phased introduction of additional encryption algorithms and key the phased introduction of additional encryption algorithms and key
specifications, and also accommodate the orderly deprecation of specifications, and also accommodate the orderly deprecation of
previously specified algorithms and keys. Accordingly, CAs and RPs previously specified algorithms and keys. Accordingly, CAs and RPs
SHOULD be capable of supporting multiple RPKI algorithm and key SHOULD be capable of supporting multiple RPKI algorithm and key
profiles simultaneously within the scope of such anticipated profiles simultaneously within the scope of such anticipated
transitions. The recommended procedures to implement such a transitions. The recommended procedures to implement such a
transition of key sizes and algorithms is not specified in this transition of key sizes and algorithms is not specified in this
document. document.
6. Security Considerations 6. Security Considerations
The Security Considerations of [RFC3279], [RFC5480], [RFC6090], The Security Considerations of [RFC3279], [RFC5480], [RFC6090],
[RFC6485], and [ID.sidr-bgpsec-pki-profiles] apply to certificates. [RFC6485], and [ID.sidr-bgpsec-pki-profiles] apply to certificates.
The security considerations of [RFC3279], [RFC6090], [RFC6485], The security considerations of [RFC3279], [RFC6090], [RFC6485],
[ID.sidr-bgpsec-pki-profiles] apply to certification requests. The [ID.sidr-bgpsec-pki-profiles] apply to certification requests. The
security considerations of [RFC3279], [ID.sidr-bgpsec-protocol], and security considerations of [RFC3279], [ID.sidr-bgpsec-protocol], and
[RFC6090] apply to BGPSEC Update messages. No new security [RFC6090] apply to BGPsec Update messages. No new security
considerations are introduced as a result of this specification. considerations are introduced as a result of this specification.
7. IANA Considerations 7. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to define The Internet Assigned Numbers Authority (IANA) is requested to define
the "BGPSEC Algorithm Suite Registry" described below. the "BGPsec Algorithm Suite Registry" described below.
An algorithm suite consists of a digest algorithm and a signature An algorithm suite consists of a digest algorithm and a signature
algorithm. This specification creates an IANA registry of one-octet algorithm. This specification creates an IANA registry of one-octet
BGPSEC algorithm suite identifiers. Additionally, this document BGPsec algorithm suite identifiers. Additionally, this document
registers a single algorithm suite which uses the digest algorithm registers a single algorithm suite which uses the digest algorithm
SHA-256 and the signature algorithm ECDSA on the P-256 curve SHA-256 and the signature algorithm ECDSA on the P-256 curve
[RFC5480]. [RFC5480].
BGPSEC Algorithm Suites Registry BGPsec Algorithm Suites Registry
Digest Signature Algorithm Suite Specification Digest Signature Algorithm Suite Specification
Algorithm Algorithm Identifier Pointer Algorithm Algorithm Identifier Pointer
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| SHA-256 | ECDSA P-256 | TBD | RFC 5480 | | SHA-256 | ECDSA P-256 | TBD | RFC 5480 |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
Future assignments are to be made using either the Standards Action Future assignments are to be made using either the Standards Action
process defined in [RFC5226], or the Early IANA Allocation process process defined in [RFC5226], or the Early IANA Allocation process
defined in [RFC7120]. Assignments consist of a digest algorithm defined in [RFC7120]. Assignments consist of a digest algorithm
skipping to change at page 7, line 19 skipping to change at page 7, line 19
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, February 2012. X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, January 2014. Points", BCP 100, RFC 7120, January 2014.
[SHS] National Institute of Standards and Technology (NIST), "FIPS [SHS] National Institute of Standards and Technology (NIST), "FIPS
Publication 180-3: Secure Hash Standard", FIPS Publication Publication 180-3: Secure Hash Standard", FIPS Publication
180-3, October 2008. 180-3, October 2008.
[ID.sidr-bgpsec-protocol] Lepinski, M., "BGPSEC Protocol [ID.sidr-bgpsec-protocol] Lepinski, M., "BGPsec Protocol
Specification", draft-ietf-sidr-bgpsec-protocol, work-in- Specification", draft-ietf-sidr-bgpsec-protocol, work-in-
progress. progress.
[ID.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile [ID.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile
for BGPSEC Router Certificates, Certificate Revocation for BGPSEC Router Certificates, Certificate Revocation
Lists, and Certification Requests", draft-ietf-sidr-bgpsec- Lists, and Certification Requests", draft-ietf-sidr-bgpsec-
pki-profiles, work-in-progress. pki-profiles, work-in-progress.
9.2. Informative References 9.2. Informative References
 End of changes. 27 change blocks. 
39 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/