Subject: [AVT] IESG comments on draft-ietf-avt-rtp-retransmission-11.txt: security concerns

From: "Jose Rey" <[email-masked]>
Date: Mon, 4 Apr 2005 17:03:22 +0200

Hi Colin, Russ, all,

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?

Thanks,

José

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Colin Perkins
> Sent: Friday, April 01, 2005 3:00 PM
> To: IETF AVT working group
> Subject: [AVT] IESG comments on 
> draft-ietf-avt-rtp-retransmission-11.txt
> 
> Folks,
> 
> The IESG has reviewed the RTP Retransmission format, and had 
> a number of concerns regarding congestion control and 
> security. These can be found in the internet-draft tracker at:
> 
> https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=print_ballot&ballot_id=973&filename=draft-ietf-avt-rtp-
> retransmission
> 
> The chairs, authors and IESG are reviewing these with a view 
> to updating the draft. Other working group members are 
> encouraged to review the comments also, since the issues 
> raised may impact other drafts.
> 
> Colin
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 07 Apr 2005 17:06:59 -0400

Sorry for the delay in responding.  I have been out of the office too much.

>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:
   > 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