[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] RE: Security for draft-ietf-avt-rtp-retransmission
José,
> -----Original Message-----
> From: Jose Rey [mailto:rey@panasonic.de]
> Sent: Thursday, January 23, 2003 8:35 AM
> To: Avt@Ietf. Org
> Cc: mbaugher@cisco.com; elisabetta.carrara@era.ericsson.se;
> mcgrew@cisco.com; mats.naslund@era.ericsson.se;
> karl.norrman@era.ericsson.se; oran@cisco.com
> 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: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin
> > Perkins
> > Sent: Friday, January 10, 2003 4:39 AM
> > To: David.Leon@nokia.com
> > Cc: avt@ietf.org
> > 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. 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.
>
> 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. 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?
>
> 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!
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.
>
> 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.
David
>
> 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.
Or maybe a subtle identity theft? :-)
David
>
>
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt