< draft-ietf-karp-crypto-key-table-06.txt		draft-ietf-karp-crypto-key-table-07.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: 20 August 2013 20 February 2013		Expires: 12 September 2013 12 March 2013
	Database of Long-Lived Symmetric Cryptographic Keys		Database of Long-Lived Symmetric Cryptographic Keys
	<draft-ietf-karp-crypto-key-table-06.txt>		<draft-ietf-karp-crypto-key-table-07.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 8, line 38 ¶		skipping to change at page 8, line 38 ¶
	A key is represented as a lower-case hexadecimal string with the most		A key is represented as a lower-case hexadecimal string with the most
	significant octet of the key first. As discussed in Section 2, the		significant octet of the key first. As discussed in Section 2, the
	length of this string depends on the associated algorithm and KDF.		length of this string depends on the associated algorithm and KDF.
	6. Operational Considerations		6. Operational Considerations
	If the valid periods for long-lived keys do not overlap or the system		If the valid periods for long-lived keys do not overlap or the system
	clocks are inconsistent, it is possible to construct scenarios where		clocks are inconsistent, it is possible to construct scenarios where
	systems cannot agree upon a long-lived key. When installing a series		systems cannot agree upon a long-lived key. When installing a series
	of keys to be used one after another (sometimes called a key chain),		of keys to be used one after another, operators should configure the
	operators should configure the SendLifetimeStart field of the key to		SendLifetimeStart field of the key to be several hours after the
	be several hours after the AcceptLifeTimeStart field of the key to		AcceptLifeTimeStart field of the key to guarantee there is some
	guarantee there is some overlap. This overlap is intended to address		overlap. This overlap is intended to address the clock skew issue and
	the clock skew issue and allow for basic operational considerations.		allow for basic operational considerations. Operators may choose to
	Operators may choose to specify a longer overlap (e.g., several		specify a longer overlap (e.g., several days) to allow for
	hours) to allow for exceptional circumstances.		exceptional circumstances.
	7. Security Considerations		7. Security Considerations
	Management of encryption and authentication keys has been a		Management of encryption and authentication keys has been a
	significant operational problem, both in terms of key synchronization		significant operational problem, both in terms of key synchronization
	and key selection. For instance, the current guidance [RFC3562]		and key selection. For instance, the current guidance [RFC3562]
	warns against sharing TCP MD5 keying material between systems, and		warns against sharing TCP MD5 keying material between systems, and
	recommends changing keys according to a schedule. The same general		recommends changing keys according to a schedule. The same general
	operational issues are relevant for the management of other		operational issues are relevant for the management of other
	cryptographic keys.		cryptographic keys.
End of changes. 3 change blocks.
	9 lines changed or deleted		9 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/