--- 1/draft-ietf-sipcore-digest-scheme-10.txt 2019-10-28 16:13:09.725096985 -0700 +++ 2/draft-ietf-sipcore-digest-scheme-11.txt 2019-10-28 16:13:09.745097485 -0700 @@ -1,44 +1,43 @@ SIP Core R. Shekh-Yusef Internet-Draft Avaya -Updates: 3261 (if approved) September 18, 2019 +Updates: 3261 (if approved) October 28, 2019 Intended status: Standards Track -Expires: March 21, 2020 +Expires: April 30, 2020 The Session Initiation Protocol (SIP) Digest Authentication Scheme - draft-ietf-sipcore-digest-scheme-10 + draft-ietf-sipcore-digest-scheme-11 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. + to add support for more secure digest algorithms, e.g., SHA-256 and + SHA-512-256, to replace the broken MD5 algorithm. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 March 21, 2020. + This Internet-Draft will expire on April 30, 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 @@ -115,60 +114,60 @@ 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 - Digest mechanism in [RFC3261] resulting from that reference update. - It adds support for the SHA-256 and SHA-512/256 algorithms. It adds - required support for the "qop" parameter. It provides additional - User Agent Client (UAC) and User Agent Server (UAS) procedures - regarding usage of multiple SIP Authorization, WWW-Authenticate and - Proxy-Authenticate header fields, including in which order to insert - and process them. It provides guidance regarding forking. Finally, - it updates the SIP BNF as required by the updates. + It replaces the reference used in [RFC3261] for Digest Access + Authentication, substituting [RFC7616] for the obsolete [RFC2617], + and describes the modifications to the usage of the Digest mechanism + in [RFC3261] resulting from that reference update. It adds support + for the SHA-256 and SHA-512/256 algorithms. It adds required support + for the "qop" parameter. It provides additional User Agent Client + (UAC) and User Agent Server (UAS) procedures regarding usage of + multiple SIP Authorization, WWW-Authenticate and Proxy-Authenticate + header fields, including in which order to insert and process them. + It provides guidance regarding forking. Finally, it updates the SIP + BNF as required by the updates. 2.1. Hash Algorithms The Digest scheme has an 'algorithm' parameter that specifies the algorithm to be used to compute the digest of the response. The IANA - registry named "HTTP Digest Hash Algorithms" specifies the algorithms - that correspond to 'algorithm' values. + registry named the "Hash Algorithms for HTTP Digest Authentication" + specifies the algorithms that correspond to 'algorithm' values. [RFC3261] specifies only one algorithm, MD5, which is used by default. This document extends [RFC3261] to allow use of any algorithm listed in the "Hash Algorithms for HTTP Digest Authentication" registry. A UAS prioritizes which algorithm to use based on the ordering of the - challenge header fields in the response it is processing. That + challenge header fields in the response it is preparing. That process is specified in section 2.3 and parallels the process used in HTTP specified by [RFC7616]. 2.2. Representation of Digest Values The size of the digest depends on the algorithm used. The bits in the digest are converted from the most significant to the least significant bit, four bits at a time to the ASCII representation as follows. Each four bits is represented by its familiar hexadecimal notation from the characters 0123456789abcdef, that is binary 0000 is represented by the character '0', 0001 by '1' and so on up to the - representation of 1111 as 'f'. If the MD5 algorithm is used to - calculate the digest, then the digest will be represented as 32 - hexadecimal characters, SHA-256 and SHA-512/256 by 64 hexadecimal - characters. + representation of 1111 as 'f'. If the SHA-256 or SHA-512/256 + algorithm is used to calculate the digest, then the digest will be + represented as 64 hexadecimal characters. 2.3. UAS Behavior When a UAS receives a request from a UAC, and an acceptable Authorization header field is not received, the UAS can challenge the originator to provide credentials by rejecting the request with a 401/407 status code with the WWW-Authenticate/Proxy-Authenticate header field respectively. The UAS MAY add multiple WWW- Authenticate/Proxy-Authenticate header fields to allow the UAS to utilize the best available algorithm supported by the client. @@ -186,52 +185,55 @@ When the UAC receives a response with multiple WWW-Authenticate/ Proxy-Authenticate header fields with the same realm it SHOULD use the topmost header field that it supports, unless a local policy dictates otherwise. The client MUST ignore any challenge it does not understand. When the UAC receives a 401 response with multiple WWW-Authenticate header fields with different realms it SHOULD retry and add an Authorization header field containing credentials that match the - topmost header field of any one of the realms. + topmost header field of any one of the realms, unless a local policy + dictates otherwise. If the UAC cannot respond to any of the challenges in the response, - then it SHOULD abandon attempts to send the request, e.g. if the UAC - does not have credentials or has stale credentials for any of the - realms, unless a local policy dictates otherwise. + then it SHOULD abandon attempts to send the request unless a local + policy dictates otherwise. For example, if the UAC does not have + credentials or has stale credentials for any of the realms, the UAC + will abandon the request. 2.5. Forking Section 22.3 of [RFC3261] discusses the operation of the proxy-to- user authentication, which describes the operation of the proxy when it forks a request. This section clarifies that operation. 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 values received from proxies relative to values received - from other proxies is not significant. + Authenticate header fields received from one downstream proxy into a + single response, it MUST maintain the order of these header fields. + The ordering of values received from different downstream 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: @@ -250,45 +252,46 @@ 4. The example procedure for choosing a nonce based on Etag does not work for SIP. 5. The text in [RFC7234] regarding cache operation does not apply to SIP. 6. [RFC7616] requires that a server check that the URI in the request line and the URI included in the Authorization header field point to the same resource. In a SIP context, these two URIs may refer to different users, due to forwarding at some proxy. - Therefore, in SIP, a UAS MAY check that the Request-URI in the + Therefore, in SIP, a UAS MUST check if the Request-URI in the Authorization/Proxy-Authorization header field value corresponds to a user for whom the UAS is willing to accept forwarded or direct - requests, but it is not necessarily a failure if the two fields are - not equivalent. + requests, but MAY still accept it if the two fields are not + equivalent. 7. As a clarification to the calculation of the A2 value for message integrity assurance in the Digest authentication scheme, implementers should assume, when the entity-body is empty (that is, when SIP messages have no body) that the hash of the entity-body resolves to the hash of an empty string: H(entity-body) = ("") For example, when the chosen algorithm is SHA-256, then: H(entity-body) = SHA-256("") = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" 8. A UAS MUST be able to properly handle "qop" parameter received in an Authorization/Proxy-Authorization header field, and a UAC MUST be able to properly handle "qop" parameter received in WWW-Authenticate and Proxy-Authenticate header fields. However, for backward compatibility reasons, the "qop" parameter is optional for - RFC3261-based clients and servers to receive. + RFC3261-based clients and servers to receive. If the "qop" parameter + is not specified, then the default value is "auth". A UAS MUST always send a "qop" parameter in WWW-Authenticate and Proxy-Authenticate header field values, and a UAC MUST send the "qop" parameter in any resulting authorization header field. The usage of the Authentication-Info header field continues to be allowed, since it provides integrity checks over the bodies and provides mutual authentication. 2.7. Augmented BNF for SIP @@ -302,25 +305,29 @@ The number of hex digits is implied by the length of the value of the algorithm used. It extends the algorithm parameter as follows to allow for any algorithm in the registry to be used: algorithm = "algorithm" EQUAL ( "MD5" / "SHA-512-256" / "SHA-256" / token ) + Each one of these algorithms might have a "-sess" variant, e.g., + MD5-sess, SHA-256-sess, etc, as defined in [RFC7616] + 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. + Digest mechanism to authenticate users. The broken MD5 algorithm + remains only for backward compatibility with [RFC2617] but its use is + NOT RECOMMENDED. 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. @@ -331,22 +338,22 @@ 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, Jean Mahoney, and Adam - Roach. + Asveren, Christer Holmberg, Brian Rosen, Jean Mahoney, Adam Roach, + Barry Leiba, and Roni Even. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, .