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 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 Sure, but SRTP with NULL encryption is not equivalent to RTP - turning off encryption is not the same as not doing SRTP. If I understand Rick correctly, this is why he's suggesting the additional "a=encryption" attribute. David >> 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 Mon Apr 17 14:08:04 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 k3HL83QJ042259; Mon, 17 Apr 2006 14:08:03 -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 k3HL83wv042258; Mon, 17 Apr 2006 14:08:03 -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 rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HL823x042251 for ; Mon, 17 Apr 2006 14:08:02 -0700 (MST) (envelope-from wmills@cisco.com) Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2006 14:07:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,127,1144047600"; d="scan'208"; a="26061988:sNHT23261202" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3HL7uvF017605; Mon, 17 Apr 2006 17:07:56 -0400 (EDT) Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Apr 2006 17:07:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Optional SRTP with SDES? Date: Mon, 17 Apr 2006 17:07:55 -0400 Message-ID: <9EF3C46DC5D14D44B218FD5E93786CA201B9D3B4@xmb-rtp-201.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optional SRTP with SDES? Thread-Index: AcZiYM0bl9KjqT3JRQ2LhFexta8OmAAAP3Qg From: "Wayne Mills \(wmills\)" To: "David McGrew \(mcgrew\)" , "Mark Baugher \(mbaugher\)" Cc: "Rick Porter" , X-OriginalArrivalTime: 17 Apr 2006 21:07:56.0588 (UTC) FILETIME=[FFE0D6C0:01C66262] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3HL823x042253 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think Mark's comments were more aimed at your parenthetical ("in principle anyway"). Sdescriptions has syntax (e.g. "unencrypted_srtp") to alter a crypto suite so that authentication is still enabled while encryption is disabled, so it accomodates establishment of unencrypted SRTP ( oxymoronic as that sounds :) ). Back to syntax, I think "a=security: " is better than "a=encryption: ", due to the ability to negotiate unencrypted SRTP. Regards, Wayne > >>> > >>> 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 > > Sure, but SRTP with NULL encryption is not equivalent to RTP > - turning off encryption is not the same as not doing SRTP. > If I understand Rick correctly, this is why he's suggesting > the additional "a=encryption" attribute. > > David > > > >> Maybe "a=secure" would be better. > >> > >>> From owner-ietf-rtpsec Mon Apr 17 14:16:42 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 k3HLGgnc042696; Mon, 17 Apr 2006 14:16: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 k3HLGg4H042695; Mon, 17 Apr 2006 14:16: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 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 k3HLGeRc042689 for ; Mon, 17 Apr 2006 14:16:40 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-3.cisco.com with ESMTP; 17 Apr 2006 14:16:35 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3HLGXw1006784; Mon, 17 Apr 2006 14:16:33 -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); Mon, 17 Apr 2006 14:16:33 -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 14:16:32 -0700 In-Reply-To: <9EF3C46DC5D14D44B218FD5E93786CA201B9D3B4@xmb-rtp-201.amer.cisco.com> References: <9EF3C46DC5D14D44B218FD5E93786CA201B9D3B4@xmb-rtp-201.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49FF7D69-1128-4106-9A20-04AE3492C4FF@cisco.com> 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 14:16:31 -0700 To: "Wayne Mills ((wmills))" , "Mark Baugher ((mbaugher))" X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 17 Apr 2006 21:16:32.0651 (UTC) FILETIME=[3379CDB0:01C66264] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Wayne, Mark, thanks for the clarifications! David On Apr 17, 2006, at 2:07 PM, Wayne Mills ((wmills)) wrote: > I think Mark's comments were more aimed at your parenthetical ("in > principle anyway"). Sdescriptions has syntax (e.g. > "unencrypted_srtp") > to alter a crypto suite so that authentication is still enabled while > encryption is disabled, so it accomodates establishment of unencrypted > SRTP ( oxymoronic as that sounds :) ). > > Back to syntax, I think "a=security: " is better > than "a=encryption: ", due to the ability to > negotiate unencrypted SRTP. > > Regards, > Wayne > >>>>> >>>>> 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 >> >> Sure, but SRTP with NULL encryption is not equivalent to RTP >> - turning off encryption is not the same as not doing SRTP. >> If I understand Rick correctly, this is why he's suggesting >> the additional "a=encryption" attribute. >> >> David >> >> >>>> Maybe "a=secure" would be better. >>>> >>>>> From owner-ietf-rtpsec Mon Apr 17 14:14:57 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 k3HLEv3n042622; Mon, 17 Apr 2006 14:14:57 -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 k3HLEvYM042621; Mon, 17 Apr 2006 14:14:57 -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-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HLEucA042613 for ; Mon, 17 Apr 2006 14:14:56 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 17 Apr 2006 14:14:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k3HLEpRT016792; Mon, 17 Apr 2006 14:14:51 -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); Mon, 17 Apr 2006 14:14:50 -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 14:14:50 -0700 In-Reply-To: <0D1719326D64BD4E9F92A0C120237678C2551D@eserv.covergence.com> References: <0D1719326D64BD4E9F92A0C120237678C2551D@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: Cc: Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: Optional SRTP with SDES? Date: Mon, 17 Apr 2006 14:14:48 -0700 To: Rick Porter X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 17 Apr 2006 21:14:50.0526 (UTC) FILETIME=[F69AC3E0:01C66263] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Rick, On Apr 14, 2006, at 6:13 AM, Rick Porter wrote: > 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. I'm no SDP expert, so I can't comment on the best way to do the SDP. But it strikes me that if we want to allow for RTP flows for which SRTP suddenly gets "turned on", then the best way to do this would be to define an SRTP cryptosuite that consists of NULL encryption and NULL authentication with anti-replay checking turned off. This very lame cryptosuite is very slightly different from regular RTP in that the ROC would be tracked by the sender and receiver and a cryptoalgorithm change could take place at some point in the future. Using SAVP with this "null cryptosuite" provides some advantages - the ROC can be used for synchronized rekeying, and the RTP profile is now consistent across the whole media flow. Are there some disadvantages to using this approach w.r.t. the SDP? My thinking has been partly motivated by the thought of what would happen if your proposal got used in a scenario in which an (S)RTP implementation was expected to process packets that it receives before the SIP "answer" gets processed. In this scenario, I'd expect that it's definitely best to use the SAVP profile across the whole session. David p.s. - the "null cryptosuite" would also violate rfc3711 if it was applied to RTCP, since authentication is required for the control protocol. I would expect that, if the "null cryptosuite" was deemed useful by the WG, then we'd deal with that by writing a new standards- track RFC that contained the appropriate disclaimers. > >>> 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 Tue Apr 18 02:15:31 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 k3I9FUxv081159; Tue, 18 Apr 2006 02:15:30 -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 k3I9FU7r081158; Tue, 18 Apr 2006 02:15:30 -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 mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3I9FTJ4081151 for ; Tue, 18 Apr 2006 02:15:30 -0700 (MST) (envelope-from christer.holmberg@ericsson.com) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 88766378; Tue, 18 Apr 2006 11:15:28 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 11:15:28 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 11:15:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Requirements, First Date: Tue, 18 Apr 2006 11:15:27 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1D3B@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements, First Thread-Index: AcZgkmBNcu0qTKgURx+ux0vi2A1HZgCNT8iw From: "Christer Holmberg \(JO/LMF\)" To: "Alan Johnston" Cc: X-OriginalArrivalTime: 18 Apr 2006 09:15:28.0013 (UTC) FILETIME=[A227B3D0:01C662C8] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3I9FUJ4081153 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, >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. Something like ZRTP? Regards, Christer From owner-ietf-rtpsec Tue Apr 18 04:08: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 k3IB8uA8089642; Tue, 18 Apr 2006 04:08:56 -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 k3IB8urG089641; Tue, 18 Apr 2006 04:08:56 -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-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IB8tXl089635 for ; Tue, 18 Apr 2006 04:08:55 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 18 Apr 2006 04:08:50 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3IB8kh6017410; Tue, 18 Apr 2006 04:08:50 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 04:08:48 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 04:08:46 -0700 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1D3B@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1D3B@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <18BB0374-94B3-4D12-8BA1-73CF44C11F12@cisco.com> Cc: "Alan Johnston" , Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: Requirements, First Date: Tue, 18 Apr 2006 04:08:44 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 18 Apr 2006 11:08:46.0214 (UTC) FILETIME=[7632DA60:01C662D8] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Christer, "DTLS Keying for SRTP" is the other method for in-band key negotiation: http://scm.sipfoundry.org/rep/ietf-drafts/ekr/draft-mcgrew-dtls- srtp.html Its not an official Internet Draft yet, which is an oversight on my part (it was written during the draft blackout period at Dallas). EKT is also in-band, but it is not a key negotiation protocol. David On Apr 18, 2006, at 2:15 AM, Christer Holmberg ((JO/LMF)) wrote: > > > Hi, > >> 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. > > Something like ZRTP? > > Regards, > > Christer From owner-ietf-rtpsec Tue Apr 18 04:34:17 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 k3IBYHeE091378; Tue, 18 Apr 2006 04:34:17 -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 k3IBYHRu091377; Tue, 18 Apr 2006 04:34:17 -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 k3IBYG0j091360 for ; Tue, 18 Apr 2006 04:34:16 -0700 (MST) (envelope-from rporter@covergence.com) Content-class: urn:content-classes:message Subject: RE: Optional SRTP with SDES? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Apr 2006 07:34:03 -0400 Message-ID: <0D1719326D64BD4E9F92A0C120237678C2586B@eserv.covergence.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optional SRTP with SDES? Thread-Index: AcZiY/md8ayuXFXpRxGEfHxKibaO2AAAYXtg 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 k3IBYG0j091372 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi David, >-----Original Message----- >> >>>> 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. > >I'm no SDP expert, so I can't comment on the best way to do the SDP. > >But it strikes me that if we want to allow for RTP flows for which >SRTP suddenly gets "turned on", then the best way to do this would be >to define an SRTP cryptosuite that consists of NULL encryption and >NULL authentication with anti-replay checking turned off. This very >lame cryptosuite is very slightly different from regular RTP in that >the ROC would be tracked by the sender and receiver and a >cryptoalgorithm change could take place at some point in the future. >Using SAVP with this "null cryptosuite" provides some advantages - >the ROC can be used for synchronized rekeying, and the RTP profile is >now consistent across the whole media flow. Are there some >disadvantages to using this approach w.r.t. the SDP? > >My thinking has been partly motivated by the thought of what would >happen if your proposal got used in a scenario in which an (S)RTP >implementation was expected to process packets that it receives >before the SIP "answer" gets processed. In this scenario, I'd expect >that it's definitely best to use the SAVP profile across the whole >session. > >David > >p.s. - the "null cryptosuite" would also violate rfc3711 if it was >applied to RTCP, since authentication is required for the control >protocol. I would expect that, if the "null cryptosuite" was deemed >useful by the WG, then we'd deal with that by writing a new standards- >track RFC that contained the appropriate disclaimers. > > I think we may want to reset the ROC(s) to zero whenever rekeying. I don't think this introduces any cryptographic weakness, since you'd also be introducing a new key. This also simplifies things so you don't need the "null cryptosuite". I've most often seen Re-INVITEs to change destinations (e.g. transfer from desk to lab phone thru PBX). The new receiver would have no knowledge of old ROC data. With mismatched ROC data, your media stream would fail (auth failures drop packets, w/o auth decryption results in static). The ROC is incremented when the RTP sequence number flips, which can happen at any point during a call. Currently, I think there is a "small" race condition with ROC with early SRTP media. If the other end has not received the key and starts receiving packets, then it will drop packets that fail authentication and not properly increment the ROC counter. The sender does not know the receiver has not incremented the ROC and keeps sending. Regards, Rick From owner-ietf-rtpsec Tue Apr 18 05:10:41 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 k3ICAenu093272; Tue, 18 Apr 2006 05:10:40 -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 k3ICAeBQ093271; Tue, 18 Apr 2006 05:10:40 -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 cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3ICAewY093254 for ; Tue, 18 Apr 2006 05:10:40 -0700 (MST) (envelope-from Brian.Rosen@neustar.biz) Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k3ICAU0d013308; Tue, 18 Apr 2006 12:10:30 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 08:10:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C662E1.15E26D22" Subject: RE: Requirements, First Date: Tue, 18 Apr 2006 08:07:03 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements, First Thread-Index: AcZgkmBNcu0qTKgURx+ux0vi2A1HZgCNT8iwAAY+y6M= From: "Rosen, Brian" To: "Christer Holmberg \(JO/LMF\)" , "Alan Johnston" Cc: X-OriginalArrivalTime: 18 Apr 2006 12:10:30.0668 (UTC) FILETIME=[1639ACC0:01C662E1] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C662E1.15E26D22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hang on, are we now expanding beyond what is reasonable to achieve? Would it not be a GREAT service to mankind if we managed to get SIP = based multimedia secured in a consistant way? Is it really important to = solve ALL rtp based security needs with one solution right now? I'd advocate sticking with SIP for the moment. I don't want to limit to = in band solutions, at least not yet. SIP is not everything, but it's the thing with the big mess right now. = Let's solve that problem first and then go on to world domination. Brian -----Original Message----- From: owner-ietf-rtpsec@mail.imc.org on behalf of Christer Holmberg = (JO/LMF) Sent: Tue 4/18/2006 5:15 AM To: Alan Johnston Cc: ietf-rtpsec@imc.org Subject: RE: Requirements, First =20 Hi,=20 >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=20 >one keying method we have not tried yet - inband keying. =20 Something like ZRTP? Regards, Christer ------_=_NextPart_001_01C662E1.15E26D22 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Requirements, First

Hang on, are we now expanding beyond what is = reasonable to achieve?

Would it not be a GREAT service to mankind if we managed to get SIP = based multimedia secured in a consistant way?  Is it really = important to solve ALL rtp based security needs with one solution right = now?

I'd advocate sticking with SIP for the moment.  I don't want to = limit to in band solutions, at least not yet.

SIP is not everything, but it's the thing with the big mess right = now.  Let's solve that problem first and then go on to world = domination.

Brian


-----Original Message-----
From: owner-ietf-rtpsec@mail.imc.org on behalf of Christer Holmberg = (JO/LMF)
Sent: Tue 4/18/2006 5:15 AM
To: Alan Johnston
Cc: ietf-rtpsec@imc.org
Subject: RE: Requirements, First



Hi,

>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. 

Something like ZRTP?

Regards,

Christer

------_=_NextPart_001_01C662E1.15E26D22-- From owner-ietf-rtpsec Tue Apr 18 05:36: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 k3ICaCPo094821; Tue, 18 Apr 2006 05:36: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 k3ICaC1I094820; Tue, 18 Apr 2006 05:36: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 Xms1.etsihq.org (email10.etsi.org [212.234.161.112]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3ICaA6B094811 for ; Tue, 18 Apr 2006 05:36:11 -0700 (MST) (envelope-from Scott.Cadzow@etsi.org) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C662E4.A83BE948" Subject: RE: Requirements, First Date: Tue, 18 Apr 2006 14:36:04 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements, First Thread-Index: AcZgkmBNcu0qTKgURx+ux0vi2A1HZgCNT8iwAAY+y6MAAOFRcA== From: "Scott Cadzow" To: "Rosen, Brian" , "Christer Holmberg \(JO/LMF\)" , "Alan Johnston" Cc: Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C662E4.A83BE948 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I may have missed a decision on "a=3Dencryption" versus "a=3Dsecurity" = but my thoughts are highly in favour of the former. The reason is that security is too vague whereas encryption offers a single service: confidentiality. It may be necessary to add other tags to cover other security services (authenticity, integrity). =20 Scott ________________________________ From: owner-ietf-rtpsec@mail.imc.org [mailto:owner-ietf-rtpsec@mail.imc.org] On Behalf Of Rosen, Brian Sent: 18 April 2006 14:07 To: Christer Holmberg (JO/LMF); Alan Johnston Cc: ietf-rtpsec@imc.org Subject: RE: Requirements, First Hang on, are we now expanding beyond what is reasonable to achieve? Would it not be a GREAT service to mankind if we managed to get SIP based multimedia secured in a consistant way? Is it really important to solve ALL rtp based security needs with one solution right now? I'd advocate sticking with SIP for the moment. I don't want to limit to in band solutions, at least not yet. SIP is not everything, but it's the thing with the big mess right now. Let's solve that problem first and then go on to world domination. Brian -----Original Message----- From: owner-ietf-rtpsec@mail.imc.org on behalf of Christer Holmberg (JO/LMF) Sent: Tue 4/18/2006 5:15 AM To: Alan Johnston Cc: ietf-rtpsec@imc.org Subject: RE: Requirements, First Hi, >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.=20 Something like ZRTP? Regards, Christer ------_=_NextPart_001_01C662E4.A83BE948 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: Requirements, First
I may have missed a decision on = "a=3Dencryption" versus=20 "a=3Dsecurity" but my thoughts are highly in favour of the former. The = reason is=20 that security is too vague whereas encryption offers a single service:=20 confidentiality. It may be necessary to add other tags to cover other = security=20 services (authenticity, integrity).
 
Scott

From: owner-ietf-rtpsec@mail.imc.org = [mailto:owner-ietf-rtpsec@mail.imc.org] On Behalf Of Rosen,=20 Brian
Sent: 18 April 2006 14:07
To: Christer = Holmberg=20 (JO/LMF); Alan Johnston
Cc: = ietf-rtpsec@imc.org
Subject: RE:=20 Requirements, First

Hang on, are we now expanding beyond what is = reasonable to=20 achieve?

Would it not be a GREAT service to mankind if we managed = to get=20 SIP based multimedia secured in a consistant way?  Is it really = important=20 to solve ALL rtp based security needs with one solution right = now?

I'd=20 advocate sticking with SIP for the moment.  I don't want to limit = to in=20 band solutions, at least not yet.

SIP is not everything, but it's = the=20 thing with the big mess right now.  Let's solve that problem first = and then=20 go on to world domination.

Brian


-----Original=20 Message-----
From: owner-ietf-rtpsec@mail.imc.org on behalf of = Christer=20 Holmberg (JO/LMF)
Sent: Tue 4/18/2006 5:15 AM
To: Alan = Johnston
Cc:=20 ietf-rtpsec@imc.org
Subject: RE: Requirements,=20 First



Hi,

>I don't limit this to just SIP, = however, as,=20 unfortunately, the whole
world does not use SIP.  I believe = these=20 requirements are moving  us
towards the
>one keying method = we have=20 not tried yet - inband keying. 

Something like=20 ZRTP?

Regards,

Christer


------_=_NextPart_001_01C662E4.A83BE948-- From owner-ietf-rtpsec Tue Apr 18 05:59:28 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 k3ICxS6I096144; Tue, 18 Apr 2006 05:59:28 -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 k3ICxSeq096143; Tue, 18 Apr 2006 05:59:28 -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 rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3ICxQmT096129 for ; Tue, 18 Apr 2006 05:59:27 -0700 (MST) (envelope-from wmills@cisco.com) Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 18 Apr 2006 05:59:15 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,130,1144047600"; d="scan'208,217"; a="26097878:sNHT90249600" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3ICxDvN022327; Tue, 18 Apr 2006 08:59:14 -0400 (EDT) Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 08:58:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C662E7.D118BFA0" Subject: RE: Requirements, First Date: Tue, 18 Apr 2006 08:58:40 -0400 Message-ID: <9EF3C46DC5D14D44B218FD5E93786CA201B9D574@xmb-rtp-201.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements, First Thread-Index: AcZgkmBNcu0qTKgURx+ux0vi2A1HZgCNT8iwAAY+y6MAAOFRcAAA585w From: "Wayne Mills \(wmills\)" To: "Scott Cadzow" , "Rosen, Brian" , "Christer Holmberg \(JO/LMF\)" , "Alan Johnston" Cc: X-OriginalArrivalTime: 18 Apr 2006 12:58:41.0676 (UTC) FILETIME=[D1667CC0:01C662E7] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C662E7.D118BFA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I responded on the other thread to avoid confusing this one with "cross-pollenation" :) ________________________________ From: owner-ietf-rtpsec@mail.imc.org [mailto:owner-ietf-rtpsec@mail.imc.org] On Behalf Of Scott Cadzow Sent: Tuesday, April 18, 2006 8:36 AM To: Rosen, Brian; Christer Holmberg (JO/LMF); Alan Johnston Cc: ietf-rtpsec@imc.org Subject: RE: Requirements, First =09 =09 I may have missed a decision on "a=3Dencryption" versus "a=3Dsecurity" but my thoughts are highly in favour of the former. The reason is that security is too vague whereas encryption offers a single service: confidentiality. It may be necessary to add other tags to cover other security services (authenticity, integrity). =20 Scott ________________________________ From: owner-ietf-rtpsec@mail.imc.org [mailto:owner-ietf-rtpsec@mail.imc.org] On Behalf Of Rosen, Brian Sent: 18 April 2006 14:07 To: Christer Holmberg (JO/LMF); Alan Johnston Cc: ietf-rtpsec@imc.org Subject: RE: Requirements, First =09 =09 Hang on, are we now expanding beyond what is reasonable to achieve? =09 Would it not be a GREAT service to mankind if we managed to get SIP based multimedia secured in a consistant way? Is it really important to solve ALL rtp based security needs with one solution right now? =09 I'd advocate sticking with SIP for the moment. I don't want to limit to in band solutions, at least not yet. =09 SIP is not everything, but it's the thing with the big mess right now. Let's solve that problem first and then go on to world domination. =09 Brian =09 =09 -----Original Message----- From: owner-ietf-rtpsec@mail.imc.org on behalf of Christer Holmberg (JO/LMF) Sent: Tue 4/18/2006 5:15 AM To: Alan Johnston Cc: ietf-rtpsec@imc.org Subject: RE: Requirements, First =09 =09 =09 Hi, =09 >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.=20 =09 Something like ZRTP? =09 Regards, =09 Christer =09 =09 =09 ------_=_NextPart_001_01C662E7.D118BFA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Requirements, First
I responded on the other thread to avoid = confusing this one=20 with "cross-pollenation" :)

From: = owner-ietf-rtpsec@mail.imc.org=20 [mailto:owner-ietf-rtpsec@mail.imc.org] On Behalf Of Scott=20 Cadzow
Sent: Tuesday, April 18, 2006 8:36 AM
To: = Rosen,=20 Brian; Christer Holmberg (JO/LMF); Alan Johnston
Cc:=20 ietf-rtpsec@imc.org
Subject: RE: Requirements,=20 First

I may have missed a decision on = "a=3Dencryption" versus=20 "a=3Dsecurity" but my thoughts are highly in favour of the former. The = reason is=20 that security is too vague whereas encryption offers a single service: = confidentiality. It may be necessary to add other tags to cover other = security=20 services (authenticity, integrity).
 
Scott

From: = owner-ietf-rtpsec@mail.imc.org=20 [mailto:owner-ietf-rtpsec@mail.imc.org] On Behalf Of Rosen,=20 Brian
Sent: 18 April 2006 14:07
To: Christer = Holmberg=20 (JO/LMF); Alan Johnston
Cc: = ietf-rtpsec@imc.org
Subject:=20 RE: Requirements, First

Hang on, are we now expanding beyond what is = reasonable to=20 achieve?

Would it not be a GREAT service to mankind if we = managed to=20 get SIP based multimedia secured in a consistant way?  Is it = really=20 important to solve ALL rtp based security needs with one solution = right=20 now?

I'd advocate sticking with SIP for the moment.  I = don't want=20 to limit to in band solutions, at least not yet.

SIP is not = everything,=20 but it's the thing with the big mess right now.  Let's solve that = problem=20 first and then go on to world=20 domination.

Brian


-----Original = Message-----
From:=20 owner-ietf-rtpsec@mail.imc.org on behalf of Christer Holmberg=20 (JO/LMF)
Sent: Tue 4/18/2006 5:15 AM
To: Alan Johnston
Cc:=20 ietf-rtpsec@imc.org
Subject: RE: Requirements,=20 First



Hi,

>I don't limit this to just SIP, = however,=20 as, unfortunately, the whole
world does not use SIP.  I = believe these=20 requirements are moving  us
towards the
>one keying = method we=20 have not tried yet - inband keying. 

Something like=20 = ZRTP?

Regards,

Christer


