idnits 2.17.1 draft-undery-sip-auth-01.txt: -(69): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(102): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(161): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(171): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(187): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(188): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(200): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(204): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(206): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(278): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 20 instances of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7986 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 section? '3' on line 234 looks like a reference -- Missing reference section? '2' on line 204 looks like a reference -- Missing reference section? '6' on line 201 looks like a reference -- Missing reference section? '7' on line 220 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group James Undery 3 Internet Draft Ubiquity 4 Category: Standards Track 5 Sanjoy Sen 6 Expires on Dec 2002 Nortel Networks 8 Vesa Torvinen 9 Ericsson 11 June 2002 13 Enhanced Usage of HTTP Digest Authentication for SIP 15 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance 20 with all provisions of Section 10 of RFC2026. 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 Internet- 24 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 HTTP Digest has some shortcomings if applied for SIP. Firstly, SIP 40 UA has serious difficulties to distinguish the source of 41 Authentication-Info and Proxy-Authentication-Info headers in SIP 42 forking situations. This is due to the absence of the �realm� 43 parameter in these headers. Secondly, HTTP authentication is 44 particularly vulnerable against MITM bid-down attacks on the list of 45 algorithms (e.g., MD-5, SHA-1) or the desired security level (auth, 46 auth-int). Thirdly, HTTP authentication provides limited integrity 47 protection of only the message body. In SIP, important information 48 can be carried in many of the headers that may need integrity 49 protection. This draft proposes to add the realm parameter in the *- 50 Authentication-Info headers, recommends a format for computing the 51 nonce for detection of bid-down attack and proposes a mechanism for 52 integrity protection of SIP headers using MIME body. 54 1 Introduction 56 HTTP Digest [3] has some shortcomings if applied for SIP. RFC 3261 57 [2] allows the use of Authentication-Info header in responses for 58 mutual authentication between the client and the server. As these 59 headers currently do not contain the �realm� parameter, the client 60 has serious difficulties to distinguish the source of Authentication- 61 Info headers if the SIP request is forked. Thus there is no way for 62 the client to match the credential carried in the Authentication-Info 63 header with the corresponding challenge. 65 HTTP authentication is also vulnerable against MITM bid-down attacks, 66 possibly on the algorithms (e.g., MD-5, SHA-1) or on the protection 67 levels (auth, auth-int). A MITM attacker can easily remove the 68 stronger mechanism among the existing mechanisms in the challenge 69 (e.g., remove �auth-int� from a challenge containing both �auth� and 70 �auth-int�). Also, HTTP authentication provides limited integrity 71 protection of only the message body. In SIP, important information 72 can be carried in many of the headers that may need integrity 73 protection. This draft proposes to add the realm parameter in the *- 74 Authentication-Info headers, recommends a format for computing the 75 nonce for detection of bid-down attack and proposes a mechanism for 76 integrity protection of SIP headers using MIME body. 78 2 Conventions used in this document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 82 this document are to be interpreted as described in RFC-2119. 84 3 Syntax for Authentication-Info header 86 The Authentication-Info header is used by the server to communicate 87 some information regarding the successful authentication in the 88 response. The modified syntax is shown. The two new parameters added 89 are �realm� and �auth-param�. 91 AuthenticationInfo = "Authentication-Info" ":" auth-info 92 auth-info = 1#(nextnonce | realm | [message-qop] 93 | [response-auth ] | [cnonce] 94 | [nonce-count] | [auth-param]) 95 nextnonce = "nextnonce" "=" nonce-value 96 response-auth = "rspauth" "=" response-digest 97 response-digest = <"> *LHEX <"> 99 realm 100 A string contained in the server challenge that can be rendered 101 for the end user to provide the context with which to authenticate 102 itself. The �realm� parameter in Authentication-Info header SHOULD 103 contain the same value as the corresponding element carried in the 104 most recent challenge from the server. 106 auth-param 107 This is included for future extensions; unknown values should be 108 ignored. 110 The same syntax changes apply to the Proxy-Authentication-Info 111 header that can be added by the Proxies in responses to UAC. 113 4 Recommendation for nonce construction 115 Traditionally nonces have contained no meaning for the client, 116 however, in order to detect bid-down attacks this draft will 117 recommend a format. This format is designed to allow a server to 118 encode the list that needs to be protected against bid-down attack. 120 The following definition will replace nonce-value: 122 nonce-value = LDQUOT "(" 1#auth-prefix ")" 123 trad-nonce-value RDQUOT 124 auth-prefix = auth-algorithms | digest-auth-type | token 125 auth-algorithms = "MD5" | "AKA" | "SHA1" 126 auth-type = "auth" | "auth-int" 127 trad-nonce-value = *(qdtext | quoted-pair) 129 auth-algorithm 130 These are the algorithms used by the Digest scheme to produce the 131 digest. 133 auth-type 134 These are the protection levels for Digest authentication. Each 135 value corresponds to a qop-value. 137 The client compares the list of algorithms or protection level 138 values with that encoded in the nonce to detect a bid-down attack. 139 If the attacker modifies the auth-prefix in the nonce, then the 140 digest credential computed by the server with the original nonce 141 will not match that in the Digest response and the attack will be 142 detected. 144 A possible implementation of trad-nonce-value is: 146 trad-nonce-value = time-stamp "-" H(time-stamp ":" request-uri 147 ":" private-key) 149 where, the time-stamp is a non repeating value, the request-uri is 150 the Request URI from the request and the private-key is to ensure 151 that the nonce was generated by an entity that knows the private- 152 key. The auth-prefix MAY be included in the hash function above. The 153 inclusion of the auth-prefix in the hash is only really useful if 154 the server generating the challenge varies the challenge on a 155 request-by-request basis and does not want to reevaluate its policy 156 rules. 158 5 Integrity protection of headers by the client 160 If the client wants to integrity protect certain headers and if the 161 server supports the level of protection �auth-int�, the client can 162 do so by using the process of including headers in the message body 163 by using MIME type �message/sipfrag�, as described in [6] or by 164 using the mechanism of tunneling entire SIP messages by using MIME 165 type �message/sip� as discussed in [2]. 167 A valid �message/sipfrag� message body is formed by taking the 168 original SIP message and deleting either (1) entire start-line, or 169 (2) one or more complete headers, or (3) entire body. The qop 170 parameter in the Authorization or Proxy-Authorization header MUST be 171 set to �auth-int�. This can be used to provide hop-by-hop, end-to- 172 end, end-to-middle or middle-to-end integrity protection of selected 173 headers using Digest. Some of the headers that can be integrity 174 protected by this mechanism are: From, To, Call-ID, Contact, CSeq, 175 Expires etc. An example of using this mechanism to protect a SIP 176 header (Security-Verify) is discussed in [7]. The MIME type 177 �message/sip� can be used for integrity protection of entire SIP 178 message. 180 The same mechanism can also be used by the server (or Proxy) to 181 integrity protect headers, the response Status Code or the entire 182 response message using the Authentication-Info (or Proxy- 183 Authentication-Info) header. 185 6 Client and Server Behavior 187 The server MUST include the �realm� parameter in the Authentication- 188 Info header. The server MUST ignore any �auth-param� value that it 189 does not understand. Otherwise, the semantic for the Authentication- 190 Info header is the same as in [3]. 192 For bid-down attack detection, the client MUST compare the list of 193 algorithms or protection levels in the challenge with those encoded 194 in the nonce. The server MUST store the original nonce that it had 195 sent in the challenge and use it to compute the credential to match 196 against the credential sent by the client. 198 If the client wants to integrity protect one or more headers of the 199 SIP message, then it MUST use the process of including headers in 200 the message body by using MIME type �message/sipfrag� as described 201 in [6]. If the client wants to integrity protect the entire SIP 202 message, then it MUST use the process of including entire SIP 203 message in the message body (tunneling) using MIME type 204 �message/sip� as discussed in [2]. In both cases, the qop parameter 205 in the Authorization or Proxy-Authorization header MUST be set to 206 �auth-int�. The client MUST use the mechanism for computing Digest 207 credential for qop = auth-int, as described in [3]. 209 7 Security Considerations 211 The purpose of this draft is security. Items ruled out of scope of 212 this document are privacy and resistance to denial of service 213 attacks. Since this draft either proposes fix to RFC 2617 headers or 214 discusses application of RFC 2617 for SIP, most of the security 215 considerations discussed in [3] are applicable here. 217 Note that, two of the mechanisms proposed in this draft � bid-down 218 detection and integrity protection of headers / entire message � 219 have to be initiated by the client. There is no way for the server 220 or the Proxy to request that the client uses these mechanisms. [7] 221 discusses a way that can be used by the server (or Proxy) to 222 negotiate the use of these mechanisms with the client. 224 The bid-down protection mechanism does not include algorithm 225 revocation mechanisms. The result of this is if a one-way hashing 226 algorithm is broken such that a message s + m can be recovered from 227 KD(s + m) if m is known; or given a message s + m, it is possible to 228 find n such that KD(s + m) = KD(s + n) for constant unknown s. Then 229 this mechanism will fail, although in the second case m and n will 230 have to be syntactically equivalent. 232 7.1 Security Considerations Missing From RFC 2617 234 RFC 2617 [3] has a remarkably thorough security considerations 235 section, however, in our opinion an important consideration 236 is missed. In the WWW-Authenticate header the qop directive can 237 contain a list of schemes supported. It is possible for an attacker 238 to downgrade the security on offer by removing auth-int if present 239 so the body of the message is not included in the protection, or 240 simply remove the qop parameter entirely. 242 8 Future Work 244 Future work on this topic should include the following: 246 - A mechanism for the server to recommend the list of headers that 247 needs to be integrity protected 248 - A way for the server to specify the protection mechanism to be 249 used in the challenge 250 - Authentication of Proxies by the UAS 252 9 References 254 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 255 9, RFC 2026, October 1996. 257 2 Handley, M., Schulzrinne, H, Schooler, E. and Rosenberg, J., 258 "SIP: Session Initiation Protocol", RFC 3261. 260 3 Franks, J. et al, "HTTP Authentication: Basic and Digest Access 261 Authentication", RFC 2617, June 1999. 263 4 Bellovin, S., "Report of the IAB Security Architecture Workshop", 264 RFC 2316, April 1998. 266 5 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 267 1992. 269 6 Sparks, R., "Internet Media Types message/sip and 270 message/sipfrag", draft-sparks-sip-mimetypes-01 (work in progress), 271 March 2002. 273 7. Arkko, et. Al., "Security Mechanism Agreement for SIP Sessions", 274 draft-ietf-sip-sec-agree-02.txt, May 2002. 276 10 Acknowledgments 278 The authors acknowledge that the idea of using �message/sip-frag� to 279 provide integrity protection of SIP headers using Digest was 280 proposed by Henning. 282 11 Authors' Addresses 284 James Undery 285 Ubiquity Software Corporation Ltd. 286 Ubiquity House 287 Langstone Park 288 Newport, UK 289 Email: jundery@ubiquity.net 291 Sanjoy Sen 292 Nortel Networks 293 sanjoy@nortelnetworks.com 294 Richardson, Texas 295 Email: sanjoy@nortelnetworks.com 297 Vesa Torvinen 298 Oy LM Ericsson Ab 299 Email: vesa.torvinen@ericsson.fi 301 12 Full Copyright Statement 303 Copyright (C) The Internet Society (2000). All Rights Reserved. 305 This document and translations of it may be copied and furnished to 306 others, and derivative works that comment on or otherwise explain it 307 or assist in its implementation may be prepared, copied, published 308 and distributed, in whole or in part, without restriction of any 309 kind, provided that the above copyright notice and this paragraph 310 are included on all such copies and derivative works. However, this 311 document itself may not be modified in any way, such as by removing 312 the copyright notice or references to the Internet Society or other 313 Internet organizations, except as needed for the purpose of 314 developing Internet standards in which case the procedures for 315 copyrights defined in the Internet Standards process must be 316 followed, or as required to translate it into languages other than 317 English. The limited permissions granted above are perpetual and 318 will not be revoked by the Internet Society or its successors or 319 assigns. This document and the information contained 320 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 321 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 322 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 323 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 324 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 325 PARTICULAR PURPOSE."