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

["Elisabetta Carrara (EAB)" <[e-mail]>]

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

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

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

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

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