< draft-ietf-sidr-rtr-keying-15.txt		draft-ietf-sidr-rtr-keying-16.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: Standards Track S. Turner		Intended status: Standards Track S. Turner
	Expires: October 25, 2018 sn3rd		Expires: March 3, 2019 sn3rd
	K. Patel		K. Patel
	Arrcus, Inc.		Arrcus, Inc.
	April 23, 2018		August 30, 2018
	Router Keying for BGPsec		Router Keying for BGPsec
	draft-ietf-sidr-rtr-keying-15		draft-ietf-sidr-rtr-keying-16
	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 39 ¶		skipping to change at page 2, line 39 ¶
	5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 5		5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 5
	6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 6		6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 6
	7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 6		7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 6
	8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 7		8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 7
	9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 8		9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 8		9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 8
	9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9		9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
	9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9		9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9
	9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 10		9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 10
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 10		10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	12.1. Normative References . . . . . . . . . . . . . . . . . . 11		12.1. Normative References . . . . . . . . . . . . . . . . . . 12
	12.1. Informative References . . . . . . . . . . . . . . . . . 13		12.1. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Management/Router Channel Security . . . . . . . . . 14		Appendix A. Management/Router Channel Security . . . . . . . . . 15
	Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 15		Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	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 sub-methods,		appropriate public-private key-pairs. There are two sub-methods,
	router-driven and operator-driven.		router-driven and operator-driven.
	skipping to change at page 4, line 50 ¶		skipping to change at page 4, line 50 ¶
	Identifier [RFC4271] to be used in the generated router certificate.		Identifier [RFC4271] to be used in the generated router certificate.
	In the case where the operator has chosen not to use unique per-		In the case where the operator has chosen not to use unique per-
	router certificates, a BGP Identifier of 0 may be used.		router certificates, a BGP Identifier of 0 may be used.
	5. Generate PKCS#10		5. Generate PKCS#10
	The private key, and hence the PKCS#10 certification request, which		The private key, and hence the PKCS#10 certification request, which
	is sometimes referred to as a Certificate Signing Request (CSR), may		is sometimes referred to as a Certificate Signing Request (CSR), may
	be generated by the router or by the operator.		be generated by the router or by the operator.
			The PKCS#10 request SHOULD be saved to enable verifying that the
			returned public key in the certificate corresponds to the private
			used to generate the signature on the CSR.
	NOTE: The PKCS#10 certification request does not include the AS		NOTE: The PKCS#10 certification request does not include the AS
	number or the BGP Identifier for the router certificate. Therefore,		number or the BGP Identifier for the router certificate. Therefore,
	the operator transmits the AS it has chosen or the router and the BGP		the operator transmits the AS it has chosen or the router and the BGP
	Identifier as well when it sends the CSR to the CA.		Identifier as well when it sends the CSR to the CA.
	5.1. Router-Generated Keys		5.1. Router-Generated Keys
	In the router-generated method, once the protected channel is		In the router-generated method, once the protected channel is
	established and the initial Set-Up (Section 4) performed, the		established and the initial Set-Up (Section 4) performed, the
	operator issues a command or commands for the router to generate the		operator issues a command or commands for the router to generate the
	public/private key pair, to generate the PKCS#10 certification		public/private key pair, to generate the PKCS#10 certification
	request, and to sign the PKCS#10 certification request with the		request, and to sign the PKCS#10 certification request with the
	private key. Once generated, the PKCS#10 certification request is		private key. Once generated, the PKCS#10 certification request is
	returned to the operator over the protected channel.		returned to the operator over the protected channel.
	The operator includes the chosen AS number and the BPG Identifier		The operator includes the chosen AS number and the BGP Identifier
	when it sends the CSR to the CA.		when it sends the CSR to the CA.
	NOTE: If a router were to communicate directly with a CA to have the		NOTE: If a router were to communicate directly with a CA to have the
	CA certify the PKCS#10 certification request, there would be no way		CA certify the PKCS#10 certification request, there would be no way
	for the CA to authenticate the router. As the operator knows the		for the CA to authenticate the router. As the operator knows the
	authenticity of the router, the operator mediates the communication		authenticity of the router, the operator mediates the communication
	with the CA.		with the CA.
	5.2. Operator-Generated Keys		5.2. Operator-Generated Keys
	In the operator-generated method, the operator generates the		In the operator-generated method, the operator generates the
	public/private key pair on a management station and installs the		public/private key pair on a management station and installs the
	private key into the router over the protected channel. Beware that		private key into the router over the protected channel. Beware that
	experience has shown that copy and paste from a management station to		experience has shown that copy and paste from a management station to
	a router can be unreliable for long texts.		a router can be unreliable for long texts.
	The operator then creates and signs the PKCS#10 certification request		The operator then creates and signs the PKCS#10 certification request
	with the private key; the operator includes the chosen AS number and		with the private key; the operator includes the chosen AS number and
	the BPG Identifier when it sends the CSR to the CA.		the BGP Identifier when it sends the CSR to the CA.
			Even if the operator cannot extract the private key from the router,
			this signature still provides a linkage between a private key and a
			router. That is the operator can verify the proof of possession
			(POP), as required by [RFC6484].
	5.2.1. Using PKCS#8 to Transfer Private Key		5.2.1. Using PKCS#8 to Transfer Private Key
	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 AS's End Entity		Syntax (CMS) SignedData [RFC5652] and signed with the AS's End Entity
	(EE) private key.		(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,
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 38 ¶
	Global RPKI.		Global RPKI.
	2. Returns the certificate to the operator's management station,		2. Returns the certificate to the operator's management station,
	packaged in a PKCS#7 certs-only message, using the corresponding		packaged in a PKCS#7 certs-only message, using the corresponding
	method by which it received the certificate request. It SHOULD		method by which it received the certificate request. It SHOULD
	include the certificate chain below the TA Certificate so that		include the certificate chain below the TA Certificate so that
	the router can validate the router certificate.		the router can validate the router certificate.
	In the operator-generated method, the operator SHOULD extract the		In the operator-generated method, the operator SHOULD extract the
	certificate from the PKCS#7 certs-only message, and verify that the		certificate from the PKCS#7 certs-only message, and verify that the
	private key it holds corresponds to the returned public key.		private key it holds corresponds to the returned public key. If the
			operator saved the PKCS#10 it can check this correspondence by
			comparing the public key in the CSR to the public key in the returned
			certificate. If the operator has not saved the PKCS#10, it can check
			this correspondence by generating a signature on any data and then
			verifying the signature using the returned certificate.
	In the operator-generated method, the operator has already installed		In the operator-generated method, the operator has already installed
	the private key in the router (see Section 5.2).		the private key in the router (see Section 5.2).
	7. Install Certificate		7. Install Certificate
	The operator provisions the PKCS#7 certs-only message into the router		The operator provisions the PKCS#7 certs-only message into the router
	over the protected channel.		over the protected channel.
	The router SHOULD extract the certificate from the PKCS#7 certs-ony		The router SHOULD extract the certificate from the PKCS#7 certs-ony
	message and verify that the public key corresponds to the stored		message and verify that the public key corresponds to the stored
	private key. The router SHOULD inform the operator whether it		private key. If the router stored the PKCS#10, it can check this
			correspondence by comparing the public key in the CSR to the public
			key in the returned certificate. If the router did not store the
			PKCS#10, it can check this correspondence by generating a signature
			on any data and then verifying the signature using the returned
			certificate. The router SHOULD inform the operator whether it
	successfully received the certificate and whether or not the keys		successfully received the certificate and whether or not the keys
	correspond; the mechanism is out of scope.		correspond; the mechanism is out of scope.
	The router SHOULD also verify that the returned certificate validates		The router SHOULD also verify that the returned certificate validates
	back to the installed TA Certificate, i.e., the entire chain from the		back to the installed TA Certificate, i.e., the entire chain from the
	installed TA Certificate through subordinate CAs to the BGPsec		installed TA Certificate through subordinate CAs to the BGPsec
	certificate validate. To perform this verification the CA		certificate validate. To perform this verification the CA
	certificate chain needs to be returned along with the router's		certificate chain needs to be returned along with the router's
	certificate in the PKCS#7 certs-only message. The router SHOULD		certificate in the PKCS#7 certs-only message. The router SHOULD
	inform the operator whether or not the signature validates to a trust		inform the operator whether or not the signature validates to a trust
	anchor; this notification mechanism is out of scope.		anchor; this notification mechanism is out of scope.
	Even if the operator cannot extract the private key from the router,
	this signature still provides a linkage between a private key and a
	router. That is the operator can verify the proof of possession
	(POP), as required by [RFC6484].
	NOTE: The signature on the PKCS#8 and Certificate need not be made by		NOTE: The signature on the PKCS#8 and Certificate need not be made by
	the same entity. Signing the PKCS#8, permits more advanced		the same entity. Signing the PKCS#8, permits more advanced
	configurations where the entity that generates the keys is not the		configurations where the entity that generates the keys is not the
	direct CA.		direct CA.
	8. Advanced Deployment Scenarios		8. Advanced Deployment Scenarios
	More PKI-capable routers can take advantage of this increased		More PKI-capable routers can take advantage of this increased
	functionality and lighten the operator's burden. Typically, these		functionality and lighten the operator's burden. Typically, these
	routers include either pre-installed manufacturer-generated		routers include either pre-installed manufacturer-generated
	skipping to change at page 12, line 8 ¶		skipping to change at page 12, line 23 ¶
	This document has no IANA Considerations.		This document has no IANA Considerations.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.sidrops-bgpsec-rollover]		[I-D.sidrops-bgpsec-rollover]
	Weis, B, R. Gagliano, and K. Patel, "BGPsec Router		Weis, B, R. Gagliano, and K. Patel, "BGPsec Router
	Certificate Rollover", draft-ietf-sidrops-bgpsec-		Certificate Rollover", draft-ietf-sidrops-bgpsec-
	rollover (work in progress), October 2017.		rollover (work in progress), December 2017.
	[I-D.lamps-rfc5751-bis]		[I-D.lamps-rfc5751-bis]
	Schaad, J., Ramsdell, B, S. Turner,		Schaad, J., Ramsdell, B, S. Turner,
	"Secure/Multipurpose Internet Mail Extension (S/MIME)		"Secure/Multipurpose Internet Mail Extension (S/MIME)
	Version 4.0", draft-ietf-lamps-rfc5751-		Version 4.0", draft-ietf-lamps-rfc5751-
	bis (work in progress), April 2013.		bis (work in progress), July 2018.
	[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, DOI		Requirement Levels", BCP 14, RFC 2119, DOI
	10.17487/RFC2119, March 1997, <https://www.rfc-		10.17487/RFC2119, March 1997, <https://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005, <https://www.rfc-		DOI 10.17487/RFC4086, June 2005, <https://www.rfc-
	editor.org/info/rfc4086>.		editor.org/info/rfc4086>.
	skipping to change at page 17, line 5 ¶		skipping to change at page 17, line 18 ¶
	At this point, you no longer need access to the router for BGPsec-		At this point, you no longer need access to the router for BGPsec-
	related initiation purposes.		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 private key by verifying the		that the certificate corresponds to the private key by verifying the
	signature on the CSR sent to the CA; this is just a check to make		signature on the CSR sent to the CA; this is just a check to make
	sure that the CA issued a certificate corresponding to the private		sure that the CA issued a certificate that includes a public key that
	key on the router.		is the pair of the private key (i.e., the math will work when
			verifying a signature generated by the 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
	administrative workstation: o Step 1: Generate key pair; o Step 2:		administrative workstation: o Step 1: Generate key pair; o Step 2:
	Create CSR and sign CSR with private key, and; o Step 3: Send CSR		Create CSR and sign CSR with private key, and; o Step 3: Send CSR
	file with the subject name and serial number to CA.		file with the subject name and serial number to CA.
	After the CA has returned the certificate and you have checked the		After the CA has returned the certificate and you have checked the
End of changes. 15 change blocks.
	21 lines changed or deleted		37 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/