Internet Engineering Task Force J. Undery Internet Draft Ubiquity Document: draft-undery-sip-digest-00.txt July 2001 Category: Experimental SIP Authentication: SIP Digest Access Authentication Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract The Session Initiation Protocol [2] currently uses the HTTP digest authentication algorithm [3] for simple authentication of SIP requests. This scheme does not allow for the inclusion of headers important to the integrity of a SIP request including To, From, Call-ID, CSeq, Contact and Expires headers. This document attempts to address this issue. Examples of possible attacks involve capturing authenticated messages on the wire, modifying headers and resending the message. This makes it possible to modify registration details and initiate sessions with entities requiring authentication. 2. Introduction RFC 2617 [3] defines two methods for a HTTP client to authenticate itself to a server, Basic and Digest. These methods are used by SIP to provide similar protection. Basic authentication sends passwords in cleartext and its use is not recommended [4]. Digest authentication as used by SIP uses a cryptographic hash of a number of elements including the request method, URI and optionally the body of the message. It is believed that Digest authentication is Undery Experimental - Expires January 2002 1 draft-undery-sip-digest-00.txt July 2001 the most commonly used mechanism for a SIP client to authenticate itself to a server today. Unfortunately Digest authentication fails to provide authentication of a number of headers critical to the integrity of a SIP request. This enables a number of attacks against servers, by attackers pretending to be the client and modifying authenticated messages. To fix this problem it is necessary to implement a new authentication scheme, previous documents [5] have tried a backward compatible approach that fails to address many of the issues involved. This document attempts to 'patch' RFC 2617 to provide a better solution for SIP. 3. Perceived Threats In this section we will describe the threats to security that we attempt to address and those that will be ignored. This section will not discuss the complexity of exploiting these threats because according to [4], "A threat is, by definition, a vulnerability available to a motivated and capable adversary". The fact it exists is enough. 3.1. Addressed Threats Replay attacks: this is really an issue of how the server creates and expires its nonces, section 4.2.1 describes a mechanism that can be used to help by including a timestamp in the nonces, that combined with the protecting headers can prevent replay attacks. Man in the Middle: attacks, this is where messages are altered by the attacker. The main purpose of this draft is to allow a server to decide which headers it requires to be included in the credentials. Any headers not chosen by the server will be vulnerable, and known to a potential attacker. It should be impossible for an attacker to alter any of the headers the server deems relevant to protect. The weakness here is a server may decide the Subject header is irrelevant, yet the recipient of the message might not appreciate an INVITE with an offensive subject injected by an intermediate proxy. Masquerade attacks: this is where an attacker inserts himself into the signaling path and attempts to fool the client into providing credentials the attacker can use to create a false message. The last two issues are addressed by both the client and server using the same set of headers for inclusion in the credentials and checking them. Any change to these headers will result in the credentials being invalid for the request. 3.2. Unaddressed Threats Undery Experimental - Expires January 2002 2 draft-undery-sip-digest-00.txt July 2001 Privacy will be totally out of scope; both data and system usage are unprotected by RFC 2617 and will be ignored by this draft too. In order to protect privacy, encryption is required. Denial of service this is also out of scope. Authentication inherently requires some level of additional work on behalf of the server and client. This additional load makes it easier to overwhelm the resources of the victim. Reliability of results is also out of scope as this document is concerned with authenticating the client to the server and not vice versa. [[ Author's note I am unsure why AuthorizationInfo was left out of SIP and I am trying to track down if it was ever discussed, however, I don't wish to suggest a new header at this point that wouldn't be backwardly compatible, Authorization although a request header can appear in responses and presumably fills AuthorizationInfo's role ?? ]] 4. SIP Digest Access Authentication Scheme 4.1. Introduction RFC 2617 describes the Digest authentication scheme. This scheme is subject to the operation and limitations as described in RFC 2617. Namely, it relies on a shared secret between the client and server and provides no mechanism for distributing those secrets; it provides no 'hiding' of the payload or headers. The change is purely to provide the same semantic integrity to SIP, as provided to HTTP by including the Method and URI in the credentials. 4.2. Specification of SIP Digest Headers 4.2.1. WWW-Authenticate Response Header The following BNF is used in the same context as RFC 2617 challenge = "SIPDigest" sipdigest-challenge sipdigest-challenge = 1# ( realm | [domain] | nonce | [opaque] | [stale]| [algorithm] | [auth-params] | header-options ) realm = "realm" "=" realm-value realm-value = quoted-string ; See Appendix C of [2] domain = "domain" "=" domain-value Undery Experimental - Expires January 2002 3 draft-undery-sip-digest-00.txt July 2001 domain-value = <"> SIP-URL <"> nonce = "nonce" "=" nonce-value nonce-value = quoted-string opaque = "opaque" "=" quoted-string stale = "stale" "=" ("true" | "false") algorithm = "algorithm" "=" ("MD5" | token ) auth-params = token "=" quoted-string header-options = "header" "=" <"> 1#header-value <"> header-value = "To" | "From" | "Contact" | "Expires" | "CSeq" | "CallID" | extension-header extension-header = token realm A string that can be rendered for the end user to provide the context with which to authenticate itself. domain A quoted SIP URL that corresponds to the request uri of the request as it arrives at the server. For registration in the domain example.com this would be sip:example.com. [[ Author's note does domain make sense in the case of non REGISTER requests i.e. sip:user1@domainA may have become sip:user2@domainB with no obvious correlation. The realm seems more important. ]] nonce A server-specified data string ideally uniquely generated for each 401 response. Care should be taken generating this value to ensure it is unique and other parties should not be able to predict its value. A possible implementation is; nonce-value = time-stamp "-" H(time-stamp ":" request-uri ":" private-key) where, the time-stamp is a non repeating value or time stamp, the request-uri is the Request URI from the request and the private- key is to ensure the nonce was generated by an entity that knows the private-key. [[ Author's note two requests close enough together will produce the same nonce, however, it should be impossible for an attacker to gain SIP Digest credentials using this. ]] opaque A string of data specified by the server, which should be returned by the client unchanged in the Authorization header. stale A flag indicating if the previous request from the client was rejected because the nonce was stale and the client should retry with the new nonce. If this value is anything other than "true", or is not present, the username and/or password are invalid. Undery Experimental - Expires January 2002 4 draft-undery-sip-digest-00.txt July 2001 algorithm A string containing the hashing algorithm used for the authentication. Currently this is only MD5 and should be assumed to be so by default. [6] auth-params This is included for future extensions unknown values should be ignored. header-options This directive specifies which header the server requires the client to include in its credentials. It is a quoted space separated list of headers. Unknown values mentioned should be assumed to be the names of headers in a SIP request that will be included in the credentials the same way as known values, using the capitalisation in the header-value. 4.2.2. Authorization Request Header credentials = "SIPDigest" sipdigest-response sipdigest-response = 1# ( username | realm | nonce | digest-uri | sipresponse | [algorithm] | cnonce | [opaque] | nonce-count | [auth-param] | header-options ) username = "username" "=" username-value username-value = quoted-string digest-uri = "uri" "=" <"> SIP-URL <"> sipresponse = "response" "=" siprequest-digest siprequest-digest = 32LHEX cnonce = "cnonce" "=" cnonce-value cnonce-value = quoted-string nonce-count = "nc" "=" nc-value nc-value = 8LHEX username The user's name in the realm in which it is trying to authenticate itself. digest-uri This is the Request-URI the client is using to send the request. This may have changed in transit so is included here. sip-response This is a string of 32 hex digits computed as defined below, which proves the user knows a password and the headers covered in header-options have not been altered. Undery Experimental - Expires January 2002 5 draft-undery-sip-digest-00.txt July 2001 cnonce This is a compulsory value returned by the client to the server for prevention of chosen plaintext attacks. nonce-count The nc-value is a hexadecimal count of the number of requests that the client has sent using this nonce. header-options This is a quoted space separated list of the headers that the client encoded into the header-list used to calculate S2. Its value MUST be a superset of the values in the WWW-Authenticate header. i.e. The client can add but not remove headers from the list, this can be used by the client to negotiate up the protection it provides to the integrity of messages. 4.3. SIP Digest Operation siprequest-digest = <"> H( unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" S1 ":" S2 ) <"> [[ Author's note I've reduced the amount of hashing, and as a result had to rearrange the digest to prevent a Man in the Middle attack where a nonce is constructed and HTTP digest used to fool a client into providing SIP Digest credentials unwittingly when it doesn't use a cnonce. ]] 4.3.1. Computing S1 S1 = H(unq(username-value) ":" unq(realm-value) ":" passwd ) This definition of S1 allows the server to store the value of S1 linked to the user name. This removes the need for the user's password, however, if this hash is obtained the user's account is still compromised in this realm. 4.3.2. Computing S2 S2 = Method ":" digest-uri-value ":" entity-body ":" header-list header-list = *headers headers = (to-addr | from-addr | contact-value Undery Experimental - Expires January 2002 6 draft-undery-sip-digest-00.txt July 2001 | cseq-value | callid-value |expires-value | other-value) to-addr = To eol-marker from-addr = From eol-marker contact-value = Contact eol-marker cseq-value = CSeq eol-marker callid-value = Call-ID eol-marker expires-value = Expires eol-marker other-value = field-name ":" [field-value] eol-marker eol-marker = headers These are the relevant headers converted to canonical form [2] with the addition that Contact headers always include the < and > delimiters even if the display name is empty. i.e. 1 No short form header fields. 2 Header field names are capitalised as shown in [2]. 3 No white space between the header name and the colon. 4 A single white space after the colon. 5 Line termination with a CRLF. 6 No line folding. 7 No comma separated lists of header values, each must appear as a separate header. 8 Only a single white space between tokens, between tokens and quoted strings, and between quoted strings. No space after the last token. 9 No LWS between tokens and separators, except as described above. 10 The To, From and Contact header fields always include < and > delimiters even if the display-name is empty. The other-value is left in for the inclusion of headers the author omitted (only long form headers should be used). It should also be noted Authorization, Max-Forwards, Proxy-Authorization, Record- Route, Route and Via headers MUST NOT appear in this list, as they are altered or added/removed in the course of normal signaling. 5. Examples The following example shows the how a client should respond to a request to authenticate its REGISTER request. SIP/2.0 401 Unauthorised WWW-Authenticate: SIPDigest realm="Vacuity Proxy", nonce="9912345-0123456789abcdef0123456789abcdef", header="To From Expires Made-Up-Header" ... The UA then decides that for REGISTER requests it should protect the Contact header so adds it to the list of header-options. It is Undery Experimental - Expires January 2002 7 draft-undery-sip-digest-00.txt July 2001 assumed the UA will prompt the client for the username and password for the realm "Vacuity Proxy" before responding with, REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 10.0.0.10 Authorization: SIPDigest username="auser", realm="Vacuity Proxy", nonce="9912345-0123456789abcdef0123456789abcdef", uri="sip:example.com", response=fedcba9876543210fedcba9876543210, cnonce="9912390-12345678123456781234567812345678", nc=00000001, header="To From Expires Contact Made-Up-Header" To: A User From: A User ;tag=1234 Call-ID: 12321@a.example.com CSeq: 2 REGISTER Contact: sip:10.0.0.10:5061, sip:10.0.0.37 m: sip:auser@home.example.com;example=madeup In the above example the header-list used will be "To: A User From: A User ;tag=1234 Expires: Contact: Contact: Contact: ;example=madeup Made-Up-Header: " [[ Author's note I should really provide a worked example or some skeleton code. ]] The headers inserted in the same order as the appear in the header- option, empty or missing headers are represented as empty headers, as shown by Expires in this example all lines are terminated with a carriage return line feed. An empty header consists of the long header name followed by a colon and a CRLF pair, without any space. Note that the Contact values appear in the list in the same order as they appear in the message, and that the client added them to the list of headers to protect. Also noteworthy is the positioning of the Authorization header before all the headers we are encoding. 6. Security Considerations The purpose of this draft is security. Items ruled out side of the scope of this document are privacy, resistance to denial of service, trustworthiness of results. The rationale for these is included in section 4 The security of this draft relies mainly on the headers chosen by the server for inclusion in the digest. If this selection is poor a false sense of security obtained. Although if a client wishes the set can be increased to cover all the relevant headers. Undery Experimental - Expires January 2002 8 draft-undery-sip-digest-00.txt July 2001 Another concern is that Basic and Digest authentication still exist and this can cause security to be down graded to these. Unless SIPDigest authentication is used as the only scheme its advantages are minimal. The SIP spec currently suggests Basic authentication SHOULD be supported. This is contrary to current IETF security guidelines [4] and is a major cause for concern. The final issue is the lack of reliability of responses this allows attacks where the attacker modifies responses, potentially fooling the client to perform a predictable action it doesn't intend to do to the real response. 6.1. Security Considerations Missing From RFC 2617 RFC 2617 [3] has a remarkably thorough security considerations section, however, in the author's 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 isn't included in the protection, or simply remove the qop parameter entirely. 7. Open Issues Without a non-backwardly compatible change to [2] this draft becomes partially obsolete, [3] defines an Authorization-Info header that authenticates the response to the client. This header would have to be treated like Authorization in that all headers following it would have to be left untouched by proxies upstream. Without this the following attack is possible; User authenticates a REGISTER, the 200 response is modified to show the contacts were registered for twice as long as they actually were, thus leaving the user registered for only half the time it expects. (Similarly attacks against the server could be initiated by shortening the expiry time increasing the number of REGISTER messages it will handle.) 8. 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", work in progress, currently, draft-ietf-sip-rfc2543bis-03.txt, May 2001. 3 Franks, J. et al, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. Undery Experimental - Expires January 2002 9 draft-undery-sip-digest-00.txt July 2001 4 Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998. 5 Rosenberg, J., "Request Header Integrity in SIP and HTTP Digest using Predictive Nonces", work in progress, June 2001. 6 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. 9. Acknowledgments The Author would like to acknowledge the authors of [3] who have unwittingly provided large portions of text for this draft. Also thanks to Neil Deason and Phil Hoffer for providing feedback on this draft. 10. Author's Addresses James Undery Ubiquity Software Corporation Ltd. Ubiquity House Langstone Park Newport, UK Email: jundery@ubiquity.net Undery Experimental - Expires January 2002 10 draft-undery-sip-digest-00.txt July 2001 Full Copyright Statement "Copyright (C) The Internet Society (2001). 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 ENINEERING TASK FORCE DICLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRENTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRENTIES OF MERCAHNTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Undery Experimental - Expires January 2002 11