= ------_=_NextPart_001_01C662E7.D118BFA0-- From owner-ietf-rtpsec Tue Apr 18 05:57: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 k3ICvR7a096097; Tue, 18 Apr 2006 05:57: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 k3ICvRoL096096; Tue, 18 Apr 2006 05:57: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-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 k3ICvQ2S096087 for ; Tue, 18 Apr 2006 05:57:26 -0700 (MST) (envelope-from wmills@cisco.com) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 18 Apr 2006 05:57:22 -0700 X-IronPort-AV: i="4.04,130,1144047600"; d="scan'208"; a="1796021887:sNHT32191416" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3ICvIVQ022864; Tue, 18 Apr 2006 05:57:20 -0700 (PDT) Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 08:57:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Optional SRTP with SDES? Date: Tue, 18 Apr 2006 08:57:17 -0400 Message-ID: <9EF3C46DC5D14D44B218FD5E93786CA201B9D56F@xmb-rtp-201.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optional SRTP with SDES? Thread-Index: AcZiZDWn4VKxrVpwRqe8MIeN71IfcwAgqhBA From: "Wayne Mills \(wmills\)" To: "Scott Cadzow" , "David McGrew \(mcgrew\)" , "Mark Baugher \(mbaugher\)" Cc: "Rick Porter" , X-OriginalArrivalTime: 18 Apr 2006 12:57:18.0333 (UTC) FILETIME=[9FB95AD0:01C662E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3ICvQ2S096091 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Scott, See below for the reasoning on why encryption is too specific. Within the context of establishing an SRTP session, sdescriptions already provides syntax to negotiate confidentiality and authenticity characteristics, no additional attributes needed for that. What we are trying to nail down is how to do profile "downgrade", i.e., SRTP-->RTP. Heck, if it helps, the attribute can be brazenly specific: a=savp_usage: Regards, Wayne > -----Original Message----- > From: David McGrew (mcgrew) > Sent: Monday, April 17, 2006 5:17 PM > To: Wayne Mills (wmills); Mark Baugher (mbaugher) > Cc: Rick Porter; ietf-rtpsec@imc.org > Subject: Re: Optional SRTP with SDES? > > Wayne, Mark, > > thanks for the clarifications! > > David > > On Apr 17, 2006, at 2:07 PM, Wayne Mills ((wmills)) wrote: > > > I think Mark's comments were more aimed at your parenthetical ("in > > principle anyway"). Sdescriptions has syntax (e.g. > > "unencrypted_srtp") > > to alter a crypto suite so that authentication is still > enabled while > > encryption is disabled, so it accomodates establishment of > unencrypted > > SRTP ( oxymoronic as that sounds :) ). > > > > Back to syntax, I think "a=security: " > is better > > than "a=encryption: ", due to the ability to > > negotiate unencrypted SRTP. > > > > Regards, > > Wayne > > > >>>>> > >>>>> 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 > >> > >> Sure, but SRTP with NULL encryption is not equivalent to RTP > >> - turning off encryption is not the same as not doing SRTP. > >> If I understand Rick correctly, this is why he's suggesting the > >> additional "a=encryption" attribute. > >> > >> David > >> > >> > >>>> Maybe "a=secure" would be better. > >>>> > >>>>> > > From owner-ietf-rtpsec Tue Apr 18 14:15: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 k3ILF5Qm026362; Tue, 18 Apr 2006 14:15: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 k3ILF5j3026361; Tue, 18 Apr 2006 14:15:05 -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 zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3ILF4WS026347 for ; Tue, 18 Apr 2006 14:15:04 -0700 (MST) (envelope-from audet@nortel.com) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3ILEtQ09079; Tue, 18 Apr 2006 17:14:55 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Requirements, First Date: Tue, 18 Apr 2006 16:14:38 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF08CFD31A@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements, First Thread-Index: AcZgLrp0OgdvVi1mQbezp8UfYN15DwC/g8fQ From: "Francois Audet" To: "Alan Johnston" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3ILF5WS026356 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > - 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) Again: the bigger problem is not forking per se, but re-targetting. Key negotiation mechanism where a key is encrypted with the public key of the initial target don't work with re-targeting because of the non-anticipated respondent problem. Forking is often accompanied by re-targetting, of course, which compounds the problem. From owner-ietf-rtpsec Tue Apr 18 16:24:44 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 k3INOiGL032570; Tue, 18 Apr 2006 16:24:44 -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 k3INOiAS032569; Tue, 18 Apr 2006 16:24: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 co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3INOg6A032563 for ; Tue, 18 Apr 2006 16:24:43 -0700 (MST) (envelope-from rrg@avaya.com) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3INMXfq030259 for ; Tue, 18 Apr 2006 19:22:33 -0400 Received: from [135.9.42.38] ([135.9.42.38]) by cof110avexu1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Apr 2006 17:24:41 -0600 Message-ID: <44457534.1080204@avaya.com> Date: Tue, 18 Apr 2006 17:24:36 -0600 From: "Robert R. Gilman" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wayne Mills (wmills)" CC: Scott Cadzow , "David McGrew (mcgrew)" , "Mark Baugher (mbaugher)" , Rick Porter , ietf-rtpsec@imc.org Subject: Re: Optional SRTP with SDES? References: <9EF3C46DC5D14D44B218FD5E93786CA201B9D56F@xmb-rtp-201.amer.cisco.com> In-Reply-To: <9EF3C46DC5D14D44B218FD5E93786CA201B9D56F@xmb-rtp-201.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2006 23:24:41.0539 (UTC) FILETIME=[44D2C130:01C6633F] X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We've been thinking along the same lines. One thing we've considered is the inclusion of a=crypto: lines in SDP/AVP to permit optional SRTP/SRTCP or "plain old" RTP/RTCP. You'd get the latter from any endpoint that didn't recognize the crypto line(s), so this should be backward compatible. If one wants to force SRTP, then one could place the crypto lines in an SDP/SAVP record - any endpoint capable of SRTP should recognize it. The various options for SRTP would be controlled by cryptosuites and parameters, as defined in sdescriptions. Looked at this way, we might want to turn the a=crypto: line into an a=srtp: line. Does this make sense? -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868 Wayne Mills (wmills) wrote: > Scott, > > See below for the reasoning on why encryption is too specific. > > Within the context of establishing an SRTP session, sdescriptions > already provides syntax to negotiate confidentiality and authenticity > characteristics, no additional attributes needed for that. What we are > trying to nail down is how to do profile "downgrade", i.e., SRTP-->RTP. > > > Heck, if it helps, the attribute can be brazenly specific: > > a=savp_usage: > > Regards, > Wayne > > >>-----Original Message----- >>From: David McGrew (mcgrew) >>Sent: Monday, April 17, 2006 5:17 PM >>To: Wayne Mills (wmills); Mark Baugher (mbaugher) >>Cc: Rick Porter; ietf-rtpsec@imc.org >>Subject: Re: Optional SRTP with SDES? >> >>Wayne, Mark, >> >>thanks for the clarifications! >> >>David >> >>On Apr 17, 2006, at 2:07 PM, Wayne Mills ((wmills)) wrote: >> >> >>>I think Mark's comments were more aimed at your parenthetical ("in >>>principle anyway"). Sdescriptions has syntax (e.g. >>>"unencrypted_srtp") >>>to alter a crypto suite so that authentication is still >> >>enabled while >> >>>encryption is disabled, so it accomodates establishment of >> >>unencrypted >> >>>SRTP ( oxymoronic as that sounds :) ). >>> >>>Back to syntax, I think "a=security: " >> >>is better >> >>>than "a=encryption: ", due to the ability to >>>negotiate unencrypted SRTP. >>> >>>Regards, >>>Wayne >>> >>> >>>>>>>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 >>>> >>>>Sure, but SRTP with NULL encryption is not equivalent to RTP >>>>- turning off encryption is not the same as not doing SRTP. >>>>If I understand Rick correctly, this is why he's suggesting the >>>>additional "a=encryption" attribute. >>>> >>>>David >>>> >>>> >>>> >>>>>>Maybe "a=secure" would be better. >>>>>> >>>>>> >> > > From owner-ietf-rtpsec Tue Apr 18 16:51:16 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 k3INpGFN033746; Tue, 18 Apr 2006 16:51:16 -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 k3INpGWm033745; Tue, 18 Apr 2006 16:51:16 -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 k3INpESe033739 for ; Tue, 18 Apr 2006 16:51:14 -0700 (MST) (envelope-from wmills@cisco.com) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 18 Apr 2006 16:51:09 -0700 X-IronPort-AV: i="4.04,132,1144047600"; d="scan'208"; a="269533218:sNHT33370740" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3INp8Yg016355; Tue, 18 Apr 2006 16:51:08 -0700 (PDT) Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 19:51:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Optional SRTP with SDES? Date: Tue, 18 Apr 2006 19:51:06 -0400 Message-ID: <9EF3C46DC5D14D44B218FD5E93786CA201B9D98E@xmb-rtp-201.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optional SRTP with SDES? Thread-Index: AcZjP0c8eI9ZXwx2TUKCTea8DsTqDgAAyi6A From: "Wayne Mills \(wmills\)" To: "Robert R. Gilman" Cc: "Scott Cadzow" , "David McGrew \(mcgrew\)" , "Mark Baugher \(mbaugher\)" , "Rick Porter" , X-OriginalArrivalTime: 18 Apr 2006 23:51:07.0703 (UTC) FILETIME=[F6402C70:01C66342] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3INpESe033740 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Actually I like that even better! Simply adding a=crypto use to RTP/AVP gives us the semantics we want without defining new attributes, while leaving RTP/SAVP backward compatible with the current implementation. Regards, Wayne > -----Original Message----- > From: Robert R. Gilman [mailto:rrg@avaya.com] > Sent: Tuesday, April 18, 2006 7:25 PM > To: Wayne Mills (wmills) > Cc: Scott Cadzow; David McGrew (mcgrew); Mark Baugher > (mbaugher); Rick Porter; ietf-rtpsec@imc.org > Subject: Re: Optional SRTP with SDES? > > We've been thinking along the same lines. One thing we've > considered is the inclusion of a=crypto: lines in SDP/AVP to > permit optional SRTP/SRTCP or "plain old" RTP/RTCP. You'd > get the latter from any endpoint that didn't recognize the > crypto line(s), so this should be backward compatible. > If one wants to force SRTP, then one could place the crypto > lines in an SDP/SAVP record - any endpoint capable of SRTP > should recognize it. > The various options for SRTP would be controlled by > cryptosuites and parameters, as defined in sdescriptions. > Looked at this way, we might want to turn the a=crypto: line > into an a=srtp: line. > Does this make sense? > -Bob > ---------------------------------------------------- > Bob Gilman rrg@avaya.com +1 303 538 3868 > > Wayne Mills (wmills) wrote: > > Scott, > > > > See below for the reasoning on why encryption is too specific. > > > > Within the context of establishing an SRTP session, sdescriptions > > already provides syntax to negotiate confidentiality and > authenticity > > characteristics, no additional attributes needed for that. What we > > are trying to nail down is how to do profile "downgrade", > i.e., SRTP-->RTP. > > > > > > Heck, if it helps, the attribute can be brazenly specific: > > > > a=savp_usage: > > > > Regards, > > Wayne > > > > > >>-----Original Message----- > >>From: David McGrew (mcgrew) > >>Sent: Monday, April 17, 2006 5:17 PM > >>To: Wayne Mills (wmills); Mark Baugher (mbaugher) > >>Cc: Rick Porter; ietf-rtpsec@imc.org > >>Subject: Re: Optional SRTP with SDES? > >> > >>Wayne, Mark, > >> > >>thanks for the clarifications! > >> > >>David > >> > >>On Apr 17, 2006, at 2:07 PM, Wayne Mills ((wmills)) wrote: > >> > >> > >>>I think Mark's comments were more aimed at your parenthetical ("in > >>>principle anyway"). Sdescriptions has syntax (e.g. > >>>"unencrypted_srtp") > >>>to alter a crypto suite so that authentication is still > >> > >>enabled while > >> > >>>encryption is disabled, so it accomodates establishment of > >> > >>unencrypted > >> > >>>SRTP ( oxymoronic as that sounds :) ). > >>> > >>>Back to syntax, I think "a=security: " > >> > >>is better > >> > >>>than "a=encryption: ", due to the ability to > >>>negotiate unencrypted SRTP. > >>> > >>>Regards, > >>>Wayne > >>> > >>> > >>>>>>>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 > >>>> > >>>>Sure, but SRTP with NULL encryption is not equivalent to RTP > >>>>- turning off encryption is not the same as not doing SRTP. > >>>>If I understand Rick correctly, this is why he's suggesting the > >>>>additional "a=encryption" attribute. > >>>> > >>>>David > >>>> > >>>> > >>>> > >>>>>>Maybe "a=secure" would be better. > >>>>>> > >>>>>> > >> > > > > > From owner-ietf-rtpsec Wed Apr 19 01:37: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 k3J8bNY9057475; Wed, 19 Apr 2006 01:37: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 k3J8bNUi057474; Wed, 19 Apr 2006 01:37: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 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 k3J8bM9J057466 for ; Wed, 19 Apr 2006 01:37:23 -0700 (MST) (envelope-from csp@csperkins.org) Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61379 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FW8BY-0004ks-JN; Wed, 19 Apr 2006 09:37:16 +0100 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: Mark Baugher , ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: Requirements, First Date: Wed, 19 Apr 2006 09:37:14 +0100 To: Alan Johnston X-Mailer: Apple Mail (2.749.3) Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 15 Apr 2006, at 14:23, Alan Johnston wrote: ... > 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. Perhaps, but I'd also like to see an analysis of the impact this has on RTP and on the devices which use it. It's not clear that doing the signalling in-band with the media won't break other devices which make assumptions on the contents of a stream that are not valid when in-band keying extensions are used, even if those extensions are legal RTP (an example might be devices which require header compression and MTU matching the RTP packet size, which would likely have trouble with RTP header extensions). Colin From owner-ietf-rtpsec Wed Apr 19 05:52:13 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 k3JCqDDB070920; Wed, 19 Apr 2006 05:52:13 -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 k3JCqDkM070919; Wed, 19 Apr 2006 05:52:13 -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 nab.org (foxtrot.nab.org [209.116.240.194]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3JCqCjl070912 for ; Wed, 19 Apr 2006 05:52:13 -0700 (MST) (envelope-from aallison@nab.org) Received: from ([199.29.3.25]) by maildc2.nab.org with ESMTP id 4028857.9860054; Wed, 19 Apr 2006 08:52:00 -0400 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.7226.0 Subject: RE: Requirements, First Date: Wed, 19 Apr 2006 08:52:00 -0400 Message-ID: <33CB4DEADE8C734CAF59FA0B47E14C17017927E3@morse.NAB.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements, First Thread-Index: AcZjjeD8zXQ6ZnEiR8iphtugDJclQAAIPKcw From: "Allison, Art" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3JCqDjl070914 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At the requirements level: When addressing the security system capabilities, we should try to avoid creating a path for DRM-asserted material in a home from exiting the home via the 'IP-telephone' connection. Also while the focus is audio, today's consumers are considering video to be part of the 'call' and we should be cognizant of that. So each segment of content should only be sent if it is 'authorized' to be sent. It would seem appropriate for this level to simply enable signaling that the content is not to be further distributed (i.e. listened to only); or if it is storable once on the receiving device, or other DRM conditions. Avoiding additional ways for content to be improperly redistributed is 'goodness' from where I sit. _____________ Art Allison Director, Advanced Engineering Science & Technology National Association of Broadcasters 1771 N Street, NW Washington, D.C. 20036 Phone: 202.429.5418 Fax: 202.777.4981 aallison@nab.org The National Association of Broadcasters is a trade association that advocates on behalf of more than 8,300 free, local radio and television stations and also broadcast networks before Congress, the Federal Communications Commission and the Courts. From owner-ietf-rtpsec Wed Apr 19 08:07: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 k3JF7Emv078085; Wed, 19 Apr 2006 08:07: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 k3JF7EKN078084; Wed, 19 Apr 2006 08:07: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 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 k3JF7CjO078076 for ; Wed, 19 Apr 2006 08:07:13 -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); Wed, 19 Apr 2006 11:07:32 -0400 To: "Robert R. Gilman" Cc: "Wayne Mills (wmills)" , Scott Cadzow , "David McGrew (mcgrew)" , "Mark Baugher (mbaugher)" , Rick Porter , ietf-rtpsec@imc.org Subject: Re: Optional SRTP with SDES? References: <9EF3C46DC5D14D44B218FD5E93786CA201B9D56F@xmb-rtp-201.amer.cisco.com> <44457534.1080204@avaya.com> From: Randell Jesup Reply-to: Randell Jesup Date: Wed, 19 Apr 2006 11:08:44 -0400 In-Reply-To: <44457534.1080204@avaya.com> (Robert R. Gilman's message of "Tue, 18 Apr 2006 17:24:36 -0600") 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: 19 Apr 2006 15:07:32.0206 (UTC) FILETIME=[FB9180E0:01C663C2] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Robert R. Gilman" writes: >We've been thinking along the same lines. One thing we've considered is >the inclusion of a=crypto: lines in SDP/AVP to permit optional SRTP/SRTCP >or "plain old" RTP/RTCP. You'd get the latter from any endpoint that >didn't recognize the crypto line(s), so this should be backward compatible. >If one wants to force SRTP, then one could place the crypto lines in an >SDP/SAVP record - any endpoint capable of SRTP should recognize it. >The various options for SRTP would be controlled by cryptosuites and >parameters, as defined in sdescriptions. Looked at this way, we might >want to turn the a=crypto: line into an a=srtp: line. >Does this make sense? Yes, quite. It fits in with the "ignore a= lines you don't understand" mantra. Biggest danger will be that some endpoint will blindly (and wrongly) copy non-understood a= lines to a response - but I don't think that's a likely problem (too many other issues with doing something that wrong). The other issue that will come up will be that vendors of QoS-by-sniffing-SDP mechanisms will be upset that they can't be certain if an auth tag will be there until they see the response. I personally don't think that's a big issue. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com From owner-ietf-rtpsec Wed Apr 19 13:01: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 k3JK1AK6091262; Wed, 19 Apr 2006 13:01: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 k3JK1AWa091261; Wed, 19 Apr 2006 13:01: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 bemg01.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3JK18RF091252 for ; Wed, 19 Apr 2006 13:01:09 -0700 (MST) (envelope-from john.elwell@siemens.com) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IXZ00I01JMK00@siemenscomms.co.uk> for ietf-rtpsec@imc.org; Wed, 19 Apr 2006 21:01:32 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IXZ00DAGJMKH5@siemenscomms.co.uk>; Wed, 19 Apr 2006 21:01:32 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 19 Apr 2006 21:01:02 +0100 Content-return: allowed Date: Wed, 19 Apr 2006 21:01:01 +0100 From: "Elwell, John" Subject: RE: Requirements, First To: Francois Audet , Alan Johnston , ietf-rtpsec@imc.org Message-id: <50B1CBA96870A34799A506B2313F266708B78850@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Francois, Whether retargeting is a problem depends on the particular key management protocol used. But forking also can bring its problems, with or without retargeting (again depending on the key management protocol used). If an INVITE request forks to an arbitrary number of destinations, the UAC could be involved in lots of different key negotiations. Waiting for the 200 OK before attempting to decrypt received SRTP streams can lead to speech clipping. On the other hand using SDP answers in multiple 18x responses to perform any cryptographic transformations needed to receive SRTP streams can be a very heavy load on the UAC. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 18 April 2006 22:15 > To: Alan Johnston; ietf-rtpsec@imc.org > Subject: RE: Requirements, First > > > > - 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) > > Again: the bigger problem is not forking per se, but re-targetting. > > Key negotiation mechanism where a key is encrypted with the public > key of the initial target don't work with re-targeting because of the > non-anticipated respondent problem. > > Forking is often accompanied by re-targetting, of course, which > compounds > the problem. > From owner-ietf-rtpsec Thu Apr 20 15:18:18 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 k3KMIHB8059466; Thu, 20 Apr 2006 15:18:17 -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 k3KMIHPH059465; Thu, 20 Apr 2006 15:18:17 -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 k3KMIFlE059442 for ; Thu, 20 Apr 2006 15:18:16 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 20 Apr 2006 15:18:10 -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 k3KMIART006674; Thu, 20 Apr 2006 15:18:10 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Apr 2006 15:18:10 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Apr 2006 15:18:09 -0700 In-Reply-To: <44405030.1010901@sipstation.com> References: <44405030.1010901@sipstation.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: David McGrew Subject: requirements discussion Date: Thu, 20 Apr 2006 15:18:08 -0700 To: Alan Johnston X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 20 Apr 2006 22:18:09.0604 (UTC) FILETIME=[4E455040:01C664C8] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi 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. Sounds good. I believe that Dan Wing is going to write up his extensive slide set as a requirements ID - but our thread can provide him with some input ;-) > 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 agree that point-to-point is important enough that it deserves its own solution. (A nit here: RTP with multiple participants can be implemented without multicast, so the scope that we want to have is "SRTP sessions with exactly two participants".) > > - forking (copies of signaling may be sent to multiple devices, and > a single request may result in multiple sessions being established. Agreed, this case must be handled. > There can be no key sharing between these sessions) ... but I'm not convinced that this last point is a hard requirement. I'd really like to understand the forking scenarios better. The best example that I've heard is of the case in which both a phone and an answering machine might answer a single SIP offer, or perhaps two phones. In those cases, I would expect that the same media would be sent from the offerer's phone to the other two devices. (Otherwise, what would be sent to each of the sessions?) Is there an actual SIP/RTP application for which it is essential to provide confidentiality between the two tines of a fork? > > - 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) I've also heard that this is a requirement, though Jonathan Rosenberg suggested otherwise in the RAI discussion. IIUC, his point was that when ICE is used, then there can be no clipping of early media. I'm no expert in this area, so I will need to rely on others to provide input on how important the requirement is. > > - no requirement for PKI and certificates issued by a public CA. I agree that PKI shouldn't be required. However, I'd add that it is desirable for the key management method to be able to take advantage of a PKI wherever one happens to exist. > > I'd like to hear other's opinions on the requirements of this work. Some more requirements that are important: The key management method SHOULD contain a suite of crypto algorithms and protocols that are approved for use in FIPS-140-2, so that it is possible to certify implementations in that program. The key management method SHOULD be as computationally cheap as possible, in order to admit implementations on devices that are low cost and low power. The keying method SHOULD be able to use an authenticated-only external channel as the basis for security. This will allow the method to take advantage of authenticated signaling, and not require confidentiality of the signaling channel. (This point is important because digitally signed signaling is much more feasible than public- key encrypted signaling.) It MUST be possible to indicate the use of the keying method using SIP. It MUST be possible for the receiver of a SIP offer indicating the use of the keying method to determine whether or not the offer can be accepted. This requirement ensures that an offer that is accepted will not result in a failed crypto-negotiation by the keying method that causes a failed media session. (With this last point I'm channeling Flemming Andreasen. It is not hard to satisfy these requirements by providing "hints" in the SDP.) It SHOULD be possible to express the following alternative in a SIP offer: the keying method may be used for a particular media session, or it is acceptable to run RTP instead of SRTP. The keying method MUST either respect the key usage requirements laid down by RFC3711 (e.g. no sharing of SRTP master keys across multiple sessions), or explicitly describe how it deviates from and supersedes that specification. The keying method SHOULD be able to provide perfect forward secrecy PFS, but it SHOULD NOT require PFS, since PFS imposes key generation requirements that have a significant computational cost. Note that IKE's DH strategy of always communicating the public keys, but not requiring that those public keys always be freshly generated, meets this requirement by making PFS into a run-time option that does not affect security. The keying method MUST support cryptoalgorithm agility. The keying method SHOULD include a provision for allowing each participant to compute an authenticator value such that the equality of the values computed on each side ensures the security of the protocol. Implementations MAY display this value, so that it can be used in a verbal authentication procedure. > > This single method would be then be a *the* standard way of keying > SRTP. I think that you mean that it would be the standard way of keying SRTP for SIP and possibly other point-to-point protocols. ;-) > 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. > Good point, which suggests to me that we adopt a simple method (if we can find one :-) IMO, It would also be good to review the state of SIP security as well, but let's leave that for another thread. David > Thanks, > Alan From owner-ietf-rtpsec Thu Apr 20 16:07:28 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 k3KN7SYa061332; Thu, 20 Apr 2006 16:07:28 -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 k3KN7SWW061331; Thu, 20 Apr 2006 16:07:28 -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 zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3KN7Rc8061314 for ; Thu, 20 Apr 2006 16:07:28 -0700 (MST) (envelope-from audet@nortel.com) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3KN7I623128; Thu, 20 Apr 2006 19:07:19 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: requirements discussion Date: Thu, 20 Apr 2006 18:07:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF08E36350@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: requirements discussion Thread-Index: AcZkyX8pmZcMD7r5SSm80g0yGVuMewABELjw From: "Francois Audet" To: "David McGrew" , "Alan Johnston" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3KN7Sc8061326 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > - forking (copies of signaling may be sent to multiple devices, and > > a single request may result in multiple sessions being established. > > Agreed, this case must be handled. > > > There can be no key sharing between these sessions) > > ... but I'm not convinced that this last point is a hard > requirement. I'd really like to understand the forking scenarios > better. The best example that I've heard is of the case in which > both a phone and an answering machine might answer a single SIP > offer, or perhaps two phones. In those cases, I would expect that > the same media would be sent from the offerer's phone to the other > two devices. (Otherwise, what would be sent to each of the > sessions?) Is there an actual SIP/RTP application for which it is > essential to provide confidentiality between the two tines of a fork? Retargeting is when a Proxy (or other node) changes the Request-URI so that it now points to a different AOR that the request was originally sent to. It is often accompanied by forking, but they are different problems. The retargeting problem means that mechanims that rely on the sender knowing the public key of the initial target before sending the request will fail. Forking may include retargeting or not. For example: - Alice calls sip:bob@example.net, but the Call is forwarded to Bob's secretary sip:secretary@example.com. This is retargeting. - Alice calls Bob at sip:bob@example.net, and all of Bob's SIP phones (including one that may have an answering machine) ring. All of his device use the same sip:bob@example.net AOR. This is forking. - Alice calls Bob at sip:bob@example.net, and it rings all of Bob SIP phones plus a PSTN home phone and a PSTN mobile phone through gateways (sip:+1-408-555-1212@isp.net, sip:+1-408-555-0000@mobile.net). This is both retargeting (different AOR) and forking. From owner-ietf-rtpsec Thu Apr 20 16:13:24 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 k3KNDOrI061618; Thu, 20 Apr 2006 16:13:24 -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 k3KNDOUj061617; Thu, 20 Apr 2006 16:13:24 -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 zrtps0kn.nortel.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3KNDNUL061601 for ; Thu, 20 Apr 2006 16:13:23 -0700 (MST) (envelope-from audet@nortel.com) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3KNDFQ29540; Thu, 20 Apr 2006 19:13:15 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: requirements discussion Date: Thu, 20 Apr 2006 18:13:13 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF08E36366@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: requirements discussion Thread-Index: AcZkyX8pmZcMD7r5SSm80g0yGVuMewABal0Q From: "Francois Audet" To: "David McGrew" , "Alan Johnston" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3KNDNUL061612 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > - 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) > > I've also heard that this is a requirement, though Jonathan > Rosenberg > suggested otherwise in the RAI discussion. IIUC, his point was that > when ICE is used, then there can be no clipping of early media. I'm > no expert in this area, so I will need to rely on others to provide > input on how important the requirement is. I'm not sure that's what he said. I think what he said that with ICE, there is always some clipping. In any case, we probably need to distinguish between clipping that is unavoidable, versus introducing more clipping. Some of the current mechanisms for key negotiation are much more susceptive to additional significant clipping because they rely on the Sip signalling path for transmitting keys back from terminating side to sending side. Doing the negotiation in-band could reduce the clipping by making the negotiation faster than on the sip channel. From owner-ietf-rtpsec Thu Apr 20 16:27:40 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 k3KNRelM062099; Thu, 20 Apr 2006 16:27:40 -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 k3KNReqr062098; Thu, 20 Apr 2006 16:27:40 -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 k3KNRdQI062091 for ; Thu, 20 Apr 2006 16:27:39 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Apr 2006 16:27:33 -0700 X-IronPort-AV: i="4.04,142,1144047600"; d="scan'208"; a="1797223230:sNHT285736184" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3KNRWYg016225; Thu, 20 Apr 2006 16:27:33 -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, 20 Apr 2006 16:27:32 -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); Thu, 20 Apr 2006 16:27:32 -0700 In-Reply-To: References: <44405030.1010901@sipstation.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2F95C913-AF8A-4516-9D4D-EB2A26C3A9FB@cisco.com> Cc: Francois Audet Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: requirements discussion Date: Thu, 20 Apr 2006 16:27:30 -0700 To: ietf-rtpsec@imc.org X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 20 Apr 2006 23:27:32.0425 (UTC) FILETIME=[FF816390:01C664D1] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I forgot an important requirement: When the keying method is used to protect a SIP/SRTP application, the protected application MUST work in all NAT traversal scenarios in which the unprotected application works. Thanks Francois for the clarifications. David From owner-ietf-rtpsec Fri Apr 21 00:19:26 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 k3L7JQl0083357; Fri, 21 Apr 2006 00:19:26 -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 k3L7JQMg083356; Fri, 21 Apr 2006 00:19:26 -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 bemg01.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3L7JP7M083349 for ; Fri, 21 Apr 2006 00:19:25 -0700 (MST) (envelope-from john.elwell@siemens.com) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IY200C019P0HI@siemenscomms.co.uk> for ietf-rtpsec@imc.org; Fri, 21 Apr 2006 08:19:48 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IY20097Q9P0WQ@siemenscomms.co.uk>; Fri, 21 Apr 2006 08:19:48 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Apr 2006 08:19:18 +0100 Content-return: allowed Date: Fri, 21 Apr 2006 08:19:17 +0100 From: "Elwell, John" Subject: RE: requirements discussion To: David McGrew , Alan Johnston Cc: ietf-rtpsec@imc.org Message-id: <50B1CBA96870A34799A506B2313F266708B79187@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David, > > There can be no key sharing between these sessions) > > ... but I'm not convinced that this last point is a hard > requirement. I'd really like to understand the forking scenarios > better. The best example that I've heard is of the case in which > both a phone and an answering machine might answer a single SIP > offer, or perhaps two phones. In those cases, I would expect that > the same media would be sent from the offerer's phone to the other > two devices. (Otherwise, what would be sent to each of the > sessions?) Is there an actual SIP/RTP application for which it is > essential to provide confidentiality between the two tines of a fork? [JRE] When a call forks to several phones or other devices, there is a risk that it might not be answered by the person I wish to speak to. For example, an assistant or another family member may answer. The caller can probably verify that he is speaking to the right callee by voice recognition and then proceed to discuss confidential matters. If other devices are in possession of the same key, it makes it easier to hack into the call. John From owner-ietf-rtpsec Fri Apr 21 09:40:38 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 k3LGecEc005773; Fri, 21 Apr 2006 09:40:38 -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 k3LGeco1005772; Fri, 21 Apr 2006 09:40:38 -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-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3LGeZxk005765 for ; Fri, 21 Apr 2006 09:40:36 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 21 Apr 2006 09:40:31 -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 k3LGeURV026480; Fri, 21 Apr 2006 09:40:30 -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); Fri, 21 Apr 2006 09:40:30 -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); Fri, 21 Apr 2006 09:40:29 -0700 In-Reply-To: <50B1CBA96870A34799A506B2313F266708B79187@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266708B79187@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <714964DF-55C4-4495-939C-B2B3490B0A90@cisco.com> Cc: Alan Johnston , ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: requirements discussion Date: Fri, 21 Apr 2006 09:40:27 -0700 To: "Elwell, John" X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 21 Apr 2006 16:40:29.0762 (UTC) FILETIME=[4CE08220:01C66562] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi John, On Apr 21, 2006, at 12:19 AM, Elwell, John wrote: > David, > > >>> There can be no key sharing between these sessions) >> >> ... but I'm not convinced that this last point is a hard >> requirement. I'd really like to understand the forking scenarios >> better. The best example that I've heard is of the case in which >> both a phone and an answering machine might answer a single SIP >> offer, or perhaps two phones. In those cases, I would expect that >> the same media would be sent from the offerer's phone to the other >> two devices. (Otherwise, what would be sent to each of the >> sessions?) Is there an actual SIP/RTP application for which it is >> essential to provide confidentiality between the two tines of a fork? > [JRE] When a call forks to several phones or other devices, there > is a risk > that it might not be answered by the person I wish to speak to. For > example, > an assistant or another family member may answer. Agreed, this is a potential security issue. As an aside, it seems to me that, in order to really eliminate this issue, we would need to secure the signaling system. And of course there are fundamental limitations to the sort of endpoint-authentication assurance that we can provide. A telephony system can't defend against an attacker who breaks into a home or office and answers the phone (or steals a mobile phone). > The caller can probably > verify that he is speaking to the right callee by voice recognition > and then > proceed to discuss confidential matters. If other devices are in > possession > of the same key, it makes it easier to hack into the call. Agreed; so the threat is that if a symmetric key is included in a SIP message that is forked to two or more phones, then the phones that don't answer the call can perpetrate cryptographic attacks against the phone that does answer the call. This is a valid point, though I question whether it is so significant as to warrant a MUST NOT. We certainly don't want to share SRTP master keys in a forking scenario, since there would not be a way to meet the requirement for SSRC uniqueness (and this is probably what Alan meant in his suggested requirement). However, it is perfectly possible to share a key- encrypting key in a forking scenario without breaking SRTP. In many scenarios it is reasonable to trust each device in the set of endpoints to whom the offer will be forked, for example, if they are all within a particular enterprise, or within a particular home. Put another way, key sharing is the *only* way that an SRTP session with multiple participants can be set up, so it is going to be an aspect of some SRTP keying solutions. So it doesn't make sense to mandate that it should *never* be used in a forking scenario. My $0.02 anyway. David > > John From owner-ietf-rtpsec Fri Apr 21 12:44: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 k3LJiEY2013285; Fri, 21 Apr 2006 12:44: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 k3LJiEN1013284; Fri, 21 Apr 2006 12:44: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 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 k3LJiDAL013277 for ; Fri, 21 Apr 2006 12:44:13 -0700 (MST) (envelope-from mbaugher@cisco.com) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 21 Apr 2006 12:44:09 -0700 X-IronPort-AV: i="4.04,146,1144047600"; d="scan'208"; a="1797536699:sNHT44652550" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3LJi7VO025196; Fri, 21 Apr 2006 12:44:08 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 12:44:08 -0700 Received: from [192.168.0.10] ([10.21.152.246]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 12:44:07 -0700 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF08E36366@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF08E36366@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "David McGrew" , "Alan Johnston" , Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: requirements discussion Date: Fri, 21 Apr 2006 12:43:59 -0700 To: Francois Audet X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 21 Apr 2006 19:44:07.0688 (UTC) FILETIME=[F4129880:01C6657B] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Apr 20, 2006, at 4:13 PM, Francois Audet wrote: ... > > Doing the negotiation in-band could reduce the clipping by making the > negotiation faster than on the sip channel. Yes, it can do that unless the in-band negotiation is delayed until a protracted negotiation in the signaling channel such as ICE completes. That being said, I think _in-path_ (same path as the media) or in- band (same packets as the media) methods are worth considering. I favor an in-path approach over in-band although DTLS arguably makes the in-path and in-band distinction moot to the extent that it does port multiplexing. Whether it is an in-path/in-band _negotiation_ or not is another question. What is missing in the signaling is an acknowledgment from the offerer that it has installed a crypto context for the answerer's stream(s). Is this ack not the absolute minimum that is needed for media to commence at the earliest possible time? That I think is what we get from DTLS and the in-band EKT and ZRTP designs. Mark From owner-ietf-rtpsec Fri Apr 21 13:04:53 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 k3LK4qxN013993; Fri, 21 Apr 2006 13:04:52 -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 k3LK4q6P013992; Fri, 21 Apr 2006 13:04:52 -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-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3LK4qYj013985 for ; Fri, 21 Apr 2006 13:04:52 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2006 13:04:47 -0700 X-IronPort-AV: i="4.04,146,1144047600"; d="scan'208"; a="424856167:sNHT31562952" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3LK4kw1019079 for ; Fri, 21 Apr 2006 13:04:46 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 13:04:46 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 13:04:46 -0700 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <62B3BC2F-6940-4F49-9196-9533E3D1AE0D@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ietf-rtpsec@imc.org From: David McGrew Subject: RTP behavior with simultaneous SIP forking and media-before-answer Date: Fri, 21 Apr 2006 13:04:43 -0700 X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 21 Apr 2006 20:04:46.0493 (UTC) FILETIME=[D6753CD0:01C6657E] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I have a question about how SIP and RTP are expected to work together, which I'd like to understand better as part of our effort to design a better keying system for SRTP. I want to focus on the non-secured case in order to keep things simple. If we require our system to handle both "media before the SIP answer" and SIP forking, then we will have to handle scenarios like this: RTP/RTCP flows +--------+ | |<----- a ----- BobOne | |------ b ----> | Alice | | |<----- c ---- BobTwo | |------ d ----> +--------+ After Alice's SIP offer forks to BobOne and BobTwo, the latter two endpoints each send media flows (a and c) to Alice that reach her before their SIP answers do. The two flows a and c arriving on Alice's RTP destination port constitute a single RTP session, since an RTP endpoint distinguishes multiple RTP sessions by using different destination transport addresses (RFC3550, Section 3"), and in this case both flows are arriving on the same RTP port. Because there is a single session, Alice needs to send RTCP receiver reports describing both BobOne and BobTwo to both of those participants, as the flows b and d. (This is the way that SSRC collision detection would work in this session.) Presumably Alice would mix the media from flows a and c in this case, or would output both media flows as appropriate for the media type. Alternately, Alice might want to accept one flow and reject the other (e.g. she might accept only the first flow that reaches her). Accepting only one flow has the significant advantage that it relieves Alice of the burden of mixing or otherwise combining multiple media flows. But it raises the question of how she distinguishes between the sources. If she uses the SSRCs to do this, it may not be reliable, since e.g. flow "a" may contain multiple RTP sources, such as streams from multiple video cameras. She could use the source address to distinguish the flows, *if* the RTP layer is built so that it can convey that address along with the RTP packet. However, this behavior doesn't conform to RFC3550 AFAICT. So my question is: what are the admissible behaviors for Alice's RTP implementation? I'd also like to hear other interpretations of the specs, if there are any. Comments welcome. David From owner-ietf-rtpsec Fri Apr 21 13:58:47 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 k3LKwlMb016208; Fri, 21 Apr 2006 13:58:47 -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 k3LKwlOm016207; Fri, 21 Apr 2006 13:58:47 -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 k3LKwkr3016196 for ; Fri, 21 Apr 2006 13:58:46 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 21 Apr 2006 13:58:41 -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 k3LKwYRx023817 for ; Fri, 21 Apr 2006 13:58:41 -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); Fri, 21 Apr 2006 13:58:39 -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); Fri, 21 Apr 2006 13:58:39 -0700 In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF08E36366@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <689A7836-5646-428F-89F6-39F3BDDA9BAD@cisco.com> Cc: ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: requirements discussion Date: Fri, 21 Apr 2006 13:58:37 -0700 To: Mark Baugher X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 21 Apr 2006 20:58:39.0570 (UTC) FILETIME=[5D85A320:01C66586] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Mark, thanks for mentioning the in-path solution! Unless the requirements explain why it is undesirable to have keying method that is on-path but not in-band, security people will be continuously asking about it (since from a security perspective, it is a clean and obvious solution). My understanding is that the reason that it is undesirable to use a separate port for key management is because it would significantly complicate NAT traversal. David On Apr 21, 2006, at 12:43 PM, Mark Baugher wrote: > > On Apr 20, 2006, at 4:13 PM, Francois Audet wrote: > ... >> >> Doing the negotiation in-band could reduce the clipping by making the >> negotiation faster than on the sip channel. > > Yes, it can do that unless the in-band negotiation is delayed until > a protracted negotiation in the signaling channel such as ICE > completes. > > That being said, I think _in-path_ (same path as the media) or in- > band (same packets as the media) methods are worth considering. I > favor an in-path approach over in-band although DTLS arguably makes > the in-path and in-band distinction moot to the extent that it does > port multiplexing. > > Whether it is an in-path/in-band _negotiation_ or not is another > question. What is missing in the signaling is an acknowledgment > from the offerer that it has installed a crypto context for the > answerer's stream(s). Is this ack not the absolute minimum that is > needed for media to commence at the earliest possible time? That I > think is what we get from DTLS and the in-band EKT and ZRTP designs. > > Mark > From owner-ietf-rtpsec Fri Apr 21 15:04:08 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 k3LM48En018953; Fri, 21 Apr 2006 15:04: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 k3LM48f1018952; Fri, 21 Apr 2006 15:04: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 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 k3LM470D018945 for ; Fri, 21 Apr 2006 15:04:07 -0700 (MST) (envelope-from alan@sipstation.com) Received: from tcn003124.tcn-catv.ne.jp ([219.109.193.124] helo=[172.16.45.243]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FX3jS-000Es3-Mk; Fri, 21 Apr 2006 18:04:06 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 219.109.193.124 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: <444956D2.2000407@sipstation.com> Date: Fri, 21 Apr 2006 17:04:02 -0500 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David McGrew CC: Mark Baugher , ietf-rtpsec@imc.org Subject: Re: requirements discussion References: <1ECE0EB50388174790F9694F77522CCF08E36366@zrc2hxm0.corp.nortel.com> <689A7836-5646-428F-89F6-39F3BDDA9BAD@cisco.com> In-Reply-To: <689A7836-5646-428F-89F6-39F3BDDA9BAD@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, In theory, in-path might be cleaner than in-band. In practice, in-path is a complete non-starter that will make implementors go away and shake their heads. There is a reason why ICE is done in-band, and it has nothing to do with being clean or architecturally nice. It is because it is the only way that works through NATs and firewalls. Having to open more pinholes and maintain new NAT bindings, leading to new and interesting failure modes is not something we can do. I'd say a strong requirement is that any solution we come up with can not complicate the already complicated NAT/firewall traversal issue. As such, in-path is effectively ruled out. We have methods to get both SIP and RTP through NATs and firewalls but we can not now have to come up with a way to get protocol XYZ traversal to work as well. Thanks, Alan David McGrew wrote: > > Hi Mark, > > thanks for mentioning the in-path solution! Unless the requirements > explain why it is undesirable to have keying method that is on-path > but not in-band, security people will be continuously asking about it > (since from a security perspective, it is a clean and obvious > solution). My understanding is that the reason that it is > undesirable to use a separate port for key management is because it > would significantly complicate NAT traversal. > > David > > On Apr 21, 2006, at 12:43 PM, Mark Baugher wrote: > >> >> On Apr 20, 2006, at 4:13 PM, Francois Audet wrote: >> ... >> >>> >>> Doing the negotiation in-band could reduce the clipping by making the >>> negotiation faster than on the sip channel. >> >> >> Yes, it can do that unless the in-band negotiation is delayed until >> a protracted negotiation in the signaling channel such as ICE >> completes. >> >> That being said, I think _in-path_ (same path as the media) or in- >> band (same packets as the media) methods are worth considering. I >> favor an in-path approach over in-band although DTLS arguably makes >> the in-path and in-band distinction moot to the extent that it does >> port multiplexing. >> >> Whether it is an in-path/in-band _negotiation_ or not is another >> question. What is missing in the signaling is an acknowledgment >> from the offerer that it has installed a crypto context for the >> answerer's stream(s). Is this ack not the absolute minimum that is >> needed for media to commence at the earliest possible time? That I >> think is what we get from DTLS and the in-band EKT and ZRTP designs. >> >> Mark >> > > > From owner-ietf-rtpsec Fri Apr 21 15:06:33 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 k3LM6XKR019049; Fri, 21 Apr 2006 15:06:33 -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 k3LM6XbS019048; Fri, 21 Apr 2006 15:06:33 -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 k3LM6VfT019040 for ; Fri, 21 Apr 2006 15:06:32 -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; 21 Apr 2006 15:06:26 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k3LM6PRZ008900 for ; Fri, 21 Apr 2006 15:06:26 -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, 21 Apr 2006 15:06:21 -0700 Received: from [192.168.0.10] ([10.21.152.246]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 15:06:20 -0700 In-Reply-To: <689A7836-5646-428F-89F6-39F3BDDA9BAD@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF08E36366@zrc2hxm0.corp.nortel.com> <689A7836-5646-428F-89F6-39F3BDDA9BAD@cisco.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 discussion Date: Fri, 21 Apr 2006 15:06:12 -0700 To: David McGrew X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 21 Apr 2006 22:06:21.0021 (UTC) FILETIME=[D255E0D0:01C6658F] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hi David, On Apr 21, 2006, at 1:58 PM, David McGrew wrote: > Hi Mark, > > thanks for mentioning the in-path solution! Unless the > requirements explain why it is undesirable to have keying method > that is on-path but not in-band, security people will be > continuously asking about it (since from a security perspective, it > is a clean and obvious solution). My understanding is that the > reason that it is undesirable to use a separate port for key > management is because it would significantly complicate NAT traversal. I agree. If it weren't for NATs then we would not even be considering in-band designs IMHO because they significantly complicate RTP sessions. Even designs of very complex payload types such as MPEG-4 manage to convey their many dozens of bytes in the signaling channel - or most of it. So I am most interested in designs that are not in-band. I want to resist the idea that we need to trade protocol and application complexity for the number of ports used. Mark > > David > > On Apr 21, 2006, at 12:43 PM, Mark Baugher wrote: > >> >> On Apr 20, 2006, at 4:13 PM, Francois Audet wrote: >> ... >>> >>> Doing the negotiation in-band could reduce the clipping by making >>> the >>> negotiation faster than on the sip channel. >> >> Yes, it can do that unless the in-band negotiation is delayed >> until a protracted negotiation in the signaling channel such as >> ICE completes. >> >> That being said, I think _in-path_ (same path as the media) or in- >> band (same packets as the media) methods are worth considering. I >> favor an in-path approach over in-band although DTLS arguably >> makes the in-path and in-band distinction moot to the extent that >> it does port multiplexing. >> >> Whether it is an in-path/in-band _negotiation_ or not is another >> question. What is missing in the signaling is an acknowledgment >> from the offerer that it has installed a crypto context for the >> answerer's stream(s). Is this ack not the absolute minimum that >> is needed for media to commence at the earliest possible time? >> That I think is what we get from DTLS and the in-band EKT and ZRTP >> designs. >> >> Mark >> > From owner-ietf-rtpsec Fri Apr 21 15:11:57 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 k3LMBvu2019232; Fri, 21 Apr 2006 15:11:57 -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 k3LMBvoG019231; Fri, 21 Apr 2006 15:11:57 -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 k3LMBtwL019224 for ; Fri, 21 Apr 2006 15:11:55 -0700 (MST) (envelope-from mbaugher@cisco.com) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 21 Apr 2006 15:11:49 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3LMBnh0020937; Fri, 21 Apr 2006 15:11:49 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 15:11:49 -0700 Received: from [192.168.0.10] ([10.21.152.246]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 15:11:49 -0700 In-Reply-To: <444956D2.2000407@sipstation.com> References: <1ECE0EB50388174790F9694F77522CCF08E36366@zrc2hxm0.corp.nortel.com> <689A7836-5646-428F-89F6-39F3BDDA9BAD@cisco.com> <444956D2.2000407@sipstation.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1BE8AF90-E12A-4004-89B7-54EDFE11D744@cisco.com> Cc: David McGrew , ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: requirements discussion Date: Fri, 21 Apr 2006 15:11:40 -0700 To: Alan Johnston X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 21 Apr 2006 22:11:49.0250 (UTC) FILETIME=[95F9A620:01C66590] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hi Alan, On Apr 21, 2006, at 3:04 PM, Alan Johnston wrote: > Mark, > > In theory, in-path might be cleaner than in-band. > > In practice, in-path is a complete non-starter that will make > implementors go away and shake their heads. There is a reason why > ICE is done in-band, and it has nothing to do with being clean or > architecturally nice. It is because it is the only way that works > through NATs and firewalls. > > Having to open more pinholes and maintain new NAT bindings, leading > to new and interesting failure modes is not something we can do. > > I'd say a strong requirement is that any solution we come up with > can not complicate the already complicated NAT/firewall traversal > issue. As such, in-path is effectively ruled out. As I suggested in my note, DTLS seems to have the benefits of both in- band and in-path. But I think that there is benefit to running SRTP to separate ports. Still, it seems incredible to argue that in-band solves the so-called early media problem and at the same time demand that we support ICE, which is going to do multiple signaling round trips before media addresses are resolved and in-band methods can be performed. Mark > We have methods to get both SIP and RTP through NATs and > firewalls but we can not now have to come up with a way to get > protocol XYZ traversal to work as well. > > Thanks, > Alan > > David McGrew wrote: > >> >> Hi Mark, >> >> thanks for mentioning the in-path solution! Unless the >> requirements explain why it is undesirable to have keying method >> that is on-path but not in-band, security people will be >> continuously asking about it (since from a security perspective, >> it is a clean and obvious solution). My understanding is that >> the reason that it is undesirable to use a separate port for key >> management is because it would significantly complicate NAT >> traversal. >> >> David >> >> On Apr 21, 2006, at 12:43 PM, Mark Baugher wrote: >> >>> >>> On Apr 20, 2006, at 4:13 PM, Francois Audet wrote: >>> ... >>> >>>> >>>> Doing the negotiation in-band could reduce the clipping by >>>> making the >>>> negotiation faster than on the sip channel. >>> >>> >>> Yes, it can do that unless the in-band negotiation is delayed >>> until a protracted negotiation in the signaling channel such as >>> ICE completes. >>> >>> That being said, I think _in-path_ (same path as the media) or >>> in- band (same packets as the media) methods are worth >>> considering. I favor an in-path approach over in-band although >>> DTLS arguably makes the in-path and in-band distinction moot to >>> the extent that it does port multiplexing. >>> >>> Whether it is an in-path/in-band _negotiation_ or not is another >>> question. What is missing in the signaling is an acknowledgment >>> from the offerer that it has installed a crypto context for the >>> answerer's stream(s). Is this ack not the absolute minimum that >>> is needed for media to commence at the earliest possible time? >>> That I think is what we get from DTLS and the in-band EKT and >>> ZRTP designs. >>> >>> Mark >>> >> >> >> From owner-ietf-rtpsec Sat Apr 22 12:24: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 k3MJOhps064330; Sat, 22 Apr 2006 12:24: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 k3MJOhWn064329; Sat, 22 Apr 2006 12:24: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 bemg01.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3MJOf1R064322 for ; Sat, 22 Apr 2006 12:24:42 -0700 (MST) (envelope-from john.elwell@siemens.com) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IY500A011XSHF@siemenscomms.co.uk> for ietf-rtpsec@imc.org; Sat, 22 Apr 2006 20:25:04 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IY5000941XSRN@siemenscomms.co.uk>; Sat, 22 Apr 2006 20:25:04 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sat, 22 Apr 2006 20:24:34 +0100 Content-return: allowed Date: Sat, 22 Apr 2006 20:24:34 +0100 From: "Elwell, John" Subject: RE: requirements discussion To: David McGrew Cc: Alan Johnston , ietf-rtpsec@imc.org Message-id: <50B1CBA96870A34799A506B2313F266708BBC425@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David, In-line John > -----Original Message----- > From: David McGrew [mailto:mcgrew@cisco.com] > Sent: 21 April 2006 17:40 > To: Elwell, John > Cc: Alan Johnston; ietf-rtpsec@imc.org > Subject: Re: requirements discussion > > Hi John, > > On Apr 21, 2006, at 12:19 AM, Elwell, John wrote: > > > David, > > > > > >>> There can be no key sharing between these sessions) > >> > >> ... but I'm not convinced that this last point is a hard > >> requirement. I'd really like to understand the forking scenarios > >> better. The best example that I've heard is of the case in which > >> both a phone and an answering machine might answer a single SIP > >> offer, or perhaps two phones. In those cases, I would expect that > >> the same media would be sent from the offerer's phone to the other > >> two devices. (Otherwise, what would be sent to each of the > >> sessions?) Is there an actual SIP/RTP application for which it is > >> essential to provide confidentiality between the two tines > of a fork? > > [JRE] When a call forks to several phones or other devices, there > > is a risk > > that it might not be answered by the person I wish to speak > to. For > > example, > > an assistant or another family member may answer. > > Agreed, this is a potential security issue. As an aside, it > seems to > me that, in order to really eliminate this issue, we would need to > secure the signaling system. And of course there are fundamental > limitations to the sort of endpoint-authentication assurance that we > can provide. A telephony system can't defend against an > attacker who > breaks into a home or office and answers the phone (or steals a > mobile phone). > > > The caller can probably > > verify that he is speaking to the right callee by voice > recognition > > and then > > proceed to discuss confidential matters. If other devices are in > > possession > > of the same key, it makes it easier to hack into the call. > > Agreed; so the threat is that if a symmetric key is included > in a SIP > message that is forked to two or more phones, then the phones that > don't answer the call can perpetrate cryptographic attacks against > the phone that does answer the call. This is a valid point, > though I > question whether it is so significant as to warrant a MUST NOT. We > certainly don't want to share SRTP master keys in a forking > scenario, > since there would not be a way to meet the requirement for SSRC > uniqueness (and this is probably what Alan meant in his suggested > requirement). However, it is perfectly possible to share a key- > encrypting key in a forking scenario without breaking SRTP. In many > scenarios it is reasonable to trust each device in the set of > endpoints to whom the offer will be forked, for example, if they are > all within a particular enterprise, or within a particular home. [JRE] Sometimes it will extend outside the enterprise or home, e.g., when a mobile user logs on at a visited endpoint that registers on his behalf with the user's home domain. Also there is a school of thought that attacks within an enterprise very often stem from inside the enterprise rather than outside. > > Put another way, key sharing is the *only* way that an SRTP session > with multiple participants can be set up, so it is going to be an > aspect of some SRTP keying solutions. So it doesn't make sense to > mandate that it should *never* be used in a forking scenario. My > $0.02 anyway. [JRE] A D-H approach could satisfy the requirement for point-to-point sessions, where forking occurs during session establishment. > > David > > > > > John > From owner-ietf-rtpsec Sun Apr 23 03:29: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 k3NATRGM092346; Sun, 23 Apr 2006 03:29: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 k3NATRkI092345; Sun, 23 Apr 2006 03:29: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 bemg01.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3NATQ4i092335 for ; Sun, 23 Apr 2006 03:29:26 -0700 (MST) (envelope-from john.elwell@siemens.com) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IY600K017TP9Z@siemenscomms.co.uk> for ietf-rtpsec@imc.org; Sun, 23 Apr 2006 11:29:49 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IY600D7E7TP60@siemenscomms.co.uk>; Sun, 23 Apr 2006 11:29:49 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sun, 23 Apr 2006 11:29:19 +0100 Content-return: allowed Date: Sun, 23 Apr 2006 11:29:19 +0100 From: "Elwell, John" Subject: RE: RTP behavior with simultaneous SIP forking and media-before-a nswer To: David McGrew , ietf-rtpsec@imc.org Message-id: <50B1CBA96870A34799A506B2313F266708BBC434@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David, This is indeed a hard problem for which the RFCs don't provide much help. If we forget early media, then this is most likely going to arise when BobOne and BobTwo answer at about the same time. The two RTP streams will arrive at Alice in no defined order, and a short time later the two 2xx responses will arrive. Alice's UA will probably wish to keep only one of these dialog/sessions and will BYE the other one, and hence will wish to accept only one RTP streams, a or c. The problem is how to determine which RTP stream corresponds to the dialog that has been retained and which corresponds to the dialog that has been cleared. Eventually one of the RTP streams will cease, but that is too long to wait. So what does Alice's UA do: 1) after receipt of the first 2xx response while both a and c are being received? It may or may not be able to distinguish based on source IP address (this relies on the source IP address being the same as the destination IP address for RTP in the opposite direction, as advertised in the SDP answer). 2) between receipt of a and c and receipt of the first 2xx response? Alice's UA has no way of knowing which one will relate to the first 2xx response received. So it might just pick the first one, or mix the two, or even ignore both. The last action would, of course, be forced upon Alice's UA for the SRTP case if it requires keying material from the 2xx before it can decode a or c. John > -----Original Message----- > From: David McGrew [mailto:mcgrew@cisco.com] > Sent: 21 April 2006 21:05 > To: ietf-rtpsec@imc.org > Subject: RTP behavior with simultaneous SIP forking and > media-before-answer > > > Hello, > > I have a question about how SIP and RTP are expected to work > together, which I'd like to understand better as part of our effort > to design a better keying system for SRTP. I want to focus on the > non-secured case in order to keep things simple. If we require our > system to handle both "media before the SIP answer" and SIP forking, > then we will have to handle scenarios like this: > > RTP/RTCP flows > +--------+ > | |<----- a ----- BobOne > | |------ b ----> > | Alice | > | |<----- c ---- BobTwo > | |------ d ----> > +--------+ > > After Alice's SIP offer forks to BobOne and BobTwo, the latter two > endpoints each send media flows (a and c) to Alice that reach her > before their SIP answers do. > > The two flows a and c arriving on Alice's RTP destination port > constitute a single RTP session, since an RTP endpoint distinguishes > multiple RTP sessions by using different destination transport > addresses (RFC3550, Section 3"), and in this case both flows are > arriving on the same RTP port. Because there is a single session, > Alice needs to send RTCP receiver reports describing both BobOne and > BobTwo to both of those participants, as the flows b and d. > (This is > the way that SSRC collision detection would work in this session.) > Presumably Alice would mix the media from flows a and c in > this case, > or would output both media flows as appropriate for the media type. > > Alternately, Alice might want to accept one flow and reject > the other > (e.g. she might accept only the first flow that reaches her). > Accepting only one flow has the significant advantage that it > relieves Alice of the burden of mixing or otherwise combining > multiple media flows. But it raises the question of how she > distinguishes between the sources. If she uses the SSRCs to > do this, > it may not be reliable, since e.g. flow "a" may contain multiple RTP > sources, such as streams from multiple video cameras. She could use > the source address to distinguish the flows, *if* the RTP layer is > built so that it can convey that address along with the RTP packet. > However, this behavior doesn't conform to RFC3550 AFAICT. > > So my question is: what are the admissible behaviors for Alice's RTP > implementation? I'd also like to hear other interpretations of the > specs, if there are any. Comments welcome. > > David > From owner-ietf-rtpsec Mon Apr 24 06:02: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 k3OD22Xk049453; Mon, 24 Apr 2006 06:02:02 -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 k3OD226Q049452; Mon, 24 Apr 2006 06:02:02 -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 k3OD217t049439 for ; Mon, 24 Apr 2006 06:02:01 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-3.cisco.com with ESMTP; 24 Apr 2006 06:01:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3OD1tw1020106; Mon, 24 Apr 2006 06:01:55 -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); Mon, 24 Apr 2006 06:01:55 -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, 24 Apr 2006 06:01:54 -0700 In-Reply-To: <50B1CBA96870A34799A506B2313F266708BBC425@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266708BBC425@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33341245-CE7A-4960-9F6E-56B4A0809548@cisco.com> Cc: Alan Johnston , ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: requirements discussion Date: Mon, 24 Apr 2006 06:01:51 -0700 To: "Elwell, John" X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 24 Apr 2006 13:01:54.0807 (UTC) FILETIME=[42FE7070:01C6679F] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John, On Apr 22, 2006, at 12:24 PM, Elwell, John wrote: > David, > > In-line > > John > >> -----Original Message----- >> From: David McGrew [mailto:mcgrew@cisco.com] >> Sent: 21 April 2006 17:40 >> To: Elwell, John >> Cc: Alan Johnston; ietf-rtpsec@imc.org >> Subject: Re: requirements discussion >> >> Hi John, >> >> On Apr 21, 2006, at 12:19 AM, Elwell, John wrote: >> >>> David, >>> >>> >>>>> There can be no key sharing between these sessions) >>>> >>>> ... but I'm not convinced that this last point is a hard >>>> requirement. I'd really like to understand the forking scenarios >>>> better. The best example that I've heard is of the case in which >>>> both a phone and an answering machine might answer a single SIP >>>> offer, or perhaps two phones. In those cases, I would expect that >>>> the same media would be sent from the offerer's phone to the other >>>> two devices. (Otherwise, what would be sent to each of the >>>> sessions?) Is there an actual SIP/RTP application for which it is >>>> essential to provide confidentiality between the two tines >> of a fork? >>> [JRE] When a call forks to several phones or other devices, there >>> is a risk >>> that it might not be answered by the person I wish to speak >> to. For >>> example, >>> an assistant or another family member may answer. >> >> Agreed, this is a potential security issue. As an aside, it >> seems to >> me that, in order to really eliminate this issue, we would need to >> secure the signaling system. And of course there are fundamental >> limitations to the sort of endpoint-authentication assurance that we >> can provide. A telephony system can't defend against an >> attacker who >> breaks into a home or office and answers the phone (or steals a >> mobile phone). >> >>> The caller can probably >>> verify that he is speaking to the right callee by voice >> recognition >>> and then >>> proceed to discuss confidential matters. If other devices are in >>> possession >>> of the same key, it makes it easier to hack into the call. >> >> Agreed; so the threat is that if a symmetric key is included >> in a SIP >> message that is forked to two or more phones, then the phones that >> don't answer the call can perpetrate cryptographic attacks against >> the phone that does answer the call. This is a valid point, >> though I >> question whether it is so significant as to warrant a MUST NOT. We >> certainly don't want to share SRTP master keys in a forking >> scenario, >> since there would not be a way to meet the requirement for SSRC >> uniqueness (and this is probably what Alan meant in his suggested >> requirement). However, it is perfectly possible to share a key- >> encrypting key in a forking scenario without breaking SRTP. In many >> scenarios it is reasonable to trust each device in the set of >> endpoints to whom the offer will be forked, for example, if they are >> all within a particular enterprise, or within a particular home. > [JRE] Sometimes it will extend outside the enterprise or home, > e.g., when a > mobile user logs on at a visited endpoint that registers on his > behalf with > the user's home domain. Is there a specification for doing that sort of mobility using SIP? > Also there is a school of thought that attacks > within an enterprise very often stem from inside the enterprise > rather than > outside. > >> >> Put another way, key sharing is the *only* way that an SRTP session >> with multiple participants can be set up, so it is going to be an >> aspect of some SRTP keying solutions. So it doesn't make sense to >> mandate that it should *never* be used in a forking scenario. My >> $0.02 anyway. > [JRE] A D-H approach could satisfy the requirement for point-to-point > sessions, where forking occurs during session establishment. Sure, but the satisfiability of the requirement doesn't imply that we actually are faced with the requirement. David From owner-ietf-rtpsec Mon Apr 24 06:19:17 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 k3ODJH5C050033; Mon, 24 Apr 2006 06:19:17 -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 k3ODJH3J050032; Mon, 24 Apr 2006 06:19:17 -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 k3ODJEuT050025 for ; Mon, 24 Apr 2006 06:19:16 -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; 24 Apr 2006 06:19:09 -0700 X-IronPort-AV: i="4.04,152,1144047600"; d="scan'208"; a="270640547:sNHT33124252" 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 k3ODJ8VI024972; Mon, 24 Apr 2006 06:19:09 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 06:19:08 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 06:19:08 -0700 In-Reply-To: <50B1CBA96870A34799A506B2313F266708BBC434@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266708BBC434@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E083C30-DA77-4029-8648-54C6AC0A905A@cisco.com> Cc: ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: RTP behavior with simultaneous SIP forking and media-before-a nswer Date: Mon, 24 Apr 2006 06:19:04 -0700 To: "Elwell, John" X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 24 Apr 2006 13:19:08.0177 (UTC) FILETIME=[AAEE3010:01C667A1] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John, good points - I had been focused on RTP, but the endpoint behavior with respect to signaling needs to be considered as well. It will be important for us ("us" in the broader sense :-) to establish what RTP/ SIP behaviors need to be supported, as an input to the key management requirements. A couple of questions inline: On Apr 23, 2006, at 3:29 AM, Elwell, John wrote: > David, > > This is indeed a hard problem for which the RFCs don't provide much > help. If > we forget early media, then this is most likely going to arise when > BobOne > and BobTwo answer at about the same time. The two RTP streams will > arrive at > Alice in no defined order, and a short time later the two 2xx > responses will > arrive. Alice's UA will probably wish to keep only one of these > dialog/sessions and will BYE the other one, and hence will wish to > accept > only one RTP streams, a or c. The problem is how to determine which > RTP > stream corresponds to the dialog that has been retained and which > corresponds to the dialog that has been cleared. Eventually one of > the RTP > streams will cease, but that is too long to wait. So what does > Alice's UA > do: > 1) after receipt of the first 2xx response while both a and c are > being > received? It may or may not be able to distinguish based on source IP > address (this relies on the source IP address being the same as the > destination IP address for RTP in the opposite direction, as > advertised in > the SDP answer). This would also rely on the IP addresses being accessible at the RTP layer. Is this an acceptable assumption? > 2) between receipt of a and c and receipt of the first 2xx > response? Alice's > UA has no way of knowing which one will relate to the first 2xx > response > received. So it might just pick the first one, or mix the two, or even > ignore both. The last action would, of course, be forced upon > Alice's UA for > the SRTP case if it requires keying material from the 2xx before it > can > decode a or c. In the case where the media is mixed, would that be a single RTP session, or would it be two sessions that happened to arrive on the same destination port? We can come up with a secure solution either way, I'm sure, but the solutions would be different in either case. David > > John > >> -----Original Message----- >> From: David McGrew [mailto:mcgrew@cisco.com] >> Sent: 21 April 2006 21:05 >> To: ietf-rtpsec@imc.org >> Subject: RTP behavior with simultaneous SIP forking and >> media-before-answer >> >> >> Hello, >> >> I have a question about how SIP and RTP are expected to work >> together, which I'd like to understand better as part of our effort >> to design a better keying system for SRTP. I want to focus on the >> non-secured case in order to keep things simple. If we require our >> system to handle both "media before the SIP answer" and SIP forking, >> then we will have to handle scenarios like this: >> >> RTP/RTCP flows >> +--------+ >> | |<----- a ----- BobOne >> | |------ b ----> >> | Alice | >> | |<----- c ---- BobTwo >> | |------ d ----> >> +--------+ >> >> After Alice's SIP offer forks to BobOne and BobTwo, the latter two >> endpoints each send media flows (a and c) to Alice that reach her >> before their SIP answers do. >> >> The two flows a and c arriving on Alice's RTP destination port >> constitute a single RTP session, since an RTP endpoint distinguishes >> multiple RTP sessions by using different destination transport >> addresses (RFC3550, Section 3"), and in this case both flows are >> arriving on the same RTP port. Because there is a single session, >> Alice needs to send RTCP receiver reports describing both BobOne and >> BobTwo to both of those participants, as the flows b and d. >> (This is >> the way that SSRC collision detection would work in this session.) >> Presumably Alice would mix the media from flows a and c in >> this case, >> or would output both media flows as appropriate for the media type. >> >> Alternately, Alice might want to accept one flow and reject >> the other >> (e.g. she might accept only the first flow that reaches her). >> Accepting only one flow has the significant advantage that it >> relieves Alice of the burden of mixing or otherwise combining >> multiple media flows. But it raises the question of how she >> distinguishes between the sources. If she uses the SSRCs to >> do this, >> it may not be reliable, since e.g. flow "a" may contain multiple RTP >> sources, such as streams from multiple video cameras. She could use >> the source address to distinguish the flows, *if* the RTP layer is >> built so that it can convey that address along with the RTP packet. >> However, this behavior doesn't conform to RFC3550 AFAICT. >> >> So my question is: what are the admissible behaviors for Alice's RTP >> implementation? I'd also like to hear other interpretations of the >> specs, if there are any. Comments welcome. >> >> David >> From owner-ietf-rtpsec Mon Apr 24 07:13:07 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 k3OED73K052638; Mon, 24 Apr 2006 07:13:07 -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 k3OED7Uu052637; Mon, 24 Apr 2006 07:13:07 -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 k3OED6j9052630 for ; Mon, 24 Apr 2006 07:13:07 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 24 Apr 2006 07:13:01 -0700 X-IronPort-AV: i="4.04,152,1144047600"; d="scan'208"; a="1798048155:sNHT35007828" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3OED1Yg012489; Mon, 24 Apr 2006 07:13:01 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 07:13:01 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 07:13:00 -0700 In-Reply-To: References: <44405030.1010901@sipstation.com> <35337CB5-56C9-4304-9CB1-4A2DC0A2D50D@cisco.com> <4440F3DE.8060401@sipstation.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6403EE4C-E2ED-4604-8100-DA6A2C52BC9C@cisco.com> Cc: ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: Requirements, First Date: Mon, 24 Apr 2006 07:12:56 -0700 To: Colin Perkins X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 24 Apr 2006 14:13:00.0567 (UTC) FILETIME=[3195C270:01C667A9] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Colin, On Apr 19, 2006, at 1:37 AM, Colin Perkins wrote: > > On 15 Apr 2006, at 14:23, Alan Johnston wrote: > ... >> 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. > > Perhaps, but I'd also like to see an analysis of the impact this > has on RTP and on the devices which use it. It's not clear that > doing the signalling in-band with the media won't break other > devices which make assumptions on the contents of a stream that are > not valid when in-band keying extensions are used, even if those > extensions are legal RTP (an example might be devices which require > header compression and MTU matching the RTP packet size, which > would likely have trouble with RTP header extensions). > I asked a few firewall implementers about RTP in-band keying. It seems as though all of the in-band methods would have trouble passing through firewalls that do RTP conformance checking. Firewalls would need to be updated in order for firewall traversal to work properly. (As an aside, it seems like the header extension method would get past the most firewalls, though any method which didn't change the RTP header would do just as well.) The approach that Mark mentioned on this thread - end-to-end keying that's on-path but not in-band - would have the advantages that Alan cites above, but would also have issues with NAT. It seems that the VoIP community is willing to trade NAT traversal problems for FW traversal problems :-) David From owner-ietf-rtpsec Mon Apr 24 13:26: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 k3OKQUGO068894; Mon, 24 Apr 2006 13:26:30 -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 k3OKQUXT068893; Mon, 24 Apr 2006 13:26:30 -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 bemg01.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3OKQSGp068887 for ; Mon, 24 Apr 2006 13:26:29 -0700 (MST) (envelope-from john.elwell@siemens.com) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IY800E01U4RV0@siemenscomms.co.uk> for ietf-rtpsec@imc.org; Mon, 24 Apr 2006 21:26:51 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IY800C6JU4RFT@siemenscomms.co.uk>; Mon, 24 Apr 2006 21:26:51 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 24 Apr 2006 21:26:21 +0100 Content-return: allowed Date: Mon, 24 Apr 2006 21:26:12 +0100 From: "Elwell, John" Subject: RE: requirements discussion To: David McGrew Cc: Alan Johnston , ietf-rtpsec@imc.org Message-id: <50B1CBA96870A34799A506B2313F266708BBCFF6@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David, See below. John > -----Original Message----- > From: David McGrew [mailto:mcgrew@cisco.com] > Sent: 24 April 2006 14:02 > To: Elwell, John > Cc: Alan Johnston; ietf-rtpsec@imc.org > Subject: Re: requirements discussion > > John, > > On Apr 22, 2006, at 12:24 PM, Elwell, John wrote: > > > David, > > > > In-line > > > > John > > > >> -----Original Message----- > >> From: David McGrew [mailto:mcgrew@cisco.com] > >> Sent: 21 April 2006 17:40 > >> To: Elwell, John > >> Cc: Alan Johnston; ietf-rtpsec@imc.org > >> Subject: Re: requirements discussion > >> > >> Hi John, > >> > >> On Apr 21, 2006, at 12:19 AM, Elwell, John wrote: > >> > >>> David, > >>> > >>> > >>>>> There can be no key sharing between these sessions) > >>>> > >>>> ... but I'm not convinced that this last point is a hard > >>>> requirement. I'd really like to understand the forking scenarios > >>>> better. The best example that I've heard is of the case in which > >>>> both a phone and an answering machine might answer a single SIP > >>>> offer, or perhaps two phones. In those cases, I would > expect that > >>>> the same media would be sent from the offerer's phone to > the other > >>>> two devices. (Otherwise, what would be sent to each of the > >>>> sessions?) Is there an actual SIP/RTP application for > which it is > >>>> essential to provide confidentiality between the two tines > >> of a fork? > >>> [JRE] When a call forks to several phones or other devices, there > >>> is a risk > >>> that it might not be answered by the person I wish to speak > >> to. For > >>> example, > >>> an assistant or another family member may answer. > >> > >> Agreed, this is a potential security issue. As an aside, it > >> seems to > >> me that, in order to really eliminate this issue, we would need to > >> secure the signaling system. And of course there are fundamental > >> limitations to the sort of endpoint-authentication > assurance that we > >> can provide. A telephony system can't defend against an > >> attacker who > >> breaks into a home or office and answers the phone (or steals a > >> mobile phone). > >> > >>> The caller can probably > >>> verify that he is speaking to the right callee by voice > >> recognition > >>> and then > >>> proceed to discuss confidential matters. If other devices are in > >>> possession > >>> of the same key, it makes it easier to hack into the call. > >> > >> Agreed; so the threat is that if a symmetric key is included > >> in a SIP > >> message that is forked to two or more phones, then the phones that > >> don't answer the call can perpetrate cryptographic attacks against > >> the phone that does answer the call. This is a valid point, > >> though I > >> question whether it is so significant as to warrant a MUST NOT. We > >> certainly don't want to share SRTP master keys in a forking > >> scenario, > >> since there would not be a way to meet the requirement for SSRC > >> uniqueness (and this is probably what Alan meant in his suggested > >> requirement). However, it is perfectly possible to share a key- > >> encrypting key in a forking scenario without breaking > SRTP. In many > >> scenarios it is reasonable to trust each device in the set of > >> endpoints to whom the offer will be forked, for example, > if they are > >> all within a particular enterprise, or within a particular home. > > [JRE] Sometimes it will extend outside the enterprise or home, > > e.g., when a > > mobile user logs on at a visited endpoint that registers on his > > behalf with > > the user's home domain. > > Is there a specification for doing that sort of mobility using SIP? [JRE] I don't believe it is precluded. > > > Also there is a school of thought that attacks > > within an enterprise very often stem from inside the enterprise > > rather than > > outside. > > > >> > >> Put another way, key sharing is the *only* way that an SRTP session > >> with multiple participants can be set up, so it is going to be an > >> aspect of some SRTP keying solutions. So it doesn't make sense to > >> mandate that it should *never* be used in a forking scenario. My > >> $0.02 anyway. > > [JRE] A D-H approach could satisfy the requirement for > point-to-point > > sessions, where forking occurs during session establishment. > > Sure, but the satisfiability of the requirement doesn't imply > that we > actually are faced with the requirement. [JRE] Perhaps not, but I thought you were arguing that the absence of a solution would mean that we should not have a requirement. I was pointing out that there might be a potential solution, so we can consider whether this matter is important enough to make it a requirement. > > David > From owner-ietf-rtpsec Mon Apr 24 13:31:18 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 k3OKVIbH069009; Mon, 24 Apr 2006 13:31:18 -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 k3OKVIsO069008; Mon, 24 Apr 2006 13:31:18 -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 bemg01.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3OKVHa4069002 for ; Mon, 24 Apr 2006 13:31:17 -0700 (MST) (envelope-from john.elwell@siemens.com) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IY800G01UCT7S@siemenscomms.co.uk> for ietf-rtpsec@imc.org; Mon, 24 Apr 2006 21:31:41 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IY800C8QUCSFT@siemenscomms.co.uk>; Mon, 24 Apr 2006 21:31:40 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 24 Apr 2006 21:31:10 +0100 Content-return: allowed Date: Mon, 24 Apr 2006 21:31:09 +0100 From: "Elwell, John" Subject: RE: RTP behavior with simultaneous SIP forking and media-before-a nswer To: David McGrew Cc: ietf-rtpsec@imc.org Message-id: <50B1CBA96870A34799A506B2313F266708BBCFF8@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David, See below. John > -----Original Message----- > From: David McGrew [mailto:mcgrew@cisco.com] > Sent: 24 April 2006 14:19 > To: Elwell, John > Cc: ietf-rtpsec@imc.org > Subject: Re: RTP behavior with simultaneous SIP forking and > media-before-a nswer > > John, > > good points - I had been focused on RTP, but the endpoint behavior > with respect to signaling needs to be considered as well. It > will be > important for us ("us" in the broader sense :-) to establish > what RTP/ > SIP behaviors need to be supported, as an input to the key > management > requirements. > > A couple of questions inline: > > On Apr 23, 2006, at 3:29 AM, Elwell, John wrote: > > > David, > > > > This is indeed a hard problem for which the RFCs don't > provide much > > help. If > > we forget early media, then this is most likely going to > arise when > > BobOne > > and BobTwo answer at about the same time. The two RTP streams will > > arrive at > > Alice in no defined order, and a short time later the two 2xx > > responses will > > arrive. Alice's UA will probably wish to keep only one of these > > dialog/sessions and will BYE the other one, and hence will wish to > > accept > > only one RTP streams, a or c. The problem is how to > determine which > > RTP > > stream corresponds to the dialog that has been retained and which > > corresponds to the dialog that has been cleared. Eventually one of > > the RTP > > streams will cease, but that is too long to wait. So what does > > Alice's UA > > do: > > 1) after receipt of the first 2xx response while both a and c are > > being > > received? It may or may not be able to distinguish based on > source IP > > address (this relies on the source IP address being the same as the > > destination IP address for RTP in the opposite direction, as > > advertised in > > the SDP answer). > > This would also rely on the IP addresses being accessible at the RTP > layer. Is this an acceptable assumption? > > > 2) between receipt of a and c and receipt of the first 2xx > > response? Alice's > > UA has no way of knowing which one will relate to the first 2xx > > response > > received. So it might just pick the first one, or mix the > two, or even > > ignore both. The last action would, of course, be forced upon > > Alice's UA for > > the SRTP case if it requires keying material from the 2xx > before it > > can > > decode a or c. > > In the case where the media is mixed, would that be a single RTP > session, or would it be two sessions that happened to arrive on the > same destination port? We can come up with a secure > solution either > way, I'm sure, but the solutions would be different in either case. [JRE] It depends what you mean by session. In SIP terms the UAC will end up with a separate session on each dialog arising from the forking of the INVITE request - these sessions could be different, e.g., in codecs used or media supported. > > David > > > > > John > > > >> -----Original Message----- > >> From: David McGrew [mailto:mcgrew@cisco.com] > >> Sent: 21 April 2006 21:05 > >> To: ietf-rtpsec@imc.org > >> Subject: RTP behavior with simultaneous SIP forking and > >> media-before-answer > >> > >> > >> Hello, > >> > >> I have a question about how SIP and RTP are expected to work > >> together, which I'd like to understand better as part of our effort > >> to design a better keying system for SRTP. I want to focus on the > >> non-secured case in order to keep things simple. If we require our > >> system to handle both "media before the SIP answer" and > SIP forking, > >> then we will have to handle scenarios like this: > >> > >> RTP/RTCP flows > >> +--------+ > >> | |<----- a ----- BobOne > >> | |------ b ----> > >> | Alice | > >> | |<----- c ---- BobTwo > >> | |------ d ----> > >> +--------+ > >> > >> After Alice's SIP offer forks to BobOne and BobTwo, the latter two > >> endpoints each send media flows (a and c) to Alice that reach her > >> before their SIP answers do. > >> > >> The two flows a and c arriving on Alice's RTP destination port > >> constitute a single RTP session, since an RTP endpoint > distinguishes > >> multiple RTP sessions by using different destination transport > >> addresses (RFC3550, Section 3"), and in this case both flows are > >> arriving on the same RTP port. Because there is a single session, > >> Alice needs to send RTCP receiver reports describing both > BobOne and > >> BobTwo to both of those participants, as the flows b and d. > >> (This is > >> the way that SSRC collision detection would work in this session.) > >> Presumably Alice would mix the media from flows a and c in > >> this case, > >> or would output both media flows as appropriate for the media type. > >> > >> Alternately, Alice might want to accept one flow and reject > >> the other > >> (e.g. she might accept only the first flow that reaches her). > >> Accepting only one flow has the significant advantage that it > >> relieves Alice of the burden of mixing or otherwise combining > >> multiple media flows. But it raises the question of how she > >> distinguishes between the sources. If she uses the SSRCs to > >> do this, > >> it may not be reliable, since e.g. flow "a" may contain > multiple RTP > >> sources, such as streams from multiple video cameras. She > could use > >> the source address to distinguish the flows, *if* the RTP layer is > >> built so that it can convey that address along with the RTP packet. > >> However, this behavior doesn't conform to RFC3550 AFAICT. > >> > >> So my question is: what are the admissible behaviors for > Alice's RTP > >> implementation? I'd also like to hear other interpretations of the > >> specs, if there are any. Comments welcome. > >> > >> David > >> > From owner-ietf-rtpsec Mon Apr 24 16:51:50 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 k3ONpo6o076970; Mon, 24 Apr 2006 16:51: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 k3ONpost076969; Mon, 24 Apr 2006 16:51: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 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 k3ONpnxi076962 for ; Mon, 24 Apr 2006 16:51:49 -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; 24 Apr 2006 16:51:44 -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 k3ONpYRn027492; Mon, 24 Apr 2006 16:51:44 -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); Mon, 24 Apr 2006 16:51:33 -0700 Received: from [192.168.0.10] ([10.21.83.141]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 16:51:33 -0700 In-Reply-To: <50B1CBA96870A34799A506B2313F266708BBCFF8@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266708BBCFF8@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7968BF54-3E38-486F-8974-4ABCE7439F82@cisco.com> Cc: David McGrew , ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: RTP behavior with simultaneous SIP forking and media-before-a nswer Date: Mon, 24 Apr 2006 16:51:20 -0700 To: "Elwell, John" X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 24 Apr 2006 23:51:33.0108 (UTC) FILETIME=[03DF2B40:01C667FA] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Apr 24, 2006, at 1:31 PM, Elwell, John wrote: ... >> >> In the case where the media is mixed, would that be a single RTP >> session, or would it be two sessions that happened to arrive on the >> same destination port? We can come up with a secure >> solution either >> way, I'm sure, but the solutions would be different in either case. > [JRE] It depends what you mean by session. In SIP terms the UAC > will end up > with a separate session on each dialog arising from the forking of the > INVITE request - these sessions could be different, e.g., in codecs > used or > media supported. This is consistent with my reading of SIP: I assume that a fork results in a multiple, independent RTP sessions and hence can be thought of multi-unicast, which is the term that I have been using to describe the result. Mark > >> >> David >> >>> >>> John >>> >>>> -----Original Message----- >>>> From: David McGrew [mailto:mcgrew@cisco.com] >>>> Sent: 21 April 2006 21:05 >>>> To: ietf-rtpsec@imc.org >>>> Subject: RTP behavior with simultaneous SIP forking and >>>> media-before-answer >>>> >>>> >>>> Hello, >>>> >>>> I have a question about how SIP and RTP are expected to work >>>> together, which I'd like to understand better as part of our effort >>>> to design a better keying system for SRTP. I want to focus on the >>>> non-secured case in order to keep things simple. If we require our >>>> system to handle both "media before the SIP answer" and >> SIP forking, >>>> then we will have to handle scenarios like this: >>>> >>>> RTP/RTCP flows >>>> +--------+ >>>> | |<----- a ----- BobOne >>>> | |------ b ----> >>>> | Alice | >>>> | |<----- c ---- BobTwo >>>> | |------ d ----> >>>> +--------+ >>>> >>>> After Alice's SIP offer forks to BobOne and BobTwo, the latter two >>>> endpoints each send media flows (a and c) to Alice that reach her >>>> before their SIP answers do. >>>> >>>> The two flows a and c arriving on Alice's RTP destination port >>>> constitute a single RTP session, since an RTP endpoint >> distinguishes >>>> multiple RTP sessions by using different destination transport >>>> addresses (RFC3550, Section 3"), and in this case both flows are >>>> arriving on the same RTP port. Because there is a single session, >>>> Alice needs to send RTCP receiver reports describing both >> BobOne and >>>> BobTwo to both of those participants, as the flows b and d. >>>> (This is >>>> the way that SSRC collision detection would work in this session.) >>>> Presumably Alice would mix the media from flows a and c in >>>> this case, >>>> or would output both media flows as appropriate for the media type. >>>> >>>> Alternately, Alice might want to accept one flow and reject >>>> the other >>>> (e.g. she might accept only the first flow that reaches her). >>>> Accepting only one flow has the significant advantage that it >>>> relieves Alice of the burden of mixing or otherwise combining >>>> multiple media flows. But it raises the question of how she >>>> distinguishes between the sources. If she uses the SSRCs to >>>> do this, >>>> it may not be reliable, since e.g. flow "a" may contain >> multiple RTP >>>> sources, such as streams from multiple video cameras. She >> could use >>>> the source address to distinguish the flows, *if* the RTP layer is >>>> built so that it can convey that address along with the RTP packet. >>>> However, this behavior doesn't conform to RFC3550 AFAICT. >>>> >>>> So my question is: what are the admissible behaviors for >> Alice's RTP >>>> implementation? I'd also like to hear other interpretations of the >>>> specs, if there are any. Comments welcome. >>>> >>>> David >>>> >> From owner-ietf-rtpsec Tue Apr 25 07:46:44 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 k3PEkiFS014072; Tue, 25 Apr 2006 07:46:44 -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 k3PEkill014071; Tue, 25 Apr 2006 07:46: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 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 k3PEkgIY014063 for ; Tue, 25 Apr 2006 07:46:43 -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); Tue, 25 Apr 2006 10:47:08 -0400 To: David McGrew Cc: Colin Perkins , ietf-rtpsec@imc.org Subject: Re: Requirements, First References: <44405030.1010901@sipstation.com> <35337CB5-56C9-4304-9CB1-4A2DC0A2D50D@cisco.com> <4440F3DE.8060401@sipstation.com> <6403EE4C-E2ED-4604-8100-DA6A2C52BC9C@cisco.com> From: Randell Jesup Reply-to: Randell Jesup Date: Tue, 25 Apr 2006 10:48:33 -0400 In-Reply-To: <6403EE4C-E2ED-4604-8100-DA6A2C52BC9C@cisco.com> (David McGrew's message of "Mon, 24 Apr 2006 07:12:56 -0700") 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: 25 Apr 2006 14:47:08.0335 (UTC) FILETIME=[20901BF0:01C66877] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David McGrew writes: >> Perhaps, but I'd also like to see an analysis of the impact this has on >> RTP and on the devices which use it. It's not clear that doing the >> signalling in-band with the media won't break other devices which make >> assumptions on the contents of a stream that are not valid when in-band >> keying extensions are used, even if those extensions are legal RTP (an >> example might be devices which require header compression and MTU >> matching the RTP packet size, which would likely have trouble with RTP >> header extensions). > >I asked a few firewall implementers about RTP in-band keying. It seems as >though all of the in-band methods would have trouble passing through >firewalls that do RTP conformance checking. Firewalls would need to be >updated in order for firewall traversal to work properly. (As an aside, >it seems like the header extension method would get past the most >firewalls, though any method which didn't change the RTP header would do >just as well.) Note that for a lot of us, (home) NAT traversal is FAR FAR FAR more important than dealing with firewalls that actually inspect RTP for conformance. Those are entirely (to my knowledge) big corporate firewalls - those can be reved, the N million home nats won't be. Anything that requires extra ports is at best problematic, and perhaps far worse. In fact, I personally have never run into a firewall that inspects RTP packets, though I'm sure they're out there. >The approach that Mark mentioned on this thread - end-to-end keying that's >on-path but not in-band - would have the advantages that Alan cites above, >but would also have issues with NAT. It seems that the VoIP community is >willing to trade NAT traversal problems for FW traversal problems :-) I'm MORE than willing to reduce NAT problems at the cost of corporate firewalls needing updates (which they get regularly anyways). :-) -- 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 Tue May 2 08:15:52 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 k42FFqRw061633; Tue, 2 May 2006 08:15:52 -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 k42FFq7e061632; Tue, 2 May 2006 08:15:52 -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 k42FFpBD061621 for ; Tue, 2 May 2006 08:15:51 -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; 02 May 2006 08:15:44 -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 k42FFhRT012021; Tue, 2 May 2006 08:15:43 -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); Tue, 2 May 2006 08:15:43 -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); Tue, 2 May 2006 08:15:43 -0700 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: saag@mit.edu, ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: David McGrew Subject: The use of AES-192 and AES-256 in Secure RTP Date: Tue, 2 May 2006 08:15:41 -0700 To: AVT X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 02 May 2006 15:15:43.0453 (UTC) FILETIME=[47BE98D0:01C66DFB] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, there has been some interest in using AES with larger key sizes in Secure RTP, and some implementations have gone in this direction in advance of any specification. I wrote up an internet draft to fill this gap (after trying unsuccessfully to get someone else to write it :-) and to provide usage guidance and (eventually) test vectors. It's online at http://www.ietf.org/internet-drafts/draft-mcgrew-srtp- big-aes-00.txt I propose that this draft be adopted for standards track, and I ask for your review (if you have an interest in Secure RTP). Please note the "Open Questions" section. The ietf-rtpsec list is copied since this draft is potentially interesting there, even though the draft has little architectural impact. Best regards, David From owner-ietf-rtpsec Tue May 2 09:50:41 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 k42GoeTD065523; Tue, 2 May 2006 09:50:40 -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 k42Goekr065522; Tue, 2 May 2006 09:50:40 -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 ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42GoeTG065516 for ; Tue, 2 May 2006 09:50:40 -0700 (MST) (envelope-from ldondeti@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42GoWIX005159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 09:50:33 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42GoSTW002385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 09:50:31 -0700 (PDT) Message-Id: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 May 2006 09:50:27 -0700 To: David McGrew , AVT From: Lakshminath Dondeti Subject: Re: The use of AES-192 and AES-256 in Secure RTP Cc: saag@mit.edu, ietf-rtpsec@imc.org In-Reply-To: References: 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 David, As I read the email, I wondered about replacing HMAC-SHA-1 in 3711 also, and glad to see that your open questions lists that. I have a few questions: 1. Is the 112-bit salt sufficient even with longer keys? You might recall that we've (Mark B., you and I) had discussions on the master key and salt being input to a KDF that results in the derivation of the encr_key, integ_key and a salt, where the output might be longer than the input to the KDF. You are the expert in this area, but I am still wondering if it is an issue. Figure 2 applies to AES-128 only, right? 2. I would suggest that this draft include AES-based CMAC, so we can move away from SHA-1 and also use a single crypto primitive for encryption, and PRF and MAC computation (opinion on your open question). Q: What are the considerations in truncating cipher-based MAC outputs? Specifically, is truncating below half-the-size of the output (which I vaguely recall as relating to the birthday attack in case of hash-based MACs -- perhaps it is not) of the cipher-based MAC ok? What would be the strength of the MAC in that case. If we are making a case for AES-192 or AES-256, then we have a certain stronger adversary in mind (one that requires us to move away from AES-128). In that case, why is MAC truncation not an issue? Let's discuss those for now. I may have more later :-). Thanks for doing this! I was going to ask you about using CMAC in 3711! regards, Lakshminath At 08:15 AM 5/2/2006, David McGrew wrote: >Hello, > >there has been some interest in using AES with larger key sizes in >Secure RTP, and some implementations have gone in this direction in >advance of any specification. I wrote up an internet draft to fill >this gap (after trying unsuccessfully to get someone else to write >it :-) and to provide usage guidance and (eventually) test vectors. >It's online at >http://www.ietf.org/internet-drafts/draft-mcgrew-srtp- big-aes-00.txt > >I propose that this draft be adopted for standards track, and I ask >for your review (if you have an interest in Secure RTP). Please note >the "Open Questions" section. The ietf-rtpsec list is copied since >this draft is potentially interesting there, even though the draft >has little architectural impact. > >Best regards, > >David From owner-ietf-rtpsec Tue May 2 11:31:49 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 k42IVnIo071124; Tue, 2 May 2006 11:31:49 -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 k42IVnTm071123; Tue, 2 May 2006 11:31:49 -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 k42IVlid071117 for ; Tue, 2 May 2006 11:31:48 -0700 (MST) (envelope-from csp@csperkins.org) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49994) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1Fazf0-0002B3-7o; Tue, 02 May 2006 19:31:46 +0100 In-Reply-To: <6403EE4C-E2ED-4604-8100-DA6A2C52BC9C@cisco.com> References: <44405030.1010901@sipstation.com> <35337CB5-56C9-4304-9CB1-4A2DC0A2D50D@cisco.com> <4440F3DE.8060401@sipstation.com> <6403EE4C-E2ED-4604-8100-DA6A2C52BC9C@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44C5F8B3-6818-4C96-AAF0-51B05E29A134@csperkins.org> Cc: ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: Requirements, First Date: Tue, 2 May 2006 19:31:43 +0100 To: David McGrew X-Mailer: Apple Mail (2.749.3) Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David, [Catching up - apologies for slow response] On 24 Apr 2006, at 15:12, David McGrew wrote: > On Apr 19, 2006, at 1:37 AM, Colin Perkins wrote: >> On 15 Apr 2006, at 14:23, Alan Johnston wrote: >> ... >>> 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. >> >> Perhaps, but I'd also like to see an analysis of the impact this >> has on RTP and on the devices which use it. It's not clear that >> doing the signalling in-band with the media won't break other >> devices which make assumptions on the contents of a stream that >> are not valid when in-band keying extensions are used, even if >> those extensions are legal RTP (an example might be devices which >> require header compression and MTU matching the RTP packet size, >> which would likely have trouble with RTP header extensions). > > I asked a few firewall implementers about RTP in-band keying. It > seems as though all of the in-band methods would have trouble > passing through firewalls that do RTP conformance checking. > Firewalls would need to be updated in order for firewall traversal > to work properly. (As an aside, it seems like the header extension > method would get past the most firewalls, though any method which > didn't change the RTP header would do just as well.) Sure. I also suspect that 3G wireless devices which match the audio frame size to the channel MTU will have difficulty with in-band signalling in RTP. Doing the signalling for the RTP channel within RTCP would likely ease these issues, and would also fit the RTP architecture better. > The approach that Mark mentioned on this thread - end-to-end keying > that's on-path but not in-band - would have the advantages that > Alan cites above, but would also have issues with NAT. It seems > that the VoIP community is willing to trade NAT traversal problems > for FW traversal problems :-) A dedicated on-path signalling channel would ease both security negotiation and device control, and would actually be a good thing to have. Yes, it complicates NAT traversal though. Colin From owner-ietf-rtpsec Tue May 2 11:44:08 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 k42Ii8tZ071863; Tue, 2 May 2006 11:44: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 k42Ii8s9071862; Tue, 2 May 2006 11:44: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 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 k42Ii7MB071856 for ; Tue, 2 May 2006 11:44:07 -0700 (MST) (envelope-from csp@csperkins.org) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:50004) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1Fazqm-00036i-U1; Tue, 02 May 2006 19:43:56 +0100 In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF08E36366@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1ACF17C7-2342-4D16-AA0E-DB7319AA128A@csperkins.org> Cc: Francois Audet , "David McGrew" , "Alan Johnston" , Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: requirements discussion Date: Tue, 2 May 2006 19:43:51 +0100 To: Mark Baugher X-Mailer: Apple Mail (2.749.3) Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 21 Apr 2006, at 20:43, Mark Baugher wrote: > On Apr 20, 2006, at 4:13 PM, Francois Audet wrote: > ... >> Doing the negotiation in-band could reduce the clipping by making the >> negotiation faster than on the sip channel. > > Yes, it can do that unless the in-band negotiation is delayed until > a protracted negotiation in the signaling channel such as ICE > completes. > > That being said, I think _in-path_ (same path as the media) or in- > band (same packets as the media) methods are worth considering. I > favor an in-path approach over in-band although DTLS arguably makes > the in-path and in-band distinction moot to the extent that it does > port multiplexing. I agree these are worth considering, even with the additional port/ NAT traversal costs, since an on-path signalling channel would be generally useful. Failing that, an on-path protocol that can be distinguished by port multiplexing (as with ICE, DTLS) would seem cleaner from an RTP viewpoint than embedding signalling into the RTP packets. Colin From owner-ietf-rtpsec Tue May 2 11:58: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 k42Iw6Z7072450; Tue, 2 May 2006 11:58: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 k42Iw6Sc072449; Tue, 2 May 2006 11:58: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 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 k42Iw5ce072439 for ; Tue, 2 May 2006 11:58:06 -0700 (MST) (envelope-from csp@csperkins.org) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:50016) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1Fb04N-0003sH-Pe; Tue, 02 May 2006 19:57:59 +0100 In-Reply-To: <62B3BC2F-6940-4F49-9196-9533E3D1AE0D@cisco.com> References: <62B3BC2F-6940-4F49-9196-9533E3D1AE0D@cisco.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: Colin Perkins Subject: Re: RTP behavior with simultaneous SIP forking and media-before-answer Date: Tue, 2 May 2006 19:57:56 +0100 To: David McGrew X-Mailer: Apple Mail (2.749.3) Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 21 Apr 2006, at 21:04, David McGrew wrote: > I have a question about how SIP and RTP are expected to work > together, which I'd like to understand better as part of our effort > to design a better keying system for SRTP. I want to focus on the > non-secured case in order to keep things simple. If we require our > system to handle both "media before the SIP answer" and SIP > forking, then we will have to handle scenarios like this: > > RTP/RTCP flows > +--------+ > | |<----- a ----- BobOne > | |------ b ----> > | Alice | > | |<----- c ---- BobTwo > | |------ d ----> > +--------+ > > After Alice's SIP offer forks to BobOne and BobTwo, the latter two > endpoints each send media flows (a and c) to Alice that reach her > before their SIP answers do. > > The two flows a and c arriving on Alice's RTP destination port > constitute a single RTP session, since an RTP endpoint > distinguishes multiple RTP sessions by using different destination > transport addresses (RFC3550, Section 3"), and in this case both > flows are arriving on the same RTP port. Because there is a single > session, Alice needs to send RTCP receiver reports describing both > BobOne and BobTwo to both of those participants, as the flows b and > d. (This is the way that SSRC collision detection would work in > this session.) Presumably Alice would mix the media from flows a > and c in this case, or would output both media flows as appropriate > for the media type. > > Alternately, Alice might want to accept one flow and reject the > other (e.g. she might accept only the first flow that reaches > her). Accepting only one flow has the significant advantage that > it relieves Alice of the burden of mixing or otherwise combining > multiple media flows. But it raises the question of how she > distinguishes between the sources. If she uses the SSRCs to do > this, it may not be reliable, since e.g. flow "a" may contain > multiple RTP sources, such as streams from multiple video cameras. > She could use the source address to distinguish the flows, *if* the > RTP layer is built so that it can convey that address along with > the RTP packet. However, this behavior doesn't conform to RFC3550 > AFAICT. > > So my question is: what are the admissible behaviors for Alice's > RTP implementation? I'd also like to hear other interpretations of > the specs, if there are any. Comments welcome. Alice gets to choose if this is a single RTP session or two separate sessions, based on how she generates RTCP responses. She could treat this scenario as a single RTP session and generate RTCP such that BobOne and BobTwo are aware of each other and share an SSRC space; or she could treat the scenario as two entirely separate RTP sessions, distinguished by the source transport address. Colin From owner-ietf-rtpsec Tue May 2 13:18: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 k42KI6qi076497; Tue, 2 May 2006 13:18: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 k42KI6vD076496; Tue, 2 May 2006 13:18: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 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 k42KI5Ff076475 for ; Tue, 2 May 2006 13:18:05 -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; 02 May 2006 13:17:57 -0700 X-IronPort-AV: i="4.05,80,1146466800"; d="scan'208"; a="1800658889:sNHT4310552158" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k42KHoYk026700; Tue, 2 May 2006 13:17:56 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 16:17:54 -0400 Received: from [192.168.0.10] ([10.82.218.238]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 16:17:54 -0400 In-Reply-To: References: <62B3BC2F-6940-4F49-9196-9533E3D1AE0D@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <647FCE8E-BDB2-4889-ACDE-B84749BAB619@cisco.com> Cc: David McGrew , ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: RTP behavior with simultaneous SIP forking and media-before-answer Date: Tue, 2 May 2006 13:17:44 -0700 To: Colin Perkins X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 02 May 2006 20:17:54.0454 (UTC) FILETIME=[7EA9CB60:01C66E25] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Colin, On May 2, 2006, at 11:57 AM, Colin Perkins wrote: > > On 21 Apr 2006, at 21:04, David McGrew wrote: >> I have a question about how SIP and RTP are expected to work >> together, which I'd like to understand better as part of our >> effort to design a better keying system for SRTP. I want to focus >> on the non-secured case in order to keep things simple. If we >> require our system to handle both "media before the SIP answer" >> and SIP forking, then we will have to handle scenarios like this: >> >> RTP/RTCP flows >> +--------+ >> | |<----- a ----- BobOne >> | |------ b ----> >> | Alice | >> | |<----- c ---- BobTwo >> | |------ d ----> >> +--------+ >> >> After Alice's SIP offer forks to BobOne and BobTwo, the latter two >> endpoints each send media flows (a and c) to Alice that reach her >> before their SIP answers do. >> >> The two flows a and c arriving on Alice's RTP destination port >> constitute a single RTP session, since an RTP endpoint >> distinguishes multiple RTP sessions by using different destination >> transport addresses (RFC3550, Section 3"), and in this case both >> flows are arriving on the same RTP port. Because there is a >> single session, Alice needs to send RTCP receiver reports >> describing both BobOne and BobTwo to both of those participants, >> as the flows b and d. (This is the way that SSRC collision >> detection would work in this session.) Presumably Alice would >> mix the media from flows a and c in this case, or would output >> both media flows as appropriate for the media type. >> >> Alternately, Alice might want to accept one flow and reject the >> other (e.g. she might accept only the first flow that reaches >> her). Accepting only one flow has the significant advantage that >> it relieves Alice of the burden of mixing or otherwise combining >> multiple media flows. But it raises the question of how she >> distinguishes between the sources. If she uses the SSRCs to do >> this, it may not be reliable, since e.g. flow "a" may contain >> multiple RTP sources, such as streams from multiple video >> cameras. She could use the source address to distinguish the >> flows, *if* the RTP layer is built so that it can convey that >> address along with the RTP packet. However, this behavior doesn't >> conform to RFC3550 AFAICT. >> >> So my question is: what are the admissible behaviors for Alice's >> RTP implementation? I'd also like to hear other interpretations >> of the specs, if there are any. Comments welcome. > > Alice gets to choose if this is a single RTP session or two > separate sessions, based on how she generates RTCP responses. She > could treat this scenario as a single RTP session and generate RTCP > such that BobOne and BobTwo are aware of each other and share an > SSRC space; or she could treat the scenario as two entirely > separate RTP sessions, distinguished by the source transport address. Good point. I don't think the SIP specification says which behavior is preferred or what the musts, shoulds, and nots are in this scenario. In the former case, Alice might act as a mixer or translator and forward the stream to (one of) the Bobs. Or just generate the RTCP in a way to indicate that this is a single session (I assume by including RRs for each Bob in its (S)RTCP). Or it could treat the scenario as two entirely separate sessions. I don't expect that we want these options to be at the discretion of each implementation. Mark > > Colin From owner-ietf-rtpsec Tue May 2 13:42: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 k42Kg6Wf077903; Tue, 2 May 2006 13:42: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 k42Kg6SE077902; Tue, 2 May 2006 13:42: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-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 k42Kg54h077893 for ; Tue, 2 May 2006 13:42:05 -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; 02 May 2006 13:42:00 -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 k42KfwRV015462; Tue, 2 May 2006 13:42:00 -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); Tue, 2 May 2006 13:41:59 -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); Tue, 2 May 2006 13:41:58 -0700 In-Reply-To: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: AVT , saag@mit.edu, ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: The use of AES-192 and AES-256 in Secure RTP Date: Tue, 2 May 2006 13:41:56 -0700 To: Lakshminath Dondeti X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 02 May 2006 20:41:58.0500 (UTC) FILETIME=[DB61BA40:01C66E28] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Lakshminath, thanks for your comments, more inline: On May 2, 2006, at 9:50 AM, Lakshminath Dondeti wrote: > Hi David, > > As I read the email, I wondered about replacing HMAC-SHA-1 in 3711 > also, and glad to see that your open questions lists that. I have > a few questions: > > 1. Is the 112-bit salt sufficient even with longer keys? You might > recall that we've (Mark B., you and I) had discussions on the > master key and salt being input to a KDF that results in the > derivation of the encr_key, integ_key and a salt, where the output > might be longer than the input to the KDF. You are the expert in > this area, but I am still wondering if it is an issue. I think that the 112-bit salt is sufficient. The srtp salt is present so that the srtp use of counter mode is essentially as secure as CBC mode against attacks that amortize computational effort over multiple target keys. This property still holds for the larger key sizes. Besides, there's not much that we can do to increase the salt length, since there are only 16 more bits that we could possibly add. I also think that it is valuable to retain counter-format compatibility with the AES-128 counter mode. > > Figure 2 applies to AES-128 only, right? > No, it's for all of the key sizes. AES-192 and AES-256 still have 16 byte plaintexts. Or maybe I'm not understanding; did I mislabel something? > 2. I would suggest that this draft include AES-based CMAC, so we > can move away from SHA-1 and also use a single crypto primitive for > encryption, and PRF and MAC computation (opinion on your open > question). We think alike :-) I implemented AES CMAC for SRTP and found that it performs better than HMAC-SHA1 for very short packets (like those for conversational voice over a WAN) but not long packets (like video). It also has some other advantages. But OTOH there is a cost to proliferating cryptoalgorithms. Let's start up a separate thread on CMAC. > > Q: What are the considerations in truncating cipher-based MAC > outputs? Specifically, is truncating below half-the-size of the > output (which I vaguely recall as relating to the birthday attack > in case of hash-based MACs -- perhaps it is not) of the cipher- > based MAC ok? Ah, good points. The NIST CMAC specification disallows truncation to MACs shorter than 64 bits. This is not because CMAC is weaker than an ideal MAC with respect to truncation, though. CMAC has been shown to be a good pseudorandom function if AES is a good blockcipher (as long as some usage limits are respected), and a PRF essentially is an ideal MAC. I'm pretty sure that the CMAC specification insists on MACs of at least 64 bits because it feels that a per-MAC forgery probability greater than 2^64 is not acceptable. No doubt they were not considering the case of stateless codecs, which some SRTP users need only 32-bit MACs. It is an interesting question as to what tag sizes would be recommended for use with CMAC! > What would be the strength of the MAC in that case. If we are > making a case for AES-192 or AES-256, then we have a certain > stronger adversary in mind (one that requires us to move away from > AES-128). In that case, why is MAC truncation not an issue? That's a good question. I think that in some circumstances it could make sense to use a short authentication tag and a huge key. If some unanticipated advance in cryptanalysis enables us to break AES-128 but not AES-256, but some user is still okay with accepting one out of a billion forged g.711 packets, this scenario would fit the bill. So the cryptosuites defined in the draft might make sense. But I take your point that users concerned that AES-128 doesn't have enough security may well not be satisfied with a 32-bit MAC. It would be good to get some input from the Suite B community on this question. > > Let's discuss those for now. I may have more later :-). Thanks > for doing this! I was going to ask you about using CMAC in 3711! > Any thoughts on whether or not AES-192 should be included? David > regards, > Lakshminath > > At 08:15 AM 5/2/2006, David McGrew wrote: > >> Hello, >> >> there has been some interest in using AES with larger key sizes in >> Secure RTP, and some implementations have gone in this direction in >> advance of any specification. I wrote up an internet draft to fill >> this gap (after trying unsuccessfully to get someone else to write >> it :-) and to provide usage guidance and (eventually) test vectors. >> It's online at http://www.ietf.org/internet-drafts/draft-mcgrew- >> srtp- big-aes-00.txt >> >> I propose that this draft be adopted for standards track, and I ask >> for your review (if you have an interest in Secure RTP). Please note >> the "Open Questions" section. The ietf-rtpsec list is copied since >> this draft is potentially interesting there, even though the draft >> has little architectural impact. >> >> Best regards, >> >> David From owner-ietf-rtpsec Tue May 2 15:12:15 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 k42MCFU3081822; Tue, 2 May 2006 15:12:15 -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 k42MCFHj081821; Tue, 2 May 2006 15:12:15 -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 k42MCAFI081814 for ; Tue, 2 May 2006 15:12:14 -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 k42M8pMX008333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 15:08:52 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-121.qualcomm.com [10.50.65.121]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42M8nYj004144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 15:08:50 -0700 (PDT) Message-Id: <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 May 2006 15:08:50 -0700 To: David McGrew From: Lakshminath Dondeti Subject: Re: The use of AES-192 and AES-256 in Secure RTP Cc: AVT , saag@mit.edu, ietf-rtpsec@imc.org In-Reply-To: References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.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 David, Thanks for the clarifications. Please see inline for some follow-up notes: At 01:41 PM 5/2/2006, David McGrew wrote: >Hi Lakshminath, > >thanks for your comments, more inline: > >On May 2, 2006, at 9:50 AM, Lakshminath Dondeti wrote: > >>Hi David, >> >> As I read the email, I wondered about replacing HMAC-SHA-1 in 3711 >>also, and glad to see that your open questions lists that. I have >>a few questions: >> >>1. Is the 112-bit salt sufficient even with longer keys? You might >>recall that we've (Mark B., you and I) had discussions on the >>master key and salt being input to a KDF that results in the >>derivation of the encr_key, integ_key and a salt, where the output >>might be longer than the input to the KDF. You are the expert in >>this area, but I am still wondering if it is an issue. > >I think that the 112-bit salt is sufficient. The srtp salt is >present so that the srtp use of counter mode is essentially as secure >as CBC mode against attacks that amortize computational effort over >multiple target keys. This property still holds for the larger key >sizes. Besides, there's not much that we can do to increase the salt >length, since there are only 16 more bits that we could possibly >add. I also think that it is valuable to retain counter-format >compatibility with the AES-128 counter mode. Ok, I understand the limitation on the salt size (also see below about my misunderstanding of the block size in AES). I also understand the aspect of offsetting counter-mode's relative key strength using the salt and that for that purpose 112-bit salt is sufficient. What about using a 128, 192, or 256-bit master key and 112-bit salt to derive a 128, 192, 256-bit encryption key and a 160-bit, 256-bit (assuming SHA-1 or SHA-2) and a session salt key (this is 112-bits in size, right?)? Is entropy or lack thereof is a consideration. >>Figure 2 applies to AES-128 only, right? > >No, it's for all of the key sizes. AES-192 and AES-256 still have 16 >byte plaintexts. Or maybe I'm not understanding; did I mislabel >something? No, my mistake. I forgot that AES uses 128-bit blocks irrespective of the key size. Apologies. >>2. I would suggest that this draft include AES-based CMAC, so we >>can move away from SHA-1 and also use a single crypto primitive for >>encryption, and PRF and MAC computation (opinion on your open >>question). > >We think alike :-) I implemented AES CMAC for SRTP and found that it >performs better than HMAC-SHA1 for very short packets (like those for >conversational voice over a WAN) but not long packets (like video). >It also has some other advantages. But OTOH there is a cost to >proliferating cryptoalgorithms. Let's start up a separate thread on >CMAC. We did talk about it before. The concept of using the same crypto primitive came up elsewhere and that sounds like a good idea. Please start that thread of discussion. >>Q: What are the considerations in truncating cipher-based MAC >>outputs? Specifically, is truncating below half-the-size of the >>output (which I vaguely recall as relating to the birthday attack >>in case of hash-based MACs -- perhaps it is not) of the cipher- based MAC ok? > >Ah, good points. The NIST CMAC specification disallows truncation to >MACs shorter than 64 bits. This is not because CMAC is weaker than >an ideal MAC with respect to truncation, though. CMAC has been shown >to be a good pseudorandom function if AES is a good blockcipher (as >long as some usage limits are respected), and a PRF essentially is an >ideal MAC. I'm pretty sure that the CMAC specification insists on >MACs of at least 64 bits because it feels that a per-MAC forgery >probability greater than 2^64 is not acceptable. No doubt they were >not considering the case of stateless codecs, which some SRTP users >need only 32-bit MACs. It is an interesting question as to what tag >sizes would be recommended for use with CMAC! Let me think more about this. >>What would be the strength of the MAC in that case. If we are >>making a case for AES-192 or AES-256, then we have a certain >>stronger adversary in mind (one that requires us to move away from >>AES-128). In that case, why is MAC truncation not an issue? > >That's a good question. I think that in some circumstances it could >make sense to use a short authentication tag and a huge key. If some >unanticipated advance in cryptanalysis enables us to break AES-128 >but not AES-256, but some user is still okay with accepting one out >of a billion forged g.711 packets, this scenario would fit the bill. >So the cryptosuites defined in the draft might make sense. But I >take your point that users concerned that AES-128 doesn't have enough >security may well not be satisfied with a 32-bit MAC. It would be >good to get some input from the Suite B community on this question. Yes, we'll wait to hear from others. >>Let's discuss those for now. I may have more later :-). Thanks >>for doing this! I was going to ask you about using CMAC in 3711! > >Any thoughts on whether or not AES-192 should be included? I think the use of AES-192 should be specified (at the expense of more work for you :-) ), but let the "market" decide whether the switch is to 192 or 256-bit keys. regards, Lakshminath >David > >>regards, >>Lakshminath >> >>At 08:15 AM 5/2/2006, David McGrew wrote: >> >>>Hello, >>> >>>there has been some interest in using AES with larger key sizes in >>>Secure RTP, and some implementations have gone in this direction in >>>advance of any specification. I wrote up an internet draft to fill >>>this gap (after trying unsuccessfully to get someone else to write >>>it :-) and to provide usage guidance and (eventually) test vectors. >>>It's online at http://www.ietf.org/internet-drafts/draft-mcgrew- >>>srtp- big-aes-00.txt >>> >>>I propose that this draft be adopted for standards track, and I ask >>>for your review (if you have an interest in Secure RTP). Please note >>>the "Open Questions" section. The ietf-rtpsec list is copied since >>>this draft is potentially interesting there, even though the draft >>>has little architectural impact. >>> >>>Best regards, >>> >>>David From owner-ietf-rtpsec Wed May 3 14:38:57 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 k43LcvFB048512; Wed, 3 May 2006 14:38:57 -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 k43Lcvkv048511; Wed, 3 May 2006 14:38:57 -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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43Lcu5L048504 for ; Wed, 3 May 2006 14:38:57 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.81.115.240]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FbP3a-00015T-3r; Wed, 03 May 2006 17:38:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> Date: Wed, 3 May 2006 17:28:56 -0400 To: Lakshminath Dondeti From: Stephen Kent Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Cc: David McGrew , saag@mit.edu, ietf-rtpsec@imc.org, AVT Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm not a cryptographer, but I generally advise against encouraging users to employ AES with 256-bit keys. The 256-bit key size is there primarily as a hedge against the future development of quantum computers. Since there are some performance costs with the use of big keys, it seems unnecessary to adopt them at this time. Steve From owner-ietf-rtpsec Wed May 3 15:19: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 k43MJ2vd049911; Wed, 3 May 2006 15:19:02 -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 k43MJ2ae049910; Wed, 3 May 2006 15:19:02 -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.rfburst.com (mail.rfburst.com [66.119.143.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43MJ1bT049904 for ; Wed, 3 May 2006 15:19:01 -0700 (MST) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (rfb135-195.radioburst.com [66.119.135.195] (may be forged)) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id k43MIsfx020996; Wed, 3 May 2006 16:18:54 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id k43MHISg012291; Wed, 3 May 2006 16:17:18 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id k43MHI7Y012287; Wed, 3 May 2006 16:17:18 -0600 Date: Wed, 3 May 2006 16:17:18 -0600 Message-Id: <200605032217.k43MHI7Y012287@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" Reply-To: "The Purple Streak, Hilarie Orman" To: ietf-rtpsec@imc.org, saag@mit.edu In-reply-to: Yourmessage Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with Steve Kent on the issue of not encouraging use of AES with large key sizes. It gives the impression that there's some immediate need for larger keys. There isn't. Hilarie From owner-ietf-rtpsec Wed May 3 15:35:28 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 k43MZR7g050866; Wed, 3 May 2006 15:35: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 k43MZRRG050865; Wed, 3 May 2006 15:35: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 numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43MZRpX050857 for ; Wed, 3 May 2006 15:35:27 -0700 (MST) (envelope-from ldondeti@qualcomm.com) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k43MZDs4012371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 May 2006 15:35:13 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k43MZBMC006413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 May 2006 15:35:12 -0700 (PDT) Message-Id: <6.2.5.6.2.20060503152702.05572e70@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 May 2006 15:35:08 -0700 To: "The Purple Streak, Hilarie Orman" , ietf-rtpsec@imc.org, saag@mit.edu From: Lakshminath Dondeti Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP In-Reply-To: <200605032217.k43MHI7Y012287@localhost.localdomain> References: <200605032217.k43MHI7Y012287@localhost.localdomain> 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: Following up further, I just checked if there is a precedence, and 3268 says the following: The AES supports key lengths of 128, 192 and 256 bits. However, this document only defines ciphersuites for 128- and 256-bit keys. This is to avoid unnecessary proliferation of ciphersuites. Rijndael actually allows for 192- and 256-bit block sizes as well as the 128- bit blocks mandated by the AES process. The ciphersuites defined here all use 128-bit blocks. (Note: some of that is relevant to the discussion on whether or not 192-bit keys need to be defined for SRTP. 3268 thought not, I think we should, but anyway, back to the matter at hand). 3268 defines AES-256 usage for TLS and that was in 2002! So, we are past giving any impressions, aren't we? 3686 is another example! regards, Lakshminath At 03:17 PM 5/3/2006, The Purple Streak, Hilarie Orman wrote: >I agree with Steve Kent on the issue of not encouraging use of AES >with large key sizes. It gives the impression that there's some >immediate need for larger keys. There isn't. > >Hilarie From owner-ietf-rtpsec Wed May 3 15:31: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 k43MVA7B050641; Wed, 3 May 2006 15:31: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 k43MVAE0050640; Wed, 3 May 2006 15:31: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43MV9G5050631 for ; Wed, 3 May 2006 15:31:10 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.81.115.240]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FbPs8-0001Zc-40; Wed, 03 May 2006 18:31:04 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.5.6.2.20060503152108.05722e58@qualcomm.com> References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> <6.2.5.6.2.20060503152108.05722e58@qualcomm.com> Date: Wed, 3 May 2006 18:31:00 -0400 To: Lakshminath Dondeti From: Stephen Kent Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Cc: David McGrew , saag@mit.edu, ietf-rtpsec@imc.org, AVT Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:25 PM -0700 5/3/06, Lakshminath Dondeti wrote: >Hi Steve, > >It all started with David's notes copy-pasted below: > >++++++++ >there has been some interest in using AES with larger key sizes in >Secure RTP, and some implementations have gone in this direction in >advance of any specification. I wrote up an internet draft to fill >this gap (after trying unsuccessfully to get someone else to write >it :-) and to provide usage guidance and (eventually) test vectors. >+++++++ > >It looks like all we are doing at the IETF is to specify; business >as usual :-). We could add a recommendation along the lines you >propose below. > >regards, >Lakshminath If we decide that we need to specify how to use 256-bit keys, then we at least owe it to users to explain why they might not wish to take advantage of that capability. So, yes, adding suitable text would make me feel more comfortable. thanks, Steve From owner-ietf-rtpsec Wed May 3 15:25:49 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 k43MPnOw050289; Wed, 3 May 2006 15:25:49 -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 k43MPni2050288; Wed, 3 May 2006 15:25:49 -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 ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43MPmXE050282 for ; Wed, 3 May 2006 15:25:48 -0700 (MST) (envelope-from ldondeti@qualcomm.com) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k43MPJUL018537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 May 2006 15:25:20 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k43MPFgX002697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 May 2006 15:25:18 -0700 (PDT) Message-Id: <6.2.5.6.2.20060503152108.05722e58@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 May 2006 15:25:13 -0700 To: Stephen Kent From: Lakshminath Dondeti Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Cc: David McGrew , saag@mit.edu, ietf-rtpsec@imc.org, AVT In-Reply-To: References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.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 Steve, It all started with David's notes copy-pasted below: ++++++++ there has been some interest in using AES with larger key sizes in Secure RTP, and some implementations have gone in this direction in advance of any specification. I wrote up an internet draft to fill this gap (after trying unsuccessfully to get someone else to write it :-) and to provide usage guidance and (eventually) test vectors. +++++++ It looks like all we are doing at the IETF is to specify; business as usual :-). We could add a recommendation along the lines you propose below. regards, Lakshminath At 02:28 PM 5/3/2006, Stephen Kent wrote: >I'm not a cryptographer, but I generally advise against encouraging >users to employ AES with 256-bit keys. The 256-bit key size is there >primarily as a hedge against the future development of quantum >computers. Since there are some performance costs with the use of >big keys, it seems unnecessary to adopt them at this time. > >Steve From owner-ietf-rtpsec Wed May 3 17:53:49 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 k440rnpP057366; Wed, 3 May 2006 17:53:49 -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 k440rnqu057365; Wed, 3 May 2006 17:53:49 -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 [10.0.6.56] (host227.sprintnetops.net [63.164.47.227] (may be forged)) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k440rYYF057359; Wed, 3 May 2006 17:53:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200605032217.k43MHI7Y012287@localhost.localdomain> References: <200605032217.k43MHI7Y012287@localhost.localdomain> Date: Wed, 3 May 2006 17:53:28 -0700 To: "The Purple Streak, Hilarie Orman" , ietf-rtpsec@imc.org, saag@mit.edu From: Paul Hoffman Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 4:17 PM -0600 5/3/06, The Purple Streak, Hilarie Orman wrote: >I agree with Steve Kent on the issue of not encouraging use of AES >with large key sizes. It gives the impression that there's some >immediate need for larger keys. There isn't. lists the requirements for one particular customer of significant size who insists on the use of 256-bit (but not 192-bit) keys. --Paul Hoffman, Director --VPN Consortium From owner-ietf-rtpsec Wed May 3 19:19:11 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 k442JBUK061793; Wed, 3 May 2006 19:19:11 -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 k442JBFH061792; Wed, 3 May 2006 19:19:11 -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 k442JAxV061775 for ; Wed, 3 May 2006 19:19:10 -0700 (MST) (envelope-from rporter@covergence.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [saag] The use of AES-192 and AES-256 in Secure RTP X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 3 May 2006 22:18:57 -0400 Message-ID: <0D1719326D64BD4E9F92A0C120237678CEEE6F@eserv.covergence.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] The use of AES-192 and AES-256 in Secure RTP Thread-Index: AcZvFY0LNUYOBIbmTluSEYNvWDYkCQAA/2Eg From: "Rick Porter" To: "Paul Hoffman" , "The Purple Streak, Hilarie Orman" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k442JAxV061787 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I was surprised to see Suite B appear on someone's radar... IMO, most aspects of SRTP would not meet the standards for Suite B certification. The key exchange seems to be the most blatantly lacking, but there are other aspects. Let me point out that the Suite B link does not even mention which mode(s) of AES are acceptable (e.g. counter, cbc, ecb, wrap). I do not have a strong opinion about whether or not to specify longer AES key lengths. However, I would not specify longer key lengths just to comply with the Suite B standards--NSA is probably going to require deviation from the IETF standard(s) anyway. NSA has its own set of requirements (and reasons for them), and they also have a number of government contractors who develop products to meet those requirements. Cheers, Rick From owner-ietf-rtpsec Wed May 3 19:38:24 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 k442cOJ0062993; Wed, 3 May 2006 19:38:24 -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 k442cOpK062992; Wed, 3 May 2006 19:38:24 -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.rfburst.com (mail.rfburst.com [66.119.143.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k442cNfH062982 for ; Wed, 3 May 2006 19:38:23 -0700 (MST) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (rfb135-195.radioburst.com [66.119.135.195] (may be forged)) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id k442cGfx010385; Wed, 3 May 2006 20:38:16 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id k442afSg024547; Wed, 3 May 2006 20:36:41 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id k442aeST024543; Wed, 3 May 2006 20:36:40 -0600 Date: Wed, 3 May 2006 20:36:40 -0600 Message-Id: <200605040236.k442aeST024543@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" Reply-To: "The Purple Streak, Hilarie Orman" To: paul.hoffman@vpnc.org Cc: saag@mit.edu, ietf-rtpsec@imc.org In-reply-to: Yourmessage Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The large customer behind Suite B can't provide much guidance to us re AES 256. Do they want more rounds or more entropy? Or just something different? Signup for zero crypto growth --- stop at 128! Hilarie From owner-ietf-rtpsec Thu May 4 04:14:39 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 k44BEdhY086190; Thu, 4 May 2006 04:14:39 -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 k44BEdRB086189; Thu, 4 May 2006 04:14:39 -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 k44BEatt086182 for ; Thu, 4 May 2006 04:14:36 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 04 May 2006 04:14:31 -0700 X-IronPort-AV: i="4.05,87,1146466800"; d="scan'208"; a="1801274965:sNHT30355844" 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 k44BEURT021444; Thu, 4 May 2006 04:14:30 -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, 4 May 2006 04:14:30 -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); Thu, 4 May 2006 04:14:29 -0700 In-Reply-To: References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5ABD5019-6481-45A1-A981-4BE362E190F8@cisco.com> Cc: Lakshminath Dondeti , saag@mit.edu, ietf-rtpsec@imc.org, AVT Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Date: Thu, 4 May 2006 04:14:26 -0700 To: Stephen Kent X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 11:14:29.0323 (UTC) FILETIME=[E95121B0:01C66F6B] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Steve, I pretty much agree. The reason that I wrote up the draft is because it's been implemented (see http://sourceforge.net/mailarchive/ forum.php?thread_id=9620686&forum_id=9697) and it's been referred to in internet drafts (Section 4.1.3 of draft-zimmermann-avt- zrtp-01.txt), even though it's not been specified. There is an important implementation detail (when using AES-XYZ for encryption, use AES-XYZ for key derivation) that won't be obvious to every implementer, so a spec is going to provide some value (even if we do decide that we don't want for AES-256 in SRTP to become a standard). One reason that I can think of for implementing AES-256 in this case would be to conform to Suite B "TOP SECRET". But there are not many other good reasons for implementing that key size at the present time. The spec does promote algorithm agility, which is a good thing. I guess that the trick is to provide for that agility without making interoperability harder. I tried to do address the interoperability issue in the draft by pointing out that AES-256 is an addition to, not a replacement for, for AES-128. I also tried to write the security considerations in such a way that encourages the use of AES-128. The bigger key sizes are a hedge, as you put it, and for almost all uses they are not needed at present. At least I tried to convey that impression - I'd value comments from readers, and I'd be happy to add or modify text in this direction. David On May 3, 2006, at 2:28 PM, Stephen Kent wrote: > I'm not a cryptographer, but I generally advise against encouraging > users to employ AES with 256-bit keys. The 256-bit key size is > there primarily as a hedge against the future development of > quantum computers. Since there are some performance costs with the > use of big keys, it seems unnecessary to adopt them at this time. > > Steve From owner-ietf-rtpsec Thu May 4 06:35:15 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 k44DZFUs092209; Thu, 4 May 2006 06:35:15 -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 k44DZFjQ092208; Thu, 4 May 2006 06:35:15 -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 k44DZE5p092199 for ; Thu, 4 May 2006 06:35:14 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 04 May 2006 06:35:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k44DZ8h0010277; Thu, 4 May 2006 06:35:08 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 06:35:08 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 06:35:07 -0700 In-Reply-To: <0D1719326D64BD4E9F92A0C120237678CEEE6F@eserv.covergence.com> References: <0D1719326D64BD4E9F92A0C120237678CEEE6F@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: <0F96E748-048A-4959-832F-6685E49E0EBE@cisco.com> Cc: AVT , ietf-rtpsec@imc.org, saag@mit.edu Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Date: Thu, 4 May 2006 06:35:06 -0700 To: Rick Porter X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 13:35:07.0964 (UTC) FILETIME=[8F238FC0:01C66F7F] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Rick, On May 3, 2006, at 7:18 PM, Rick Porter wrote: > > I was surprised to see Suite B appear on someone's radar... > > IMO, most aspects of SRTP would not meet the standards for Suite B > certification. The key exchange seems to be the most blatantly > lacking, > but there are other aspects. you are right that there is probably no standardized way to provide keys to SRTP that would meet the Suite B guidelines. But this doesn't imply that we shouldn't specify a Suite B conformant profile for SRTP (since we don't want to create a chicken-or-egg-first? situation). Also, some of the proposed key management methods do incorporate or admit FIPS-140/Suite B approved key establishment methods (for example, DTLS-SRTP could be used with one of the ECC methods currently being drafted for TLS). > Let me point out that the Suite B link does > not even mention which mode(s) of AES are acceptable (e.g. counter, > cbc, > ecb, wrap). > You're right that Suite B is underspecified, and it would be reassuring to get more details about it. (I prefer "underspecified" to "overly narrow" though :-) > I do not have a strong opinion about whether or not to specify longer > AES key lengths. However, I would not specify longer key lengths > just to > comply with the Suite B standards--NSA is probably going to require > deviation from the IETF standard(s) anyway. NSA has its own set of > requirements (and reasons for them), and they also have a number of > government contractors who develop products to meet those > requirements. True, but I would rather work with Suite B and try to promote broader interoperability. I think that the big value of Suite B is that it will enable interoperability between the high-assurance implementations that you mention and commercial standards-based implementations. This is an obvious gain for the high-assurance community, and it could also benefit the commercial community. But I'm getting off topic here; Suite B is worth discussing, but the use of elliptic curve crypto is the most important topic there, not SRTP key sizes ;-) David > > > Cheers, > Rick From owner-ietf-rtpsec Thu May 4 06:57: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 k44DvpGW093223; Thu, 4 May 2006 06:57:51 -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 k44DvptT093222; Thu, 4 May 2006 06:57:51 -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 k44DvoNa093216 for ; Thu, 4 May 2006 06:57:51 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 04 May 2006 06:57:45 -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 k44DvjRT009747; Thu, 4 May 2006 06:57:45 -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, 4 May 2006 06:57:45 -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); Thu, 4 May 2006 06:57:44 -0700 In-Reply-To: <200605040236.k442aeST024543@localhost.localdomain> References: <200605040236.k442aeST024543@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73C7FC51-5717-46AB-8B4A-F3842C855D6D@cisco.com> Cc: saag@mit.edu, ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Date: Thu, 4 May 2006 06:57:42 -0700 To: "The Purple Streak, Hilarie Orman" X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 13:57:44.0730 (UTC) FILETIME=[B7D59FA0:01C66F82] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Hilarie, On May 3, 2006, at 7:36 PM, The Purple Streak, Hilarie Orman wrote: > > The large customer behind Suite B can't provide much guidance > to us re AES 256. Do they want more rounds or more entropy? > Or just something different? > I believe that the best motivation for AES-256 is as a hedge, as Steve put it, in case of unforeseen advances in cryptanalysis (quantum computers, new attack algorithms, and so on). > Signup for zero crypto growth --- stop at 128! > Ha! I like that. For sure a 128-bit security level is a suitable goal. But the hedging is intended to provide us with protection in case AES-128 doesn't actually meet that security goal. That's my understanding anyway. But I think that your main point is that we don't need to implement AES-256 in order for it to have value as a hedge. This is valid. Perhaps the real motivation for the use of AES-256 by the high- assurance community is that, considering that their crypto gear is quite expensive due to their stringent development and manufacturing processes, the additional cost for supporting bigger key sizes is inconsequential ;-) David From owner-ietf-rtpsec Thu May 4 07:11: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 k44EBiSp093646; Thu, 4 May 2006 07:11: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 k44EBiUW093645; Thu, 4 May 2006 07:11: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 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 k44EBhjN093638 for ; Thu, 4 May 2006 07:11:44 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 04 May 2006 07:11:39 -0700 X-IronPort-AV: i="4.05,88,1146466800"; d="scan'208"; a="272699724:sNHT33693932" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k44EBcYg008628; Thu, 4 May 2006 07:11:38 -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, 4 May 2006 07:11:38 -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); Thu, 4 May 2006 07:11:37 -0700 In-Reply-To: <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <475941AD-07C3-47CE-9B0F-F8FE7616887E@cisco.com> Cc: AVT , saag@mit.edu, ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: The use of AES-192 and AES-256 in Secure RTP Date: Thu, 4 May 2006 07:11:35 -0700 To: Lakshminath Dondeti X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 14:11:37.0511 (UTC) FILETIME=[A835EB70:01C66F84] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Lakshminath, a couple of comments inline: On May 2, 2006, at 3:08 PM, Lakshminath Dondeti wrote: > Hi David, > > Thanks for the clarifications. Please see inline for some follow- > up notes: > > At 01:41 PM 5/2/2006, David McGrew wrote: >> Hi Lakshminath, >> >> thanks for your comments, more inline: >> >> On May 2, 2006, at 9:50 AM, Lakshminath Dondeti wrote: >> >>> Hi David, >>> >>> As I read the email, I wondered about replacing HMAC-SHA-1 in 3711 >>> also, and glad to see that your open questions lists that. I have >>> a few questions: >>> >>> 1. Is the 112-bit salt sufficient even with longer keys? You might >>> recall that we've (Mark B., you and I) had discussions on the >>> master key and salt being input to a KDF that results in the >>> derivation of the encr_key, integ_key and a salt, where the output >>> might be longer than the input to the KDF. You are the expert in >>> this area, but I am still wondering if it is an issue. >> >> I think that the 112-bit salt is sufficient. The srtp salt is >> present so that the srtp use of counter mode is essentially as secure >> as CBC mode against attacks that amortize computational effort over >> multiple target keys. This property still holds for the larger key >> sizes. Besides, there's not much that we can do to increase the salt >> length, since there are only 16 more bits that we could possibly >> add. I also think that it is valuable to retain counter-format >> compatibility with the AES-128 counter mode. > > Ok, I understand the limitation on the salt size (also see below > about my misunderstanding of the block size in AES). I also > understand the aspect of offsetting counter-mode's relative key > strength using the salt and that for that purpose 112-bit salt is > sufficient. > > What about using a 128, 192, or 256-bit master key and 112-bit salt > to derive a 128, 192, 256-bit encryption key and a 160-bit, 256-bit > (assuming SHA-1 or SHA-2) and a session salt key (this is 112-bits > in size, right?)? Is entropy or lack thereof is a consideration. That's a good question. I believe that the way that there aren't any problems with the way that key derivation is defined, but it deserves some text in the security considerations. > > > >>> Figure 2 applies to AES-128 only, right? >> >> No, it's for all of the key sizes. AES-192 and AES-256 still have 16 >> byte plaintexts. Or maybe I'm not understanding; did I mislabel >> something? > > No, my mistake. I forgot that AES uses 128-bit blocks irrespective > of the key size. Apologies. > > >>> 2. I would suggest that this draft include AES-based CMAC, so we >>> can move away from SHA-1 and also use a single crypto primitive for >>> encryption, and PRF and MAC computation (opinion on your open >>> question). >> >> We think alike :-) I implemented AES CMAC for SRTP and found that it >> performs better than HMAC-SHA1 for very short packets (like those for >> conversational voice over a WAN) but not long packets (like video). >> It also has some other advantages. But OTOH there is a cost to >> proliferating cryptoalgorithms. Let's start up a separate thread on >> CMAC. > > We did talk about it before. The concept of using the same crypto > primitive came up elsewhere and that sounds like a good idea. > Please start that thread of discussion. Will do, but it may take a week. > > > >>> Q: What are the considerations in truncating cipher-based MAC >>> outputs? Specifically, is truncating below half-the-size of the >>> output (which I vaguely recall as relating to the birthday attack >>> in case of hash-based MACs -- perhaps it is not) of the cipher- >>> based MAC ok? >> >> Ah, good points. The NIST CMAC specification disallows truncation to >> MACs shorter than 64 bits. This is not because CMAC is weaker than >> an ideal MAC with respect to truncation, though. CMAC has been shown >> to be a good pseudorandom function if AES is a good blockcipher (as >> long as some usage limits are respected), and a PRF essentially is an >> ideal MAC. I'm pretty sure that the CMAC specification insists on >> MACs of at least 64 bits because it feels that a per-MAC forgery >> probability greater than 2^64 is not acceptable. No doubt they were >> not considering the case of stateless codecs, which some SRTP users >> need only 32-bit MACs. It is an interesting question as to what tag >> sizes would be recommended for use with CMAC! > > Let me think more about this. > > >>> What would be the strength of the MAC in that case. If we are >>> making a case for AES-192 or AES-256, then we have a certain >>> stronger adversary in mind (one that requires us to move away from >>> AES-128). In that case, why is MAC truncation not an issue? >> >> That's a good question. I think that in some circumstances it could >> make sense to use a short authentication tag and a huge key. If some >> unanticipated advance in cryptanalysis enables us to break AES-128 >> but not AES-256, but some user is still okay with accepting one out >> of a billion forged g.711 packets, this scenario would fit the bill. >> So the cryptosuites defined in the draft might make sense. But I >> take your point that users concerned that AES-128 doesn't have enough >> security may well not be satisfied with a 32-bit MAC. It would be >> good to get some input from the Suite B community on this question. > > Yes, we'll wait to hear from others. > > > >>> Let's discuss those for now. I may have more later :-). Thanks >>> for doing this! I was going to ask you about using CMAC in 3711! >> >> Any thoughts on whether or not AES-192 should be included? > > I think the use of AES-192 should be specified (at the expense of > more work for you :-) ), but let the "market" decide whether the > switch is to 192 or 256-bit keys. Actually, the draft does include AES-192, though at this point I'm inclined to remove it (TLS doesn't support it, as you pointed out :-) Not that it is a big deal, though. One approach that we could take would be to have the "big keys" draft say AES-256 is a MUST and AES-192 is a MAY. David > > regards, > Lakshminath > > >> David >> >>> regards, >>> Lakshminath >>> >>> At 08:15 AM 5/2/2006, David McGrew wrote: >>> >>>> Hello, >>>> >>>> there has been some interest in using AES with larger key sizes in >>>> Secure RTP, and some implementations have gone in this direction in >>>> advance of any specification. I wrote up an internet draft to fill >>>> this gap (after trying unsuccessfully to get someone else to write >>>> it :-) and to provide usage guidance and (eventually) test vectors. >>>> It's online at http://www.ietf.org/internet-drafts/draft-mcgrew- >>>> srtp- big-aes-00.txt >>>> >>>> I propose that this draft be adopted for standards track, and I ask >>>> for your review (if you have an interest in Secure RTP). Please >>>> note >>>> the "Open Questions" section. The ietf-rtpsec list is copied >>>> since >>>> this draft is potentially interesting there, even though the draft >>>> has little architectural impact. >>>> >>>> Best regards, >>>> >>>> David From owner-ietf-rtpsec Thu May 4 07:37:26 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 k44EbQv7095154; Thu, 4 May 2006 07:37:26 -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 k44EbQNQ095153; Thu, 4 May 2006 07:37:26 -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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44EbPG3095142 for ; Thu, 4 May 2006 07:37:25 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.81.115.240]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FbexC-0001Fe-6A; Thu, 04 May 2006 10:37:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <5ABD5019-6481-45A1-A981-4BE362E190F8@cisco.com> References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> <5ABD5019-6481-45A1-A981-4BE362E190F8@cisco.com> Date: Thu, 4 May 2006 10:36:39 -0400 To: David McGrew From: Stephen Kent Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Cc: saag@mit.edu, ietf-rtpsec@imc.org, Lakshminath Dondeti , AVT Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 4:14 AM -0700 5/4/06, David McGrew wrote: >... >One reason that I can think of for implementing AES-256 in this case >would be to conform to Suite B "TOP SECRET". But there are not many >other good reasons for implementing that key size at the present >time. The spec does promote algorithm agility, which is a good >thing. I guess that the trick is to provide for that agility without >making interoperability harder. I tried to do address the >interoperability issue in the draft by pointing out that AES-256 is >an addition to, not a replacement for, for AES-128. I also tried to >write the security considerations in such a way that encourages the >use of AES-128. The bigger key sizes are a hedge, as you put it, and >for almost all uses they are not needed at present. At least I tried >to convey that impression - I'd value comments from readers, and I'd >be happy to add or modify text in this direction. David, I don't think Suite B is relevant here. To be approved for protecting classified data at the TS level, a product will have to meet a lot of requirements, and the algorithm and key size are two of the easiest ones to meet. SRTP is carefully engineered to minimize overhead, and for commercial applications the tradeoffs that were made re security seem reasonable. However, there is non indication that these tradeoffs are appropriate for use in the classified data protection area. I note that DoD folks are working hard on defining how to use ROHC with IPsec, and a primary motivation is to enable use of IPsec, as implemented in HAIPS-compliant devices, to protect voice traffic. That is indicative of the current view on the suitability of using SRTP as a primary security mechanism for classified VoIP apoplications. Steve From owner-ietf-rtpsec Thu May 4 08:26:36 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 k44FQaXd097641; Thu, 4 May 2006 08:26:36 -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 k44FQae2097640; Thu, 4 May 2006 08:26:36 -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-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44FQZHK097631 for ; Thu, 4 May 2006 08:26:35 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 04 May 2006 08:26:30 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="426262600:sNHT31621694" 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 k44FQTRV004701; Thu, 4 May 2006 08:26:29 -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, 4 May 2006 08:26:29 -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); Thu, 4 May 2006 08:26:28 -0700 In-Reply-To: References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> <5ABD5019-6481-45A1-A981-4BE362E190F8@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: AVT , ietf-rtpsec@imc.org, saag@mit.edu Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Date: Thu, 4 May 2006 08:26:25 -0700 To: Stephen Kent X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 15:26:28.0886 (UTC) FILETIME=[1D475B60:01C66F8F] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Steve, On May 4, 2006, at 7:36 AM, Stephen Kent wrote: > At 4:14 AM -0700 5/4/06, David McGrew wrote: >> ... >> One reason that I can think of for implementing AES-256 in this >> case would be to conform to Suite B "TOP SECRET". But there are >> not many other good reasons for implementing that key size at the >> present time. The spec does promote algorithm agility, which is a >> good thing. I guess that the trick is to provide for that agility >> without making interoperability harder. I tried to do address the >> interoperability issue in the draft by pointing out that AES-256 >> is an addition to, not a replacement for, for AES-128. I also >> tried to write the security considerations in such a way that >> encourages the use of AES-128. The bigger key sizes are a hedge, >> as you put it, and for almost all uses they are not needed at >> present. At least I tried to convey that impression - I'd value >> comments from readers, and I'd >> be happy to add or modify text in this direction. > > David, > > I don't think Suite B is relevant here. To be approved for > protecting classified data at the TS level, a product will have to > meet a lot of requirements, and the algorithm and key size are two > of the easiest ones to meet. I take your point here. At http://www.nsa.gov/ia/industry/ crypto_suite_b.cfm, we're told that a CMVP evaluation is all that's needed to protect unclassified information (at which level AES-128 is considered sufficient, but AES-256 is allowed), but an NSA evaluation is required for implementations that protect classified info (which would require AES-256). An important question is: will the adopters of Suite B for the protection of unclassified information regard AES-256 as desirable? > SRTP is carefully engineered to minimize overhead, and for > commercial applications the tradeoffs that were made re security > seem reasonable. However, there is non indication that these > tradeoffs are appropriate for use in the classified data protection > area. I note that DoD folks are working hard on defining how to > use ROHC with IPsec, and a primary motivation is to enable use of > IPsec, as implemented in HAIPS-compliant devices, to protect voice > traffic. For sure the interest in ROHC stems from a desire to protect VoIP with ESP, and IMO this makes good sense. > That is indicative of the current view on the suitability of using > SRTP as a primary security mechanism for classified VoIP > apoplications. > > Steve Perhaps, though SRTP is comparable to ESP transport mode, and header compression in ESP is applicable to tunnel mode. Also, I've heard that AES-256 in SRTP has been discussed in other US DoD contexts, FWIW. But at any rate, I can't speak for the Suite B community, and I'm glad to take input from them on the content of the draft. There has been a bunch of good discussion on this draft, and my feeling is that we ought to standardize how to use AES-256 as an option in SRTP, but provide lots of guidance about the sufficiency of AES-128. Given that TLS and IPsec provide AES-256 options, I don't see how we can argue otherwise, and I'm concerned that incompatible implementations would proliferate in the absence of a standard. If the reference to Suite B is inappropriate, then it can be amended or removed. David From owner-ietf-rtpsec Thu May 4 10:51:52 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 k44Hpq6d006697; Thu, 4 May 2006 10:51:52 -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 k44HpqK5006696; Thu, 4 May 2006 10:51:52 -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 merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44HppEa006690 for ; Thu, 4 May 2006 10:51:51 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Thu, 4 May 2006 10:51:48 -0700 Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Thu, 04 May 2006 10:51:48 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 04 May 2006 10:51:48 -0700 In-Reply-To: References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> <5ABD5019-6481-45A1-A981-4BE362E190F8@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DB7E403-39E1-4933-9435-2741DD492940@callas.org> Cc: Stephen Kent , saag@mit.edu, ietf-rtpsec@imc.org, AVT Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Date: Thu, 4 May 2006 10:51:41 -0700 To: David McGrew X-Mailer: Apple Mail (2.749.3) Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with the assessment that there's no security need for AES-256. Until we get quantum computers or something like them, 128 bits are enough. However, there are trends that make it so that AES-256 is now the norm, regardless of what we think. Here are a number of reasons: * The intelligent-but-naive populace will think that 256 is better than 128. Bigger is better. The intelligent-but-paranoid crowd who vaguely remember the crypto wars are often convinced that 128-bits is now "exportable" (meaning easily breakable by efforts similar to DeepCrack). I talk to these people all the time. Yes, they exist. In short, customers respond positively to the use of 256-bit keys. * Suite B, which specifies 192/256 for top secret data reinforces the above. After all, if the government recommends 128 for secret data, and 256 for top secret, what's good for them is good for me. * AES-256 is 20%-ish slower than AES-128. In real-world systems, this ends up being far less. I did a bit of googling as I composed this to look for charts and numbers. You can, too. But look at which has nice charts of a variety of ciphers in SCP/SSH performance. In short, the *cost* of implementing AES-256 is low. The effect of these together is that the costs of 256 bit keys are low, the benefits in marketing, perception, and merely being seen as up-to-date are high. You can also denigrate those who are not offering 256. That's why you're seeing it. These aren't security reasons, they're human reasons. Jon From owner-ietf-rtpsec Thu May 4 12:15:18 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 k44JFIAv011850; Thu, 4 May 2006 12:15:18 -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 k44JFIhA011849; Thu, 4 May 2006 12:15:18 -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 k44JFHVR011835 for ; Thu, 4 May 2006 12:15:18 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 04 May 2006 12:15:12 -0700 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 k44JFCh0021814; Thu, 4 May 2006 12:15:12 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 12:15:12 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 12:15:11 -0700 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: AVT , ietf-rtpsec@imc.org, saag@mit.edu From: David McGrew Subject: The use of AES-192 and AES-256 in Secure RTP Date: Thu, 4 May 2006 12:15:10 -0700 X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 19:15:11.0709 (UTC) FILETIME=[10B7F8D0:01C66FAF] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, here's some additional text that explains the "hedge" strategy. Perhaps it's worth adding to the draft. Comments welcome. David The main motivation for AES-192 and AES-256 is to provide alternative ciphers to AES-128 that can be adopted in event that unforeseen advances in cryptanalysis significantly erode the security level of AES-128. The main purpose of this specification is to provide algorithm agility to SRTP, to allow that protocol to easily adopt the alternative ciphers if the need arises in the future. It MUST NOT be interpreted as discouraging the use of AES-128. Implementers MAY support the alternative ciphers in advance of any need to replace AES-128, in order to facilitate a potential future 'hot swap' replacement, but those implementations MUST be prepared to interoperate with implementations that do not support the alternative ciphers. From owner-ietf-rtpsec Thu May 4 12:26:32 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 k44JQWUg012295; Thu, 4 May 2006 12:26:32 -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 k44JQVVk012294; Thu, 4 May 2006 12:26:31 -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 [10.0.6.56] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44JQHbt012278; Thu, 4 May 2006 12:26:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> References: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> Date: Thu, 4 May 2006 12:26:17 -0700 To: David McGrew , AVT , ietf-rtpsec@imc.org, saag@mit.edu From: Paul Hoffman Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:15 PM -0700 5/4/06, David McGrew wrote: >It MUST NOT be >interpreted as discouraging the use of AES-128. Half-nit: that's an improper use of MUST NOT according to RFC 2119. More important: you also don't want to encourage use of things other than AES-128 unless needed. Proposed change: It should not be interpreted as discouraging the use of AES-128, nor encouraging the use of AES-192 or AES-256 unless there is a strong cryptographic reason to do so. --Paul Hoffman, Director --VPN Consortium From owner-ietf-rtpsec Thu May 4 13:42:25 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 k44KgPxp015127; Thu, 4 May 2006 13:42:25 -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 k44KgPXe015126; Thu, 4 May 2006 13:42:25 -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 merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44KgONc015109 for ; Thu, 4 May 2006 13:42:24 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Thu, 4 May 2006 13:42:23 -0700 Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Thu, 04 May 2006 13:42:23 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 04 May 2006 13:42:23 -0700 In-Reply-To: References: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: David McGrew , AVT , ietf-rtpsec@imc.org, saag@mit.edu Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Date: Thu, 4 May 2006 13:42:20 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.749.3) Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Proposed change: It should not be interpreted as discouraging the use > of AES-128, nor encouraging the use of AES-192 or AES-256 unless > there is a strong cryptographic reason to do so. How about "must not" rather than "should not." Yeah, it's not an appropriate use of MUST or SHOULD, but I think the emphasis should be there (and my use of "should" is also intentional). We need to fight the slide. I think Dave's paragraph is wonderful. Jon From owner-ietf-rtpsec Mon May 8 03:33:28 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 k48AXSZn037815; Mon, 8 May 2006 03:33:28 -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 k48AXSPk037814; Mon, 8 May 2006 03:33:28 -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 gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48AXQVE037807 for ; Mon, 8 May 2006 03:33:27 -0700 (MST) (envelope-from steffen.fries@siemens.com) Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k48AXJYN024548; Mon, 8 May 2006 12:33:21 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k48AXILU018704; Mon, 8 May 2006 12:33:18 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 12:33:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [AVT] Re: The use of AES-192 and AES-256 in Secure RTP Date: Mon, 8 May 2006 12:33:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Re: The use of AES-192 and AES-256 in Secure RTP Thread-Index: AcZuNaVqXrztNxldS8SNUwPoGHdX3wESWgpA From: "Fries, Steffen" To: "Lakshminath Dondeti" , "David McGrew" Cc: , , "AVT" X-OriginalArrivalTime: 08 May 2006 10:33:17.0904 (UTC) FILETIME=[D1E38500:01C6728A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k48AXRVE037809 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi David, hi Lakshminath, sorry for the late response to that issue: > >>2. I would suggest that this draft include AES-based CMAC, so we > >>can move away from SHA-1 and also use a single crypto primitive for > >>encryption, and PRF and MAC computation (opinion on your open > >>question). > > > >We think alike :-) I implemented AES CMAC for SRTP and found that it > >performs better than HMAC-SHA1 for very short packets (like those for > >conversational voice over a WAN) but not long packets (like video). > >It also has some other advantages. But OTOH there is a cost to > >proliferating cryptoalgorithms. Let's start up a separate thread on > >CMAC. > > We did talk about it before. The concept of using the same crypto > primitive came up elsewhere and that sounds like a good idea. Please > start that thread of discussion. I assume that AES CMAC would go as an option into the draft, to be on one hand backward compatible and on the other hand be able to support different algorithms for MAC and encryption. BTW, is there a general opinion/advice, if it is better to use different mechanisms for different services (encryption, integrity) to not loose the complete security if one mechanism is broken? Regards Steffen > > > >>Q: What are the considerations in truncating cipher-based MAC > >>outputs? Specifically, is truncating below half-the-size of the > >>output (which I vaguely recall as relating to the birthday attack > >>in case of hash-based MACs -- perhaps it is not) of the > cipher- based MAC ok? > > > >Ah, good points. The NIST CMAC specification disallows truncation to > >MACs shorter than 64 bits. This is not because CMAC is weaker than > >an ideal MAC with respect to truncation, though. CMAC has been shown > >to be a good pseudorandom function if AES is a good blockcipher (as > >long as some usage limits are respected), and a PRF essentially is an > >ideal MAC. I'm pretty sure that the CMAC specification insists on > >MACs of at least 64 bits because it feels that a per-MAC forgery > >probability greater than 2^64 is not acceptable. No doubt they were > >not considering the case of stateless codecs, which some SRTP users > >need only 32-bit MACs. It is an interesting question as to what tag > >sizes would be recommended for use with CMAC! > > Let me think more about this. > > > >>What would be the strength of the MAC in that case. If we are > >>making a case for AES-192 or AES-256, then we have a certain > >>stronger adversary in mind (one that requires us to move away from > >>AES-128). In that case, why is MAC truncation not an issue? > > > >That's a good question. I think that in some circumstances it could > >make sense to use a short authentication tag and a huge key. If some > >unanticipated advance in cryptanalysis enables us to break AES-128 > >but not AES-256, but some user is still okay with accepting one out > >of a billion forged g.711 packets, this scenario would fit the bill. > >So the cryptosuites defined in the draft might make sense. But I > >take your point that users concerned that AES-128 doesn't have enough > >security may well not be satisfied with a 32-bit MAC. It would be > >good to get some input from the Suite B community on this question. > > Yes, we'll wait to hear from others. > > > > >>Let's discuss those for now. I may have more later :-). Thanks > >>for doing this! I was going to ask you about using CMAC in 3711! > > > >Any thoughts on whether or not AES-192 should be included? > > I think the use of AES-192 should be specified (at the expense of > more work for you :-) ), but let the "market" decide whether the > switch is to 192 or 256-bit keys. > > regards, > Lakshminath > > > >David > > > >>regards, > >>Lakshminath > >> > >>At 08:15 AM 5/2/2006, David McGrew wrote: > >> > >>>Hello, > >>> > >>>there has been some interest in using AES with larger key sizes in > >>>Secure RTP, and some implementations have gone in this direction in > >>>advance of any specification. I wrote up an internet draft to fill > >>>this gap (after trying unsuccessfully to get someone else to write > >>>it :-) and to provide usage guidance and (eventually) test vectors. > >>>It's online at http://www.ietf.org/internet-drafts/draft-mcgrew- > >>>srtp- big-aes-00.txt > >>> > >>>I propose that this draft be adopted for standards track, and I ask > >>>for your review (if you have an interest in Secure RTP). > Please note > >>>the "Open Questions" section. The ietf-rtpsec list is > copied since > >>>this draft is potentially interesting there, even though the draft > >>>has little architectural impact. > >>> > >>>Best regards, > >>> > >>>David > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > From owner-ietf-rtpsec Mon May 8 09:13: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 k48GDLwa051853; Mon, 8 May 2006 09:13: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 k48GDLg3051852; Mon, 8 May 2006 09:13: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 [10.20.30.249] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48GBt3O051785; Mon, 8 May 2006 09:11:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> References: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> Date: Mon, 8 May 2006 09:12:03 -0700 To: David McGrew , AVT , ietf-rtpsec@imc.org, saag@mit.edu From: Paul Hoffman Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:15 PM -0700 5/4/06, David McGrew wrote: >The main motivation for AES-192 and AES-256 is to provide alternative >ciphers to AES-128 that can be adopted in event that unforeseen >advances in cryptanalysis significantly erode the security level of >AES-128. The downside of proposing multiple alternative ciphers, as compared to just one, is that it is likely that implementers will not do interop testing on all of them. It is much better to propose just one fall-back cipher. This is particularly true for AES, as we have discovered in the VPNC test lab. For IETF standards where AES-128 is a MUST-level requirement, there should be just one fall-back, AES-256, with wording like the "SHOULD+" definitions in RFC 4307. --Paul Hoffman, Director --VPN Consortium From owner-ietf-rtpsec Mon May 8 09:18:04 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 k48GI4ew052012; Mon, 8 May 2006 09:18:04 -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 k48GI4aB052011; Mon, 8 May 2006 09:18: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 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 k48GI3gn051996 for ; Mon, 8 May 2006 09:18:04 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 08 May 2006 09:17:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k48GHwh0023731; Mon, 8 May 2006 09:17:58 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 May 2006 09:17:58 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 May 2006 09:17:57 -0700 In-Reply-To: References: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: AVT , ietf-rtpsec@imc.org, saag@mit.edu Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Date: Mon, 8 May 2006 09:17:54 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 08 May 2006 16:17:57.0633 (UTC) FILETIME=[F7F7BF10:01C672BA] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul, good points, I'm convinced that it would be better to dump AES-192 from the spec. David On May 8, 2006, at 9:12 AM, Paul Hoffman wrote: > At 12:15 PM -0700 5/4/06, David McGrew wrote: >> The main motivation for AES-192 and AES-256 is to provide >> alternative ciphers to AES-128 that can be adopted in event that >> unforeseen advances in cryptanalysis significantly erode the >> security level of >> AES-128. > > The downside of proposing multiple alternative ciphers, as compared > to just one, is that it is likely that implementers will not do > interop testing on all of them. It is much better to propose just > one fall-back cipher. This is particularly true for AES, as we have > discovered in the VPNC test lab. > > For IETF standards where AES-128 is a MUST-level requirement, there > should be just one fall-back, AES-256, with wording like the "SHOULD > +" definitions in RFC 4307. > > --Paul Hoffman, Director > --VPN Consortium From owner-ietf-rtpsec Tue May 9 17:48:52 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 k4A0mq1G030644; Tue, 9 May 2006 17:48:52 -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 k4A0mqIO030643; Tue, 9 May 2006 17:48:52 -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 k4A0mpZ9030637 for ; Tue, 9 May 2006 17:48:52 -0700 (MST) (envelope-from alan@sipstation.com) Received: from san-cust-208.57.35.169.mpowercom.net ([208.57.35.169]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1Fdcsh-0000HT-DU; Tue, 09 May 2006 20:48:49 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 208.57.35.169 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: <4461386D.9000100@sipstation.com> Date: Tue, 09 May 2006 19:48:45 -0500 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins CC: David McGrew , ietf-rtpsec@imc.org Subject: RTCP and in-path (Was Re: Requirements, First) References: <44405030.1010901@sipstation.com> <35337CB5-56C9-4304-9CB1-4A2DC0A2D50D@cisco.com> <4440F3DE.8060401@sipstation.com> <6403EE4C-E2ED-4604-8100-DA6A2C52BC9C@cisco.com> <44C5F8B3-6818-4C96-AAF0-51B05E29A134@csperkins.org> In-Reply-To: <44C5F8B3-6818-4C96-AAF0-51B05E29A134@csperkins.org> 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: Colin, A few comments on RTCP and in-path transport below. Thanks, Alan Colin Perkins wrote: > > David, > > [Catching up - apologies for slow response] > > On 24 Apr 2006, at 15:12, David McGrew wrote: > >> On Apr 19, 2006, at 1:37 AM, Colin Perkins wrote: >> >>> On 15 Apr 2006, at 14:23, Alan Johnston wrote: >>> ... >>> >>>> 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. >>> >>> >>> Perhaps, but I'd also like to see an analysis of the impact this >>> has on RTP and on the devices which use it. It's not clear that >>> doing the signalling in-band with the media won't break other >>> devices which make assumptions on the contents of a stream that are >>> not valid when in-band keying extensions are used, even if those >>> extensions are legal RTP (an example might be devices which require >>> header compression and MTU matching the RTP packet size, which >>> would likely have trouble with RTP header extensions). >> >> >> I asked a few firewall implementers about RTP in-band keying. It >> seems as though all of the in-band methods would have trouble >> passing through firewalls that do RTP conformance checking. >> Firewalls would need to be updated in order for firewall traversal >> to work properly. (As an aside, it seems like the header extension >> method would get past the most firewalls, though any method which >> didn't change the RTP header would do just as well.) > > I have tested ZRTP through a number of media intermediaries including a number of SIP and RTP aware firewalls, and ZRTP does work (that is, RTP header extensions do traverse) through most of them. The ones where it fails are the ones that completely terminate the RTP stream, go back to the codec (ones that do transcoding go back to the audio) then rebuild the RTP packet again. These devices truly terminate the media path, and I'm sure it is not possible to do end-to-end secure media through one of these devices. > Sure. I also suspect that 3G wireless devices which match the audio > frame size to the channel MTU will have difficulty with in-band > signalling in RTP. Doing the signalling for the RTP channel within > RTCP would likely ease these issues, and would also fit the RTP > architecture better. > I have a few practical problems with using RTCP. First, many UAs today don't implement RTCP. Adding a requirement that UAs first implement RTCP before they can key SRTP might limit the usefulness of the solution. Secondly, and more importantly, RTCP is difficult to get through NATs and firewalls. The unfortunate odd/even implicit port allocation fails through port mapping NATs (although RFC 3605 fixes this, but again, we don't want to design a solution that is dependent on extra extensions), and also requires a second run through ICE to open RTCP ports. If I look at real implementations, they are minimalist - they only implement what they must to make things work - this is one reason why using RTP is better from a practical point of view - every implementation must support RTP or the resulting sessions are awfully quiet ;-) >> The approach that Mark mentioned on this thread - end-to-end keying >> that's on-path but not in-band - would have the advantages that Alan >> cites above, but would also have issues with NAT. It seems that the >> VoIP community is willing to trade NAT traversal problems for FW >> traversal problems :-) > > > A dedicated on-path signalling channel would ease both security > negotiation and device control, and would actually be a good thing to > have. Yes, it complicates NAT traversal though. Any solution must not require any new ports to be opened - anything that complicates NAT traversal is a non-starter in my opinion. I hope we really have learnt this hard lesson already... Another protocol multiplexed over the same ports as RTP is an interesting idea, like the way ICE sends STUN packets to RTP ports. In ZRTP, the RTP header extension is really only needed for discovery. This is because you don't need to rely on the signaling to find out if the other UA supports ZRTP - it can be discovered more rapidly and effectively in-band by a Hello message in the first few RTP packets exchanged. At the SIPit last month, I tested Zfone against practically every UA there and all of them responded correctly to RTP packets with an unknown RTP header extension present - they simply ignored it. Once the in-band discovery has succeeded, the rest of the key management doesn't need to take place within RTP - it could be another protocol, even MIKEY, as long as it used the same ports as RTP. However, some media intermediary devices might not pass media packets that don't look like RTP - we'd need to get some field tests to know for sure. Thanks, Alan > > Colin > > > From owner-ietf-rtpsec Wed May 10 12:01:17 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 k4AJ1H9F075798; Wed, 10 May 2006 12:01:17 -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 k4AJ1HUG075797; Wed, 10 May 2006 12:01:17 -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 k4AJ1F3c075787 for ; Wed, 10 May 2006 12:01:16 -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); Wed, 10 May 2006 15:01:45 -0400 To: Alan Johnston Cc: Colin Perkins , David McGrew , ietf-rtpsec@imc.org Subject: Re: RTCP and in-path (Was Re: Requirements, First) References: <44405030.1010901@sipstation.com> <35337CB5-56C9-4304-9CB1-4A2DC0A2D50D@cisco.com> <4440F3DE.8060401@sipstation.com> <6403EE4C-E2ED-4604-8100-DA6A2C52BC9C@cisco.com> <44C5F8B3-6818-4C96-AAF0-51B05E29A134@csperkins.org> <4461386D.9000100@sipstation.com> From: Randell Jesup Reply-to: Randell Jesup Date: Wed, 10 May 2006 15:03:39 -0400 In-Reply-To: <4461386D.9000100@sipstation.com> (Alan Johnston's message of "Tue, 09 May 2006 19:48:45 -0500") 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: 10 May 2006 19:01:45.0829 (UTC) FILETIME=[2EDAF150:01C67464] Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan Johnston writes: >> Sure. I also suspect that 3G wireless devices which match the audio >> frame size to the channel MTU will have difficulty with in-band >> signalling in RTP. Doing the signalling for the RTP channel within RTCP >> would likely ease these issues, and would also fit the RTP architecture >> better. >> >I have a few practical problems with using RTCP. First, many UAs today >don't implement RTCP. Adding a requirement that UAs first implement RTCP >before they can key SRTP might limit the usefulness of the solution. Well, if they're adding SRTP, implementing (simple) RTCP as part of that shouldn't be hard. And ones that don't support this keying over RTCP would ignore it (either the keying or all RTCP). I'd be more worried about SBCs and NATs. >Secondly, and more importantly, RTCP is difficult to get through NATs and >firewalls. The unfortunate odd/even implicit port allocation fails through >port mapping NATs (although RFC 3605 fixes this, but again, we don't want >to design a solution that is dependent on extra extensions), and also >requires a second run through ICE to open RTCP ports. Again, though, if these extensions (3605) matter to devices implementing this keying, they can add support for that - though again, SBCs and ALGs can interfere here if they don't understand it. In general (with admitted exceptions) things like SBCs *should be* more "complete" and compliant than UAs tend to be. >If I look at real implementations, they are minimalist - they only >implement what they must to make things work - this is one reason why using >RTP is better from a practical point of view - every implementation must >support RTP or the resulting sessions are awfully quiet ;-) Understood and I partially agree - the caveats are as above; if you _need_ simple RTCP to key SRTP, then it's not hard to do when you're implementing SRTP, and if you're not it doesn't matter. >> A dedicated on-path signalling channel would ease both security >> negotiation and device control, and would actually be a good thing to >> have. Yes, it complicates NAT traversal though. > >Any solution must not require any new ports to be opened - anything that >complicates NAT traversal is a non-starter in my opinion. I hope we really >have learnt this hard lesson already... A good point. It can also slow call setup (ICEing more ports). >Once the in-band discovery has succeeded, the rest of the key management >doesn't need to take place within RTP - it could be another protocol, even >MIKEY, as long as it used the same ports as RTP. However, some media >intermediary devices might not pass media packets that don't look like RTP >- we'd need to get some field tests to know for sure. Alternatively - you can do ZRTP/etc "hello" without using extensions, by using a innocuous G.711 almost-silence packet with a very specific form as a marker, which starts a quick negotiation. Pseudo-stenography, at least for key negotiation - which will mean you don't have to rely on elements passing header extensions or intermediary devices thinking they weren't media (etc). You could specify "Hello" and response patterns for each codec type that would decode harmlessly. You could even (as I mentioned before) hide a low-bitrate codec's data (say g.723 or iLBC) in a higher-bitrate (G.711/722/etc) codec's data - real stenography. Admittedly, more complex and annoying than header extensions (if extensions work, which for the most part they do, modulo perhaps some very bandwidth-limited channels), so probably not worth it. -- 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 Mon May 15 01:09:04 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 k4F893FI067249; Mon, 15 May 2006 01:09:03 -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 k4F893pK067248; Mon, 15 May 2006 01:09:03 -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 gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4F892Oe067231 for ; Mon, 15 May 2006 01:09:02 -0700 (MST) (envelope-from steffen.fries@siemens.com) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k4F88xjM013642; Mon, 15 May 2006 10:08:59 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k4F88wsV004112; Mon, 15 May 2006 10:08:58 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 10:08:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: KM approach using MIKEY and EKT Date: Mon, 15 May 2006 10:08:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KM approach using MIKEY and EKT Thread-Index: AcZyu5rVuKJNOMMwQ36ZMTJsZVvwbgFNTP+g From: "Fries, Steffen" To: "David McGrew" Cc: X-OriginalArrivalTime: 15 May 2006 08:08:58.0259 (UTC) FILETIME=[D13ACE30:01C677F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4F893Oe067243 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi David, based on the discussion we had during the last IETF meeting and the requirements discussed on the list here I would like to share some ideas regarding the interworking of EKT and MIKEY. The current EKT document does not talk about the cooperation of both in specific. It rather mentions the usage of MIKEY to establish the EKT key, cipher and SPI values in section 4. Combining EKT with MIKEY would be advanterous for the MIKEY modes needing a full roundtrip. What I have in mind are specifically the DH approaches but also the rsa-r method could gain from it. Here the following may be supported with EKT, keeping in mind that early media and forking are the important issues. A is sending an INVITE to B including the MIKEY I_message containing a signed DH half key as well as a new payload indicating the use of EKT. Upon reciving this INVITE B can use his DH half key and can calculate the DH secret, derive the SRTP master key for the connection to A. B's DH half key can now be fed into EKT and send over to A via SRTCP (or even SRTP, if EKT is going to support it). Upon receiving the DH half key A can also calculate the DH secret and start to decrypt the received SRTP stream. B sends the MIKEY_R message also in the signaling back to A. Upon receiving this message A is in a position to verify, that he got the same DH half key via EKT as he received in MIKEY. This is to provide A with the assurance that nobody performs a MitM attack on the media path. EKT requires a shared key to protect the key distribution, which is not in place here. One may use a signed DH to cope with this or, when using an unsigned DH, start with SRTP based on the received parameter and get a delayed, authenticated DH, via the signaling. This approach would solve both the early media and the forking. Early media is ensured, as EKT is transported directly to B inside SRTCP (or even inside SRTP, if this is going to be defined). Moreover the forking is eased as now, security precondition may not be needed and thus the provisional responses connected with the security preconditions do not need to be sent. Problems I see here are the following: - The caller gets the assurance about the quality of the security when receiving the 200 OK. Before that he cannot be sure regarding a MitM. - Fragmentation. As signed DH messages or asymmetric encrypted messages are rather large, the common path MTU boundary may be crossed. Therfore the approach with the unsigned DH above. What's your opinion to that approach? Would that be something to include in the EKT ID when it is updated? Regards Steffen From owner-ietf-rtpsec Mon May 15 01:52: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 k4F8qDEn076894; Mon, 15 May 2006 01:52:13 -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 k4F8qDlg076893; Mon, 15 May 2006 01:52:13 -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 k4F8qCgp076878 for ; Mon, 15 May 2006 01:52:13 -0700 (MST) (envelope-from csp@csperkins.org) Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60787 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FfYoE-00032j-Ni; Mon, 15 May 2006 09:52:10 +0100 In-Reply-To: <4461386D.9000100@sipstation.com> References: <44405030.1010901@sipstation.com> <35337CB5-56C9-4304-9CB1-4A2DC0A2D50D@cisco.com> <4440F3DE.8060401@sipstation.com> <6403EE4C-E2ED-4604-8100-DA6A2C52BC9C@cisco.com> <44C5F8B3-6818-4C96-AAF0-51B05E29A134@csperkins.org> <4461386D.9000100@sipstation.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: David McGrew , ietf-rtpsec@imc.org Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: RTCP and in-path (Was Re: Requirements, First) Date: Mon, 15 May 2006 09:52:07 +0100 To: Alan Johnston X-Mailer: Apple Mail (2.750) Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan, On 10 May 2006, at 01:48, Alan Johnston wrote: ... > I have tested ZRTP through a number of media intermediaries > including a number of SIP and RTP aware firewalls, and ZRTP does > work (that is, RTP header extensions do traverse) through most of > them. The ones where it fails are the ones that completely > terminate the RTP stream, go back to the codec (ones that do > transcoding go back to the audio) then rebuild the RTP packet > again. These devices truly terminate the media path, and I'm sure > it is not possible to do end-to-end secure media through one of > these devices. ZRTP should certainly go through compliant firewalls. I'm more concerned with low-MTU links, for example on various wireless devices. >> Sure. I also suspect that 3G wireless devices which match the >> audio frame size to the channel MTU will have difficulty with in- >> band signalling in RTP. Doing the signalling for the RTP channel >> within RTCP would likely ease these issues, and would also fit >> the RTP architecture better. >> > I have a few practical problems with using RTCP. First, many UAs > today don't implement RTCP. Adding a requirement that UAs first > implement RTCP before they can key SRTP might limit the usefulness > of the solution. I have little sympathy for broken implementations. An RTCP implementation is around 1500 lines of C code, so complexity is not an issue, and it's a mandatory part of RTP, required in many circumstances. > Secondly, and more importantly, RTCP is difficult to get through > NATs and firewalls. The unfortunate odd/even implicit port > allocation fails through port mapping NATs (although RFC 3605 fixes > this, but again, we don't want to design a solution that is > dependent on extra extensions), Why not? You'll already require several extensions (ICE, STUN, TURN, SRTP and whatever keying solution we develop). RFC 3605 is a trivial addition, once you've implemented all the rest. > and also requires a second run through ICE to open RTCP ports. Again, so what? You'll have the ICE implementation already, and the RTCP ICE exchange can happen after the RTP exchange, so it doesn't increase call setup delays. ... > Another protocol multiplexed over the same ports as RTP is an > interesting idea, like the way ICE sends STUN packets to RTP > ports. In ZRTP, the RTP header extension is really only needed for > discovery. This is because you don't need to rely on the signaling > to find out if the other UA supports ZRTP - it can be discovered > more rapidly and effectively in-band by a Hello message in the > first few RTP packets exchanged. At the SIPit last month, I tested > Zfone against practically every UA there and all of them responded > correctly to RTP packets with an unknown RTP header extension > present - they simply ignored it. Presumably they'll also ignore non-RTP packets? In which case, there's no real need to tunnel ZRTP in RTP at all. > Once the in-band discovery has succeeded, the rest of the key > management doesn't need to take place within RTP - it could be > another protocol, even MIKEY, as long as it used the same ports as > RTP. However, some media intermediary devices might not pass media > packets that don't look like RTP - we'd need to get some field > tests to know for sure. In which case, they won't pass STUN either... Colin From owner-ietf-rtpsec Mon May 15 04:17:07 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 k4FBH7nH013839; Mon, 15 May 2006 04:17:07 -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 k4FBH7Gi013838; Mon, 15 May 2006 04:17:07 -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 gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4FBH5Mq013823 for ; Mon, 15 May 2006 04:17:06 -0700 (MST) (envelope-from steffen.fries@siemens.com) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k4FBH3f4001123; Mon, 15 May 2006 13:17:03 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k4FBH25W002897; Mon, 15 May 2006 13:17:03 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 13:17:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: KM approach using MIKEY and EKT Date: Mon, 15 May 2006 13:17:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KM approach using MIKEY and EKT Thread-Index: AcZyu5rVuKJNOMMwQ36ZMTJsZVvwbgFNTP+gAAXvxLA= From: "Fries, Steffen" To: "David McGrew" Cc: X-OriginalArrivalTime: 15 May 2006 11:17:02.0662 (UTC) FILETIME=[17420E60:01C67811] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4FBH6Mq013825 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi David, as an addition to the described approach, one could also leverage the idea of keeping hashes of session keys for further sessions. E.g., one could save the hash of the DH secret of the ongoing call and use it as shared secret with EKT for the next call to the same destination. This would limit the vulnerability for MitM attacks when using unsigned DH to the very first call. Regards Steffen > -----Original Message----- > From: owner-ietf-rtpsec@mail.imc.org > [mailto:owner-ietf-rtpsec@mail.imc.org] On Behalf Of Fries, Steffen > Sent: Monday, May 15, 2006 10:09 AM > To: David McGrew > Cc: ietf-rtpsec@imc.org > Subject: KM approach using MIKEY and EKT > > > Hi David, > > based on the discussion we had during the last IETF meeting > and the requirements discussed on the list here I would like > to share some ideas regarding the interworking of EKT and > MIKEY. The current EKT document does not talk about the > cooperation of both in specific. > It rather mentions the usage of MIKEY to establish the EKT > key, cipher and SPI values in section 4. > > Combining EKT with MIKEY would be advanterous for the MIKEY > modes needing a full roundtrip. What I have in mind are > specifically the DH approaches but also the rsa-r method > could gain from it. Here the following may be supported with > EKT, keeping in mind that early media and forking are the > important issues. A is sending an INVITE to B including the > MIKEY I_message containing a signed DH half key as well as a > new payload indicating the use of EKT. Upon reciving this > INVITE B can use his DH half key and can calculate the DH > secret, derive the SRTP master key for the connection to A. > B's DH half key can now be fed into EKT and send over to A > via SRTCP (or even SRTP, if EKT is going to support it). Upon > receiving the DH half key A can also calculate the DH secret > and start to decrypt the received SRTP stream. B sends the > MIKEY_R message also in the signaling back to A. > Upon receiving this message A is in a position to verify, > that he got the same DH half key via EKT as he received in > MIKEY. This is to provide A with the assurance that nobody > performs a MitM attack on the media path. EKT requires a > shared key to protect the key distribution, which is not in > place here. One may use a signed DH to cope with this or, > when using an unsigned DH, start with SRTP based on the > received parameter and get a delayed, authenticated DH, via > the signaling. > > This approach would solve both the early media and the forking. > Early media is ensured, as EKT is transported directly to B > inside SRTCP (or even inside SRTP, if this is going to be > defined). Moreover the forking is eased as now, security > precondition may not be needed and thus the provisional > responses connected with the security preconditions do not > need to be sent. > > Problems I see here are the following: > - The caller gets the assurance about the quality of the security when > receiving the 200 OK. Before that he cannot be sure > regarding a MitM. > - Fragmentation. As signed DH messages or asymmetric > encrypted messages > are rather large, the common path MTU boundary may be crossed. > Therfore > the approach with the unsigned DH above. > > What's your opinion to that approach? Would that be something > to include in the EKT ID when it is updated? > > Regards > Steffen > > From owner-ietf-rtpsec Mon May 15 14:33: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 k4FLXB3J045790; Mon, 15 May 2006 14:33:11 -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 k4FLXBa7045789; Mon, 15 May 2006 14:33:11 -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 k4FLXB8u045776 for ; Mon, 15 May 2006 14:33:11 -0700 (MST) (envelope-from jmpolk@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 15 May 2006 14:32:55 -0700 X-IronPort-AV: i="4.05,130,1146466800"; d="scan'208"; a="277104953:sNHT2213380548" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4FLWscQ006966 for ; Mon, 15 May 2006 14:32:54 -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 k4FLWqHe011838 for ; Mon, 15 May 2006 14:32:54 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 May 2006 14:32:51 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.16.83]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 May 2006 14:32:51 -0700 Message-Id: <4.3.2.7.2.20060515163012.03802be8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 May 2006 16:32:48 -0500 To: From: "James M. Polk" Subject: Re: Optional SRTP with SDES? In-Reply-To: References: <68CA46B2-1D20-4492-B4A5-22A94E357435@csperkins.org> <0D1719326D64BD4E9F92A0C120237678C250F5@eserv.covergence.com> <68CA46B2-1D20-4492-B4A5-22A94E357435@csperkins.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 15 May 2006 21:32:51.0699 (UTC) FILETIME=[1E99AC30:01C67867] DKIM-Signature: a=rsa-sha1; q=dns; l=302; t=1147728774; x=1148592774; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20Optional=20SRTP=20with=20SDES?; X=v=3Dcisco.com=3B=20h=3D7daTADtn1c7UZtL2TtCwe7EHT7c=3D; b=A/FHp6ulkiLpfRsOnESmgwKpK+a2QFSG3Gsw9BwYxelD5MaRy6siGMCFW+Zv30NvTuGjvBNw 9oYHSq32nwBOo7b8Pf/EcYlqUFYT+auCCwhQFPkklEmsG9luw+8yw4p+; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Is it the intention of this list to have its own BoF in Montreal, or be part of an Open RAI Area meeting again? If either is the case, can someone indicate this. I'm trying to work out WG conflicts with other WGs on the Scheduler, and I don't have either of the above as a choice. Thanks From owner-ietf-rtpsec Fri May 19 08: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 k4JF7ju0037474; Fri, 19 May 2006 08: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 k4JF7jGx037470; Fri, 19 May 2006 08: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 outbound1-cpk-R.bigfish.com (outbound-cpk.frontbridge.com [207.46.163.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4JF7hDt037436 for ; Fri, 19 May 2006 08:07:43 -0700 (MST) (envelope-from laurent.pilati@mindspeed.com) Received: from outbound1-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-cpk-R.bigfish.com (Postfix) with ESMTP id A2193A49666; Fri, 19 May 2006 15:07:37 +0000 (UTC) Received: from mail79-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound1-cpk.bigfish.com (Postfix) with ESMTP id 9AC4DA495CC; Fri, 19 May 2006 15:07:37 +0000 (UTC) Received: from mail79-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail79-cpk-R.bigfish.com (Postfix) with ESMTP id 89B8E4066BF; Fri, 19 May 2006 15:07:37 +0000 (UTC) X-BigFish: VP Received: by mail79-cpk (MessageSwitch) id 1148051257459585_6546; Fri, 19 May 2006 15:07:37 +0000 (UCT) Received: from mspdsmtp2.mindspeed.com (mspdsmtp2.mindspeed.com [199.33.64.93]) by mail79-cpk.bigfish.com (Postfix) with ESMTP id 2BE663FB408; Fri, 19 May 2006 15:07:37 +0000 (UTC) Received: from npblnh1.la.mindspeed.com (npblnh1.nb.mindspeed.com [10.1.16.81]) by mspdsmtp2.mindspeed.com (8.11.7p1+Sun/8.11.7) with ESMTP id k4JF7am17258; Fri, 19 May 2006 08:07:36 -0700 (PDT) Received: from sophiam1.nice.mindspeed.com ([10.1.124.21]) by npblnh1.la.mindspeed.com (Lotus Domino Release 6.5.3) with ESMTP id 2006051908072537-223966 ; Fri, 19 May 2006 08:07:25 -0700 To: David McGrew Cc: AVT , ietf-rtpsec@imc.org, owner-ietf-rtpsec@mail.imc.org, Paul Hoffman , saag@mit.edu Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: laurent.pilati@mindspeed.com Date: Fri, 19 May 2006 17:07:33 +0200 X-MIMETrack: Serialize by Router on SOPHIAM1/Server/Mindspeed(653HF723|September 16, 2005) at 05/19/2006 05:07:31 PM, Serialize complete at 05/19/2006 05:07:31 PM, Itemize by SMTP Server on NPBLNH1/Server/Conexant(Release 6.5.3|September 14, 2004) at 05/19/2006 08:07:25 AM, Serialize by Router on NPBLNH1/Server/Conexant(Release 6.5.3|September 14, 2004) at 05/19/2006 08:07:26 AM, Serialize complete at 05/19/2006 08:07:26 AM Content-Type: multipart/alternative; boundary="=_alternative 0053167AC1257173_=" Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multipart message in MIME format. --=_alternative 0053167AC1257173_= Content-Type: text/plain; charset="us-ascii" Hi all, As a suggestion, would it be also possible to use SSRC and RTP sequence number different of 0000 for the AES-CM Test Vectors section. This would avoid any endianess issue. Regards Laurent PILATI Tel. + 33 (0) 4 93 00 69 34 Design Center Mindspeed Technologies France David McGrew Sent by: owner-ietf-rtpsec@mail.imc.org 08/05/2006 18:17 To Paul Hoffman cc AVT , ietf-rtpsec@imc.org, saag@mit.edu Subject Re: [saag] The use of AES-192 and AES-256 in Secure RTP Paul, good points, I'm convinced that it would be better to dump AES-192 from the spec. David On May 8, 2006, at 9:12 AM, Paul Hoffman wrote: > At 12:15 PM -0700 5/4/06, David McGrew wrote: >> The main motivation for AES-192 and AES-256 is to provide >> alternative ciphers to AES-128 that can be adopted in event that >> unforeseen advances in cryptanalysis significantly erode the >> security level of >> AES-128. > > The downside of proposing multiple alternative ciphers, as compared > to just one, is that it is likely that implementers will not do > interop testing on all of them. It is much better to propose just > one fall-back cipher. This is particularly true for AES, as we have > discovered in the VPNC test lab. > > For IETF standards where AES-128 is a MUST-level requirement, there > should be just one fall-back, AES-256, with wording like the "SHOULD > +" definitions in RFC 4307. > > --Paul Hoffman, Director > --VPN Consortium --=_alternative 0053167AC1257173_= Content-Type: text/html; charset="us-ascii"
Hi all,

