From sip-security-admin@ietf.org Mon Oct 15 17:43:48 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 RAA12767 for ; Mon, 15 Oct 2001 17:43:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07604; Mon, 15 Oct 2001 17:41:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07573 for ; Mon, 15 Oct 2001 17:41:45 -0400 (EDT) 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 RAA12719 for ; Mon, 15 Oct 2001 17:41:42 -0400 (EDT) Received: from jariws1 ([62.248.239.226]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011015214143.WYW18920.fep01-app.kolumbus.fi@jariws1>; Tue, 16 Oct 2001 00:41:43 +0300 Message-ID: <00aa01c155c2$3cc2cba0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: , Date: Tue, 16 Oct 2001 00:42:07 +0300 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 Subject: [Sip-security] Security requirements from 3GPP 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, I just wanted to let this group also know that the 3GPP has produced a requirements document for SIP containing among other things security requirements. Main security issues are dealt with in the sections 6.22 (Security Model), 6.23 (Access Domain Security), and 6.24 (Network Domain Security). There are also a couple of other security related requirements on identities, network hiding etc elsewhere. I'm sure feedback on this document would be wellcome, both in terms of the requirements themselves, as well as possible ideas on how they can be fullfilled. This might also be a good opportunity to compare the various requirements documents, check inconsistencies and missed issues. And to propose solutions ;-) Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Mon Oct 15 17:50: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 RAA13113 for ; Mon, 15 Oct 2001 17:50:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07695; Mon, 15 Oct 2001 17:45:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07661 for ; Mon, 15 Oct 2001 17:45:49 -0400 (EDT) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12797 for ; Mon, 15 Oct 2001 17:45:46 -0400 (EDT) Received: from jariws1 ([62.248.239.226]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011015214548.KMBF1085.fep06-app.kolumbus.fi@jariws1>; Tue, 16 Oct 2001 00:45:48 +0300 Message-ID: <00c101c155c2$ce70cd40$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: , References: <00aa01c155c2$3cc2cba0$8a1b6e0a@arenanet.fi> Subject: Re: [Sip-security] Security requirements from 3GPP Date: Tue, 16 Oct 2001 00:46:11 +0300 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 And a pointer to the draft might also prove useful: http://search.ietf.org/internet-drafts/draft-garcia-sipping-3gpp-reqs-00.txt _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Wed Oct 17 10:46:01 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 KAA26344 for ; Wed, 17 Oct 2001 10:45:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26983; Wed, 17 Oct 2001 10:35:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26946 for ; Wed, 17 Oct 2001 10:35:01 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26121 for ; Wed, 17 Oct 2001 10:34:58 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9HEYsC06134 for ; Wed, 17 Oct 2001 16:34:54 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9HEYsL11162 for ; Wed, 17 Oct 2001 17:34:54 +0300 (EET DST) Message-ID: <3BCD970E.9853659D@lmf.ericsson.se> Date: Wed, 17 Oct 2001 17:34:54 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) 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] Proxy authentication in incoming INVITEs? 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, I've been looking at the use of HTTP authentication framework within SIP, and in particular its ability to authenticate a client to a proxy. Does this authentication work for incoming as well as outgoing INVITEs? In HTTP, proxy authentication allows a local proxy to ensure that only authenticated clients access the net through it. A one way client-server relationship exists in this situation. In contrast, SIP user agents act as servers when receiving an INVITE. Does the current bis draft/rfc 2617 allow authenticating the user agent to the proxy in this case? If yes, how? If not, why can't authentication be provided in a symmetric manner in this situation? Also, why does section 19.4 in the bis draft forbid proxies to add proxy-authorization? Doesn't this also prevent the user agent from requesting the proxy to authenticate itself, because even if the agent gave a 407, the proxy could not respond to it? Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Wed Oct 17 11:39: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 LAA27698 for ; Wed, 17 Oct 2001 11:39:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28855; Wed, 17 Oct 2001 11:33:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28826 for ; Wed, 17 Oct 2001 11:33:44 -0400 (EDT) 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 LAA27558 for ; Wed, 17 Oct 2001 11:33:42 -0400 (EDT) Received: from no.name.available by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 17 Oct 2001 15:33:46 UT Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 17 Oct 2001 16:34:58 +0100 From: "James Undery" To: "Jari Arkko" , Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? Date: Wed, 17 Oct 2001 16:34:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3BCD970E.9853659D@lmf.ericsson.se> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-OriginalArrivalTime: 17 Oct 2001 15:34:58.0134 (UTC) FILETIME=[47176F60:01C15721] 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, You've come across the problem I've recently noticed. The inclusion (in bis04) of Authentication-Info allows the server to authenticate itself to the client, similarly including the Proxy-Authentication-Info header (rfc2617 hidden in section 3.6) would allow the reverse. My only concern about this issue is that the server can't authenticate itself to the client except in a response to an authenticated request. This is because you can't be sure of the username until the client authenticates. While this sounds petty it prevents the sever from ensuring no step down attack can occur. HTH James > -----Original Message----- > From: sip-security-admin@ietf.org > [mailto:sip-security-admin@ietf.org]On > Behalf Of Jari Arkko > Hi, > > I've been looking at the use of HTTP authentication > framework within SIP, and in particular its ability > to authenticate a client to a proxy. Does this > authentication work for incoming as well as outgoing > INVITEs? > > In HTTP, proxy authentication allows a local proxy > to ensure that only authenticated clients access the > net through it. A one way client-server relationship > exists in this situation. > > In contrast, SIP user agents act as servers when receiving > an INVITE. Does the current bis draft/rfc 2617 allow > authenticating the user agent to the proxy in this case? > If yes, how? If not, why can't authentication be provided > in a symmetric manner in this situation? > > Also, why does section 19.4 in the bis draft forbid > proxies to add proxy-authorization? Doesn't this also > prevent the user agent from requesting the proxy to > authenticate itself, because even if the agent gave > a 407, the proxy could not respond to it? > > 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 sip-security-admin@ietf.org Thu Oct 18 07:20:19 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 HAA04197 for ; Thu, 18 Oct 2001 07:20:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04903; Thu, 18 Oct 2001 07:18:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04873 for ; Thu, 18 Oct 2001 07:18:47 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04181 for ; Thu, 18 Oct 2001 07:18:41 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9IBIfC18136; Thu, 18 Oct 2001 13:18:41 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9IBIeL10869; Thu, 18 Oct 2001 14:18:40 +0300 (EET DST) Message-ID: <3BCEBA90.B423D542@lmf.ericsson.se> Date: Thu, 18 Oct 2001 14:18:40 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: James Undery CC: sip-security@ietf.org Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? 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 James Undery wrote: > You've come across the problem I've recently noticed. The inclusion > (in bis04) of Authentication-Info allows the server to authenticate > itself to the client, similarly including the > Proxy-Authentication-Info header (rfc2617 hidden in section 3.6) would > allow the reverse. You mean "... would allow the proxy to do the same"? By the way, table 3 in bis-04 does not include the *-Authentication-info headers. Has someone made a bug report about this? (And where are by the way the current outstanding issue lists for the bis?) > My only concern about this issue is that the server can't authenticate > itself to the client except in a response to an authenticated request. > This is because you can't be sure of the username until the client > authenticates. While this sounds petty it prevents the sever from > ensuring no step down attack can occur. Yes, and this is OK. But I'm uncertain if your explanations above offer any solution to my original problem, i.e. the fact that we proxy authentication in SIP seems to work in one direction only, while the end-to-end authentication works in both directions? Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Thu Oct 18 07:34: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 HAA04523 for ; Thu, 18 Oct 2001 07:34:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05277; Thu, 18 Oct 2001 07:30:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05228 for ; Thu, 18 Oct 2001 07:30:21 -0400 (EDT) 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 HAA04401 for ; Thu, 18 Oct 2001 07:30:16 -0400 (EDT) Received: from no.name.available by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 18 Oct 2001 11:30:22 UT Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Thu, 18 Oct 2001 12:31:35 +0100 From: "James Undery" To: Cc: Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? Date: Thu, 18 Oct 2001 12:31:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3BCEBA90.B423D542@lmf.ericsson.se> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-OriginalArrivalTime: 18 Oct 2001 11:31:35.0924 (UTC) FILETIME=[71E8C340:01C157C8] 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 > -----Original Message----- > From: Jari.Arkko@lmf.ericsson.se [mailto:Jari.Arkko@lmf.ericsson.se] > James Undery wrote: > > > You've come across the problem I've recently noticed. The > inclusion > > (in bis04) of Authentication-Info allows the server to > authenticate > > itself to the client, similarly including the > > Proxy-Authentication-Info header (rfc2617 hidden in > section 3.6) would > > allow the reverse. > > You mean "... would allow the proxy to do the same"? Yes. > > By the way, table 3 in bis-04 does not include the > *-Authentication-info headers. Has someone made a > bug report about this? (And where are by the way the > current outstanding issue lists for the bis?) Yes, I've mentioned that Authentication-Info was missing from section 10, Jonathan noted it so I guess it'll be in bis05. I've not mentioned Proxy-Authentication-Info before. > > My only concern about this issue is that the server can't > authenticate > > itself to the client except in a response to an > authenticated request. > > This is because you can't be sure of the username until the client > > authenticates. While this sounds petty it prevents the sever from > > ensuring no step down attack can occur. > > Yes, and this is OK. > > But I'm uncertain if your explanations above offer any > solution to my original problem, i.e. the fact that we > proxy authentication in SIP seems to work in one > direction only, while the end-to-end authentication > works in both directions? Proxy-Authentication-Info should be included in responses to any requests that have been authenticated with Proxy-Authorization (at that proxy obviously) according to rfc2617. But Proxy-Authentication-Info has never been discussed on the SIP lists to my knowledge. James _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Thu Oct 18 08:05:27 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 IAA05246 for ; Thu, 18 Oct 2001 08:05:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06308; Thu, 18 Oct 2001 08:04:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06273 for ; Thu, 18 Oct 2001 08:04:35 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05218 for ; Thu, 18 Oct 2001 08:04:28 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9IC49C13798; Thu, 18 Oct 2001 14:04:10 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9IC48L12891; Thu, 18 Oct 2001 15:04:08 +0300 (EET DST) Message-ID: <3BCEC538.57BCEEC2@lmf.ericsson.se> Date: Thu, 18 Oct 2001 15:04:08 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: James Undery CC: sip-security@ietf.org Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? 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 James Undery wrote: > Proxy-Authentication-Info should be included in responses to any > requests that have been authenticated with Proxy-Authorization (at > that proxy obviously) according to rfc2617. But > Proxy-Authentication-Info has never been discussed on the SIP lists to > my knowledge. So, do you suggest the following: UA<---------------------INV---------------------Proxy UA--------407, P-Authenticate: challenge------->Proxy UA<-------INV, P-Authorization: response--------Proxy UA--------200 OK, P-Auth-Info: response-------->Proxy This scheme looks good, but it has two problems: 1) 19.4 in the bis draft requires passing the 407 upstream (which in this case would be somewhere beyond the proxy). Hence, the local proxy doesn't doesn't even think of answering. 2) 19.4 also forbids proxies to add Proxy-Authorization header, which prevents the proxy from answering even if knew it would have to. But perhaps I missed something and this wasn't what you were proposing? Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Thu Oct 18 08:54: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 IAA07191 for ; Thu, 18 Oct 2001 08:54:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07298; Thu, 18 Oct 2001 08:49:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07266 for ; Thu, 18 Oct 2001 08:49:11 -0400 (EDT) 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 IAA06952 for ; Thu, 18 Oct 2001 08:49:01 -0400 (EDT) Received: from no.name.available by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 18 Oct 2001 12:49:07 UT Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Thu, 18 Oct 2001 13:50:21 +0100 From: "James Undery" To: Cc: Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? Date: Thu, 18 Oct 2001 13:50:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3BCEC538.57BCEEC2@lmf.ericsson.se> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-OriginalArrivalTime: 18 Oct 2001 12:50:21.0747 (UTC) FILETIME=[72B82030:01C157D3] 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 Ah, now I see what you wanted, you want the UAS (callee) to be able to authenticate proxies, you are right this doesn't work. Only an Entity with server behaviour can mutually authenticate with the UAC in the current security model. A server can't authenticate (using SIP) with other non UAC entities. And the UAC can only add a Require header so that all servers must authenticate with it. The only HACK solution I can see is, if the INVITE was record routed, send a request (OPTIONS, COMET or whatever) back, in this case the callee gets to be the UAC and insert a suitable Require header. However, that is a really bad solution. James > -----Original Message----- > From: Jari.Arkko@lmf.ericsson.se [mailto:Jari.Arkko@lmf.ericsson.se] > James Undery wrote: > > > Proxy-Authentication-Info should be included in responses to any > > requests that have been authenticated with Proxy-Authorization (at > > that proxy obviously) according to rfc2617. But > > Proxy-Authentication-Info has never been discussed on the > SIP lists to > > my knowledge. > > So, do you suggest the following: > > UA<---------------------INV---------------------Proxy > UA--------407, P-Authenticate: challenge------->Proxy > UA<-------INV, P-Authorization: response--------Proxy > UA--------200 OK, P-Auth-Info: response-------->Proxy > > This scheme looks good, but it has two problems: > > 1) 19.4 in the bis draft requires passing the 407 upstream > (which in this case would be somewhere beyond the proxy). > Hence, the local proxy doesn't doesn't even think of > answering. > > 2) 19.4 also forbids proxies to add Proxy-Authorization > header, which prevents the proxy from answering > even if knew it would have to. > > But perhaps I missed something and this wasn't what > you were proposing? > > Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Thu Oct 18 09:08: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 JAA07787 for ; Thu, 18 Oct 2001 09:08:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07949; Thu, 18 Oct 2001 09:06:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07918 for ; Thu, 18 Oct 2001 09:06:11 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07684 for ; Thu, 18 Oct 2001 09:06:06 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9ID67C16761; Thu, 18 Oct 2001 15:06:08 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9ID67B15613; Thu, 18 Oct 2001 16:06:07 +0300 (EET DST) Message-ID: <3BCED3BF.5EC21FFA@lmf.ericsson.se> Date: Thu, 18 Oct 2001 16:06:07 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: James Undery CC: sip-security@ietf.org Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? 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 >Ah, now I see what you wanted, you want the UAS (callee) to be able to >authenticate proxies, you are right this doesn't work. This confirms my fear. Does anyone think we should do something about it? I can sort of see why we ended up in this based on the CSeq explanations in 19.4. However, I don't think the end-result is good. SIP doesn't have proxy authentication if it can only be done half of the time! Don't we have to do something about this in the Bis RFC? Any suggestions on how to fix this properly? Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Thu Oct 18 13:49: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 NAA16659 for ; Thu, 18 Oct 2001 13:48:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15982; Thu, 18 Oct 2001 13:47:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15951 for ; Thu, 18 Oct 2001 13:47:29 -0400 (EDT) Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16602 for ; Thu, 18 Oct 2001 13:47:24 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA27119; Thu, 18 Oct 2001 13:46:59 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id ASA27340; Thu, 18 Oct 2001 13:46:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20011018133946.00b205c8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Oct 2001 13:51:21 -0400 To: Jari Arkko From: Michael Hammer Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? Cc: James Undery , sip-security@ietf.org In-Reply-To: <3BCED3BF.5EC21FFA@lmf.ericsson.se> References: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" 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 Jari,

