Subject: [AVT] RTP: Confidentiality mechanisms

From: Stephen Casner <[email-masked]>
Date: Tue, 7 Jan 2003 16:33:36 -0800 (PST)

In Section 9.1 of the RTP spec on Confidentiality, I added "redrawn
for each unit" to clarify that RTCP packets can't use just one random
number for all packets.  In addition, I've added two statements
requested by the IESG.

                                                        -- Steve

OLD:
   For RTCP, a 32-bit random number MUST be
   prepended to the unit before encryption to deter known plaintext
   attacks. For RTP, no prefix is required because the sequence number
   and timestamp fields are initialized with random offsets.

NEW:
   For RTCP, a 32-bit random number redrawn for
   each unit MUST be prepended to the unit before encryption to deter
   known plaintext attacks.  For RTP, no prefix is required because the
   sequence number and timestamp fields are initialized with random
   offsets.  This is considered to be a weak initialization vector (IV),
   because of poor randomness properties.  In addition, if the
   subsequent field, the SSRC, can be manipulated by an enemy, there is
   further weakness of the encryption method.

OLD:
   Other encryption algorithms MAY be
   specified dynamically for a session by non-RTP means.  It is
   RECOMMENDED that stronger encryption algorithms such as Triple-DES be
   used in place of the default algorithm.
NEW ADDITION:
   In particular, an AES
   profile taking into account known plaintext and CBC plaintext
   manipulation concerns will be the correct choice in future.

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 07 Jan 2003 21:11:20 -0500

>number for all packets.  In addition, I've added two statements

Looks reasonable. I suggest a small addition to the second change, to
indicate that stronger security is under development. 

>   manipulation concerns will be the correct choice in future.
                         ^ is under development, and 

Colin

---

From: Mark Baugher <[email-masked]>
Date: Wed, 08 Jan 2003 14:10:10 -0800

Steve
    Has any thought been given to dropping the confidentiality 
specification altogether?  Are there real implementations using it?

Mark

---

From: Stephen Casner <[email-masked]>
Date: Wed, 8 Jan 2003 23:16:32 -0800 (PST)

> indicate that stronger security is under development.
[snip]
>                          ^ is under development, and

These wording I showed was verbatim from the message Allison sent
requesting these changes.  I'm not sure to what she was referring, but
I interpreted "profile" to be in the AES domain, not RTP domain.  If
that's correct, then I don't think your addition is needed.

I'm guessing from your comment that you interpret this as referring to
the SRTP profile, but that is really past development, except perhaps
for tweaks for IESG approval.  If SRTP is indeed what Allison meant as
well, then I think we should refer to it by name.

                                                        -- Steve

---

From: Stephen Casner <[email-masked]>
Date: Wed, 8 Jan 2003 23:24:46 -0800 (PST)

Mark,

> specification altogether?  Are there real implementations using it?

Indeed there are two independent interoperable implementations, or it
would have been removed for Draft Standard.  I think the description
of the existing mechanism is adequately qualified (as in constrainted).

                                                        -- Steve

---

From: Mats Näslund <[email-masked]>
Date: Thu, 09 Jan 2003 14:10:28 +0100

Hi,

>    further weakness of the encryption method.

I have some problem with this wording. I assume we are talking CBC
mode(?) I think the text confuses the real issues with using CBC.

First:

 >    known plaintext attacks.

This might signal: "It's okay to use a cipher that does not
resist known plaintext attacks, as long as a rand is prepended".¨

It is *not* ok to use such a cipher, neither does the prepend fix
that problem: the next input block, p2,  *might* still be known and
the previous cipher text block, c1, is certainly known too, so the
input to the 2nd block, c1 XOR p2, will be known anyway.

However, the issue with CBC is that the initial IV must be random
for existing security arguments to hold. Therefore, I assume that
what we really want to say is that in the absence of a truly random
IV, we must randomize the first plaintext block. This is indeed
indicated in the sequel of the above text, but has nothing to do with 
known plaintext attacks: even with a random IV, that IV will in
typical CBC appl. be known to an attacker anyway, and is not the
issue. The only issue is to (sufficiently) "randomize the starting
point".

Next,

 > For RTP, no prefix is required because the
 >    offsets.

This is (strictly speaking) not true. The existing security arguments
for CBC fail if a "counter" type value is used for the IV: even if
the first IV is random, following packet IVs may be highly correlated
to the first one. This does not mean that there is an "attack" on what
you propose (you are probably helped by the fact that the "IV" is
never seen by the attacker), I merely claim that it is not clear that
it is a "sound" way of doing it. At the very least, the caveats
should be pointed out.