As a suggestion, would it be also possible to use SSRC and RTP sequence number different of  0000 for the AES-CM Test Vectors section.

This would avoid any endianess issue.

Regards

Laurent PILATI
Tel. + 33 (0) 4 93 00 69 34
Design Center
Mindspeed Technologies France


David McGrew <mcgrew@cisco.com>
Sent by: owner-ietf-rtpsec@mail.imc.org

08/05/2006 18:17

To
Paul Hoffman <paul.hoffman@vpnc.org>
cc AVT <avt@ietf.org>, ietf-rtpsec@imc.org, saag@mit.edu
Subject Re: [saag] The use of AES-192 and AES-256 in Secure RTP






Paul,

good points, I'm convinced that it would be better to dump AES-192  
from the spec.

David

On May 8, 2006, at 9:12 AM, Paul Hoffman wrote:

> At 12:15 PM -0700 5/4/06, David McGrew wrote:
>> The main motivation for AES-192 and AES-256 is to provide  
>> alternative ciphers to AES-128 that can be adopted in event that  
>> unforeseen advances in cryptanalysis significantly erode the  
>> security level of
>> AES-128.
>
> The downside of proposing multiple alternative ciphers, as compared  
> to just one, is that it is likely that implementers will not do  
> interop testing on all of them. It is much better to propose just  
> one fall-back cipher. This is particularly true for AES, as we have  
> discovered in the VPNC test lab.
>
> For IETF standards where AES-128 is a MUST-level requirement, there  
> should be just one fall-back, AES-256, with wording like the "SHOULD
> +" definitions in RFC 4307.
>
> --Paul Hoffman, Director
> --VPN Consortium