Is there a reason for doing proxy-authenticate half the time versus for the whole path?  What is the gain in that?  If for some reason you do not trust the N-proxy, what would stop it from being the N-1-proxy and go to an N-proxy you do trust?  If you assume the N-proxy will authenticate the N-1-proxy and follow that thought all the way, you end up with all proxies needing to authenticate.

Mike


At 04:06 PM 10/18/2001 +0300, Jari Arkko wrote:

>Ah, now I see what you wanted, you want the UAS (callee) to be able to
>authenticate proxies, you are right this doesn't work.

This confirms my fear. Does anyone think we should do
something about it?

I can sort of see why we ended up in this based on
the CSeq explanations in 19.4. However, I don't
think the end-result is good. SIP doesn't have
proxy authentication if it can only be done half
of the time! Don't we have to do something about
this in the Bis RFC?

Any suggestions on how to fix this properly?

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 sip-security-admin@ietf.org Thu Oct 18 17:03:51 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 RAA19764 for ; Thu, 18 Oct 2001 17:03:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23115; Thu, 18 Oct 2001 16:54:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23080 for ; Thu, 18 Oct 2001 16:54:21 -0400 (EDT) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19591 for ; Thu, 18 Oct 2001 16:54:14 -0400 (EDT) Received: from jariws1 ([62.248.238.156]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011018205418.NRGL15145.fep07-app.kolumbus.fi@jariws1>; Thu, 18 Oct 2001 23:54:18 +0300 Message-ID: <010401c15817$0ff39bc0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Jari Arkko" , "Michael Hammer" Cc: "James Undery" , References: <4.3.2.7.2.20011018133946.00b205c8@cia.cisco.com> Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? Date: Thu, 18 Oct 2001 23:54:21 +0300 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 >Is there a reason for doing proxy-authenticate half the time >versus for the whole path? What is the gain in that? If for >some reason you do not trust the N-proxy, what would >stop it from being the N-1-proxy and go to an N-proxy you >do trust? If you assume the N-proxy will authenticate the >N-1-proxy and follow that thought all the way, you end up >with all proxies needing to authenticate. Well, we could discuss proxies authenticating each other or clients authenticating to everyone on the path, but this wasn't really why I brought this issue up. (That issue propably deserves its own thread here.) The fact of the matter is that SIP *does* allow user agents to authenticate with the local proxy, but for some reason seems to implement this *partially*, i.e. only for outgoing calls and not incoming. I think there's good reasons to have authentication in local proxies regardless of what happens after the proxy, but I'd like to have the full functionality. Especially when all this worked for HTTP, including the situation of having both a server and client on your machine! Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Thu Oct 18 19:59:19 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 TAA21605 for ; Thu, 18 Oct 2001 19:59:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28147; Thu, 18 Oct 2001 19:55:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28114 for ; Thu, 18 Oct 2001 19:55:30 -0400 (EDT) Received: from agni.research.nokia.com ([213.28.243.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21582 for ; Thu, 18 Oct 2001 19:55:24 -0400 (EDT) Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.2/8.11.2) id f9IFqRl14266; Thu, 18 Oct 2001 18:52:27 +0300 To: Jari Arkko Cc: James Undery , Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? References: <3BCED3BF.5EC21FFA@lmf.ericsson.se> X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: Jari Arkko's message of "Thu, 18 Oct 2001 16:06:07 +0300" Date: 18 Oct 2001 18:52:27 +0300 Message-ID: Lines: 14 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 In message <3BCED3BF.5EC21FFA@lmf.ericsson.se> Jari Arkko writes: >I can sort of see why we ended up in this based on >the CSeq explanations in 19.4. However, I don't >think the end-result is good. SIP doesn't have >proxy authentication if it can only be done half >of the time! Don't we have to do something about >this in the Bis RFC? >Any suggestions on how to fix this properly? Require the proxy to use different branch value for resubmitted request? Pekka _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Fri Oct 19 04:11: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 EAA12291 for ; Fri, 19 Oct 2001 04:11:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16129; Fri, 19 Oct 2001 04:04:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16096 for ; Fri, 19 Oct 2001 04:04:30 -0400 (EDT) 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 EAA12265 for ; Fri, 19 Oct 2001 04:04:27 -0400 (EDT) Received: from no.name.available by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Oct 2001 08:04:31 UT Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 19 Oct 2001 09:05:47 +0100 From: "James Undery" To: "Pekka Pessi" , "Jari Arkko" Cc: Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? Date: Fri, 19 Oct 2001 09:05:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 19 Oct 2001 08:05:47.0903 (UTC) FILETIME=[DC5408F0:01C15874] 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 > -----Original Message----- > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > In message <3BCED3BF.5EC21FFA@lmf.ericsson.se> Jari Arkko > writes: > >I can sort of see why we ended up in this based on > >the CSeq explanations in 19.4. However, I don't > >think the end-result is good. SIP doesn't have > >proxy authentication if it can only be done half > >of the time! Don't we have to do something about > >this in the Bis RFC? > > >Any suggestions on how to fix this properly? > > Require the proxy to use different branch value for > resubmitted > request? That isn't going to help, it'll just look like a retransmission James _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Fri Oct 19 05:42:45 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 FAA13117 for ; Fri, 19 Oct 2001 05:42:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18734; Fri, 19 Oct 2001 05:39:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18703 for ; Fri, 19 Oct 2001 05:39:41 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13090 for ; Fri, 19 Oct 2001 05:39:37 -0400 (EDT) Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9J9eFf25835 for ; Fri, 19 Oct 2001 12:40:15 +0300 (EET DST) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Oct 2001 12:39:38 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id 40AXLCD3; Fri, 19 Oct 2001 12:39:38 +0300 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id MAA08373; Fri, 19 Oct 2001 12:39:37 +0300 (EETDST) Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.2/8.11.2) id f9J9gMo01308; Fri, 19 Oct 2001 12:42:22 +0300 To: James Undery Cc: Pekka Pessi , "Jari Arkko" , Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? References: X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: James Undery's message of "Fri, 19 Oct 2001 11:05:49 +0300" Date: 19 Oct 2001 12:42:22 +0300 Message-ID: Lines: 16 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 In message James Undery writes: >That isn't going to help, it'll just look like a retransmission No, changing the topmost Via is enough. Pekka ---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)--- Isomorphic request or response: Two requests or responses are defined to be isomorphic for the purposes of this document if they have the same values for the Call-ID, To, From and CSeq header fields. In addition, isomorphic requests have to have the same Request-URI and the same top-most Via header. ---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)--- _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Fri Oct 19 06:04:19 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 GAA13301 for ; Fri, 19 Oct 2001 06:04:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19366; Fri, 19 Oct 2001 06:00:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19331 for ; Fri, 19 Oct 2001 06:00:30 -0400 (EDT) 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 GAA13276 for ; Fri, 19 Oct 2001 06:00:26 -0400 (EDT) Received: from no.name.available by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Oct 2001 10:00:31 UT Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 19 Oct 2001 11:01:48 +0100 From: "James Undery" To: "Pekka Pessi" Cc: "Jari Arkko" , Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? Date: Fri, 19 Oct 2001 11:01:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 19 Oct 2001 10:01:48.0516 (UTC) FILETIME=[112D4A40:01C15885] 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 > -----Original Message----- > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > Sent: 19 October 2001 10:42 > To: James Undery > Cc: Pekka Pessi; Jari Arkko; sip-security@ietf.org > Subject: Re: [Sip-security] Proxy authentication in > incoming INVITEs? > > > In message > James > Undery writes: > >That isn't going to help, it'll just look like a retransmission > > No, changing the topmost Via is enough. And how pray tell are you going to change the topmost via in all cases > ---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)---(bis04) > ---(bis04)--- > Isomorphic request or response: Two requests or > responses are > defined to be isomorphic for the purposes of > this document > if they have the same values for the Call-ID, > To, From and > CSeq header fields. In addition, isomorphic > requests have > to have the same Request-URI and the same top-most Via > header. > ---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)---(bis04) > ---(bis04)--- > _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Fri Oct 19 11:13:57 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 LAA21168 for ; Fri, 19 Oct 2001 11:13:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28246; Fri, 19 Oct 2001 11:12:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28207 for ; Fri, 19 Oct 2001 11:12:40 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21131 for ; Fri, 19 Oct 2001 11:12:37 -0400 (EDT) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f9JFIFD13922; Fri, 19 Oct 2001 10:18:16 -0500 Message-ID: <005701c158b0$71c24510$7d7075d5@flak> From: "Dean Willis" To: "Jari Arkko" , "Pekka Pessi" Cc: "James Undery" , References: <3BCED3BF.5EC21FFA@lmf.ericsson.se> Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? Date: Fri, 19 Oct 2001 10:12:13 -0500 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Huh? SIP doesn't authenticate proxies. SIP Proxies authenticate clients making use of those proxies. If you want UAs to be able to authenticate every proxy that has processed a message, you'll need to do something like using a PKI to have each proxy sign the message and attach a signed copy of the message to the body of the outgoing message. Checking the authentications requires processing the signature chain in reverse order. It's pretty seriously tedious, and consumes vast amounts of signaling bandwidth, not to mention CPU. Of course, one could implement TLS with bidirectional certification. That would essentisally authenticate edge proxies. -- Dean ----- Original Message ----- From: "Pekka Pessi" To: "Jari Arkko" Cc: "James Undery" ; Sent: Thursday, October 18, 2001 10:52 AM Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? > In message <3BCED3BF.5EC21FFA@lmf.ericsson.se> Jari Arkko writes: > >I can sort of see why we ended up in this based on > >the CSeq explanations in 19.4. However, I don't > >think the end-result is good. SIP doesn't have > >proxy authentication if it can only be done half > >of the time! Don't we have to do something about > >this in the Bis RFC? > > >Any suggestions on how to fix this properly? > > Require the proxy to use different branch value for resubmitted > request? > > Pekka > > _______________________________________________ > 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 sip-security-admin@ietf.org Fri Oct 19 11:44:21 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 LAA21779 for ; Fri, 19 Oct 2001 11:44:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28856; Fri, 19 Oct 2001 11:36:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28823 for ; Fri, 19 Oct 2001 11:36:55 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21705 for ; Fri, 19 Oct 2001 11:36:49 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9JFOlj10570; Fri, 19 Oct 2001 17:24:47 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9JFOlB23880; Fri, 19 Oct 2001 18:24:47 +0300 (EET DST) Message-ID: <3BD045BF.E55CF5B9@lmf.ericsson.se> Date: Fri, 19 Oct 2001 18:24:47 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: Pekka Pessi , James Undery , sip-security@ietf.org Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? References: <3BCED3BF.5EC21FFA@lmf.ericsson.se> <005701c158b0$71c24510$7d7075d5@flak> 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 Dean Willis wrote: > SIP Proxies authenticate clients > making use of those proxies. Yes... and this has to be interpreted very literally. If you have a local proxy and a user agent, you can authenticate half of what the user agent does, namely the user agent client part, but not the user agent server part. > If you want UAs to be able to authenticate every proxy that has processed a > message, you'll need to do something like using a PKI to have each proxy > sign the message and attach a signed copy of the message to the body of the > outgoing message. Checking the authentications requires processing the > signature chain in reverse order. It's pretty seriously tedious, and > consumes vast amounts of signaling bandwidth, not to mention CPU. I don't think anyone is proposing authenticating every proxy. Just the whole user agent to the local proxy. >Of course, one could implement TLS with bidirectional certification. That >would essentisally authenticate edge proxies. This would work, if you can pay for it... seems a bit strange that one has to upgrade to PKIs, TCP, public key cryptography, etc. because an otherwise suitable scheme only works in one direction. But I do appreciate the problems outlined in 19.4. Are there any other possible solutions than TLS? Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Fri Oct 19 12:16:56 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 MAA22539 for ; Fri, 19 Oct 2001 12:16:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00405; Fri, 19 Oct 2001 12:10:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00372 for ; Fri, 19 Oct 2001 12:10:34 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22336 for ; Fri, 19 Oct 2001 12:10:30 -0400 (EDT) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f9JGGBD14107; Fri, 19 Oct 2001 11:16:11 -0500 Message-ID: <008f01c158b8$87a09780$7d7075d5@flak> From: "Dean Willis" To: "Jari Arkko" Cc: "Pekka Pessi" , "James Undery" , References: <3BCED3BF.5EC21FFA@lmf.ericsson.se> <005701c158b0$71c24510$7d7075d5@flak> <3BD045BF.E55CF5B9@lmf.ericsson.se> Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? Date: Fri, 19 Oct 2001 11:10:07 -0500 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Ah, Perhaps I was being dense. I've just reread the entire thread. Perhaps further analysis of the requirement would help. Do we wish to authenticate the identity of the system that is acting as a UAS, or authenticate the identity of the human operating that system? What is the persistency of the relationship between the proxy and the UAS? Will the UAS need to know how to authenticate to many proxies? What level of security is required? Do we need to protect against playback, or does the call signature (to:, From:, Call-ID) provide sufficient uniqueness on its own? Several possible candidates might include TLS (already discussed, just issue a client cert signed by a CAS trusted by the proxy) IPSEC (key management base problem for IKE) HIP SSH Kerberos (it has to be said) Use of remote-party-ID extended with some sort of cryptographic signature of the response -- shared secret key -- PGP -- PKI cert -- kerberos key exchange Personally, I'm leaning toward the latter. This would have interesting interaction with the goals of the DCS Privacy draft. -- Dean ----- Original Message ----- From: "Jari Arkko" To: "Dean Willis" Cc: "Pekka Pessi" ; "James Undery" ; Sent: Friday, October 19, 2001 10:24 AM Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? > Dean Willis wrote: > > > SIP Proxies authenticate clients > > making use of those proxies. > > Yes... and this has to be interpreted very literally. > If you have a local proxy and a user agent, you can > authenticate half of what the user agent does, namely > the user agent client part, but not the user agent > server part. > > > If you want UAs to be able to authenticate every proxy that has processed a > > message, you'll need to do something like using a PKI to have each proxy > > sign the message and attach a signed copy of the message to the body of the > > outgoing message. Checking the authentications requires processing the > > signature chain in reverse order. It's pretty seriously tedious, and > > consumes vast amounts of signaling bandwidth, not to mention CPU. > > I don't think anyone is proposing authenticating every proxy. > Just the whole user agent to the local proxy. > > >Of course, one could implement TLS with bidirectional certification. That > >would essentisally authenticate edge proxies. > > This would work, if you can pay for it... seems a bit strange > that one has to upgrade to PKIs, TCP, public key cryptography, > etc. because an otherwise suitable scheme only works in one > direction. > > But I do appreciate the problems outlined in 19.4. Are > there any other possible solutions than TLS? > > 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 sip-security-admin@ietf.org Fri Oct 19 13:57:07 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 NAA26021 for ; Fri, 19 Oct 2001 13:57:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02905; Fri, 19 Oct 2001 13:44:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02870 for ; Fri, 19 Oct 2001 13:44:17 -0400 (EDT) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25694 for ; Fri, 19 Oct 2001 13:44:09 -0400 (EDT) Received: from jariws1 ([62.248.238.156]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011019174354.BDIG5453.fep07-app.kolumbus.fi@jariws1>; Fri, 19 Oct 2001 20:43:54 +0300 Message-ID: <004401c158c5$a1b6d500$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Dean Willis" , "Jari Arkko" Cc: "Pekka Pessi" , "James Undery" , References: <3BCED3BF.5EC21FFA@lmf.ericsson.se> <005701c158b0$71c24510$7d7075d5@flak> <3BD045BF.E55CF5B9@lmf.ericsson.se> <008f01c158b8$87a09780$7d7075d5@flak> Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? Date: Fri, 19 Oct 2001 20:43:58 +0300 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 > Perhaps further analysis of the requirement would help. Yes. Two cases: 1) I started this thread in order to discuss something which at first look seemed more like a bug than a feature in current SIP. HTTP authentication in SIP is propably going to stay, so if possible it might make sense to try to make it work like, uh, HTTP authentication which does allow what I originally assumed SIP would allow. But this is mainly for the purpose of keeping the specs symmetric and to give the right impression to folks who use SIP. I don't have major requirements in this case, though it is possible that if this problem was fixed then HTTP authentication in SIP would be applicable in some cases that it currently isn't. 2) Since we jumped into the discussion of the security architecture and its requirements, we might as well start the discussions based on the one published set of requirements: Miguel Garcia's draft on 3g requirements to SIP [1]. This includes security in chapters 6.22-6.24. Here, I care much more than in point 1! > Do we wish to authenticate the identity of the system that is acting as a > UAS, or authenticate the identity of the human operating that system? What Usually the human. (I'm not sure though it makes much of a difference protocol wise, username/passwords for instance could be given to the device or prompted from the user. More fine-grained systems such as smart cards allow users to 'open' the security with a PIN for a period, from there on the device can act from the behalf of the user.) > is the persistency of the relationship between the proxy and the UAS? Will For 3g, authentication is towards the home environment, and there's a contractual business relationship between the UA owner and the home environment. (There are proxies in between.) > the UAS need to know how to authenticate to many proxies? Yes, at least in the sense of load-sharing and fault-tolerance, though not necessarily in terms of authenticating to a bunch of unknown proxies somewhere else. > What level of > security is required? Do we need to protect against playback, or does the > call signature (to:, From:, Call-ID) provide sufficient uniqueness on its > own? Authentication as such is useful, but not sufficient. It will also be necessary to protect the actual messages somehow (which is another drawback of HTTP authentication, though there's some work in progress fixing this). I think integrity protection is a MUST, while confidentiality may be a SHOULD or a MAY. I believe replay protection is necessary. If service providers want to bill for their service, it would be bad for users if anyone could replay their sessions/calls. I suspect call signature might be useful here, but the thought of storing a huge amount of these triplets might be troublesome. Could be better to nonces, sequence numbers etc. that require only the storage of the last state. Oh yes, and I should mention all this should be ready and defined in the March IETF... Jari [1] http://search.ietf.org/internet-drafts/draft-garcia-sipping-3gpp-reqs-00.txt _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Mon Oct 22 17:15: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 RAA29935 for ; Mon, 22 Oct 2001 17:15:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06968; Mon, 22 Oct 2001 17:07:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06932 for ; Mon, 22 Oct 2001 17:07:12 -0400 (EDT) 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 RAA29851 for ; Mon, 22 Oct 2001 17:07:09 -0400 (EDT) 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 QAA20727 for ; Mon, 22 Oct 2001 16:06:26 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 22 Oct 2001 15:59:33 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Oct 2001 16:05:39 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F258@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'dean.willis@softarmor.com'" , "'sip-security@ietf.org'" Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? Date: Mon, 22 Oct 2001 16:05:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15B3D.4ADC9FB0" 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_01C15B3D.4ADC9FB0 Content-Type: text/plain; charset="iso-8859-1" Dean, I like the option of using extended Remote-party-id header for transfering the credential. How about the option of using the Cookie header for the same purpose? Sanjoy ====================== To: "Jari Arkko" Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? From: "Dean Willis" Date: Fri, 19 Oct 2001 11:10:07 -0500 Cc: "Pekka Pessi" , "James Undery" , List-Id: Security Issues for the SIP protocol References: <3BCED3BF.5EC21FFA@lmf.ericsson.se> <005701c158b0$71c24510$7d7075d5@flak> <3BD045BF.E55CF5B9@lmf.ericsson.se> Sender: sip-security-admin@ietf.org ---------------------------------------------------------------------------- ---- Ah, Perhaps I was being dense. I've just reread the entire thread. Perhaps further analysis of the requirement would help. Do we wish to authenticate the identity of the system that is acting as a UAS, or authenticate the identity of the human operating that system? What is the persistency of the relationship between the proxy and the UAS? Will the UAS need to know how to authenticate to many proxies? What level of security is required? Do we need to protect against playback, or does the call signature (to:, From:, Call-ID) provide sufficient uniqueness on its own? Several possible candidates might include TLS (already discussed, just issue a client cert signed by a CAS trusted by the proxy) IPSEC (key management base problem for IKE) HIP SSH Kerberos (it has to be said) Use of remote-party-ID extended with some sort of cryptographic signature of the response -- shared secret key -- PGP -- PKI cert -- kerberos key exchange Personally, I'm leaning toward the latter. This would have interesting interaction with the goals of the DCS Privacy draft. -- Dean ----- Original Message ----- From: "Jari Arkko" To: "Dean Willis" Cc: "Pekka Pessi" ; "James Undery" ; Sent: Friday, October 19, 2001 10:24 AM Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? > Dean Willis wrote: > > > SIP Proxies authenticate clients > > making use of those proxies. > > Yes... and this has to be interpreted very literally. > If you have a local proxy and a user agent, you can > authenticate half of what the user agent does, namely > the user agent client part, but not the user agent > server part. > > > If you want UAs to be able to authenticate every proxy that has processed a > > message, you'll need to do something like using a PKI to have each proxy > > sign the message and attach a signed copy of the message to the body of the > > outgoing message. Checking the authentications requires processing the > > signature chain in reverse order. It's pretty seriously tedious, and > > consumes vast amounts of signaling bandwidth, not to mention CPU. > > I don't think anyone is proposing authenticating every proxy. > Just the whole user agent to the local proxy. > > >Of course, one could implement TLS with bidirectional certification. That > >would essentisally authenticate edge proxies. > > This would work, if you can pay for it... seems a bit strange > that one has to upgrade to PKIs, TCP, public key cryptography, > etc. because an otherwise suitable scheme only works in one > direction. > > But I do appreciate the problems outlined in 19.4. Are > there any other possible solutions than TLS? > > 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 ------_=_NextPart_001_01C15B3D.4ADC9FB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip-security] Proxy authentication in incoming INVITEs? =