Best,

/Mats

---

From: Colin Perkins <[email-masked]>
Date: Thu, 09 Jan 2003 17:42:20 -0500

>well, then I think we should refer to it by name.

I assumed SRTP was meant, and would be happy for it to be referenced by
name (provided it is completed in time).

Colin

---

From: Stephen Casner <[email-masked]>
Date: Thu, 9 Jan 2003 17:57:44 -0800 (PST)

Colin,

> name (provided it is completed in time).

What I meant was that we could say something like this:

   In particular, a profile called "Secure Real-time Transport
   Protocol" is being developed to take into account known plaintext
   and CBC plaintext manipulation concerns, and will be the correct
   choice in the future.

I believe this could be published without any dependency concerns.

But first, I need to clarify that this is what Allison meant.

                                                        -- Steve

---

From: Stephen Casner <[email-masked]>
Date: Fri, 10 Jan 2003 00:39:36 -0800 (PST)

Mats,

I appreciate your input.

> mode(?) I think the text confuses the real issues with using CBC.

Yes, we are talking DES CBC by default.  As the section explains, this
is only there to document existing practice (i.e., for backward
compatibility).  Mark asked earlier whether this whole section should
be removed; I don't think so, but it may be that more needs to be said
about this method being rudimentary and subject to replacement.

> resist known plaintext attacks, as long as a rand is prepended".¨

I am probably responsible for these words, and I think they were
written in 1995.  I only know epsilon about security now, and I knew
less then.  I am happy to change this to say something more
appropriate about why the random prepend is required.

> issue. The only issue is to (sufficiently) "randomize the starting

Just saying this phase doesn't seem very informative or convincing,
either.

> it is a "sound" way of doing it. At the very least, the caveats

Again, I'd be happy to point out the caveats.  The sentence I added at
IESG request about this approach being weak was for that purpose.

The IV is zero in this scheme, as mentioned in a later paragraph.

                                                        -- Steve

---

From: Mats Näslund <[email-masked]>
Date: Fri, 10 Jan 2003 15:55:26 +0100

Hi Steve,

Stephen Casner wrote:

[snip]

> Just saying this phase doesn't seem very informative or convincing,

Agree.

> The IV is zero in this scheme, as mentioned in a later paragraph.

Here is something along the lines I would like to see: What we
want to do is to point out that CBC is a secure way to encrypt
assuming that IVs are independent and random (and, of course,
assuming the cipher itself is secure). This is well-known and
follows from [BDJR] (at least in a certain, reasonable model).

What RTP spec. proposes is to replace the IV by randomization of
the first plaintext block.

For RTCP, the spec. prepends 32 bits of randomness (*independently*
for each packet). This will do part of the job, but corresponds to
only having a short IV which may limit the achievable security
somewhat (basically, after "only" 2^16 packets, a collision is
likely to occur which may leak some information).

For RTP, it is stated that the prepend is not needed as SEQ, TS
are random. However, notice that they are *not* independent from
packet to packet. (I am not sure, but I've heard of video app's
where the TS can even stay fixed for two packets in a row.) Also,
they only consitute at most 48 bits of randomness, and may
cycle/wrap quite quickly. Had a "real" IV (sent along in the clear)
been used in this way (as a counter) it is clear that it would limit
the security, see [BDJR], at least theoretically. In your case, no
IV is actually ever sent in the clear, so I cannot immediately see
that it introduces additional weaknesses. One would, however, need
to verify that this is indeed OK.

Summing up, I would like to see something like (others, please
comment):

   Secure CBC mode requires that the first block of each packet
   be XORed with random, independent, IVs of the same size as the
   cipher's block size. For RTCP, this is (partially) achieved by
   prepending each packet by a 32-bit random string, independently
   chosen for each packet. For RTP, the fact that the timestamp and
   sequence number start from random values are used to this end, and
   no prepend is done. It should however be noted that the randomness
   in both cases (RTP, RTCP) is limited, and for RTP, consecutive
   packets will not be independently randomized. High-security
   applications SHOULD consider other, more conventional, protection
   means.

I would also like to connect to the discussion of need for integrity
protection that we currently have for the SRTP profile. Note that
the suggested use of CBC gives very limited integrity protection.
An attacker flipping bits of the first block of ciphertext will
produce "controlled" flips of the directly following block. He will,
however, also then create random flips in the first decrypted plaintext
block. For RTCP, half of these bits will be assumed to be random
anyway (due to the prepend). So the prob. that he creates something
"readable" is not too big. For sure, he succeeds with prob. at least
2^(-32), though it could be even bigger some times.

