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

[Mark Baugher <[e-mail]>]

hi David
   I think you should remove reference to SRTP and send this I-D on its way 
rather than hold it and the SRTP I-D up while we analyze the security 
considerations of AVPF.  If someone needs SRTP for AVPF, then they can take 
the lead to do this specification.  If there is no interest in secure AVPF, 
then no effort needs to be wasted on it.

thanks, Mark
At 04:29 PM 1/23/2003 -0600, [e-mail] wrote:


>Hi Mark,
>
>Thanks for the feedback. Please see answers below.
>
> > hi Jose,
> >    I think that you cannot mention SRTP in this draft because
> > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retrans
> > mission-04.txt
> > uses the
> > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedba
> > ck-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. "
>
>Yes. We are aware that this has to be defined somewhere. This is what Jose 
>meant in point 3 of his mail.
>
> >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?
>
>
> >
> > 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.
>
>What is actually required in order to adapt SRTP for retransmission and 
>AVPF? I think SRTP could be used as it is to encrypt the retransmission 
>packets. As far as SRTCP is concerned, does it need any modifications in 
>order to be able to encrypt the new ACKs and NACKs packets?
>
>Thanks, David.
>
>
> >
> > As
> > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedba
> > ck-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: [e-mail] [mailto:[e-mail]]On
> > Behalf Of Colin
> > > > Perkins
> > > > Sent: Friday, January 10, 2003 4:39 AM
> > > > To: [e-mail]
> > > > Cc: [e-mail]
> > > > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/avt
> >

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