Dean,

   I like the option of using extended = Remote-party-id header for transfering the credential. How about the = option of using the Cookie header for the same purpose?

Sanjoy


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

To: "Jari Arkko" = <Jari.Arkko@lmf.ericsson.se>
Subject: Re: [Sip-security] Proxy authentication in = incoming INVITEs?
From: "Dean Willis" = <dean.willis@softarmor.com>
Date: Fri, 19 Oct 2001 11:10:07 -0500
Cc: "Pekka Pessi" = <Pekka.Pessi@nokia.com>, "James Undery" = <jundery@ubiquity.net>, <sip-security@ietf.org>
List-Id: Security Issues for the SIP protocol = <sip-security.ietf.org>
References: = <3BCED3BF.5EC21FFA@lmf.ericsson.se> = <pvg08hoshw.fsf@agni.research.nokia.com> = <005701c158b0$71c24510$7d7075d5@flak> = <3BD045BF.E55CF5B9@lmf.ericsson.se>

Sender: sip-security-admin@ietf.org

---------------------------------------------------------------= -----------------

Ah, Perhaps I was being dense. I've just reread the = entire thread.

Perhaps further analysis of the requirement would = help.

Do we wish to authenticate the identity of the system = that is acting as a
UAS, or authenticate the identity of the human = operating that system? What
is the persistency of the relationship between the = proxy and the UAS? Will
the UAS need to know how to authenticate to many = proxies? What level of
security is required? Do we need to protect against = playback, or does the
call signature (to:, From:, Call-ID) provide = sufficient uniqueness on its
own?


Several possible candidates might include

TLS (already discussed, just issue a client cert = signed by a CAS trusted by
the proxy)
IPSEC (key management base problem for IKE)
HIP
SSH
Kerberos (it has to be said)
Use of remote-party-ID extended with some sort of = cryptographic signature of
the response
-- shared secret key
-- PGP
-- PKI cert
--  kerberos key exchange

Personally, I'm leaning toward the latter. This would = have interesting
interaction with the goals of the DCS Privacy = draft.

--
Dean

----- Original Message -----
From: "Jari Arkko" = <Jari.Arkko@lmf.ericsson.se>
To: "Dean Willis" = <dean.willis@softarmor.com>
Cc: "Pekka Pessi" = <Pekka.Pessi@nokia.com>; "James Undery"
<jundery@ubiquity.net>; = <sip-security@ietf.org>
Sent: Friday, October 19, 2001 10:24 AM
Subject: Re: [Sip-security] Proxy authentication in = incoming INVITEs?


> Dean Willis wrote:
>
> > SIP Proxies authenticate clients
> > making use of those proxies.
>
> Yes... and this has to be interpreted very = literally.
> If you have a local proxy and a user agent, you = can
> authenticate half of what the user agent does, = namely
> the user agent client part, but not the user = agent
> server part.
>
> > If you want UAs to be able to authenticate = every proxy that has
processed a
> > message, you'll need to do something like = using a PKI to have each proxy
> > sign the message and attach a signed copy = of the message to the body of
the
> > outgoing message. Checking the = authentications requires processing the
> > signature chain in reverse order. It's = pretty seriously tedious, and
> > consumes vast amounts of signaling = bandwidth, not to mention CPU.
>
> I don't think anyone is proposing = authenticating every proxy.
> Just the whole user agent to the local = proxy.
>
> >Of course, one could implement TLS with = bidirectional certification. That
> >would essentisally authenticate edge = proxies.
>
> This would work, if you can pay for it... seems = a bit strange
> that one has to upgrade to PKIs, TCP, public = key cryptography,
> etc. because an otherwise suitable scheme only = works in one
> direction.
>
> But I do appreciate the problems outlined in = 19.4. Are
> there any other possible solutions than = TLS?
>
> 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=

