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

From: Jose Rey <[email-masked]>
Date: Thu, 23 Jan 2003 17:35:00 +0100

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: [email-masked] [mailto:[email-masked]]On Behalf Of Colin
> Perkins
> Sent: Friday, January 10, 2003 4:39 AM
> To: [email-masked]
> Cc: [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Mark Baugher <[email-masked]>
Date: Thu, 23 Jan 2003 12:46:01 -0800

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