--- 1/draft-ietf-sipcore-digest-scheme-00.txt 2019-05-08 05:13:16.145040697 -0700 +++ 2/draft-ietf-sipcore-digest-scheme-01.txt 2019-05-08 05:13:16.165041202 -0700 @@ -1,19 +1,19 @@ SIP Core R. Shekh-Yusef Internet-Draft Avaya -Updates: 3261 (if approved) April 18, 2019 +Updates: 3261 (if approved) May 7, 2019 Intended status: Standards Track -Expires: October 20, 2019 +Expires: November 8, 2019 The Session Initiation Protocol (SIP) Digest Authentication Scheme - draft-ietf-sipcore-digest-scheme-00 + draft-ietf-sipcore-digest-scheme-01 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. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,21 +22,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 October 20, 2019. + This Internet-Draft will expire on November 8, 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 @@ -58,22 +58,22 @@ 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 SIP Digest Authentication Scheme . . . . . . . . . . . . 3 2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 3 2.2. Representation of Digest Values . . . . . . . . . . . . . 3 - 2.3. The Authenticate Response Header . . . . . . . . . . . . 4 - 2.4. The Authorization Request Header . . . . . . . . . . . . 4 + 2.3. The Authenticate Response Header Field . . . . . . . . . 4 + 2.4. The Authorization Request Header Field . . . . . . . . . 4 2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.6. HTTP Modifications . . . . . . . . . . . . . . . . . . . 5 3. Augmented BNF for the SIP Protocol . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction @@ -136,48 +136,48 @@ 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 +2.3. The Authenticate Response Header Field When a UAS receives a request from a UAC, and an acceptable - Authorization header is not sent, the UAS can challenge the + 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. 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. -2.4. The Authorization Request Header +2.4. The Authorization Request Header Field - When the UAC receives a response with multiple headers with the same - realm it SHOULD use the topmost header that it supports, unless a - local policy dictates otherwise. The client MUST ignore any + 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 - headers with different realms it SHOULD retry and include an - Authorization header containing credentials that match the topmost - header of any one of the realms. + 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. 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 for any of the realms. 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 introduces some clarification to @@ -193,33 +193,35 @@ 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. 2.6. HTTP 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. The changes specified here - are mostly copied from section 22.4 of [RFC3261] with few changes. + 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 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" replaced by "SIP/2.0" in addition to the following differences: 1. The URI included in the challenge has the following BNF: - URI = Request-URI + 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 4. The example procedure for choosing a nonce based on Etag does not work for SIP.