------_=_NextPart_001_01C15B3D.4ADC9FB0-- _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Mon Oct 22 17:16:10 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 RAA29947 for ; Mon, 22 Oct 2001 17:16:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07064; Mon, 22 Oct 2001 17:12:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07033 for ; Mon, 22 Oct 2001 17:12:06 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29883 for ; Mon, 22 Oct 2001 17:12:00 -0400 (EDT) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f9MLHmD25245; Mon, 22 Oct 2001 16:17:48 -0500 Message-ID: <001901c15b3e$281c2e40$892e713f@flak> From: "Dean Willis" To: "Sanjoy Sen" , References: <933FADF5E673D411B8A30002A5608A0E06F258@zrc2c012.us.nortel.com> Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? Date: Mon, 22 Oct 2001 16:11:44 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C15B14.3E2E9BC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 is a multi-part message in MIME format. ------=_NextPart_000_0016_01C15B14.3E2E9BC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip-security] Proxy authentication in incoming INVITEs? That might work, but it would take some thinking. One of the issues is = that the credential set needs to include something like a a serial = number or a hash of the message it is in, or it is subject to replay = attacks. The cookie draft is mostly intended to force "replays" of = certain information, so this could be problematic for use in credential = transfer. I suppose one could have something like an "adaptive cookie" that is = modified by the UA, but this is sort of antithetical to the original = cookie concept. -- Dean ----- Original Message -----=20 From: Sanjoy Sen=20 To: 'dean.willis@softarmor.com' ; 'sip-security@ietf.org'=20 Sent: Monday, October 22, 2001 4:05 PM Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? Dean,=20 I like the option of using extended Remote-party-id header for = transfering the credential. How about the option of using the Cookie = header for the same purpose?=20 Sanjoy=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 To: "Jari Arkko" =20 Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs?=20 From: "Dean Willis" =20 Date: Fri, 19 Oct 2001 11:10:07 -0500=20 Cc: "Pekka Pessi" , "James Undery" = , =20 List-Id: Security Issues for the SIP protocol =20 References: <3BCED3BF.5EC21FFA@lmf.ericsson.se> = = <005701c158b0$71c24510$7d7075d5@flak> = <3BD045BF.E55CF5B9@lmf.ericsson.se>=20 Sender: sip-security-admin@ietf.org=20 = -------------------------------------------------------------------------= -------=20 Ah, Perhaps I was being dense. I've just reread the entire thread.=20 Perhaps further analysis of the requirement would help.=20 Do we wish to authenticate the identity of the system that is acting = as a=20 UAS, or authenticate the identity of the human operating that system? = What=20 is the persistency of the relationship between the proxy and the UAS? = Will=20 the UAS need to know how to authenticate to many proxies? What level = of=20 security is required? Do we need to protect against playback, or does = the=20 call signature (to:, From:, Call-ID) provide sufficient uniqueness on = its=20 own?=20 Several possible candidates might include=20 TLS (already discussed, just issue a client cert signed by a CAS = trusted by=20 the proxy)=20 IPSEC (key management base problem for IKE)=20 HIP=20 SSH=20 Kerberos (it has to be said)=20 Use of remote-party-ID extended with some sort of cryptographic = signature of=20 the response=20 -- shared secret key=20 -- PGP=20 -- PKI cert=20 -- kerberos key exchange=20 Personally, I'm leaning toward the latter. This would have interesting = interaction with the goals of the DCS Privacy draft.=20 --=20 Dean=20 ----- Original Message -----=20 From: "Jari Arkko" =20 To: "Dean Willis" =20 Cc: "Pekka Pessi" ; "James Undery"=20 ; =20 Sent: Friday, October 19, 2001 10:24 AM=20 Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs?=20 > Dean Willis wrote:=20 >=20 > > SIP Proxies authenticate clients=20 > > making use of those proxies.=20 >=20 > Yes... and this has to be interpreted very literally.=20 > If you have a local proxy and a user agent, you can=20 > authenticate half of what the user agent does, namely=20 > the user agent client part, but not the user agent=20 > server part.=20 >=20 > > If you want UAs to be able to authenticate every proxy that has=20 processed a=20 > > message, you'll need to do something like using a PKI to have each = proxy=20 > > sign the message and attach a signed copy of the message to the = body of=20 the=20 > > outgoing message. Checking the authentications requires processing = the=20 > > signature chain in reverse order. It's pretty seriously tedious, = and=20 > > consumes vast amounts of signaling bandwidth, not to mention CPU.=20 >=20 > I don't think anyone is proposing authenticating every proxy.=20 > Just the whole user agent to the local proxy.=20 >=20 > >Of course, one could implement TLS with bidirectional = certification. That=20 > >would essentisally authenticate edge proxies.=20 >=20 > This would work, if you can pay for it... seems a bit strange=20 > that one has to upgrade to PKIs, TCP, public key cryptography,=20 > etc. because an otherwise suitable scheme only works in one=20 > direction.=20 >=20 > But I do appreciate the problems outlined in 19.4. Are=20 > there any other possible solutions than TLS?=20 >=20 > Jari=20 >=20 > _______________________________________________=20 > Sip-security mailing list=20 > Sip-security@ietf.org=20 > http://www1.ietf.org/mailman/listinfo/sip-security=20 >=20 >=20 _______________________________________________=20 Sip-security mailing list=20 Sip-security@ietf.org=20 http://www1.ietf.org/mailman/listinfo/sip-security=20 ------=_NextPart_000_0016_01C15B14.3E2E9BC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip-security] Proxy authentication in incoming = INVITEs?
 
That might work, but it would take some = thinking.=20 One of the issues is that the credential set needs to include something = like a a=20 serial number or a hash of the message it is in, or it is subject to = replay=20 attacks. The cookie draft is mostly intended to force "replays" of = certain=20 information, so this could be problematic for use in credential=20 transfer.
 
I suppose one could have something like = an=20 "adaptive cookie" that is modified by the UA, but this is sort of = antithetical=20 to the original cookie concept.
 
--
Dean
----- Original Message -----
From:=20 Sanjoy Sen
Sent: Monday, October 22, 2001 = 4:05=20 PM
Subject: Re: [Sip-security] = Proxy=20 authentication in incoming INVITEs?

Dean,

   I like the option of using extended=20 Remote-party-id header for transfering the credential. How about the = option of=20 using the Cookie header for the same purpose?

Sanjoy


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

To: "Jari Arkko" <Jari.Arkko@lmf.ericsson.se= >=20
Subject: Re: [Sip-security] Proxy = authentication in=20 incoming INVITEs?
From: "Dean Willis" <dean.willis@softarmor.com&g= t;=20
Date: Fri, 19 Oct 2001 11:10:07 -0500 =
Cc: "Pekka Pessi" <Pekka.Pessi@nokia.com>, "James = Undery"=20 <jundery@ubiquity.net>, <sip-security@ietf.org> =
List-Id: Security Issues for the SIP protocol=20 <sip-security.ietf.org>
References:=20 <3BCED3BF.5EC21FFA@lmf.ericsson.se>=20 <pvg08hoshw.fsf@agni.research.nokia.com>=20 <005701c158b0$71c24510$7d7075d5@flak>=20 <3BD045BF.E55CF5B9@lmf.ericsson.se>

Sender: sip-security-admin@ietf.org

----------------------------------------------------------------= ----------------=20

Ah, Perhaps I was being dense. I've just reread the = entire=20 thread.

Perhaps further analysis of the requirement would = help.=20

Do we wish to authenticate the identity of the = system that is=20 acting as a
UAS, or authenticate the = identity of the=20 human operating that system? What
is the = persistency=20 of the relationship between the proxy and the UAS? Will =
the UAS need to know how to authenticate to many proxies? = What level=20 of
security is required? Do we need to = protect against=20 playback, or does the
call signature (to:, = From:,=20 Call-ID) provide sufficient uniqueness on its
own?


Several possible candidates might include =

TLS (already discussed, just issue a client cert = signed by a=20 CAS trusted by
the proxy)
IPSEC (key management base problem for IKE)
HIP
SSH
Kerberos (it=20 has to be said)
Use of remote-party-ID = extended with=20 some sort of cryptographic signature of
the=20 response
-- shared secret key =
-- PGP
-- PKI cert
--  kerberos key exchange

Personally, I'm leaning toward the latter. This = would have=20 interesting
interaction with the goals of = the DCS=20 Privacy draft.

--
Dean

----- Original Message -----
From:=20 "Jari Arkko" <Jari.Arkko@lmf.ericsson.se>
To:=20 "Dean Willis" <dean.willis@softarmor.com>
Cc:=20 "Pekka Pessi" <Pekka.Pessi@nokia.com>; "James Undery" =
<jundery@ubiquity.net>; = <sip-security@ietf.org>=20
Sent: Friday, October 19, 2001 10:24 AM =
Subject: Re: [Sip-security] Proxy authentication in incoming=20 INVITEs?


> Dean Willis wrote:
>=20
> > SIP Proxies authenticate clients =
> > making use of those proxies.
>
> Yes... and this has to be = interpreted=20 very literally.
> If you have a local = proxy and a=20 user agent, you can
> authenticate half = of what the=20 user agent does, namely
> the user agent = client=20 part, but not the user agent
> server = part.=20
>
> > If you = want UAs to be=20 able to authenticate every proxy that has
processed=20 a
> > message, you'll need to do = something like=20 using a PKI to have each proxy
> > = sign the=20 message and attach a signed copy of the message to the body of=20
the
> > outgoing = message.=20 Checking the authentications requires processing the
> > signature chain in reverse order. It's pretty = seriously=20 tedious, and
> > consumes vast amounts = of=20 signaling bandwidth, not to mention CPU.
>=20
> I don't think anyone is proposing = authenticating every=20 proxy.
> Just the whole user agent to the = local=20 proxy.
>
> = >Of=20 course, one could implement TLS with bidirectional certification. = That=20
> >would essentisally authenticate edge = proxies.=20
>
> This would = work, if you can=20 pay for it... seems a bit strange
> that = one has to=20 upgrade to PKIs, TCP, public key cryptography,
>=20 etc. because an otherwise suitable scheme only works in one =
> direction.
> =
> But I do appreciate the problems outlined in 19.4. = Are=20
> there any other possible solutions than = TLS?=20
>
> Jari =
>
>=20 _______________________________________________
>=20 Sip-security mailing list
>=20 Sip-security@ietf.org
> http://www1.ietf.org/mailman/listinfo/sip-security=20
>
>


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

------=_NextPart_000_0016_01C15B14.3E2E9BC0-- _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Mon Oct 22 18:24: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 SAA00906 for ; Mon, 22 Oct 2001 18:24:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08890; Mon, 22 Oct 2001 18:17:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08820 for ; Mon, 22 Oct 2001 18:17:50 -0400 (EDT) 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 SAA00848 for ; Mon, 22 Oct 2001 18:17:46 -0400 (EDT) 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 RAA08288 for ; Mon, 22 Oct 2001 17:17:20 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 22 Oct 2001 17:15:18 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Oct 2001 17:16:27 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F259@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Dean Willis'" , sip-security Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? Date: Mon, 22 Oct 2001 17:16:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15B47.2FD37F40" 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_01C15B47.2FD37F40 Content-Type: text/plain; charset="iso-8859-1" I was hoping that the UA and the Proxy are in the participatory mode (as defined in draft-willis-sip-cookies-00.txt) and are able to modify the cookie to a certain extent (am I correct in assuming this?). The Cookie header will contain the credential generated (by the Proxy) using the already existing security state association between the UA and the Proxy & will be added by the Proxy to all incoming Requests to the UA (after the security association has been established). Thoughts? Sanjoy -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Monday, October 22, 2001 4:12 PM To: Sen, Sanjoy [NGB:B602:EXCH]; sip-security Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? That might work, but it would take some thinking. One of the issues is that the credential set needs to include something like a a serial number or a hash of the message it is in, or it is subject to replay attacks. The cookie draft is mostly intended to force "replays" of certain information, so this could be problematic for use in credential transfer. I suppose one could have something like an "adaptive cookie" that is modified by the UA, but this is sort of antithetical to the original cookie concept. -- Dean ----- Original Message ----- From: Sanjoy Sen To: 'dean.willis@softarmor.com' ; 'sip-security@ietf.org' Sent: Monday, October 22, 2001 4:05 PM Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? Dean, I like the option of using extended Remote-party-id header for transfering the credential. How about the option of using the Cookie header for the same purpose? Sanjoy ====================== To: "Jari Arkko" < Jari.Arkko@lmf.ericsson.se > Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? From: "Dean Willis" < dean.willis@softarmor.com > Date: Fri, 19 Oct 2001 11:10:07 -0500 Cc: "Pekka Pessi" , "James Undery" , List-Id: Security Issues for the SIP protocol References: <3BCED3BF.5EC21FFA@lmf.ericsson.se> <005701c158b0$71c24510$7d7075d5@flak> <3BD045BF.E55CF5B9@lmf.ericsson.se> Sender: sip-security-admin@ietf.org ---------------------------------------------------------------------------- ---- Ah, Perhaps I was being dense. I've just reread the entire thread. Perhaps further analysis of the requirement would help. Do we wish to authenticate the identity of the system that is acting as a UAS, or authenticate the identity of the human operating that system? What is the persistency of the relationship between the proxy and the UAS? Will the UAS need to know how to authenticate to many proxies? What level of security is required? Do we need to protect against playback, or does the call signature (to:, From:, Call-ID) provide sufficient uniqueness on its own? Several possible candidates might include TLS (already discussed, just issue a client cert signed by a CAS trusted by the proxy) IPSEC (key management base problem for IKE) HIP SSH Kerberos (it has to be said) Use of remote-party-ID extended with some sort of cryptographic signature of the response -- shared secret key -- PGP -- PKI cert -- kerberos key exchange Personally, I'm leaning toward the latter. This would have interesting interaction with the goals of the DCS Privacy draft. -- Dean ----- Original Message ----- From: "Jari Arkko" To: "Dean Willis" Cc: "Pekka Pessi" ; "James Undery" ; Sent: Friday, October 19, 2001 10:24 AM Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? > Dean Willis wrote: > > > SIP Proxies authenticate clients > > making use of those proxies. > > Yes... and this has to be interpreted very literally. > If you have a local proxy and a user agent, you can > authenticate half of what the user agent does, namely > the user agent client part, but not the user agent > server part. > > > If you want UAs to be able to authenticate every proxy that has processed a > > message, you'll need to do something like using a PKI to have each proxy > > sign the message and attach a signed copy of the message to the body of the > > outgoing message. Checking the authentications requires processing the > > signature chain in reverse order. It's pretty seriously tedious, and > > consumes vast amounts of signaling bandwidth, not to mention CPU. > > I don't think anyone is proposing authenticating every proxy. > Just the whole user agent to the local proxy. > > >Of course, one could implement TLS with bidirectional certification. That > >would essentisally authenticate edge proxies. > > This would work, if you can pay for it... seems a bit strange > that one has to upgrade to PKIs, TCP, public key cryptography, > etc. because an otherwise suitable scheme only works in one > direction. > > But I do appreciate the problems outlined in 19.4. Are > there any other possible solutions than TLS? > > 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 ------_=_NextPart_001_01C15B47.2FD37F40 Content-Type: text/html; charset="iso-8859-1" Re: [Sip-security] Proxy authentication in incoming INVITEs?
I was hoping that the UA and the Proxy are in the participatory mode (as defined in draft-willis-sip-cookies-00.txt) and are able to modify the cookie to a certain extent (am I correct in assuming this?). The Cookie header will contain the credential generated (by the Proxy) using the already existing security state association between the UA and the Proxy & will be added by the Proxy to all incoming Requests to the  UA (after the security association has been established). Thoughts?
 
