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

[Jose Rey <[e-mail]>]

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?

thanks,

José



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