From daemon@optimus.ietf.org Mon Nov 5 15:47:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07179 for ; Mon, 5 Nov 2001 15:47:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24275 for sip-security-archive@odin.ietf.org; Mon, 5 Nov 2001 15:47:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24140; Mon, 5 Nov 2001 15:40:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24108 for ; Mon, 5 Nov 2001 15:40:29 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06829 for ; Mon, 5 Nov 2001 15:40:23 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA5KbuVW004856; Mon, 5 Nov 2001 15:37:56 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Nov 2001 15:39:12 -0500 Message-ID: From: Jonathan Rosenberg To: "'Jari Arkko'" , Jonathan Rosenberg , "'Henning G. Schulzrinne'" , "C. R. Kalmanek" Cc: sip-security@ietf.org Subject: RE: [Sip-security] Basic/digest over TLS Date: Mon, 5 Nov 2001 15:39:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Wednesday, October 24, 2001 1:04 AM > To: Jonathan Rosenberg; 'Henning G. Schulzrinne'; C. R. Kalmanek > Cc: sip-security@ietf.org > Subject: Re: [Sip-security] Basic/digest over TLS > > > > > I suspect you are going to need to keep them open > indefinitely to support > > quick call setups. > > Keeping the session open indefinitely would cause an > interesting situation > in the mobile networks where local proxies are contacted by roaming > terminals: the proxies would be keeping state not just with > everyone who > is on the area but also those who have been on the area. Does your OS > support a billion open TCP sessions? ;-) I agree its a problem. I am merely suggesting that Basic/Digest over TLS can help us solve some cases. > * Unnecessary reliance on public key crypto. There's never enough CPU > and power on small mobile devices (if there was, the > manufacturer would > make the device smaller and the battery to last longer). > Are we taking > public key crypto because we need it, or because our symmetric key > protocols aren't good enough? TLS only uses PKI for the initial authentication; it causes the exchange of a symmetric session key thats used for all actual data exchange. So, I don't see the issue here. > > * Bandwidth. How much extra bandwidth is going to be consumed > by sending > certificates etc? Its just at setup, so I don't think its too bad, but I don't have any figures. > > * Roundtrips. I don't know how many additional roundtrips TLS > introduces, but > it is essential to minimize them, in order to get the call > setup and/or registration > delays small. IKE at least introduces currently too many > roundtrips for this > application (in the order of 9 messages). RTT is *long* in > cellular networks. Right; I would not propose establishing a TLS connection every time you want to make a call. You more or less need to leave one nailed up for reasonable performance. That has challenges too, of course. > * Can we reuse legacy authentication schemes in TLS? This would be > important for e.g. 3g folks who would like to reuse > existing infra (smart > cards, procedures to hand out them, slots in devices, etc.). SSL does support negotiatble crypto techniques. However, everything you list above is for client authentication to the server. I am NOT proposing that we use TLS for that. I am only proposing TLS for the server authentication to the client. Client authentication to the server follows using SIP basic, digest, or something else, over that connection. > > * Even if we were able to make TLS perfect in this > environment, we still > face the problem that it is hop-by-hop. In many cases I see that an > end-to-end solution is needed as well, so wouldn't we > prefer a solution that > can handle both the hop-by-hop and end-to-end protection cases? TLS + Basic/Digest does not solve the end-to-end problems, but it does provide some low hanging fruit to solve a few of them. I would NOT advocate a single mechanism that is the one and only security mechanism for sip, which is the same for all use cases. > That being said, I think both TLS and IPsec/IKE are clearly > the preferred > solutions in many cases, e.g. protecting traffic between > proxies or within > a corporate LAN. Well, I have little faith in IKE, but thats a separate issue. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Nov 5 16:21:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08225 for ; Mon, 5 Nov 2001 16:21:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25232 for sip-security-archive@odin.ietf.org; Mon, 5 Nov 2001 16:21:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25102; Mon, 5 Nov 2001 16:18:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25071 for ; Mon, 5 Nov 2001 16:18:07 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08082 for ; Mon, 5 Nov 2001 16:18:01 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fA5LALV05732; Mon, 5 Nov 2001 16:10:22 -0500 (EST) Message-ID: <3BE7003D.C835D2B9@cs.columbia.edu> Date: Mon, 05 Nov 2001 16:10:21 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Jari Arkko'" , "C. R. Kalmanek" , sip-security@ietf.org Subject: Re: [Sip-security] Basic/digest over TLS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > is on the area but also those who have been on the area. Does your OS > > support a billion open TCP sessions? ;-) > > I agree its a problem. I am merely suggesting that Basic/Digest over TLS can > help us solve some cases. Note that this is a common problem for any state, not just TCP. My interpretation is that TCP state is no larger than typical secured connection state, be it IPsec or TLS or anything else. > > Its just at setup, so I don't think its too bad, but I don't have any > figures. Would be nice if somebody could do a tcpdump to make some measurements. > > > > > * Roundtrips. I don't know how many additional roundtrips TLS > > introduces, but > > it is essential to minimize them, in order to get the call > > setup and/or registration > > delays small. IKE at least introduces currently too many > > roundtrips for this > > application (in the order of 9 messages). RTT is *long* in > > cellular networks. > > Right; I would not propose establishing a TLS connection every time you want > to make a call. You more or less need to leave one nailed up for reasonable > performance. That has challenges too, of course. And this is common to most any protocol that establishes a security association. Do you want to run IKE for every phone call? > TLS + Basic/Digest does not solve the end-to-end problems, but it does > provide some low hanging fruit to solve a few of them. I would NOT advocate > a single mechanism that is the one and only security mechanism for sip, > which is the same for all use cases. Agreed; if we were to to try to do this, we would - have to invent a fairly complicated new security mechanisms, with all the inherent dangers; - never get done, given the amount (or lack thereof) of progress we've so far. > > > That being said, I think both TLS and IPsec/IKE are clearly > > the preferred > > solutions in many cases, e.g. protecting traffic between > > proxies or within > > a corporate LAN. > > Well, I have little faith in IKE, but thats a separate issue. > From all that I've heard, IKE is an interoperability nightmare and recognized as a poorly specified protocol. There's a reason people in the IETF are talking about son-of-IKE or alternatives for key establishment. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Wed Nov 14 17:37:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19812 for ; Wed, 14 Nov 2001 17:37:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14005 for sip-security-archive@odin.ietf.org; Wed, 14 Nov 2001 17:37:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13761; Wed, 14 Nov 2001 17:31:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13703 for ; Wed, 14 Nov 2001 17:31:21 -0500 (EST) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19684; Wed, 14 Nov 2001 17:31:13 -0500 (EST) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA25260; Wed, 14 Nov 2001 16:30:46 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 14 Nov 2001 16:26:58 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Nov 2001 16:29:32 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F30C@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: sipping@ietf.org, "'sip-security@ietf.org'" Cc: "Sanjoy Sen" , "Lee Valerius" , "'vesa.torvinen@ericsson.fi'" Date: Wed, 14 Nov 2001 16:29:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16D5B.D545AF90" Subject: [Sip-security] new I-D: single hop Digest message authentication Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C16D5B.D545AF90 Content-Type: text/plain; charset="iso-8859-1" Hi Folks, We've submitted a draft discussing the usage of Digest for providing full message authentication capabilities between UA and a Proxy one-hop away. Until the draft appears in the directory, it can be found at: http://www.obsidian97.com/draft-sen-sipping-onehop-digest-00.txt I've attached the abstract below. Regards, Sanjoy ========= To date, the HTTP access authentication framework, as described in [RFC2617] and as used in [SIPbis05], has permitted limited SIP message authentication from UAC to Proxy/UAS, Proxy to Proxy, and Proxy to UAS. This draft addresses some of the shortcomings of SIP usage of Digest for message authentication between a SIP User Agent and a Proxy one hop away (e.g., an outbound Proxy). For the messages exchanged between the UA and a Proxy one hop away, the Service Provider may want to provide a different level of protection than that possible for the same messages end-to-end. Authentication of both requests and responses traveling in either direction should be possible with minimum number of necessary roundtrip exchanges. We discuss some the limitations of SIP Digest message authentication framework in satisfying these requirements and propose possible solutions. A new value of the "qop-options" parameter would indicate to a SIP entity that the challenging entity is one hop away and the maximum protection of SIP message is required. Some other aspects of this solution are in the form of behavior enhancements of SIP Proxy and UA. ------_=_NextPart_001_01C16D5B.D545AF90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable new I-D: single hop Digest message authentication

Hi Folks,

   We've submitted a draft discussing the = usage of Digest for providing full message authentication capabilities = between UA and a Proxy one-hop away. Until the draft appears in the = directory, it can be found at:

http://www.obsidian97.com/draft-sen-sipping-onehop-dig= est-00.txt

I've attached the abstract below.

Regards,
Sanjoy

=3D=3D=3D=3D=3D=3D=3D=3D=3D
To date, the HTTP access authentication framework, = as described in
   [RFC2617] and as used in [SIPbis05], = has permitted limited SIP
   message authentication from UAC to = Proxy/UAS, Proxy to Proxy, and
   Proxy to UAS. This draft addresses some = of the shortcomings of SIP
   usage of Digest for message = authentication between a SIP User Agent
   and a Proxy one hop away (e.g., an = outbound Proxy). For the messages
   exchanged between the UA and a Proxy = one hop away, the Service
   Provider may want to provide a = different level of protection than
   that possible for the same messages = end-to-end. Authentication of
   both requests and responses traveling = in either direction should be
   possible with minimum number of = necessary roundtrip exchanges. We
   discuss some the limitations of SIP = Digest message authentication
   framework in satisfying these = requirements and propose possible
   solutions. A new value of the = "qop-options" parameter would indicate
   to a SIP entity that the challenging = entity is one hop away and the
   maximum protection of SIP message is = required. Some other aspects = of           &nbs= p;           &nbs= p;  
   this solution are in the form of = behavior enhancements of SIP Proxy
   and UA.

------_=_NextPart_001_01C16D5B.D545AF90-- _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Nov 16 13:16:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15093 for ; Fri, 16 Nov 2001 13:16:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13599 for sip-security-archive@odin.ietf.org; Fri, 16 Nov 2001 13:16:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13492; Fri, 16 Nov 2001 13:06:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13461 for ; Fri, 16 Nov 2001 13:06:01 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14684 for ; Fri, 16 Nov 2001 13:05:58 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAGI48CJ009242 for ; Fri, 16 Nov 2001 13:04:08 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Nov 2001 13:05:30 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E7D8@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip-security@ietf.org'" Date: Fri, 16 Nov 2001 13:05:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip-security] FW: [Sip] review of draft-ietf-sip-refer-02 Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Recall that REFER had a mechanism for passing credentials from the referor to the refer target that were pulled in favor of the common mechanisms this design team kicked out. As you can see, I'm getting pressure to put _something_ back into the REFER draft. (There have been more empassioned outcries against the use of REFER in 3GPP reported on the sipping list, because it is perceived to be dangerous without some form of auth{entic|oriz)ation. Are these common mechanisms going to spring into existance soon? Does anyone have a roadmap for the output of this team in their head? RjS -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: Friday, November 16, 2001 8:13 AM To: William Marshall Cc: sip@ietf.org Subject: Re: [Sip] review of draft-ietf-sip-refer-02 Hi Bill: See my comments below. William Marshall wrote: > > [snip] > > (3) security > The security section is correct in the second paragraph that anyone > can issue a request claiming that they were referred to that resource > by an arbitrary third party. I think the refer draft should get the > level of security at least as high as general SIP, so that the final UAS > can reasonably restrict access to itself. > > Has 3GPP accepted REFER as the way to implement call transfer? Security > was a huge consideration when my proposal to use REFER in 3G was initially > rejected last May. My suspicion is that without a "reasonable" security > mechanism (like comparable to HTTP digest authentication, a sufficiently > low threshold to meet), no service provider will allow REFER. 3GPP has flows based on the REFER, but they are in stand-by, in the annex of the specification, waiting to have a wider acceptance and to resolve the security issues that you point out. > > While a mechanism to protect header integrity is sorely needed in SIP, > I don't believe it will solve the problems of REFER. The UAS would > want to authenticate the referrer (UA that initiated the REFER), not just > the UA that initiated the refer-requested INVITE. > > Consider the following as a strawman proposal: > > Agent A Agent B Agent C > | | | > |---REFER------------->| | > |<--202 Accepted-------| | > | |---INVITE------------>| > | |<--4xx Ref Auth-(*1)--| > |<--NOTIFY (w/4xx)-----|---ACK--------------->| > |---200 OK------------>| | > | | | > |---REFER-(w/Auth,*2)->| | > |<--202 Accepted-------| | > | |---INVITE-(w/Auth)--->| > | |<--200 OK-------------| > |<--NOTIFY (w/200)-----|---ACK--------------->| > |---200 OK------------>| | > | | | > > Agent C, (*1) responds to the INVITE with a Referred-By header by a new 4xx > response code, requesting authentication by the Referred-By-entity. > Agent C provides a challenge. This information is passed back to Agent > A in the NOTIFY; more than just the 4xx response code is in this > message/sipfrag. > > Agent A then re-issues the REFER with the proper authentication (*2) > response. This authentication information is included in the INVITE > sent by Agent B to Agent C, who then accepts the request. > > Can this use the existing "Authentication-Info" and "Authorization" headers? > If so, how does Agent B know whether to answer the authorization request, > or pass it back to Agent A? A new 4xx response code could help, but what > if Agent C also wanted to authenticate Agent B? Perhaps new headers > are required for this. If so, they would seem to be REFER-specific, and > should be included in this draft instead of in a general security > principles and procedures document. I agree with you that some sort of authentication mechanism is desirable. However I think that the problem is difficult to solve. In your example, does it mean that A and C must share some secret key in order to authenticate each other? If the answer is yes, I don't think the mechanism is valid, because it implies a heavy key management scheme between agents A and C in your example. Or are you thinking of something completely different. /Miguel > Bill Marshall > wtm@research.att.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sun Nov 18 20:39:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00758 for ; Sun, 18 Nov 2001 20:39:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA02033 for sip-security-archive@odin.ietf.org; Sun, 18 Nov 2001 20:39:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02005; Sun, 18 Nov 2001 20:34:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01974 for ; Sun, 18 Nov 2001 20:34:37 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00734 for ; Sun, 18 Nov 2001 20:34:34 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fAJ1YZV05627 for ; Sun, 18 Nov 2001 20:34:35 -0500 (EST) Message-ID: <3BF861AB.D6191185@cs.columbia.edu> Date: Sun, 18 Nov 2001 20:34:35 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: sip-security@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip-security] A minimalist security framework for SIP Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Instigated by some recent frustration expressed by a colleague, I drafted a strawman that tries to get from the perennial (or, rather, every-four-months) hand-wringing about the lack of progress on SIP security to at least a summary of where we are and where we might be able to get to reasonably quickly. http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-sip-security-00.txt It's biased, rough and incomplete, but it's hopefully at least something that can serve as a target for stones thrown. (I missed the 00 I-D deadline, so don't expect to see this in the repository.) I don't claim that this is the only viable model. Indeed, I think the most important item right now is to avoid the entertaining but largely pointless discussions as to which security mechanism is better. It is likely that we'll need all non-broken mechanisms. Barring some major breakthroughs in cryptography, it is also likely that we can't have all four of the below: - no centralized non-SIP infrastructure (KDCs) - no public keys - robust in the face of active man-in-the-middle attacks - fast enough to run in 10 microseconds on a Z80 Thus, just setting up requirements that require security magic is also not that helpful at this point. If nothing else, I'm hoping that this will trigger somebody else to write up an alternative, with different assumptions. Henning -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Nov 19 14:16:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18284 for ; Mon, 19 Nov 2001 14:16:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13298 for sip-security-archive@odin.ietf.org; Mon, 19 Nov 2001 14:16:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13251; Mon, 19 Nov 2001 14:11:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13218 for ; Mon, 19 Nov 2001 14:11:22 -0500 (EST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17985 for ; Mon, 19 Nov 2001 14:11:19 -0500 (EST) Received: from jariws1 ([62.248.155.237]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011119191120.GCBD4415.fep02-app.kolumbus.fi@jariws1>; Mon, 19 Nov 2001 21:11:20 +0200 Message-ID: <00a601c1712d$f9c6b1e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Henning G. Schulzrinne" , References: <3BF861AB.D6191185@cs.columbia.edu> Subject: Re: [Sip-security] A minimalist security framework for SIP Date: Mon, 19 Nov 2001 21:11:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Nice draft. Here's a few comments: >It is unlikely that a single mechanism will be able to solve >all SIP security issues. It is thus pointless to argue whether Yes! (And, that's exactly the kind of arguing that has taken place on the list recently... my take on this is that we should recognize where certain mechanisms and architectures are usable and where they are not.) >There is a strong preference for mechanisms that do not >require an elaborate on-line infrastructure across the whole >set of participants. Indeed. I might add that it could be quite OK to have some infrastructure such as a RADIUS/DIAMETER server on a home org to keep the passwords/whatever for the users, but if we start requiring some sort of global interconnection using certificates between all users and all random proxies in the network, we're in trouble. >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. Yes, this is possible. (This is similar to what 3g folks want to do, though they would typically set things up at registration time.) >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.) I don't understand why you say AMIM protection implies 3rd parties or PK cryptography. Can you explain? The reason that HTTP authentication for instance is broken, is uh, that it is broken and not because of any fundamental limitation. Many (or maybe even most) SIP-based networks have "subscribers" and "home networks" (companies or operators) that have a relationship with the subscriber. In these cases it should be possible to arrange for a shared secret, and to use that shared secret for the e2e (or at least end-to-middle) protection of the signaling. e2e/e2m requires mainly an appropriate mechanism to agree which parts of the message should be protected, not public keys. By the way, I'm not certain if S/MIME can also do symmetric schemes. Anyone? >Barring some major >breakthroughs in cryptography, it is also likely that we can't have all >four of the below: > >- no centralized non-SIP infrastructure (KDCs) >- no public keys >- robust in the face of active man-in-the-middle attacks >- fast enough to run in 10 microseconds on a Z80 There are secure authentication methods based on symmetric schemes. Coupled with a decent protection format (maybe like ESP but capable of e2e as well), this would be quite fast. Maybe not 10 us on a Z80, but a PK operation would not be needed. And active MITM attacks aren't problem. The need for pk or infrastructure seems to be more related to the kind of trust model one has; secure communication to your home proxy/server is quite OK even over other proxies, but if you want e2e to another random user, or want security to a random proxy you go through, then there's more trouble. >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.] Again, this is something that I would find useful (and would be willing to work on it if there's interest). BTW, running HTTP EAP + an EAP method that can generate session keys + Sanjoy et al draft achieves something like this. >The To, From, Call-ID, CSeq and Date header fields MUST be included >in the HMAC. Why not all? Or some set definition as in the Undery draft? >In some cases, the inability to drop packets may allow the ... >Need header signing (enhanced digest authentication), as described in ... There are a few incomplete sentences around the draft. Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Nov 19 15:08:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21794 for ; Mon, 19 Nov 2001 15:08:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14855 for sip-security-archive@odin.ietf.org; Mon, 19 Nov 2001 15:08:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14820; Mon, 19 Nov 2001 15:04:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14782 for ; Mon, 19 Nov 2001 15:04:01 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21517 for ; Mon, 19 Nov 2001 15:03:58 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fAJK3tV22865; Mon, 19 Nov 2001 15:03:55 -0500 (EST) Message-ID: <3BF965AB.20D2F86A@cs.columbia.edu> Date: Mon, 19 Nov 2001 15:03:55 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: sip-security@ietf.org Subject: Re: [Sip-security] A minimalist security framework for SIP References: <3BF861AB.D6191185@cs.columbia.edu> <00a601c1712d$f9c6b1e0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Yes! (And, that's exactly the kind of arguing that has taken > place on the list recently... my take on this is that we should > recognize where certain mechanisms and architectures are > usable and where they are not.) Yes, a more objective "applicability statement" for each would be helpful. > Indeed. I might add that it could be quite OK to have some > infrastructure such as a RADIUS/DIAMETER server on a > home org to keep the passwords/whatever for the users, but > if we start requiring some sort of global interconnection using > certificates between all users and all random proxies in the > network, we're in trouble. There's also a difference between having an on-line server infrastructure and off-line certificates for servers. We have existence proof that the latter works reasonably well, but various efforts at on-line certificates or universal login seem to have up-time and security difficulties even if run by a single large companies, as opposed to the more likely loose affiliation of competitors. > Yes, this is possible. (This is similar to what 3g folks want to do, though > they would typically set things up at registration time.) This seems to be somewhat different, namely setting up a session key between the registrar and the user, rather than the two users (that are likely to be on two different registrars). How does having a session key help with the e2e issue? > > >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.) > > I don't understand why you say AMIM protection implies 3rd parties > or PK cryptography. Can you explain? Sorry, should've added that shared secret are also possible as a third option. Does that make more sense? > > The reason that HTTP authentication for instance is broken, is uh, > that it is broken and not because of any fundamental limitation. Which brokenness are you referring to? > Many (or maybe even most) SIP-based networks have "subscribers" > and "home networks" (companies or operators) that have a relationship > with the subscriber. In these cases it should be possible to arrange for > a shared secret, and to use that shared secret for the e2e (or at least > end-to-middle) protection of the signaling. I have a hard time with the e2e version. How does my local Verizon shared secret help me when calling an AT&T customer, unless there's something like a cross-certification of the KDCs involved? > >Barring some major > >breakthroughs in cryptography, it is also likely that we can't have all > >four of the below: > > > >- no centralized non-SIP infrastructure (KDCs) > >- no public keys > >- robust in the face of active man-in-the-middle attacks > >- fast enough to run in 10 microseconds on a Z80 > > There are secure authentication methods based on symmetric schemes. Again, I omitted those by accident, probably because N^2 shared secrets between end users didn't seem that attractive. > Coupled with a decent protection format (maybe like ESP but capable > of e2e as well), this would be quite fast. Maybe not 10 us on a Z80, but > a PK operation would not be needed. And active MITM attacks aren't > problem. The primary problem is getting shared secrets between two parties in networks operated by competitors or in networks that don't know about each other. Columbia University shouldn't have to set up a trust relationship with kolumbus.fi for me to make a call to you. > > The need for pk or infrastructure seems to be more related to the kind > of trust model one has; secure communication to your home proxy/server > is quite OK even over other proxies, but if you want e2e to another random > user, or want security to a random proxy you go through, then there's > more trouble. I think we're in agreement. That's primarily my concern, as yours and other work seem to provide a decent handle on the e2p case. In those cases, shared secrets work quite well, as we know from login, network file systems, etc. > > >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.] > > Again, this is something that I would find useful (and would be willing > to work on it if there's interest). BTW, running HTTP EAP + an EAP > method that can generate session keys + Sanjoy et al draft > achieves something like this. Indeed, I think it's a nice coincidence that all these drafts are appearing. Maybe we can hash something out in SLC. > > >The To, From, Call-ID, CSeq and Date header fields MUST be included > >in the HMAC. > > Why not all? Or some set definition as in the Undery draft? This is the minimal set. Others might be considered less important or might change in transit. (Although so far, it seems that only the Via header has the latter property.) > > >In some cases, the inability to drop packets may allow the > ... > >Need header signing (enhanced digest authentication), as described in > ... > > There are a few incomplete sentences around the draft. Yes, this was a Sunday afternoon effort. Thanks for reading it. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Nov 19 15:46:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24051 for ; Mon, 19 Nov 2001 15:46:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15687 for sip-security-archive@odin.ietf.org; Mon, 19 Nov 2001 15:46:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15617; Mon, 19 Nov 2001 15:42:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15589 for ; Mon, 19 Nov 2001 15:42:21 -0500 (EST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23854 for ; Mon, 19 Nov 2001 15:42:20 -0500 (EST) Received: from jariws1 ([62.248.155.237]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011119204219.GQUM4415.fep02-app.kolumbus.fi@jariws1>; Mon, 19 Nov 2001 22:42:19 +0200 Message-ID: <010201c1713a$b025e580$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Henning G. Schulzrinne" Cc: References: <3BF861AB.D6191185@cs.columbia.edu> <00a601c1712d$f9c6b1e0$8a1b6e0a@arenanet.fi> <3BF965AB.20D2F86A@cs.columbia.edu> Subject: Re: [Sip-security] A minimalist security framework for SIP Date: Mon, 19 Nov 2001 22:42:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit > > Yes, this is possible. (This is similar to what 3g folks want to do, though > > they would typically set things up at registration time.) > > This seems to be somewhat different, namely setting up a session key > between the registrar and the user, rather than the two users (that are > likely to be on two different registrars). How does having a session key > help with the e2e issue? These are definately different use cases, but it might be that the SIP-level mechanisms to achieve the same thing could be similar. Session keys are essentially an optimization, and they require some form of symmetric crypto encapsulation (maybe CMS/digest/smime). If we could assume that whatever authentication we do with our friends and operators both can produce session keys, then both could use similar methods to pass protected data in subsequent messages without the overhead of new public key operations, AAA calls or whatever that is needed. > > I don't understand why you say AMIM protection implies 3rd parties > > or PK cryptography. Can you explain? > > Sorry, should've added that shared secret are also possible as a third > option. Does that make more sense? Yes. > > The reason that HTTP authentication for instance is broken, is uh, > > that it is broken and not because of any fundamental limitation. > > Which brokenness are you referring to? My main issue with it is that the auth-int doesn't cover enough. > > Many (or maybe even most) SIP-based networks have "subscribers" > > and "home networks" (companies or operators) that have a relationship > > with the subscriber. In these cases it should be possible to arrange for > > a shared secret, and to use that shared secret for the e2e (or at least > > end-to-middle) protection of the signaling. > > I have a hard time with the e2e version. How does my local Verizon > shared secret help me when calling an AT&T customer, unless there's > something like a cross-certification of the KDCs involved? You're right, it doesn't help for the e2e case... at least not with INVITEs. Maybe it does help in some of the other messages, such as REGISTER that are e2e between you and your provider. > Again, I omitted those by accident, probably because N^2 shared secrets > between end users didn't seem that attractive. Right. This boils down to the trust model that one wants to employ, the original reason for doing security. Security for user x user is definately hard without public keys or similar methods. Security to your company/provider works better (perhaps even where that company/provider acts as a proxy to give the second secure m2e leg to the peer user). > The primary problem is getting shared secrets between two parties in > networks operated by competitors or in networks that don't know about > each other. Columbia University shouldn't have to set up a trust > relationship with kolumbus.fi for me to make a call to you. Yes. These could be different things, however. It could be that Columbia University wants to protect your signaling as it passses through their proxy, for accounting and other reasons, but they might not care at all who you are talking to. If I wanted a secure session with you, I propably wouldn't involve either organization in the trust model and would exchange keys with you directly. Nevertheless, I'm quite willing to go through a number of providers who perhaps require me to protect my signaling as I pass through their proxies. > > The need for pk or infrastructure seems to be more related to the kind > > of trust model one has; secure communication to your home proxy/server > > is quite OK even over other proxies, but if you want e2e to another random > > user, or want security to a random proxy you go through, then there's > > more trouble. > > I think we're in agreement. That's primarily my concern, as yours and > other work seem to provide a decent handle on the e2p case. In those > cases, shared secrets work quite well, as we know from login, network > file systems, etc. Yes. And I think we need the applicability statement also for the shared secret model. Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sat Nov 24 17:05:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25481 for ; Sat, 24 Nov 2001 17:05:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA10842 for sip-security-archive@odin.ietf.org; Sat, 24 Nov 2001 17:05:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10312; Sat, 24 Nov 2001 16:53:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10281 for ; Sat, 24 Nov 2001 16:53:42 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25377 for ; Sat, 24 Nov 2001 16:53:39 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fAOLreV16334; Sat, 24 Nov 2001 16:53:40 -0500 (EST) Message-ID: <3C0016E4.E3CFC4C0@cs.columbia.edu> Date: Sat, 24 Nov 2001 16:53:40 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: sip-security@ietf.org Subject: Re: [Sip-security] A minimalist security framework for SIP References: <3BF861AB.D6191185@cs.columbia.edu> <00a601c1712d$f9c6b1e0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Indeed. I might add that it could be quite OK to have some > infrastructure such as a RADIUS/DIAMETER server on a > home org to keep the passwords/whatever for the users, but > if we start requiring some sort of global interconnection using > certificates between all users and all random proxies in the > network, we're in trouble. As useful as they are, servers in the home domain are likely to only be useful for REGISTER or INVITEs within the same domain. > The need for pk or infrastructure seems to be more related to the kind > of trust model one has; secure communication to your home proxy/server > is quite OK even over other proxies, but if you want e2e to another random > user, or want security to a random proxy you go through, then there's > more trouble. That's what I'm focusing on, as we seem to have at least plausible non-PK solutions for authenticating to a home proxy, say. > >The To, From, Call-ID, CSeq and Date header fields MUST be included > >in the HMAC. > > Why not all? Or some set definition as in the Undery draft? This already has a set definition (header=). The set I listed would seem to be the minimal useful set for SIP; I clarified the wording. Thanks again for the comments; I've folded them into the draft. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sat Nov 24 17:36:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25814 for ; Sat, 24 Nov 2001 17:36:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA11352 for sip-security-archive@odin.ietf.org; Sat, 24 Nov 2001 17:36:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10952; Sat, 24 Nov 2001 17:17:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10917 for ; Sat, 24 Nov 2001 17:17:57 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25569 for ; Sat, 24 Nov 2001 17:17:54 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fAOMHtV17263; Sat, 24 Nov 2001 17:17:55 -0500 (EST) Message-ID: <3C001C93.AA3CBB81@cs.columbia.edu> Date: Sat, 24 Nov 2001 17:17:55 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: sip-security@ietf.org Subject: Re: [Sip-security] A minimalist security framework for SIP References: <3BF861AB.D6191185@cs.columbia.edu> <00a601c1712d$f9c6b1e0$8a1b6e0a@arenanet.fi> <3BF965AB.20D2F86A@cs.columbia.edu> <010201c1713a$b025e580$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > > These are definately different use cases, but it might be that the > SIP-level mechanisms to achieve the same thing could be similar. > Session keys are essentially an optimization, and they require some > form of symmetric crypto encapsulation (maybe CMS/digest/smime). Maybe we can separate the security processes into two parts: (1) Obtain a shared secret (2) Use it. (1) can be via an earlier SMIME exchange between the two parties, via a pre-shared key in a registration relationship, via some kind of Kerberos-style KDC. (2) would be either in Digest (requiring either a 401 round trip or the MD5-sess mechanism in 2617), some form of HMAC or SMIME with shared secrets (if that's possible). Is that a > If we could assume that whatever authentication we do with our friends > and operators both can produce session keys, then both could use > similar methods to pass protected data in subsequent messages > without the overhead of new public key operations, AAA calls or > whatever that is needed. > > My main issue with it is that the auth-int doesn't cover enough. The enhanced versions (Undery, Sen) address this, right? > You're right, it doesn't help for the e2e case... at least not with INVITEs. Maybe it > does help in some of the other messages, such as REGISTER that are > e2e between you and your provider. For proxying the REGISTER to my home registrar, I don't see much need for authentication at intermediate proxies (or for intermediate proxies to authenticate themselves to me). What matters is that I'm talking to the right registrar, and the registrar to the right user. > > > Again, I omitted those by accident, probably because N^2 shared secrets > > between end users didn't seem that attractive. > > Right. This boils down to the trust model that one wants to employ, > the original reason for doing security. Security for user x user is > definately hard without public keys or similar methods. Security > to your company/provider works better (perhaps even where that > company/provider acts as a proxy to give the second secure > m2e leg to the peer user). Maybe we should discuss what "typical" deployments might look like. For non-forwarded calls, it seems that caller - [outbound proxy] - some number of other proxies - ["destination" proxy] - more proxies on the way to callee - callee would be typical, where I enclosed the proxies doing authentication in []. If we can reduce this to caller - [outbound proxy] - [destination proxy] - trusted network - callee things become somewhat simpler, as you could then indeed have "big company" to "big company" authorization, somewhat similar to the trust model in today's phone network. In that simplified model, as long as both []'s have public keys (likely) and each party trusts each home network operator, if the []'s use L3 or L4 security, users are reasonably well protected. This obviously doesn't work if the destination proxy (home network) ends up sending the request through some untrusted network to the callee. > > > The primary problem is getting shared secrets between two parties in > > networks operated by competitors or in networks that don't know about > > each other. Columbia University shouldn't have to set up a trust > > relationship with kolumbus.fi for me to make a call to you. > > Yes. These could be different things, however. It could be that Columbia > University wants to protect your signaling as it passses through their > proxy, for accounting and other reasons, but they might not care at > all who you are talking to. If I wanted a secure session with you, > I propably wouldn't involve either organization in the trust model and > would exchange keys with you directly. Nevertheless, I'm quite willing > to go through a number of providers who perhaps require me to protect > my signaling as I pass through their proxies. Protecting signaling seems like something we have L3 and L4 security for. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sat Nov 24 20:58:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27033 for ; Sat, 24 Nov 2001 20:58:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA14501 for sip-security-archive@odin.ietf.org; Sat, 24 Nov 2001 20:58:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14391; Sat, 24 Nov 2001 20:36:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14354 for ; Sat, 24 Nov 2001 20:36:14 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26894 for ; Sat, 24 Nov 2001 20:36:11 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id A74721E045; Sat, 24 Nov 2001 20:36:10 -0500 (EST) Received: from research.att.com (wold5173.research.att.com [135.207.53.173]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id UAA03703; Sat, 24 Nov 2001 20:36:08 -0500 (EST) Message-ID: <3C0049E9.2A57AEBD@research.att.com> Date: Sat, 24 Nov 2001 20:31:21 -0500 From: Charles Kalmanek X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: sip-security@ietf.org Subject: Re: [Sip-security] A minimalist security framework for SIP References: <3BF861AB.D6191185@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Hi, Henning, Thanks for starting this discussion. First, I'll list the things which, at first reading, I like: 1. I agree that sip proxies should use pairwise network or transport layer security associations to provide message privacy and integrity. 2. Seems reasonable to assume that an important deployment scenario will involve bilateral trust among companies operating proxies. 3. I agree that we shouldn't assume that clients have certificates. (I need to think more about proxies). 4. Having outbound proxies sign all unsigned requests & responses allows message authentication of the form "this message originated by user@domain" for an authenticated user. 5. Having clients HMAC messages once they have a shared key allows end to end message privacy and integrity. I'm not sure about enhanced digest though. We've been thinking in what contexts it would be acceptable. If I understand it correctly, it does not provide either privacy or proxy authentication. Re: privacy. Most people have come to expect that phone calls are not trivially easy to eavesdrop on. Without secure signaling and secure media, this isn't true. But let's set this aside, since securing the media may be perceived to be a somewhat high bar to set for a minimalist solution. Re: lack of proxy authentication. At a minimum, I think the draft should state the assumptions under which this provides acceptable security. Pre-configured proxy address in clients? Only for use behind firewalls? Spoofing a proxy is pretty easy on a LAN. chuck "Henning G. Schulzrinne" wrote: > > Instigated by some recent frustration expressed by a colleague, I > drafted a strawman that tries to get from the perennial (or, rather, > every-four-months) hand-wringing about the lack of progress on SIP > security to at least a summary of where we are and where we might be > able to get to reasonably quickly. > > http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-sip-security-00.txt _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sat Nov 24 22:10:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28440 for ; Sat, 24 Nov 2001 22:10:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA15737 for sip-security-archive@odin.ietf.org; Sat, 24 Nov 2001 22:10:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15377; Sat, 24 Nov 2001 21:59:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15349 for ; Sat, 24 Nov 2001 21:59:44 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28383 for ; Sat, 24 Nov 2001 21:59:40 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA19564; Sat, 24 Nov 2001 21:59:42 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fAP2xf810986; Sat, 24 Nov 2001 21:59:42 -0500 (EST) Message-ID: <3C005F53.EB88C893@cs.columbia.edu> Date: Sat, 24 Nov 2001 22:02:43 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Charles Kalmanek CC: sip-security@ietf.org Subject: Re: [Sip-security] A minimalist security framework for SIP References: <3BF861AB.D6191185@cs.columbia.edu> <3C0049E9.2A57AEBD@research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Charles Kalmanek wrote: > > Hi, Henning, > > Thanks for starting this discussion. First, I'll list the > things which, at first reading, I like: > > 1. I agree that sip proxies should use pairwise network or > transport layer security associations to provide message > privacy and integrity. > 2. Seems reasonable to assume that an important deployment > scenario will involve bilateral trust among companies > operating proxies. > 3. I agree that we shouldn't assume that clients have > certificates. (I need to think more about proxies). > 4. Having outbound proxies sign all unsigned requests & > responses allows message authentication of the form "this > message originated by user@domain" for an authenticated > user. > 5. Having clients HMAC messages once they have a shared key > allows end to end message privacy and integrity. > > I'm not sure about enhanced digest though. We've been > thinking in what contexts it would be acceptable. If > I understand it correctly, it does not provide either > privacy or proxy authentication. Correct, in its current form. I believe, however, that the Undery draft can be trivially extended to work for Proxy-Authorization as well. Digest > > Re: privacy. Most people have come to expect that phone > calls are not trivially easy to eavesdrop on. Without This may be a case of blissful ignorance: All it takes in my town is to open the box on the main road and get a butt set and you'll get your choice of the town's gossip. (The pedestal seems to be unlocked, sometimes even with the door ajar.) That said, I agree that we clearly need encryption in addition to authentication. The S/MIME solution sketched (described would be too generous a word) offers that. Would you suggest a different solution? Another possibility is to rely on hop-by-hop encryption at L3 or L4. Avoids exposing the "outer" headers, but has its own set of problems. I vaguely remember somebody (your group?) proposing a Proxy-Require that asks the next hop to use L3/4 encryption. Clearly, this has roughly the same trust model as the currrent phone system. > secure signaling and secure media, this isn't true. But > let's set this aside, since securing the media may be > perceived to be a somewhat high bar to set for a minimalist > solution. SRTP seems to be an ok solution for securing media, but the key exchange problem remains. S/MIME encryption of SDP is one solution; some version of Kerberos KDCs have been suggested here recently. Other approaches? > > Re: lack of proxy authentication. At a minimum, I think > the draft should state the assumptions under which this > provides acceptable security. Pre-configured proxy address > in clients? Only for use behind firewalls? Spoofing a > proxy is pretty easy on a LAN. You mean the client ascertaining the identity of the server or the other way around? > > chuck > _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sun Nov 25 02:35:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17522 for ; Sun, 25 Nov 2001 02:35:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28018 for sip-security-archive@odin.ietf.org; Sun, 25 Nov 2001 02:35:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27593; Sun, 25 Nov 2001 02:17:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27558 for ; Sun, 25 Nov 2001 02:17:17 -0500 (EST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17361 for ; Sun, 25 Nov 2001 02:17:14 -0500 (EST) Received: from jariws1 ([62.248.154.94]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011125071715.JPUZ2704.fep01-app.kolumbus.fi@jariws1>; Sun, 25 Nov 2001 09:17:15 +0200 Message-ID: <019801c17581$40b7c1a0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Henning Schulzrinne" , "Charles Kalmanek" Cc: References: <3BF861AB.D6191185@cs.columbia.edu> <3C0049E9.2A57AEBD@research.att.com> <3C005F53.EB88C893@cs.columbia.edu> Subject: Re: [Sip-security] A minimalist security framework for SIP Date: Sun, 25 Nov 2001 09:17:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit > Re: lack of proxy authentication. At a minimum, I think > the draft should state the assumptions under which this > provides acceptable security. Pre-configured proxy address > in clients? Only for use behind firewalls? Spoofing a > proxy is pretty easy on a LAN. The current Digest proxy mechanisms are pretty useless, imho. It only works one way, it doesn't protect all of the messages even where it could, it is hard to protect responses, etc. So we need some work here. My personal view of what should get is a two-level solution where the first level is mandatory and the second one is optional for those who have the CPU. The first level should provide at least integrity and replay protection, and operate based on symmetric crypto (e.g. enhanced digest). The second level should provide in addition operation in a N x N networks using asymmetric crypto, and confidentiality (e.g. S/MIME). You could perhaps compare these levels to having manually keyed IPsec, and IPsec with certs. (Of course, IPsec wouldn't cut it because we need to go through proxies.) Question: does anyone know if S/MIME gives replay protection? Does everyone agree that we need replay protection? I would assume so, unless we want to allow attackers to replay a dangerous or expensive INVITE. As for making Digest better, the following may help (though I think it should be extended to cover end-to-end as well, and perhaps merged with the undery work): http://search.ietf.org/internet-drafts/draft-sen-sipping-onehop-digest-00.txt Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sun Nov 25 02:36:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17537 for ; Sun, 25 Nov 2001 02:36:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28032 for sip-security-archive@odin.ietf.org; Sun, 25 Nov 2001 02:36:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27453; Sun, 25 Nov 2001 02:01:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27422 for ; Sun, 25 Nov 2001 02:01:08 -0500 (EST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09775 for ; Sun, 25 Nov 2001 02:01:05 -0500 (EST) Received: from jariws1 ([62.248.154.94]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011125070106.JVOL4415.fep02-app.kolumbus.fi@jariws1>; Sun, 25 Nov 2001 09:01:06 +0200 Message-ID: <019401c1757e$fec2e880$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Henning Schulzrinne" , "Charles Kalmanek" Cc: References: <3BF861AB.D6191185@cs.columbia.edu> <3C0049E9.2A57AEBD@research.att.com> <3C005F53.EB88C893@cs.columbia.edu> Subject: Re: [Sip-security] A minimalist security framework for SIP Date: Sun, 25 Nov 2001 09:01:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit > > But let's set this aside, since securing the media may be > > perceived to be a somewhat high bar to set for a minimalist > > solution. > > SRTP seems to be an ok solution for securing media, but the key exchange > problem remains. S/MIME encryption of SDP is one solution; some version > of Kerberos KDCs have been suggested here recently. Other approaches? I think we should allow for secure media as well, though propably not all hosts want do that so it should be an optional component of the framework. As for the key management of SRTP, here's another approach: http://search.ietf.org/internet-drafts/draft-ietf-msec-mikey-00.txt Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sun Nov 25 11:05:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21737 for ; Sun, 25 Nov 2001 11:05:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06067 for sip-security-archive@odin.ietf.org; Sun, 25 Nov 2001 11:06:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05732; Sun, 25 Nov 2001 11:00:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05704 for ; Sun, 25 Nov 2001 11:00:01 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21685 for ; Sun, 25 Nov 2001 10:59:58 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fAPFxwV19996; Sun, 25 Nov 2001 10:59:59 -0500 (EST) Message-ID: <3C01157E.A46E2A7B@cs.columbia.edu> Date: Sun, 25 Nov 2001 10:59:58 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: sip-security@ietf.org Subject: Re: [Sip-security] A minimalist security framework for SIP References: <3BF861AB.D6191185@cs.columbia.edu> <3C0049E9.2A57AEBD@research.att.com> <3C005F53.EB88C893@cs.columbia.edu> <019401c1757e$fec2e880$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit This would seem largely orthogonal to SIP security, even though SIP (and SDP) may be participants. Jari Arkko wrote: > > > > But let's set this aside, since securing the media may be > > > perceived to be a somewhat high bar to set for a minimalist > > > solution. > > > > SRTP seems to be an ok solution for securing media, but the key exchange > > problem remains. S/MIME encryption of SDP is one solution; some version > > of Kerberos KDCs have been suggested here recently. Other approaches? > > I think we should allow for secure media as well, though propably not all > hosts want do that so it should be an optional component of the framework. > As for the key management of SRTP, here's another approach: > > http://search.ietf.org/internet-drafts/draft-ietf-msec-mikey-00.txt > > Jari -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sun Nov 25 11:23:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21864 for ; Sun, 25 Nov 2001 11:23:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06162 for sip-security-archive@odin.ietf.org; Sun, 25 Nov 2001 11:23:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06141; Sun, 25 Nov 2001 11:18:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06108 for ; Sun, 25 Nov 2001 11:18:54 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21835 for ; Sun, 25 Nov 2001 11:18:51 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id D767C4CE79; Sun, 25 Nov 2001 11:18:50 -0500 (EST) Received: from research.att.com (wold5173.research.att.com [135.207.53.173]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA08417; Sun, 25 Nov 2001 11:18:49 -0500 (EST) Message-ID: <3C0118C7.920AF8CA@research.att.com> Date: Sun, 25 Nov 2001 11:13:59 -0500 From: Charles Kalmanek X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: sip-security@ietf.org Subject: Re: [Sip-security] A minimalist security framework for SIP References: <3BF861AB.D6191185@cs.columbia.edu> <3C0049E9.2A57AEBD@research.att.com> <3C005F53.EB88C893@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Hi, Henning. Comments inline. Henning Schulzrinne wrote: > > Charles Kalmanek wrote: > > > > I'm not sure about enhanced digest though. We've been > > thinking in what contexts it would be acceptable. If > > I understand it correctly, it does not provide either > > privacy or proxy authentication. > > Correct, in its current form. I believe, however, that the Undery draft > can be trivially extended to work for Proxy-Authorization as well. I'd say that this is worth doing. Is the same extension feasible for digest+pnonce? > > > > Re: privacy. Most people have come to expect that phone > > calls are not trivially easy to eavesdrop on. Without > > This may be a case of blissful ignorance: All it takes in my town is to > open the box on the main road and get a butt set and you'll get your > choice of the town's gossip. (The pedestal seems to be unlocked, > sometimes even with the door ajar.) Understood, but with many Ethernet installations, it's the equivalent of bringing the "box" into my office, where I can sniff packets w/ impunity. In corporate LANs for example, I think managers would be legimately concerned to learn that employees could trivially eavesdrop on their phone calls. > That said, I agree that we clearly need encryption in addition to > authentication. The S/MIME solution sketched (described would be too > generous a word) offers that. Would you suggest a different solution? I need to read through all the S/MIME stuff; will get back to you. > Another possibility is to rely on hop-by-hop encryption at L3 or L4. > Avoids exposing the "outer" headers, but has its own set of problems. I > vaguely remember somebody (your group?) proposing a Proxy-Require that > asks the next hop to use L3/4 encryption. Clearly, this has roughly the > same trust model as the currrent phone system. > > > secure signaling and secure media, this isn't true. But > > let's set this aside, since securing the media may be > > perceived to be a somewhat high bar to set for a minimalist > > solution. > > SRTP seems to be an ok solution for securing media, but the key exchange > problem remains. S/MIME encryption of SDP is one solution; some version > of Kerberos KDCs have been suggested here recently. Other approaches? Well, proxies might be another example of a trusted 3rd party. But I haven't thought through the trust models enough to advocate this approach. > > Re: lack of proxy authentication. At a minimum, I think > > the draft should state the assumptions under which this > > provides acceptable security. Pre-configured proxy address > > in clients? Only for use behind firewalls? Spoofing a > > proxy is pretty easy on a LAN. > > You mean the client ascertaining the identity of the server or the other > way around? I was alluding to the ability of a random host on a LAN to respond to or generate messages as if they were the local proxy. _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sun Nov 25 11:36:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22076 for ; Sun, 25 Nov 2001 11:36:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06560 for sip-security-archive@odin.ietf.org; Sun, 25 Nov 2001 11:36:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06545; Sun, 25 Nov 2001 11:31:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06508 for ; Sun, 25 Nov 2001 11:31:29 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22000 for ; Sun, 25 Nov 2001 11:31:26 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fAPGVTV20968; Sun, 25 Nov 2001 11:31:29 -0500 (EST) Message-ID: <3C011CE1.4339266C@cs.columbia.edu> Date: Sun, 25 Nov 2001 11:31:29 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Charles Kalmanek CC: sip-security@ietf.org Subject: Re: [Sip-security] A minimalist security framework for SIP References: <3BF861AB.D6191185@cs.columbia.edu> <3C0049E9.2A57AEBD@research.att.com> <3C005F53.EB88C893@cs.columbia.edu> <3C0118C7.920AF8CA@research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Charles Kalmanek wrote: > I'd say that this is worth doing. Is the same extension feasible > for digest+pnonce? I believe so. James willing, I will be working with him to make this happen. > > > > > > > Re: privacy. Most people have come to expect that phone > > > calls are not trivially easy to eavesdrop on. Without > > > > This may be a case of blissful ignorance: All it takes in my town is to > > open the box on the main road and get a butt set and you'll get your > > choice of the town's gossip. (The pedestal seems to be unlocked, > > sometimes even with the door ajar.) > > Understood, but with many Ethernet installations, it's the equivalent > of bringing the "box" into my office, where I can sniff packets w/ > impunity. In corporate LANs for example, I think managers would > be legimately concerned to learn that employees could trivially > eavesdrop on their phone calls. Well, they'd be surprised to learn that in some cases, employees can trivially eavesdrop on their email... However, issues of perception vs. reality aside, we clearly need to have good solution for media privacy. One question that isn't clear to me is whether there are cases where SRTP is needed and IPsec wouldn't work. I'm trying to minimize the number of security protocols, particularly special-purpose ones. I can see that RTP translators would mess up IPsec. Anything else? > > > > You mean the client ascertaining the identity of the server or the other > > way around? > > I was alluding to the ability of a random host on a LAN to > respond to or generate messages as if they were the local proxy. I agree that that is bad, but wouldn't IPsec or TLS be the appropriate solution here, given that the outbound proxy is one IP hop away from the client? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sun Nov 25 11:58:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22396 for ; Sun, 25 Nov 2001 11:58:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06741 for sip-security-archive@odin.ietf.org; Sun, 25 Nov 2001 11:58:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06732; Sun, 25 Nov 2001 11:53:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06693 for ; Sun, 25 Nov 2001 11:53:56 -0500 (EST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22331 for ; Sun, 25 Nov 2001 11:53:52 -0500 (EST) Received: from jariws1 ([62.248.154.94]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011125165355.MVAI4415.fep02-app.kolumbus.fi@jariws1>; Sun, 25 Nov 2001 18:53:55 +0200 Message-ID: <003c01c175d1$c8c8c4e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Henning G. Schulzrinne" Cc: References: <3BF861AB.D6191185@cs.columbia.edu> <3C0049E9.2A57AEBD@research.att.com> <3C005F53.EB88C893@cs.columbia.edu> <019401c1757e$fec2e880$8a1b6e0a@arenanet.fi> <3C01157E.A46E2A7B@cs.columbia.edu> Subject: Re: [Sip-security] A minimalist security framework for SIP Date: Sun, 25 Nov 2001 18:54:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit > This would seem largely orthogonal to SIP security, even though SIP (and > SDP) may be participants. Yes, and I think we like it orthogonal. Then we can concentrate on SIP security on ensuring that the signaling is protected. Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sun Nov 25 11:58:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22416 for ; Sun, 25 Nov 2001 11:58:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06755 for sip-security-archive@odin.ietf.org; Sun, 25 Nov 2001 11:58:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06679; Sun, 25 Nov 2001 11:52:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06648 for ; Sun, 25 Nov 2001 11:52:56 -0500 (EST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22327 for ; Sun, 25 Nov 2001 11:52:52 -0500 (EST) Received: from jariws1 ([62.248.154.94]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011125165255.MPZG2704.fep01-app.kolumbus.fi@jariws1>; Sun, 25 Nov 2001 18:52:55 +0200 Message-ID: <003701c175d1$a5088c20$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Henning G. Schulzrinne" , "Charles Kalmanek" Cc: References: <3BF861AB.D6191185@cs.columbia.edu> <3C0049E9.2A57AEBD@research.att.com> <3C005F53.EB88C893@cs.columbia.edu> <3C0118C7.920AF8CA@research.att.com> <3C011CE1.4339266C@cs.columbia.edu> Subject: Re: [Sip-security] A minimalist security framework for SIP Date: Sun, 25 Nov 2001 18:53:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit > One question that isn't clear to me is whether there are cases where > SRTP is needed and IPsec wouldn't work. I'm trying to minimize the > number of security protocols, particularly special-purpose ones. I can > see that RTP translators would mess up IPsec. Anything else? Headers on a low bandwidth link. More seriously, ESP CBC cipher behaviour with respect to bit errors. SRTP survives bit errors, in ESP they in practise destroy the whole packet. Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sun Nov 25 22:44:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29195 for ; Sun, 25 Nov 2001 22:44:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA17520 for sip-security-archive@odin.ietf.org; Sun, 25 Nov 2001 22:44:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17445; Sun, 25 Nov 2001 22:39:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17413 for ; Sun, 25 Nov 2001 22:39:57 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29135 for ; Sun, 25 Nov 2001 22:39:53 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 941711E075; Sun, 25 Nov 2001 22:39:56 -0500 (EST) Received: from research.att.com (wold5173.research.att.com [135.207.53.173]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id WAA12582; Sun, 25 Nov 2001 22:39:55 -0500 (EST) Message-ID: <3C01B884.21B1DAD9@research.att.com> Date: Sun, 25 Nov 2001 22:35:32 -0500 From: Charles Kalmanek X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: sip-security@ietf.org Subject: Re: [Sip-security] A minimalist security framework for SIP References: <3BF861AB.D6191185@cs.columbia.edu> <3C0049E9.2A57AEBD@research.att.com> <3C005F53.EB88C893@cs.columbia.edu> <3C0118C7.920AF8CA@research.att.com> <3C011CE1.4339266C@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Comments inline. > However, issues of perception vs. reality aside, we clearly need to have > good solution for media privacy. Agreed. > One question that isn't clear to me is whether there are cases where > SRTP is needed and IPsec wouldn't work. I'm trying to minimize the > number of security protocols, particularly special-purpose ones. I can > see that RTP translators would mess up IPsec. Anything else? When RTP translators are present, it seems that they are an endpoint either of the IPsec SA or the SRTP session. Is there a major difference? > > I was alluding to the ability of a random host on a LAN to > > respond to or generate messages as if they were the local proxy. > > I agree that that is bad, but wouldn't IPsec or TLS be the appropriate > solution here, given that the outbound proxy is one IP hop away from the > client? Exactly. We have been trying to determine under what scenarios digest+enhancements might be acceptable. I'm not sure there are many. _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sun Nov 25 23:13:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29379 for ; Sun, 25 Nov 2001 23:13:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA18029 for sip-security-archive@odin.ietf.org; Sun, 25 Nov 2001 23:13:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA17996; Sun, 25 Nov 2001 23:09:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA17964 for ; Sun, 25 Nov 2001 23:09:19 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29359 for ; Sun, 25 Nov 2001 23:09:14 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id XAA15943; Sun, 25 Nov 2001 23:09:18 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fAQ49H817998; Sun, 25 Nov 2001 23:09:17 -0500 (EST) Message-ID: <3C01C118.BAB001F6@cs.columbia.edu> Date: Sun, 25 Nov 2001 23:12:08 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Charles Kalmanek CC: sip-security@ietf.org Subject: Re: [Sip-security] A minimalist security framework for SIP References: <3BF861AB.D6191185@cs.columbia.edu> <3C0049E9.2A57AEBD@research.att.com> <3C005F53.EB88C893@cs.columbia.edu> <3C0118C7.920AF8CA@research.att.com> <3C011CE1.4339266C@cs.columbia.edu> <3C01B884.21B1DAD9@research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit > When RTP translators are present, it seems that they are an endpoint > either of the IPsec SA or the SRTP session. Is there a major > difference? Not that I can tell, but others have pointed out more important differences. > Exactly. We have been trying to determine under what scenarios > digest+enhancements might be acceptable. I'm not sure there are > many. I think it remains a good low-cost solution for e2e authentication (where IPsec and TLS wouldn't do), in particular REGISTER and SUBSCRIBE, but also INVITE. IPsec and TLS have costs, as discussed earlier, both in terms of implementation complexity and delay. _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Nov 26 00:33:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00401 for ; Mon, 26 Nov 2001 00:33:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA19824 for sip-security-archive@odin.ietf.org; Mon, 26 Nov 2001 00:33:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19441; Mon, 26 Nov 2001 00:27:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19407 for ; Mon, 26 Nov 2001 00:27:46 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00322 for ; Mon, 26 Nov 2001 00:27:44 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQ5PEhp028869; Mon, 26 Nov 2001 00:25:14 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 00:26:41 -0500 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , Charles Kalmanek Cc: sip-security@ietf.org Subject: RE: [Sip-security] A minimalist security framework for SIP Date: Mon, 26 Nov 2001 00:26:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, November 25, 2001 11:12 PM > To: Charles Kalmanek > Cc: sip-security@ietf.org > Subject: Re: [Sip-security] A minimalist security framework for SIP > > > > > When RTP translators are present, it seems that they are an endpoint > > either of the IPsec SA or the SRTP session. Is there a major > > difference? > > Not that I can tell, but others have pointed out more important > differences. > > > Exactly. We have been trying to determine under what scenarios > > digest+enhancements might be acceptable. I'm not sure there are > > many. > > I think it remains a good low-cost solution for e2e authentication > (where IPsec and TLS wouldn't do), in particular REGISTER and > SUBSCRIBE, > but also INVITE. IPsec and TLS have costs, as discussed > earlier, both in > terms of implementation complexity and delay. Its not clear to me that shared secrets will exist end-to-end often enough to be really useful, especially in the case of interdomain operation. In that case, the big question is whether we need the enhance digest stuff for user<->proxy; TLS/IPSec would be easier to specify and meet all the security needs. I think the latency is a non-issue for persistent connections, the real issue is the cost of maintaing an extremely large number of such open connections. I still don't feel anyone has provided any concrete data on that. For the e2e case, I think the only workable models are (1) some kind of transitive trust situation, as has been discussed already, (2) some mechanism for automatically establishing a shared secret after the first call. This would be similar to the SSH model - you could ensure that someone who calls again is the same person that called last time. That works well for INVITE, but its not clear its useful for SUBSCRIBE. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Nov 26 09:09:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27577 for ; Mon, 26 Nov 2001 09:09:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08541 for sip-security-archive@odin.ietf.org; Mon, 26 Nov 2001 09:09:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08472; Mon, 26 Nov 2001 09:05:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08441 for ; Mon, 26 Nov 2001 09:05:53 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27292 for ; Mon, 26 Nov 2001 09:05:48 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA01978; Mon, 26 Nov 2001 09:05:47 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fAQE5k822103; Mon, 26 Nov 2001 09:05:46 -0500 (EST) Message-ID: <3C024CE1.79769ABA@cs.columbia.edu> Date: Mon, 26 Nov 2001 09:08:33 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Charles Kalmanek , sip-security@ietf.org Subject: Re: [Sip-security] A minimalist security framework for SIP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit > Its not clear to me that shared secrets will exist end-to-end often enough > to be really useful, especially in the case of interdomain operation. In Agreed; that's why I emphasized REGISTER and SUBSCRIBE, which are more likely to go to the home domain. (SUBSCRIBE for various SIP-related events, not buddy lists.) > that case, the big question is whether we need the enhance digest stuff for > user<->proxy; TLS/IPSec would be easier to specify and meet all the security I think this is mainly an issue of complexity. TLS is non-trivial for embedded systems and for IPsec, I wouldn't want to foist IKE on anybody, let alone embedded systems. Maybe son-of-IKE / JFK make this a more viable proposition. > needs. I think the latency is a non-issue for persistent connections, the > real issue is the cost of maintaing an extremely large number of such open > connections. I still don't feel anyone has provided any concrete data on > that. Agreed; hopefully, we'll have our TLS implementation running by year's end and should be able to do those experiments across our range of platforms (Linux, WinNT, Solaris, Tru64, FreeBSD). > > For the e2e case, I think the only workable models are (1) some kind of > transitive trust situation, as has been discussed already, (2) some > mechanism for automatically establishing a shared secret after the first > call. This would be similar to the SSH model - you could ensure that someone > who calls again is the same person that called last time. That works well > for INVITE, but its not clear its useful for SUBSCRIBE. The problem is that active MIM attacks require externally signed certificates, not just D-H. Thus, you still need a client-level PK infrastructure. > > -Jonathan R. _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Nov 26 11:51:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11480 for ; Mon, 26 Nov 2001 11:51:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16387 for sip-security-archive@odin.ietf.org; Mon, 26 Nov 2001 11:52:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16254; Mon, 26 Nov 2001 11:47:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16223 for ; Mon, 26 Nov 2001 11:47:55 -0500 (EST) Received: from fw11.telekom.de (gw11.telekom.de [62.225.183.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11105 for ; Mon, 26 Nov 2001 11:47:50 -0500 (EST) Received: by fw11.telekom.de; (8.8.8/1.3/10May95) id RAA31627; Mon, 26 Nov 2001 17:45:13 +0100 (MET) Received: from Q9J99.mgb01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for sip-security@ietf.org; Mon, 26 Nov 2001 17:37:57 +0100 Received: from g9jbq.mgb01.telekom.de by Q9J99.mgb01.telekom.de with ESMTP for sip-security@ietf.org; Mon, 26 Nov 2001 17:37:47 +0100 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 17:37:46 +0100 Message-Id: From: "Beck01, Wolfgang" To: sip-security@ietf.org Date: Mon, 26 Nov 2001 17:37:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip-security] how many TCP connections can be handled? Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org TCP itself does not have a big overhead compared to UDP if messages must be sent reliably. But with UDP, the application programmer can use a single socket and demultiplex the incoming messages by their source ip address and source port. There is no need to determine message boundaries. With TCP, the programmer has to deal with hundreds or thousands of sockets when developing a server. The common select() and poll() system calls are not very good at this. Multithreading does not scale too well either. Multiple reads may be necessary to receive a complete message. Faster constructs like /dev/poll (Solaris, Linux), kqueue()/ kevent() (BSD) or Mach's port sets are not commonly used at this time. Some numbers: The SPECWeb99 pages (http://www.spec.org/osg/web99) contain http server benchmarks. SIP proxies have not as much disk IO, so the 'Conforming Simultaneous Connections' displayed there will be higher for SIP. With in-kernel http server support (TUX 2.0) the number of Conforming Simultaneous Connections doubles. One source says that SSL reduces the [http] server capacity by 33 - 50 percent depending on the strength of encryption used in the connection. A different source talks about a reduction of 17 - 22 percent. Time to make some tests with openssl.. -- Wolfgang Beck T-Systems Nova GmbH _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Nov 26 13:10:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17420 for ; Mon, 26 Nov 2001 13:10:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20701 for sip-security-archive@odin.ietf.org; Mon, 26 Nov 2001 13:10:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20570; Mon, 26 Nov 2001 13:06:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20543 for ; Mon, 26 Nov 2001 13:06:22 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17157 for ; Mon, 26 Nov 2001 13:06:19 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQI4J7x003214; Mon, 26 Nov 2001 13:04:19 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 13:05:45 -0500 Message-ID: From: Jonathan Rosenberg To: "'Beck01, Wolfgang'" , sip-security@ietf.org Subject: RE: [Sip-security] how many TCP connections can be handled? Date: Mon, 26 Nov 2001 13:05:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org > -----Original Message----- > From: Beck01, Wolfgang [mailto:BeckW@t-systems.de] > Sent: Monday, November 26, 2001 11:38 AM > To: sip-security@ietf.org > Subject: [Sip-security] how many TCP connections can be handled? > > With TCP, the programmer has to deal with hundreds or > thousands of sockets > when developing a server. The common select() and poll() system calls > are not very good at this. Multithreading does not scale too > well either. > Multiple reads may be necessary to receive a complete message. > > Faster constructs like /dev/poll (Solaris, Linux), kqueue()/ kevent() > (BSD) or Mach's port sets are not commonly used at this time. So what are the commercial web servers using? With http 1.1 they will need to handle lots of concurrent connections. > > Some numbers: > > The SPECWeb99 pages (http://www.spec.org/osg/web99) contain > http server > benchmarks. SIP proxies have not as much disk IO, so the 'Conforming > Simultaneous Connections' displayed there will be higher for SIP. With > in-kernel http server support (TUX 2.0) the number of Conforming > Simultaneous Connections doubles. > > One source says that SSL reduces the [http] server capacity > by 33 - 50 percent depending on the strength of encryption used > in the connection. A different source talks about a reduction > of 17 - 22 percent. THis probably depends a lot on your assumption about churn in the connections. With SIP, the SSL connections could be long-lived, avoiding the PKI overheads. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Nov 26 13:22:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18394 for ; Mon, 26 Nov 2001 13:22:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20983 for sip-security-archive@odin.ietf.org; Mon, 26 Nov 2001 13:22:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20928; Mon, 26 Nov 2001 13:19:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20898 for ; Mon, 26 Nov 2001 13:18:58 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18118 for ; Mon, 26 Nov 2001 13:18:55 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id C25091E026; Mon, 26 Nov 2001 13:18:57 -0500 (EST) Received: from research.att.com (pc-crk.research.att.com [135.207.17.83]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA23022; Mon, 26 Nov 2001 13:18:56 -0500 (EST) Message-ID: <3C028797.528BE0A1@research.att.com> Date: Mon, 26 Nov 2001 13:19:03 -0500 From: "C. R. Kalmanek" X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne , Jonathan Rosenberg Cc: sip-security@ietf.org Subject: Re: [Sip-security] A minimalist security framework for SIP References: <3C024CE1.79769ABA@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Comments inline. Henning Schulzrinne wrote: > > that case, the big question is whether we need the enhance digest stuff for > > user<->proxy; TLS/IPSec would be easier to specify and meet all the security > > I think this is mainly an issue of complexity. TLS is non-trivial for > embedded systems and for IPsec, I wouldn't want to foist IKE on anybody, > let alone embedded systems. Maybe son-of-IKE / JFK make this a more > viable proposition. IPsec doesn't imply IKE. You can use pre-shared keys, Kerberos, Passport (which is/will be Kerberos), IKE, JFK... > > For the e2e case, I think the only workable models are (1) some kind of > > transitive trust situation, as has been discussed already, (2) some > > mechanism for automatically establishing a shared secret after the first > > call. This would be similar to the SSH model - you could ensure that someone > > who calls again is the same person that called last time. That works well > > for INVITE, but its not clear its useful for SUBSCRIBE. > > The problem is that active MIM attacks require externally signed > certificates, not just D-H. Thus, you still need a client-level PK > infrastructure. You don't necessarily need PKI, which is complex and I may not live long enough. As Jonathan says, transitive trust works. Kerberos works. Or, I can provision public keys without getting into the complexity of certs, cert revocation, etc. > > > > -Jonathan R. _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Nov 26 15:00:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25892 for ; Mon, 26 Nov 2001 15:00:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24595 for sip-security-archive@odin.ietf.org; Mon, 26 Nov 2001 15:00:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24041; Mon, 26 Nov 2001 14:51:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24013 for ; Mon, 26 Nov 2001 14:51:57 -0500 (EST) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24988 for ; Mon, 26 Nov 2001 14:51:52 -0500 (EST) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA13982 for ; Mon, 26 Nov 2001 13:51:24 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 26 Nov 2001 13:44:10 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 13:49:58 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F310@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jari Arkko'" , Henning Schulzrinne , Charles Kalmanek Cc: sip-security , "Sanjoy Sen" Subject: RE: [Sip-security] A minimalist security framework for SIP Date: Mon, 26 Nov 2001 13:49:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C176B3.875F7C50" X-Orig: Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C176B3.875F7C50 Content-Type: text/plain; charset="iso-8859-1" All, Thanks for bringing this up, Jari! As Henning has rightly pointed out in his draft, several types of security solutions are likely to exist and will be applicable to different markets/terminals. Currently, Digest is the most widespread authentication framework available and I strongly favor an approach which will minimally enhance the existing framework to satisfy the first two of the three key requirements - authentication, integrity and confidentiality. The benefits are code reuse and a cheap, lightweight solution. There has been three drafts which discusses SIP/Digest enhancements: 1) Jonathan's "pnonce" draft - needs no standard's change 2) Undery's "Access Authentication" draft - needs standard's enhancements 3) Sen/Valerius/Torvinens' "one-hop Digest" draft - need very minimal enhancement and perhaps some behavior enhancements on the part of the Proxy/UA The third draft has been recently published at http://search.ietf.org/internet-drafts/draft-sen-sipping-onehop-digest-00.tx t This draft attempts to address the need for integrity protect entire SIP messages over a single hop between the UA and a Proxy as required by certain network operators such as the third-generation mobile network operators. The draft also addresses other issues not addressed by the other two drafts, such as authentication of messages forwarded by the Proxy etc. Some of the issues discussed in this draft fits well with the discussion in Section 8 (In-session authentication for SIP) of Henning's SIP security draft. The draft discusses some potential solutions (without bending the rules of SIP/HTTP) and is intended to be a "request for comments". The issues identified are: 1) UAC-Proxy message authentication: It is not clear from RFC2617/bis05 how the response forwarded upstream by the Proxy towards the UAC will be authenticated. The authors propose using the "Authentication-Info" header for this purpose. 2) UAS-Proxy message authentication: Bis05 does not allow the Proxy to add the Proxy-Authorization header in a request unless it is resubmitted. Jonathan had suggested in the list that "resubmission" can be performed by changing the topmost Via branch id. This would need some behavior enhancements in the Proxy/UAS. Also, Bis05 does not mention the use of Proxy-Authentication-Info which is used by HTTP/Digest for authenticating responses from the UAS to the Proxy. 3) In order to avoid excess round-trip, a Proxy should be able to piggyback its challenge in a 401 or 407 response that it forwards upstream to the UAC. Proxies today are allowed to merge multiple challenges in case of forking. 4) Integrity protect complete (or complete to the extent possible) messages: The undery draft makes this a dynamic list of headers. Jonathan proposes predictive nonce computed on these headers. The sen draft proposes a new qop-options parameter - auth-extd-int - to indicate to the UA/Proxy that a static, pre-negototiated protection level is needed. For some more details on these issues and example call flows, please refer to the draft. The intent of this mail is to stimulate some discussions on these issues and, if possible, resolve them before the IETF meeting. Regards, Sanjoy > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Sunday, November 25, 2001 1:18 AM > To: Henning Schulzrinne; Charles Kalmanek > Cc: sip-security > Subject: Re: [Sip-security] A minimalist security framework for SIP > > > > Re: lack of proxy authentication. At a minimum, I think > > the draft should state the assumptions under which this > > provides acceptable security. Pre-configured proxy address > > in clients? Only for use behind firewalls? Spoofing a > > proxy is pretty easy on a LAN. > > The current Digest proxy mechanisms are pretty useless, > imho. It only works one way, it doesn't protect all of the messages > even where it could, it is hard to protect responses, etc. So > we need some work here. My personal view of what should > get is a two-level solution where the first level is mandatory > and the second one is optional for those who have the CPU. > The first level should provide at least integrity and replay > protection, and operate based on symmetric crypto (e.g. > enhanced digest). The second level should provide in > addition operation in a N x N networks using asymmetric > crypto, and confidentiality (e.g. S/MIME). You could perhaps > compare these levels to having manually keyed IPsec, and > IPsec with certs. (Of course, IPsec wouldn't cut it because we > need to go through proxies.) > > Question: does anyone know if S/MIME gives replay > protection? Does everyone agree that we need replay > protection? I would assume so, unless we want to allow > attackers to replay a dangerous or expensive INVITE. > > As for making Digest better, the following may help (though I > think it should be extended to cover end-to-end as well, and > perhaps merged with the undery work): > > http://search.ietf.org/internet-drafts/draft-sen-sipping-oneho p-digest-00.txt Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security ------_=_NextPart_001_01C176B3.875F7C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip-security] A minimalist security framework for = SIP

All,

Thanks for bringing this up, Jari! As Henning has = rightly pointed out in his draft, several types of security solutions = are likely to exist and will be applicable to different = markets/terminals. Currently, Digest is the most widespread = authentication framework available and I strongly favor an approach = which will minimally enhance the existing framework to satisfy the = first two of the three key requirements - authentication, integrity and = confidentiality. The benefits are code reuse and a cheap, lightweight = solution.

There has been three drafts which discusses = SIP/Digest enhancements:
1) Jonathan's "pnonce" draft - needs no = standard's change
2) Undery's "Access Authentication" = draft  - needs standard's enhancements
3) Sen/Valerius/Torvinens' "one-hop = Digest" draft - need very minimal enhancement and perhaps some = behavior enhancements on the part of the Proxy/UA

The third  draft has been recently published at =
http://search.ietf.org/internet-drafts/draft-sen-sippi= ng-onehop-digest-00.txt

This draft attempts to address the need for integrity = protect entire SIP messages over a single hop between the UA and a = Proxy as required by certain network operators such as the = third-generation mobile network operators. The draft also addresses = other issues not addressed by the other two drafts, such as = authentication of messages forwarded by the Proxy etc. Some of the = issues discussed in this draft fits well with the discussion in Section = 8 (In-session authentication for SIP) of Henning's SIP security = draft.

The draft discusses some potential solutions (without = bending the rules of SIP/HTTP) and is intended to be a "request = for comments".

The issues identified are:
1) UAC-Proxy message authentication: It is not clear = from RFC2617/bis05 how the response forwarded upstream by the Proxy = towards the UAC will be authenticated. The authors propose using the = "Authentication-Info" header for this purpose.

2) UAS-Proxy message authentication: Bis05 does not = allow the Proxy to add the Proxy-Authorization header in a request = unless it is resubmitted. Jonathan had suggested in the list that = "resubmission" can be performed by changing the topmost Via = branch id. This would need some behavior enhancements in the Proxy/UAS. = Also, Bis05 does not mention the use of Proxy-Authentication-Info which = is used by HTTP/Digest for authenticating responses from the UAS to the = Proxy.

