--- 1/draft-ietf-sipcore-digest-scheme-02.txt 2019-05-26 05:13:12.808748438 -0700 +++ 2/draft-ietf-sipcore-digest-scheme-03.txt 2019-05-26 05:13:12.828748946 -0700 @@ -1,42 +1,43 @@ SIP Core R. Shekh-Yusef Internet-Draft Avaya -Updates: 3261 (if approved) May 9, 2019 +Updates: 3261 (if approved) May 26, 2019 Intended status: Standards Track -Expires: November 10, 2019 +Expires: November 27, 2019 The Session Initiation Protocol (SIP) Digest Authentication Scheme - draft-ietf-sipcore-digest-scheme-02 + draft-ietf-sipcore-digest-scheme-03 Abstract This document updates the Digest Access Authentication scheme used by - the Session Initiation Protocol (SIP) to add support for secure - digest algorithms to replace the broken MD5 algorithm. + 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. 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 November 10, 2019. + This Internet-Draft will expire on November 27, 2019. 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 @@ -55,119 +56,132 @@ the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The Updated SIP Digest Authentication Scheme . . . . . . . . 3 + 2. SIP Digest Authentication Scheme Updates . . . . . . . . . . 3 2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 3 - 2.2. Representation of Digest Values . . . . . . . . . . . . . 3 - 2.3. The Authenticate Response Header Field . . . . . . . . . 4 - 2.4. The Authorization Request Header Field . . . . . . . . . 4 - 2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Representation of Digest Values . . . . . . . . . . . . . 4 + 2.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 4 + 2.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 4 + 2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.6. HTTP Modifications . . . . . . . . . . . . . . . . . . . 5 - 2.7. Augmented BNF for the SIP Protocol . . . . . . . . . . . 6 + 2.7. Augmented BNF for the SIP Protocol . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 - 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 + 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The SIP protocol [RFC3261] uses the same mechanism used by the HTTP protocol for authenticating users, which is a simple challenge- response authentication mechanism that allows a server to challenge a client request and allows a client to provide authentication information in response to that challenge. The SIP protocol uses the Digest Authentication scheme that is used - with the HTTP authentication mechanism, which by default uses MD5 as - the default algorithm. + with the HTTP authentication mechanism, which uses MD5 as the default + algorithm. The HTTP Digest Access Authentication [RFC7616] document defines the Digest Authentication scheme and defines a few algorithms that could be used with the Digest Authentication scheme, and establishes a registry for these algorithms to allow for additional algorithms to be added in the future. This document updates the Digest Access Authentication scheme used by - SIP to support the list of digest algorithms defined in the "Hash - Algorithms for HTTP Digest Authentication" registry defined by - [RFC7616]. + SIP to support the algorithms defined 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]. -2. The Updated SIP Digest Authentication Scheme +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 - SHA- 256 and SHA-512/256 algorithms as described in [RFC7616], and - also to require support for the "qop" option." + 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" option. It provides additional UAC + and 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 protocol 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, and specifies a priority for each algorithm. [RFC3261] specifies only one algorithm, MD5, which is used by default. This document extends [RFC3261] to allow use of any registered algorithm. - The priority of the algorithm defines its usage preference. UAs - SHOULD prefer algorithms with higher priorities. - - Note that [RFC7616] defines a -sess variant for each algorithm; the - -sess variants are not used with SIP. + A UAS prioritizes which algorithm to use based on the ordering of the + challenge header fields in the response it is processing. 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. -2.3. The Authenticate Response Header Field +2.3. UAS Behavior When a UAS receives a request from a UAC, and an acceptable Authorization header field is not sent, 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. The UAS MAY include multiple WWW-Authenticate/Proxy- - Authenticate headers to allow the UAS to utilize the best available - algorithm supported by the client. + header field respectively. The UAS MAY include multiple WWW- + Authenticate/Proxy-Authenticate header fields to allow the UAS to + utilize the best available algorithm supported by the client. If the UAS challenges with multiple WWW-Authenticate/Proxy- - Authenticate headers with the same realm, then each one of these - headers MUST use a different digest algorithm. The UAS MUST add - these headers to the response in the order that it would prefer to - see them used, starting with the most preferred algorithm at the top, - followed by the less preferred algorithms. + Authenticate header fields with the same realm, then each one of + these header fields MUST use a different digest algorithm. The UAS + MUST add these header fields to the response in the order that it + would prefer to see them used, starting with the most preferred + algorithm at the top, followed by the less preferred algorithms. The + UAS cannot assume that the client will use the algorithm specified at + the topmost header field. -2.4. The Authorization Request Header Field +2.4. UAC Behavior When the UAC receives a response with multiple 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 include an Authorization header field containing credentials that match the topmost header field of any one of the realms. @@ -266,25 +280,25 @@ 2.7. Augmented BNF for the SIP Protocol This document updates the Augmented BNF for the SIP Protocol as follows. It extends the request-digest as follows to allow for different digest sizes: request-digest = LDQUOT *LHEX RDQUOT - The number of hex digits must be specified by the specification of - the algorithm used. + 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 SHA2 - algorithms to be 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 ) 3. Security Considerations This specification adds new secure algorithms to be used to with the Digest mechanism to authenticate users, but leaves the broken MD5 algorithm for backward compatibility. @@ -294,47 +308,56 @@ 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 will use the algorithms defined in that - registry. + in the future. This document specifies that algorithms defined in + that registry may be used in SIP digest authentication. 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, and Brian Rosen. -6. Normative References +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. +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. + Author's Address Rifaat Shekh-Yusef Avaya 425 Legget Dr. Ottawa, Ontario Canada Phone: +1-613-595-9106 EMail: rifaat.ietf@gmail.com