Internet Engineering Task Force SIP WG Internet Draft Rosenberg draft-rosenberg-sip-http-pnonce-00.txt dynamicsoft June 16, 2001 Expires: December 2001 Request Header Integrity in SIP and HTTP Digest using Predictive Nonces 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract The HTTP Digest algorithm, specified in RFC 2617, allows for authentication of a request, along with integrity checks over the method, request URI, and optionally, the body. HTTP Digest is the primary client authentication mechanism used by SIP. However, Digest does not provide for integrity checks over several key SIP headers, including the To, From, Call-ID and Contact headers. We define a mechanism for supporting integrity over these headers, using a new algorithm we call predictive nonces. The mechanism requires no changes in clients, and no protocol changes. It requires only a change in the way the nonce is computed by servers. 1 Introduction Rosenberg [Page 1]
Internet Draft pnonce June 16, 2001 RFC 2617 [1] defines two mechanisms for client authentication to servers - Basic and Digest. Basic involves the use of a cleartext password, and comes with many known security flaws. HTTP Digest avoids the use of cleartext passwords through a challenge-response mechanism. It also provides for integrity checks over the request method, URI, and optionally, the body. HTTP Digest has found usage within HTTP itself (often in conjunction with TLS/SSL), and within SIP [2]. To date, HTTP Digest is the predominantly used mechanism for client to server authentication in SIP systems. Unfortunately, HTTP Digest suffers from some critical problems. Most significantly, it does not provide integrity checks over the headers. This results in a number of possible attacks, both man-in-the-middle, and replay. To fix this problem, we describe a server-side algorithm for nonce computation, called predictive nonces. This approach allows HTTP Digest to provide integrity over many of the request headers, including (for SIP), the To, From, Call-ID, and Contact headers. The approach requires no changes to clients, and no protocol extensions. It is a purely local implementation choice on the server side. As a result of this, predictive nonces also provide the server flexibility in choosing which headers it would like to see covered by integrity. The more headers are covered, the more computation needs to be done at the server. 2 Weaknesses of HTTP Digest In this section, we review some of the weaknesses present in HTTP Digest as a result of its lack of integrity checks over headers. First off, there are a large set of man-in-the-middle attacks. If an attacker can intercept a request, they can modify its contents, and still have the request accepted by the server. Some of the more troubling attacks are: o The From header of an INVITE can be changed, resulting in a caller believing the call is actually from someone else. o The Contact header in a REGISTER can be modified. This allows a user to "steal" the calls from someone else, so that incoming calls from the target are directed to the attackers phone. o The request URI an an INVITE can be modified, resulting in a call for one party to ring the phone of another, unintended Rosenberg [Page 2]
Internet Draft pnonce June 16, 2001 party instead. Man-in-the-middle attacks, fortunately, are difficult to launch, as they require an attacker to have subverted some kind of intermediate entity in the call setup path (such as a router, physical wire, or proxy server). The barriers to such attacks are therefore higher. However, the lack of integrity also means that replay attacks are possible. An attacker can watch for messages on the wire, store them, modify them, and then replay them later. Some of the attacks possible with this approach are: o An attacker can record a REGISTER message. They store it, add an Expires header with value 0, modify the Call-ID header to a new value, and then resend the message. The server receives this replayed message and then removes the registrations for the targeted user. This means an attacker can cause the phone of a target to lose all calls. o An attacker can record a REGISTER message. They store it, and modify it to expire the registered Contact. An additional Contact header is added, pointing to the phone of the attacker. This registration is accepted by the server. As a result of this, an attacker can cause all calls for the target to ring the attackers phone instead. o An attacker can record an INVITE message. They store it, and modify it with different Via headers and Contact header, which instead point to the attacker's phone. The Call-ID is changed, and the CSeq incremented. This INVITE is sent a few seconds later. This is accepted by the called party. The result is that an attacker can hijack an in-progress call, causing communications to continue with the attackers phone. There are existing techniques that can combat the replay attacks. RFC 2617 allows for one-time nonces. However, this imposes a serious burden on the server, in that it must remember the last nonce used for any specific request URI. This also opens up the server to denial-of-service attacks, since an attacker can send requests to many users on the server, requiring the server to store the last nonce for each of these. The nonce can also include a hash of the source IP address of the request. This means that a replay attack can only occur using a spoofed source address. However, source address spoofing is not difficult to do, and network ingress filtering is not yet widely deployed [3]. Therefore, we believe the existence of serious man-in-the-middle Rosenberg [Page 3]
Internet Draft pnonce June 16, 2001 attacks, and of replay attacks for which existing solutions are not sufficient, warrants an additional mechanism to be defined. 3 Predictive Nonces Our approach to solve some of these problems is called predictive nonces. The idea, at a high level, is simple. When a server receives a request, it computes the nonce as a function of those headers in the request which it knows to be invariant when the client resubmits its request. When the new request, with the Authorization header, arrives, the server recomputes the nonce using the same set of headers in the same way. If the headers have not changed, the resulting nonce will be identical to the one issued in the challenge, and the digest response will be valid. If any of the headers has been changed by an attacker, the nonce that is computed will be different, and the server can detect this condition, and reject the request. Even if an attacker could determine the algorithm for computing a nonce, and therefore determined what nonce to use for a message it modified, it would not have access to a digest response that was computed using that nonce. Specifically, we recommend that the nonce be computed as: nonce = H(source-IP:<canonicalization of headers to be protected>:round-time) where H is a suitable cryptographic hash function, and round-time is the current time-of-day, rounded to the nearest minute. For this approach to work, the server must be certain that the headers it uses in the nonce computation will be the same (after some canonicalization) in the resubmitted request as the original request. This is why we call the approach predictive nonces. The server is predicting that the headers in the resubmitted request will be a certain value. If its wrong, the result will be a stale nonce, and a reissuance of the challenge. Should that header continue to change from request to request, the result will be an endless loop of requests, followed by failures due to stale nonces. This loop is broken so long as there will eventually exist two consecutive requests over which the header does not change value. Fortunately, most of the headers worth proctecting do not change in this fashion. The only header which always will change in this way is the CSeq (specifically, the sequence number). Since the CSeq method is not likely to change, it can be protected. To our knowledge, all clients resubmit a challenged request with the same values of the To, Rosenberg [Page 4]
Internet Draft pnonce June 16, 2001 From, Call-ID and CSeq method (some may recompute the tag in the From field, so we do not recommend that it be included in the computation of the nonce). For SIP REGISTER requests, we recommend that the nonce be computed over the To field URI, From field URI, Contact URIs (in alphabetical order), and Call-ID. Protecting Expires is a bit tricky, since it is possible that it might get updated in each subsequent request. To deal with this, we recommend that relative expiration values be first rounded to the nearest minute, and that this rounded value be used in the hash computation. For absolute times, the time should be rounded to the nearest minute as well, and that time used. Canonicalization of the headers to be protected is important. The exact mechanism used for canonicalization is server-specific and need not be standardized, so long as it is consistent within a particular server. As an example, a canonicalization of the Call-ID, To, and From might start with the Call-ID value, append the To username, if present, followed by the To domain name, followed by the From username, if present, followed by the From domain. 4 Discussion Our approach yields many benefits: o It requires no state in the server. o It requires no change to the protocol. o It requires no change to the clients. o As a purely localized implementation choice, each server can elect to use, or not use, predictive nonces, as it sees fit. o The set of headers covered by the integrity check is purely at the discretion of the server, subject to the constraint that they must be headers which will not change in the resubmitted request. o It protects against all of the replay attacks discussed above. o It protects against all of the man-in-the-middle attacks discussed above, so long as clients do not provide Basic credentials (in this case, as pointed out in RFC 2617 [1], an attacker can intercept challenges from the server, and insert a Basic challenge). o It works for HTTP as well as SIP, although it is far more Rosenberg [Page 5]
Internet Draft pnonce June 16, 2001 useful for SIP where headers are more significant, and where transport level integrity (using SSL or TLS) is not available. The primary issue is that it will only work if clients do, indeed, not attempt to modify the protected headers every time a request is resubmitted with credentials. We believe that the most important headers to be protected will not change from request to request. Even if this should happen, it is possible for the server to detect this race condition statelessly. To do that, it issues the first challenge for a request using a value N that is a counter of the maximum number of iterations of stale nonces the server is willing to tolerate. The nonce is computed as: nonce = H(source-IP:<headers to protect>) + "." + N where + signifies concatentation. When the request is resubmitted, the server checks the numeric value at the end of the nonce. If nonzero, it decrements it and uses this value for N in the construction of the new nonce. When it receives a request with a value of zero for N, it knows that there has been an error of some sort. This approach does not prevent an attacker from modifying the value of the count, but it does provide a way for the server to detect race conditions with cooperating clients. In these cases, the request should probably be rejected with a 500 class response, and some kind of alarm generated to the operations staff. This detection approach is similar to the function provided by the nonce-count in RFC 2617 [1], but is different. The nonce-count decrements every time the same nonce is reused. Here, the nonce is changing on each reuse. Predictive nonces also interact with B2BUAs. A B2BUA will modify many aspects of messages before forwarding them onward. A B2BUA may think that it can still forward credentials provided by a client onward, even though it has modified the request. While this may work with existing implementations, those servers using predictive nonces will detect these cases (as they are, after all, man-in-the-middle attacks) and generate challenges due to stale nonces. Therefore, we recommend that a B2BUA not attempt to pass on credentials, and should rather generate its own credentials for requests. 5 Security Considerations Security considerations are at the heart of this draft. Rosenberg [Page 6]
Internet Draft pnonce June 16, 2001 6 Authors Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com 7 Bibliography [1] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, and L. Stewart, "HTTP authentication: Basic and digest access authentication," Request for Comments 2617, Internet Engineering Task Force, June 1999. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [3] P. Ferguson and D. Senie, "Network ingress filtering: Defeating denial of service attacks which employ IP source address spoofing," Request for Comments 2827, Internet Engineering Task Force, May 2000. Rosenberg [Page 7]