3) In order to avoid excess round-trip, a Proxy = should be able to piggyback its challenge in a 401 or 407 response that = it forwards upstream to the UAC. Proxies today are allowed to merge = multiple challenges in case of forking.

4) Integrity protect complete (or complete to the = extent possible) messages: The undery draft makes this a dynamic list = of headers. Jonathan proposes predictive nonce computed on these = headers. The sen draft proposes a new qop-options parameter - = auth-extd-int - to indicate to the UA/Proxy that a static, = pre-negototiated protection level is needed.

For some more details on these issues and example = call flows, please refer to the draft.

The intent of this mail is to stimulate some = discussions on these issues and, if possible, resolve them before the = IETF meeting.

Regards,
Sanjoy


> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@kolumbus.fi= ]
> Sent: Sunday, November 25, 2001 1:18 AM
> To: Henning Schulzrinne; Charles = Kalmanek
> Cc: sip-security
> Subject: Re: [Sip-security] A minimalist = security framework for SIP
>
>
> > Re: lack of proxy authentication.  At = a minimum, I think
> > the draft should state the assumptions = under which this
> > provides acceptable security.  = Pre-configured proxy address
> > in clients?  Only for use behind = firewalls?  Spoofing a
> > proxy is pretty easy on a LAN.
>
> The current Digest proxy mechanisms are pretty = useless,
> imho. It only works one way, it doesn't protect = all of the messages
> even where it could, it is hard to protect = responses, etc. So
> we need some work here. My personal view of = what should
> get is a two-level solution where the first = level is mandatory
> and the second one is optional for those who = have the CPU.
> The first level should provide at least = integrity and replay
> protection, and operate based on symmetric = crypto (e.g.
> enhanced digest). The second level should = provide in
> addition operation in a N x N networks using = asymmetric
> crypto, and confidentiality (e.g. S/MIME). You = could perhaps
> compare these levels to having manually keyed = IPsec, and
> IPsec with certs. (Of course, IPsec wouldn't = cut it because we
> need to go through proxies.)
>
> Question: does anyone know if S/MIME gives = replay
> protection? Does everyone agree that we need = replay
> protection? I would assume so, unless we want = to allow
> attackers to replay a dangerous or expensive = INVITE.
>
> As for making Digest better, the following may = help (though I
> think it should be extended to cover end-to-end = as well, and
> perhaps merged with the undery work):
>
> http://search.ietf.org/internet-drafts/draft-sen-sippi= ng-oneho
p-digest-00.txt

