draft-ietf-sidrops-rtr-keying-05.txt		draft-ietf-sidrops-rtr-keying-06.txt
	Network Working Group R. Bush		Network Working Group R. Bush
	Internet-Draft IIJ Lab / Dragon Research Lab		Internet-Draft IIJ Lab / Dragon Research Lab
	Intended status: Best Current Practice S. Turner		Intended status: Best Current Practice S. Turner
	Expires: October 13, 2019 sn3rd		Expires: November 15, 2019 sn3rd
	K. Patel		K. Patel
	Arrcus, Inc.		Arrcus, Inc.
	April 11, 2019		May 14, 2019
	Router Keying for BGPsec		Router Keying for BGPsec
	draft-ietf-sidrops-rtr-keying-05		draft-ietf-sidrops-rtr-keying-06
	Abstract		Abstract
	BGPsec-speaking routers are provisioned with private keys in order to		BGPsec-speaking routers are provisioned with private keys in order to
	sign BGPsec announcements. The corresponding public keys are		sign BGPsec announcements. The corresponding public keys are
	published in the global Resource Public Key Infrastructure, enabling		published in the global Resource Public Key Infrastructure, enabling
	verification of BGPsec messages. This document describes two methods		verification of BGPsec messages. This document describes two methods
	of generating the public-private key-pairs: router-driven and		of generating the public-private key-pairs: router-driven and
	operator-driven.		operator-driven.
	skipping to change at page 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 9		9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 9
	9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10		9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10
	9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 10		9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 10
	9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 11		9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 11
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 12		10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	12.1. Normative References . . . . . . . . . . . . . . . . . . 13		12.1. Normative References . . . . . . . . . . . . . . . . . . 13
	12.1. Informative References . . . . . . . . . . . . . . . . . 14		12.1. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. Management/Router Channel Security . . . . . . . . . 16		Appendix A. Management/Router Channel Security . . . . . . . . . 16
	Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 16		Appendix B. An Introduction to BGPsec Key Management . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	BGPsec-speaking routers are provisioned with private keys, which		BGPsec-speaking routers are provisioned with private keys, which
	allow them to digitally sign BGPsec announcements. To verify the		allow them to digitally sign BGPsec announcements. To verify the
	signature, the public key, in the form of a certificate [RFC8209], is		signature, the public key, in the form of a certificate [RFC8209], is
	published in the Resource Public Key Infrastructure (RPKI). This		published in the Resource Public Key Infrastructure (RPKI). This
	document describes provisioning of BGPsec-speaking routers with the		document describes provisioning of BGPsec-speaking routers with the
	appropriate public-private key-pairs. There are two methods, router-		appropriate public-private key-pairs. There are two methods, router-
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	A private key can be encapsulated in a PKCS#8 Asymmetric Key Package		A private key can be encapsulated in a PKCS#8 Asymmetric Key Package
	[RFC5958] and SHOULD be further encapsulated in Cryptographic Message		[RFC5958] and SHOULD be further encapsulated in Cryptographic Message
	Syntax (CMS) SignedData [RFC5652] and signed with the operators's End		Syntax (CMS) SignedData [RFC5652] and signed with the operators's End
	Entity (EE) private key.		Entity (EE) private key.
	The router SHOULD verify the signature of the encapsulated PKCS#8 to		The router SHOULD verify the signature of the encapsulated PKCS#8 to
	ensure the returned private key did in fact come from the operator,		ensure the returned private key did in fact come from the operator,
	but this requires that the operator also provision via the CLI or		but this requires that the operator also provision via the CLI or
	include in the SignedData the RPKI CA certificate and relevant		include in the SignedData the RPKI CA certificate and relevant
	operator's EE certificate(s). The router SHOULD inform the operator		operators' EE certificate(s). The router SHOULD inform the operator
	whether or not the signature validates to a trust anchor; this		whether or not the signature validates to a trust anchor; this
	notification mechanism is out of scope.		notification mechanism is out of scope.
	6. Send PKCS#10 and Receive PKCS#7		6. Send PKCS#10 and Receive PKCS#7
	The operator uses RPKI management tools to communicate with the		The operator uses RPKI management tools to communicate with the
	global RPKI system to have the appropriate CA validate the PKCS#10		global RPKI system to have the appropriate CA validate the PKCS#10
	certification request, sign the key in the PKCS#10 (i.e., certify it)		certification request, sign the key in the PKCS#10 (i.e., certify it)
	and generate a PKCS#7 certs-only message, as well as publishing the		and generate a PKCS#7 certs-only message, as well as publishing the
	certificate in the Global RPKI. External network connectivity may be		certificate in the Global RPKI. External network connectivity may be
	skipping to change at page 16, line 34 ¶		skipping to change at page 16, line 34 ¶
	Some routers support the use of public key certificates and SSH. The		Some routers support the use of public key certificates and SSH. The
	certificates used for the SSH session are different than the		certificates used for the SSH session are different than the
	certificates used for BGPsec. The certificates used with SSH should		certificates used for BGPsec. The certificates used with SSH should
	also enable a level of security at least as good as the security		also enable a level of security at least as good as the security
	offered by th BGPsec keys; x509v3-ecdsa-sha2-nistp256 [RFC6187] could		offered by th BGPsec keys; x509v3-ecdsa-sha2-nistp256 [RFC6187] could
	be used for authentication.		be used for authentication.
	The protected channel must provide confidentiality, authentication,		The protected channel must provide confidentiality, authentication,
	and integrity and replay protection.		and integrity and replay protection.
	Appendix B. The n00b Guide to BGPsec Key Management		Appendix B. An Introduction to BGPsec Key Management
	This appendix is informative. It attempts to explain some of the PKI		This appendix is informative. It attempts to explain some of the PKI
	lingo in plainer language.		lingo in plainer language.
	BGPsec speakers send signed BGPsec updates that are verified by other		BGPsec speakers send signed BGPsec updates that are verified by other
	BGPsec speakers. In PKI parlance, the senders are referred to as		BGPsec speakers. In PKI parlance, the senders are referred to as
	signers and the receivers are referred to as relying parties. The		signers and the receivers are referred to as relying parties. The
	signers with which we are concerned here are routers signing BGPsec		signers with which we are concerned here are routers signing BGPsec
	updates. Signers use private keys to sign and relying parties use		updates. Signers use private keys to sign and relying parties use
	the corresponding public keys, in the form of X.509 public key		the corresponding public keys, in the form of X.509 public key
	skipping to change at page 18, line 17 ¶		skipping to change at page 18, line 17 ¶
	CSR to the CA, is beyond the scope of this document. While you are		CSR to the CA, is beyond the scope of this document. While you are
	still connected to the router, install the Trust Anchor (TA) for the		still connected to the router, install the Trust Anchor (TA) for the
	root of the PKI. At this point, you no longer need access to the		root of the PKI. At this point, you no longer need access to the
	router for BGPsec-related initiation purposes.		router for BGPsec-related initiation purposes.
	The fourth step is for the CA to issue the certificate based on the		The fourth step is for the CA to issue the certificate based on the
	CSR you sent; the certificate will include the subject name, serial		CSR you sent; the certificate will include the subject name, serial
	number, public key, and other fields as well as being signed by the		number, public key, and other fields as well as being signed by the
	CA. After the CA issues the certificate, the CA returns the		CA. After the CA issues the certificate, the CA returns the
	certificate, and posts the certificate to the RPKI repository. Check		certificate, and posts the certificate to the RPKI repository. Check
	that the certificate corresponds to the pubic key contained in the		that the certificate corresponds to the public key contained in the
	certificate by verifying the signature on the CSR sent to the CA;		certificate by verifying the signature on the CSR sent to the CA;
	this is just a check to make sure that the CA issued a certificate		this is just a check to make sure that the CA issued a certificate
	that includes a public key that is the pair of the private key (i.e.,		that includes a public key that is the pair of the private key (i.e.,
	the math will work when verifying a signature generated by the		the math will work when verifying a signature generated by the
	private with the returned certificate).		private with the returned certificate).
	If generating the keys off-router (operator-driven), then the same		If generating the keys off-router (operator-driven), then the same
	steps are used as the on-router key generation, (possibly with the		steps are used as the on-router key generation, (possibly with the
	same arcane commands as those used in the on-router approach), but no		same arcane commands as those used in the on-router approach), but no
	access to the router is needed the first three steps are done on an		access to the router is needed the first three steps are done on an
End of changes. 7 change blocks.
	7 lines changed or deleted		7 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/