[AVT] Re: Security for draft-ietf-avt-rtp-retransmission

Mark Baugher <mbaugher@cisco.com> Thu, 23 January 2003 20:46 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19634 for <avt-archive@odin.ietf.org>; Thu, 23 Jan 2003 15:46:05 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NL4kI24318 for avt-archive@odin.ietf.org; Thu, 23 Jan 2003 16:04:46 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NL2wJ24260; Thu, 23 Jan 2003 16:02:58 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NL1mJ24223 for <avt@optimus.ietf.org>; Thu, 23 Jan 2003 16:01:48 -0500
Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19600 for <avt@ietf.org>; Thu, 23 Jan 2003 15:42:36 -0500 (EST)
Received: from cscoamera13263.cisco.com ([10.21.83.71]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h0NKjxB7004232; Thu, 23 Jan 2003 12:46:00 -0800 (PST)
Message-Id: <5.1.1.5.2.20030123123828.09df0cb8@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Thu, 23 Jan 2003 12:46:01 -0800
To: Jose Rey <rey@panasonic.de>
From: Mark Baugher <mbaugher@cisco.com>
Cc: "Avt@Ietf. Org" <avt@ietf.org>
In-Reply-To: <NGBBJIBNJOKHDHFKEOMHEECOEIAA.rey@panasonic.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0NL1mJ24224
Subject: [AVT] Re: Security for draft-ietf-avt-rtp-retransmission
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

hi Jose,
   I think that you cannot mention SRTP in this draft because 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-04.txt 
uses the 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedback-04.txt, 
which states in its security considerations section
"Attacks using false RTCP packets (regular as well as early ones) can be 
avoided by authenticating all RTCP messages. This can be achieved by using 
the AVPF profile together with the Secure RTP profile as defined in [17]; 
as a prerequisite, an appropriate combination of those two profiles (an 
"SAVPF") needs to be specified. "

This is because SRTP is nowhere defined for AVPF.  It may be a small 
problem to adapt SRTP to your RTP profile, but this needs to be done 
because we only had RTP's AVP in mind when doing SAVP.

As http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedback-04.txt 
states, something needs to be specified.

best regards, Mark

At 05:35 PM 1/23/2003 +0100, Jose Rey wrote:
>Hi all,
>
>we are doing the final edits to the draft-ietf-avt-rtp-retransmission.
>We have considered all your comments until the date, but there's
>something for which we would like to get some feedback on: security.
>
>A couple of questions:
>
>1.-As discussed on the list:
>...
> > -----Original Message-----
> > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin
> > Perkins
> > Sent: Friday, January 10, 2003 4:39 AM
> > To: David.Leon@nokia.com
> > Cc: avt@ietf.org
> > Subject: Re: [AVT] Comments on
> > draft-ietf-avt-rtp-retransmission-04.txt
> >
>...snip...
>
> > >>  - In section 12, how does this draft affect SRTP? Is it
> > possible to use
> > >>    the two formats together?
> > >
> > >We'll try to draft something on that. My understanding is that the
> > >retransmission stream is seen as any other stream by SRTP
> > and there should
> > >thus be no problem.
> >
> > I was not clear if retransmitting packets caused problems for
> > SRTP; maybe
> > one of the SRTP authors can comment on any potential security issue?
> >
>
>we don't see any problems (except for SRTCP as below in 2) to use SRTP
>with RTX since the RTP retransmission packets (with a two byte
>retransmission payload header) are seen by SRTP as 'normal' RTP packets.
>Is our assumption correct?
>
>2.-The retransmission payload format needs of the AVPF profile to enable
>more frequent feedback and to request packets. This profile defines
>(besides the new timing rules) some general-purpose messages such as
>ACKs and NACKs and a new RTCP packet format: the early feedback packet,
>which just contains 1 SR or RR and 1 SDES with just the CNAME. Now,
>there should be no problem to encrypt/authenticate early packets,
>according to the SRTP draft:
>
>"
>    According to [RFC1889] there is a "recommended" packet format for
>    compound packets. SRTCP MUST be given packets according to that
>    recommendation in the sense that the first part MUST be a sender
>    report or a receiver report. However, the encryption prefix (Section
>    6.1 of [RFC1889]), a random 32-bit quantity intended to deter known
>    plaintext attacks, MUST NOT be used (see below).
>"
>
>
>Also there should be no problem to authenticate/encrypt ACKs and NACKs
>with SRTCP since they are sent in compound RTCP packets starting with an
>RR or SR packet. Let us know if you disagree with this point.
>
>
>3.- if a new profile needs be defined, something like "SAVPF", where
>shall this profile "SAVPF" be specified and registered? wouldn't it be
>reasonable to do this in the SRTP draft which already registers the
>"SAVP" profile given that the feedback draft would (presumably) have a
>similar schedule to the SRTP draft? In this way the question 2. could
>also be anwered there.
>
>4.- the security section in the retransmission draft already points out
>the risks of using the same keys across sessions, e.g. two.-time pads
>and points to the SRTP for solutions. That much is done. Are we missing
>something else?
>
>5.-It is also pointed out that the Timestamp of the retransmission
>packets is the same as in the original packets. Since this is random it
>should be no problem for security. Is this assumption correct?
>
>Thanks in advance,
>
>
>José
>
>
>PS: by the way, in draft-05 Rolf Blom's email is the same as Mark
>Baugher's. Probably a cut&paste error.

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt