draft-ietf-sipcore-digest-scheme-08.txt		draft-ietf-sipcore-digest-scheme-09.txt
	SIP Core R. Shekh-Yusef		SIP Core R. Shekh-Yusef
	Internet-Draft Avaya		Internet-Draft Avaya
	Updates: 3261 (if approved) July 3, 2019		Updates: 3261 (if approved) September 16, 2019
	Intended status: Standards Track		Intended status: Standards Track
	Expires: January 4, 2020		Expires: March 19, 2020
	The Session Initiation Protocol (SIP) Digest Authentication Scheme		The Session Initiation Protocol (SIP) Digest Authentication Scheme
	draft-ietf-sipcore-digest-scheme-08		draft-ietf-sipcore-digest-scheme-09
	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, which might be used		SHA-512-256, to replace the broken MD5 algorithm, which might be used
	for backward compatibility reasons only.		for backward compatibility reasons only.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 January 4, 2020.		This Internet-Draft will expire on March 19, 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 3, line 22 ¶		skipping to change at page 3, line 22 ¶
	future.		future.
	This document updates the Digest Access Authentication scheme used by		This document updates the Digest Access Authentication scheme used by
	SIP to support the algorithms listed in the "Hash Algorithms for HTTP		SIP to support the algorithms listed in the "Hash Algorithms for HTTP
	Digest Authentication" registry defined by [RFC7616].		Digest Authentication" registry defined by [RFC7616].
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC8174].
	2. SIP Digest Authentication Scheme Updates		2. SIP Digest Authentication Scheme Updates
	This section describes the modifications to the operation of the		This section describes the modifications to the operation of the
	Digest mechanism as specified in [RFC3261] in order to support the		Digest mechanism as specified in [RFC3261] in order to support the
	algorithms defined in the "Hash Algorithms for HTTP Digest		algorithms defined in the "Hash Algorithms for HTTP Digest
	Authentication" registry described in [RFC7616].		Authentication" registry described in [RFC7616].
	It replaces the reference to [RFC2617] with a reference to [RFC7616]		It replaces the reference to [RFC2617] with a reference to [RFC7616]
	in [RFC3261], and describes the modifications to the usage of the		in [RFC3261], and describes the modifications to the usage of the
	skipping to change at page 5, line 39 ¶		skipping to change at page 5, line 39 ¶
	If a request is forked, various proxy servers and/or UAs may wish to		If a request is forked, various proxy servers and/or UAs may wish to
	challenge the UAC. In this case, the forking proxy server is		challenge the UAC. In this case, the forking proxy server is
	responsible for aggregating these challenges into a single response.		responsible for aggregating these challenges into a single response.
	Each WWW-Authenticate and Proxy-Authenticate value received in		Each WWW-Authenticate and Proxy-Authenticate value received in
	responses to the forked request MUST be placed into the single		responses to the forked request MUST be placed into the single
	response that is sent by the forking proxy to the UAC.		response that is sent by the forking proxy to the UAC.
	When the forking proxy places multiple WWW-Authenticate and Proxy-		When the forking proxy places multiple WWW-Authenticate and Proxy-
	Authenticate header fields from one received response into the single		Authenticate header fields from one received response into the single
	response it MUST maintain the order of these header fields. The		response it MUST maintain the order of these header fields. The
	ordering of the header field values from the various proxies is not		ordering of values received from proxies relative to values received
	significant.		from other proxies is not significant.
	2.6. HTTP Digest Authentication Scheme Modifications		2.6. HTTP Digest Authentication Scheme Modifications
	This section describes the modifications and clarifications required		This section describes the modifications and clarifications required
	to apply the HTTP Digest authentication scheme to SIP. The SIP		to apply the HTTP Digest authentication scheme to SIP. The SIP
	scheme usage is similar to that for HTTP. For completeness, the		scheme usage is similar to that for HTTP. For completeness, the
	bullets specified below are mostly copied from section 22.4 of		bullets specified below are mostly copied from section 22.4 of
	[RFC3261]; the only semantic changes are specified in bullets 1, 7,		[RFC3261]; the only semantic changes are specified in bullets 1, 7,
	and 8 below.		and 8 below.
	SIP clients and servers MUST NOT accept or request Basic		SIP clients and servers MUST NOT accept or request Basic
	authentication.		authentication.
	The rules for Digest authentication follow those defined in HTTP,		The rules for Digest authentication follow those defined in HTTP,
	with "HTTP/1.1" [RFC7616] replaced by "SIP/2.0" in addition to the		with "HTTP/1.1" [RFC7616] replaced by "SIP/2.0" in addition to the
	following differences:		following differences:
	1. The URI included in the challenge has the following BNF:		1. The URI included in the challenge has the following BNF
			[RFC5234]:
	URI = Request-URI ; as defined in [RFC3261], Section 25		URI = Request-URI ; as defined in [RFC3261], Section 25
	2. The 'uri' parameter of the Authorization header field MUST be		2. The 'uri' parameter of the Authorization header field MUST be
	enclosed in quotation marks.		enclosed in quotation marks.
	3. The BNF for digest-uri-value is:		3. The BNF for digest-uri-value is:
	digest-uri-value = Request-URI		digest-uri-value = Request-URI
	skipping to change at page 7, line 44 ¶		skipping to change at page 7, line 44 ¶
	algorithm = "algorithm" EQUAL ( "MD5" / "SHA-512-256" / "SHA-256"		algorithm = "algorithm" EQUAL ( "MD5" / "SHA-512-256" / "SHA-256"
	/ token )		/ 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, but leaves the broken MD5		Digest mechanism to authenticate users, but leaves the broken MD5
	algorithm for backward compatibility.		algorithm for backward compatibility.
	This opens the system to the potential of a downgrade attack by man-		This opens the system to the potential of a downgrade attack by an
	in-the-middle. The most effective way of dealing with this type of		on-path attacker. The most effective way of dealing with this type
	attack is to either validate the client and challenge it accordingly,		of attack is to either validate the client and challenge it
	or remove the support for backward compatibility by not supporting		accordingly, or remove the support for backward compatibility by not
	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
	Digest scheme.		Digest scheme.
	4. IANA Considerations		4. IANA Considerations
	[RFC7616] defines an IANA registry named "Hash Algorithms for HTTP		[RFC7616] defines an IANA registry named "Hash Algorithms for HTTP
	Digest Authentication" to simplify the introduction of new algorithms		Digest Authentication" to simplify the introduction of new algorithms
	in the future. This document specifies that algorithms defined in		in the future. This document specifies that algorithms defined in
	that registry may be used in SIP digest authentication.		that registry may be used in SIP digest authentication.
	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, and Jean Mahoney.		Asveren, Christer Holmberg, Brian Rosen, Jean Mahoney, and Adam
			Roach.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext		[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext
	Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June		Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June
	2014.		2014.
	[RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest		[RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest
	Access Authentication", RFC 7616, September 2015.		Access Authentication", RFC 7616, September 2015.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	6.2. Informative References		6.2. Informative References
	[RFC2617] Franks, J., M. Hallam-Baker, P., L. Hostetler, J., D.		[RFC2617] Franks, J., M. Hallam-Baker, P., L. Hostetler, J., D.
	Lawrence, S., J. Leach, P., Luotonen, A., and L. C.		Lawrence, S., J. Leach, P., Luotonen, A., and L. C.
	Stewart, "HTTP Authentication: Basic and Digest Access		Stewart, "HTTP Authentication: Basic and Digest Access
	Authentication", RFC 2617, June 1999.		Authentication", RFC 2617, June 1999.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
End of changes. 11 change blocks.
	17 lines changed or deleted		20 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/