< draft-ietf-sidr-bgpsec-algs-15.txt   draft-ietf-sidr-bgpsec-algs-16.txt >
Secure Inter-Domain Routing Working Group S. Turner Secure Inter-Domain Routing Working Group S. Turner
Internet-Draft IECA, Inc. Internet-Draft sn3rd
Updates: 6485bis (if approved) April 21, 2016 Updates: 7935 (if approved) November 14, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: October 23, 2016 Expires: May 18, 2017
BGPsec Algorithms, Key Formats, & Signature Formats BGPsec Algorithms, Key Formats, & Signature Formats
draft-ietf-sidr-bgpsec-algs-15 draft-ietf-sidr-bgpsec-algs-16
Abstract Abstract
This document specifies the algorithms, algorithm 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 (ID.sidr-rfc6485bis). Public Key Infrastructure (RFC 7935).
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 39 skipping to change at page 2, line 39
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 processing speakers (i.e., routers). CAs use these algorithms when processing
requests for BGPsec Router Certificates [ID.sidr-bgpsec-pki- requests for BGPsec Router Certificates [ID.sidr-bgpsec-pki-
profiles]. Examples when BGPsec routers use these algorithms include profiles]. Examples when BGPsec routers use these algorithms include
requesting BGPsec certificates [ID.sidr-bgpsec-pki-profiles], signing 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], and verifying
BGPsec Update messages [ID.sidr-bgpsec-protocol]. BGPsec Update messages [ID.sidr-bgpsec-protocol].
This document updates [ID.sidr-rfc6485bis] to add support for a) a This document updates [RFC7935] to add support for a) a different
different algorithm for BGPsec certificate requests, which are issued algorithm for BGPsec certificate requests, which are issued only by
only by BGPsec speakers; b) a different Subject Public Key Info BGPsec speakers; b) a different Subject Public Key Info format for
format for BGPsec certificates, which is needed for the specified BGPsec certificates, which is needed for the specified BGPsec
BGPsec signature algorithm; and, c) a different signature format for signature algorithm; and, c) a different signature format for BGPsec
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
The algorithms used to compute signatures on CA certificates, BGPsec The algorithms used to compute signatures on CA certificates, BGPsec
Router Certificates, and CRLs are as specified in Section 2 of Router Certificates, and CRLs are as specified in Section 2 of
[ID.sidr-rfc6485bis]. This section addresses BGPsec algorithms, for [RFC7935]. This section addresses BGPsec algorithms, for example
example these algorithms are used by BGPsec routers to request BGPsec these algorithms are used by BGPsec routers to request BGPsec
certificates, by RPKI CAs to verify BGPsec certification requests, by certificates, by RPKI CAs to verify BGPsec certification requests, by
BGPsec routers to generate BGPsec Update messages, and by BGPsec BGPsec routers to generate BGPsec Update messages, and by BGPsec
routers to verify BGPsec Update message: routers to verify BGPsec Update message:
o The signature algorithm used MUST be the Elliptic Curve Digital o The signature algorithm used MUST be the Elliptic Curve Digital
Signature Algorithm (ECDSA) with curve P-256 [RFC6090][DSS]. Signature Algorithm (ECDSA) with curve P-256 [RFC6090][DSS].
o The hash algorithm used MUST be SHA-256 [SHS]. o The hash algorithm used MUST be SHA-256 [SHS].
Hash algorithms are not identified by themselves in certificates or Hash algorithms are not identified by themselves in certificates or
BGPsec Update messages. They are represented by an OID that combines BGPsec Update messages. They are represented by an OID that combines
the hash algorithm with the digital signature algorithm as follows: the hash algorithm with the digital signature algorithm as follows:
o The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the PKCS #10 o The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the PKCS #10
signatureAlgorithm field [RFC2986] or in Certificate Request signatureAlgorithm field [RFC2986] or in Certificate Request
Message Format (CRMF) POPOSigningKey algorithm field [RFC4211], Message Format (CRMF) POPOSigningKey algorithm field [RFC4211],
which location depends on the certificate request format which location depends on the certificate request format
generated. 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 value 0x1 (see Section 7) is included in the
List's Algorithm Suite Identifier field. Signature-Block List's Algorithm Suite Identifier field.
3. Asymmetric Key Pair Formats 3. Asymmetric Key Pair Formats
The key formats used to compute signatures on CA certificates, BGPsec The key formats used to compute signatures on CA certificates, 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]. This section addresses key formats found in [RFC7935]. This section addresses key formats found in the BGPsec
the BGPsec router certificate requests and in BGPsec Router router certificate requests and in BGPsec Router Certificates.
Certificates.
The ECDSA private keys 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:
skipping to change at page 4, line 27 skipping to change at page 4, line 27
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], which is the same as specified in Section 4 of [RFC7935], which is the same format used
format used by other RPKI certificates. The structure for the by other RPKI certificates. The structure for the certification
certification request's and BGPsec Update message's signature field request's and BGPsec Update message's signature field MUST be as
MUST be as specified in Section 2.2.3 of [RFC3279]. 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. This profile should be updated to specify such future security. This profile should be updated to specify such future
requirements, when appropriate. requirements, when appropriate.
The recommended procedures to implement such a transition of key The recommended procedures to implement such a transition of key
sizes and algorithms is specified in [RFC6916]. sizes and algorithms is specified in [RFC6916].
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 [RFC7935], and [ID.sidr-bgpsec-pki-profiles] apply to certificates.
certificates. The security considerations of [RFC3279], [RFC6090], The security considerations of [RFC3279], [RFC6090], [RFC7935],
[ID.sidr-rfc6485bis], [ID.sidr-bgpsec-pki-profiles] apply to [ID.sidr-bgpsec-pki-profiles] apply to certification requests. The
certification requests. The security considerations of [RFC3279], security considerations of [RFC3279], [ID.sidr-bgpsec-protocol], and
[ID.sidr-bgpsec-protocol], and [RFC6090] apply to BGPsec Update [RFC6090] apply to BGPsec Update messages. No new security
messages. No new security considerations are introduced as a result considerations are introduced as a result of this specification.
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 in the Resource the "BGPsec Algorithm Suite Registry" in the Resource Public Key
Public Key Infrastructure (RPKI) group. Infrastructure (RPKI) group. The one-octet BGPsec Algorithm Suite
Registry identifiers assigned by IANA identifies the digest algorithm
and a signature algorithm used in the BGPsec Signature-Block List's
Algorithm Suite Identifier field.
An algorithm suite consists of a digest algorithm and a signature IANA is kindly requested to also register a single algorithm suite
algorithm. This specification creates an IANA registry of one-octet identifier, for the digest algorithm SHA-256 [SHS] and the signature
BGPsec algorithm suite identifiers. Additionally, this document algorithm ECDSA on the P-256 curve [RFC6090][DSS].
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 BGPsec Algorithm Suites Registry
Digest Signature Algorithm Specification Algorithm Digest Signature Specification
Algorithm Algorithm Suite Pointer Suite Algorithm Algorithm Pointer
Identifier Identifier
+-------------------------------------------------------+ +------------+------------+-------------+---------------------+
| Reserved | Reserved | 0x0 | This draft | | 0x0 | Reserved | Reserved | This draft |
+-------------------------------------------------------+ +------------+------------+-------------+---------------------+
| SHA-256 | ECDSA P-256 | TBD | RFC 5480 | | 0x1 | SHA-256 | ECDSA P-256 | [SHS][DSS][RFC6090] |
+-------------------------------------------------------+ +------------+------------+-------------+---------------------+
| Unassigned | Unassigned | TBD+1..0xE | This draft | | 0x2-0xE | Unassigned | Unassigned | This draft |
+-------------------------------------------------------+ +------------+------------+-------------+---------------------+
| Reserved | Reserved | 0xF | This draft | | 0xF | Reserved | Reserved | This draft |
+-------------------------------------------------------+ +------------+------------+-------------+---------------------+
Future assignments are to be made using either the Standards Action Future assignments are to be made using the Standards Action process
process defined in [RFC5226], or the Early IANA Allocation process defined in [RFC5226]. Assignments consist of the one-octet algorithm
defined in [RFC7120]. Assignments consist of a digest algorithm suite identifier value and the associated digest algorithm name and
name, signature algorithm name, and the algorithm suite identifier signature algorithm name.
value.
8. Acknowledgements 8. Acknowledgements
The author wishes to thank Geoff Huston and George Michaelson for The author wishes to thank Geoff Huston and George Michaelson for
producing [ID.sidr-rfc6485bis], which this document is entirely based producing [RFC7935], which this document is entirely based on. I'd
on. I'd also like to thank Roque Gagliano, David Mandelberg, Tom also like to thank Roque Gagliano, David Mandelberg, Tom Petch, Sam
Petch, Sam Weiller, and Stephen Kent for their reviews 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, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[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, DOI
November 2000. 10.17487/RFC2986, November 2000, <http://www.rfc-
editor.org/info/rfc2986>.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002. (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 2002,
<http://www.rfc-editor.org/info/rfc3279>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211, Certificate Request Message Format (CRMF)", RFC 4211, DOI
September 2005. 10.17487/RFC4211, September 2005, <http://www.rfc-
editor.org/info/rfc4211>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI
2008. 10.17487/RFC5226, May 2008, <http://www.rfc-
editor.org/info/rfc5226>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key "Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, March 2009. Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<http://www.rfc-editor.org/info/rfc5480>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011. Curve Cryptography Algorithms", RFC 6090, DOI
10.17487/RFC6090, February 2011, <http://www.rfc-
editor.org/info/rfc6090>.
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
Procedure for the Resource Public Key Infrastructure Procedure for the Resource Public Key Infrastructure
(RPKI)", BCP 182, RFC 6916, April 2013. (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
2013, <http://www.rfc-editor.org/info/rfc6916>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, January 2014.
[ID.sidr-rfc6485bis] Huston, G., and G. Michaelson, "The Profile for [RFC7935] Huston, G. and G. Michaelson, Ed., "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", RFC 7935, DOI 10.17487/RFC7935, August
progress. 2016, <http://www.rfc-editor.org/info/rfc7935>.
[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.
skipping to change at page 7, line 25 skipping to change at page 7, line 29
Department of Commerce, "Secure Hash Standard", FIPS Department of Commerce, "Secure Hash Standard", FIPS
Publication 180-4, August 2015. Publication 180-4, August 2015.
9.2. Informative References 9.2. Informative References
None. None.
Authors' Addresses Authors' Addresses
Sean Turner Sean Turner
IECA, Inc. sn3rd
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
EMail: turners@ieca.com EMail: sean@sn3rd.com
 End of changes. 29 change blocks. 
81 lines changed or deleted 83 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/