--- 1/draft-ietf-sipcore-digest-scheme-08.txt 2019-09-17 02:13:14.471173570 -0700 +++ 2/draft-ietf-sipcore-digest-scheme-09.txt 2019-09-17 02:13:14.499174268 -0700 @@ -1,19 +1,19 @@ SIP Core R. Shekh-Yusef Internet-Draft Avaya -Updates: 3261 (if approved) July 3, 2019 +Updates: 3261 (if approved) September 16, 2019 Intended status: Standards Track -Expires: January 4, 2020 +Expires: March 19, 2020 The Session Initiation Protocol (SIP) Digest Authentication Scheme - draft-ietf-sipcore-digest-scheme-08 + draft-ietf-sipcore-digest-scheme-09 Abstract This document updates RFC 3261 by updating the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) 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 for backward compatibility reasons only. Status of This Memo @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -104,21 +104,21 @@ future. This document updates the Digest Access Authentication scheme used by SIP to support the algorithms listed in the "Hash Algorithms for HTTP Digest Authentication" registry defined by [RFC7616]. 1.1. Terminology 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 [RFC2119]. + document are to be interpreted as described in [RFC8174]. 2. SIP Digest Authentication Scheme Updates This section describes the modifications to the operation of the Digest mechanism as specified in [RFC3261] in order to support the algorithms defined in the "Hash Algorithms for HTTP Digest Authentication" registry described in [RFC7616]. It replaces the reference to [RFC2617] with a reference to [RFC7616] in [RFC3261], and describes the modifications to the usage of the @@ -207,40 +207,41 @@ 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 responsible for aggregating these challenges into a single response. Each WWW-Authenticate and Proxy-Authenticate value received in responses to the forked request MUST be placed into the single response that is sent by the forking proxy to the UAC. When the forking proxy places multiple WWW-Authenticate and Proxy- Authenticate header fields from one received response into the single response it MUST maintain the order of these header fields. The - ordering of the header field values from the various proxies is not - significant. + ordering of values received from proxies relative to values received + from other proxies is not significant. 2.6. HTTP Digest Authentication Scheme Modifications This section describes the modifications and clarifications required to apply the HTTP Digest authentication scheme to SIP. The SIP scheme usage is similar to that for HTTP. For completeness, the bullets specified below are mostly copied from section 22.4 of [RFC3261]; the only semantic changes are specified in bullets 1, 7, and 8 below. SIP clients and servers MUST NOT accept or request Basic authentication. The rules for Digest authentication follow those defined in HTTP, with "HTTP/1.1" [RFC7616] replaced by "SIP/2.0" in addition to the 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 2. The 'uri' parameter of the Authorization header field MUST be enclosed in quotation marks. 3. The BNF for digest-uri-value is: digest-uri-value = Request-URI @@ -305,64 +306,66 @@ algorithm = "algorithm" EQUAL ( "MD5" / "SHA-512-256" / "SHA-256" / token ) 3. Security Considerations This specification adds new secure algorithms to be used with the Digest mechanism to authenticate users, but leaves the broken MD5 algorithm for backward compatibility. - This opens the system to the potential of a downgrade attack by man- - in-the-middle. The most effective way of dealing with this type of - attack is to either validate the client and challenge it accordingly, - or remove the support for backward compatibility by not supporting - MD5. + 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 + of attack is to either validate the client and challenge it + accordingly, or remove the support for backward compatibility by not + supporting MD5. See section 5 of [RFC7616] for a detailed security discussion of the Digest scheme. 4. IANA Considerations [RFC7616] defines an IANA registry named "Hash Algorithms for HTTP Digest Authentication" to simplify the introduction of new algorithms in the future. This document specifies that algorithms defined in that registry may be used in SIP digest authentication. This document has no actions for IANA. 5. Acknowledgments The author would like to thank the following individuals for their careful reviews, comments, and suggestions: Paul Kyzivat, Olle 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.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, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014. [RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest 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, . + 6.2. Informative References [RFC2617] Franks, J., M. Hallam-Baker, P., L. Hostetler, J., D. Lawrence, S., J. Leach, P., Luotonen, A., and L. C. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,