--=_alternative 0053167AC1257173_=-- From owner-ietf-rtpsec Mon May 22 14:58:24 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 k4MLwOIv068109; Mon, 22 May 2006 14:58:24 -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 k4MLwOCU068108; Mon, 22 May 2006 14:58:24 -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 k4MLwNRg068066 for ; Mon, 22 May 2006 14:58:23 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 22 May 2006 14:57:57 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208,217"; a="1810771702:sNHT3581789784" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4MLvvu3018351; Mon, 22 May 2006 14:57:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4MLvvB9008503; Mon, 22 May 2006 14:57:57 -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, 22 May 2006 14:57:56 -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, 22 May 2006 14:57:56 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/alternative; boundary=Apple-Mail-13-376666168 Message-Id: Cc: AVT , ietf-rtpsec@imc.org, owner-ietf-rtpsec@mail.imc.org, Paul Hoffman , saag@mit.edu From: David McGrew Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP Date: Mon, 22 May 2006 14:57:54 -0700 To: laurent.pilati@mindspeed.com X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 22 May 2006 21:57:56.0728 (UTC) FILETIME=[C88F1F80:01C67DEA] DKIM-Signature: a=rsa-sha1; q=dns; l=6138; t=1148335077; x=1149199077; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:David=20McGrew=20 |Subject:Re=3A=20[saag]=20The=20use=20of=20AES-192=20and=20AES-256=20in=20Secure= 20RTP; X=v=3Dcisco.com=3B=20h=3D1SRNnyOe4C6vJOekCLc6pGYvYYY=3D; b=Z78admRHovhcUyqeyRyB2eqnXnfvWx2qbu4VkZyY2Ow9/Uf9vgi+a6qWtbE3yLtre5+WZFqi 7PMAQJr7mLkXMoc2qh8n908BTcOKKNLiv2zrXmPk3P3/EAfKF2KJUwLl; Authentication-Results: sj-dkim-3.cisco.com; header.From=mcgrew@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-13-376666168 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Laurent, using an SSRC different from 0x0000 in (at least one of) the test vectors is a very good suggestion! David On May 19, 2006, at 8:07 AM, laurent.pilati@mindspeed.com wrote: > > Hi all, > > As a suggestion, would it be also possible to use SSRC and RTP > sequence number different of 0000 for the AES-CM Test Vectors > section. > > This would avoid any endianess issue. > > Regards > > Laurent PILATI > Tel. + 33 (0) 4 93 00 69 34 > Design Center > Mindspeed Technologies France > > > David McGrew > Sent by: owner-ietf-rtpsec@mail.imc.org > 08/05/2006 18:17 > > To > Paul Hoffman > cc AVT , ietf-rtpsec@imc.org, saag@mit.edu > Subject Re: [saag] The use of AES-192 and AES-256 in Secure RTP > > > > > > > Paul, > > good points, I'm convinced that it would be better to dump AES-192 > from the spec. > > David > > On May 8, 2006, at 9:12 AM, Paul Hoffman wrote: > > > At 12:15 PM -0700 5/4/06, David McGrew wrote: > >> The main motivation for AES-192 and AES-256 is to provide > >> alternative ciphers to AES-128 that can be adopted in event that > >> unforeseen advances in cryptanalysis significantly erode the > >> security level of > >> AES-128. > > > > The downside of proposing multiple alternative ciphers, as compared > > to just one, is that it is likely that implementers will not do > > interop testing on all of them. It is much better to propose just > > one fall-back cipher. This is particularly true for AES, as we have > > discovered in the VPNC test lab. > > > > For IETF standards where AES-128 is a MUST-level requirement, there > > should be just one fall-back, AES-256, with wording like the "SHOULD > > +" definitions in RFC 4307. > > > > --Paul Hoffman, Director > > --VPN Consortium > > > > --Apple-Mail-13-376666168 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Laurent,

