Internet Engineering Task Force

INTERNET-DRAFT  Schulzrinne
draft-schulzrinne-sip-security-00.ps  Columbia U.

November 18, 2001 Expires: May 2002

A Minimalist Security Framework 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (c) The Internet Society (2001). All Rights Reserved.

Abstract This document describes a minimalist set of algorithms and protocols that solve some of the more

important security issues in SIP.

1 Introduction

SIP [1] has a number of security issues that remain to be addressed. There is not likely to be a single security mechanism that is appropriate for all threat scenarios or applications, while minimizing complexity and message overhead. Numerous attempts have been made to make progress on SIP security, but with little visible output that is ready to be standardized and deployed in the near term. Thus, this draft takes a minimalist approach and tries to find the smallest set of approaches that solve the most urgent problems. The emphasis is on solutions that do not require extensive new infrastructure or algorithms. Approaches relaxing this assumption are complementary to the recommendations in this memo.

2 Goals and Assumptions

• Avoid inventing new security algorithms and infrastructure to minimize risks and delay.

• Any new algorithm or protocol should be applicable to all similar protocols, such as HTTP/1.1, SIP and RTSP or RFC 2822.

• It is unlikely that a single mechanism will be able to solve all SIP security issues. It is thus pointless to argue whether, say, IPsec, TLS, digest authentication or some other mechanism is “better”. It is likely that a variety of mechanisms will be deployed, depending on the infrastructure that is available or can be built, restrictions on the computational power of end systems, security expectations, attack models and bandwidth constraints.

INTERNET-DRAFT  draft-schulzrinne-sip-security-00.ps  November 18, 2001

• There is a strong preference for mechanisms that do not require an elaborate on-line infrastructure across the whole set of participants. Such an on-line infrastructure adds additional points of failure and compromise.

• The administrative domains of participants are assumed to be only “loosely coupled”, i.e., there is not likely to be mutual trust or a common KDC infrastructure. This corresponds to the typical web model.

• Server and per-domain public-key certificates are widely used for web servers and thus likely to be available for SIP servers.

• Client certificates are less likely to be available than server certificates.

• Computational resources in proxies are more readily available than those in UAs. (For example, on an 800 MHz Pentium III, signing a request takes about 3 ms.)

• In many cases, it is sufficient if the outbound proxy “assumes responsibility” for a message, e.g., signs it. Often, the outbound proxy has other mechanisms at its disposal to verify the identity of the requestor.

3 Threat Models

Below, we categorize the attacks we worry about here. There are many other classifications, but we believe that they capture the essential differences, i.e., this is the minimal set of classifications that allows one to pick different approaches. (In other words, if all methods are equivalent to variations on a single attack, there is not much point in distinguishing these variations.)

We attempt to follow the terminology of RFC 2828 [2] and use the standard naming conventions [3] (p.

23) with the cast of characters including Alice, Bob and Carol as the three parties that wish to communicate with each other (the ”legitimate” users), Eve as the eavesdropper, and Mallory as the malicious active attacker.

SIP is primarily concerned with two-party communications, rather than multi-party communications. Thus, we focus our attention on that model.

Third-party messages (TP): In this attack, the attacker cannot intercept or modify messages between communicating parties (e.g., Alice and Bob), but can send arbitrary messages to either party, possibly with spoofed IP source addresses.

