draft-ietf-sipcore-digest-scheme-14.txt		draft-ietf-sipcore-digest-scheme-15.txt
	SIP Core R. Shekh-Yusef		SIP Core R. Shekh-Yusef
	Internet-Draft Avaya		Internet-Draft Avaya
	Updates: 3261 (if approved) October 30, 2019		Updates: 3261 (if approved) November 3, 2019
	Intended status: Standards Track		Intended status: Standards Track
	Expires: May 2, 2020		Expires: May 6, 2020
	The Session Initiation Protocol (SIP) Digest Authentication Scheme		The Session Initiation Protocol (SIP) Digest Authentication Scheme
	draft-ietf-sipcore-digest-scheme-14		draft-ietf-sipcore-digest-scheme-15
	Abstract		Abstract
	This document updates RFC 3261 by updating the Digest Access		This document updates RFC 3261 by updating the Digest Access
	Authentication scheme used by the Session Initiation Protocol (SIP)		Authentication scheme used by the Session Initiation Protocol (SIP)
	to add support for more secure digest algorithms, e.g., SHA-256 and		to add support for more secure digest algorithms, e.g., SHA-256 and
	SHA-512-256, to replace the broken MD5 algorithm.		SHA-512-256, to replace the obsolete MD5 algorithm.
	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 May 2, 2020.		This Internet-Draft will expire on May 6, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	skipping to change at page 7, line 24 ¶		skipping to change at page 7, line 24 ¶
	allowed, since it provides integrity checks over the bodies and		allowed, since it provides integrity checks over the bodies and
	provides mutual authentication.		provides mutual authentication.
	2.7. Augmented BNF for SIP		2.7. Augmented BNF for SIP
	This document updates the Augmented BNF [RFC5234] for SIP as follows.		This document updates the Augmented BNF [RFC5234] for SIP as follows.
	It extends the request-digest as follows to allow for different		It extends the request-digest as follows to allow for different
	digest sizes:		digest sizes:
	request-digest = LDQUOT 32*LHEX RDQUOT		request-digest = LDQUOT *LHEX RDQUOT
	The number of hex digits is implied by the length of the value of the		The number of hex digits is implied by the length of the value of the
	algorithm used.		algorithm used, with the minimum size of 32. A parameter with an
			empty value (empty string) is allowed when the UAC has not yet
			received a challenge.
	It extends the algorithm parameter as follows to allow for any		It extends the algorithm parameter as follows to allow for any
	algorithm in the registry to be used:		algorithm in the registry to be used:
	algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / "SHA-256" /		algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / "SHA-256" /
	"SHA-256-sess" / "SHA-512-256" / "SHA-512-256-sess" / token )		"SHA-256-sess" / "SHA-512-256" / "SHA-512-256-sess" / token )
	3. Security Considerations		3. Security Considerations
	This specification adds new secure algorithms to be used with the		This specification adds new secure algorithms to be used with the
	Digest mechanism to authenticate users. The broken MD5 algorithm		Digest mechanism to authenticate users. The obsolete MD5 algorithm
	remains only for backward compatibility with [RFC2617] but its use is		remains only for backward compatibility with [RFC2617] but its use is
	NOT RECOMMENDED.		NOT RECOMMENDED.
	This opens the system to the potential of a downgrade attack by an		This opens the system to the potential of a downgrade attack by an
	on-path attacker. The most effective way of dealing with this type		on-path attacker. The most effective way of dealing with this type
	of attack is to either validate the client and challenge it		of attack is to either validate the client and challenge it
	accordingly, or remove the support for backward compatibility by not		accordingly, or remove the support for backward compatibility by not
	supporting MD5.		supporting MD5.
	See section 5 of [RFC7616] for a detailed security discussion of the		See section 5 of [RFC7616] for a detailed security discussion of the
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 24 ¶
	This document has no actions for IANA.		This document has no actions for IANA.
	5. Acknowledgments		5. Acknowledgments
	The author would like to thank the following individuals for their		The author would like to thank the following individuals for their
	careful reviews, comments, and suggestions: Paul Kyzivat, Olle		careful reviews, comments, and suggestions: Paul Kyzivat, Olle
	Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga		Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga
	Asveren, Christer Holmberg, Brian Rosen, Jean Mahoney, Adam Roach,		Asveren, Christer Holmberg, Brian Rosen, Jean Mahoney, Adam Roach,
	Barry Leiba, Roni Even, Eric Vyncke, Benjamin Kaduk, Alissa Cooper,		Barry Leiba, Roni Even, Eric Vyncke, Benjamin Kaduk, Alissa Cooper,
	Roman Danyliw, and Alexey Melnikov. .		Roman Danyliw, and Alexey Melnikov, and Maxim Sobolev. .
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[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>.
End of changes. 9 change blocks.
	9 lines changed or deleted		11 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/