using an SSRC different = from 0x0000 in (at least one of) the test vectors is a very good = suggestion!

David

On May 19, 2006, at 8:07 AM, laurent.pilati@mindspeed.com<= /A> wrote:


Hi all, =

As a suggestion, would it = be also possible to use SSRC and RTP sequence number different of =A00000 = for the AES-CM Test Vectors section.

This would avoid any endianess issue.
=
Regards

Laurent = PILATI
Tel. + 33 (0) 4 93 00 69 34
Design Center
Mindspeed = Technologies France


=
David McGrew <mcgrew@cisco.com> =
Sent by: owner-ietf-rtpsec@mail.imc.= org

08/05/2006 = 18:17

=
To
Paul Hoffman <paul.hoffman@vpnc.org>=
cc AVT <avt@ietf.org>, ietf-rtpsec@imc.org, saag@mit.edu
=
Subject Re: [saag] The use of AES-192 and AES-256 in Secure = RTP

=




Paul,

good points, I'm convinced that = it would be better to dump AES-192 =A0
from the spec.

= David

On May 8, 2006, at 9:12 AM, Paul Hoffman wrote:

= > At 12:15 PM -0700 5/4/06, David McGrew wrote:
>> The main = motivation for AES-192 and AES-256 is to provide =A0
>> = alternative ciphers to AES-128 that can be adopted in event that =A0
= >> unforeseen advances in cryptanalysis significantly erode the = =A0
>> security level of
>> AES-128.
>
= > The downside of proposing multiple alternative ciphers, as compared = =A0
> to just one, is that it is likely that implementers will = not do =A0
> interop testing on all of them. It is much better to = propose just =A0
> one fall-back cipher. This is particularly = true for AES, as we have =A0
> discovered in the VPNC test = lab.
>
> For IETF standards where AES-128 is a MUST-level = requirement, there =A0
> should be just one fall-back, AES-256, = with wording like the "SHOULD
> +" definitions in RFC = 4307.
>
> = --Paul Hoffman, Director
> --VPN Consortium


 =


