From owner-ietf-rtpsec Wed Apr 12 07:01:01 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3CE11bw069514; Wed, 12 Apr 2006 07:01:01 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3CE11jF069513; Wed, 12 Apr 2006 07:01:01 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from mail.covergence.com (mail.convergence.com [63.110.43.12] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3CE0wg4069496 for ; Wed, 12 Apr 2006 07:01:00 -0700 (MST) (envelope-from rporter@covergence.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: Optional SRTP with SDES? Date: Wed, 12 Apr 2006 10:00:48 -0400 Message-ID: <0D1719326D64BD4E9F92A0C120237678C250F5@eserv.covergence.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optional SRTP with SDES? Thread-index: AcZeOX/bd7sK+aTCSNSuUvjV0swddg== From: "Rick Porter" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3CE11g4069508 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This discussion started on the mmusic list (http://www1.ietf.org/mail-archive/web/mmusic/current/msg04091.html), and was moved to this list this list at the request of the mmusic moderator. The original question was: How do you make a call and optionally do SRTP? The responses highlighted that with SDES there is no way to do this without additional INVITEs or mulitpart alternate SDP (which most clients do not yet support). There are other requirements in the SDES draft that also have negative impact on users (e.g. if a voicemail system is configured for SRTP, only SRTP enabled phones could get their voicemail). I know there are other SRTP keying options (e.g. ZRTP, RTP/DTLS, MIKEY, EKT, SDP-DH). I'm aware that each solution has its good and bad points, but I want to focus on the SDES draft since my un-scientific findings are that it is the most widely used. I've been testing with five other SDES/SRTP vendors who all handle things a bit differently. Some are following the SDES draft to the letter, but others have taken a more "user-friendly" approach. I think with a few tweaks, the SDES draft could reflect the behavior with which everyone is moderately happy (and seems to be converging on). Here are my suggestions to the SDES draft: 1) Use the same media stream. No special transport. Crypto is just another "optional" attribute of the media description. When a callee who does not support SDES receives an INVITE with crypto, he can accept the call and does not provide a crypto attribute in the 200/OK/SDP. Then, the caller can choose to CANCEL the call or continue the non-secure call if he does not like the 200/OK/SDP without the crypto attribute. 2) Add an encryption attribute (e.g. "a=encryption="). If the encryption attribute is present, the callee knows whether he can accept the call even if he does not share a common set of crypto algorithms/options with the caller. It could give the callee the chance to reject the call early (e.g. 480) instead of sending the 200/OK (without crypto) and letting the caller reject the call upon receipt of the 200/OK. I do not have a strong preference whether lack of the encryption attribute means that encryption is optional or mandatory. 3) Add notification requirement (suggested by Paul/Alan). It is important to let end-users know if their call is secure (at least on the first hop). Wording may be tricky since network devices (e.g. b2bua, media-gateway) that may terminate SRTP do not have per user/session UI's. In the mmusic discussion, there was concern expressed about a bid-down attack. When using SDES, I would not be concerned with a bid-down attack since anyone with access to the signaling stream has all the key material necessary to decrypt each and every RTP packet. No need to bid it down crypto if you can decrypt the RTP packets anyway. This is a design limitation of SDES. Cheers, Rick From owner-ietf-rtpsec Wed Apr 12 07:14:02 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3CEE118069961; Wed, 12 Apr 2006 07:14:01 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3CEE13M069960; Wed, 12 Apr 2006 07:14:01 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3CEE0vl069952 for ; Wed, 12 Apr 2006 07:14:01 -0700 (MST) (envelope-from csp@csperkins.org) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:57113) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FTg6V-0005Wi-K8; Wed, 12 Apr 2006 15:13:55 +0100 In-Reply-To: <0D1719326D64BD4E9F92A0C120237678C250F5@eserv.covergence.com> References: <0D1719326D64BD4E9F92A0C120237678C250F5@eserv.covergence.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68CA46B2-1D20-4492-B4A5-22A94E357435@csperkins.org> Cc: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: Optional SRTP with SDES? Date: Wed, 12 Apr 2006 15:13:52 +0100 To: Rick Porter X-Mailer: Apple Mail (2.749.3) Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One terminology point: RFC 1889 defines "SDES" to mean RTP source description packets. When talking about SDP extensions defined in draft-ietf-mmusic-sdescriptions-12.txt, please use "sdescriptions" instead, to avoid confusion (since some of the security extensions may involve new RTP/RTCP packet types). Colin On 12 Apr 2006, at 15:00, Rick Porter wrote: > This discussion started on the mmusic list > (http://www1.ietf.org/mail-archive/web/mmusic/current/msg04091.html), > and was moved to this list this list at the request of the mmusic > moderator. > > The original question was: How do you make a call and optionally do > SRTP? > > The responses highlighted that with SDES there is no way to do this > without additional INVITEs or mulitpart alternate SDP (which most > clients do not yet support). There are other requirements in the SDES > draft that also have negative impact on users (e.g. if a voicemail > system is configured for SRTP, only SRTP enabled phones could get > their > voicemail). > > I know there are other SRTP keying options (e.g. ZRTP, RTP/DTLS, > MIKEY, > EKT, SDP-DH). I'm aware that each solution has its good and bad > points, > but I want to focus on the SDES draft since my un-scientific findings > are that it is the most widely used. > > I've been testing with five other SDES/SRTP vendors who all handle > things a bit differently. Some are following the SDES draft to the > letter, but others have taken a more "user-friendly" approach. I think > with a few tweaks, the SDES draft could reflect the behavior with > which > everyone is moderately happy (and seems to be converging on). > > Here are my suggestions to the SDES draft: > > 1) Use the same media stream. No special transport. Crypto is just > another "optional" attribute of the media description. > > When a callee who does not support SDES receives an INVITE with > crypto, > he can accept the call and does not provide a crypto attribute in the > 200/OK/SDP. Then, the caller can choose to CANCEL the call or continue > the non-secure call if he does not like the 200/OK/SDP without the > crypto attribute. > > 2) Add an encryption attribute (e.g. > "a=encryption="). > > If the encryption attribute is present, the callee knows whether he > can > accept the call even if he does not share a common set of crypto > algorithms/options with the caller. It could give the callee the > chance > to reject the call early (e.g. 480) instead of sending the 200/OK > (without crypto) and letting the caller reject the call upon > receipt of > the 200/OK. I do not have a strong preference whether lack of the > encryption attribute means that encryption is optional or mandatory. > > 3) Add notification requirement (suggested by Paul/Alan). > > It is important to let end-users know if their call is secure (at > least > on the first hop). Wording may be tricky since network devices (e.g. > b2bua, media-gateway) that may terminate SRTP do not have per > user/session UI's. > > > In the mmusic discussion, there was concern expressed about a bid-down > attack. When using SDES, I would not be concerned with a bid-down > attack > since anyone with access to the signaling stream has all the key > material necessary to decrypt each and every RTP packet. No need to > bid > it down crypto if you can decrypt the RTP packets anyway. This is a > design limitation of SDES. > > Cheers, > Rick > From owner-ietf-rtpsec Wed Apr 12 11:56:06 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3CIu6aC083208; Wed, 12 Apr 2006 11:56:06 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3CIu6Rf083207; Wed, 12 Apr 2006 11:56:06 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3CIu4rd083198 for ; Wed, 12 Apr 2006 11:56:05 -0700 (MST) (envelope-from mbaugher@cisco.com) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-2.cisco.com with ESMTP; 12 Apr 2006 11:55:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k3CItwRX007327; Wed, 12 Apr 2006 11:55:59 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Apr 2006 11:55:53 -0700 Received: from [128.107.163.218] ([128.107.163.218]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Apr 2006 11:55:53 -0700 In-Reply-To: <68CA46B2-1D20-4492-B4A5-22A94E357435@csperkins.org> References: <0D1719326D64BD4E9F92A0C120237678C250F5@eserv.covergence.com> <68CA46B2-1D20-4492-B4A5-22A94E357435@csperkins.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Rick Porter , From: Mark Baugher Subject: Re: Optional SRTP with SDES? Date: Wed, 12 Apr 2006 11:55:51 -0700 To: Colin Perkins X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 12 Apr 2006 18:55:53.0265 (UTC) FILETIME=[B924F210:01C65E62] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Or "sdesc" if you're into the brevity thing. Mark On Apr 12, 2006, at 7:13 AM, Colin Perkins wrote: > > One terminology point: RFC 1889 defines "SDES" to mean RTP source > description packets. When talking about SDP extensions defined in > draft-ietf-mmusic-sdescriptions-12.txt, please use "sdescriptions" > instead, to avoid confusion (since some of the security extensions may > involve new RTP/RTCP packet types). > > Colin > > > > On 12 Apr 2006, at 15:00, Rick Porter wrote: >> This discussion started on the mmusic list >> (http://www1.ietf.org/mail-archive/web/mmusic/current/msg04091.html), >> and was moved to this list this list at the request of the mmusic >> moderator. >> >> The original question was: How do you make a call and optionally do >> SRTP? >> >> The responses highlighted that with SDES there is no way to do this >> without additional INVITEs or mulitpart alternate SDP (which most >> clients do not yet support). There are other requirements in the SDES >> draft that also have negative impact on users (e.g. if a voicemail >> system is configured for SRTP, only SRTP enabled phones could get >> their >> voicemail). >> >> I know there are other SRTP keying options (e.g. ZRTP, RTP/DTLS, >> MIKEY, >> EKT, SDP-DH). I'm aware that each solution has its good and bad >> points, >> but I want to focus on the SDES draft since my un-scientific findings >> are that it is the most widely used. >> >> I've been testing with five other SDES/SRTP vendors who all handle >> things a bit differently. Some are following the SDES draft to the >> letter, but others have taken a more "user-friendly" approach. I think >> with a few tweaks, the SDES draft could reflect the behavior with >> which >> everyone is moderately happy (and seems to be converging on). >> >> Here are my suggestions to the SDES draft: >> >> 1) Use the same media stream. No special transport. Crypto is just >> another "optional" attribute of the media description. >> >> When a callee who does not support SDES receives an INVITE with >> crypto, >> he can accept the call and does not provide a crypto attribute in the >> 200/OK/SDP. Then, the caller can choose to CANCEL the call or continue >> the non-secure call if he does not like the 200/OK/SDP without the >> crypto attribute. >> >> 2) Add an encryption attribute (e.g. >> "a=encryption="). >> >> If the encryption attribute is present, the callee knows whether he >> can >> accept the call even if he does not share a common set of crypto >> algorithms/options with the caller. It could give the callee the >> chance >> to reject the call early (e.g. 480) instead of sending the 200/OK >> (without crypto) and letting the caller reject the call upon receipt >> of >> the 200/OK. I do not have a strong preference whether lack of the >> encryption attribute means that encryption is optional or mandatory. >> >> 3) Add notification requirement (suggested by Paul/Alan). >> >> It is important to let end-users know if their call is secure (at >> least >> on the first hop). Wording may be tricky since network devices (e.g. >> b2bua, media-gateway) that may terminate SRTP do not have per >> user/session UI's. >> >> >> In the mmusic discussion, there was concern expressed about a bid-down >> attack. When using SDES, I would not be concerned with a bid-down >> attack >> since anyone with access to the signaling stream has all the key >> material necessary to decrypt each and every RTP packet. No need to >> bid >> it down crypto if you can decrypt the RTP packets anyway. This is a >> design limitation of SDES. >> >> Cheers, >> Rick >> > From owner-ietf-rtpsec Thu Apr 13 12:31:43 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3DJVg4P060520; Thu, 13 Apr 2006 12:31:42 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3DJVg0X060519; Thu, 13 Apr 2006 12:31:42 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3DJVgeL060513 for ; Thu, 13 Apr 2006 12:31:42 -0700 (MST) (envelope-from mbaugher@cisco.com) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 13 Apr 2006 12:31:37 -0700 X-IronPort-AV: i="4.04,118,1144047600"; d="scan'208,217"; a="320007976:sNHT47088856" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3DJVah0012219; Thu, 13 Apr 2006 12:31:36 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 12:31:36 -0700 Received: from [192.168.0.10] ([10.21.80.4]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 12:31:35 -0700 In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597054F43E7@stntexch03.cis.neustar.com> References: <24EAE5D4448B9D4592C6D234CBEBD597054F43E7@stntexch03.cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/alternative; boundary=Apple-Mail-2--854229717 Message-Id: <90EA8479-1A39-413E-97F2-1DC6C434404D@cisco.com> Cc: ietf-rtpsec@imc.org From: Mark Baugher Subject: Re: [MMUSIC] Announcement of Real Time Security list Date: Thu, 13 Apr 2006 12:31:34 -0700 To: "Peterson, Jon" X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 13 Apr 2006 19:31:35.0674 (UTC) FILETIME=[E0885DA0:01C65F30] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2--854229717 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Jon, I assume we want this discussion to be on ietf-rtpsec so I changed the distribution. On Apr 12, 2006, at 11:14 AM, Peterson, Jon wrote: > > Following our discussion in the RAI Open Area Meeting in Dallas a > few weeks ago on the many strategies circulating for securing RTP, > we've formed a new mailing list in order to further refine our > understanding of the problem space and figure out a way forward. > > Subscription information for the list is available here. > > I'd like to be clear on one point: I don't think we are going back to considering how to secure RTP. We have a common, interoperable standard in SRTP and a widely-used library in libsrtp. The name "rtpsec" is a bit confusing in this regard. > The agenda item from the RAI Open Meeting, including the list of > associated drafts, is pasted below. Interested parties, please move > discussion of these documents to this list. > > Jon Peterson > NeuStar, Inc. > > ---- > > There are many proposal discussing keying for RTP when used > with SIP. > These issues cross SIPPING, MMUSIC, AVT, and MSEC. I'd say the first thing we need to consider is how or whether we can get a common method of establishing SRTP keys for SIP-established sessions. That would be a good thing, but we have learned that the problem is hard to solve. What's more, solutions tend to unravel either because of wrong assumptions, unexpected problems, or even engineering fashion. > What are the common underling requirements driving these > proposals? I think we're talking about appropriate key establishment, agreement, managed for sessions that are established using SIP. So the common, underlying requirements are security and functional requirements related to SIP and the environments where SIP is deployed. At least, that's what I think needs to be our focus. Dan Wing has a table that captures a subset of these requirements. It's hard to get the table right because each cell of the table references a variety of SIP or telephony functions and various protocol specifications. > At the high level what are the various architectures? > What cross WG architectural level question do we need to answer? > Can we come to consensus on high level approaches we would like to > investigate? I think you said it well in Dallas about the value of beauty contests. We should be looking for something that is good enough in meeting a set of perceived requirements and get behind it. I would not abandon all the other work. If past experience is any predictor, we may not get the right solution on RAI's first attempt. But we need to agree up front that having a single, interoperable solution to the stated problem, however we finally state it, is a goal. Mark > > RFC 3830 (MIKEY) > RFC 3711 (SRTP) > draft-ietf-msec-mikey-rsa-r-02 > draft-ietf-mmusic-sdescriptions-12 > draft-ietf-mmusic-kmgmt-ext-15 > draft-wing-mmusic-sdes-early-media-00 > draft-mcgrew-srtp-ekt-00 > draft-baugher-mmusic-sdp-dh-00 > draft-zimmerman-avt-zrtp-00 > draft-tschofenig-avt-rtp-dtls-00 > draft-fischl-sipping-media-dtls-0 > draft-fischl-mmusic-sdp-dtls-00 > draft-rescorla-tls-partial-00 > draft-modadugu-dtls-short-00 > draft-fries-msec-mikey-applicability-00 > draft-ietf-msec-mikey-dhhmac-11 > draft-lehtovirta-srtp-rcc-01 > draft-saito-mmusic-ipsec-negotiation-req-02 > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic --Apple-Mail-2--854229717 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Jon,
=A0 I assume we want = this discussion to be on ietf-rtpsec so I changed the = distribution.
On Apr 12, 2006, at 11:14 AM, = Peterson, Jon wrote:

=

Following our discussion in = the RAI Open Area Meeting in Dallas a few weeks ago on the many = strategies circulating for securing RTP, we've formed a new mailing list = in order to further refine our understanding of the problem space and = figure out a way forward.

Subscription information for the list is available here. =

<http://www.imc.org/ietf-rtpsec/>


I'd like to be clear on one = point:=A0 I don't think we are going back to considering how to secure = RTP.=A0 We have a common, interoperable standard in SRTP and a = widely-used library in libsrtp.=A0 The name "rtpsec" is a bit confusing = in this regard.

The agenda item from the RAI Open Meeting, = including the list of associated drafts, is pasted below. Interested = parties, please move discussion of these documents to this = list.

Jon = Peterson
NeuStar, = Inc.

---- =

=A0=A0=A0 There are many = proposal discussing keying for RTP when used with SIP.
=A0=A0=A0 These issues cross SIPPING, = MMUSIC, AVT, and MSEC.

I'd say the first = thing we need to consider is how or whether we can get a common method = of establishing SRTP keys for SIP-established sessions.=A0 That would be = a good thing, but we have learned that the problem is hard to solve.=A0 = What's more, solutions tend to unravel either because of wrong = assumptions, unexpected problems, or even engineering = fashion.

Dan Wing has a table that = captures a subset of these requirements.=A0 It's hard to get the table = right because each cell of the table references a variety of SIP or = telephony functions and various protocol specifications.

=A0=A0=A0 At the = high level what are the various architectures?
=A0=A0=A0 What cross WG architectural level = question do we need to answer?
=A0=A0=A0 Can we come to consensus on high level approaches we = would like to
=A0=A0=A0 = investigate?

I think you said it well in Dallas = about the value of beauty contests.=A0 We should be looking for = something that is good enough in meeting a set of perceived requirements = and get behind it.=A0 I would not abandon all the other work.=A0 If past = experience is any predictor, we may not get the right solution on RAI's = first attempt.=A0 But we need to agree up front that having a single, = interoperable solution to the stated problem, however we finally state = it, is a goal.

Mark


=A0=A0=A0=A0=A0=A0=A0 RFC 3830 (MIKEY)
=A0=A0=A0=A0=A0=A0=A0 RFC 3711 (SRTP) =
=A0=A0=A0=A0=A0=A0=A0 = draft-ietf-msec-mikey-rsa-r-02
=A0=A0=A0=A0=A0=A0=A0 draft-ietf-mmusic-sdescriptions-12 =
=A0=A0=A0=A0=A0=A0=A0 = draft-ietf-mmusic-kmgmt-ext-15
=A0=A0=A0=A0=A0=A0=A0 draft-wing-mmusic-sdes-early-media-00 =
=A0=A0=A0=A0=A0=A0=A0 = draft-mcgrew-srtp-ekt-00
=A0=A0=A0=A0=A0=A0=A0 draft-baugher-mmusic-sdp-dh-00 =
=A0=A0=A0=A0=A0=A0=A0 = draft-zimmerman-avt-zrtp-00
=A0=A0=A0=A0=A0=A0=A0 draft-tschofenig-avt-rtp-dtls-00 =
=A0=A0=A0=A0=A0=A0=A0 = draft-fischl-sipping-media-dtls-0
=A0=A0=A0=A0=A0=A0=A0 = draft-fischl-mmusic-sdp-dtls-00
=A0=A0=A0=A0=A0=A0=A0 = draft-rescorla-tls-partial-00
=A0=A0=A0=A0=A0=A0=A0 draft-modadugu-dtls-short-00
=A0=A0=A0=A0=A0=A0=A0 = draft-fries-msec-mikey-applicability-00
=A0=A0=A0=A0=A0=A0=A0 = draft-ietf-msec-mikey-dhhmac-11
=A0=A0=A0=A0=A0=A0=A0 = draft-lehtovirta-srtp-rcc-01
=A0=A0=A0=A0=A0=A0=A0 = draft-saito-mmusic-ipsec-negotiation-req-02

mmusic mailing list
 =

= --Apple-Mail-2--854229717-- From owner-ietf-rtpsec Thu Apr 13 14:19:10 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3DLJAvE066655; Thu, 13 Apr 2006 14:19:10 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3DLJA1i066654; Thu, 13 Apr 2006 14:19:10 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3DLJ8ue066646 for ; Thu, 13 Apr 2006 14:19:09 -0700 (MST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 17:19:29 -0400 To: ietf-rtpsec@imc.org Subject: Re: Optional SRTP with SDES? References: <0D1719326D64BD4E9F92A0C120237678C250F5@eserv.covergence.com> From: Randell Jesup Reply-to: Randell Jesup Date: Thu, 13 Apr 2006 17:20:31 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 13 Apr 2006 21:19:29.0852 (UTC) FILETIME=[F37187C0:01C65F3F] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >1) Use the same media stream. No special transport. Crypto is just >another "optional" attribute of the media description. > >When a callee who does not support SDES receives an INVITE with crypto, >he can accept the call and does not provide a crypto attribute in the >200/OK/SDP. Then, the caller can choose to CANCEL the call or continue >the non-secure call if he does not like the 200/OK/SDP without the >crypto attribute. I generally like this. The person who cares about encryption decides if they insist on it (by rejecting an offer without it, or by not BYEing a 200 OK without encryption after offering it.) >2) Add an encryption attribute (e.g. >"a=encryption="). Minor point: even if the channel is encrypted on TCP, all these wordy options end up pushing offers towards multiple packets. That does NOT help with setup time, and increases the chance of packet loss interfering with call setup. It causes even more of a hit for UDP SIP (though that wouldn't likely use sdescriptions unless it was with end-to-end client certs, etc). >If the encryption attribute is present, the callee knows whether he can >accept the call even if he does not share a common set of crypto >algorithms/options with the caller. It could give the callee the chance >to reject the call early (e.g. 480) instead of sending the 200/OK >(without crypto) and letting the caller reject the call upon receipt of >the 200/OK. I do not have a strong preference whether lack of the >encryption attribute means that encryption is optional or mandatory. I'd suggest lack of attribute mean optional, since the caller can always reject the OK with a BYE. One assumes that normally if the callee can accept with encryption it will, so there's little lost in making that the default. >3) Add notification requirement (suggested by Paul/Alan). > >It is important to let end-users know if their call is secure (at least >on the first hop). Wording may be tricky since network devices (e.g. >b2bua, media-gateway) that may terminate SRTP do not have per >user/session UI's. That's horribly device-dependant. You also want to make it non-spoofable. I would use a SHOULD, and I would suggest that the notification SHOULD be done such that the other end can't spoof it. Phones with UI available (LCD, LEDs, computer screen, etc) can do so easily. As you mention, intermediary devices may ONLY be able to indicate this in-stream, so they may have to do so in a way that can't be spoofed, such as (if you want to be notified of crypto) generating a tone sequence/message at call start for each case (so the other side can't play back a recording of the "Encrypted call" message). >In the mmusic discussion, there was concern expressed about a bid-down >attack. When using SDES, I would not be concerned with a bid-down attack >since anyone with access to the signaling stream has all the key >material necessary to decrypt each and every RTP packet. No need to bid >it down crypto if you can decrypt the RTP packets anyway. This is a >design limitation of SDES. Yup. In a later message: >I'd say the first thing we need to consider is how or whether we can >get a common method of establishing SRTP keys for SIP-established >sessions. That would be a good thing, but we have learned that the >problem is hard to solve. What's more, solutions tend to unravel >either because of wrong assumptions, unexpected problems, or even >engineering fashion. YES! And please don't forget issues of call setup time and robustness. sdescriptions is good in one way - because it assumes a secure channel, it doesn't have to add to call setup time (much). But non-secure channels are pretty common, and to deal with that we need some level of end-to-end security. This is an advantage of ZRTP for example. I'm wondering if there's a way to combine fast-call-setup with slower authentication of the channel. In some uses, you don't want media to flow at all until fully secured, but (ala ZRTP) you may be able to secure the call after startup, or verify it after the startup. For example: Startup with SIPS/sdescriptions (which is vulnerable to MITM/etc attacks at the servers). Once initial crypto is established, start the call using the possibly compromised keys, and start an end-to-end renegotiation of the crypto keys. This could be via ZRTP or an out-of-band, end-to-end (via SIP) rekey. I'm not sure this is a behavior that would be valuable enough though (i.e. reasonably good crypto at start (vulnerable at servers), quickly followed by full end-to-end crypto). The media streams are never in-the-clear, but they are vulnerable at servers (hacked or lawful-intercept) for a second or so. It's never worse than sdescriptions/SIPS, however. A MITM could block the end-to-end renegotiation, but that blocking could be detected. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From owner-ietf-rtpsec Thu Apr 13 14:25:27 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3DLPRwb066953; Thu, 13 Apr 2006 14:25:27 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3DLPRrf066952; Thu, 13 Apr 2006 14:25:27 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3DLPQOs066937 for ; Thu, 13 Apr 2006 14:25:26 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 13 Apr 2006 14:25:19 -0700 X-IronPort-AV: i="4.04,118,1144047600"; d="scan'208"; a="268645426:sNHT33263108" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3DLPJVI010231; Thu, 13 Apr 2006 14:25:19 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 14:25:19 -0700 Received: from [128.107.176.181] ([128.107.176.181]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 14:25:18 -0700 In-Reply-To: <0D1719326D64BD4E9F92A0C120237678C250F5@eserv.covergence.com> References: <0D1719326D64BD4E9F92A0C120237678C250F5@eserv.covergence.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <541FA8D4-56DD-4B27-8C11-27F65DF7D389@cisco.com> Cc: Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: Optional SRTP with SDES? Date: Thu, 13 Apr 2006 14:25:17 -0700 To: Rick Porter X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 13 Apr 2006 21:25:18.0627 (UTC) FILETIME=[C3545F30:01C65F40] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Rick, On Apr 12, 2006, at 7:00 AM, Rick Porter wrote: > > This discussion started on the mmusic list > (http://www1.ietf.org/mail-archive/web/mmusic/current/msg04091.html), > and was moved to this list this list at the request of the mmusic > moderator. > > The original question was: How do you make a call and optionally do > SRTP? > > The responses highlighted that with SDES there is no way to do this > without additional INVITEs or mulitpart alternate SDP (which most > clients do not yet support). There are other requirements in the SDES > draft that also have negative impact on users (e.g. if a voicemail > system is configured for SRTP, only SRTP enabled phones could get > their > voicemail). > > I know there are other SRTP keying options (e.g. ZRTP, RTP/DTLS, > MIKEY, > EKT, SDP-DH). I'm aware that each solution has its good and bad > points, > but I want to focus on the SDES draft since my un-scientific findings > are that it is the most widely used. > > I've been testing with five other SDES/SRTP vendors who all handle > things a bit differently. Some are following the SDES draft to the > letter, but others have taken a more "user-friendly" approach. I think > with a few tweaks, the SDES draft could reflect the behavior with > which > everyone is moderately happy (and seems to be converging on). > > Here are my suggestions to the SDES draft: > > 1) Use the same media stream. No special transport. Crypto is just > another "optional" attribute of the media description. > > When a callee who does not support SDES receives an INVITE with > crypto, > he can accept the call and does not provide a crypto attribute in the > 200/OK/SDP. Then, the caller can choose to CANCEL the call or continue > the non-secure call if he does not like the 200/OK/SDP without the > crypto attribute. If I understand correctly, this would be equivalent to the current methods security-wise in that the offerer could specify both "secure" and "insecure" options, and the answerer would get to choose. But there are deployability advantages to doing it this way, which we definitely want, so it deserves serious consideration IMO. A minor question: with your proposal, if the answerer selected "no encryption", would the media stream use the AVP profile or the SAVP profile with NULL encryption and NULL authentication? > > 2) Add an encryption attribute (e.g. > "a=encryption="). I agree that adding something explicit like this would be good. But I have a nit here: we probably want to choose a term other than "encryption", since SRTP can provide authentication and not encryption (in principle anyway - the sdesc spec doesn't include any cryptosuites that do authentication but not encryption, IIRC). Maybe "a=secure" would be better. > > If the encryption attribute is present, the callee knows whether he > can > accept the call even if he does not share a common set of crypto > algorithms/options with the caller. It could give the callee the > chance > to reject the call early (e.g. 480) instead of sending the 200/OK > (without crypto) and letting the caller reject the call upon > receipt of > the 200/OK. I do not have a strong preference whether lack of the > encryption attribute means that encryption is optional or mandatory. > > 3) Add notification requirement (suggested by Paul/Alan). > > It is important to let end-users know if their call is secure (at > least > on the first hop). Wording may be tricky since network devices (e.g. > b2bua, media-gateway) that may terminate SRTP do not have per > user/session UI's. > > > In the mmusic discussion, there was concern expressed about a bid-down > attack. When using SDES, I would not be concerned with a bid-down > attack > since anyone with access to the signaling stream has all the key > material necessary to decrypt each and every RTP packet. No need to > bid > it down crypto if you can decrypt the RTP packets anyway. This is a > design limitation of SDES. Slightly OT: SDP-DH would remove that limitation, so I guess that we should consider bid-down attacks w.r.t. that protocol. David > > Cheers, > Rick From owner-ietf-rtpsec Thu Apr 13 15:42:14 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3DMgEal071190; Thu, 13 Apr 2006 15:42:14 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3DMgEwN071189; Thu, 13 Apr 2006 15:42:14 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3DMgCWu071174 for ; Thu, 13 Apr 2006 15:42:12 -0700 (MST) (envelope-from mbaugher@cisco.com) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-3.cisco.com with ESMTP; 13 Apr 2006 15:42:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3DMg6w1007985; Thu, 13 Apr 2006 15:42:07 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 15:42:06 -0700 Received: from [192.168.0.10] ([10.21.80.4]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 15:42:06 -0700 In-Reply-To: <541FA8D4-56DD-4B27-8C11-27F65DF7D389@cisco.com> References: <0D1719326D64BD4E9F92A0C120237678C250F5@eserv.covergence.com> <541FA8D4-56DD-4B27-8C11-27F65DF7D389@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Rick Porter , Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: Optional SRTP with SDES? Date: Thu, 13 Apr 2006 15:42:05 -0700 To: David McGrew X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 13 Apr 2006 22:42:06.0377 (UTC) FILETIME=[7DC33990:01C65F4B] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David, A nit below... On Apr 13, 2006, at 2:25 PM, David McGrew wrote: > > Hi Rick, > > On Apr 12, 2006, at 7:00 AM, Rick Porter wrote: > >> >> This discussion started on the mmusic list >> (http://www1.ietf.org/mail-archive/web/mmusic/current/msg04091.html), >> and was moved to this list this list at the request of the mmusic >> moderator. >> >> The original question was: How do you make a call and optionally do >> SRTP? >> >> The responses highlighted that with SDES there is no way to do this >> without additional INVITEs or mulitpart alternate SDP (which most >> clients do not yet support). There are other requirements in the SDES >> draft that also have negative impact on users (e.g. if a voicemail >> system is configured for SRTP, only SRTP enabled phones could get >> their >> voicemail). >> >> I know there are other SRTP keying options (e.g. ZRTP, RTP/DTLS, >> MIKEY, >> EKT, SDP-DH). I'm aware that each solution has its good and bad >> points, >> but I want to focus on the SDES draft since my un-scientific findings >> are that it is the most widely used. >> >> I've been testing with five other SDES/SRTP vendors who all handle >> things a bit differently. Some are following the SDES draft to the >> letter, but others have taken a more "user-friendly" approach. I >> think >> with a few tweaks, the SDES draft could reflect the behavior with >> which >> everyone is moderately happy (and seems to be converging on). >> >> Here are my suggestions to the SDES draft: >> >> 1) Use the same media stream. No special transport. Crypto is just >> another "optional" attribute of the media description. >> >> When a callee who does not support SDES receives an INVITE with >> crypto, >> he can accept the call and does not provide a crypto attribute in the >> 200/OK/SDP. Then, the caller can choose to CANCEL the call or >> continue >> the non-secure call if he does not like the 200/OK/SDP without the >> crypto attribute. > > If I understand correctly, this would be equivalent to the current > methods security-wise in that the offerer could specify both > "secure" and "insecure" options, and the answerer would get to > choose. But there are deployability advantages to doing it this > way, which we definitely want, so it deserves serious consideration > IMO. > > A minor question: with your proposal, if the answerer selected "no > encryption", would the media stream use the AVP profile or the > SAVP profile with NULL encryption and NULL authentication? > >> >> 2) Add an encryption attribute (e.g. >> "a=encryption="). > > I agree that adding something explicit like this would be good. > But I have a nit here: we probably want to choose a term other than > "encryption", since SRTP can provide authentication and not > encryption (in principle anyway - the sdesc spec doesn't include > any cryptosuites that do authentication but not encryption, IIRC). Any sdescriptions crypto suite can signal "unencrypted_srtp", which is effectively SRTP null encryption. Mark > Maybe "a=secure" would be better. > >> >> If the encryption attribute is present, the callee knows whether >> he can >> accept the call even if he does not share a common set of crypto >> algorithms/options with the caller. It could give the callee the >> chance >> to reject the call early (e.g. 480) instead of sending the 200/OK >> (without crypto) and letting the caller reject the call upon >> receipt of >> the 200/OK. I do not have a strong preference whether lack of the >> encryption attribute means that encryption is optional or mandatory. >> >> 3) Add notification requirement (suggested by Paul/Alan). >> >> It is important to let end-users know if their call is secure (at >> least >> on the first hop). Wording may be tricky since network devices (e.g. >> b2bua, media-gateway) that may terminate SRTP do not have per >> user/session UI's. >> >> >> In the mmusic discussion, there was concern expressed about a bid- >> down >> attack. When using SDES, I would not be concerned with a bid-down >> attack >> since anyone with access to the signaling stream has all the key >> material necessary to decrypt each and every RTP packet. No need >> to bid >> it down crypto if you can decrypt the RTP packets anyway. This is a >> design limitation of SDES. > > Slightly OT: SDP-DH would remove that limitation, so I guess that > we should consider bid-down attacks w.r.t. that protocol. > > David > >> >> Cheers, >> Rick From owner-ietf-rtpsec Thu Apr 13 22:05:43 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3E55hcA087901; Thu, 13 Apr 2006 22:05:43 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3E55hsn087900; Thu, 13 Apr 2006 22:05:43 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from acmepacket.com (host10.216.41.24.conversent.net [216.41.24.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3E55fF1087893 for ; Thu, 13 Apr 2006 22:05:42 -0700 (MST) (envelope-from HKaplan@acmepacket.com) Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id AD9E0658; Fri, 14 Apr 2006 01:05:34 -0400 From: "Hadriel Kaplan" To: "'Randell Jesup'" , Subject: RE: Optional SRTP with SDES? Date: Fri, 14 Apr 2006 01:05:44 -0400 Message-ID: <038d01c65f81$161b8500$0a01a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZfP/hMqOh33DsXTd+aOJvz5QrGDgAPidqQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Randell, This discussion seems all too familiar. ;) Comments inline... > -----Original Message----- > From: owner-ietf-rtpsec@mail.imc.org [mailto:owner-ietf- > rtpsec@mail.imc.org] On Behalf Of Randell Jesup > > I generally like this. The person who cares about encryption decides if > they insist on it (by rejecting an offer without it, or by not BYEing a > 200 OK without encryption after offering it.) I like that model as well. > I'd suggest lack of attribute mean optional, since the caller can always > reject the OK with a BYE. One assumes that normally if the callee can > accept with encryption it will, so there's little lost in making that > the default. Agree. > I'm not sure this is a behavior that would be valuable enough though (i.e. > reasonably good crypto at start (vulnerable at servers), quickly followed > by full end-to-end crypto). The media streams are never in-the-clear, but > they are vulnerable at servers (hacked or lawful-intercept) for a second > or > so. It's never worse than sdescriptions/SIPS, however. A MITM could > block > the end-to-end renegotiation, but that blocking could be detected. It would only be "detected" if both ends knew they should be able to do zrtp. A MITM could remove any sdp parameters indicating support for zrtp, and block the zrtp hello message. So unless both users said "Hey, I have a zrtp phone why didn't the zrtp icon show up?", the UA application would just assume the other end didn't do zrtp and no one would be the wiser. Of course you're right it's no worse than sdesc/sips alone, but it's worse than doing it only and not also starting with sdesc/sips (for some people). -hadriel From owner-ietf-rtpsec Fri Apr 14 06:02:12 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3ED2CAm011337; Fri, 14 Apr 2006 06:02:12 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3ED2CYR011336; Fri, 14 Apr 2006 06:02:12 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from mail.covergence.com (mail.convergence.com [63.110.43.12] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3ED2A8c011330 for ; Fri, 14 Apr 2006 06:02:11 -0700 (MST) (envelope-from rporter@covergence.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Optional SRTP with SDES? Date: Fri, 14 Apr 2006 09:01:55 -0400 Message-ID: <0D1719326D64BD4E9F92A0C120237678C25508@eserv.covergence.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optional SRTP with SDES? Thread-index: AcZfQC50ub5M3KRxSDeNNwEKhHRSgwAfaKDA From: "Rick Porter" To: "Randell Jesup" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3ED2B8c011331 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Randell, Thanks for the comments. > >>2) Add an encryption attribute (e.g. >>"a=encryption="). > >Minor point: even if the channel is encrypted on TCP, all these wordy >options end up pushing offers towards multiple packets. That does NOT help >with setup time, and increases the chance of packet loss interfering with >call setup. It causes even more of a hit for UDP SIP (though that wouldn't >likely use sdescriptions unless it was with end-to-end client certs, etc). Brevity is good. I suggested the "encryption" name, since Snom, Asterisk, and others currently use that attribute name in essentially that manner. >I'd suggest lack of attribute mean optional, since the caller can always >reject the OK with a BYE. One assumes that normally if the callee can >accept with encryption it will, so there's little lost in making that >the default. Sounds good to me. > >>3) Add notification requirement (suggested by Paul/Alan). >> >That's horribly device-dependant. You also want to make it non-spoofable. >I would use a SHOULD, and I would suggest that the notification SHOULD be >done such that the other end can't spoof it. Phones with UI available >(LCD, LEDs, computer screen, etc) can do so easily. As you mention, >intermediary devices may ONLY be able to indicate this in-stream, so they >may have to do so in a way that can't be spoofed, such as (if you want to >be notified of crypto) generating a tone sequence/message at call start for >each case (so the other side can't play back a recording of the "Encrypted >call" message). It is device dependant. I don't have a strong feeling whether it is a SHOULD or a MUST--good implementations will do the best notification they are capable of. You need to be careful about inserting tone--for example, you would not want the tone going the non-secure PSTN. However, it is probably the best way to let an end-user know (since SIP TA's go to an analog phone without a nice UI). >In a later message: >>I'd say the first thing we need to consider is how or whether we can >>get a common method of establishing SRTP keys for SIP-established >>sessions. That would be a good thing, but we have learned that the >>problem is hard to solve. What's more, solutions tend to unravel >>either because of wrong assumptions, unexpected problems, or even >>engineering fashion. I think there is room for improvement wrt many RTP security issues. I was trying to limit the scope to something we could agree on before too many SRTP implementations "hit the street." Thanks again, Rick From owner-ietf-rtpsec Fri Apr 14 06:14:05 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3EDE5Ur011628; Fri, 14 Apr 2006 06:14:05 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3EDE4TS011627; Fri, 14 Apr 2006 06:14:04 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from mail.covergence.com (mail.convergence.com [63.110.43.12] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3EDE3ZZ011600 for ; Fri, 14 Apr 2006 06:14:04 -0700 (MST) (envelope-from rporter@covergence.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Optional SRTP with SDES? Date: Fri, 14 Apr 2006 09:13:57 -0400 Message-ID: <0D1719326D64BD4E9F92A0C120237678C2551D@eserv.covergence.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optional SRTP with SDES? Thread-index: AcZfQMRXVk7iUFFWQde3dEuH1/N4pgAgAlvw From: "Rick Porter" To: "David McGrew" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3EDE4ZZ011622 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi David, Thanks for the comments. >> 1) Use the same media stream. No special transport. Crypto is just >> another "optional" attribute of the media description. > >A minor question: with your proposal, if the answerer selected "no >encryption", would the media stream use the AVP profile or the SAVP >profile with NULL encryption and NULL authentication? I am suggesting one media stream with AVP as the transport, regardless of whether sdescriptions (or potentially other cryptographic/secure methods) are identified in the SDP. I know this disagrees with RFC-3711 Section 12 (IANA Considerations), but IMO it is the most expeditious/practical way forward. >> 2) Add an encryption attribute (e.g. >> "a=encryption="). > >I agree that adding something explicit like this would be good. But >I have a nit here: we probably want to choose a term other than >"encryption", since SRTP can provide authentication and not >encryption (in principle anyway - the sdesc spec doesn't include any >cryptosuites that do authentication but not encryption, IIRC). Maybe >"a=secure" would be better. I'm open to name suggestions, but Snom, Asterisk, and others already use the "encryption" attribute in essentially this manner. > >Slightly OT: SDP-DH would remove that limitation, so I guess that we >should consider bid-down attacks w.r.t. that protocol. > Agree. Each key exchange method has its own strengths and weaknesses, and I don't think you're going to find a one-size-fits-all solution. The slides presented at the last IETF meeting had a good quick comparison. Cheers, Rick From owner-ietf-rtpsec Fri Apr 14 07:16:34 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3EEGYDQ015044; Fri, 14 Apr 2006 07:16:34 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3EEGYXb015043; Fri, 14 Apr 2006 07:16:34 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3EEGXOO015036 for ; Fri, 14 Apr 2006 07:16:33 -0700 (MST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 10:16:54 -0400 To: "Hadriel Kaplan" Cc: Subject: Re: Optional SRTP with SDES? References: <038d01c65f81$161b8500$0a01a8c0@acmepacket.com> From: Randell Jesup Reply-to: Randell Jesup Date: Fri, 14 Apr 2006 10:17:57 -0400 In-Reply-To: <038d01c65f81$161b8500$0a01a8c0@acmepacket.com> (Hadriel Kaplan's message of "Fri, 14 Apr 2006 01:05:44 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 14 Apr 2006 14:16:54.0728 (UTC) FILETIME=[15066480:01C65FCE] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Hadriel Kaplan" writes: >This discussion seems all too familiar. ;) :-) >> I'm not sure this is a behavior that would be valuable enough though >> (i.e. reasonably good crypto at start (vulnerable at servers), quickly >> followed by full end-to-end crypto). The media streams are never >> in-the-clear, but they are vulnerable at servers (hacked or >> lawful-intercept) for a second or so. It's never worse than >> sdescriptions/SIPS, however. A MITM could block the end-to-end >> renegotiation, but that blocking could be detected. > >It would only be "detected" if both ends knew they should be able to do >zrtp. A MITM could remove any sdp parameters indicating support for zrtp, >and block the zrtp hello message. So unless both users said "Hey, I have a >zrtp phone why didn't the zrtp icon show up?", the UA application would just >assume the other end didn't do zrtp and no one would be the wiser. True - though if you've called that UA before and done zrtp, it could warn you that ZRTP appears to be blocked. >Of course you're right it's no worse than sdesc/sips alone, but it's worse >than doing it only and not also starting with sdesc/sips (for some people). Actually, it's no worse than ZRTP alone either - straight ZRTP can be blocked in the exact same way. ZRTP added to SIPS/sdescriptions give you a way (in some but not all cases) to infer that a supposedly-secure SIPS connection has been compromised, and (if not blocked) fully secure the media without a large call-answer-time hit - plus greater overall compatibility (such a device would work in pure-SIPS/sdescriptions and pure-ZRTP as well). Downside is increased complexity (both technically and in explaining it to users) and that the first few seconds of a call would only be secured by SIPS/sdescriptions. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From owner-ietf-rtpsec Fri Apr 14 12:39:09 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3EJd8SG029914; Fri, 14 Apr 2006 12:39:08 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3EJd8KA029913; Fri, 14 Apr 2006 12:39:08 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from acmepacket.com (host10.216.41.24.conversent.net [216.41.24.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3EJd5Kk029907 for ; Fri, 14 Apr 2006 12:39:08 -0700 (MST) (envelope-from HKaplan@acmepacket.com) Received: from HKaplan [10.0.200.145] by acmepacket.com with ESMTP (SMTPD-9.02) id AA53061C; Fri, 14 Apr 2006 15:38:59 -0400 From: "Hadriel Kaplan" To: "'Randell Jesup'" Cc: Subject: RE: Optional SRTP with SDES? Date: Fri, 14 Apr 2006 15:39:07 -0400 Message-ID: <008a01c65ffb$189b0380$91c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZfzgd6DN/ZfwrXQqCQIag2tXmLIwAG4VJg In-Reply-To: Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > > >Of course you're right it's no worse than sdesc/sips alone, but it's > worse > >than doing it only and not also starting with sdesc/sips (for some > people). > > Actually, it's no worse than ZRTP alone either - straight ZRTP can be > blocked in the exact same way. ZRTP added to SIPS/sdescriptions give you > a > way (in some but not all cases) to infer that a supposedly-secure SIPS > connection has been compromised, and (if not blocked) fully secure the > media without a large call-answer-time hit - plus greater overall > compatibility (such a device would work in pure-SIPS/sdescriptions and > pure-ZRTP as well). Downside is increased complexity (both technically > and > in explaining it to users) and that the first few seconds of a call would > only be secured by SIPS/sdescriptions. Ahh, no I meant trying to do ZRTP checking in the media-plane without also trying to do SRTP via sdesc/sips (ie, no zrtp) would be worse. Whereas I now think you mean doing ZRTP checking in the media alone is no worse than also doing zrtp offers in sdesc? In other words I think there's a value in starting with SRTP via sdesc/sips, and also offering zrtp in sdp, and then trying zrtp afterwards in the media-path. I'm curious if active ZRTP checking - using an RTP extension header for hello message even if signaling didn't say the other end supported zrtp - is totally safe to do with all the RTP implementations out there? By "safe" I mean won't end the call due to unsupported extension or some other error. (I'm speaking from a real-world perspective question of implementations, not standards compliance) -hadriel From owner-ietf-rtpsec Fri Apr 14 15:07:45 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3EM7jLT036181; Fri, 14 Apr 2006 15:07:45 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3EM7jk0036180; Fri, 14 Apr 2006 15:07:45 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3EM7h9S036172 for ; Fri, 14 Apr 2006 15:07:44 -0700 (MST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 18:08:05 -0400 To: "Hadriel Kaplan" Cc: Subject: Re: Optional SRTP with SDES? References: <008a01c65ffb$189b0380$91c8000a@acmepacket.com> From: Randell Jesup Reply-to: Randell Jesup Date: Fri, 14 Apr 2006 18:09:09 -0400 In-Reply-To: <008a01c65ffb$189b0380$91c8000a@acmepacket.com> (Hadriel Kaplan's message of "Fri, 14 Apr 2006 15:39:07 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 14 Apr 2006 22:08:05.0123 (UTC) FILETIME=[E77E5530:01C6600F] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Hadriel Kaplan" writes: >In other words I think there's a value in starting with SRTP via sdesc/sips, >and also offering zrtp in sdp, and then trying zrtp afterwards in the >media-path. I was analyzing SIPS/sdesc plus ZRTP in the media plane. >I'm curious if active ZRTP checking - using an RTP extension header for >hello message even if signaling didn't say the other end supported zrtp - is >totally safe to do with all the RTP implementations out there? By "safe" I >mean won't end the call due to unsupported extension or some other error. >(I'm speaking from a real-world perspective question of implementations, not >standards compliance) Safe? Probably not totally - how many implementations actually tested their extension-handling code? Though I suspect most (not all) RTP implementations will at least ignore it properly. And it breaks anything relying on using header extensions (if you try to handle it outside the application generating the RTP with header extensions). People in the AVT mailing list are discussing creating an extensible header extension mechanism (so for example you could use ZRTP header extensions plus an SMPTE timestamp header extension, etc. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From owner-ietf-rtpsec Fri Apr 14 18:32:21 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3F1WL4Y045588; Fri, 14 Apr 2006 18:32:21 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3F1WLGS045587; Fri, 14 Apr 2006 18:32:21 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from outbound.mailhop.org (mailnull@outbound.mailhop.org [63.208.196.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3F1WLhS045581 for ; Fri, 14 Apr 2006 18:32:21 -0700 (MST) (envelope-from alan@sipstation.com) Received: from 71-81-78-136.dhcp.stls.mo.charter.com ([71.81.78.136] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FUZe8-0002HB-Qo for ietf-rtpsec@imc.org; Fri, 14 Apr 2006 21:32:20 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.81.78.136 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <44404D23.2070105@sipstation.com> Date: Fri, 14 Apr 2006 20:32:19 -0500 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-rtpsec@imc.org Subject: Re: Optional SRTP with SDES? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As for how safe ZRTP is with normal RTP extensions, I will let you know after next week's testing at SIPit is complete ;-) Implementations should handle unknown header extensions properly anyway, so perhaps ZRTP will help find some bugs... Thanks, Alan From owner-ietf-rtpsec Fri Apr 14 18:45:22 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3F1jM8N045997; Fri, 14 Apr 2006 18:45:22 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3F1jMuQ045996; Fri, 14 Apr 2006 18:45:22 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from outbound.mailhop.org (mailnull@outbound.mailhop.org [63.208.196.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3F1jM5U045990 for ; Fri, 14 Apr 2006 18:45:22 -0700 (MST) (envelope-from alan@sipstation.com) Received: from 71-81-78-136.dhcp.stls.mo.charter.com ([71.81.78.136] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FUZqj-0004GZ-Q5 for ietf-rtpsec@imc.org; Fri, 14 Apr 2006 21:45:21 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.81.78.136 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <44405030.1010901@sipstation.com> Date: Fri, 14 Apr 2006 20:45:20 -0500 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-rtpsec@imc.org Subject: Requirements, First Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Before we jump into mechanisms and comparing approaches, lets first discuss the requirements. Here's my opinion. Currently, we have standardized a number of ways to key SRTP. They all involve using a signaling channel (SIP) or another protocol (MIKEY). Each method works in some set of circumstances. However, none of them work in all the scenarios and implementors have inidicated that they are not happy with any of them. In this work, we are looking for a single (1) method to key SRTP which works under the following conditions: - unicast (if it works with multicast as well, that's great, but requiring this one method to also work with multicast will fail for sure). - forking (copies of signaling may be sent to multiple devices, and a single request may result in multiple sessions being established. There can be no key sharing between these sessions) - early media (there can be no media clipping of the initial media packets sent by the answering party i.e. the "Hello". Note that this "Hello" will in most cases arrive before any associated signaling from the answering party) - no requirement for PKI and certificates issued by a public CA. I'd like to hear other's opinions on the requirements of this work. This single method would be then be a *the* standard way of keying SRTP. Implementations are of course free to choose and support additional methods which might be optimized for one particular environment, but they still must support and offer this single standard way. Thanks, Alan From owner-ietf-rtpsec Fri Apr 14 18:58:34 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3F1wYv4046457; Fri, 14 Apr 2006 18:58:34 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3F1wYI1046456; Fri, 14 Apr 2006 18:58:34 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from acmepacket.com (host10.216.41.24.conversent.net [216.41.24.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3F1wX4s046450 for ; Fri, 14 Apr 2006 18:58:34 -0700 (MST) (envelope-from HKaplan@acmepacket.com) Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A3440668; Fri, 14 Apr 2006 21:58:28 -0400 From: "Hadriel Kaplan" To: "'Alan Johnston'" , Subject: RE: Requirements, First Date: Fri, 14 Apr 2006 21:58:37 -0400 Message-ID: <00b301c66030$1c834720$91c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZgLk6YhNUeMXfCSKSFb9+ocQdVzwAAETLA In-Reply-To: <44405030.1010901@sipstation.com> Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Excellent topic. I was wondering if we were trying to come up with a base/default key-exchange method, or a base/default way of cleanly negotiating (offering/choosing) a key exchange method. By clean I mean in one offer/answer exchange each UA knows what to do next (e.g., do zrtp, or just send srtp). In other words, which of the following is the type of "choice" we're making? 1) Choose one member of set A: {MIKEY flavors, SDES, SDES-EM, EKT, SDP-DH, ZRTP, DTLS} 2) Choose one member of set B: {SDP negotiation for all/any of set A, media negotiation (ZRTP/DTLS)}; and if SDP is chosen then fix it to negotiate cleanly as much as possible. 3) Choose one clean way to do both members of B and document it. I prefer 1, but I'm not sure that's possible/realistic in this forum. So I'm guessing we'll end up doing 3. I am guessing by your email you prefer 1 as well? -hadriel > -----Original Message----- > From: owner-ietf-rtpsec@mail.imc.org [mailto:owner-ietf- > rtpsec@mail.imc.org] On Behalf Of Alan Johnston > Sent: Friday, April 14, 2006 9:45 PM > To: ietf-rtpsec@imc.org > Subject: Requirements, First > > > Before we jump into mechanisms and comparing approaches, lets first > discuss the requirements. Here's my opinion. > > Currently, we have standardized a number of ways to key SRTP. They all > involve using a signaling channel (SIP) or another protocol (MIKEY). > Each method works in some set of circumstances. However, none of them > work in all the scenarios and implementors have inidicated that they are > not happy with any of them. > > In this work, we are looking for a single (1) method to key SRTP which > works under the following conditions: > > - unicast (if it works with multicast as well, that's great, but > requiring this one method to also work with multicast will fail for sure). > > - forking (copies of signaling may be sent to multiple devices, and a > single request may result in multiple sessions being established. There > can be no key sharing between these sessions) > > - early media (there can be no media clipping of the initial media > packets sent by the answering party i.e. the "Hello". Note that this > "Hello" will in most cases arrive before any associated signaling from > the answering party) > > - no requirement for PKI and certificates issued by a public CA. > > I'd like to hear other's opinions on the requirements of this work. > > This single method would be then be a *the* standard way of keying > SRTP. Implementations are of course free to choose and support > additional methods which might be optimized for one particular > environment, but they still must support and offer this single standard > way. > > Thanks, > Alan From owner-ietf-rtpsec Fri Apr 14 20:01:51 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3F31ok1048765; Fri, 14 Apr 2006 20:01:50 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3F31o7I048764; Fri, 14 Apr 2006 20:01:50 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3F31oRF048756 for ; Fri, 14 Apr 2006 20:01:50 -0700 (MST) (envelope-from ldondeti@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3F31inA008852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Apr 2006 20:01:44 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-69-5.qualcomm.com [10.50.69.5]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3F31elg003689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Apr 2006 20:01:43 -0700 (PDT) Message-Id: <6.2.5.6.2.20060414194945.03b9e118@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Apr 2006 20:01:41 -0700 To: Alan Johnston , ietf-rtpsec@imc.org From: Lakshminath Dondeti Subject: Re: Requirements, First In-Reply-To: <44405030.1010901@sipstation.com> References: <44405030.1010901@sipstation.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Alan, I think the reqs exercise is in fact the right way to go. I hope this can be quick though! At 06:45 PM 4/14/2006, Alan Johnston wrote: >Before we jump into mechanisms and comparing approaches, lets first >discuss the requirements. Here's my opinion. > >Currently, we have standardized a number of ways to key SRTP. They >all involve using a signaling channel (SIP) or another protocol (MIKEY). >Each method works in some set of circumstances. However, none of >them work in all the scenarios and implementors have inidicated that >they are not happy with any of them. > >In this work, we are looking for a single (1) method to key SRTP >which works under the following conditions: > >- unicast (if it works with multicast as well, that's great, but >requiring this one method to also work with multicast will fail for sure). I think "the" method should keep in mind group keying requirements, and at the very least should have an evolutionary path toward support of group communication. I have some ideas around this, but going into those details would mean reaching into the solution space. >- forking (copies of signaling may be sent to multiple devices, and >a single request may result in multiple sessions being >established. There can be no key sharing between these sessions) > >- early media (there can be no media clipping of the initial media >packets sent by the answering party i.e. the "Hello". Note that >this "Hello" will in most cases arrive before any associated >signaling from the answering party) Are early media security requirements different from "general" media security requirements. For instance is integrity protection more important for early media than confidentiality. I don't know. Just asking the question to understand. Some additional things to think about are as follows: Are each of the following "required", "important" or "nice to have"? 1. authentication mode negotiation or multiple authentication mode support 2. Identity protection (initiator or responder) 3. algorithm agility 4. crypto context negotiation/establishment for multiple streams 5. group keying support 6. extensibility 7. version support ... regards, Lakshminath >- no requirement for PKI and certificates issued by a public CA. > >I'd like to hear other's opinions on the requirements of this work. > >This single method would be then be a *the* standard way of keying >SRTP. Implementations are of course free to choose and support >additional methods which might be optimized for one particular >environment, but they still must support and offer this single standard way. > >Thanks, >Alan From owner-ietf-rtpsec Fri Apr 14 21:40:01 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3F4e1pp053708; Fri, 14 Apr 2006 21:40:01 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3F4e1Sv053707; Fri, 14 Apr 2006 21:40:01 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3F4e0wS053689 for ; Fri, 14 Apr 2006 21:40:00 -0700 (MST) (envelope-from mbaugher@cisco.com) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 14 Apr 2006 21:39:55 -0700 X-IronPort-AV: i="4.04,121,1144047600"; d="scan'208"; a="268923278:sNHT37855026" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3F4dsYg029351; Fri, 14 Apr 2006 21:39:55 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Apr 2006 21:39:54 -0700 Received: from [192.168.0.10] ([10.21.114.167]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Apr 2006 21:39:54 -0700 In-Reply-To: <44405030.1010901@sipstation.com> References: <44405030.1010901@sipstation.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <35337CB5-56C9-4304-9CB1-4A2DC0A2D50D@cisco.com> Cc: ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: Requirements, First Date: Fri, 14 Apr 2006 21:39:51 -0700 To: Alan Johnston X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 15 Apr 2006 04:39:54.0388 (UTC) FILETIME=[A41B7D40:01C66046] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan, On Apr 14, 2006, at 6:45 PM, Alan Johnston wrote: > > Before we jump into mechanisms and comparing approaches, lets first > discuss the requirements. Here's my opinion. > > Currently, we have standardized a number of ways to key SRTP. They > all involve using a signaling channel (SIP) or another protocol > (MIKEY). Each method works in some set of circumstances. However, > none of them work in all the scenarios and implementors have > inidicated that they are not happy with any of them. > > In this work, we are looking for a single (1) method to key SRTP > which works under the following conditions: I believe that you have just articulated a non-requirement for this work. We should not be looking for a single way to key SRTP in my opinion because there is no single way to do that. We might have some success in looking for a single way to key SRTP for SIP applications, or maybe for general telephony applications, but SRTP is too broad for their to be a single key management scheme for all types of multicast applications, including unidirectional broadcast, group key applications with revocation algorithms that have logarithmic complexity, small groups, large groups, pairwise unicast, multi-unicast sessions. The fact is, that we have not been able to do it for SIP, let alone for the great variety of applications that use RTP and can benefit from SRTP. > > - unicast (if it works with multicast as well, that's great, but > requiring this one method to also work with multicast will fail for > sure). I agree. Thus, we are obviously not concerned with key agreement or key establishment for SRTP in general, right? > > - forking (copies of signaling may be sent to multiple devices, and > a single request may result in multiple sessions being > established. There can be no key sharing between these sessions) > > - early media (there can be no media clipping of the initial media > packets sent by the answering party i.e. the "Hello". Note that > this "Hello" will in most cases arrive before any associated > signaling from the answering party) > > - no requirement for PKI and certificates issued by a public CA. > > I'd like to hear other's opinions on the requirements of this work. What you have listed above are the latest issues that have arisen in SIP signaling of SRTP sessions. This is a fine start along the lines that Dan Wing presented at the RAI area meeting. There are some additional requirements that need to be considered, such as RTP mixers and translators. I think the list will become long and that we will have a lot to consider when comparing the applicability of MIKEY, sdesc, DTLS, zRTP, EKT, SDP-DH, and the other methods. There is also the question of how sessions are authorized. Is the fingerprint method all that there is? What about third parties? These are not required, but will they be supported? Does SIP identity have a role to play? The first thing I'd like to understand is applicability: We need to constrain and demarcate the problem that we are addressing in this group. For starters, yesterday I asked about the name "rtpsec", which might lead to one to believe that we are trying to find the best way to secure RTP. I don't think that we will start by considering how to secure RTP flows at this point but instead focus on the best way to agree, establish, and/or agree upon keys for SRTP for IP telephony applications. > > This single method would be then be a *the* standard way of keying > SRTP. Ah, you just said that we're not considering multicast so it's clear that you're talking about one standard way to key SRTP *for a particular application or set of applications*. I think you're considering IP telephony and not all SRTP applications. > Implementations are of course free to choose and support additional > methods which might be optimized for one particular environment, > but they still must support and offer this single standard way. I'm not sure what "must" means here. There is no way to mandate whatever this group develops for all SRTP applications. Maybe it might be done for SIP or some specific signaling protocols that can mandate a specific key method be used. RFC 3711 does not because the application demands for keying SRTP vary so much. Mark > > Thanks, > Alan From owner-ietf-rtpsec Fri Apr 14 21:48:23 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3F4mNOS053999; Fri, 14 Apr 2006 21:48:23 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3F4mNcc053998; Fri, 14 Apr 2006 21:48:23 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3F4mM4O053979 for ; Fri, 14 Apr 2006 21:48:22 -0700 (MST) (envelope-from mbaugher@cisco.com) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 14 Apr 2006 21:48:18 -0700 X-IronPort-AV: i="4.04,121,1144047600"; d="scan'208"; a="1795300482:sNHT31743034" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3F4mHYg001109; Fri, 14 Apr 2006 21:48:17 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Apr 2006 21:48:17 -0700 Received: from [192.168.0.10] ([10.21.114.167]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Apr 2006 21:48:16 -0700 In-Reply-To: <6.2.5.6.2.20060414194945.03b9e118@qualcomm.com> References: <44405030.1010901@sipstation.com> <6.2.5.6.2.20060414194945.03b9e118@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1191FC98-8CD4-43E8-9545-1AC7453013D5@cisco.com> Cc: Alan Johnston , ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: Requirements, First Date: Fri, 14 Apr 2006 21:48:13 -0700 To: Lakshminath Dondeti X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 15 Apr 2006 04:48:16.0591 (UTC) FILETIME=[CF7195F0:01C66047] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Lakshminath, I expect that if we are going to try and invent a general-purpose key management for SRTP, then we are going to reinvent something like ISAKMP, which is a very general framework that provides a mechanism for specializing the key management system for specific applications, e.g. a DOI. It is one thing to develop key management for, say, IPTV broadcast to thousands of recipients. This system won't share much in common with a system that keys SRTP for point-to-point telephony. Video server applications may have yet another set of needs. I don't believe that there is an evolutionary path to establish one method for keying all the types of applications that might establish keys for SRTP. We need to narrow our focus. If this group could agree upon a way to key SIP SRTP sessions, we will have accomplished a lot. Mark On Apr 14, 2006, at 8:01 PM, Lakshminath Dondeti wrote: > > Hi Alan, > > I think the reqs exercise is in fact the right way to go. I hope > this can be quick though! > > At 06:45 PM 4/14/2006, Alan Johnston wrote: > >> Before we jump into mechanisms and comparing approaches, lets >> first discuss the requirements. Here's my opinion. >> >> Currently, we have standardized a number of ways to key SRTP. >> They all involve using a signaling channel (SIP) or another >> protocol (MIKEY). >> Each method works in some set of circumstances. However, none of >> them work in all the scenarios and implementors have inidicated >> that they are not happy with any of them. >> >> In this work, we are looking for a single (1) method to key SRTP >> which works under the following conditions: >> >> - unicast (if it works with multicast as well, that's great, but >> requiring this one method to also work with multicast will fail >> for sure). > > I think "the" method should keep in mind group keying requirements, > and at the very least should have an evolutionary path toward > support of group communication. I have some ideas around this, but > going into those details would mean reaching into the solution space. > > >> - forking (copies of signaling may be sent to multiple devices, >> and a single request may result in multiple sessions being >> established. There can be no key sharing between these sessions) >> >> - early media (there can be no media clipping of the initial media >> packets sent by the answering party i.e. the "Hello". Note that >> this "Hello" will in most cases arrive before any associated >> signaling from the answering party) > > Are early media security requirements different from "general" > media security requirements. For instance is integrity protection > more important for early media than confidentiality. I don't > know. Just asking the question to understand. > > Some additional things to think about are as follows: > > Are each of the following "required", "important" or "nice to have"? > > 1. authentication mode negotiation or multiple authentication mode > support > 2. Identity protection (initiator or responder) > 3. algorithm agility > 4. crypto context negotiation/establishment for multiple streams > 5. group keying support > 6. extensibility > 7. version support > ... > regards, > Lakshminath > > > >> - no requirement for PKI and certificates issued by a public CA. >> >> I'd like to hear other's opinions on the requirements of this work. >> >> This single method would be then be a *the* standard way of keying >> SRTP. Implementations are of course free to choose and support >> additional methods which might be optimized for one particular >> environment, but they still must support and offer this single >> standard way. >> >> Thanks, >> Alan From owner-ietf-rtpsec Sat Apr 15 06:23:45 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FDNiF1075303; Sat, 15 Apr 2006 06:23:45 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3FDNi59075302; Sat, 15 Apr 2006 06:23:44 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from outbound.mailhop.org (mailnull@outbound.mailhop.org [63.208.196.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FDNiht075296 for ; Sat, 15 Apr 2006 06:23:44 -0700 (MST) (envelope-from alan@sipstation.com) Received: from 71-81-78-136.dhcp.stls.mo.charter.com ([71.81.78.136] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FUkkZ-000EHh-BK; Sat, 15 Apr 2006 09:23:43 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.81.78.136 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <4440F3DE.8060401@sipstation.com> Date: Sat, 15 Apr 2006 08:23:42 -0500 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher CC: ietf-rtpsec@imc.org Subject: Re: Requirements, First References: <44405030.1010901@sipstation.com> <35337CB5-56C9-4304-9CB1-4A2DC0A2D50D@cisco.com> In-Reply-To: <35337CB5-56C9-4304-9CB1-4A2DC0A2D50D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mark, Underlying every requirement in my list is the application of establishing secure point to point sessions between arbitrary Internet endpoints, i.e. VoIP. Clearly we are talking about a single application on this list. VoIP or general multimedia sessions is the application here - it is the one that has a strong need for SRTP which is currently not being met. 3GPP is also following this work, and if we fail to solve this problem I'm sure they will step in and do our work for us. I don't limit this to just SIP, however, as, unfortunately, the whole world does not use SIP. I believe these requirements are moving us towards the one keying method we have not tried yet - inband keying. With inband keying, we will be able to establish a secure session even between endpoints which don't use a common signaling protocol (i.e. they could use H.323, Jingle, Skinny, etc.) If we did this, the IETF would be doing an immense service to the real time communications industry by providing useful, deployable security. In terms of SIP, anything we design here has to co-exist with current implementations. This means we can require any special extensions to SIP or support of new features such as multipart alternative. Essentially, what we come up with must work with vanilla RFC 3261 SIP. Thanks, Alan Mark Baugher wrote: > Alan, > > On Apr 14, 2006, at 6:45 PM, Alan Johnston wrote: > >> >> Before we jump into mechanisms and comparing approaches, lets first >> discuss the requirements. Here's my opinion. >> >> Currently, we have standardized a number of ways to key SRTP. They >> all involve using a signaling channel (SIP) or another protocol >> (MIKEY). Each method works in some set of circumstances. However, >> none of them work in all the scenarios and implementors have >> inidicated that they are not happy with any of them. >> >> In this work, we are looking for a single (1) method to key SRTP >> which works under the following conditions: > > > I believe that you have just articulated a non-requirement for this > work. We should not be looking for a single way to key SRTP in my > opinion because there is no single way to do that. We might have > some success in looking for a single way to key SRTP for SIP > applications, or maybe for general telephony applications, but SRTP > is too broad for their to be a single key management scheme for all > types of multicast applications, including unidirectional broadcast, > group key applications with revocation algorithms that have > logarithmic complexity, small groups, large groups, pairwise unicast, > multi-unicast sessions. > > The fact is, that we have not been able to do it for SIP, let alone > for the great variety of applications that use RTP and can benefit > from SRTP. > >> >> - unicast (if it works with multicast as well, that's great, but >> requiring this one method to also work with multicast will fail for >> sure). > > > I agree. Thus, we are obviously not concerned with key agreement or > key establishment for SRTP in general, right? > >> >> - forking (copies of signaling may be sent to multiple devices, and >> a single request may result in multiple sessions being established. >> There can be no key sharing between these sessions) >> >> - early media (there can be no media clipping of the initial media >> packets sent by the answering party i.e. the "Hello". Note that >> this "Hello" will in most cases arrive before any associated >> signaling from the answering party) >> >> - no requirement for PKI and certificates issued by a public CA. >> >> I'd like to hear other's opinions on the requirements of this work. > > > What you have listed above are the latest issues that have arisen in > SIP signaling of SRTP sessions. This is a fine start along the lines > that Dan Wing presented at the RAI area meeting. There are some > additional requirements that need to be considered, such as RTP > mixers and translators. I think the list will become long and that > we will have a lot to consider when comparing the applicability of > MIKEY, sdesc, DTLS, zRTP, EKT, SDP-DH, and the other methods. There > is also the question of how sessions are authorized. Is the > fingerprint method all that there is? What about third parties? > These are not required, but will they be supported? Does SIP > identity have a role to play? > > The first thing I'd like to understand is applicability: We need to > constrain and demarcate the problem that we are addressing in this > group. For starters, yesterday I asked about the name "rtpsec", > which might lead to one to believe that we are trying to find the > best way to secure RTP. I don't think that we will start by > considering how to secure RTP flows at this point but instead focus > on the best way to agree, establish, and/or agree upon keys for SRTP > for IP telephony applications. > >> >> This single method would be then be a *the* standard way of keying >> SRTP. > > > Ah, you just said that we're not considering multicast so it's clear > that you're talking about one standard way to key SRTP *for a > particular application or set of applications*. I think you're > considering IP telephony and not all SRTP applications. > >> Implementations are of course free to choose and support additional >> methods which might be optimized for one particular environment, but >> they still must support and offer this single standard way. > > > I'm not sure what "must" means here. There is no way to mandate > whatever this group develops for all SRTP applications. Maybe it > might be done for SIP or some specific signaling protocols that can > mandate a specific key method be used. RFC 3711 does not because the > application demands for keying SRTP vary so much. > > Mark > >> >> Thanks, >> Alan > > > From owner-ietf-rtpsec Sat Apr 15 08:45:54 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FFjsmC081982; Sat, 15 Apr 2006 08:45:54 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3FFjsxc081981; Sat, 15 Apr 2006 08:45:54 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from acmepacket.com (host10.216.41.24.conversent.net [216.41.24.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FFjrxZ081975 for ; Sat, 15 Apr 2006 08:45:53 -0700 (MST) (envelope-from HKaplan@acmepacket.com) Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A52E06D4; Sat, 15 Apr 2006 11:45:50 -0400 From: "Hadriel Kaplan" To: "'Alan Johnston'" , "'Mark Baugher'" Cc: Subject: RE: Requirements, First Date: Sat, 15 Apr 2006 11:45:59 -0400 Message-ID: <00d201c660a3$b1a6eb40$91c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZgkUyzBVVQHcU2QeacV2WLFUUdEAADdHhg In-Reply-To: <4440F3DE.8060401@sipstation.com> Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: If we're going to even try to come up with one keying method, and you want it to be a successful choice, then you have to take into consideration things which the IETF typically does not: cost and demand. The demand for securing media exists, but how it gets secured, and how strong that security has to be, is not from what I can tell. So cost will be a huge factor. This is not a forum for cost analysis, and the costs vary depending on a great many device-dependent things, but the level of security is almost always weighed against the cost in the marketplace. That's why choices are good - each choice's cost can be weighed by the one making the decision based on her demand. For software folks thinking about one phone call the choices here don't make much cost difference, assuming all the choices are royalty free; but for people putting SRTP in hardware or trying to scale it to thousands, the keying mechanism is significant. No IETF RFC is going to make it such that the customers are willing to pay for the price difference, when they don't care about the nuances that made the RFC choose a more-expensive mechanism. -hadriel > -----Original Message----- > From: owner-ietf-rtpsec@mail.imc.org [mailto:owner-ietf- > rtpsec@mail.imc.org] On Behalf Of Alan Johnston > Sent: Saturday, April 15, 2006 9:24 AM > To: Mark Baugher > Cc: ietf-rtpsec@imc.org > Subject: Re: Requirements, First > > > Mark, > > Underlying every requirement in my list is the application of > establishing secure point to point sessions between arbitrary Internet > endpoints, i.e. VoIP. Clearly we are talking about a single application > on this list. > > VoIP or general multimedia sessions is the application here - it is the > one that has a strong need for SRTP which is currently not being met. > 3GPP is also following this work, and if we fail to solve this problem > I'm sure they will step in and do our work for us. > > I don't limit this to just SIP, however, as, unfortunately, the whole > world does not use SIP. I believe these requirements are moving us > towards the one keying method we have not tried yet - inband keying. > With inband keying, we will be able to establish a secure session even > between endpoints which don't use a common signaling protocol (i.e. they > could use H.323, Jingle, Skinny, etc.) If we did this, the IETF would > be doing an immense service to the real time communications industry by > providing useful, deployable security. > > In terms of SIP, anything we design here has to co-exist with current > implementations. This means we can require any special extensions to > SIP or support of new features such as multipart alternative. > Essentially, what we come up with must work with vanilla RFC 3261 SIP. > > Thanks, > Alan > > Mark Baugher wrote: > > > Alan, > > > > On Apr 14, 2006, at 6:45 PM, Alan Johnston wrote: > > > >> > >> Before we jump into mechanisms and comparing approaches, lets first > >> discuss the requirements. Here's my opinion. > >> > >> Currently, we have standardized a number of ways to key SRTP. They > >> all involve using a signaling channel (SIP) or another protocol > >> (MIKEY). Each method works in some set of circumstances. However, > >> none of them work in all the scenarios and implementors have > >> inidicated that they are not happy with any of them. > >> > >> In this work, we are looking for a single (1) method to key SRTP > >> which works under the following conditions: > > > > > > I believe that you have just articulated a non-requirement for this > > work. We should not be looking for a single way to key SRTP in my > > opinion because there is no single way to do that. We might have > > some success in looking for a single way to key SRTP for SIP > > applications, or maybe for general telephony applications, but SRTP > > is too broad for their to be a single key management scheme for all > > types of multicast applications, including unidirectional broadcast, > > group key applications with revocation algorithms that have > > logarithmic complexity, small groups, large groups, pairwise unicast, > > multi-unicast sessions. > > > > The fact is, that we have not been able to do it for SIP, let alone > > for the great variety of applications that use RTP and can benefit > > from SRTP. > > > >> > >> - unicast (if it works with multicast as well, that's great, but > >> requiring this one method to also work with multicast will fail for > >> sure). > > > > > > I agree. Thus, we are obviously not concerned with key agreement or > > key establishment for SRTP in general, right? > > > >> > >> - forking (copies of signaling may be sent to multiple devices, and > >> a single request may result in multiple sessions being established. > >> There can be no key sharing between these sessions) > >> > >> - early media (there can be no media clipping of the initial media > >> packets sent by the answering party i.e. the "Hello". Note that > >> this "Hello" will in most cases arrive before any associated > >> signaling from the answering party) > >> > >> - no requirement for PKI and certificates issued by a public CA. > >> > >> I'd like to hear other's opinions on the requirements of this work. > > > > > > What you have listed above are the latest issues that have arisen in > > SIP signaling of SRTP sessions. This is a fine start along the lines > > that Dan Wing presented at the RAI area meeting. There are some > > additional requirements that need to be considered, such as RTP > > mixers and translators. I think the list will become long and that > > we will have a lot to consider when comparing the applicability of > > MIKEY, sdesc, DTLS, zRTP, EKT, SDP-DH, and the other methods. There > > is also the question of how sessions are authorized. Is the > > fingerprint method all that there is? What about third parties? > > These are not required, but will they be supported? Does SIP > > identity have a role to play? > > > > The first thing I'd like to understand is applicability: We need to > > constrain and demarcate the problem that we are addressing in this > > group. For starters, yesterday I asked about the name "rtpsec", > > which might lead to one to believe that we are trying to find the > > best way to secure RTP. I don't think that we will start by > > considering how to secure RTP flows at this point but instead focus > > on the best way to agree, establish, and/or agree upon keys for SRTP > > for IP telephony applications. > > > >> > >> This single method would be then be a *the* standard way of keying > >> SRTP. > > > > > > Ah, you just said that we're not considering multicast so it's clear > > that you're talking about one standard way to key SRTP *for a > > particular application or set of applications*. I think you're > > considering IP telephony and not all SRTP applications. > > > >> Implementations are of course free to choose and support additional > >> methods which might be optimized for one particular environment, but > >> they still must support and offer this single standard way. > > > > > > I'm not sure what "must" means here. There is no way to mandate > > whatever this group develops for all SRTP applications. Maybe it > > might be done for SIP or some specific signaling protocols that can > > mandate a specific key method be used. RFC 3711 does not because the > > application demands for keying SRTP vary so much. > > > > Mark > > > >> > >> Thanks, > >> Alan > > > > > > From owner-ietf-rtpsec Sat Apr 15 15:12:56 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FMCtbL099247; Sat, 15 Apr 2006 15:12:55 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3FMCtj4099246; Sat, 15 Apr 2006 15:12:55 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FMCtjP099239 for ; Sat, 15 Apr 2006 15:12:55 -0700 (MST) (envelope-from mbaugher@cisco.com) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 15 Apr 2006 15:12:49 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k3FMCnRT016331; Sat, 15 Apr 2006 15:12:49 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 15 Apr 2006 15:12:49 -0700 Received: from [192.168.0.13] ([10.21.88.111]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 15 Apr 2006 15:12:49 -0700 In-Reply-To: <4440F3DE.8060401@sipstation.com> References: <44405030.1010901@sipstation.com> <35337CB5-56C9-4304-9CB1-4A2DC0A2D50D@cisco.com> <4440F3DE.8060401@sipstation.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: Requirements, First Date: Sat, 15 Apr 2006 15:12:45 -0700 To: Alan Johnston X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 15 Apr 2006 22:12:49.0100 (UTC) FILETIME=[BB2B88C0:01C660D9] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan, On Apr 15, 2006, at 6:23 AM, Alan Johnston wrote: > Mark, > > Underlying every requirement in my list is the application of > establishing secure point to point sessions between arbitrary > Internet endpoints, i.e. VoIP. Clearly we are talking about a > single application on this list. Good, the we agree. This needs to be stated up front since the name 'rtpsec' is leaves a lot of questions unanswered. And we're not just interested in voice over IP but also dial tones and other stuff that falls into the general category of IP telephony. > VoIP or general multimedia sessions is the application here - it is > the one that has a strong need for SRTP which is currently not > being met. 3GPP is also following this work, and if we fail to > solve this problem I'm sure they will step in and do our work for us. Last I heard, they were supporting MIKEY for this application. > > I don't limit this to just SIP, however, as, unfortunately, the > whole world does not use SIP. I believe these requirements are > moving us towards the one keying method we have not tried yet - > inband keying. With inband keying, we will be able to establish a > secure session even between endpoints which don't use a common > signaling protocol (i.e. they could use H.323, Jingle, Skinny, > etc.) If we did this, the IETF would be doing an immense service > to the real time communications industry by providing useful, > deployable security. Well, the name of your thread is "Requirements, First" but has wandered into the territory of what is the best mechanism: In-band keying is the answer! What's the question? > > In terms of SIP, anything we design here has to co-exist with > current implementations. This means we can require any special > extensions to SIP or support of new features such as multipart > alternative. Is this what you mean: We can require special extensions such as multipart alternative? I think you're missing a "not". > Essentially, what we come up with must work with vanilla RFC 3261 SIP. And 3G? H-series? How long is the list? I'd make it short and keep this whole effort focused on SIP. My two cents. Mark > > Thanks, > Alan > > Mark Baugher wrote: > >> Alan, >> >> On Apr 14, 2006, at 6:45 PM, Alan Johnston wrote: >> >>> >>> Before we jump into mechanisms and comparing approaches, lets >>> first discuss the requirements. Here's my opinion. >>> >>> Currently, we have standardized a number of ways to key SRTP. >>> They all involve using a signaling channel (SIP) or another >>> protocol (MIKEY). Each method works in some set of >>> circumstances. However, none of them work in all the scenarios >>> and implementors have inidicated that they are not happy with >>> any of them. >>> >>> In this work, we are looking for a single (1) method to key SRTP >>> which works under the following conditions: >> >> >> I believe that you have just articulated a non-requirement for >> this work. We should not be looking for a single way to key SRTP >> in my opinion because there is no single way to do that. We >> might have some success in looking for a single way to key SRTP >> for SIP applications, or maybe for general telephony >> applications, but SRTP is too broad for their to be a single key >> management scheme for all types of multicast applications, >> including unidirectional broadcast, group key applications with >> revocation algorithms that have logarithmic complexity, small >> groups, large groups, pairwise unicast, multi-unicast sessions. >> >> The fact is, that we have not been able to do it for SIP, let >> alone for the great variety of applications that use RTP and can >> benefit from SRTP. >> >>> >>> - unicast (if it works with multicast as well, that's great, but >>> requiring this one method to also work with multicast will fail >>> for sure). >> >> >> I agree. Thus, we are obviously not concerned with key agreement >> or key establishment for SRTP in general, right? >> >>> >>> - forking (copies of signaling may be sent to multiple devices, >>> and a single request may result in multiple sessions being >>> established. There can be no key sharing between these sessions) >>> >>> - early media (there can be no media clipping of the initial >>> media packets sent by the answering party i.e. the "Hello". >>> Note that this "Hello" will in most cases arrive before any >>> associated signaling from the answering party) >>> >>> - no requirement for PKI and certificates issued by a public CA. >>> >>> I'd like to hear other's opinions on the requirements of this work. >> >> >> What you have listed above are the latest issues that have arisen >> in SIP signaling of SRTP sessions. This is a fine start along >> the lines that Dan Wing presented at the RAI area meeting. There >> are some additional requirements that need to be considered, such >> as RTP mixers and translators. I think the list will become long >> and that we will have a lot to consider when comparing the >> applicability of MIKEY, sdesc, DTLS, zRTP, EKT, SDP-DH, and the >> other methods. There is also the question of how sessions are >> authorized. Is the fingerprint method all that there is? What >> about third parties? These are not required, but will they be >> supported? Does SIP identity have a role to play? >> >> The first thing I'd like to understand is applicability: We need >> to constrain and demarcate the problem that we are addressing in >> this group. For starters, yesterday I asked about the name >> "rtpsec", which might lead to one to believe that we are trying >> to find the best way to secure RTP. I don't think that we will >> start by considering how to secure RTP flows at this point but >> instead focus on the best way to agree, establish, and/or agree >> upon keys for SRTP for IP telephony applications. >> >>> >>> This single method would be then be a *the* standard way of >>> keying SRTP. >> >> >> Ah, you just said that we're not considering multicast so it's >> clear that you're talking about one standard way to key SRTP *for >> a particular application or set of applications*. I think >> you're considering IP telephony and not all SRTP applications. >> >>> Implementations are of course free to choose and support >>> additional methods which might be optimized for one particular >>> environment, but they still must support and offer this single >>> standard way. >> >> >> I'm not sure what "must" means here. There is no way to mandate >> whatever this group develops for all SRTP applications. Maybe it >> might be done for SIP or some specific signaling protocols that >> can mandate a specific key method be used. RFC 3711 does not >> because the application demands for keying SRTP vary so much. >> >> Mark >> >>> >>> Thanks, >>> Alan >> >> >> From owner-ietf-rtpsec Mon Apr 17 13:49:30 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HKnTMu041457; Mon, 17 Apr 2006 13:49:29 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3HKnTo4041456; Mon, 17 Apr 2006 13:49:29 -0700 (MST) (envelope-from owner-ietf-rtpsec@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-rtpsec@mail.imc.org using -f Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HKnQHm041449 for ; Mon, 17 Apr 2006 13:49:27 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 17 Apr 2006 13:49:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k3HKnLRT028665; Mon, 17 Apr 2006 13:49:21 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Apr 2006 13:49:21 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Apr 2006 13:49:20 -0700 In-Reply-To: References: <0D1719326D64BD4E9F92A0C120237678C250F5@eserv.covergence.com> <541FA8D4-56DD-4B27-8C11-27F65DF7D389@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Rick Porter , ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: Optional SRTP with SDES? Date: Mon, 17 Apr 2006 13:49:19 -0700 To: Mark Baugher X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 17 Apr 2006 20:49:20.0370 (UTC) FILETIME=[668F7D20:01C66260] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mark, On Apr 13, 2006, at 3:42 PM, Mark Baugher wrote: > David, > A nit below... > On Apr 13, 2006, at 2:25 PM, David McGrew wrote: > >> >> Hi Rick, >> >> On Apr 12, 2006, at 7:00 AM, Rick Porter wrote: >> >>> >>> This discussion started on the mmusic list >>> (http://www1.ietf.org/mail-archive/web/mmusic/current/ >>> msg04091.html), >>> and was moved to this list this list at the request of the mmusic >>> moderator. >>> >>> The original question was: How do you make a call and optionally do >>> SRTP? >>> >>> The responses highlighted that with SDES there is no way to do this >>> without additional INVITEs or mulitpart alternate SDP (which most >>> clients do not yet support). There are other requirements in the >>> SDES >>> draft that also have negative impact on users (e.g. if a voicemail >>> system is configured for SRTP, only SRTP enabled phones could get >>> their >>> voicemail). >>> >>> I know there are other SRTP keying options (e.g. ZRTP, RTP/DTLS, >>> MIKEY, >>> EKT, SDP-DH). I'm aware that each solution has its good and bad >>> points, >>> but I want to focus on the SDES draft since my un-scientific >>> findings >>> are that it is the most widely used. >>> >>> I've been testing with five other SDES/SRTP vendors who all handle >>> things a bit differently. Some are following the SDES draft to the >>> letter, but others have taken a more "user-friendly" approach. I >>> think >>> with a few tweaks, the SDES draft could reflect the behavior with >>> which >>> everyone is moderately happy (and seems to be converging on). >>> >>> Here are my suggestions to the SDES draft: >>> >>> 1) Use the same media stream. No special transport. Crypto is just >>> another "optional" attribute of the media description. >>> >>> When a callee who does not support SDES receives an INVITE with >>> crypto, >>> he can accept the call and does not provide a crypto attribute in >>> the >>> 200/OK/SDP. Then, the caller can choose to CANCEL the call or >>> continue >>> the non-secure call if he does not like the 200/OK/SDP without the >>> crypto attribute. >> >> If I understand correctly, this would be equivalent to the current >> methods security-wise in that the offerer could specify both >> "secure" and "insecure" options, and the answerer would get to >> choose. But there are deployability advantages to doing it this >> way, which we definitely want, so it deserves serious >> consideration IMO. >> >> A minor question: with your proposal, if the answerer selected "no >> encryption", would the media stream use the AVP profile or the >> SAVP profile with NULL encryption and NULL authentication? >> >>> >>> 2) Add an encryption attribu