draft-ietf-bfd-optimizing-authentication-09.txt		draft-ietf-bfd-optimizing-authentication-10.txt
	Network Working Group M. Jethanandani		Network Working Group M. Jethanandani
	Internet-Draft VMware		Internet-Draft Kloud Services
	Intended status: Standards Track A. Mishra		Updates: 5880 (if approved) A. Mishra
	Expires: June 11, 2020 SES Networks		Intended status: Standards Track SES Networks
	A. Saxena		Expires: January 14, 2021 A. Saxena
	Ciena Corporation		Ciena Corporation
	M. Bhatia		M. Bhatia
	Nokia		Nokia
	December 9, 2019		July 13, 2020
	Optimizing BFD Authentication		Optimizing BFD Authentication
	draft-ietf-bfd-optimizing-authentication-09		draft-ietf-bfd-optimizing-authentication-10
	Abstract		Abstract
	This document describes an optimization to BFD Authentication as		This document describes an optimization to BFD Authentication as
	described in Section 6.7 of BFD RFC5880.		described in Section 6.7 of BFD RFC 5880. This document updates RFC
			5880.
	Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in BCP 14 [RFC2119]
	[RFC8174] when, and only when, they appear in all 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 June 11, 2020.		This Internet-Draft will expire on January 14, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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
			1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
			1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 3		2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 3
	3. NULL Auth TLV . . . . . . . . . . . . . . . . . . . . . . . . 4		3. NULL Auth Type . . . . . . . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. Normative References . . . . . . . . . . . . . . . . . . 6		6.1. Normative References . . . . . . . . . . . . . . . . . . 7
	6.2. Informative References . . . . . . . . . . . . . . . . . 6		6.2. Informative References . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	Authenticating every BFD [RFC5880] packet with a Simple Password, or		Authenticating every BFD [RFC5880] packet with a Simple Password, or
	with a MD5 Message-Digest Algorithm [RFC1321] , or Secure Hash		with a MD5 Message-Digest Algorithm [RFC1321] , or Secure Hash
	Algorithm (SHA-1) algorithms is computationally intensive process,		Algorithm (SHA-1) algorithms is a computationally intensive process.
	making it difficult if not impossible to authenticate every packet -		This makes it difficult, if not impossible to authenticate every
	particularly at faster rates. Also, the recent escalating series of		packet - particularly at faster rates. Also, the recent escalating
	attacks on MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise		series of attacks on MD5 and SHA-1 described in Finding Collisions in
	concerns about their remaining useful lifetime as outlined in Updated		the Full SHA-1 [SHA-1-attack1] and New Collision Search for SHA-1
	Security Considerations for the MD5 Message-Digest and the HMAC-MD5		[SHA-1-attack2] raise concerns about their remaining useful lifetime
	Algorithm [RFC6151] and Security Considerations for the SHA-0 and		as outlined in Updated Security Considerations for the MD5 Message-
	SHA-1 Message-Digest Algorithm [RFC6194]. If replaced by stronger		Digest and the HMAC-MD5 Algorithm [RFC6151] and Security
	algorithms, the computational overhead, will make the task of		Considerations for the SHA-0 and SHA-1 Message-Digest Algorithm
	authenticating every packet even more difficult to achieve.		[RFC6194]. If replaced by stronger algorithms, the computational
			overhead, will make the task of authenticating every packet even more
			difficult to achieve.
	This document proposes that only BFD frames that signal a state		This document proposes that only BFD packets that signal a state
	change in BFD be authenticated. Rest of the frames can be		change, a demand mode change (to D bit) or a poll sequence change (P
	transmitted and received without authentication enabled. Most frames		or F bit change) in a BFD packet be categorized as a significant
	that are transmitted and received have no state change associated		change. This document also proposes that all BFD control packets
	with them. Limiting authentication to frames that affect a BFD		which signal a significant change MUST be authenticated if the
	session state allows more sessions to be supported for		session's bfd.AuthType is non-zero. Other BFD Control packets MAY be
	authentication. Moreover, most BFD frames that signal a state change		transmitted and received without the A bit set.
	are generally transmitted at a slower interval of 1s leaving enough
	time to compute the hash. To detect a Man In the Middle (MITM)		Most packets that are transmitted and received have no state change
	attack, it is also proposed that a non-state change frame be		associated with them. Limiting authentication to packets that affect
	authenticated occasionally. The interval of this non-state change		a BFD session state allows more sessions to be supported with this
	frame can be configured depending on the detect multiplier and the		optimized method of authentication. Moreover, most BFD packets that
	capability of the system. As an example, this could be equal to the		signal a significant change are generally transmitted at a slower
	detect multiplier number of packets.		interval of 1s, leaving enough time to compute the hash.
			To detect a Man In the Middle (MITM) attack, it is also proposed that
			a BFD control packet without a significant change be authenticated
			occasionally. The interval of this non-state change frame can be
			configured depending on the detect multiplier and the capability of
			the system. As an example, this could be equal to the detect
			multiplier number of packets.
	The rest of the document is structured as follows. Section 2 talks		The rest of the document is structured as follows. Section 2 talks
	about the changes to authentication mode as described in BFD		about the changes to authentication mode as described in BFD
	[RFC5880]. Section 3 goes into the details of the new Authentication		[RFC5880]. Section 3 goes into the details of the new Authentication
	TLV.		Type.
			1.1. Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in BCP 14 [RFC2119]
			[RFC8174] when, and only when, they appear in all capitals, as shown
			here.
			1.2. Terminology
			The following terms used in this document have been defined in BFD
			[RFC5880].
			o Detect Multiplier
			o Detection Time
			+--------------+----------------------------------------------------+
			| Term | Meaning |
			+--------------+----------------------------------------------------+
			| significant | State change, a demand model change (to D bit) or |
			| change | a poll sequence change (P or F bit). |
			| configured | configured authentication periodic interval |
			| interval | |
			+--------------+----------------------------------------------------+
	2. Authentication Mode		2. Authentication Mode
	The cryptographic authentication mechanisms specified in BFD		The cryptographic authentication mechanisms specified in BFD
	[RFC5880] describes enabling and disabling of authentication as a one		[RFC5880] describes enabling and disabling of authentication as a one
	time operation. As a security precaution, it mentions that		time operation. As a security precaution, it mentions that
	authentication state be allowed to change at most once. Once		authentication state be allowed to change at most once. Once
	enabled, every packet must have Authentication Bit set and the		enabled, every packet must have Authentication Bit set and the
	associated Authentication TLV appended. In addition, it states that		associated Authentication Type appended. In addition, it states that
	an implementation SHOULD NOT allow the authentication state to be		an implementation SHOULD NOT allow the authentication state to be
	changed based on the receipt of a BFD Control packet.		changed based on the receipt of a BFD Control packet.
	This document proposes that the authentication mode be modified to be		This document proposes that the authentication mode be modified to be
	enabled on demand. Instead of authenticating every packet, BFD peers		enabled on demand. Instead of authenticating every packet, BFD peers
	are configured for which frames need to be authenticated, and		are configured for which packets need to be authenticated, and
	authenticate only those frames. Rest of the frames can be		authenticate only those packets. Rest of the packets can be
	transmitted and received without authentication. For example, the		transmitted and received without authentication. For example, the
	two ends can be configured such that BFD frames that indicate a state		two ends can be configured such that BFD packets that indicate a
	change should be authenticated and enable authentication on those		significant change should be authenticated and enable authentication
	frames only. If the two ends have previously been configured as		on those packets only. If the two ends have previously been
	such, but at least one side decides not to authenticate a state		configured as such, but at least one side decides not to authenticate
	change frame, then the BFD session will fail to come up.		a significant change frame, then the BFD session will fail to come
			up.
	This proposal outlines which frames need to be authenticated (carry		This proposal outlines which packets need to be authenticated (carry
	the A-bit), and which frames can be transmitted or received without		the A-bit), and which packets can be transmitted or received without
	authentication enabled. A frame that fails authentication is		authentication enabled. A frame that fails authentication is
	discarded, or a frame that was supposed to be authenticated, but was		discarded, or a frame that was supposed to be authenticated, but was
	not, e.g. a state-change frame, is discarded. However, there is no		not, e.g. a significant change frame, is discarded. However, there
	change to the state machine for BFD, as the decision of a state		is no change to the state machine for BFD, as the decision of a
	change is still decided by how many valid consecutive frames were		significant change is still decided by how many valid consecutive
	received, authenticated or otherwise.		packets were received, authenticated or otherwise.
	The state changes for which authentication is being suggested		The following table summarizes when the A bit should be set. The
	include:		table should be read with the column indicating the BFD state the
			receiver is currently in, and the row indicating the BFD state the
			receiver might transition to based on the packet received. The
			interesection of the two indicates whether the received packet should
			have the A bit set (Auth), no authentication is needed (NULL), most
			packets are NULL AUTH (Select) or the state transition is not
			applicable.
	Read : On state change from <column> to <row>		Read : On state change from <column> to <row>
	Auth : Authenticate frame		Auth : Authenticate frame
	NULL : No Authentication. Use NULL AUTH TLV.		NULL : No Authentication. Use NULL AUTH Type.
	n/a : Invalid state transition.		n/a : Invalid state transition.
	Select : Most frames NULL AUTH. Selective (periodic)		Select : Most packets NULL AUTH. Selective (periodic)
	frames authenticated.		packets authenticated.
	+--------+--------+--------+--------+--------+--------+		+--------+--------+--------+--------+------------+
	| | DOWN | INIT | UP | POLL | DEMAND |		| | DOWN | INIT | UP | ADMIN DOWN |
	+--------+--------+--------+--------+--------+--------+		+--------+--------+--------+--------+------------+
	| DOWN | NULL | Auth | Auth | Auth | Auth |		| DOWN | NULL | Auth | Auth | NULL |
	+--------+--------+--------+--------+--------+--------+		+--------+--------+--------+--------+------------+
	| INIT | Auth | NULL | Auth | Auth | Auth |		| INIT | Auth | NULL | n/a | n/a |
	+--------+--------+--------+--------+--------+--------+		+--------+--------+--------+--------+------------+
	| UP | Auth | n/a | Select | Auth | Auth |		| UP | Auth | Auth | Select | n/a |
	+--------+--------+--------+--------+--------+--------+		+--------+--------+--------+--------+------------+
	| POLL | Auth | n/a | Auth | Auth | Auth |		| ADMIN | NULL | Auth | Auth | NULL |
	+--------+--------+--------+--------+--------+--------+		+--------+--------+--------+--------+------------+
	| DEMAND | Auth | Auth | Auth | Auth | Auth |
	+--------+--------+--------+--------+--------+--------+
	Optimized Authentication Map		Optimized Authentication Map
	All frames already carry the sequence number. The NULL AUTH frames		If P or F bit changes value, the packet MUST be authenticated. If
	MUST contain the TLV specified in Section 3. This enables a		the D bit changes value, the packet MUST be authenticated.
			All packets already carry the sequence number. The NULL AUTH packets
			MUST contain the Type specified in Section 3. This enables a
	monotonically increasing sequence number to be carried in each frame,		monotonically increasing sequence number to be carried in each frame,
	and prevents man-in-the-middle from capturing and replaying the same		and prevents man-in-the-middle from capturing and replaying the same
	frame again. Since all frames still carry a sequence number, the		frame again. Since all packets still carry a sequence number, the
	logic for sequence number maintenance remains unchanged from		logic for sequence number maintenance remains unchanged from BFD
	[RFC5880]. If at a later time, a different scheme is adopted for		[RFC5880]. If at a later time, a different scheme is adopted for
	changing sequence number, this method can use the updated scheme		changing sequence number, e.g. Secure BFD Sequence Numbers
	without any impact.		[I-D.ietf-bfd-secure-sequence-numbers], this method can use the
			updated scheme without any impact.
	Most frames transmitted on a BFD session are BFD CC UP frames.		Most packets transmitted on a BFD session are BFD UP packets.
	Authenticating a small subset of these frames, for example, a detect		Authenticating a small subset of these packets, for example, a detect
	multiplier number of packets per configured period, significantly		multiplier number of packets per configured period, significantly
	reduces the computational demand for the system while maintaining		reduces the computational demand for the system while maintaining
	security of the session across the configured authentication periods.		security of the session across the configured authentication periods.
	A minimum of Detect Multiplier packets MUST be transmitted per		A minimum of Detect Multiplier packets MUST be transmitted per
	configured periodic authentication interval. This ensures that the		configured periodic authentication interval. This ensures that the
	BFD session should see at least one authenticated packet during that		BFD session should see at least one authenticated packet during that
	interval.		interval.
	3. NULL Auth TLV		3. NULL Auth Type
	This section describes a new Authentication TLV as:		This section describes a new Authentication Type as:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Auth Type | Auth Len | Auth Key ID | Reserved |		| Auth Type | Auth Len | Auth Key ID | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	NULL Auth TLV		NULL Auth Type
	where:		where:
	Auth Type: The Authentication Type, which in this case is TBD (NULL		Auth Type: The Authentication Type, which in this case is TBD (NULL,
	Auth TLV, to be assigned by IANA)		to be assigned by IANA)
	Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytes		Auth Len: The length of the NULL Auth Type, in bytes i.e. 8 bytes
	Auth Key ID: The authentication key ID in use for this packet. Must		Auth Key ID: The authentication key ID in use for this packet. Must
	be set to zero.		be set to zero.
	Reserved: This byte MUST be set to zero on transmit and ignored on		Reserved: This byte MUST be set to zero on transmit and ignored on
	receive.		receive.
	Sequence Number: The sequence number for this packet. Implementation		Sequence Number: The sequence number for this packet. Implementation
	may use sequence numbers as defined in [RFC5880], or secure sequence		may use sequence numbers (bfd.XmitAuthSeq) as defined in BFD
	numbers as defined in [I-D.ietf-bfd-secure-sequence-numbers].		[RFC5880], or secure sequence numbers as defined in Secure BFD
			Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers].
	The NULL Auth TLV must be used for all frames that are not		The NULL Auth Type must be used for all packets that are not
	authenticated. This protects against replay-attacks by allowing the		authenticated. This protects against replay-attacks by allowing the
	session to maintain an incrementing sequence number for all frames		session to maintain an incrementing sequence number for all packets
	(authenticated and un-authenticated).		(authenticated and un-authenticated).
	In the future, if a new scheme is adopted for changing the sequence		In the future, if a new scheme is adopted for changing the sequence
	number, this method can adopt the new scheme without any impact.		number, this method can adopt the new scheme without any impact.
	4. IANA Considerations		4. IANA Considerations
	This document requests an update to the registry titled "BFD		This document requests an update to the registry titled "BFD
	Authentication Types". IANA is requested to to assign a new BFD Auth		Authentication Types". IANA is requested to to assign a new BFD Auth
	Type for "NULL Auth TLV" (see Section 3).		Type for "NULL" (see Section 3).
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	5. Security Considerations		5. Security Considerations
	The approach described in this document enhances the ability to		The approach described in this document enhances the ability to
	authentication a BFD session by taking away the onerous requirement		authenticate a BFD session by taking away the onerous requirement
	that every frame be authenticated. By authenticating frames that		that every BFD control packet be authenticated. By authenticating
	affect the state of the session, the security of the BFD session is		packets that affect the state of the session, the security of the BFD
	maintained. As such this document does not change the security		session is maintained. In this mode, packets that are a significant
	considerations for BFD.		change but are not authenticated, are dropped by the system.
			Therefore, a malicious user that tries to inject a non-authenticated
			packet, e.g. with a Down state to take a session down will fail.
			That combined with the proposal of using sequence number defined in
			Secure BFD Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers]
			further enhances the security of BFD sessions.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[I-D.ietf-bfd-secure-sequence-numbers]		[I-D.ietf-bfd-secure-sequence-numbers]
	Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and		Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and
	A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd-		A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd-
	secure-sequence-numbers-04 (work in progress), August		secure-sequence-numbers-05 (work in progress), February
	2019.		2020.
	[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>.
			[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
			(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
			<https://www.rfc-editor.org/info/rfc5880>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	6.2. Informative References		6.2. Informative References
	[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,		[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	DOI 10.17487/RFC1321, April 1992,		DOI 10.17487/RFC1321, April 1992,
	<https://www.rfc-editor.org/info/rfc1321>.		<https://www.rfc-editor.org/info/rfc1321>.
	[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
	(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
	<https://www.rfc-editor.org/info/rfc5880>.
	[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations		[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
	for the MD5 Message-Digest and the HMAC-MD5 Algorithms",		for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
	RFC 6151, DOI 10.17487/RFC6151, March 2011,		RFC 6151, DOI 10.17487/RFC6151, March 2011,
	<https://www.rfc-editor.org/info/rfc6151>.		<https://www.rfc-editor.org/info/rfc6151>.
	[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security		[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
	Considerations for the SHA-0 and SHA-1 Message-Digest		Considerations for the SHA-0 and SHA-1 Message-Digest
	Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,		Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
	<https://www.rfc-editor.org/info/rfc6194>.		<https://www.rfc-editor.org/info/rfc6194>.
	skipping to change at page 7, line 16 ¶		skipping to change at page 8, line 21 ¶
	Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the		Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
	Full SHA-1", 2005.		Full SHA-1", 2005.
	[SHA-1-attack2]		[SHA-1-attack2]
	Wang, X., Yao, A., and F. Yao, "New Collision Search for		Wang, X., Yao, A., and F. Yao, "New Collision Search for
	SHA-1", 2005.		SHA-1", 2005.
	Authors' Addresses		Authors' Addresses
	Mahesh Jethanandani		Mahesh Jethanandani
	VMware		Kloud Services
	USA		USA
	Email: mjethanandani@gmail.com		Email: mjethanandani@gmail.com
	Ashesh Mishra		Ashesh Mishra
	SES Networks		SES Networks
	Email: mishra.ashesh@gmail.com		Email: mishra.ashesh@gmail.com
	Ankur Saxena		Ankur Saxena
End of changes. 37 change blocks.
	112 lines changed or deleted		157 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/