< draft-ietf-sidrops-rtr-keying-04.txt		draft-ietf-sidrops-rtr-keying-05.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: August 31, 2019 sn3rd		Expires: October 13, 2019 sn3rd
	K. Patel		K. Patel
	Arrcus, Inc.		Arrcus, Inc.
	February 27, 2019		April 11, 2019
	Router Keying for BGPsec		Router Keying for BGPsec
	draft-ietf-sidrops-rtr-keying-04		draft-ietf-sidrops-rtr-keying-05
	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 23 ¶		skipping to change at page 2, line 23 ¶
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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
	2. Management / Router Communication . . . . . . . . . . . . . . 4		2. Management / Router Communication . . . . . . . . . . . . . . 3
	3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4		3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4
	4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 5		5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 5
	5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 5		5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 5
	5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 6		5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 6
	5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 6		5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 6
	6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 7		6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 7
	7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 7		7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 7
	8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 8		8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 8
	9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 9		9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 9
	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 . . . . . . . . . . . . . . . . . . . 11		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 . . . . . . . . . 15		Appendix A. Management/Router Channel Security . . . . . . . . . 16
	Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 16		Appendix B. The n00b Guide 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-
	driven and operator-driven.		driven and operator-driven.
	These two methods differ in where the keys are generated: on the		These two methods differ in where the keys are generated: on the
	router in the router-driven method, and elsewhere in the		router in the router-driven method, and elsewhere in the
	operator-driven method. Routers are required to support at least one		operator-driven method.
	of the methods in order to work in various deployment environments.
	Some routers may not allow the private key to be exported while
	others may. While exporting private keys would ease swapping of
	routing engines, exposure of private keys is a well known security
	risk.
	In the operator-driven method, the operator generates the
	private/public key-pair and sends it to the router.
	In the router-driven method, the router generates its own		The two methods also differ in who generates the private/public key
	public/private key-pair.		pair: the operator generates the pair and sends it to the router in
			the operator-driven method, and the router generates its own pair in
			the router-drive method.
	The router-driven method mirrors the model used by traditional PKI		The router-driven method mirrors the model used by traditional PKI
	subscribers; the private key never leaves trusted storage (e.g.,		subscribers; the private key never leaves trusted storage (e.g.,
	Hardware Security Module). This is by design and supports classic		Hardware Security Module). This is by design and supports classic
	PKI Certification Policies for (often human) subscribers which		PKI Certification Policies for (often human) subscribers which
	require the private key only ever be controlled by the subscriber to		require the private key only ever be controlled by the subscriber to
	ensure that no one can impersonate the subscriber. For non-humans,		ensure that no one can impersonate the subscriber. For non-humans,
	this method does not always work. The operator-driven model is		this method does not always work. The operator-driven model is
	motivated by the extreme importance placed on ensuring the continued		motivated by the extreme importance placed on ensuring the continued
	operation of the network. In some deployments, the same private key		operation of the network. In some deployments, the same private key
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 4 ¶
	two end points (i.e., the management station and the router) and		two end points (i.e., the management station and the router) and
	acting as the intermediary. Section 8 describes another method that		acting as the intermediary. Section 8 describes another method that
	requires more capable routers.		requires more capable routers.
	Useful References: [RFC8205] describes details of BGPsec, [RFC8209]		Useful References: [RFC8205] describes details of BGPsec, [RFC8209]
	specifies the format for the PKCS#10 certification request, and		specifies the format for the PKCS#10 certification request, and
	[RFC8208] specifies the algorithms used to generate the PKCS#10		[RFC8208] specifies the algorithms used to generate the PKCS#10
	signature.		signature.
	2. Management / Router Communication		2. Management / Router Communication
	Operators are free to use either the router-driven or operator-driven		Operators are free to use either the router-driven or operator-driven
	method as supported by the platform. Prudent security practice		method as supported by the platform. Prudent security practice
	recommends router-generated keying, if the delay in replacing a		recommends router-generated keying, if the delay in replacing a
	router (or router engine) is acceptable to the operator. Regardless		router (or router engine) is acceptable to the operator. Regardless
	of the method chosen, operators first establish a protected channel		of the method chosen, operators first establish a protected channel
	between the management system and the router; this protected channel		between the management system and the router; this protected channel
	prevents eavesdropping, tampering, and message forgery as well as		prevents eavesdropping, tampering, and message forgery as well as
	provides mutual authentication. How this protected channel is		provides mutual authentication. How this protected channel is
	established is router-specific and is beyond scope of this document.		established is router-specific and is beyond scope of this document.
	Though other configuration mechanisms might be used, e.g. NETCONF		Though other configuration mechanisms might be used, e.g. NETCONF
	(see [RFC6470]), the protected channel used between the management		(see [RFC6470]), the protected channel used between the management
	platform and the router is assumed to be an SSH-protected CLI. See		platform and the router is assumed to be an SSH-protected CLI. See
	Appendix A for security considerations for this protected channel.		Appendix A for security considerations for this protected channel.
	The previous paragraph assumes the management system-to-router		The previous paragraph assumes the management system-to-router
	communications are over a network. When the management system has a		communications are over a network. When the management system has a
	direct physical connection to the router, e.g., via the craft port,		direct physical connection to the router, e.g., via the craft port,
	there is no assumption that there is a protected channel between the		there is no assumption that there is a protected channel between the
	two.		two.
			To be clear: for both of these methods, an initial leap-of-faith is
			required because the router has no keying material that it can use to
			protect communications with anyone or anything. Because of this
			initial leap of faith, a direct physical connection is safer than
			connecting via a network connection because there is less chance of a
			man in the middle. Once keying material is established on the
			router, the communications channel must prevent eavesdropping,
			tampering, and message forgery. This initial leap-of-faith will no
			longer be required once routers are delivered to operators with
			operator-trusted keying material
	3. Exchange Certificates		3. Exchange Certificates
	A number of options exist for the operator management station to		A number of options exist for the operator management station to
	exchange PKI-related information with routers and with the RPKI		exchange PKI-related information with routers and with the RPKI
	including:		including:
	- Using application/pkcs10 media type [RFC5967] to extract		- Using application/pkcs10 media type [RFC5967] to extract
	certificate requests and application/pkcs7-mime [I-D.lamps-rfc5751-		certificate requests and application/pkcs7-mime [I-D.lamps-rfc5751-
	bis] to return the issued certificate,		bis] to return the issued certificate,
	skipping to change at page 8, line 48 ¶		skipping to change at page 9, line 5 ¶
	the CA prior to operator initiating the router's CSR. CAs use		the CA prior to operator initiating the router's CSR. CAs use
	authentication material to determine whether the router is		authentication material to determine whether the router is
	eligible to receive a certificate. Authentication material at a		eligible to receive a certificate. Authentication material at a
	minimum includes the router's AS number and BGP Identifier as		minimum includes the router's AS number and BGP Identifier as
	well as the router's key material, but can also include		well as the router's key material, but can also include
	additional information. Authentication material can be		additional information. Authentication material can be
	communicated to the CA (i.e., CSRs signed by this key material		communicated to the CA (i.e., CSRs signed by this key material
	are issued certificates with this AS and BGP Identifier) or to		are issued certificates with this AS and BGP Identifier) or to
	the router (i.e., the operator uses the vendor-supplied		the router (i.e., the operator uses the vendor-supplied
	management interface to include the AS number and BGP Identifier		management interface to include the AS number and BGP Identifier
	in the router-generated CSR).		in the router-generated CSR). The CA stores this authentication
			material in an account entry for the router so that it can later
			be compared against the CSR prior to the CA issuing a certificate
			to the router.
	2. Enabling the router to communicate with the CA. While the		2. Enabling the router to communicate with the CA. While the
	router-to-CA communications are operator-initiated, the		router-to-CA communications are operator-initiated, the
	operator's management interface need not be involved in the		operator's management interface need not be involved in the
	communications path. Enabling the router-to-CA connectivity		communications path. Enabling the router-to-CA connectivity
	requires connections to external networks (i.e., through		requires connections to external networks (i.e., through
	firewalls, NATs, etc.).		firewalls, NATs, etc.).
	3. Ensuring the cryptographic chain of custody from the		3. Ensuring the cryptographic chain of custody from the
	manufacturer. For the pre-installed key material, the operator		manufacturer. For the pre-installed key material, the operator
	skipping to change at page 16, line 19 ¶		skipping to change at page 16, line 27 ¶
	security), do not use Triple DES (112 bits of security). Suggested		security), do not use Triple DES (112 bits of security). Suggested
	minimum algorithms would be AES-128: aes128-cbc [RFC4253] and		minimum algorithms would be AES-128: aes128-cbc [RFC4253] and
	AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-256 [RFC6668] or		AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-256 [RFC6668] or
	AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-sha2-nistp256		AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-sha2-nistp256
	[RFC5656] for authentication, and ecdh-sha2-nistp256 [RFC5656] for		[RFC5656] for authentication, and ecdh-sha2-nistp256 [RFC5656] for
	key exchange.		key exchange.
	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 commensurate with BGPsec keys;		also enable a level of security at least as good as the security
	x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for		offered by th BGPsec keys; x509v3-ecdsa-sha2-nistp256 [RFC6187] could
	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. The n00b Guide 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
End of changes. 13 change blocks.
	23 lines changed or deleted		30 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/