Hi Russ,
Sorry for the delay. Here is the proposed text, hopefully satisfying your
requests:
--
12. Security considerations
RTP packets using the payload format defined in this specification are
subject to the general security considerations discussed in RTP, Section 9.
In common streaming scenarios message authentication, data integrity,
replay protection and confidentiality are desired. The absence of
authentication may enable man-in-the-middle and replay attacks, which can
be very harmful for RTP retransmission. For example: tampered RTCP packets
may trigger inappropriate retransmissions that effectively reduce the
actual bitrate share allocated to the original data stream, tampered RTP
retransmission packets could cause the client's decoder to crash, tampered
retransmission requests may invalidate the SSRC association mechanism
described in Section 5 of this document. On the other hand, replayed
packets could lead to false re-ordering and RTT measurements (required for
the retransmission request strategy) and may cause the receiver buffer to
overflow. Further, in order to ensure confidentiality of the data, the
original payload data needs to be encrypted. There is actually no need to
encrypt the 2-byte retransmission payload header since it does not provide
any hints about the data content.
Furthermore, it is RECOMMENDED that the cryptography mechanisms used for
this payload format provide protection against known plaintext attacks.
RTP recommends that the initial RTP timestamp SHOULD be random to secure
the stream against known plaintext attacks. This payload format does not
follow this recommendation as the initial timestamp will be the media
timestamp of the first retransmitted packet. However, since the initial
timestamp of the original stream is itself random, if the original stream
is encrypted, the first retransmitted packet timestamp would also be
random to an attacker. Therefore, confidentiality would not be compromised.
If cryptography is used to provide security services on the original
stream, then the same services, with equivalent cryptographic strength,
MUST be provided on the retransmission stream. The use of the same key
for the retransmitted stream and the original stream may lead to security
problems, e. g., two-time pads. Refer to Section 9.1 of the Secure
Real-Time Transport Protocol (SRTP)[12] for a discussion the implications
of two-time pads and how to avoid them.
However, at the time of writing this document, the current SRTP
specification cannot afford all the security services mentioned. There
are, at least, two reasons for this: 1) the ocurrence of two-time pads and
2) the fact that this payload format typically works under the RTP/AVPF
profile while SRTP only supports RTP/AVP. An adapted variant of SRTP
shall solve these shortcomings in the future.
Congestion control considerations with the use of retransmission are dealt
with in Section 7 of this document.
--
Looking forward to your comments,
José
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> Behalf Of Russ Housley
> Sent: Thursday, April 07, 2005 11:07 PM
> To: Jose.Rey at eu.panasonic.com
> Cc: david.leon at nokia.com; csp at csperkins.org; avt at ietf.org
> Subject: [AVT] Re: IESG comments on
> draft-ietf-avt-rtp-retransmission-11.txt: security concerns
>
> Sorry for the delay in responding. I have been out of the
> office too much.
>
> >I'll start with the security comments. Russ says:
> >
> > The introduction says:
> >
> > [snip] (no problems with these...)
> >
> > The first paragraph of the security considerations says:
> > >
> > > If cryptography is used to provide security services on the
> > > original stream, then the same services, with equivalent
> > > cryptographic strength, MUST be provided on the retransmission
> > > stream. Old keys will likely need to be cached so that when the
> > > keys change for the original stream, the old key is
> used until it
> > > is determined that the key has changed on the retransmission
> > > packets as well.
> > >
> > > The use of the same key for the retransmitted stream and the
> > > original stream may lead to security problems, e.g.
> two-time pads.
> > > This sharing has to be evaluated towards the chosen security
> > > protocol and security algorithms.
> > >
> > I like the first sentence of the first paragraph very
> much. However,
> > the second sentence implies that the same keying material might be
> > used to encrypt the retransmission, even though it is
> being sent on a
> > separate stream. The second paragraph points to the
> possible security
> > flaw if this is done. Since a SRTP-variant is the
> security protocol
> > that would be used in this context and SRTP is almost
> always used with
> > counter mode, the result could be a loss of
> confidentiality. If the
> > same keying material is used, then a mechanism is needed to ensure
> > that the counter value will be different. SRTP seems to
> be prepared
> > to support this situation, but not without some guidance.
> RFC 3711
> > says:
> > >
> > > In addition, there can be cases (see Sections 8 and 9.1) where
> > > several SRTP streams within a given RTP session,
> identified by their
> > > synchronization source (SSRCs, which is part of the RTP header),
> > > share most of the crypto context parameters (including possibly
> > > master and session keys). In such cases, just as in the normal
> > > SRTP/SRTCP parameter sharing above, separate replay
> lists and packet
> > > counters for each stream (SSRC) MUST still be maintained.
> >
> >
> >I am not sure what is the action that should result from
> this comment.
> >Let me explain myself: the two-time pads issue was discussed in the
> >past with the SRTP authors. The last sentence in the second
> paragraph
> >" This sharing..." is trying to say that if two-time pads
> are not dealt
> >with in the security protocol used, then there is a security
> problem.
> >As Russ (and the doc) says it is a variant of SRTP, SAVPF,
> that will
> >be used to secure the original and rtx streams.
> >
> >Therefore it would be in this SRTP variant that shall define
> what to do
> >with potential two-time pads cases and not in the draft, hence what
> >else could be said here? Since SAVPF draft has expired, I
> understand
> >that the security issue is not solved. Is this what has to be
> >documented or make these two last facts even more explicit?
>
> I think we need to start with a more basic discussion of
> security services. Which ones are desired? And, what are the
> consequences if they are not provided. At a minimum, data
> integrity, authentication, replay protection, and
> confidentiality should be discussed.
>
> Next, the section should point out that a SRTP variant is a
> likely way to provide the needed services. State that SRTP
> as it stands is not acceptable because of the two-time pad
> issue. Give a reference to the two-time pad discussion in
> the SRTP specification.
>
> This would be a good place to include the sentence that I
> liked so much:
> > If cryptography is used to provide security services on the
> > original stream, then the same services, with equivalent
> > cryptographic strength, MUST be provided on the retransmission
> > stream.
>
> I would omit the discussion of "old keys." Leave the
> solution to the designers of the SRTP variant.
>
> I have no problem with the following two paragraphs from your
> -11 document coming next; it seems like good context for the
> SRTP variant designers:
> > Furthermore, it is RECOMMENDED that the cryptography mechanisms
> > used for this payload format provide protection against known
> > plaintext attacks. RTP recommends that the initial RTP timestamp
> > SHOULD be random to secure the stream against known plaintext
> > attacks. This payload format does not follow this recommendation
> > as the initial timestamp will be the media timestamp of the first
> > retransmitted packet. However, since the initial
> timestamp of the
> > original stream is itself random, if the original stream is
> > encrypted, the first retransmitted packet timestamp would also be
> > random to an attacker. Therefore, confidentiality would not be
> > compromised.
> >
> > Congestion control considerations with the use of retransmission
> > are dealt with in Section 7 of this document.
>
> Does this raise any concerns?
>
> Russ
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>
>