Reference:

[BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P.,
        "A Concrete Treatment of Symmetric Encryption: Analysis of
         DES Modes of Operation", Proceedings 38th IEEE FOCS,
         pp. 394-403, 1997.

Best,

/Mats

---

From: Stephen Casner <[email-masked]>
Date: Fri, 10 Jan 2003 08:20:17 -0800 (PST)

Mats,

Thanks for the additional details.  One question:  For RTP, the SSRC,
which follows the SEQ and TS, is also randomly chosen and unknown to
the attacker if both RTP and RTCP are encrypted.  But it does not
change from packet to packet.  Does that contribute anything to the
security?

                                                        -- Steve

---

From: Mats Näslund <[email-masked]>
Date: Fri, 10 Jan 2003 17:58:30 +0100

Steve,

> change from packet to packet.  Does that contribute anything to the

Not much. With CBC (using 3DES as I understand is the default),
the SSRC will not go into "the IV", but rather into the second
block: note that since DES has 64-bit blocks, the first block
will be filled by

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |V=2|P|X|  CC   |M|     PT      |       sequence number         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           timestamp                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

which makes up for the 64-bits. If SEQ/TS wraps or repeats, you will
still get a collision in the first block which can be detected. If
that is serious or not in practice can be discussed, but it is
generally considered as a "problem" (e.g. it leaks the information
that the two packets started with the same thing).

Clearly, the fact that you have something random and unknown in the
second block can't hurt, though I am not sure how much it really helps.

With a larger block size (e.g. AES 128) it will add to the randomization
*per* session, but as you say it is then fixed and the inter-packet
dependence is the same as before.

Cheers,

/Mats

---

From: "David A. Mcgrew" <[email-masked]>
Date: Wed, 15 Jan 2003 08:03:14 -0800

Mats,

thanks for bringing this issue up, more inline:

>    applications SHOULD consider other, more conventional, protection

Clearly these mechanisms should be deprecated.  It might be best to have text
that states that fact up front, and then provides the details for the interested
reader.  It's hard to judge text without knowing where it would go in the
document, but your text looks fine.

Looking through Section 9.1 of RFC1889 makes me wonder if perhaps the entire
confidentiality mechanism described there should be deprecated.  It's DES in CBC
mode with a 32-bit IV.  Because it lacks a full IV, there are attacks which will
work against it with less than 2^56 effort.  It is certainly good security
practice to deprecate weak legacy crypto whenever possible, though perhaps it
would be best to wait until there's an accepted alternative for RTP.

David

---

From: Mats Näslund <[email-masked]>
Date: Thu, 16 Jan 2003 11:13:35 +0100

Hi David,

> would be best to wait until there's an accepted alternative for RTP.

I am inclined to agree. It is really a non-standard crypto transform
that is described. In fact, one alternative way to conceptually think
of the encryption is as follows:

1. The packet header (or part thereof) is prepended with randomness
    and encrypted in ECB (electronic code book mode).
2. The result of step 1 is used as IV for the CBC encryption of
    the remainder, using the *same* key as in step 1.

It seems to me that defining this new "mode of encryption" is
against the AVT WG's earlier stated policy not to define actual
crypto transforms. I too would therefore ask the WG to consider
removing this altogether, rather than adding the text I proposed.

Best,

/Mats

---

From: Colin Perkins <[email-masked]>
Date: Thu, 16 Jan 2003 07:51:43 -0800

>removing this altogether, rather than adding the text I proposed.

It's included for backwards compatibility.  You will note that the draft
also says "It is RECOMMENDED that stronger encryption algorithms such as
Triple-DES be used in place of the default algorithm", and points to the
possible existance of new profiles with additional security.

My hope is that applications will migrate to SRTP or some other more secure
solution, once those are complete.

Colin

---

From: Mats Näslund <[email-masked]>
Date: Thu, 16 Jan 2003 16:58:48 +0100

Colin,

> possible existance of new profiles with additional security.

Note though that the problems comming from the short IV are not really
addressed by replacing DES by 3-DES. I.e., one should should at least
make clear what the issues are so that implementors do not think that
3-DES will be a "cure" to all problems. Our concern is not so much the
cipher transform itself, it is more the use of it.

Agree.

Best,

/Mats