Sanjoy
-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Monday, October 22, 2001 4:12 PM
To: Sen, Sanjoy [NGB:B602:EXCH]; sip-security
Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs?

 
That might work, but it would take some thinking. One of the issues is that the credential set needs to include something like a a serial number or a hash of the message it is in, or it is subject to replay attacks. The cookie draft is mostly intended to force "replays" of certain information, so this could be problematic for use in credential transfer.
 
I suppose one could have something like an "adaptive cookie" that is modified by the UA, but this is sort of antithetical to the original cookie concept.
 
--
Dean
----- Original Message -----
From: Sanjoy Sen
Sent: Monday, October 22, 2001 4:05 PM
Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs?

Dean,

   I like the option of using extended Remote-party-id header for transfering the credential. How about the option of using the Cookie header for the same purpose?

Sanjoy


======================

To: "Jari Arkko" <Jari.Arkko@lmf.ericsson.se>
Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs?
From: "Dean Willis" <dean.willis@softarmor.com>
Date: Fri, 19 Oct 2001 11:10:07 -0500
Cc: "Pekka Pessi" <Pekka.Pessi@nokia.com>, "James Undery" <jundery@ubiquity.net>, <sip-security@ietf.org>
List-Id: Security Issues for the SIP protocol <sip-security.ietf.org>
References: <3BCED3BF.5EC21FFA@lmf.ericsson.se> <pvg08hoshw.fsf@agni.research.nokia.com> <005701c158b0$71c24510$7d7075d5@flak> <3BD045BF.E55CF5B9@lmf.ericsson.se>

Sender: sip-security-admin@ietf.org

--------------------------------------------------------------------------------

Ah, Perhaps I was being dense. I've just reread the entire thread.

Perhaps further analysis of the requirement would help.

Do we wish to authenticate the identity of the system that is acting as a
UAS, or authenticate the identity of the human operating that system? What
is the persistency of the relationship between the proxy and the UAS? Will
the UAS need to know how to authenticate to many proxies? What level of
security is required? Do we need to protect against playback, or does the
call signature (to:, From:, Call-ID) provide sufficient uniqueness on its
own?


Several possible candidates might include

TLS (already discussed, just issue a client cert signed by a CAS trusted by
the proxy)
IPSEC (key management base problem for IKE)
HIP
SSH
Kerberos (it has to be said)
Use of remote-party-ID extended with some sort of cryptographic signature of
the response
-- shared secret key
-- PGP
-- PKI cert
--  kerberos key exchange

Personally, I'm leaning toward the latter. This would have interesting
interaction with the goals of the DCS Privacy draft.

--
Dean

----- Original Message -----
From: "Jari Arkko" <Jari.Arkko@lmf.ericsson.se>
To: "Dean Willis" <dean.willis@softarmor.com>
Cc: "Pekka Pessi" <Pekka.Pessi@nokia.com>; "James Undery"
<jundery@ubiquity.net>; <sip-security@ietf.org>
Sent: Friday, October 19, 2001 10:24 AM
Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs?


> Dean Willis wrote:
>
> > SIP Proxies authenticate clients
> > making use of those proxies.
>
> Yes... and this has to be interpreted very literally.
> If you have a local proxy and a user agent, you can
> authenticate half of what the user agent does, namely
> the user agent client part, but not the user agent
> server part.
>
> > If you want UAs to be able to authenticate every proxy that has
processed a
> > message, you'll need to do something like using a PKI to have each proxy
> > sign the message and attach a signed copy of the message to the body of
the
> > outgoing message. Checking the authentications requires processing the
> > signature chain in reverse order. It's pretty seriously tedious, and
> > consumes vast amounts of signaling bandwidth, not to mention CPU.
>
> I don't think anyone is proposing authenticating every proxy.
> Just the whole user agent to the local proxy.
>
> >Of course, one could implement TLS with bidirectional certification. That
> >would essentisally authenticate edge proxies.
>
> This would work, if you can pay for it... seems a bit strange
> that one has to upgrade to PKIs, TCP, public key cryptography,
> etc. because an otherwise suitable scheme only works in one
> direction.
>
> But I do appreciate the problems outlined in 19.4. Are
> there any other possible solutions than TLS?
>
> 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

