< draft-ietf-lsvr-l3dl-signing-01.txt		draft-ietf-lsvr-l3dl-signing-02.txt >
	Network Working Group R. Bush		Network Working Group R. Bush
	Internet-Draft Arrcus & IIJ		Internet-Draft Arrcus & IIJ
	Intended status: Standards Track R. Austein		Intended status: Standards Track R. Housley
	Expires: July 30, 2021 Arrcus		Expires: August 16, 2021 Vigil Security
	January 26, 2021		R. Austein
			Arrcus
			February 12, 2021
	Layer 3 Discovery and Liveness Signing		Layer-3 Discovery and Liveness Signing
	draft-ietf-lsvr-l3dl-signing-01		draft-ietf-lsvr-l3dl-signing-02
	Abstract		Abstract
	The Layer 3 Discovery and Liveness protocol OPEN PDU may contain a		The Layer-3 Discovery and Liveness protocol OPEN PDU may contain a
	key and a certificate, which can be used to verify signatures on		public key and a certificate, which can be used to verify signatures
	subsequent PDUs. This document describes two mechanisms based on		on subsequent PDUs. This document describes two mechanisms based on
	digital signatures, one that is Trust On First Use (TOFU), and one		digital signatures, one that is Trust On First Use (TOFU), and one
	that uses certificates to provide authentication as well as session		that uses a trust anchor signture over the public key to provide
	integrity.		authentication as well as session integrity.
	Requirements Language		Requirements Language
	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 BCP
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 30, 2021.		This Internet-Draft will expire on August 16, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	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. Trust On First Use Method . . . . . . . . . . . . . . . . . . 3		2. Signature Algorithm Identifiers . . . . . . . . . . . . . . . 3
	2.1. Signing a PDU . . . . . . . . . . . . . . . . . . . . . . 3		3. Trust On First Use Method . . . . . . . . . . . . . . . . . . 3
	2.2. Verifying the OPEN PDU . . . . . . . . . . . . . . . . . 4		3.1. Signing a PDU . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Verifying Other PDUs . . . . . . . . . . . . . . . . . . 4		3.2. Verifying the OPEN PDU . . . . . . . . . . . . . . . . . 4
	3. Public Key Infrastructure Method . . . . . . . . . . . . . . 5		3.3. Verifying Other PDUs . . . . . . . . . . . . . . . . . . 5
	3.1. Signing OPEN PDU with PKI . . . . . . . . . . . . . . . . 5		4. Public Key Infrastructure Method . . . . . . . . . . . . . . 5
	3.2. Verifying OPEN PDU with PKI . . . . . . . . . . . . . . . 5		4.1. Signing OPEN PDU with PKI . . . . . . . . . . . . . . . . 6
	4. Local Policy . . . . . . . . . . . . . . . . . . . . . . . . 6		4.2. Verifying OPEN PDU with PKI . . . . . . . . . . . . . . . 6
	5. NEWKEY, Key Roll . . . . . . . . . . . . . . . . . . . . . . 6		5. Local Policy . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. NEWKEY, Key Roll . . . . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	9. Normative References . . . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
			9.1. Normative References . . . . . . . . . . . . . . . . . . 9
			9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	This draft is being published without incorporating changes from an		The Layer-3 Discovery and Liveness protocol [I-D.ietf-lsvr-l3dl] OPEN
	excellent security review. This is being done so a couple of other		PDU contains an algorithm identifier, a key, and a L3DL certificate,
	drafts can reference it. While all comments will, of course, be		which can be used to verify signatures on subsequent PDUs. This
	appreciated, readers may want to wait for the -01 version.		document describes two methods of key generation and signing for use
			by L3DL, Trust On First Use (TOFU) and a PKI-based mechanism to
	The Layer 3 Discovery and Liveness protocol [I-D.ietf-lsvr-l3dl] OPEN		provide authentication as well as session integrity.
	PDU contains an algorithm identifier, a key, and a certificate, which
	can be used to verify signatures on subsequent PDUs. This document
	describes two methods of key generation and signing for use by L3DL,
	Trust On First Use (TOFU) and a PKI-based mechanism to provide
	authentication as well as session integrity.
	The Key in the OPEN PDU SHOULD be the public key of an asymmetric key		The Key in the OPEN PDU SHOULD be the public key of an asymmetric key
	pair. The sender signs with the private key, of course. The device		pair. The sender signs with the private key, of course. The device
	sending the OPEN may use one key for all links, a different key for		sending the OPEN PDU may use one key for all links, a different key
	each link, or some mix(s) thereof.		for each link, or some mix(es) thereof.
	In the TOFU method the key sent in the OPEN PDU is generated on the		In the TOFU method the key sent in the OPEN PDU is generated on the
	sending device, is believed without question by the receiver, and		sending device, is believed without question by the receiver, and
	used to verify all subsequent PDUs from the same sender with the same		used to verify all subsequent PDUs from the same sender with the same
	Key Algorithm.		public key and algorithm.
	With the PKI-mechanism, an enrollment step is performed. The public		With the PKI method, an enrollment step is performed. The public key
	key is put into a certificate [RFC5280], which is signed by the the		is signed by the the operational environment's trust anchor. In this
	operational environment's trust anchor. In this way, the relying		way, the relying party can be confident that the public key is under
	party can be confident that the public key is under control of the		control of the identified L3DL protocol entity.
	identified L3DL protocol entity.
			As part of enrollment or before hand, all relying parties must have
			received the trust anchor in an authentic manner.
	To the receiver verifying signatures on PDUs, the two methods are		To the receiver verifying signatures on PDUs, the two methods are
	indistinguishable; the key provided in the OPEN PDU is used to verify		indistinguishable; the key provided in the OPEN PDU is used to verify
	the signatures of subsequent PDUs. The difference that PKI-based		the signatures of subsequent PDUs. The difference that PKI-based
	keys may be verified against the trust anchor when the OPEN PDU is		keys may be verified against the trust anchor when the OPEN PDU is
	received.		received.
	In the PKI method the OPEN key MUST be verified against the trust		In the PKI method the public key in the OPEN PDU MUST be verified
	anchor for the operational domain. The OPEN key is then used to		against the trust anchor for the operational domain. The OPEN PDU
	verify all subsequent PDUs in the session.		public key is then used to verify all subsequent PDUs in the session.
			A mechanism for 'rolling' from the current public key to a fresh one
			is described in Section 6.
	2. Trust On First Use Method		2. Signature Algorithm Identifiers
			To avoid the creation of yet another IANA registry for digital
			signature algorithm identifiers, this specification makes use of the
			existing IANA registry for "DNS Security Algorithm Numbers" [IANA].
			In this registry, each signature algorithm is identified by an 8-bit
			value. The entries in this registry with "Y" in the "Zone Signing"
			column are appropriate for use with this protocol.
			For interoperability, all implementations of this protocol MUST
			support the RSASHA256 algorithm (identified by the value 8).
			Implementation MAY support any other registered "Zone Signing"
			signature algorithms.
			3. Trust On First Use Method
	There are three parts to using a key: signing PDUs, verifying the		There are three parts to using a key: signing PDUs, verifying the
	OPEN PDU, and verifying subsequent PDUs.		OPEN PDU, and verifying subsequent PDUs.
	2.1. Signing a PDU		3.1. Signing a PDU
	All signed PDUs are generated in the same way:		All signed PDUs are generated in the same way:
	o Compose the PDU, with all fields including "Sig Algo" and		o Compose the PDU, with all fields including "Sig Algo" and
	"Signature Length" set, but omitting the trailing "Signature"		"Signature Length" set, but omitting the trailing "Signature"
	field itself. The Certificate Length should be zero and the		field itself. The Certificate Length should be zero and the
	Certificate field should be empty. This is the "message to be		Certificate field should be empty. This is the "message to be
	signed" for purposes of the signature algorithm.		signed" for purposes of the signature algorithm.
	o Generate the signature as specified for the chosen signature		o Generate the signature as specified for the chosen algorithm,
	suite, using the private member of the asymmetric key pair. In		using the private key of the asymmetric key pair. In general,
	general this will involve first hashing the "message to be signed"		this will involve first hashing the "message to be signed" then
	then signing the hash, but the precise details may vary with the		signing the hash, but the precise details may vary with the
	specific algorithm. The result will be a sequence of octets, the		specific signature algorithm. The result will be a sequence of
	length of which MUST be equal to the setting of the "Signature		octets, the length of which MUST be equal to the value in the
	Length" field.		"Signature Length" field.
	o Construct the complete message by appending the signature octets		o Construct the complete message by appending the signature octets
	to the otherwise complete message composed above.		to the otherwise complete message composed above.
	In the case of the OPEN PDU, the message to be signed will include		In the case of the OPEN PDU, the message to be signed will include
	the public member of the asymmetric keypair, but as far as the		the public member of the asymmetric keypair, but as far as the
	signature algorithm is concerned that's just payload, no different		signature algorithm is concerned that's just payload, no different
	from any other PDU content.		from any other PDU content.
	2.2. Verifying the OPEN PDU		3.2. Verifying the OPEN PDU
	The process for verifying an OPEN PDU is slightly different from the		The process for verifying an OPEN PDU is slightly different from the
	process for verifying other PDU types, because the OPEN PDU also		process for verifying other PDU types, because the OPEN PDU also
	establishes the session key.		establishes the session key.
	o Verify that the PDU is syntactically correct, and extract the Auth		o Verify that the PDU is syntactically correct, and extract the Auth
	Type, Key, Sig Type, and Signature fields.		Type, Key, Sig Type, and Signature fields.
	o Verify that Auth Type and Sig Type refer to the same algorithm		o Verify that Auth Type and Sig Type refer to the same algorithm
	suite, and that said algorithm suite is one that the		suite, and that said algorithm suite is one that the
	skipping to change at page 4, line 40 ¶		skipping to change at page 5, line 11 ¶
	o Verify the message constructed above against the public key using		o Verify the message constructed above against the public key using
	the rules for the specific signature suite.		the rules for the specific signature suite.
	o Record Auth Type and Key as this sessions's authentication type		o Record Auth Type and Key as this sessions's authentication type
	and session key, for use in verifying subseuqent PDUs.		and session key, for use in verifying subseuqent PDUs.
	If any of the above verification steps fail, generate an error using		If any of the above verification steps fail, generate an error using
	error code 2 ("Authorization failure in OPEN").		error code 2 ("Authorization failure in OPEN").
	2.3. Verifying Other PDUs		3.3. Verifying Other PDUs
	The process for verifying non-OPEN PDUs is slightly simpler, but		The process for verifying non-OPEN PDUs is slightly simpler, but
	follows the same basic pattern as for OPEN PDUs.		follows the same basic pattern as for OPEN PDUs.
	o Verify that the PDU is syntactically correct, and extract the Sig		o Verify that the PDU is syntactically correct, and extract the Sig
	Type and Signature fields.		Type and Signature fields.
	o Verify that Sig Type refers to the same algorithm suite as the		o Verify that Sig Type refers to the same algorithm suite as the
	Auth Type recorded during verification of the OPEN PDU.		Auth Type recorded during verification of the OPEN PDU.
	o Construct the "message to be verified" by truncating the PDU to		o Construct the "message to be verified" by truncating the PDU to
	remove the Signature field.		remove the Signature field.
	o Verify the message constructed above against the recorded session		o Verify the message constructed above against the recorded session
	key using the rules for the specific signature suite.		key using the rules for the specific signature suite.
	If any of the above verification steps fail, generate an error using		If any of the above verification steps fail, generate an error using
	error code 3 ("Signature failure in PDU").		error code 3 ("Signature failure in PDU").
	3. Public Key Infrastructure Method		4. Public Key Infrastructure Method
	Using a PKI, [RFC5280], is almost the same as using TOFU, but with		Using a PKI is almost the same as using TOFU, but with one additional
	one additional step: during verification of an OPEN PDU, after		step: during verification of an OPEN PDU, after extracting the Key
	extracting the Key field from the PDU but before attempting to use it		field from the PDU but before attempting to use it to verify the OPEN
	to verify the PDU's signature, the receiver MUST verify the received		PDU signature, the receiver MUST verify the received key against the
	key against the PKI to confirm that it's an authorized key.		PKI to confirm that it's an authorized key.
	Generating an OPEN PDU using the PKI method requires a certificate,		Generating an OPEN PDU using the PKI method requires a certificate,
	which must be supplied via out of band configuration. The		which must be supplied via out of band configuration. The
	certificate is a signature of the public key to be sent in the Key		certificate is a signature of the public key to be sent in the Key
	field of the OPEN PDU, signed by the trust anchor private key.		field of the OPEN PDU, signed by the trust anchor private key.
	Verifying an OPEN PDU using the PKI method requires the public key of		Verifying an OPEN PDU using the PKI method requires the public key of
	the trust anchor, which the receiver uses to verify the certificate,		the trust anchor, which the receiver uses to verify the certificate,
	thereby demonstrating that the supplied is represents an authorized		thereby demonstrating that the supplied public key represents an
	L3DL speaker in this administrative domain.		authorized L3DL speaker in this administrative domain.
	We use the term "certificate" here in the generic sense. These are		We use the term "certificate" here in the generic sense, not as
	not X.509 certificates: X.509 is much more complicated than we need		defined in [RFC5280]. X.509 certificates are not used here; X.509
	for L3DL. The certificates used here are just signatures of one key		certificates are more complicated than needed for L3DL. The L3DL
	(the session key supplied in the Key field of the OPEN PDU) by		certificates are just signatures of one key (the public key supplied
	another key (the trust anchor).		in the Key field of the OPEN PDU) that can be verified by another
			trusted public key (the trust anchor).
	3.1. Signing OPEN PDU with PKI		4.1. Signing OPEN PDU with PKI
	Generating and signing the OPEN PDU with the PKI method is almost the		Generating and signing the OPEN PDU with the PKI method is almost the
	same as in Section 2.1. The only difference is that the PKI method		same as in Section 3.1. The only difference is that the PKI method
	MUST supply the appropriate certificate in the Certificate field.		MUST supply the appropriate certificate in the Certificate field.
	Note that the Auth Type field applies to both the Key and Certificate		Note that the Auth Type field applies to both the Key and Certificate
	fields. That is: the certificate uses the same certificate suite as		fields. That is: the certificate uses the same certificate suite as
	the session keys, L3DL does not support cross-algorithm-suite		the session keys, L3DL does not support cross-algorithm-suite
	certification.		certification.
	3.2. Verifying OPEN PDU with PKI		4.2. Verifying OPEN PDU with PKI
	Verifying the OPEN PDU with PKI is similar to verifying with TOFU as		Verifying the OPEN PDU with PKI is similar to verifying with TOFU as
	described in Section 2.2, but includes one critical extra step:		described in Section 3.2, but includes one critical extra step:
	After extracting the Key field from the PDU but before verifying the		After extracting the Key field from the PDU but before verifying the
	Signature, extract the Certificate field and verfiy that the		Signature, extract the Certificate field and verfiy that the
	Certificate is a valid signature of the Key field, according to the		Certificate is a valid signature of the Key field, according to the
	rules for the signature suite specified by Auth Type. If this step		rules for the signature suite specified by Auth Type. If this step
	fails, handle as in Section 2.2.		fails, handle as in Section 3.2.
	4. Local Policy		5. Local Policy
	Whether to use TOFU, PKI, or no signatures at all is a matter of		Whether to use TOFU, PKI, or no signatures at all is a matter of
	local policy, to be decided by the operator. The useful policy		local policy, to be decided by the operator. The useful policy
	combinations for Key and Certificate are probably:		combinations for Key and Certificate are probably:
	o Not signing: sender need not sign, receiver does not check.		o Not signing: sender need not sign, receiver does not check.
	o Require TOFU: sender MUST supply key and receiver MUST check,		o Require TOFU: sender MUST supply key and receiver MUST check, but
	certificate not needed and ignored if sent.		L3DL certificates not needed and ignored if sent.
	o Allow TOFU: sender must supply key and receiver MUST check,		o Allow TOFU: sender MUST supply key and receiver MUST check,
	receiver SHOULD check certificate if supplyed by sender.		receiver SHOULD check certificate if supplyed by sender.
	o Require PKI: sender MUST supply key and certificate, receiver MUST		o Require PKI: sender MUST supply key and L3DL certificate, receiver
	check both.		MUST check signature and verify the L3DL certificate.
	5. NEWKEY, Key Roll		6. NEWKEY, Key Roll
	Modern key management allows for agility in 'rolling' to a new key or		Modern key management allows for agility in 'rolling' to a new key or
	even algorithm in case of key expiry, key compromise, or merely		even algorithm in case of key expiry, key compromise, or merely
	prudence. Declaring a new key with an L3DL OPEN PDU would cause		prudence. Declaring a new key with an L3DL OPEN PDU would cause
	serious churn in topology as a new OPEN may cause a withdraw of		serious churn in topology as a new OPEN PDU may cause a withdraw of
	previously announced encapsulations. Therefore, a gentler rekeying		previously announced encapsulations. Therefore, a gentler rekeying
	is needed.		is needed.
			Prior to 'rolling' to a new key or new algorithm, a new public/
			private key pair is generated. If PKI is being used, then the trust
			anchor also signs the new public key to create a new L3DL
			certificate.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 8 | Payload Length | New Key Algor |		| Type = 8 | Payload Length | New Key Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| New Key Length | New Key ... |		| New Key Length | New Key ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | New Cert Length |		| | New Cert Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| New Certificate ... |		| New Certificate ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Old Sig Type | Old Signature Length | |		| Old Key Type | Old Signature Length | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	| Old Signature ... |		| Old Signature ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The New Key Type, New Key Length, New Key, New Cert Length, and New		The New Key Type, New Key Length, New Key, New Cert Length, and New
	Certificate field declare the replacement algorithm suite, key, and		Certificate fields declare the replacement algorithm, key, and L3DL
	certificate.		certificate.
	The NEWKEY PDU is signed using the current (soon to be old) algorithm		The NEWKEY PDU is signed using the current (soon to be old) algorithm
	suite and key.		and key.
	The sender and the receiver should be cautious of algorithm suite		The sender and the receiver should be cautious of signature algorithm
	downgrade attacks.		downgrade attacks.
	To avoid possible race conditions, the receiver SHOULD accept		To avoid possible race conditions, the receiver SHOULD accept
	signatures using either the new or old key for a configurable time		signatures using either the new or old key for a configurable time
	(default 30 seconds). This is intended to accommodate situations		(default 30 seconds). This is intended to accommodate situations
	such as senders with high peer out-degree and a single per-device		such as senders with high peer out-degree and a single per-device
	asymmetric key.		asymmetric key.
	If the sender does not receive an ACK in the normal window, including		If the sender does not receive an ACK in the normal window, including
	retransmission, then the sender MAY choose to allow a session reset		retransmission, then the sender MAY choose to allow a session reset
	by either issuing a new OPEN or by letting the receiver eventually		by either issuing a new OPEN PDU or by letting the receiver
	have a signature failure (error code 3) on a PDU.		eventually have a signature failure (error code 3) on a PDU.
	The rekeying operation changes the session key and algorithm suite		The rekeying operation changes the session key and the associated
	described in Section 2.3. The NEWKEY PDU itself is verified using		algorithm described in Section 3.3. The NEWKEY PDU itself is
	the old algorithm and session key, subsequent PDUs are verified with		verified using the old algorithm and session key. After the NEWKEY
	the new algorithm and session key recorded after the NEWKEY PDU has		PDU has been accepted, subsequent PDUs are verified with the new
	been accepted.		algorithm and the new session key.
	6. Security Considerations		7. Security Considerations
	The TOFU method requires a leap of faith to accept the key in the		The TOFU method requires a leap of faith to accept the key in the
	OPEN PDU, as it can not be verified against any authority. Hence it		OPEN PDU, as it can not be verified against any authority. Hence it
	is jokingly referred to as Married On First Date. The assurance it		is jokingly referred to as Married On First Date. The assurance it
	does provide is that subsequent signed PDUs are from the same peer.		does provide is that subsequent signed PDUs are from the same peer.
	And data integrity is a positive side effect of the signature		And data integrity is a positive side effect of the signature
	covering the payload.		covering the payload.
	The PKI-based method offers assurance that the certificate, and hence		The PKI method offers assurance that the L3DL certificate, and hence
	the keying material, provided in the OPEN PDU are authorized by a		the public key, provided in the OPEN PDU are authorized by a central
	central authority, e.g. the network's network security team. The		authority, e.g. the network's security team. The onward assurance of
	onward assurance of talking to the same peer and data integrity are		talking to the same peer and data integrity are the same as in the
	the same as in the TOFU method.		TOFU method.
	With the PKI-based method, automated device provisioning could		With the PKI method, automated device provisioning could restrict
	restrict which certificates are allowed from which peers on a per		which L3DL certificates are allowed from which peers on a per
	interface basis. This would complicate key rolls. Where one draws		interface basis. This would complicate key rolls. Where one draws
	the line between rigidity, flexibility, and security varies.		the line between rigidity, flexibility, and security varies.
	The REKEY PDU is open to abuse to create an algorithm suite downgrade		The REKEY PDU is open to abuse to create a signature algorithm
	attack.		downgrade attack.
	7. IANA Considerations		8. IANA Considerations
	This document requests the IANA create a new entry in the L3DL PDU		This document requests the IANA create a new entry in the L3DL PDU
	Type registry as follows:		Type registry as follows:
	PDU		PDU
	Code PDU Name		Code PDU Name
	---- -------------------		---- -------------------
	8 NEWKEY		8 NEWKEY
	This document requests the IANA add registry entries for "TOFU -		This document requests the IANA add registry entries for "TOFU -
	Trust On First Use" and "PKI" to the L3DL-Signature-Type registry as		Trust On First Use" and "PKI" to the L3DL-Signature-Type registry as
	follows:		follows:
	Number Name		Number Name
	------ -------------------		------ -------------------
	1 TOFU - Trust On First Use		1 TOFU - Trust On First Use
	2 PKI		2 PKI
	8. Acknowledgments		9. References
	The authors thank Russ Housley for advice and reviews.
	9. Normative References		9.1. Normative References
	[I-D.ietf-lsvr-l3dl]		[I-D.ietf-lsvr-l3dl]
	Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery		Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery
	and Liveness", draft-ietf-lsvr-l3dl-06 (work in progress),		and Liveness", draft-ietf-lsvr-l3dl-07 (work in progress),
	July 2020.		January 2021.
			[IANA] "DNS Security Algorithm Numbers",
			<https://www.iana.org/assignments/dns-sec-alg-numbers/dns-
			sec-alg-numbers.xhtml>.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			9.2. Informative References
	[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, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	Authors' Addresses		Authors' Addresses
	Randy Bush		Randy Bush
	Arrcus & IIJ		Arrcus & IIJ
	5147 Crystal Springs		5147 Crystal Springs
	Bainbridge Island, WA 98110		Bainbridge Island, WA 98110
	United States of America		United States of America
	Email: randy@psg.com		Email: randy@psg.com
			Russ Housley
			Vigil Security, LLC
			516 Dranesville Road
			Herndon, VA 20170
			USA
			Email: housley@vigilsec.com
	Rob Austein		Rob Austein
	Arrcus, Inc.		Arrcus, Inc.
	Email: sra@hactrn.net		Email: sra@hactrn.net
End of changes. 52 change blocks.
	118 lines changed or deleted		153 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/