= --Apple-Mail-13-376666168-- From owner-ietf-rtpsec Fri May 26 16:11: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 k4QNBsaq037334; Fri, 26 May 2006 16:11: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 k4QNBsWg037333; Fri, 26 May 2006 16:11: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 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 k4QNBsSm037276 for ; Fri, 26 May 2006 16:11:54 -0700 (MST) (envelope-from dwing@cisco.com) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 26 May 2006 16:11:49 -0700 X-IronPort-AV: i="4.05,178,1146466800"; d="scan'208"; a="1813812439:sNHT31547560" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k4QNBmV4030368 for ; Fri, 26 May 2006 16:11:48 -0700 Received: from dwingwxp (sjc-vpn1-386.cisco.com [10.21.97.130]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4QNBmJj010571 for ; Fri, 26 May 2006 16:11:48 -0700 (PDT) From: "Dan Wing" To: "ietf-rtpsec" Subject: Evaluation of SRTP Keying with SIP Date: Fri, 26 May 2006 16:11:48 -0700 Message-ID: <017b01c68119$c3c9ddf0$8261150a@amer.cisco.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: AcaANSiiomG3pt9tR1C2Nlo7QhcneQA3Sg3A DKIM-Signature: a=rsa-sha1; q=dns; l=2896; t=1148685108; x=1149549108; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:Evaluation=20of=20SRTP=20Keying=20with=20SIP; X=v=3Dcisco.com=3B=20h=3DlF+qbnzdPcLoqKSYdch54ZM9d9M=3D; b=dTUULdEADzfbxLKTSLvoccx1eu9EUL4dwBkLdBajvBDDB4XEpQo3+PyJ39aWJ8huX8Sd+Din oQQhH109UxDyWZqL1GfCU3YDqup7Y7aTFYWSpA9/sX2eKkE43ROiEnAf; Authentication-Results: sj-dkim-6.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Francois and I wrote an I-D which compares all of the current keying mechanisms in several areas. Much of the content is similar to my RAI presentation, but about half is new. (The name of this draft may change to draft-wing-rtpsec-keying-eval shortly; my mistake.) -d > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, May 25, 2006 12:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-wing-srtp-keying-eval-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Evaluation of SRTP Keying with SIP > Author(s) : F. Audet, D. Wing > Filename : draft-wing-srtp-keying-eval-00.txt > Pages : 32 > Date : 2006-5-25 > > Over a dozen incompatible mechanisms have been defined to key an > Secure RTP (SRTP) media stream. This document evaluates the keying > mechanisms, concentrating on their interaction with SIP > features and > their security properties. > > This document is discussed on the rtpsec mailing list, > . > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wing-srtp-keying-eval-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-wing-srtp-keying-eval-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-wing-srtp-keying-eval-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-ietf-rtpsec Tue Jun 6 09:32: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 k56GWjv2075075; Tue, 6 Jun 2006 09:32: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 k56GWjLD075074; Tue, 6 Jun 2006 09:32: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 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 k56GWi2F075039 for ; Tue, 6 Jun 2006 09:32:44 -0700 (MST) (envelope-from mcgrew@cisco.com) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2006 09:32:39 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208"; a="289778512:sNHT38425866" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k56GWcO8022104; Tue, 6 Jun 2006 09:32:38 -0700 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 k56GWcIu026614; Tue, 6 Jun 2006 09:32:38 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 09:32:36 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 09:32:35 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B8C6B87-AD58-4F08-A342-D98378EAF535@cisco.com> Cc: ietf-rtpsec@imc.org, AVT Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: KM approach using MIKEY and EKT Date: Tue, 6 Jun 2006 09:32:33 -0700 To: "Fries, Steffen" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 06 Jun 2006 16:32:35.0528 (UTC) FILETIME=[D136A480:01C68986] DKIM-Signature: a=rsa-sha1; q=dns; l=7675; t=1149611558; x=1150475558; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:David=20McGrew=20 |Subject:Re=3A=20KM=20approach=20using=20MIKEY=20and=20EKT; X=v=3Dcisco.com=3B=20h=3DFnZgQcNd4L1HflVUOW9NMmbIPrs=3D; b=q6wykBlU6ldOGDRhSr+H0335Pbvh5M86rEB5NIH8zyiZPU6yFRxZDQrmVoFQ9eHWyO6SXudU QO11wurb2NMv86cKeTWXPNNNjfqd2YPxEbC2wyyIt3ZXoigXG1UF3oQf; Authentication-Results: sj-dkim-7.cisco.com; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Steffen, I think that I understand the problems that you're solving, and the hybrid approach (with the first KM message going over signaling, and the second over the media) that you're describing would work, but EKT is not very suitable for transporting another protocol. Currently, the EKT payloads are defined in terms of the participant's SRTP context, and there is a very simple protocol state machine (if an EKT message authenticates properly, then the SRTP master key that it conveys should be stored so that it can be used to process subsequent SRTP messages). This method is simple, and results in EKT fields that have small, fixed sizes. The constant size of the fields enable the SRTCP implementation to accommodate the additional fields into the RTCP bandwidth calculations. To use EKT to convey messages for an arbitrary key management protocol would add a good amount of complexity to it. The KM protocol state machine, complete with retransmissions, would become a factor. It would also add the complication that the (S)RTCP packet sizes would vary, which would change the bandwidth allocation for SRTCP. Also, adding support for a public-key method inside of EKT could make the RTCP packets quite large, which in some cases would interfere with normal RTP/RTCP operation. Another point is that EKT as defined works for point-to-multipoint cases, while the MIKEY-over-EKT would be restricted to point-to- point. This is important because EKT relies on SSRCs to identify sources, while SSRCs are most likely not sufficient to identify sources for MIKEY. (Consider the SIP forking scenario; the offerer needs to track the MIKEY responders by their source addresses. How could we implement this without making EKT 'know' about source addresses?) All that said, I think that it is actually possible to do what you're describing with EKT as defined by the current draft, by defining a new "EKT Cipher" that is in actuality an interface to a key management protocol. (This might be abusing the intent of the specification, but the draft was written to be general so it looks like it conforms to the letter of the specification.) From Section 2.3.3: An EKT cipher determines how the Encrypted Master Key field is written, and how it is processed when it is read. This field is opaque to the other aspects of EKT processing. EKT ciphers are free to use this field in any way, but they SHOULD NOT use other EKT or SRTP fields as an input. The values of the parameters L, M, N, and T MUST be defined by each EKT cipher, and those values MUST be inferable from the EKT parameter set. To transport an arbitrary key management protocol, you would need to define an "EKT Cipher" that had a variable-length payload, and which contained a field that described its length. I am not sure how the RTCP bandwidth computations would be done; perhaps there would need to be an interface between the EKT Cipher and the RTCP implementation that would notify RTCP about the different payload sizes (so that RTCP could start sending more packets once the key negotiation is over). Please understand that I'm *not* recommending using EKT as a general-purpose transport here; I just want to point out that there is some flexibility in the definitions that might be useful. The STUN approach to multiplexing additional protocols over the RTP ports (as used in DTLS-SRTP, see Section 3.6.2 of http:// scm.sipfoundry.org/rep/ietf-drafts/ekr/draft-mcgrew-dtls-srtp.html) provides better separation between the additional key management protocol and the RTP implementation. I think that it is preferable over using EKT as a general-purpose transport for a key management protocol. It could be used with a key management protocol that uses a 'hybrid' signaling/media approach to transporting its packets. As an aside, I'm not convinced that a hybrid approach is the best way to go. Some coordination between signaling and the key management protocol is needed, of course, but I suspect that it is best to minimize the burden that we put on the signaling plane and the properties that we expect from it. Lastly, I should mention that I'd like to have EKT become a WG item in AVT, and if the WG thinks that EKT should be able to convey an arbitrary key management protocol, I'd be OK with that. However, I suspect that the reverse is true, and that the WG would prefer to keep EKT simple (and keep EKT field sizes fixed). (I've added the AVT email list to the CC line to solicit comments.) David P. S. - Sorry to take so long to respond. The problem is complex enough that there are no simple answers :-) On May 15, 2006, at 1:08 AM, Fries, Steffen wrote: > Hi David, > > based on the discussion we had during the last IETF meeting and the > requirements discussed on the list here I would like to share some > ideas regarding the interworking of EKT and MIKEY. The current EKT > document does not talk about the cooperation of both in specific. > It rather mentions the usage of MIKEY to establish the EKT key, > cipher and SPI values in section 4. > > Combining EKT with MIKEY would be advanterous for the MIKEY modes > needing a full roundtrip. What I have in mind are specifically the DH > approaches but also the rsa-r method could gain from it. Here the > following may be supported with EKT, keeping in mind that early media > and forking are the important issues. A is sending an INVITE to > B including the MIKEY I_message containing a signed DH half key as > well as a new payload indicating the use of EKT. Upon reciving this > INVITE B can use his DH half key and can calculate the DH secret, > derive the SRTP master key for the connection to A. B's DH half key > can now be fed into EKT and send over to A via SRTCP (or even SRTP, > if EKT is going to support it). Upon receiving the DH half key A can > also calculate the DH secret and start to decrypt the received SRTP > stream. B sends the MIKEY_R message also in the signaling back to A. > Upon receiving this message A is in a position to verify, that he got > the same DH half key via EKT as he received in MIKEY. This is to > provide A with the assurance that nobody performs a MitM attack on > the media path. EKT requires a shared key to protect the key > distribution, > which is not in place here. One may use a signed DH to cope with this > or, when using an unsigned DH, start with SRTP based on the received > parameter and get a delayed, authenticated DH, via the signaling. > > This approach would solve both the early media and the forking. > Early media is ensured, as EKT is transported directly to B inside > SRTCP (or even inside SRTP, if this is going to be defined). Moreover > the forking is eased as now, security precondition may not be needed > and thus the provisional responses connected with the security > preconditions do not need to be sent. > > Problems I see here are the following: > - The caller gets the assurance about the quality of the security when > receiving the 200 OK. Before that he cannot be sure regarding a > MitM. > - Fragmentation. As signed DH messages or asymmetric encrypted > messages > are rather large, the common path MTU boundary may be crossed. > Therfore > the approach with the unsigned DH above. > > What's your opinion to that approach? Would that be something to > include in the EKT ID when it is updated? > > Regards > Steffen From owner-ietf-rtpsec Fri Jun 9 08:55: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 k59FtudY043632; Fri, 9 Jun 2006 08:55:56 -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 k59FtuvI043630; Fri, 9 Jun 2006 08:55:56 -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 gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k59Fts7U043605 for ; Fri, 9 Jun 2006 08:55:55 -0700 (MST) (envelope-from steffen.fries@siemens.com) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k59Ftl07002351; Fri, 9 Jun 2006 17:55:47 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k59Ftkw0027685; Fri, 9 Jun 2006 17:55:47 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 17:55:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: KM approach using MIKEY and EKT Date: Fri, 9 Jun 2006 17:55:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KM approach using MIKEY and EKT thread-index: AcaJhulHOE9cPwFaSDSHBXKzFlMs9wCKmAwA From: "Fries, Steffen" To: "David McGrew" Cc: , "AVT" X-OriginalArrivalTime: 09 Jun 2006 15:55:46.0542 (UTC) FILETIME=[2BCB60E0:01C68BDD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k59Ftt7U043625 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi David, thanks for your explanation. I understand that enhancing EKT with this would make it more complex. By thinking more about my initial approach I think we could even use plain RTP with the appropriate payload type to send the DH parameter (I have to check that), without using EKT also gaining a secure media path. For the phase from receiving the DH half key of the callee till receiving the final MIKEY response, there is only the chance for the callee to provide audio. As long as the SIP response is not received at the caller, he cannot provide the media as he does not have a target port to send to. Thus the security decrease by using an unauthenticated DH half key for a limited time should not be high. Regards Steffen > -----Original Message----- > From: David McGrew [mailto:mcgrew@cisco.com] > Sent: Tuesday, June 06, 2006 6:33 PM > To: Fries, Steffen > Cc: ietf-rtpsec@imc.org; AVT > Subject: Re: KM approach using MIKEY and EKT > > Hi Steffen, > > I think that I understand the problems that you're solving, > and the hybrid approach (with the first KM message going over > signaling, and the second over the media) that you're > describing would work, but EKT is not very suitable for > transporting another protocol. Currently, the EKT payloads > are defined in terms of the participant's SRTP context, and > there is a very simple protocol state machine (if an EKT > message authenticates properly, then the SRTP master key that > it conveys should be stored so that it can be used to process > subsequent SRTP messages). This method is simple, and > results in EKT fields > that have small, fixed sizes. The constant size of the fields > enable the SRTCP implementation to accommodate the additional > fields into the RTCP bandwidth calculations. > > To use EKT to convey messages for an arbitrary key management > protocol would add a good amount of complexity to it. The KM > protocol state machine, complete with retransmissions, would > become a factor. It would also add the complication that the > (S)RTCP packet sizes would vary, which would change the > bandwidth allocation for SRTCP. Also, adding support for a > public-key method inside of EKT could make the RTCP packets > quite large, which in some cases would interfere with normal > RTP/RTCP operation. > > Another point is that EKT as defined works for > point-to-multipoint cases, while the MIKEY-over-EKT would be > restricted to point-to- point. This is important because EKT > relies on SSRCs to identify sources, while SSRCs are most > likely not sufficient to identify sources for MIKEY. > (Consider the SIP forking scenario; the offerer needs to > track the MIKEY responders by their source addresses. How > could we implement this without making EKT 'know' about source > addresses?) > > All that said, I think that it is actually possible to do > what you're describing with EKT as defined by the current > draft, by defining a new "EKT Cipher" that is in actuality an > interface to a key management protocol. (This might be > abusing the intent of the specification, but the draft was > written to be general so it looks like it conforms to the > letter of the specification.) From Section > 2.3.3: > > An EKT cipher determines how the Encrypted Master Key field is > written, and how it is processed when it is read. This field is > opaque to the other aspects of EKT processing. EKT > ciphers are free > to use this field in any way, but they SHOULD NOT use other EKT or > SRTP fields as an input. The values of the parameters L, > M, N, and T > MUST be defined by each EKT cipher, and those values MUST be > inferable from the EKT parameter set. > > To transport an arbitrary key management protocol, you would > need to define an "EKT Cipher" that had a variable-length > payload, and which contained a field that described its > length. I am not sure how the RTCP bandwidth computations > would be done; perhaps there would need to be an interface > between the EKT Cipher and the RTCP implementation that would > notify RTCP about the different payload sizes (so that RTCP > could start sending more packets once the key negotiation is > over). Please understand that I'm *not* recommending using > EKT as a general-purpose transport here; I just want to point > out that there is some flexibility in the definitions that > might be useful. > > The STUN approach to multiplexing additional protocols over > the RTP ports (as used in DTLS-SRTP, see Section 3.6.2 of http:// > scm.sipfoundry.org/rep/ietf-drafts/ekr/draft-mcgrew-dtls-srtp.html) > provides better separation between the additional key > management protocol and the RTP implementation. I think that > it is preferable over using EKT as a general-purpose > transport for a key management protocol. It could be used > with a key management protocol that uses a 'hybrid' > signaling/media approach to transporting its packets. As an > aside, I'm not convinced that a hybrid approach is the best > way to go. Some coordination between signaling and the key > management protocol is needed, of course, but I suspect that > it is best to minimize the burden that we put on the > signaling plane and the properties that we expect from it. > > Lastly, I should mention that I'd like to have EKT become a > WG item in AVT, and if the WG thinks that EKT should be able > to convey an arbitrary key management protocol, I'd be OK > with that. However, I suspect that the reverse is true, and > that the WG would prefer to keep EKT simple (and keep EKT > field sizes fixed). (I've added the AVT email list to the CC > line to solicit comments.) > > David > > P. S. - Sorry to take so long to respond. The problem is > complex enough that there are no simple answers :-) > > On May 15, 2006, at 1:08 AM, Fries, Steffen wrote: > > > Hi David, > > > > based on the discussion we had during the last IETF meeting and the > > requirements discussed on the list here I would like to share some > > ideas regarding the interworking of EKT and MIKEY. The current EKT > > document does not talk about the cooperation of both in specific. > > It rather mentions the usage of MIKEY to establish the EKT > key, cipher > > and SPI values in section 4. > > > > Combining EKT with MIKEY would be advanterous for the MIKEY modes > > needing a full roundtrip. What I have in mind are > specifically the DH > > approaches but also the rsa-r method could gain from it. Here the > > following may be supported with EKT, keeping in mind that > early media > > and forking are the important issues. A is sending an INVITE to B > > including the MIKEY I_message containing a signed DH half > key as well > > as a new payload indicating the use of EKT. Upon reciving > this INVITE > > B can use his DH half key and can calculate the DH secret, > derive the > > SRTP master key for the connection to A. B's DH half key can now be > > fed into EKT and send over to A via SRTCP (or even SRTP, if EKT is > > going to support it). Upon receiving the DH half key A can also > > calculate the DH secret and start to decrypt the received > SRTP stream. > > B sends the MIKEY_R message also in the signaling back to A. > > Upon receiving this message A is in a position to verify, > that he got > > the same DH half key via EKT as he received in MIKEY. This is to > > provide A with the assurance that nobody performs a MitM > attack on the > > media path. EKT requires a shared key to protect the key > distribution, > > which is not in place here. One may use a signed DH to cope > with this > > or, when using an unsigned DH, start with SRTP based on the > received > > parameter and get a delayed, authenticated DH, via the signaling. > > > > This approach would solve both the early media and the forking. > > Early media is ensured, as EKT is transported directly to B inside > > SRTCP (or even inside SRTP, if this is going to be > defined). Moreover > > the forking is eased as now, security precondition may not > be needed > > and thus the provisional responses connected with the security > > preconditions do not need to be sent. > > > > Problems I see here are the following: > > - The caller gets the assurance about the quality of the > security when > > receiving the 200 OK. Before that he cannot be sure regarding a > > MitM. > > - Fragmentation. As signed DH messages or asymmetric encrypted > > messages > > are rather large, the common path MTU boundary may be crossed. > > Therfore > > the approach with the unsigned DH above. > > > > What's your opinion to that approach? Would that be something to > > include in the EKT ID when it is updated? > > > > Regards > > Steffen > From owner-ietf-rtpsec Mon Jun 12 01:13: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 k5C8DUkw097440; Mon, 12 Jun 2006 01:13:30 -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 k5C8DU3W097437; Mon, 12 Jun 2006 01:13:30 -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 k5C8DTrT097406 for ; Mon, 12 Jun 2006 01:13:29 -0700 (MST) (envelope-from csp@csperkins.org) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:53673) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FphY2-0001SL-1S; Mon, 12 Jun 2006 09:13:22 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "David McGrew" , ietf-rtpsec@imc.org, AVT Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] RE: KM approach using MIKEY and EKT Date: Sun, 11 Jun 2006 11:48:56 +0100 To: "Fries, Steffen" X-Mailer: Apple Mail (2.750) Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steffen, On 9 Jun 2006, at 16:55, Fries, Steffen wrote: > thanks for your explanation. I understand that enhancing EKT with this > would make it more complex. By thinking more about my initial > approach I > think we could even use plain RTP with the appropriate payload type to > send the DH parameter (I have to check that), ... I would strongly recommend against that. We have an RTP control protocol to avoid putting control into RTP data packet. Either use it -- which would be my preferred approach -- or multiplex a separate protocol onto the RTP port (as done with ICE). Colin From owner-ietf-rtpsec Mon Jun 12 04:34:20 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 k5CBYJDL099776; Mon, 12 Jun 2006 04:34:19 -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 k5CBYJ2r099775; Mon, 12 Jun 2006 04:34:19 -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 gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5CBYInh099752 for ; Mon, 12 Jun 2006 04:34:18 -0700 (MST) (envelope-from steffen.fries@siemens.com) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5CBYAa7003994; Mon, 12 Jun 2006 13:34:10 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k5CBY9bc025445; Mon, 12 Jun 2006 13:34:09 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 13:34:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [AVT] RE: KM approach using MIKEY and EKT Date: Mon, 12 Jun 2006 13:34:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RE: KM approach using MIKEY and EKT thread-index: AcaN+OLM837OZoA8TeuvGnixyYhtJwAGrT8w From: "Fries, Steffen" To: "Colin Perkins" Cc: "David McGrew" , , "AVT" X-OriginalArrivalTime: 12 Jun 2006 11:34:09.0626 (UTC) FILETIME=[1EF153A0:01C68E14] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k5CBYJnh099764 Sender: owner-ietf-rtpsec@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Colin, well, the approach is merely independent of RTP or RTCP. I thought RTP may be more suitable as RTCP is not mandatory and requires opening an additional port in intermediate devices. But you are right, RTCP may be a better place. My first concern was to see if the security properties of this approach would be acceptable. Regards Steffen > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Sunday, June 11, 2006 12:49 PM > To: Fries, Steffen > Cc: David McGrew; ietf-rtpsec@imc.org; AVT > Subject: Re: [AVT] RE: KM approach using MIKEY and EKT > > Steffen, > > On 9 Jun 2006, at 16:55, Fries, Steffen wrote: > > thanks for your explanation. I understand that enhancing > EKT with this > > would make it more complex. By thinking more about my > initial approach > > I think we could even use plain RTP with the appropriate > payload type > > to send the DH parameter (I have to check that), > ... > > I would strongly recommend against that. We have an RTP control > protocol to avoid putting control into RTP data packet. > Either use it > -- which would be my preferred approach -- or multiplex a separate > protocol onto the RTP port (as done with ICE). > > Colin > From owner-ietf-rtpsec Mon Jun 12 07:27: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 k5CERUZp011270; Mon, 12 Jun 2006 07:27:30 -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 k5CERUL7011269; Mon, 12 Jun 2006 07:27:30 -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-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5CERTaG011191 for ; Mon, 12 Jun 2006