Passive man-in-the-middle (PMIM): In a passive attack, the attacker can intercept arbitrary messages between the two principals. However, the attacker cannot modify the messages. (It does not matter whether the attacker in this model can drop messages, as this is hard to distinguish from normal network operation. In some cases, the inability to drop packets may allow the

Active man-in-the-middle (AMIM): An active man-in-the-middle attacker can modify messages, insert additional messsages and drop arbitrary messages.

4 Authentication without Encryption

In SIP, one of primary concerns is authentication of requests, as spoofed requests can cause major damage. Authentication is needed, for example, for the following cases:

Session setup: During session setup, each participant desires to know the true identity of the other party. In some cases, it is sufficient to know that the party calling is the same one that called earlier, even if the legal name, for example, of the party is not verifiable.

In addition, any SIP intermederias, such as B2BUA’s or proxies, may need to be able to ascertain the identity of the participants, for billing and logging purposes.

Triggering requests: The REFER request can be used to ask a user to generate a request to a third party. There are two situations with different requirements. In the first case (known-party REFER), the sender and recipient of the REFER request are already in an existing SIP session. In the second case (spontaneous REFER), the sender of the REFER request is unknown to the recipient.

Session modification: Even if the session participants do not know or care who the other participant is, they do care that an unauthorized third party does not modify their session in progress.

Terminating sessions: Terminating a session, via BYE, is a special case of the previous problem.

Registration: Malicious users need to be prevented from registering for parties that have not authorized to do so.

From the perspective of the caller and callee, session setup authentication is probably the least important of these, as users routinely receive PSTN calls or messages from unknown users that are traceable only with large amounts of effort, if at all.

In many, but not all, of these cases, the actual content of the message is of secondary importance and contains information that is equivalent to traffic analysis rather than revealing sensitive information.

4.1 Digest Authentication

Need header signing (enhanced digest authentication), as described in [4, ?].

Shared secrets are reasonable assumptions for registration, but less so for session establishment.

Ephemeral keys require signed certificates for AMIM, but not for PMIM.

5 S/MIME for SIP

RFC 2633 [5] appears to be directly applicable to SIP, as long as each SIP request and response is treated as an independent message. This approach is only suitable for end-to-end (UA-to-UA) security; it does not address UA-to-proxy and proxy-to-UA security.

It may be possible to optimize performance by establishing a session key during the initial INVITE and then use HMAC or enhanced Digest authentication to protect the response and future exchanges between the two parties, either for the same session or for a session key lifetime spanning multiple sessions.

Example:

  INVITE sip:UserB@there.com SIP/2.0
  Via: SIP/2.0/UDP here.com:5060
  From: BigGuy <sip:UserA@here.com>
  To: LittleGuy <sip:UserB@there.com>
  Call-ID: 12345601@here.com

CSeq: 1 INVITE
Content-Type: multipart/signed;
  protocol="application/pkcs7-signature";
  micalg=sha1; boundary=boundary42
--boundary42
Content-Type: message/sip
INVITE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP here.com:5060
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@there.com>
Call-ID: 12345601@here.com
CSeq: 1 INVITE
Contact: <sip:UserA@100.101.102.103>
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42--

Section 3.1.3 of RFC 2633 [5] does not apply to SIP, since SIP message bodies are eight-bit clean. Thus, base-64 encoding is not recommended. (Since this memo is restricted to 7-bit ASCII, we do use it in the example above.)

Other constraints on S/MIME?

6 CMS for SIP

Instead of using S/MIME, it is more efficient to use CMS [6], without multipart. This, however, reeks of a kludge and only works for authentication-only.

INVITE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP here.com:5060
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@there.com>
Call-ID: 12345601@here.com
CSeq: 1 INVITE
Signature: ;algorithm=pkcs7
  ;header="From,To,Call-ID,CSeq,Contact,Content-Type,Content-Length,body"
  ;value="ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
  ..."
Contact: <sip:UserA@100.101.102.103>
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

7 Ephemeral Keys

If the S/MIME operation is considered too heavy-weight AND if AMIM attack is discounted, ephemeral keys may be used instead. (If AMIM is possible, only public key cryptography, e.g., using S/MIME, or a Kerberos-like KDC model is known to work.)

8 In-Session Authentication for SIP

In some cases, a full challenge-response exchange is not necessary for shared secret authentication. Avoiding such an exchange significantly reduces the bandwidth overhead of in-session signaling, e.g., for re-INVITE, known-party REFER and BYE. In particular, for an existing session, Eve can replay a message, but it would either be treated as a duplicate and discarded or, if it has an old CSeq number treated as an old message and discarded. If digest authentication has been used, the next-nonce mechanism allows this. If the shared secret is established using S/MIME, however, this mechanism is not suitable. In that case, it may be desirable to transfer a shared session secret to the other party and use it to sign the content using HMAC [7]. The signature protects the method, request-URI, body and a selected set of headers indicated in the header attribute. [THIS NEEDS WORK.]

TBD: Use CMS UserKeyingMaterial or define SIP header Session-Key, with expiration time and preferred methods? Can this be easily extracted from S/MIME?

  Authorization: HMAC header="To,From,CSeq,Date",
     hmac="750c783e6ab0b503eaa86e310a5db738"

The To, From, Call-ID, CSeq and Date header fields must be included in the HMAC.

Note: It may be possible to use Kerberos to generate such a session key. Indeed, one possibility might be to transport a ticket obtained by Alice for Bob to Bob in SIP (header or attachment).

9 Summary of Recommendations

• SIP proxies should use network or transport-level security mechanisms, preferably using long-lived associations, for hop-by-hop security.

• REGISTER uses enhanced digest authentication.

• For the PMIM threat model only, known-party REFER requests may use enhanced SIP digest authentication based on ephemeral keys established during the session setup.

• UACs may protect initial requests within a session using S/MIME.

• UACs can choose HMAC authentication or S/MIME for subsequent authentication.

• Outbound proxies must sign all unsigned requests and responses, including REFER, via S/MIME. Such outbound proxies should use appropriate mechanisms, such as proxy digest authentication, to ascertain the identity of the UA.

10 Open Issues

References

[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, “SIP: session initiation protocol,” Request for Comments 2543, Internet Engineering Task Force, Mar. 1999.

[2] R. Shirey, “Internet security glossary,” Request for Comments 2828, Internet Engineering Task Force, May 2000.

[3] B. Schneier, Applied Cryptography. New York: Wiley, 1996.

[4] J. Undery, “Sip authentication: Sip digest access authentication,” Internet Draft, Internet Engineering Task Force, July 2000. Work in progress.

[5] B. Ramsdell and Ed, “S/MIME version 3 message specification,” Request for Comments 2633, Internet Engineering Task Force, June 1999.

[6] R. Housley, “Cryptographic message syntax,” Request for Comments 2630, Internet Engineering Task Force, June 1999.

INTERNET-DRAFT  draft-schulzrinne-sip-security-00.ps  November 18, 2001

[7] H. Krawczyk, M. Bellare, and R. Canetti, “HMAC: keyed-hashing for message authentication,” Request for Comments 2104, Internet Engineering Task Force, Feb. 1997.

11 Acknowledgements

TBD

12 Authors’ Addresses

Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu

Contents

1 Introduction 1 2 Goals and Assumptions 1 3 Threat Models 2 4 Authentication without Encryption 2

4.1 Digest Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5 S/MIME for SIP 3 6 CMS for SIP 5 7 Ephemeral Keys 5 8 In-Session Authentication for SIP 5 9 Summary of Recommendations 6 10 Open Issues 6 11 Acknowledgements 7 12 Authors’ Addresses 7

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 IN-TERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WAR-RANTIES, 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.