Jari




_______________________________________________
Sip-security mailing list
Sip-security@ietf.org
http://www1.ietf.org/mailman/listinfo/sip-security=

------_=_NextPart_001_01C176B3.875F7C50-- _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Tue Nov 27 07:32:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23077 for ; Tue, 27 Nov 2001 07:32:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA29922 for sip-security-archive@odin.ietf.org; Tue, 27 Nov 2001 07:32:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29483; Tue, 27 Nov 2001 07:25:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29449 for ; Tue, 27 Nov 2001 07:25:35 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22754 for ; Tue, 27 Nov 2001 07:25:32 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 27 Nov 2001 12:25:45 UT Received: from gbnewp0796m ([193.195.52.113]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 27 Nov 2001 12:25:50 +0000 From: "James Undery" To: "'Sanjoy Sen'" , "'Jari Arkko'" , "'Henning Schulzrinne'" , "'Charles Kalmanek'" Cc: "'sip-security'" Subject: RE: [Sip-security] A minimalist security framework for SIP Date: Tue, 27 Nov 2001 12:25:48 -0000 Message-ID: <019c01c1773e$a5f85e80$7134c3c1@eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <933FADF5E673D411B8A30002A5608A0E06F310@zrc2c012.us.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 27 Nov 2001 12:25:50.0114 (UTC) FILETIME=[A614C020:01C1773E] Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Hi, Firstly I do intend to address Proxy-Authenticate (although this harder than it appears at first due to Proxy-Authentication-Info), secondly I'll probably be making it an extension of digest and thirdly I'll include "step-down attack protection" (without the additional messages of the Sen draft). The gist of these changes will be the draft will require no extenstions to SIP (although Proxy-Authentication-Info type behaviour will require some modification for the server to client authentication). Implementations aware of the draft will be able to spot step-down attack in the challange (via pnonces that will still be unguessable and potentially statelessly generated and validated by the server). Currently I don't have the time to publish this draft, although expect to release it early January. James -----Original Message----- From: sip-security-admin@ietf.org [mailto:sip-security-admin@ietf.org]On Behalf Of Sanjoy Sen Sent: 26 November 2001 19:50 To: 'Jari Arkko'; Henning Schulzrinne; Charles Kalmanek Cc: sip-security; Sanjoy Sen Subject: RE: [Sip-security] A minimalist security framework for SIP All, Thanks for bringing this up, Jari! As Henning has rightly pointed out in his draft, several types of security solutions are likely to exist and will be applicable to different markets/terminals. Currently, Digest is the most widespread authentication framework available and I strongly favor an approach which will minimally enhance the existing framework to satisfy the first two of the three key requirements - authentication, integrity and confidentiality. The benefits are code reuse and a cheap, lightweight solution. There has been three drafts which discusses SIP/Digest enhancements: 1) Jonathan's "pnonce" draft - needs no standard's change 2) Undery's "Access Authentication" draft - needs standard's enhancements 3) Sen/Valerius/Torvinens' "one-hop Digest" draft - need very minimal enhancement and perhaps some behavior enhancements on the part of the Proxy/UA The third draft has been recently published at http://search.ietf.org/internet-drafts/draft-sen-sipping-onehop-digest-00.tx t This draft attempts to address the need for integrity protect entire SIP messages over a single hop between the UA and a Proxy as required by certain network operators such as the third-generation mobile network operators. The draft also addresses other issues not addressed by the other two drafts, such as authentication of messages forwarded by the Proxy etc. Some of the issues discussed in this draft fits well with the discussion in Section 8 (In-session authentication for SIP) of Henning's SIP security draft. The draft discusses some potential solutions (without bending the rules of SIP/HTTP) and is intended to be a "request for comments". The issues identified are: 1) UAC-Proxy message authentication: It is not clear from RFC2617/bis05 how the response forwarded upstream by the Proxy towards the UAC will be authenticated. The authors propose using the "Authentication-Info" header for this purpose. 2) UAS-Proxy message authentication: Bis05 does not allow the Proxy to add the Proxy-Authorization header in a request unless it is resubmitted. Jonathan had suggested in the list that "resubmission" can be performed by changing the topmost Via branch id. This would need some behavior enhancements in the Proxy/UAS. Also, Bis05 does not mention the use of Proxy-Authentication-Info which is used by HTTP/Digest for authenticating responses from the UAS to the Proxy. 3) In order to avoid excess round-trip, a Proxy should be able to piggyback its challenge in a 401 or 407 response that it forwards upstream to the UAC. Proxies today are allowed to merge multiple challenges in case of forking. 4) Integrity protect complete (or complete to the extent possible) messages: The undery draft makes this a dynamic list of headers. Jonathan proposes predictive nonce computed on these headers. The sen draft proposes a new qop-options parameter - auth-extd-int - to indicate to the UA/Proxy that a static, pre-negototiated protection level is needed. For some more details on these issues and example call flows, please refer to the draft. The intent of this mail is to stimulate some discussions on these issues and, if possible, resolve them before the IETF meeting. Regards, Sanjoy > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Sunday, November 25, 2001 1:18 AM > To: Henning Schulzrinne; Charles Kalmanek > Cc: sip-security > Subject: Re: [Sip-security] A minimalist security framework for SIP > > > > Re: lack of proxy authentication. At a minimum, I think > > the draft should state the assumptions under which this > > provides acceptable security. Pre-configured proxy address > > in clients? Only for use behind firewalls? Spoofing a > > proxy is pretty easy on a LAN. > > The current Digest proxy mechanisms are pretty useless, > imho. It only works one way, it doesn't protect all of the messages > even where it could, it is hard to protect responses, etc. So > we need some work here. My personal view of what should > get is a two-level solution where the first level is mandatory > and the second one is optional for those who have the CPU. > The first level should provide at least integrity and replay > protection, and operate based on symmetric crypto (e.g. > enhanced digest). The second level should provide in > addition operation in a N x N networks using asymmetric > crypto, and confidentiality (e.g. S/MIME). You could perhaps > compare these levels to having manually keyed IPsec, and > IPsec with certs. (Of course, IPsec wouldn't cut it because we > need to go through proxies.) > > Question: does anyone know if S/MIME gives replay > protection? Does everyone agree that we need replay > protection? I would assume so, unless we want to allow > attackers to replay a dangerous or expensive INVITE. > > As for making Digest better, the following may help (though I > think it should be extended to cover end-to-end as well, and > perhaps merged with the undery work): > > http://search.ietf.org/internet-drafts/draft-sen-sipping-oneho p-digest-00.txt Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Tue Nov 27 10:15:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02507 for ; Tue, 27 Nov 2001 10:15:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA03905 for sip-security-archive@odin.ietf.org; Tue, 27 Nov 2001 10:15:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03855; Tue, 27 Nov 2001 10:10:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03820 for ; Tue, 27 Nov 2001 10:10:56 -0500 (EST) Received: from fw11.telekom.de (gw11.telekom.de [62.225.183.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02259 for ; Tue, 27 Nov 2001 10:10:35 -0500 (EST) Received: by fw11.telekom.de; (8.8.8/1.3/10May95) id QAA23392; Tue, 27 Nov 2001 16:08:26 +0100 (MET) Received: from Q9J99.mgb01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for sip-security@ietf.org; Tue, 27 Nov 2001 16:09:10 +0100 Received: from g9jbr.mgb01.telekom.de by Q9J99.mgb01.telekom.de with ESMTP; Tue, 27 Nov 2001 16:08:58 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Nov 2001 16:08:48 +0100 Message-Id: From: "Beck01, Wolfgang" To: sip-security@ietf.org, jdrosen@dynamicsoft.com Subject: RE: [Sip-security] how many TCP connections can be handled? Date: Tue, 27 Nov 2001 16:08:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org > > > > Faster constructs like /dev/poll (Solaris, Linux), > kqueue()/ kevent() > > (BSD) or Mach's port sets are not commonly used at this time. jdrosen@dynamicsoft.com wrote: > > So what are the commercial web servers using? With http 1.1 > they will need to handle lots of concurrent connections. They do, but according to the SPECWeb99 pages it takes a lot of horse power to handle more than 1000 concurrent connections. Apache for example, forks a process for every connection. This is a portable, but not very scalable solution. The fastest web server was implemented as part of the kernel. Handling a large number of active TCP connections is a problem. If you have one thread per connection, programming is easy but you have the thread overhead in addition to the (negligible) TCB. If you have more than one connection per thread, programming becomes more difficult and your OS must provide better system calls than select() or poll(). I've done a small test program under FreeBSD: it accepts connections and creates threads for them (FreeBSD uthread). The thread starts the TLS (openssl) and exchanges 3 small (120 byte) messages. It closes the socket and waits some minutes before it exits. 'ps' before and after having connected 3000 sessions shows that each connection needs about 5 Kbyte. The load on the PIII 850Mhz is low as the TLS initial exchanges and the encrypted test messages are sent one after the other in my test. > > One source says that SSL reduces the [http] server capacity > > by 33 - 50 percent depending on the strength of encryption used > > in the connection. A different source talks about a reduction > > of 17 - 22 percent. jdrosen@dynamicsoft.com wrote: > > THis probably depends a lot on your assumption about churn in the > connections. With SIP, the SSL connections could be > long-lived, avoiding the > PKI overheads. Agreed. And with SIP, the connections will be much less busy than with http. The numbers I've quoted include the performance penalty introduced by any encrypting method, though. > > -Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > -- Wolfgang Beck T-Systems Nova GmbH _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security