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

["David A. Mcgrew" <[e-mail]>]

Jose,

> -----Original Message-----
> From: Jose Rey [mailto:[e-mail]]
> Sent: Monday, February 17, 2003 7:41 AM
> To: David A. Mcgrew; Avt@Ietf. Org
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission
>
>
> David,
>
> thanks for your comments, please see inline.
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On Behalf Of David
> > A. Mcgrew
> > Sent: Thursday, February 06, 2003 4:53 PM
> > To: Jose Rey; Avt@Ietf. Org
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [e-mail];
> > [e-mail]
> > Subject: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission
> >
> >
> > José,
> >
> > > -----Original Message-----
> > > From: Jose Rey [mailto:[e-mail]]
> > > Sent: Thursday, January 23, 2003 8:35 AM
> > > To: Avt@Ietf. Org
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]
> > > 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: [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?
> >
> > 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.
>
> Fine.
>
> >  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.
> >
>
> This is also my understanding.
>
> > >
> > > 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.
>
> Yes, I understand.
>
> > 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?
> >
>
> 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 (?)
> > >
> > > 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!
> >
>
> Right, thanks for the rewording. I like a MUST instead better.
>
> > 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.
>
>
> 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.
>
>
>
> >
> > >
> > > 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.
> >
> 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?

In crypto jargon, the SN in the retransmission packet is known-plaintext.  The
ciphers used in SRTP, like most modern ciphers, provide good protection against
known-plaintext attacks, even where there is really great of known plaintext.
So the point that you bring up isn't really a security problem.

David

>
> thanks,
>
> José
>
>
>

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