< draft-housley-gigabeam-radio-link-encrypt-01.txt		draft-housley-gigabeam-radio-link-encrypt-02.txt >
	INTERNET DRAFT R. Housley (Vigil Security)		INTERNET DRAFT R. Housley (Vigil Security)
	Informational A. Corry (GigaBeam)		Informational A. Corry (GigaBeam)
	Expires December 2006 June 2006		Expires December 2006 June 2006
	GigaBeam High-Speed Radio Link Encryption		GigaBeam High-Speed Radio Link Encryption
	<draft-housley-gigabeam-radio-link-encrypt-01.txt>		<draft-housley-gigabeam-radio-link-encrypt-02.txt>
	Status of this Memo		Status of this Memo
	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		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	This document may not be modified, and derivative works of it may not		This document may not be modified, and derivative works of it may not
	be created, except to publish it as an RFC and to translate it into		be created, except to publish it as an RFC and to translate it into
	languages other than English.		languages other than English.
	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 a "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	Abstract		Abstract
	This document describes the encryption and key management used by		This document describes the encryption and key management used by
	skipping to change at page 11, line 42 ¶		skipping to change at page 11, line 42 ¶
	leaks the plaintext. The automated key management described here is		leaks the plaintext. The automated key management described here is
	intended to prevent this from ever happening.		intended to prevent this from ever happening.
	Since AES has a 128-bit block size, regardless of the mode employed,		Since AES has a 128-bit block size, regardless of the mode employed,
	the ciphertext generated by AES encryption becomes distinguishable		the ciphertext generated by AES encryption becomes distinguishable
	from random values after 2^64 blocks are encrypted with a single key.		from random values after 2^64 blocks are encrypted with a single key.
	Since the GigaBeam radio link frame allows for up to 2^40 fixed-		Since the GigaBeam radio link frame allows for up to 2^40 fixed-
	length frames in a single security association, there is no		length frames in a single security association, there is no
	possibility for more than 2^64 blocks to be encrypted with one key.		possibility for more than 2^64 blocks to be encrypted with one key.
			The lifetime of a particular key AES key can be shorter that 2^40
			frames. A smaller threshold can be used as a trigger to transition
			to the next key. This capability allows straightforward
			implementation of policies that require the key to be changed after a
			particular volume of traffic or a particular amount of time.
	There are fairly generic precomputation attacks against all block		There are fairly generic precomputation attacks against all block
	cipher modes that allow a meet-in-the-middle attack against the key.		cipher modes that allow a meet-in-the-middle attack against the key.
	These attacks require the creation and searching of huge tables of		These attacks require the creation and searching of huge tables of
	ciphertext associated with known plaintext and known keys. Assuming		ciphertext associated with known plaintext and known keys. Assuming
	that the memory and processor resources are available for a		that the memory and processor resources are available for a
	precomputation attack, then the theoretical strength of AES Counter		precomputation attack, then the theoretical strength of AES Counter
	mode (and any other block cipher mode) is limited to 2^(n/2) bits,		mode (and any other block cipher mode) is limited to 2^(n/2) bits,
	where n is the number of bits in the key. The use of long keys is		where n is the number of bits in the key. The use of long keys is
	the best countermeasure to precomputation attacks. The unpredictable		the best countermeasure to precomputation attacks. The unpredictable
	nonce value in the counter block significantly increases the size of		nonce value in the counter block significantly increases the size of
	the table that the attacker must compute to mount a successful		the table that the attacker must compute to mount a successful
	precomputation attack.		precomputation attack.
	Rekeying with Quick Mode results in new keys to protect GigaBeam		Rekeying with Quick Mode results in new keys to protect GigaBeam
	radio link frames; however, these keys are generated from the same		radio link frames; however, these keys are generated from the same
	Diffie-Hellman shared secret. In order to limit the amount of data		Diffie-Hellman shared secret. In order to limit the amount of data
	that would be exposed by the disclosure of this Diffie-Hellman shared		that would be exposed by the disclosure of this Diffie-Hellman shared
	secret or the associated Difffie-Hellman private key, implementations		secret or the associated Difffie-Hellman private key, implementations
	should periodically rekey using a new Phase 1 exchange. The number		should periodically rekey using a new Phase 1 exchange.
	of Quick Mode Exchanges between Phase 1 exchanges should not exceed
	48.
	Diffie-Hellman exponents used in IKE Phase 1 should be erased from		Diffie-Hellman exponents used in IKE Phase 1 should be erased from
	memory immediately after use.		memory immediately after use. Likewise, AES and HMAC-SHA-1 keying
			material should be erased from memory when it is no longer needed.
	This security solution makes use of IKEv1 [IKE]. IKEv1 was selected		This security solution makes use of IKEv1 [IKE]. IKEv1 was selected
	over IKEv2 [IKEv2] primarily due to the availability of an		over IKEv2 [IKEv2] primarily due to the availability of an
	implementation for the processing environment. The use of IKEv2		implementation for the processing environment. The use of IKEv2
	would provide some useful capabilities, such as Diffie-Hellman group		would provide some useful capabilities, such as Diffie-Hellman group
	negotiation. These additional capabilities are would not		negotiation. These additional capabilities are would not
	significantly improve the security of the overall key management		significantly improve the security of the overall key management
	solution that runs on the two-node IP network.		solution that runs on the two-node IP network.
	6. Informative References		6. Informative References
			[CBC] Dworkin, M., "Recommendation for Block Cipher Modes of
			Operation: Methods and Techniques," NIST Special
			Publication 800-38A, December 2001.
	[ESP] Kent, S. and R. Atkinson, "IP Encapsulating		[ESP] Kent, S. and R. Atkinson, "IP Encapsulating
	Security Payload (ESP)", RFC 2406, November 1998.		Security Payload (ESP)", RFC 2406, November 1998.
	[ESP-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC		[ESP-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
	Cipher Algorithm and Its Use with IPsec", RFC 3602,		Cipher Algorithm and Its Use with IPsec", RFC 3602,
	September 2003.		September 2003.
	[ESP-GCM] J. Viega, J., and D. McGrew, "The Use of		[ESP-GCM] J. Viega, J., and D. McGrew, "The Use of
	Galois/Counter Mode (GCM) in IPsec Encapsulating		Galois/Counter Mode (GCM) in IPsec Encapsulating
	Security Payload (ESP)", RFC 4106, June 2005.		Security Payload (ESP)", RFC 4106, June 2005.
	skipping to change at page 14, line 20 ¶		skipping to change at page 14, line 20 ¶
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
	EMail: housley <at> vigilsec <dot> com		EMail: housley <at> vigilsec <dot> com
	Alan Corry		Alan Corry
	GigaBeam Corporation		GigaBeam Corporation
	470 Springpark Place, Suite 900		470 Springpark Place, Suite 900
	Herndon, VA 20170		Herndon, VA 20170
	EMail: acorry <at> gigabeam <dot> com		EMail: acorry <at> gigabeam <dot> com
			Intellectual Property Rights Statement
			The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
			Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
End of changes. 7 change blocks.
	6 lines changed or deleted		39 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/