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

From: "David A. Mcgrew" <[email-masked]>
Date: Thu, 6 Feb 2003 07:52:45 -0800

José,

> -----Original Message-----
> From: Jose Rey [mailto:[email-masked]]
> Sent: Thursday, January 23, 2003 8:35 AM
> To: Avt@Ietf. Org
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Security for draft-ietf-avt-rtp-retransmission
>
>
> 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?

I think so.  Certainly if the retransmission packets are treated as a separate
session or separate stream with its own set of SRTP keys, then there's no
problem.  The only potential issue that I see is that the SRTP protection for
the retransmission data will need to get keys (and other parameters) somehow.
Is the plan to signal the retransmission session/stream at the same time as the
original stream, but then only use it if it is needed?  In that case, I'd expect
that all the SRTP info for both streams/sessions would be provided by the
signaling, which seems like it would work well.

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

The SRTP draft is in IESG review, so at this point it wouldn't be appropriate to
drag it back.  But if the new profile is uncomplicated, it shouldn't be hard to
throw together a new draft that references AVPF and SRTP to make SAVPF.  Could
you point me in the right direction as to what differences between AVP and AVPF
would be important w.r.t. SRTP?

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

The draft says that "Applications utilising encryption SHOULD encrypt both the
original    and the retransmission stream."   IIUC, it might be better to state
that "If cryptography is used to provide security services on the original
stream, then the same services, with equivalent cryptographic strength, SHOULD
be provided on the retransmission stream."  Also, I'm wondering why you would
want a SHOULD and not a MUST here!

Correct me if I'm wrong, but here's my mental picture of how the combined
srtp/retransmission system would work:

sender side
-----------

original rtp source -+------------------> srtp encrypter (key1) ---> ...
                     |
                     +-> rexmit buffer -> srtp encrypter (key2) ---> ...

Another approach would be to move the retransmission buffer to the other side of
the srtp encrypter, and get rid of key2.  This would be workable, since the
original sequence number is provided in the retransmitted packet.  However, this
scheme would not provide message authentication on the retransmission packet
flow.  Another demerit of this scheme is that it would interact badly with the
SRTP anti-replay window; the recommended size for this window is 128, and this
scheme might require an even larger one.  So I like the first method (the way I
think that you're doing it) better!

At any rate, it might be good to describe how you want the retransmission
mechanism to work with SRTP or other crypto mechanisms, to avoid confusion down
the road.

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

I think that the non-randomness of the initial timestamp of the retransmission
stream is not an issue.  The unpredictability of the initial RTP timestamp makes
a DoS attack more difficult for an attacker who is not able to observe the RTP
flow, but who knows the destination address, destination port number, and SSRC
of that flow.  The same argument could be made for the avt-rtp-retranmission
mechanism.  If the attacker can't see the original flow, she can't predict the
initial timestamp of the retransmission flow.  If she can see the original flow,
then there is no protection provided by having random timestamp on either flow.
So there is no disadvantage to the avt-rtp-retransmission mechanism's re-use of
the initial timestamp.

David

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

Or maybe a subtle identity theft? :-)

David

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Jose Rey <[email-masked]>
Date: Mon, 17 Feb 2003 16:41:29 +0100

David,

thanks for your comments, please see inline.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of David
> A. Mcgrew
> Sent: Thursday, February 06, 2003 4:53 PM
> To: Jose Rey; Avt@Ietf. Org
> [email-masked]; [email-masked];
> [email-masked]
> Subject: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission
>
>
> José,
>
> problem.

Fine.

>  The only potential issue that I see is that the
> SRTP protection for

This is also my understanding.

> drag it back.

Yes, I understand.

> But if the new profile is uncomplicated, it
> shouldn't be hard to

AVPF introduces new feedback messages ACKs/NACKs and application layer
messages which, as concluded above, don't represent any problem for
SRTP. This is because the RTCP packets used by AVPF-compliant entities
also use the "recommended" RTCP packet format as in RTP, thus not being
a problem (see point 2 above).

The other major change is that the AVPF profile abolishes the 5-second
rule; this shouldn't be a problem for SRTP either (?)
> want a SHOULD and not a MUST here!

Right, thanks for the rewording. I like a MUST instead better.

> srtp/retransmission system would work:

The 1st possibility as depicted by you is the one we have in mind. Your
other "option" could be given as an example of what not to do and why.
This would  rule out possible questions.

> So there is no disadvantage to the avt-rtp-retransmission
OK.

Now, I got a question:

as discussed in previous emails (see the email from Elisabetta), in the
case of SSRC-multiplexing the same master key might be used for both
streams since the SSRC is unique among the streams.

In the original packets the SN  is sent in the header, thus accessible.
However in the retransmission packets, the retransmission payload header
(the two bytes containing the original SN, OSN) is sent encrypted and
its location is known: right after the RTP header before the payload.
Since both original and retransmission packets have the same TS, an
attacker could easily identify an original packet and its retransmission
by comparing the TS. Once this is done he could easily see how the
cleartext SN is encrypted. Now, I am not a security expert but,
intuitively, this is not secure. Is it not a security threat? Does SRTP
solve this?

thanks,

José