BGPsec Algorithms, Key Formats, & Signature Formats
draft-ietf-sidr-bgpsec-algs-14
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (sidr WG) | |
|---|---|---|---|
| Author | Sean Turner | ||
| Last updated | 2016-04-06 (Latest revision 2015-11-10) | ||
| Replaces | draft-turner-sidr-bgpsec-algs | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Reviews |
OPSDIR Telechat review
(of
-16)
Has Nits
SECDIR Last Call review
(of
-15)
Has Nits
OPSDIR Last Call review
(of
-15)
Has Nits
|
||
| Stream | WG state | WG Consensus: Waiting for Write-Up | |
| Document shepherd | Sandra L. Murphy | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | "Sandra L. Murphy" <sandy@tislabs.com> |
draft-ietf-sidr-bgpsec-algs-14
Secure Inter-Domain Routing Working Group S. Turner
Internet-Draft IECA, Inc.
Updates: 6485bis (if approved) November 10, 2015
Intended status: Standards Track
Expires: May 13, 2016
BGPsec Algorithms, Key Formats, & Signature Formats
draft-ietf-sidr-bgpsec-algs-14
Abstract
This document specifies the algorithms, algorithm parameters,
asymmetric key formats, asymmetric key size and signature format used
in BGPsec (Border Gateway Protocol Security). This document updates
the Profile for Algorithms and Key Sizes for use in the Resource
Public Key Infrastructure (ID.sidr-rfc6485bis).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Turner Expires May 13, 2016 [Page 1]
Internet-Draft BGPsec Algs, Key & Signature Formats November 10, 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Asymmetric Key Pair Formats . . . . . . . . . . . . . . . . . 3
3.1. Public Key Format . . . . . . . . . . . . . . . . . . . . 4
3.2. Private Key Format . . . . . . . . . . . . . . . . . . . . 4
4. Signature Format . . . . . . . . . . . . . . . . . . . . . . . 4
5. Additional Requirements . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This document specifies:
o the digital signature algorithm and parameters;
o the hash algorithm and parameters;
o the public and private key formats; and,
o the signature format
used by Resource Public Key Infrastructure (RPKI) Certification
Authorities (CA), and BGPsec (Border Gateway Protocol Security)
speakers (i.e., routers). CAs use these algorithms when processing
requests for BGPsec Router Certificates [ID.sidr-bgpsec-pki-
profiles]. BGPsec routers use these algorithms when requesting
BGPsec certificates [ID.sidr-bgpsec-pki-profiles], signing BGPsec
Update messages [ID.sidr-bgpsec-protocol], and verifying BGPsec
Update messages [ID.sidr-bgpsec-protocol].
This document is referenced by the BGPsec specification [ID.sidr-
bgpsec-protocol] and the profile for BGPsec Router Certificates and
Certification Requests [ID.sidr-bgpsec-pki-profiles]. Familiarity
with these documents is assumed. Implementers are reminded, however,
that, as noted in Section 2 of [ID.sidr-bgpsec-pki-profiles], the
algorithms used to sign CA Certificates, BGPsec Router Certificates,
and CRLs are found in [ID.sidr-rfc6485bis].
This document updates [ID.sidr-rfc6485bis] to add support for a) a
different algorithm for BGPsec certificate requests, which are issued
only by BGPsec speakers; b) a different Subject Public Key Info
format for BGPsec certificates, which is needed for the specified
Turner Expires May 13, 2016 [Page 2]
Internet-Draft BGPsec Algs, Key & Signature Formats November 10, 2015
BGPsec signature algorithm; and, c) a different signature format for
BGPsec signatures, which is needed for the specified BGPsec signature
algorithm. The BGPsec certificate are differentiated from other RPKI
certificates by the use of the BGPsec Extended Key Usage defined in
[ID.sidr-bgpsec-pki-profiles].
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2. Algorithms
The algorithms used to compute signatures on CA certificates, BGPsec
Router Certificates, and CRLs are as specified in Section 2 of
[ID.sidr-rfc6485bis]. The remainder of this section addresses
algorithms used when BGPsec routers request certificates, RPKI CAs
verify BGPsec certification requests, BGPsec routers generate BGPsec
Update messages, and when BGPsec routers verify BGPsec Update
messages:
o The signature algorithm used MUST be the Elliptic Curve Digital
Signature Algorithm (ECDSA) with curve P-256 [RFC6090][FIPS186].
o The hash algorithm used MUST be SHA-256 [SHS].
Hash algorithms are not identified by themselves in certificates or
BGPsec Update messages. They are represented by an OID that combines
the hash algorithm with the digital signature algorithm as follows:
o The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the PKCS #10
signatureAlgorithm field [RFC2986] or in Certificate Request
Message Format (CRMF) 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
Identifier from Section 7 is included in the Signature-Block
List's Algorithm Suite Identifier field.
3. Asymmetric Key Pair Formats
The key formats used to compute signatures on CA certificates, BGPsec
Router Certificates, and CRLs are as specified in Section 3 of
[ID.sidr-rfc6485bis]. The remainder of this section addresses key
formats found in the BGPsec router certificate requests and in BGPsec
Turner Expires May 13, 2016 [Page 3]
Internet-Draft BGPsec Algs, Key & Signature Formats November 10, 2015
Router Certificates.
The ECDSA private keys used to compute signatures for certificate
requests and BGPsec Update messages MUST come from the P-256 curve
[RFC5480]. The public key pair MUST use the uncompressed form.
3.1. Public Key Format
The Subject's public key is included in subjectPublicKeyInfo
[RFC5280]. It has two sub-fields: algorithm and subjectPublicKey.
The values for the structures and their sub-structures follow:
o algorithm (an AlgorithmIdentifier type): The id-ecPublicKey OID
MUST be used in the algorithm field, as specified in Section
2.1.1 of [RFC5480]. The value for the associated parameters MUST
be secp256r1, as specified in Section 2.1.1.1 of [RFC5480].
o subjectPublicKey: ECPoint MUST be used to encode the
certificate's subjectPublicKey field, as specified in Section 2.2
of [RFC5480].
3.2. Private Key Format
Local Policy determines private key format.
4. Signature Format
The structure for the certificate's and CRL's signature field MUST be
as specified in Section 4 of [ID.sidr-rfc6485bis], which is the same
format used by other RPKI certificates. The structure for the
certification request's and BGPsec Update message's signature field
MUST be as specified in Section 2.2.3 of [RFC3279].
5. Additional Requirements
It is anticipated that BGPsec will require the adoption of updated
key sizes and a different set of signature and hash algorithms over
time, in order to maintain an acceptable level of cryptographic
security. This profile should be updated to specify such future
requirements, when appropriate.
CAs and RPs SHOULD be capable of supporting a transition to allow for
the phased introduction of additional encryption algorithms and key
specifications, and also accommodate the orderly deprecation of
previously specified algorithms and keys [RFC6919]. Accordingly, CAs
and RPs SHOULD be capable of supporting multiple RPKI algorithm and
key profiles simultaneously within the scope of such anticipated
transitions. The recommended procedures to implement such a
Turner Expires May 13, 2016 [Page 4]
Internet-Draft BGPsec Algs, Key & Signature Formats November 10, 2015
transition of key sizes and algorithms are not specified in this
document, see Section 6 in [ID.sidr-bgpsec-protocol] for more
information.
6. Security Considerations
The Security Considerations of [RFC3279], [RFC5480], [RFC6090],
[ID.sidr-rfc6485bis], and [ID.sidr-bgpsec-pki-profiles] apply to
certificates. The security considerations of [RFC3279], [RFC6090],
[ID.sidr-rfc6485bis], [ID.sidr-bgpsec-pki-profiles] apply to
certification requests. The security considerations of [RFC3279],
[ID.sidr-bgpsec-protocol], and [RFC6090] apply to BGPsec Update
messages. No new security considerations are introduced as a result
of this specification.
7. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to define
the "BGPsec Algorithm Suite Registry" described below.
An algorithm suite consists of a digest algorithm and a signature
algorithm. This specification creates an IANA registry of one-octet
BGPsec algorithm suite identifiers. Additionally, this document
registers a single algorithm suite which uses the digest algorithm
SHA-256 and the signature algorithm ECDSA on the P-256 curve
[RFC5480].
BGPsec Algorithm Suites Registry
Digest Signature Algorithm Specification
Algorithm Algorithm Suite Pointer
Identifier
+-------------------------------------------------------+
| Reserved | Reserved | 0x0 | This draft |
+-------------------------------------------------------+
| SHA-256 | ECDSA P-256 | TBD | RFC 5480 |
+-------------------------------------------------------+
| Unassigned | Unassigned | TBD..0xF | This draft |
+-------------------------------------------------------+
| Reserved | Reserved | 0xF | This draft |
+-------------------------------------------------------+
Future assignments are to be made using either the Standards Action
process defined in [RFC5226], or the Early IANA Allocation process
defined in [RFC7120]. Assignments consist of a digest algorithm
name, signature algorithm name, and the algorithm suite identifier
value.
Turner Expires May 13, 2016 [Page 5]
Internet-Draft BGPsec Algs, Key & Signature Formats November 10, 2015
8. Acknowledgements
The author wishes to thank Geoff Huston and George Michaelson for
producing [ID.sidr-rfc6485bis], which this document is entirely based
on. I'd also like to thank Roque Gagliano, David Mandelberg, Sam
Weiler, and Stephen Kent for their reviews and comments.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
November 2000.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
September 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, March 2009.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, January 2014.
Turner Expires May 13, 2016 [Page 6]
Internet-Draft BGPsec Algs, Key & Signature Formats November 10, 2015
[SHS] National Institute of Standards and Technology (NIST), "FIPS
Publication 180-3: Secure Hash Standard", FIPS Publication
180-3, October 2008.
[ID.sidr-rfc6485bis] Huston, G., and G. Michaelson, "The Profile for
Algorithms and Key Sizes for use in the Resource Public Key
Infrastructure", draft-ietf-sidr-rfc6485bis, work-in-
progress.
[ID.sidr-bgpsec-protocol] Lepinski, M., "BGPsec Protocol
Specification", draft-ietf-sidr-bgpsec-protocol, work-in-
progress.
[ID.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile
for BGPSEC Router Certificates, Certificate Revocation
Lists, and Certification Requests", draft-ietf-sidr-bgpsec-
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
None.
Authors' Addresses
Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
EMail: turners@ieca.com
Turner Expires May 13, 2016 [Page 7]