< draft-housley-aes-key-wrap-with-pad-02.txt		draft-housley-aes-key-wrap-with-pad-03.txt >
	INTERNET DRAFT R. Housley		INTERNET DRAFT R. Housley
	Intended Status: Informational Vigil Security		Intended Status: Informational Vigil Security
	M. Dworkin		M. Dworkin
	NIST		NIST
	Expires: 24 September 2009 24 March 2009		Expires: 15 January 2010 15 June 2009
	Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm		Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm
	<draft-housley-aes-key-wrap-with-pad-02.txt>		<draft-housley-aes-key-wrap-with-pad-03.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 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of
	(http://trustee.ietf.org/license-info) in effect on the date of		publication of this document (http://trustee.ietf.org/license-info).
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document.
	to this document.
	Abstract		Abstract
	This document specifies a padding convention for use with the AES Key		This document specifies a padding convention for use with the AES Key
	Wrap algorithm specified in RFC 3394. This convention eliminates the		Wrap algorithm specified in RFC 3394. This convention eliminates the
	requirement that the length of the key to be wrapped is a multiple of		requirement that the length of the key to be wrapped is a multiple of
	64 bits, allowing a key of any practical length to be wrapped.		64 bits, allowing a key of any practical length to be wrapped.
	1. Introduction		1. Introduction
	Management of cryptographic keys often leads to situations where a		Management of cryptographic keys often leads to situations where a
	symmetric key is used to encrypt and integrity protect another key,		symmetric key is used to encrypt and integrity protect another key,
	which can be either a symmetric key or an asymmetric key. The		which can be either a symmetric key or an asymmetric key. The
	operation is often called key wrapping.		operation is often called key wrapping.
	This document specifies an extension of the Advanced Encryption		This document specifies an extension of the Advanced Encryption
	Standard (AES) Key Wrap algorithm [AES-KW1,AES-KW2]. Without this		Standard (AES) Key Wrap algorithm [AES-KW1,AES-KW2]. Without this
	extension, the input to the AES Key Wrap algorithm, called the key		extension, the input to the AES Key Wrap algorithm, called the key
	data, must be a sequence of two or more 64-bit blocks.		data, must be a sequence of two or more 64-bit blocks.
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 26 ¶
	must be 128, 192, or 256 bits. The input key data may be as short as		must be 128, 192, or 256 bits. The input key data may be as short as
	9 octets, which will result in an output of two 64-bit blocks or 16		9 octets, which will result in an output of two 64-bit blocks or 16
	octets. Although the AES Key Wrap algorithm does not place a maximum		octets. Although the AES Key Wrap algorithm does not place a maximum
	bound on the size of the key data that can be wrapped, this extension		bound on the size of the key data that can be wrapped, this extension
	does so. The use of a 32-bit fixed field to carry the octet length		does so. The use of a 32-bit fixed field to carry the octet length
	of the key data bounds the size of the input at 2^32 octets. Most		of the key data bounds the size of the input at 2^32 octets. Most
	systems will have other factors that limit the practical size of key		systems will have other factors that limit the practical size of key
	data to much less than 2^32 octets.		data to much less than 2^32 octets.
	A message length indicator (MLI) is defined as part of an		A message length indicator (MLI) is defined as part of an
	"Alternative Initial Value" in keeping with the statement in 2.2.3.2		"Alternative Initial Value" in keeping with the statement in section
	of [AES-KW1], which says:		2.2.3.2 of [AES-KW1], which says:
	Also, if the key data is not just an AES key, it may not always be		Also, if the key data is not just an AES key, it may not always be
	a multiple of 64 bits. Alternative definitions of the initial		a multiple of 64 bits. Alternative definitions of the initial
	value can be used to address such problems.		value can be used to address such problems.
	2. Notation and Definitions		2. Notation and Definitions
	The following notation is used in the algorithm descriptions:		The following notation is used in the algorithm descriptions:
	MSB(j, W) Return the most significant j bits of W		MSB(j, W) Return the most significant j bits of W
	LSB(j, W) Return the least significant j bits of W		LSB(j, W) Return the least significant j bits of W
	B1 | B2 Concatenate B1 and B2		B1 | B2 Concatenate B1 and B2
	K The key-encryption key		K The key-encryption key
	m The number of octets in the key data		m The number of octets in the key data
	n The number of 64-bit blocks in the padded key data		n The number of 64-bit blocks in the padded key data
	Q[i] The ith plaintext octet in the key data		Q[i] The ith plaintext octet in the key data
	P[i] The ith 64-bit plaintext block in the padded key data		P[i] The ith 64-bit plaintext block in the padded key data
	C[i] The ith 64-bit ciphertext data block		C[i] The ith 64-bit ciphertext data block
	A The 64-bit integrity check register		A The 64-bit integrity check register
	3. Alternative Initial Value		3. Alternative Initial Value
	The Alternative Initial Value (AIV) required by this specification is		The Alternative Initial Value (AIV) required by this specification is
	a 32-bit constant concatenated to a 32-bit MLI. The constant is (in		a 32-bit constant concatenated to a 32-bit MLI. The constant is (in
	hexadecimal) A65959A6 and occupies the high-order half of the AIV.		hexadecimal) A65959A6 and occupies the high-order half of the AIV.
	Note that this differs from the high order 32 bits of the default IV		Note that this differs from the high order 32 bits of the default IV
	in [AES-KW1] Section 2.2.3.1, so there is no ambiguity between the		in [AES-KW1] Section 2.2.3.1, so there is no ambiguity between the
	two. The 32-bit MLI, which occupies the low-order half of the AIV,		two. The 32-bit MLI, which occupies the low-order half of the AIV,
	is an unsigned binary integer equal to the octet length of the		is an unsigned binary integer equal to the octet length of the
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 38 ¶
	2) Wrapping		2) Wrapping
	Apply the wrapping process specified in Section 2.2.1 of		Apply the wrapping process specified in Section 2.2.1 of
	[AES-KW2] to the padded plaintext {P1, ..., Pn} and K (the KEK),		[AES-KW2] to the padded plaintext {P1, ..., Pn} and K (the KEK),
	with the AIV as defined in Section 3 above as the initial value.		with the AIV as defined in Section 3 above as the initial value.
	The result is n+1 64-bit blocks {C0, C1, ..., Cn}.		The result is n+1 64-bit blocks {C0, C1, ..., Cn}.
	4.2 Extended Key Unwrapping Process		4.2 Extended Key Unwrapping Process
	The inputs to the extended key unwrapping process are the KEK and n+1		The inputs to the extended key unwrapping process are the KEK and
	64-bit ciphertext blocks consisting of a previously wrapped key. If		(n+1) 64-bit ciphertext blocks consisting of a previously wrapped
	the ciphertext is a validly wrapped key, then the (original)		key. If the ciphertext is a validly wrapped key, then the (original)
	unwrapping process returns n 64-bit plaintext blocks, which are then		unwrapping process returns n 64-bit plaintext blocks, which are then
	mapped in this extension to m octets of decrypted key data, as		mapped in this extension to m octets of decrypted key data, as
	indicated by the MLI embedded in the AIV.		indicated by the MLI embedded in the AIV.
	Inputs: Ciphertext, (n+1) 64-bit blocks {C0, C1, ..., Cn}, and		Inputs: Ciphertext, (n+1) 64-bit blocks {C0, C1, ..., Cn}, and
	Key, K (the KEK).		Key, K (the KEK).
	Outputs: Plaintext, m octets {Q1, Q2, ..., Qm}, or an error.		Outputs: Plaintext, m octets {Q1, Q2, ..., Qm}, or an error.
	1) Key unwrapping		1) Key unwrapping
	Apply Steps 1 and 2 of the unwrapping process specified in		Apply Steps 1 and 2 of the unwrapping process specified in
	Section 2.2.2 of [AESKW2] to the n+1 64-bit ciphertext blocks,		Section 2.2.2 of [AES-KW2] to the n+1 64-bit ciphertext blocks,
	{C0, C1, ..., Cn}, and the KEK, K. Define the padded plaintext		{C0, C1, ..., Cn}, and the KEK, K. Define the padded plaintext
	blocks, {P1, ..., Pn}, as specified in Step 3 of that process,		blocks, {P1, ..., Pn}, as specified in Step 3 of that process,
	with A[0] as the A value. Note that checking "If A[0] is an		with A[0] as the A value. Note that checking "If A[0] is an
	appropriate value" is slightly delayed to Step 2 below since the		appropriate value" is slightly delayed to Step 2 below since the
	padded plaintext is needed to perform this verification when the		padded plaintext is needed to perform this verification when the
	AIV is used.		AIV is used.
	2) AIV verification		2) AIV verification
	Perform the three checks described in Section 3 above on the		Perform the three checks described in Section 3 above on the
	skipping to change at page 6, line 7 ¶		skipping to change at page 6, line 7 ¶
	nistAlgorithm(4) 1 }		nistAlgorithm(4) 1 }
	id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }		id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
	id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 }		id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 }
	id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }		id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
	id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 }		id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 }
	id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }		id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }
	id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 }		id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 }
	In all cases, the AlgorithmIdentifier parameter field must be absent.		In all cases, the AlgorithmIdentifier parameter field MUST be absent.
	6. Padded Key Wrap Example		6. Padded Key Wrap Example
	The example in this section was generated using the index-based		The example in this section was generated using the index-based
	implementation of the AES Key Wrap algorithm along with the padding		implementation of the AES Key Wrap algorithm along with the padding
	approach specified in Section 4 of this document. The example wraps		approach specified in Section 4 of this document. The example wraps
	20 octets of Key Data with a 192-bit KEK. All values are shown in		20 octets of Key Data with a 192-bit KEK. All values are shown in
	hexadecimal.		hexadecimal.
	KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8		KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 31 ¶
	Wrap : 138bdeaa9b8fa7fc 61f97742e72248ee 5ae6ae5360d1ae6a		Wrap : 138bdeaa9b8fa7fc 61f97742e72248ee 5ae6ae5360d1ae6a
	: 5f54f373fa543b6a		: 5f54f373fa543b6a
	7. Security Considerations		7. Security Considerations
	Implementations must protect the key-encryption key (KEK).		Implementations must protect the key-encryption key (KEK).
	Compromise of the KEK may result in the disclosure of all keys that		Compromise of the KEK may result in the disclosure of all keys that
	have been wrapped with the KEK, which may lead to the compromise of		have been wrapped with the KEK, which may lead to the compromise of
	all traffic protected with those wrapped keys.		all traffic protected with those wrapped keys.
			The KEK must be at least as good as the keying material it is
			protecting.
	If the KEK and wrapped key are associated with different		If the KEK and wrapped key are associated with different
	cryptographic algorithms, the effective security provided to data		cryptographic algorithms, the effective security provided to data
	protected with the wrapped key is determined by the weaker of the two		protected with the wrapped key is determined by the weaker of the two
	algorithms. If, for example, data is encrypted with 128-bit AES and		algorithms. If, for example, data is encrypted with 128-bit AES and
	that AES key is wrapped with a 256-bit AES key, then at most 128 bits		that AES key is wrapped with a 256-bit AES key, then at most 128 bits
	of protection is provided to the data. If, for another example, a		of protection is provided to the data. If, for another example, a
	128-bit AES key is used to wrap a 4096-bit RSA private key, then at		128-bit AES key is used to wrap a 4096-bit RSA private key, then at
	most 128 bits of protection is provided to any data that depends on		most 128 bits of protection is provided to any data that depends on
	that private key. Thus, implementers must ensure that key-encryption		that private key. Thus, implementers must ensure that key-encryption
	algorithms are as strong or stronger than other cryptographic		algorithms are as strong or stronger than other cryptographic
	skipping to change at page 7, line 22 ¶		skipping to change at page 7, line 25 ¶
	octets of key data. In particular, if the key data consists of eight		octets of key data. In particular, if the key data consists of eight
	or fewer octets, then a 64-bit integrity check value could be		or fewer octets, then a 64-bit integrity check value could be
	prepended to the key data to form a single 128-bit block. For		prepended to the key data to form a single 128-bit block. For
	example, the integrity check value could consist of a fixed seven		example, the integrity check value could consist of a fixed seven
	octet value followed by a single octet length value. The wrapping		octet value followed by a single octet length value. The wrapping
	and unwrapping processes employing such an integrity check value and		and unwrapping processes employing such an integrity check value and
	a single AES codebook operation could be defined analogous to those		a single AES codebook operation could be defined analogous to those
	in Section 4 if there is a need to wrap keys that are smaller than		in Section 4 if there is a need to wrap keys that are smaller than
	nine octets.		nine octets.
	8. References		In the design of some high assurance cryptographic modules, it is
			desirable to segregate cryptographic keying material from other data.
			The use of a specific cryptographic mechanism solely for the
			protection of cryptographic keying material can assist in this goal.
			The AES Key Wrap and the AES Key Wrap with Pad are such mechanisms.
			System designers should not use these algorithms to encrypt anything
			other than cryptographic keying material.
	8.1. Normative References		8. IANA Considerations
	AES National Institute of Standards and Technology. FIPS Pub		No IANA actions are required.
			{{{ RFC Editor: Please remove this section prior to publication. }}}
			9. References
			9.1. Normative References
			[AES] National Institute of Standards and Technology. FIPS Pub
	197: Advanced Encryption Standard (AES). 26 November 2001.		197: Advanced Encryption Standard (AES). 26 November 2001.
	AES-KW1 National Institute of Standards and Technology. AES Key		[AES-KW1] National Institute of Standards and Technology. AES Key
	Wrap Specification. 17 November 2001.		Wrap Specification. 17 November 2001.
	[http://csrc.nist.gov/encryption/kms/key-wrap.pdf]		[http://csrc.nist.gov/groups/ST/toolkit/documents/kms/
			AES_key_wrap.pdf]
	AES-KW2 J. Schaad and R. Housley, "Advanced Encryption Standard		[AES-KW2] J. Schaad and R. Housley, "Advanced Encryption Standard
	(AES) Key Wrap Algorithm", RFC 3394, September 2002.		(AES) Key Wrap Algorithm", RFC 3394, September 2002.
	X.680 ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,		[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
	Information technology - Abstract Syntax Notation One		Information technology - Abstract Syntax Notation One
	(ASN.1): Specification of basic notation.		(ASN.1): Specification of basic notation.
	8.2. Informative References		9.2. Informative References
	OLD-KW J. Schaad and R. Housley, "Wrapping a Hashed Message		[AES-CMS] J. Schaad, "Use of the Advanced Encryption Standard (AES)
			Encryption Algorithm in Cryptographic Message Syntax
			(CMS)", RFC 3565, July 2003.
			[CMS-ASN] J. Schaad and P. Hoffman, "New ASN.1 Modules for CMS and
			S/MIME", draft-smime-newasn1-05.txt, work-in-progress.
			[OLD-KW] J. Schaad and R. Housley, "Wrapping a Hashed Message
	Authentication Code (HMAC) key with a Triple-Data		Authentication Code (HMAC) key with a Triple-Data
	Encryption Standard (DES) Key or an Advanced		Encryption Standard (DES) Key or an Advanced
	Encryption Standard (AES) Key", RFC 3537, May 2003.		Encryption Standard (AES) Key", RFC 3537, May 2003.
	9. Acknowledgments		[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002,
			Information Technology - Abstract Syntax Notation One:
			Information Object Specification.
			[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002,
			Information Technology - Abstract Syntax Notation One:
			Constraint Specification.
			[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002,
			Information Technology - Abstract Syntax Notation One:
			Parameterization of ASN.1 Specifications.
			10. Acknowledgments
	Paul Timmel should be credited with the MLI and padding technique		Paul Timmel should be credited with the MLI and padding technique
	described in this document.		described in this document.
	Authors Addresses		Appendix A: ASN.1 Modules
			This appendix includes two ASN.1 modules. The first one makes use of
			the 1988 syntax, and the second one makes use of the 2002 ASN.1
			syntax.
			Appendix A.1 provides the normative ASN.1 definitions for the
			algorithm identifiers included in this specification using ASN.1 as
			defined in [X.680] using the 1988 ASN.1 syntax.
			Appendix A.2 provides informative ASN.1 definitions for the algorithm
			identifiers included in this specification using ASN.1 as defined in
			[X.680], [X.681], [X.682], and [X.683] using the 2002 ASN.1 syntax.
			This appendix contains the same information as Appendix A.1; however,
			Appendix A.1 takes precedence in case of conflict. The content
			encryption and key wrap algorithm objects are defined in [CMS-ASN].
			The id-aes128-wrap, id-aes192-wrap, and id-aes256-wrap algorithm
			identifiers are defined in [AES-CMS].
			A.1. 1988 ASN.1 Module
			AESKeyWrapWithPad-88 { iso(1) member-body(2) us(840) rsadsi(113549)
			pkcs(1) pkcs-9(9) smime(16) modules(0) 47 }
			DEFINITIONS IMPLICIT TAGS ::=
			BEGIN
			-- EXPORTS ALL --
			-- IMPORTS NONE --
			-- AES information object identifiers --
			aes OBJECT IDENTIFIER ::= {
			joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
			csor(3) nistAlgorithms(4) 1 }
			-- AES Key Wrap With Padding Algorithm Identifiers are to be used
			-- with the Parameter field absent
			id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 }
			id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 }
			id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 }
			END
			A.2. 2002 ASN.1 Module
			AESKeyWrapWithPad-02 { iso(1) member-body(2) us(840) rsadsi(113549)
			pkcs(1) pkcs-9(9) smime(16) modules(0) 48 }
			DEFINITIONS IMPLICIT TAGS ::=
			BEGIN
			-- EXPORTS ALL --
			IMPORTS
			AlgorithmIdentifier{}, CONTENT-ENCRYPTION, KEY-WRAP, SMIME-CAPS
			FROM AlgorithmInformation-2009 -- [CMS-ASN]
			{ iso(1) identified-organization(3) dod(6) internet(1)
			security(5) mechanisms(5) pkix(7) id-mod(0)
			id-mod-algorithmInformation-02(58) };
			AES-ContentEncryption CONTENT-ENCRYPTION ::= {
			cea-aes128-wrap-pad |
			cea-aes192-wrap-pad |
			cea-aes256-wrap-pad,
			... }
			AES-KeyWrap KEY-WRAP ::= {
			kwa-aes128-wrap-pad |
			kwa-aes192-wrap-pad |
			kwa-aes256-wrap-pad,
			... }
			SMimeCaps SMIME-CAPS ::= {
			cea-aes128-wrap-pad.&smimeCaps |
			cea-aes192-wrap-pad.&smimeCaps |
			cea-aes256-wrap-pad.&smimeCaps |
			kwa-aes128-wrap-pad.&smimeCaps |
			kwa-aes192-wrap-pad.&smimeCaps |
			kwa-aes256-wrap-pad.&smimeCaps,
			... }
			-- AES object identifier
			aes OBJECT IDENTIFIER ::= {
			joint-iso-itu-t(2) country(16) us(840) organization(1)
			gov(101) csor(3) nistAlgorithms(4) 1 }
			-- Content Encryption Algorithms
			cea-aes128-wrap-pad CONTENT-ENCRYPTION ::= {
			IDENTIFIER id-aes128-wrap-pad
			PARAMS ARE absent
			SMIME-CAPS { IDENTIFIED BY id-aes128-wrap-pad } }
			cea-aes192-wrap-pad CONTENT-ENCRYPTION ::= {
			IDENTIFIER id-aes192-wrap-pad
			PARAMS ARE absent
			SMIME-CAPS { IDENTIFIED BY id-aes192-wrap-pad } }
			cea-aes256-wrap-pad CONTENT-ENCRYPTION ::= {
			IDENTIFIER id-aes256-wrap-pad
			PARAMS ARE absent
			SMIME-CAPS { IDENTIFIED BY id-aes256-wrap-pad } }
			-- Key Wrap Algorithms
			kwa-aes128-wrap-pad KEY-WRAP ::= {
			IDENTIFIER id-aes128-wrap-pad
			PARAMS ARE absent
			SMIME-CAPS { IDENTIFIED BY id-aes128-wrap-pad } }
			id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 }
			kwa-aes192-wrap-pad KEY-WRAP ::= {
			IDENTIFIER id-aes192-wrap-pad
			PARAMS ARE absent
			SMIME-CAPS { IDENTIFIED BY id-aes192-wrap-pad } }
			id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 }
			kwa-aes256-wrap-pad KEY-WRAP ::= {
			IDENTIFIER id-aes256-wrap-pad
			PARAMS ARE absent
			SMIME-CAPS { IDENTIFIED BY id-aes256-wrap-pad } }
			id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 }
			END
			Authors' Addresses
	Russell Housley		Russell Housley
	Vigil Security, LLC		Vigil Security, LLC
	918 Spring Knoll Drive		918 Spring Knoll Drive
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
	EMail: housley@vigilsec.com		EMail: housley@vigilsec.com
	Morris Dworkin		Morris Dworkin
	National Institute of Standards and Technology		National Institute of Standards and Technology
End of changes. 21 change blocks.
	36 lines changed or deleted		203 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/