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

[Colin Perkins <[e-mail]>]

Seems reasonable...
Colin


--> Mark Baugher writes:
>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
_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt