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