< draft-ietf-karp-crypto-key-table-05.txt		draft-ietf-karp-crypto-key-table-06.txt >
	INTERNET-DRAFT R. Housley		INTERNET-DRAFT R. Housley
	Internet Engineering Task Force (IETF) Vigil Security		Internet Engineering Task Force (IETF) Vigil Security
	Intended Status: Standards Track T. Polk		Intended Status: Standards Track T. Polk
	NIST		NIST
	S. Hartman		S. Hartman
	Painless Security		Painless Security
	D. Zhang		D. Zhang
	Huawei		Huawei
	Expires: 14 August 2013 14 February 2013		Expires: 20 August 2013 20 February 2013
	Database of Long-Lived Symmetric Cryptographic Keys		Database of Long-Lived Symmetric Cryptographic Keys
	<draft-ietf-karp-crypto-key-table-05.txt>		<draft-ietf-karp-crypto-key-table-06.txt>
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	indication that the time is in UTC.		indication that the time is in UTC.
	AcceptLifeTimeEnd		AcceptLifeTimeEnd
	The AcceptLifeTimeEnd field specifies the latest date and time		The AcceptLifeTimeEnd field specifies the latest date and time
	at which this key should be considered for use when processing		at which this key should be considered for use when processing
	the received traffic. The format of this field is identical to		the received traffic. The format of this field is identical to
	the format of AcceptLifeTimeStart.		the format of AcceptLifeTimeStart.
	3. Key Selection and Rollover		3. Key Selection and Rollover
	A protocol may directly consult the key table to find the key		A protocol may directly consult the key table to find the key to use
	to use on an outgoing packet. The protocol provides a protocol		on an outgoing packet. The protocol provides a protocol (P) and a
	(P) and a peer identifier (H) into the key selection function.		peer identifier (H) into the key selection function. Optionally, an
	Optionally, an interface identifier (I) may also need to be		interface identifier (I) may also need to be provided. Any key that
	provided. Any key that satisfies the following conditions may		satisfies the following conditions may be selected:
	be selected:
	(1) the Peers field includes H;		(1) the Peers field includes H;
	(2) the Protocol field matches P;		(2) the Protocol field matches P;
	(3) If an interface is specified, the Interfaces field includes I		(3) If an interface is specified, the Interfaces field includes I
	or "all";		or "all";
	(4) the Direction field is either "out" or "both"; and		(4) the Direction field is either "out" or "both"; and
	skipping to change at page 7, line 8 ¶		skipping to change at page 7, line 4 ¶
	time in the SendLifetimeStart field.		time in the SendLifetimeStart field.
	In order to look up a key for verifying an incoming packet, the		In order to look up a key for verifying an incoming packet, the
	protocol provides its protocol (P), the peer identifier (H), the key		protocol provides its protocol (P), the peer identifier (H), the key
	identifier (L), and optionally the interface (I). If one key matches		identifier (L), and optionally the interface (I). If one key matches
	the following conditions it is selected:		the following conditions it is selected:
	(1) the Peer field includes H;		(1) the Peer field includes H;
	(2) the Protocol field matches P;		(2) the Protocol field matches P;
	(3) if the Interface field is provided, it includes I or is		(3) if the Interface field is provided, it includes I or is
	"all";		"all";
	(4) the Direction field is either "in" or "both";		(4) the Direction field is either "in" or "both";
	(5) the LocalKeyName is L; and		(5) the LocalKeyName is L; and
	(5) AcceptLifeTimeStart <= current time <= AcceptLifeTimeEnd.		(6) AcceptLifeTimeStart <= current time <= AcceptLifeTimeEnd.
	Note that the key usage is loosely bound by the times specified in		Note that the key usage is loosely bound by the times specified in
	the AcceptLifeTimeStart and AcceptLifeTimeEnd fields. New security		the AcceptLifeTimeStart and AcceptLifeTimeEnd fields. New security
	associations should not be established except within the period of		associations should not be established except within the period of
	use specified by these fields, while allowing some grace time for		use specified by these fields, while allowing some grace time for
	clock skew. However, if a security association has already been		clock skew. However, if a security association has already been
	established based on a particular long-lived key, exceeding the		established based on a particular long-lived key, exceeding the
	lifetime does not have any direct impact. The implementations of		lifetime does not have any direct impact. The implementations of
	security protocols that involve long-lived security association		security protocols that involve long-lived security association
	should be designed to periodically interrogate the database and		should be designed to periodically interrogate the database and
End of changes. 5 change blocks.
	10 lines changed or deleted		8 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/