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

[Jose Rey <[e-mail]>]

Hi Elisabetta,

thanks for your review. See my comments in-line.

>
> Hi!
> we gave a look at the draft, we have only few remarks.
>
> It seems that applying SRTP should be quite straight (however,
> we have not read AVPF).
>
> - there is the two time pad issue for the
> session-multiplexing (as the SSRC
> 	must be the same): the two flows MUST use different master keys
>
> - there is no problem in the SSRC-multiplexing case (as the
> SSRC must be
> 	different), i.e. it is possible to use the same master key or
> 	different ones.
> 	However, the issue is with RTCP, that we understand
> joint. You can
> 	have several alternatives there on how to use the keys,
> up to you
> 	to decide. The simplest is to share the master key
> between the 3
> 	flows (original RTP, retx, RTCP).
OK.

>
> - what should be encrypted by SRTP? SRTP encrypts *the RTP payload*.
> 	Now, we only read certain parts of the draft, but it
> was not clear
> 	if saying *RTP payload* includes also the OSN field.
> 	If it is clear to you, forget the comment.
>

Saying 'RTP payload' for the retransmission packet also includes the
OSN, as this is defined as part of the retransmission payload format for
RTP. Thus the OSN would be encrypted without further changes in SRTP.

> - there should be no problem for the new ACK and NACK
> messages, as they
> 	are placed after a Sender Report or Receiver Report

The initial question (3 in my first mail) is actually answered by this
statement :)


>
> As for the profile issue, we would leave it to the chairmen.

As Colin said, it seems that another document is the right place to do
it.


thanks,

José

>
> Cheers
> /E et al
>
>
>
> >
> > > >>  - 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt

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