< draft-ietf-sidr-bgpsec-algs-12.txt   draft-ietf-sidr-bgpsec-algs-13.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: 6485bis (if approved) November 3, 2015 Updates: 6485bis (if approved) November 4, 2015
Intended status: BCP Intended status: Standards Track
Expires: May 6, 2016 Expires: May 7, 2016
BGPsec Algorithms, Key Formats, & Signature Formats BGPsec Algorithms, Key Formats, & Signature Formats
draft-ietf-sidr-bgpsec-algs-12 draft-ietf-sidr-bgpsec-algs-13
Abstract Abstract
This document specifies the algorithms, algorithms' parameters, This document specifies the algorithms, algorithm 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 (draft-ietf-sidr-rfc6485bis). Public Key Infrastructure (ID.sidr-rfc6485bis).
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
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Asymmetric Key Format . . . . . . . . . . . . . . . . . . . . 4 3. Asymmetric Key Pair Formats . . . . . . . . . . . . . . . . . 3
3.1. Public Key Format . . . . . . . . . . . . . . . . . . . . 4 3.1. Public Key Format . . . . . . . . . . . . . . . . . . . . 4
3.2. Private Key Format . . . . . . . . . . . . . . . . . . . . 4 3.2. Private Key Format . . . . . . . . . . . . . . . . . . . . 4
4. Signature Format . . . . . . . . . . . . . . . . . . . . . . . 4 4. Signature Format . . . . . . . . . . . . . . . . . . . . . . . 4
5. Additional Requirements . . . . . . . . . . . . . . . . . . . 4 5. Additional Requirements . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 processing
BGPsec Router Certificates [ID.sidr-bgpsec-pki-profiles] and CRLs requests for BGPsec Router Certificates [ID.sidr-bgpsec-pki-
[RFC6487]. BGPsec routers use these when requesting BGPsec profiles]. BGPsec routers use these algorithms when requesting
certificates [ID.sidr-bgpsec-pki-profiles], generating BGPsec Update BGPsec certificates [ID.sidr-bgpsec-pki-profiles], signing BGPsec
messages [ID.sidr-bgpsec-protocol], and verifying BGPsec Update Update messages [ID.sidr-bgpsec-protocol], and verifying BGPsec
messages [ID.sidr-bgpsec-protocol]. Update 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 [ID.sidr-rfc6485bis]. and CRLs are found in [ID.sidr-rfc6485bis].
This document updates [ID.sidr-rfc6485bis] to add support for a) a This document updates [ID.sidr-rfc6485bis] to add support for a) a
different algorithm for BGPsec certificate requests, which are only different algorithm for BGPsec certificate requests, which are issued
issued by BGPsec speakers; b) a different Subject Public Key Info only by BGPsec speakers; b) a different Subject Public Key Info
format for BGPsec certificates, which is needed for the specified format for 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 BGPsec 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: The algorithms used to compute signatures on CA certificates, BGPsec
Router Certificates, and CRLs are as specified in Section 2 of
o The signature algorithm used when issuing BGPsec certificates and [ID.sidr-rfc6485bis]. The remainder of this section addresses
CRLs, which would revoke BGPsec certificates, MUST be as algorithms used when BGPsec routers request certificates, RPKI CAs
specified in [ID.sidr-rfc6485bis]. verify BGPsec certification request, BGPsec routers generate BGPsec
Update messages, and when BGPsec routers verify BGPsec Update
o The signature algorithm used in certification requests and BGPsec messages:
Update messages MUST be Elliptic Curve Digital Signature
Algorithm (ECDSA) [RFC6090].
o The hashing algorithm used when issuing certificates and CRLs
MUST be as specified in [ID.sidr-rfc6485bis].
o The hashing algorithm used when generating certification requests
and BGPsec Update messages MUST be SHA-256 [SHS]. Hash
algorithms are not identified by themselves in certificates, or
BGPsec Update messages instead they are combined with the digital
signature algorithm (see below).
NOTE: The exception to the above hashing algorithm is the use of o The signature algorithm used MUST be the Elliptic Curve Digital
SHA-1 [SHS] when CAs generate authority and subject key Signature Algorithm (ECDSA) with curve P-256 [RFC6090][FIPS186].
identifiers [RFC6487].
To support BGPsec, the algorithms are identified as follows: o The hash algorithm used MUST be SHA-256 [SHS].
o In certificates and CRLs, an Object Identifier (OID) is used. Hash algorithms are not identified by themselves in certificates or
The value and locations are as specified in section 2 of BGPsec Update messages. They are represented by an OID that combines
[ID.sidr-rfc6485bis]. the hash algorithm with the digital signature algorithm as follows:
o In certification request, an OID is used. The ecdsa-with-SHA256 o The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the PKCS #10
OID [RFC5480] MUST appear in the PKCS #10 signatureAlgorithm signatureAlgorithm field [RFC2986] or in Certificate Request
field [RFC2986] or in Certificate Request Message Format (CRMF) Message Format (CRMF) POPOSigningKey algorithm field [RFC4211],
POPOSigningKey algorithm field [RFC4211]. which location depends on the certificate request format
generated.
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 Pair Formats
The RSA key pairs used to compute signatures on CA certificates, The key formats used to compute signatures on CA certificates, BGPsec
BGPsec Router Certificates, and CRLs are as specified in Section 3 of Router Certificates, and CRLs are as specified in Section 3 of
[ID.sidr-rfc6485bis]. The remainder of this section addresses key [ID.sidr-rfc6485bis]. The remainder of this section addresses key
formats found in the BGPsec router certificate requests and in BGPsec formats found in the BGPsec router certificate requests and in BGPsec
Router Certificates. Router Certificates.
The ECDSA key pairs used to compute signatures for certificate The ECDSA private keys 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 (an AlgorithmIdentifier type): The id-ecPublicKey OID
ecPublicKey OID MUST be used in the algorithm field, as specified MUST be used in the algorithm field, as specified in Section
in Section 2.1.1 of [RFC5480]. The value for the associated 2.1.1 of [RFC5480]. The value for the associated parameters MUST
parameters MUST be secp256r1, as specified in Section 2.1.1.1 of be secp256r1, as specified in Section 2.1.1.1 of [RFC5480].
[RFC5480].
o subjectPublicKey: ECPoint MUST be used to encode the o subjectPublicKey: ECPoint MUST be used to encode the
certificate's subjectPublicKey field, as specified in Section 2.2 certificate's subjectPublicKey field, as specified in Section 2.2
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 [ID.sidr-rfc6485bis]. The structure for as specified in Section 4 of [ID.sidr-rfc6485bis], which is the same
the certification request's and BGPsec Update message's signature format used by other RPKI certificates. The structure for the
field MUST be as specified in Section 2.2.3 of [RFC3279]. certification request's and BGPsec Update message's signature field
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. This profile should be updated to specify such future
updated to specify such future requirements, when appropriate. 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 [RFC6919]. Accordingly, CAs
SHOULD be capable of supporting multiple RPKI algorithm and key and RPs SHOULD be capable of supporting multiple RPKI algorithm and
profiles simultaneously within the scope of such anticipated key 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 are not specified in this transition of key sizes and algorithms are not specified in this
document, see Section 6 in [ID.sidr-bgpsec-protocol] for more document, see Section 6 in [ID.sidr-bgpsec-protocol] for more
information. information.
6. Security Considerations 6. Security Considerations
The Security Considerations of [RFC3279], [RFC5480], [RFC6090], The Security Considerations of [RFC3279], [RFC5480], [RFC6090],
[ID.sidr-rfc6485bis], and [ID.sidr-bgpsec-pki-profiles] apply to [ID.sidr-rfc6485bis], and [ID.sidr-bgpsec-pki-profiles] apply to
certificates. The security considerations of [RFC3279], [RFC6090], certificates. The security considerations of [RFC3279], [RFC6090],
skipping to change at page 6, line 17 skipping to change at page 6, line 7
+-------------------------------------------------------+ +-------------------------------------------------------+
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
name, signature algorithm name, and the algorithm suite identifier name, signature algorithm name, and the algorithm suite identifier
value. value.
8. Acknowledgements 8. Acknowledgements
The author wishes to thank Geoff Huston for producing [ID.sidr- The author wishes to thank Geoff Huston and George Michaelson for
rfc6485bis], which this document is heavily based on. I'd also like producing [ID.sidr-rfc6485bis], which this document is entirely based
to thank Roque Gagliano, David Mandelberg, and Sam Weiller for their on. I'd also like to thank Roque Gagliano, David Mandelberg, Sam
review and comments. Weiller, and Stephen Kent for their reviews and comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
skipping to change at page 7, line 25 skipping to change at page 7, line 14
[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-rfc6485bis] Huston, G., and G. Michaelson, "The Profile for [ID.sidr-rfc6485bis] Huston, G., and G. Michaelson, "The Profile for
Algorithms and Key Sizes for use in the Resource Public Key Algorithms and Key Sizes for use in the Resource Public Key
Infrastructure", draft-ietf-sidr-rfc6485bis, work-in- Infrastructure", draft-ietf-sidr-rfc6485bis, work-in-
progress. progress.
[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.
[FIPS-186-3] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard", FIPS
186-4, July 2013.
9.2. Informative References 9.2. Informative References
None. None.
Authors' Addresses Authors' Addresses
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106 3057 Nutley Street, Suite 106
Fairfax, VA 22031 Fairfax, VA 22031
 End of changes. 23 change blocks. 
67 lines changed or deleted 60 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/