SIP Working Group James Undery Internet Draft Ubiquity Category: Standards Track Sanjoy Sen Expires on Dec 2002 Nortel Networks Vesa Torvinen Ericsson June 2002 Enhanced Usage of HTTP Digest Authentication for SIP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract HTTP Digest has some shortcomings if applied for SIP. Firstly, SIP UA has serious difficulties to distinguish the source of Authentication-Info and Proxy-Authentication-Info headers in SIP forking situations. This is due to the absence of the ærealmÆ parameter in these headers. Secondly, HTTP authentication is particularly vulnerable against MITM bid-down attacks on the list of algorithms (e.g., MD-5, SHA-1) or the desired security level (auth, auth-int). Thirdly, HTTP authentication provides limited integrity protection of only the message body. In SIP, important information can be carried in many of the headers that may need integrity protection. This draft proposes to add the realm parameter in the *- Authentication-Info headers, recommends a format for computing the Undery/Sen/Torvinen [Page 1] Internet Draft Enhanced Usage of HTTP Digest June 2002 nonce for detection of bid-down attack and proposes a mechanism for integrity protection of SIP headers using MIME body. 1 Introduction HTTP Digest [3] has some shortcomings if applied for SIP. RFC 3261 [2] allows the use of Authentication-Info header in responses for mutual authentication between the client and the server. As these headers currently do not contain the ærealmÆ parameter, the client has serious difficulties to distinguish the source of Authentication- Info headers if the SIP request is forked. Thus there is no way for the client to match the credential carried in the Authentication-Info header with the corresponding challenge. HTTP authentication is also vulnerable against MITM bid-down attacks, possibly on the algorithms (e.g., MD-5, SHA-1) or on the protection levels (auth, auth-int). A MITM attacker can easily remove the stronger mechanism among the existing mechanisms in the challenge (e.g., remove æauth-intÆ from a challenge containing both æauthÆ and æauth-intÆ). Also, HTTP authentication provides limited integrity protection of only the message body. In SIP, important information can be carried in many of the headers that may need integrity protection. This draft proposes to add the realm parameter in the *- Authentication-Info headers, recommends a format for computing the nonce for detection of bid-down attack and proposes a mechanism for integrity protection of SIP headers using MIME body. 2 Conventions used in this document 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 RFC-2119. 3 Syntax for Authentication-Info header The Authentication-Info header is used by the server to communicate some information regarding the successful authentication in the response. The modified syntax is shown. The two new parameters added are ærealmÆ and æauth-paramÆ. AuthenticationInfo = "Authentication-Info" ":" auth-info auth-info = 1#(nextnonce | realm | [message-qop] | [response-auth ] | [cnonce] | [nonce-count] | [auth-param]) nextnonce = "nextnonce" "=" nonce-value response-auth = "rspauth" "=" response-digest response-digest = <"> *LHEX <"> Undery/Sen/Torvinen Expires Dec 2002 [Page 2] Internet Draft Enhanced Usage of HTTP Digest June 2002 realm A string contained in the server challenge that can be rendered for the end user to provide the context with which to authenticate itself. The ærealmÆ parameter in Authentication-Info header SHOULD contain the same value as the corresponding element carried in the most recent challenge from the server. auth-param This is included for future extensions; unknown values should be ignored. The same syntax changes apply to the Proxy-Authentication-Info header that can be added by the Proxies in responses to UAC. 4 Recommendation for nonce construction Traditionally nonces have contained no meaning for the client, however, in order to detect bid-down attacks this draft will recommend a format. This format is designed to allow a server to encode the list that needs to be protected against bid-down attack. The following definition will replace nonce-value: nonce-value = LDQUOT "(" 1#auth-prefix ")" trad-nonce-value RDQUOT auth-prefix = auth-algorithms | digest-auth-type | token auth-algorithms = "MD5" | "AKA" | "SHA1" auth-type = "auth" | "auth-int" trad-nonce-value = *(qdtext | quoted-pair) auth-algorithm These are the algorithms used by the Digest scheme to produce the digest. auth-type These are the protection levels for Digest authentication. Each value corresponds to a qop-value. The client compares the list of algorithms or protection level values with that encoded in the nonce to detect a bid-down attack. If the attacker modifies the auth-prefix in the nonce, then the digest credential computed by the server with the original nonce will not match that in the Digest response and the attack will be detected. A possible implementation of trad-nonce-value is: Undery/Sen/Torvinen Expires Dec 2002 [Page 3] Internet Draft Enhanced Usage of HTTP Digest June 2002 trad-nonce-value = time-stamp "-" H(time-stamp ":" request-uri ":" private-key) where, the time-stamp is a non repeating value, the request-uri is the Request URI from the request and the private-key is to ensure that the nonce was generated by an entity that knows the private- key. The auth-prefix MAY be included in the hash function above. The inclusion of the auth-prefix in the hash is only really useful if the server generating the challenge varies the challenge on a request-by-request basis and does not want to reevaluate its policy rules. 5 Integrity protection of headers by the client If the client wants to integrity protect certain headers and if the server supports the level of protection æauth-intÆ, the client can do so by using the process of including headers in the message body by using MIME type æmessage/sipfragÆ, as described in [6] or by using the mechanism of tunneling entire SIP messages by using MIME type æmessage/sipÆ as discussed in [2]. A valid æmessage/sipfragÆ message body is formed by taking the original SIP message and deleting either (1) entire start-line, or (2) one or more complete headers, or (3) entire body. The qop parameter in the Authorization or Proxy-Authorization header MUST be set to æauth-intÆ. This can be used to provide hop-by-hop, end-to- end, end-to-middle or middle-to-end integrity protection of selected headers using Digest. Some of the headers that can be integrity protected by this mechanism are: From, To, Call-ID, Contact, CSeq, Expires etc. An example of using this mechanism to protect a SIP header (Security-Verify) is discussed in [7]. The MIME type æmessage/sipÆ can be used for integrity protection of entire SIP message. The same mechanism can also be used by the server (or Proxy) to integrity protect headers, the response Status Code or the entire response message using the Authentication-Info (or Proxy- Authentication-Info) header. 6 Client and Server Behavior The server MUST include the ærealmÆ parameter in the Authentication- Info header. The server MUST ignore any æauth-paramÆ value that it does not understand. Otherwise, the semantic for the Authentication- Info header is the same as in [3]. Undery/Sen/Torvinen Expires Dec 2002 [Page 4] Internet Draft Enhanced Usage of HTTP Digest June 2002 For bid-down attack detection, the client MUST compare the list of algorithms or protection levels in the challenge with those encoded in the nonce. The server MUST store the original nonce that it had sent in the challenge and use it to compute the credential to match against the credential sent by the client. If the client wants to integrity protect one or more headers of the SIP message, then it MUST use the process of including headers in the message body by using MIME type æmessage/sipfragÆ as described in [6]. If the client wants to integrity protect the entire SIP message, then it MUST use the process of including entire SIP message in the message body (tunneling) using MIME type æmessage/sipÆ as discussed in [2]. In both cases, the qop parameter in the Authorization or Proxy-Authorization header MUST be set to æauth-intÆ. The client MUST use the mechanism for computing Digest credential for qop = auth-int, as described in [3]. 7 Security Considerations The purpose of this draft is security. Items ruled out of scope of this document are privacy and resistance to denial of service attacks. Since this draft either proposes fix to RFC 2617 headers or discusses application of RFC 2617 for SIP, most of the security considerations discussed in [3] are applicable here. Note that, two of the mechanisms proposed in this draft û bid-down detection and integrity protection of headers / entire message û have to be initiated by the client. There is no way for the server or the Proxy to request that the client uses these mechanisms. [7] discusses a way that can be used by the server (or Proxy) to negotiate the use of these mechanisms with the client. The bid-down protection mechanism does not include algorithm revocation mechanisms. The result of this is if a one-way hashing algorithm is broken such that a message s + m can be recovered from KD(s + m) if m is known; or given a message s + m, it is possible to find n such that KD(s + m) = KD(s + n) for constant unknown s. Then this mechanism will fail, although in the second case m and n will have to be syntactically equivalent. 7.1 Security Considerations Missing From RFC 2617 RFC 2617 [3] has a remarkably thorough security considerations section, however, in our opinion an important consideration is missed. In the WWW-Authenticate header the qop directive can contain a list of schemes supported. It is possible for an attacker to downgrade the security on offer by removing auth-int if present so the body of the message is not included in the protection, or simply remove the qop parameter entirely. Undery/Sen/Torvinen Expires Dec 2002 [Page 5] Internet Draft Enhanced Usage of HTTP Digest June 2002 8 Future Work Future work on this topic should include the following: - A mechanism for the server to recommend the list of headers that needs to be integrity protected - A way for the server to specify the protection mechanism to be used in the challenge - Authentication of Proxies by the UAS 9 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Handley, M., Schulzrinne, H, Schooler, E. and Rosenberg, J., "SIP: Session Initiation Protocol", RFC 3261. 3 Franks, J. et al, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. 4 Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998. 5 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. 6 Sparks, R., "Internet Media Types message/sip and message/sipfrag", draft-sparks-sip-mimetypes-01 (work in progress), March 2002. 7. Arkko, et. Al., "Security Mechanism Agreement for SIP Sessions", draft-ietf-sip-sec-agree-02.txt, May 2002. 10 Acknowledgments The authors acknowledge that the idea of using æmessage/sip-fragÆ to provide integrity protection of SIP headers using Digest was proposed by Henning. 11 Authors' Addresses James Undery Ubiquity Software Corporation Ltd. Ubiquity House Undery/Sen/Torvinen Expires Dec 2002 [Page 6] Internet Draft Enhanced Usage of HTTP Digest June 2002 Langstone Park Newport, UK Email: jundery@ubiquity.net Sanjoy Sen Nortel Networks sanjoy@nortelnetworks.com Richardson, Texas Email: sanjoy@nortelnetworks.com Vesa Torvinen Oy LM Ericsson Ab Email: vesa.torvinen@ericsson.fi 12 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Undery/Sen/Torvinen Expires Dec 2002 [Page 7]