idnits 2.17.1 draft-yusef-sipcore-digest-scheme-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 10, 2014) is 3757 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3261' is mentioned on line 68, but not defined == Missing Reference: 'HTTP-DIGEST' is mentioned on line 211, but not defined == Missing Reference: 'CERT-VU' is mentioned on line 86, but not defined == Missing Reference: 'RFC2119' is mentioned on line 99, but not defined == Unused Reference: 'KEYWORDS' is defined on line 224, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group R. Shekh-Yusef 3 INTERNET-DRAFT Avaya 4 Intended Status: Standards Track January 10, 2014 5 Expires: July 14, 2014 7 The Session Initiation Protocol (SIP) Digest Authentication Scheme 8 draft-yusef-sipcore-digest-scheme-00 10 Abstract 12 This document updates the Digest Access Authentication scheme used by 13 the Session Initiation Protocol (SIP) to add support for SHA2 digest 14 algorithms to replace the MD5 algorithm. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright and License Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2 The SIP Digest Authentication Scheme . . . . . . . . . . . . . 3 57 3 Augmented BNF for the SIP Protocol . . . . . . . . . . . . . . 6 58 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 60 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7.1 Normative References . . . . . . . . . . . . . . . . . . . 7 63 7.2 Informative References . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1 Introduction 68 The SIP protocol [RFC3261] uses the same mechanism used by the HTTP 69 protocol for authenticating users, which is a simple challenge- 70 response authentication mechanism that allows a server to challenge a 71 client request and allows a client to provide authentication 72 information in response to that challenge. 74 The SIP protocol uses the Digest Authentication scheme that is used 75 with the HTTP authentication mechanism, which by default uses MD5 as 76 the default algorithm. 78 The HTTP Digest Access Authentication [HTTP-DIGEST] document defines 79 the challenge-response authentication mechanism and the Digest 80 Authentication scheme, and defines few algorithms that could be used 81 with the Digest Authentication scheme, and establishes a registry for 82 these algorithms to allow for additional algorithms to be added in 83 the future. 85 In 2008 the US-CERT issued a note that MD5 "should be considered 86 cryptographically broken and unsuitable for further use" [CERT-VU]. 88 This document updates the Digest Access Authentication scheme used by 89 SIP to add support for SHA2 digest algorithms to replace the MD5 90 algorithm. 92 This document replaces what is specified in RFC3261, Section 22.4. 94 1.1 Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2 The SIP Digest Authentication Scheme 102 This document describes the modifications and clarifications required 103 to apply the HTTP Digest Authentication scheme to SIP. The SIP scheme 104 usage is almost completely identical to that for HTTP [HTTP-DIGEST]. 106 Since RFC 2543 is based on HTTP Digest as defined in RFC 2069, SIP 107 servers supporting [HTTP-DIGEST] MUST ensure they are backwards 108 compatible with RFC 2069. Procedures for this backwards 109 compatibility are specified in [HTTP-DIGEST]. Note, however, that 110 SIP servers MUST NOT accept or request Basic authentication. 112 The rules for Digest authentication follow those defined in [HTTP- 113 DIGEST], with "HTTP/1.1" replaced by "SIP/2.0" in addition to the 114 following differences: 116 1. The URI included in the challenge has the following BNF: 118 URI = SIP-URI / SIPS-URI 120 2. The BNF for digest-uri-value is: 122 digest-uri-value = Request-URI 124 3. The example procedure for choosing a nonce based on Etag does 125 not work for SIP. 127 4. The text in [HTTP-DIGEST] regarding cache operation 128 does not apply to SIP. 130 5. [HTTP-DIGEST] requires that a server check that the URI in 131 the request line and the URI included in the Authorization 132 header field point to the same resource. In a SIP context, 133 these two URIs may refer to different users, due to 134 forwarding at some proxy. Therefore, in SIP, a server MAY 135 check that the Request-URI in the Authorization header field 136 value corresponds to a user for whom the server is willing to 137 accept forwarded or direct requests, but it is not 138 necessarily a failure if the two fields are not equivalent. 140 6. As a clarification to the calculation of the A2 value for 141 message integrity assurance in the Digest authentication 142 scheme, implementers should assume, when the entity-body is 143 empty (that is, when SIP messages have no body) that the hash 144 of the entity-body resolves to the hash of an empty 145 string as follows: 147 H(entity-body) = MD5("") = 148 "d41d8cd98f00b204e9800998ecf8427e" 150 H(entity-body) = SHA2-256("") = 151 "TODO" 153 H(entity-body) = SHA2-512-256("") = 154 "TODO" 156 7. [HTTP-DIGEST] notes that a cnonce value MUST NOT be sent in an 157 Authorization (and by extension Proxy-Authorization) header 158 field if no qop directive has been sent. Therefore, any 159 algorithms that have a dependency on the cnonce (including 160 "MD5-sess", "SHA2-256-sess", and "SHA2-512-256-sess") require 161 that the qop directive be sent. Use of the "qop" parameter 162 is optional in [HTTP-DIGEST] for the purposes of backwards 163 compatibility with RFC 2069; since RFC 2543 was based on 164 RFC 2069, the "qop" parameter must unfortunately 165 remain optional for clients and servers to receive. However, 166 servers MUST always send a "qop" parameter in WWW-Authenticate 167 and Proxy-Authenticate header field values. If a client 168 receives a "qop" parameter in a challenge header field, it 169 MUST send the "qop" parameter in any resulting authorization 170 header field. 172 RFC 2543 did not allow usage of the Authentication-Info header field 173 (it effectively used RFC 2069). However, we now allow usage of this 174 header field, since it provides integrity checks over the bodies and 175 provides mutual authentication. [HTTP-DIGEST] defines mechanisms for 176 backwards compatibility using the qop attribute in the request. These 177 mechanisms MUST be used by a server to determine if the client 178 supports the new mechanisms in [HTTP-DIGEST] that were not specified 179 in RFC 2069. 181 [OPEN ISSUE:] 183 Should the backward compatibility with RFC2543/RFC2069 be deprecated? 185 3 Augmented BNF for the SIP Protocol 187 This document updates the Augmented BNF for the SIP Protocol as 188 follows. 190 It extends the request-digest as follows to allow for different 191 digest sizes: 193 request-digest = LDQUOT digest-size LHEX RDQUOT 194 digest-size = "32" / "64" 196 It extends the algorithm parameter as follows to allow for SHA2 197 algorithms to be used: 199 algorithm = "algorithm" EQUAL ( 200 "MD5" / "MD5-sess" / 201 "SHA2-256" / "SHA2-256-sess" / 202 "SHA2-512-256" / "SHA2-512-256-sess" / 203 token ) 205 4 Security Considerations 207 209 5 IANA Considerations 211 The [HTTP-DIGEST] defines an IANA registry named "HTTP Digest Hash 212 Algorithms" to simplify the introduction of new algorithms in the 213 future. This document will use the algorithms defined in that 214 registry. 216 6 Acknowledgments 218 220 7 References 222 7.1 Normative References 224 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 7.2 Informative References 229 Authors' Addresses 231 Rifaat Shekh-Yusef 232 Avaya 233 250 Sydney Street 234 Belleville, Ontario 235 Canada 237 Phone: +1-613-967-5267 238 Email: rifaat.ietf@gmail.com