------_=_NextPart_001_01C15B47.2FD37F40-- _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Mon Oct 22 21:15:19 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 VAA02338 for ; Mon, 22 Oct 2001 21:15:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13170; Mon, 22 Oct 2001 21:14:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13135 for ; Mon, 22 Oct 2001 21:14:12 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02331 for ; Mon, 22 Oct 2001 21:14:08 -0400 (EDT) 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 f9N1CUPI007238 for ; Mon, 22 Oct 2001 21:12:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQYTW>; Mon, 22 Oct 2001 21:13:42 -0400 Message-ID: From: Jonathan Rosenberg To: sip-security@ietf.org Date: Mon, 22 Oct 2001 21:13:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip-security] Basic/digest over TLS 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 Folks, One of the problems with the basic and digest mechanisms in SIP is that they assume a very short lived relationship between the client and the server, as was the case for HTTP in the beginning as well. In such a short lived relationship, establishment of session keys between a UA and a proxy makes little sense, and thats why that functionality was not initially provided. It was our initial vision that proxies would be pure forwarding engines, and thus most useful authentication would be primarily between UAC and UAS, not between users and proxies. However, things have changed, and it seems people are very much interested in more long lived relationships between clients and proxies, and authentication/integrity/privacy in that relationship is important. There is a very simple solution for this. A UA establishes a TLS connection with its server, and this TLS connection is used for all communications, in both directions, between the UA and the server. When the UA sends the first request over that connection, the server challenges it, using basic or digest, and therefore associates a user identity with messages arriving over that connection. That initial message can be REGISTER, or it can be INVITE. From then on, the server need not challenge any requests. The TLS conenction provides a persistent session key. If the connection breaks, the UA re-establishes, and the same thing happens again. This approach is not at all dis-similar to the way http has evolved, where user ID is done primarily using passwords sent over TLS connections that use server side certs only. The penalty, of course, is a whole lot of really long lived TCP connections hanging off a proxy, and the requirement for client establishment of the connection in order to secure identity. Persistent TCP is also probably going to be problematic for devices, like wireless handsets, which are only intermittently connected. However, that seems to be an issue of much controversy. This capability requires no extensions or changes to SIP, and would work with pretty much any client that supports TLS. Its merely a server side behavior - don't challenge requests over a TLS connection more than once. This mechanism provides quite a lot of whats needed - request and response authentication between UAC/proxy and proxy/UAS, integrity for those relationships, and privacy over those relationships. Comments? -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 sip-security-admin@ietf.org Mon Oct 22 21:18:40 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 VAA02356 for ; Mon, 22 Oct 2001 21:18:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13217; Mon, 22 Oct 2001 21:14:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13180 for ; Mon, 22 Oct 2001 21:14:26 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02333 for ; Mon, 22 Oct 2001 21:14:22 -0400 (EDT) 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 f9N1CSPI007235; Mon, 22 Oct 2001 21:12:29 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQYTV>; Mon, 22 Oct 2001 21:13:40 -0400 Message-ID: From: Jonathan Rosenberg To: Jari Arkko , Dean Willis , Jari Arkko Cc: Pekka Pessi , James Undery , sip-security@ietf.org Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? Date: Mon, 22 Oct 2001 21:13:39 -0400 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: Friday, October 19, 2001 1:44 PM > To: Dean Willis; Jari Arkko > Cc: Pekka Pessi; James Undery; sip-security@ietf.org > Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? > > > > > Perhaps further analysis of the requirement would help. > > Yes. Two cases: > > 1) I started this thread in order to discuss something which > at first look seemed more like a bug than a feature in current > SIP. HTTP authentication in SIP is propably going to stay, > so if possible it might make sense to try to make it work like, > uh, HTTP authentication which does allow what I originally > assumed SIP would allow. But this is mainly for the purpose > of keeping the specs symmetric and to give the right impression > to folks who use SIP. No, HTTP does not do what you are asking. Translating SIP elements to HTTP elements: UAC -> client proxy -> proxy UAS -> origin server What you want is for the proxy server to authenticate the identity of the UAS which has generated a response. This translates to having the proxy authenticate the identity of the origin server. rfc2617 does not provide that capability, to my knowledge. Proxy-Authorization-Info allows a client to authenticate the identity of proxies, which is not what you want. THe reason it is not mentioned in bis is that it has a fatal flaw - no realms. As a result, there is no way for a client to determine which set of credentials is provided by which proxy. This is an open issue I am currently tracking (issue #164). Now, that said, I do think its useful to be able to authenticate the identity of a responder by a proxy, but its not as critical as you might think. Authenticating the UAC is clearly critical, since they are the ones actively making a call. But, the UAS is responding to an event initiated by someone else. Thus, the attacks are different. An attacker could inject false responses to an INVITE, stopping someone else from getting calls. This would require eavesdropping of requests in order to see the call-ids, tags, and so on, and would require them to inject a response before the UAS answers. Yeah, its possible, but its much harder than other attacks where the attacker pretends to be a valid UAC. Its also not a fraud attack, but more of an individual dos attack. That said, how might we provide this functionality? Well, there are two ways that are within the realm of the current framework: 1. TLS between the proxy and the UAS 2. some kind of proxy->uas challenge (1) works within SIP now. You might think there is an issue because most UA won't have certs, and they are the server side in this transaction, but that need not be the case. If that same proxy is the one that a client registers to, the client can use a TLS connection to send its registration, and then maintain that connection. It performs basic or digest auth over it. Now, the server knows that the thing on the other end of this connection is a specific user, and can trust that any requests sent to it, and any responses from it, are actually from that user. More on this in a separate note. The other approach (2) is to have the proxies insert a new header into requests, Proxy-UAS-Authenticate or some other such thing. This contains a challenge. When the UAS sends a response, the response has an answer to the challenge, in another header of sorts, like Proxy-UAS-Authorization. The proxy inspects this, and then passes the response if its valid. If not, it may need to "resubmit" the request in order to ask for credentials once more (in the case of a stale nonce, for example). Now, thats the hard part, since proxies resubmitting requests seems untenable. But, turns out its not. The reason its not is that "proxies resubmitting requests" is no different than sequential forking. Just think about it. Granted, the R-URI doesn't change, but the proxy resubmitting the request would use a different branch ID on the topmost via. This would appear to the downstream proxy as a merged request. Now, we have recently agreed on the lists that merged requests are fine, and since the transaction is identified including the topmost via, the next hop proxy won't see this as a retransmission at all. When it arrives at the UAS, the UAS would see it as a separate transaction, but correlated with the previous request through call leg IDs. It could then generate a successful response, and that gets forwarded as usual. Thus, through "legal merged requests" we do have the ability for a proxy to retry a request after modification. I am not sure how interoperable this would be; since detecting request merging is hard, it might work through proxies that didn't try to detect this condition (and my guess is that most don't), but a UAS would probably be confused. THen again, this is all new behavior for a UAS, so maybe thats OK. -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 sip-security-admin@ietf.org Tue Oct 23 00:34:30 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 AAA06944 for ; Tue, 23 Oct 2001 00:34:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17955; Tue, 23 Oct 2001 00:33:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17924 for ; Tue, 23 Oct 2001 00:33:30 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06934 for ; Tue, 23 Oct 2001 00:33:29 -0400 (EDT) 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 AAA06778; Tue, 23 Oct 2001 00:33:31 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id f9N4XVb01271; Tue, 23 Oct 2001 00:33:31 -0400 (EDT) Message-ID: <3BD4F283.6E12FFD7@cs.columbia.edu> Date: Tue, 23 Oct 2001 00:30:59 -0400 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: 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 I agree (having advocated TLS for years...). I'm not clear whether the direction of the TCP connection has to be the same as that for TLS, i.e., could the TCP client (SIP proxy) be the TLS server? There doesn't seem to be an inherent coupling of the two roles. I vaguely remember that the two TCP parties can negotiate their role at the TLS level. This doesn't address the end-to-end protection case, but I suspect that S/MIME for message/sip handles most of the interesting cases, in addition to an improved version of Digest that includes headers in the digest. Can we go home now :-)? Jonathan Rosenberg wrote: > > Folks, > > One of the problems with the basic and digest mechanisms in SIP is that they > assume a very short lived relationship between the client and the server, as > was the case for HTTP in the beginning as well. In such a short lived > relationship, establishment of session keys between a UA and a proxy makes > little sense, and thats why that functionality was not initially provided. > It was our initial vision that proxies would be pure forwarding engines, and > thus most useful authentication would be primarily between UAC and UAS, not > between users and proxies. > > However, things have changed, and it seems people are very much interested > in more long lived relationships between clients and proxies, and > authentication/integrity/privacy in that relationship is important. > > There is a very simple solution for this. A UA establishes a TLS connection > with its server, and this TLS connection is used for all communications, in > both directions, between the UA and the server. When the UA sends the first > request over that connection, the server challenges it, using basic or > digest, and therefore associates a user identity with messages arriving over > that connection. That initial message can be REGISTER, or it can be INVITE. > > >From then on, the server need not challenge any requests. The TLS conenction > provides a persistent session key. If the connection breaks, the UA > re-establishes, and the same thing happens again. > > This approach is not at all dis-similar to the way http has evolved, where > user ID is done primarily using passwords sent over TLS connections that use > server side certs only. > > The penalty, of course, is a whole lot of really long lived TCP connections > hanging off a proxy, and the requirement for client establishment of the > connection in order to secure identity. Persistent TCP is also probably > going to be problematic for devices, like wireless handsets, which are only > intermittently connected. However, that seems to be an issue of much > controversy. > > This capability requires no extensions or changes to SIP, and would work > with pretty much any client that supports TLS. Its merely a server side > behavior - don't challenge requests over a TLS connection more than once. > > This mechanism provides quite a lot of whats needed - request and response > authentication between UAC/proxy and proxy/UAS, integrity for those > relationships, and privacy over those relationships. > > Comments? > _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Tue Oct 23 03:48: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 DAA23414 for ; Tue, 23 Oct 2001 03:48:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29764; Tue, 23 Oct 2001 03:41:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29731 for ; Tue, 23 Oct 2001 03:41:33 -0400 (EDT) Received: from fw11.telekom.de (gw11.telekom.de [62.225.183.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23381 for ; Tue, 23 Oct 2001 03:41:29 -0400 (EDT) From: Wolfgang.Beck01@telekom.de Received: by fw11.telekom.de; (8.8.8/1.3/10May95) id JAA03534; Tue, 23 Oct 2001 09:40:08 +0200 (MET DST) Received: from Q9J99.mgb01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for sip-security@ietf.org; Tue, 23 Oct 2001 09:41:28 +0200 Received: from g9jbq.mgb01.telekom.de by Q9J99.mgb01.telekom.de with ESMTP for sip-security@ietf.org; Tue, 23 Oct 2001 09:41:19 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Oct 2001 09:41:19 +0200 Message-Id: <4579F937256CD31191FF00902751580D039B87E9@U9JN2> To: sip-security@ietf.org Subject: RE: [Sip-security] Basic/digest over TLS -- denial of service Date: Tue, 23 Oct 2001 09:41:18 +0200 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 Hello, o in TLS, one party can request a CPU expensive operation from the other party without authentification. There is a paper describing the problem and describing a possible solution: http://www.cs.rice.edu/~astubble/tls-usenix.pdf The proposed solution is the 'client-puzzle'; the server sends a 'puzzle' to the client and the solution of this puzzle is used as a temporary authentification for requesting expensive public-key operations. I like the approach, but it might be not applicable in the SIP environment. Client puzzles that are expensive enough for fast workstations to prevent them from performing DoS attacks may cause unacceptable delays for users of cheap embedded SIP devices. o What are the memory and CPU requirements of keeping ten thousands of TLS connections in a large softswitch? o Using existing protocols is good thing, but it can lead to code bloat. What does a SIP device need to have? - SIP stuff (parser, state machine, encoder) - a MIME parser /encoder - S/MIME (that means ASN1 BER for CMS)? - MIME/PGP ? - TLS ? Does that fit in my SIP-capable wrist watch? -- Wolfgang Beck T-Systems Nova GmbH _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Tue Oct 23 11:41:58 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 LAA08179 for ; Tue, 23 Oct 2001 11:41:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14020; Tue, 23 Oct 2001 11:31:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13990 for ; Tue, 23 Oct 2001 11:31:44 -0400 (EDT) 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 LAA07762 for ; Tue, 23 Oct 2001 11:31:40 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id C61901E078; Tue, 23 Oct 2001 11:31:44 -0400 (EDT) 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 LAA20936; Tue, 23 Oct 2001 11:31:43 -0400 (EDT) Message-ID: <3BD58D3F.D3BE13A9@research.att.com> Date: Tue, 23 Oct 2001 11:31:11 -0400 From: "C. R. Kalmanek" X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: 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 Hi, This framework (TLS/certs for server auth + http basic or digest for client auth) seems to meet most requirements: + it can be used between clients and servers that are either inside (easy) or outside firewalls + it provides mutual authentication + TLS connection provides both message privacy and integrity There seem to be a few remaining questions that we need to have answers to: Assuming TLS connections are long-lived, how scalable is this solution? Web servers have not had to deal with persistent connections that last essentially forever, from huge numbers of clients. Scalability may not be an issue in the short term, but we need to take a longer view. Can TLS connections be initiated from server->client? (so we don't need to keep them around forever). If so, what is the impact on session establishment delay? IMHO, there is real value to having a UDP based solution that is equivalent to TLS in functionality. IPSec could provide this, if combined with an acceptable key management scheme (not necessarily IKE) and if server implementations allow adequate visibility into the security association that a packet arrived on. Any comments on the scalability issue? Not sure we should go home just yet :). chuck Jonathan Rosenberg wrote: > > Folks, > > One of the problems with the basic and digest mechanisms in SIP is that they > assume a very short lived relationship between the client and the server, as > was the case for HTTP in the beginning as well. In such a short lived > relationship, establishment of session keys between a UA and a proxy makes > little sense, and thats why that functionality was not initially provided. > It was our initial vision that proxies would be pure forwarding engines, and > thus most useful authentication would be primarily between UAC and UAS, not > between users and proxies. > > However, things have changed, and it seems people are very much interested > in more long lived relationships between clients and proxies, and > authentication/integrity/privacy in that relationship is important. > > There is a very simple solution for this. A UA establishes a TLS connection > with its server, and this TLS connection is used for all communications, in > both directions, between the UA and the server. When the UA sends the first > request over that connection, the server challenges it, using basic or > digest, and therefore associates a user identity with messages arriving over > that connection. That initial message can be REGISTER, or it can be INVITE. > > From then on, the server need not challenge any requests. The TLS conenction > provides a persistent session key. If the connection breaks, the UA > re-establishes, and the same thing happens again. > > This approach is not at all dis-similar to the way http has evolved, where > user ID is done primarily using passwords sent over TLS connections that use > server side certs only. > > The penalty, of course, is a whole lot of really long lived TCP connections > hanging off a proxy, and the requirement for client establishment of the > connection in order to secure identity. Persistent TCP is also probably > going to be problematic for devices, like wireless handsets, which are only > intermittently connected. However, that seems to be an issue of much > controversy. > > This capability requires no extensions or changes to SIP, and would work > with pretty much any client that supports TLS. Its merely a server side > behavior - don't challenge requests over a TLS connection more than once. > > This mechanism provides quite a lot of whats needed - request and response > authentication between UAC/proxy and proxy/UAS, integrity for those > relationships, and privacy over those relationships. > > Comments? > > -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 _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Tue Oct 23 15:51:56 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 PAA17846 for ; Tue, 23 Oct 2001 15:51:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22364; Tue, 23 Oct 2001 15:49:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22328 for ; Tue, 23 Oct 2001 15:49:35 -0400 (EDT) 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 PAA17744 for ; Tue, 23 Oct 2001 15:49:30 -0400 (EDT) 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 f9NJnHV24865; Tue, 23 Oct 2001 15:49:17 -0400 (EDT) Message-ID: <3BD5C9BD.EAEA978F@cs.columbia.edu> Date: Tue, 23 Oct 2001 15:49:17 -0400 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: "C. R. Kalmanek" CC: Jonathan Rosenberg , sip-security@ietf.org Subject: Re: [Sip-security] Basic/digest over TLS References: <3BD58D3F.D3BE13A9@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 "C. R. Kalmanek" wrote: > > Assuming TLS connections are long-lived, how scalable is this > solution? Web servers have not had to deal with persistent > connections that last essentially forever, from huge numbers > of clients. Scalability may not be an issue in the short > term, but we need to take a longer view. Would the session lifetimes be much longer than, say, for a web banking or order application, where it's probably also on the order of minutes to tens of minutes? > > Can TLS connections be initiated from server->client? (so we > don't need to keep them around forever). If so, what is the > impact on session establishment delay? I'm not sure, but according to Thomas, "SSL and TLS Essentials", the (TCP, I assume) server can ask a client to restart the connection (Section 4.5.1), using HelloRequest. Also, this seems to be primarily a memory issue. Anybody know how much state is consumed by a TLS connection, above and beyond TCP state? If we assume 1 kB and 20,000 connections, which seems high for a single server, that's 20 MB, which costs roughly $3. > > IMHO, there is real value to having a UDP based solution that > is equivalent to TLS in functionality. IPSec could provide > this, if combined with an acceptable key management scheme > (not necessarily IKE) and if server implementations allow > adequate visibility into the security association that a > packet arrived on. In one of my network security exams, I asked students what it would take to run TLS on top of UDP. We didn't do a careful analysis, but my perception is that the record layer would have to be modified a bit, but it wouldn't affect the rest of the protocol. However, I don't think this is necessary, since the TCP state isn't that big a deal. > > Any comments on the scalability issue? See above. > > Not sure we should go home just yet :). > > chuck > -- 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 sip-security-admin@ietf.org Tue Oct 23 17:15:26 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 RAA20427 for ; Tue, 23 Oct 2001 17:15:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24306; Tue, 23 Oct 2001 17:04:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24271 for ; Tue, 23 Oct 2001 17:04:04 -0400 (EDT) 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 RAA20157 for ; Tue, 23 Oct 2001 17:03:58 -0400 (EDT) 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 QAA15428 for ; Tue, 23 Oct 2001 16:03:33 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 23 Oct 2001 15:56:37 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Oct 2001 16:02:44 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F263@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jonathan Rosenberg'" , Jari Arkko , Dean Willis Cc: Pekka Pessi , James Undery , sip-security@ietf.org Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? Date: Tue, 23 Oct 2001 16:02:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15C06.0CD15890" 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_01C15C06.0CD15890 Content-Type: text/plain; charset="iso-8859-1" Jonathan, A couple of questions/clarifications related to your scheme (2) below: 1. When you talk about using a different branch id with the topmost Via header, are you just talking about the part used for matching requests with responses or the entire via-branch parameter? 2. Given your scheme below which allows "resubmission" of a Request by a Proxy, is it possible for the Proxy now to add the Proxy-Authorization (or UAS-Proxy-Authorization?) header to Requests towards the UAS? This can be used to satisfy the requirement of authenticating Request messages from the Proxy towards the UAS. I'm assuming that the Proxy and UAS have an already set-up Security Association which can be used to generate the message-authentication credential which is inserted by the Proxy in the Proxy-Authorization(?) header. If message authentication is the sole purpose (as in this case), is it more clean to define a new header? Regards, Sanjoy > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, October 22, 2001 8:14 PM > To: Jari Arkko; Dean Willis; Jari Arkko > Cc: Pekka Pessi; James Undery; sip-security@ietf.org > Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? > > > > > > > > -----Original Message----- > > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > > Sent: Friday, October 19, 2001 1:44 PM > > To: Dean Willis; Jari Arkko > > Cc: Pekka Pessi; James Undery; sip-security@ietf.org > > Subject: Re: [Sip-security] Proxy authentication in > incoming INVITEs? > > > > > > > > > Perhaps further analysis of the requirement would help. > > > > Yes. Two cases: > > > > 1) I started this thread in order to discuss something which > > at first look seemed more like a bug than a feature in current > > SIP. HTTP authentication in SIP is propably going to stay, > > so if possible it might make sense to try to make it work like, > > uh, HTTP authentication which does allow what I originally > > assumed SIP would allow. But this is mainly for the purpose > > of keeping the specs symmetric and to give the right impression > > to folks who use SIP. > > No, HTTP does not do what you are asking. > > Translating SIP elements to HTTP elements: > > UAC -> client > proxy -> proxy > UAS -> origin server > > What you want is for the proxy server to authenticate the > identity of the > UAS which has generated a response. This translates to having > the proxy > authenticate the identity of the origin server. rfc2617 does > not provide > that capability, to my knowledge. > > Proxy-Authorization-Info allows a client to authenticate the > identity of > proxies, which is not what you want. THe reason it is not > mentioned in bis > is that it has a fatal flaw - no realms. As a result, there > is no way for a > client to determine which set of credentials is provided by > which proxy. > This is an open issue I am currently tracking (issue #164). > > Now, that said, I do think its useful to be able to authenticate the > identity of a responder by a proxy, but its not as critical > as you might > think. Authenticating the UAC is clearly critical, since they > are the ones > actively making a call. But, the UAS is responding to an > event initiated by > someone else. Thus, the attacks are different. An attacker > could inject > false responses to an INVITE, stopping someone else from > getting calls. This > would require eavesdropping of requests in order to see the > call-ids, tags, > and so on, and would require them to inject a response before the UAS > answers. Yeah, its possible, but its much harder than other > attacks where > the attacker pretends to be a valid UAC. Its also not a fraud > attack, but > more of an individual dos attack. > > That said, how might we provide this functionality? Well, > there are two ways > that are within the realm of the current framework: > > 1. TLS between the proxy and the UAS > 2. some kind of proxy->uas challenge > > (1) works within SIP now. You might think there is an issue > because most UA > won't have certs, and they are the server side in this > transaction, but that > need not be the case. If that same proxy is the one that a > client registers > to, the client can use a TLS connection to send its > registration, and then > maintain that connection. It performs basic or digest auth > over it. Now, the > server knows that the thing on the other end of this connection is a > specific user, and can trust that any requests sent to it, > and any responses > from it, are actually from that user. More on this in a separate note. > > The other approach (2) is to have the proxies insert a new header into > requests, Proxy-UAS-Authenticate or some other such thing. > This contains a > challenge. When the UAS sends a response, the response has an > answer to the > challenge, in another header of sorts, like > Proxy-UAS-Authorization. The > proxy inspects this, and then passes the response if its > valid. If not, it > may need to "resubmit" the request in order to ask for > credentials once more > (in the case of a stale nonce, for example). Now, thats the > hard part, since > proxies resubmitting requests seems untenable. But, turns out its not. > > The reason its not is that "proxies resubmitting requests" is > no different > than sequential forking. Just think about it. Granted, the > R-URI doesn't > change, but the proxy resubmitting the request would use a > different branch > ID on the topmost via. This would appear to the downstream > proxy as a merged > request. Now, we have recently agreed on the lists that > merged requests are > fine, and since the transaction is identified including the > topmost via, the > next hop proxy won't see this as a retransmission at all. > When it arrives at > the UAS, the UAS would see it as a separate transaction, but > correlated with > the previous request through call leg IDs. It could then generate a > successful response, and that gets forwarded as usual. > > Thus, through "legal merged requests" we do have the ability > for a proxy to > retry a request after modification. I am not sure how > interoperable this > would be; since detecting request merging is hard, it might > work through > proxies that didn't try to detect this condition (and my > guess is that most > don't), but a UAS would probably be confused. THen again, > this is all new > behavior for a UAS, so maybe thats OK. > > -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 > ------_=_NextPart_001_01C15C06.0CD15890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip-security] Proxy authentication in incoming = INVITEs?

Jonathan,

    A couple of = questions/clarifications related to your scheme (2) below:

1. When you talk about using a different branch id = with the topmost Via header, are you just talking about the part used = for matching requests with responses or the entire via-branch = parameter?

2. Given your scheme below which allows = "resubmission" of a Request by a Proxy, is it possible for = the Proxy now to add the Proxy-Authorization (or = UAS-Proxy-Authorization?) header to Requests towards the UAS? This can = be used to satisfy the requirement of authenticating Request messages = from the Proxy towards the UAS. I'm assuming that the Proxy and UAS = have an already set-up Security Association which can be used to = generate the message-authentication credential which is inserted by the = Proxy in the Proxy-Authorization(?) header. If message authentication = is the sole purpose (as in this case), is it more clean to define a new = header?

Regards,
Sanjoy




> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Monday, October 22, 2001 8:14 PM
> To: Jari Arkko; Dean Willis; Jari Arkko
> Cc: Pekka Pessi; James Undery; = sip-security@ietf.org
> Subject: RE: [Sip-security] Proxy = authentication in incoming INVITEs?
>
>
>
>
> 
>
> > -----Original Message-----
> > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi= ]
> > Sent: Friday, October 19, 2001 1:44 = PM
> > To: Dean Willis; Jari Arkko
> > Cc: Pekka Pessi; James Undery; = sip-security@ietf.org
> > Subject: Re: [Sip-security] Proxy = authentication in
> incoming INVITEs?
> >
> >
> >
> > > Perhaps further analysis of the = requirement would help.
> >
> > Yes. Two cases:
> >
> > 1) I started this thread in order to = discuss something which
> > at first look seemed more like a bug than = a feature in current
> > SIP. HTTP authentication in SIP is = propably going to stay,
> > so if possible it might make sense to try = to make it work like,
> > uh, HTTP authentication which does allow = what I originally
> > assumed SIP would allow. But this is = mainly for the purpose
> > of keeping the specs symmetric and to give = the right impression
> > to folks who use SIP.
>
> No, HTTP does not do what you are asking.=
>
> Translating SIP elements to HTTP = elements:
>
> UAC -> client
> proxy -> proxy
> UAS -> origin server
>
> What you want is for the proxy server to = authenticate the
> identity of the
> UAS which has generated a response. This = translates to having
> the proxy
> authenticate the identity of the origin server. = rfc2617 does
> not provide
> that capability, to my knowledge.
>
> Proxy-Authorization-Info allows a client to = authenticate the
> identity of
> proxies, which is not what you want. THe reason = it is not
> mentioned in bis
> is that it has a fatal flaw - no realms. As a = result, there
> is no way for a
> client to determine which set of credentials is = provided by
> which proxy.
> This is an open issue I am currently tracking = (issue #164).
>
> Now, that said, I do think its useful to be = able to authenticate the
> identity of a responder by a proxy, but its not = as critical
> as you might
> think. Authenticating the UAC is clearly = critical, since they
> are the ones
> actively making a call. But, the UAS is = responding to an
> event initiated by
> someone else. Thus, the attacks are different. = An attacker
> could inject
> false responses to an INVITE, stopping someone = else from
> getting calls. This
> would require eavesdropping of requests in = order to see the
> call-ids, tags,
> and so on, and would require them to inject a = response before the UAS
> answers. Yeah, its possible, but its much = harder than other
> attacks where
> the attacker pretends to be a valid UAC. Its = also not a fraud
> attack, but
> more of an individual dos attack.
>
> That said, how might we provide this = functionality? Well,
> there are two ways
> that are within the realm of the current = framework:
>
> 1. TLS between the proxy and the UAS
> 2. some kind of proxy->uas challenge
>
> (1) works within SIP now. You might think there = is an issue
> because most UA
> won't have certs, and they are the server side = in this
> transaction, but that
> need not be the case. If that same proxy is the = one that a
> client registers
> to, the client can use a TLS connection to send = its
> registration, and then
> maintain that connection. It performs basic or = digest auth
> over it. Now, the
> server knows that the thing on the other end of = this connection is a
> specific user, and can trust that any requests = sent to it,
> and any responses
> from it, are actually from that user. More on = this in a separate note.
>
> The other approach (2) is to have the proxies = insert a new header into
> requests, Proxy-UAS-Authenticate or some other = such thing.
> This contains a
> challenge. When the UAS sends a response, the = response has an
> answer to the
> challenge, in another header of sorts, like =
> Proxy-UAS-Authorization. The
> proxy inspects this, and then passes the = response if its
> valid. If not, it
> may need to "resubmit" the request in = order to ask for
> credentials once more
> (in the case of a stale nonce, for example). = Now, thats the
> hard part, since
> proxies resubmitting requests seems untenable. = But, turns out its not.
>
> The reason its not is that "proxies = resubmitting requests" is
> no different
> than sequential forking. Just think about it. = Granted, the
> R-URI doesn't
> change, but the proxy resubmitting the request = would use a
> different branch
> ID on the topmost via. This would appear to the = downstream
> proxy as a merged
> request. Now, we have recently agreed on the = lists that
> merged requests are
> fine, and since the transaction is identified = including the
> topmost via, the
> next hop proxy won't see this as a = retransmission at all.
> When it arrives at
> the UAS, the UAS would see it as a separate = transaction, but
> correlated with
> the previous request through call leg IDs. It = could then generate a
> successful response, and that gets forwarded as = usual.
>
> Thus, through "legal merged requests" = we do have the ability
> for a proxy to
> retry a request after modification. I am not = sure how
> interoperable this
> would be; since detecting request merging is = hard, it might
> work through
> proxies that didn't try to detect this = condition (and my
> guess is that most
> don't), but a UAS would probably be confused. = THen again,
> this is all new
> behavior for a UAS, so maybe thats OK.
>
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
> Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> = _______________________________________________
> Sip-security mailing list
> Sip-security@ietf.org
> http://www1.ietf.org/mailman/listinfo/sip-security=
>

------_=_NextPart_001_01C15C06.0CD15890-- _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Tue Oct 23 18:30:41 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 SAA21736 for ; Tue, 23 Oct 2001 18:30:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26389; Tue, 23 Oct 2001 18:26:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26352 for ; Tue, 23 Oct 2001 18:26:44 -0400 (EDT) Received: from longmail2.lboard.com ([63.109.116.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21658 for ; Tue, 23 Oct 2001 18:26:40 -0400 (EDT) Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id <49ZFTPFG>; Tue, 23 Oct 2001 18:24:47 -0400 Message-ID: From: Ed Ellesson To: "'Henning G. Schulzrinne'" , "C. R. Kalmanek" Cc: Jonathan Rosenberg , sip-security@ietf.org Subject: RE: [Sip-security] Basic/digest over TLS Date: Tue, 23 Oct 2001 18:24:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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 I was under the impression that the max number of file descriptors available in the OS is the limiting factor in determining the max number of TCP sessions that are possible. Does anyone have a list of max possible file descriptors, or, better yet, max possible active TCP sessions that have been tested or claimed, on some popular OS's? (If someone knows that this limitation has been removed, or if it has been replaced by perhaps another limitation such as max threads, please advise.) Thanks, Ed Ellesson LongBoard, Inc. -----Original Message----- From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, October 23, 2001 3:49 PM To: C. R. Kalmanek Cc: Jonathan Rosenberg; sip-security@ietf.org Subject: Re: [Sip-security] Basic/digest over TLS "C. R. Kalmanek" wrote: > > Assuming TLS connections are long-lived, how scalable is this > solution? Web servers have not had to deal with persistent > connections that last essentially forever, from huge numbers > of clients. Scalability may not be an issue in the short > term, but we need to take a longer view. Would the session lifetimes be much longer than, say, for a web banking or order application, where it's probably also on the order of minutes to tens of minutes? > > Can TLS connections be initiated from server->client? (so we > don't need to keep them around forever). If so, what is the > impact on session establishment delay? I'm not sure, but according to Thomas, "SSL and TLS Essentials", the (TCP, I assume) server can ask a client to restart the connection (Section 4.5.1), using HelloRequest. Also, this seems to be primarily a memory issue. Anybody know how much state is consumed by a TLS connection, above and beyond TCP state? If we assume 1 kB and 20,000 connections, which seems high for a single server, that's 20 MB, which costs roughly $3. > > IMHO, there is real value to having a UDP based solution that > is equivalent to TLS in functionality. IPSec could provide > this, if combined with an acceptable key management scheme > (not necessarily IKE) and if server implementations allow > adequate visibility into the security association that a > packet arrived on. In one of my network security exams, I asked students what it would take to run TLS on top of UDP. We didn't do a careful analysis, but my perception is that the record layer would have to be modified a bit, but it wouldn't affect the rest of the protocol. However, I don't think this is necessary, since the TCP state isn't that big a deal. > > Any comments on the scalability issue? See above. > > Not sure we should go home just yet :). > > chuck > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ 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 sip-security-admin@ietf.org Tue Oct 23 18:33:03 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 SAA21772 for ; Tue, 23 Oct 2001 18:33:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26515; Tue, 23 Oct 2001 18:29:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26444 for ; Tue, 23 Oct 2001 18:29:14 -0400 (EDT) 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 SAA21716 for ; Tue, 23 Oct 2001 18:29:09 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id AB9E84CE07; Tue, 23 Oct 2001 18:29:10 -0400 (EDT) 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 SAA28489; Tue, 23 Oct 2001 18:29:09 -0400 (EDT) Message-ID: <3BD5EF13.B80231BA@research.att.com> Date: Tue, 23 Oct 2001 18:28:35 -0400 From: "C. R. Kalmanek" X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , sip-security@ietf.org Subject: Re: [Sip-security] Basic/digest over TLS References: <3BD58D3F.D3BE13A9@research.att.com> <3BD5C9BD.EAEA978F@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 Responses below. "Henning G. Schulzrinne" wrote: > > "C. R. Kalmanek" wrote: > > > > > Assuming TLS connections are long-lived, how scalable is this > > solution? Web servers have not had to deal with persistent > > connections that last essentially forever, from huge numbers > > of clients. Scalability may not be an issue in the short > > term, but we need to take a longer view. > > Would the session lifetimes be much longer than, say, for a web banking > or order application, where it's probably also on the order of minutes > to tens of minutes? To minimize post dial delay, sessions may need to be up for a very long time. > > Can TLS connections be initiated from server->client? (so we > > don't need to keep them around forever). If so, what is the > > impact on session establishment delay? > > I'm not sure, but according to Thomas, "SSL and TLS Essentials", the > (TCP, I assume) server can ask a client to restart the connection > (Section 4.5.1), using HelloRequest. If this works (I'm not sure either), the ClientHello would presumably include a Session ID to indicate that it wants to reuse a previously existing connection. This still involves TCP's 3-way handshake, but is faster than initiating a TLS session from scratch. One other concern is that TCP's congestion control algorithm is not well matched with the performance requirements of signaling. The standard 500 ms retransmission timer is huge compared with post dial delay budget, and even worse if multiple losses cause an exponential timer backoff -- hidden in the kernel and invisible to my signaling application... > Also, this seems to be primarily a memory issue. Anybody know how much > state is consumed by a TLS connection, above and beyond TCP state? If we > assume 1 kB and 20,000 connections, which seems high for a single > server, that's 20 MB, which costs roughly $3. True enough. Although implementors seem to be very concerned about large numbers of held TCP connections. > > IMHO, there is real value to having a UDP based solution that > > is equivalent to TLS in functionality. IPSec could provide > > this, if combined with an acceptable key management scheme > > (not necessarily IKE) and if server implementations allow > > adequate visibility into the security association that a > > packet arrived on. > > In one of my network security exams, I asked students what it would take > to run TLS on top of UDP. We didn't do a careful analysis, but my > perception is that the record layer would have to be modified a bit, but > it wouldn't affect the rest of the protocol. However, I don't think this > is necessary, since the TCP state isn't that big a deal. It's probably more complicated than that, message order issues would need to be addressed, etc. But it would be good to have a version of TLS over UDP... _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Tue Oct 23 23:10: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 XAA28635 for ; Tue, 23 Oct 2001 23:10:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02559; Tue, 23 Oct 2001 23:06:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02528 for ; Tue, 23 Oct 2001 23:06:33 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28586 for ; Tue, 23 Oct 2001 23:06:27 -0400 (EDT) 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 f9O34dPI015154; Tue, 23 Oct 2001 23:04:40 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Oct 2001 23:05:50 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sanjoy Sen'" , Jonathan Rosenberg , Jari Arkko , Dean Willis Cc: Pekka Pessi , James Undery , sip-security@ietf.org Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? Date: Tue, 23 Oct 2001 23:05:48 -0400 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: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Tuesday, October 23, 2001 5:03 PM To: 'Jonathan Rosenberg'; Jari Arkko; Dean Willis Cc: Pekka Pessi; James Undery; sip-security@ietf.org Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? >Jonathan, > A couple of questions/clarifications related to your scheme (2) below: > >1. When you talk about using a different branch id with the topmost Via header, are you >just talking about the part used for matching requests with responses or the entire via- >branch parameter? The part for matching requests with responses, which, being part of the entire branch parameter, means the entire via branch parameter will be different. > >2. Given your scheme below which allows "resubmission" of a Request by a Proxy, is it >possible for the Proxy now to add the Proxy-Authorization (or UAS-Proxy-Authorization?) Sure. Proxies that do sequential forking can have different requests on each forked branch. >header to Requests towards the UAS? This can be used to satisfy the requirement of >authenticating Request messages from the Proxy towards the UAS. I'm assuming that the >Proxy and UAS have an already set-up Security Association which can be used to generate >the message-authentication credential which is inserted by the Proxy in the Proxy- >Authorization(?) header. If message authentication is the sole purpose (as in this case), >is it more clean to define a new header? I don't understand. If you already have a security association between the ua and proxy (ala tls or ipsec) then what do you need from sip? -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 sip-security-admin@ietf.org Tue Oct 23 23:26:34 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 XAA28905 for ; Tue, 23 Oct 2001 23:26:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02761; Tue, 23 Oct 2001 23:22:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02715 for ; Tue, 23 Oct 2001 23:22:06 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28830 for ; Tue, 23 Oct 2001 23:22:00 -0400 (EDT) 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 f9O3JnPI015199; Tue, 23 Oct 2001 23:19:49 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Oct 2001 23:21:00 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning G. Schulzrinne'" , "C. R. Kalmanek" Cc: Jonathan Rosenberg , sip-security@ietf.org Subject: RE: [Sip-security] Basic/digest over TLS Date: Tue, 23 Oct 2001 23:20:51 -0400 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 G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, October 23, 2001 3:49 PM > To: C. R. Kalmanek > Cc: Jonathan Rosenberg; sip-security@ietf.org > Subject: Re: [Sip-security] Basic/digest over TLS > > > "C. R. Kalmanek" wrote: > > > > > Assuming TLS connections are long-lived, how scalable is this > > solution? Web servers have not had to deal with persistent > > connections that last essentially forever, from huge numbers > > of clients. Scalability may not be an issue in the short > > term, but we need to take a longer view. > > Would the session lifetimes be much longer than, say, for a > web banking > or order application, where it's probably also on the order of minutes > to tens of minutes? I suspect you are going to need to keep them open indefinitely to support quick call setups. In any case, proxy->UA tcp connections are not likely to work for nat/fw reasons. > > > > > Can TLS connections be initiated from server->client? (so we > > don't need to keep them around forever). If so, what is the > > impact on session establishment delay? > > I'm not sure, but according to Thomas, "SSL and TLS Essentials", the > (TCP, I assume) server can ask a client to restart the connection > (Section 4.5.1), using HelloRequest. Does having a different tcp directionality (compared to the client/server tls roles) introduce any security issues? > > Also, this seems to be primarily a memory issue. Anybody know how much > state is consumed by a TLS connection, above and beyond TCP > state? If we > assume 1 kB and 20,000 connections, which seems high for a single > server, that's 20 MB, which costs roughly $3. The issue about memory/resource consumption for lots of tcp connections plagued the IMPP working group for months. Seems that there is a lot of very contradictory anecdotal evidence about this subject. -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 sip-security-admin@ietf.org Tue Oct 23 23:30:26 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 XAA29037 for ; Tue, 23 Oct 2001 23:30:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02877; Tue, 23 Oct 2001 23:26:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02844 for ; Tue, 23 Oct 2001 23:26:33 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28902 for ; Tue, 23 Oct 2001 23:26:27 -0400 (EDT) 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 XAA14696; Tue, 23 Oct 2001 23:26:28 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id f9O3QRb07888; Tue, 23 Oct 2001 23:26:27 -0400 (EDT) Message-ID: <3BD6344B.2EDC6CD6@cs.columbia.edu> Date: Tue, 23 Oct 2001 23:23:55 -0400 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Henning G. Schulzrinne'" , "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 > I suspect you are going to need to keep them open indefinitely to support > quick call setups. In any case, proxy->UA tcp connections are not likely to > work for nat/fw reasons. > Not all environments run firewalls or, more seriously, NATs, fortunately. For example, I could well see running this inside a corporation, to the outbound proxy. > Does having a different tcp directionality (compared to the client/server > tls roles) introduce any security issues? Not that I know of. From my limited understanding, this simply is a request to the client to start the normal TLS handshake, so the rest of the TLS exchange is exactly the same. > > The issue about memory/resource consumption for lots of tcp connections > plagued the IMPP working group for months. Seems that there is a lot of very > contradictory anecdotal evidence about this subject. I suspect that the answer will largely come down to OS written for web servers (NT, Solaris, Linux) vs. real-time OS (VxWorks and kin). The primary problem is not likely to be memory consumption, but search time for connection lookup. _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Wed Oct 24 01:11: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 BAA01476 for ; Wed, 24 Oct 2001 01:11:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05156; Wed, 24 Oct 2001 01:03:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05127 for ; Wed, 24 Oct 2001 01:03:49 -0400 (EDT) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01040 for ; Wed, 24 Oct 2001 01:03:45 -0400 (EDT) Received: from jariws1 ([62.248.238.80]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011024050346.OTVY1726.fep06-app.kolumbus.fi@jariws1>; Wed, 24 Oct 2001 08:03:46 +0300 Message-ID: <00fc01c15c49$480c05c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Jonathan Rosenberg" , "'Henning G. Schulzrinne'" , "C. R. Kalmanek" Cc: References: Subject: Re: [Sip-security] Basic/digest over TLS Date: Wed, 24 Oct 2001 08:03:55 +0300 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 > 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? ;-) The TLS solution is excellent in many respects, but I do have a number of concerns particularly with its application on large mobile networks. Perhaps someone can answer my questions below: * 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? * Bandwidth. How much extra bandwidth is going to be consumed by sending certificates etc? * 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. Given the roaming situation, delays in registration/initial set up are also relevant, particularly when radio resources are consumed and there is no guarantee yet that the subscriber makes any billable traffic. So, what is the additional amount of RTTs introduced by TCP + TLS? * 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.). * 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? 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. Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From sip-security-admin@ietf.org Wed Oct 24 12:27:03 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 MAA05390 for ; Wed, 24 Oct 2001 12:26:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01030; Wed, 24 Oct 2001 12:26:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00995 for ; Wed, 24 Oct 2001 12:26:07 -0400 (EDT) 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 MAA05359 for ; Wed, 24 Oct 2001 12:26:04 -0400 (EDT) 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 LAA17979 for ; Wed, 24 Oct 2001 11:25:32 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 24 Oct 2001 11:23:22 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Oct 2001 11:24:39 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F266@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jonathan Rosenberg'" , Jari Arkko , Dean Willis Cc: Pekka Pessi , James Undery , sip-security@ietf.org Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? Date: Wed, 24 Oct 2001 11:24:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15CA8.604A7CC0" 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_01C15CA8.604A7CC0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, October 23, 2001 10:06 PM > To: Sen, Sanjoy [NGB:B602:EXCH]; Jonathan Rosenberg; Jari Arkko; Dean > Willis > Cc: Pekka Pessi; James Undery; sip-security@ietf.org > Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs? > > > > > >2. Given your scheme below which allows "resubmission" of a > Request by a > Proxy, is it > >possible for the Proxy now to add the Proxy-Authorization (or > UAS-Proxy-Authorization?) > > Sure. Proxies that do sequential forking can have different > requests on each > forked branch. > > Consider the case when an incoming INVITE (through a local Proxy) & the Proxy itself, need to be authenticated by the UAS. According to section 3.6 of RFC 2617, a Proxy can be authenticated to an origin server using the Proxy-Authenticate and Proxy-Authorization headers. As you said, for SIP<->HTTP translation, Proxy<-->Proxy & UAS<-->origin server. The call sequence is as follows: 1. Proxy-->UAS: INVITE (Proxy-Authorization:...) //Proxy adds "Proxy-Authorization", but according to Sec. 19.4 of bis04, Proxies are NOT allowed to insert Proxy-Authorization header, unless the request is re-submitted. Hence, as you've proposed, the Proxy can mimick forking by using a new branch-id & resubmit the INVITE 2. UAS-->Proxy: 407 (Proxy-Authenticate:...) //if the credentials do not satisfy the UAS, it sends a new challenge 3. Proxy-->UAS: INVITE (Proxy-Authorization:...) // This is also re-submitted as before with new credentials 4. UAS-->Proxy: 200 OK (Proxy-Authentication-Info:...) // For mutual authentication. If the Proxy is okay with this, it forwards the 200 OK. If not, it issues a new challenge to the UAS. Q: In the latter case, does the Proxy resubmit the INVITE with a Proxy-UAS-Authenticate header? For any new request, the Proxy, if required, can pre-emptively insert the Proxy-Authorization header for message authentication purpose & resubmit the request. 5. Proxy-->UAS: (re)INVITE (Proxy-Authorization:...) ... Is this call flow valid? Regards, Sanjoy ------_=_NextPart_001_01C15CA8.604A7CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip-security] Proxy authentication in incoming = INVITEs?

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, October 23, 2001 10:06 PM
> To: Sen, Sanjoy [NGB:B602:EXCH]; Jonathan = Rosenberg; Jari Arkko; Dean
> Willis
> Cc: Pekka Pessi; James Undery; = sip-security@ietf.org
> Subject: RE: [Sip-security] Proxy = authentication in incoming INVITEs?
>
>
> >
> >2. Given your scheme below which allows = "resubmission" of a
> Request by a
> Proxy, is it
> >possible for the Proxy now to add the = Proxy-Authorization (or
> UAS-Proxy-Authorization?)
>
> Sure. Proxies that do sequential forking can = have different
> requests on each
> forked branch.
>
>

Consider the case when an incoming INVITE (through a = local Proxy) & the Proxy itself, need to be authenticated by the = UAS. According to section 3.6 of RFC 2617, a Proxy can be authenticated = to an origin server using the Proxy-Authenticate and = Proxy-Authorization headers. As you said, for SIP<->HTTP = translation, Proxy<-->Proxy & UAS<-->origin server. The = call sequence is as follows:

1. Proxy-->UAS: INVITE (Proxy-Authorization:...) =
//Proxy adds "Proxy-Authorization", but = according to Sec. 19.4 of bis04, Proxies are NOT allowed to insert = Proxy-Authorization header, unless the request is re-submitted. Hence, = as you've proposed, the Proxy can mimick forking by using a new = branch-id & resubmit the INVITE

2. UAS-->Proxy: 407 (Proxy-Authenticate:...)  =
//if the credentials do not satisfy the UAS, it = sends a new challenge

3. Proxy-->UAS: INVITE (Proxy-Authorization:...) =
// This is also re-submitted as before with new = credentials

4. UAS-->Proxy: 200 OK = (Proxy-Authentication-Info:...)
// For mutual authentication. If the Proxy is okay = with this, it forwards the 200 OK. If not, it issues a new challenge to = the UAS. Q: In the latter case, does the Proxy resubmit the INVITE with = a Proxy-UAS-Authenticate header?

For any new request, the Proxy, if required, can = pre-emptively insert the Proxy-Authorization header for message = authentication purpose & resubmit the request.

5. Proxy-->UAS: (re)INVITE = (Proxy-Authorization:...)
...

Is this call flow valid?

Regards,
Sanjoy




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