Subject: [AVT] Media over DTLS

From: Eric Rescorla <[email-masked]>
Date: Thu, 02 Mar 2006 15:59:27 -0800

Hi,

AVT working group members may be interested in the following suite
of drafts, which define a method for securing multimedia (especially)
RTP traffic using DTLS:

http://www.ietf.org/internet-drafts/draft-fischl-sipping-media-dtls-00.txt
http://www.ietf.org/internet-drafts/draft-tschofenig-avt-rtp-dtls-00.txt
http://www.ietf.org/internet-drafts/draft-fischl-mmusic-sdp-dtls-00.txt
http://www.ietf.org/internet-drafts/draft-modadugu-dtls-short-00.txt
http://www.ietf.org/internet-drafts/draft-rescorla-tls-partial-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-tls-ctr-00.txt

Why is this interesting? SIP does not have a scheme for key negotiation
of media encryption that works with early media and forking. This set of
drafts addresses these issues. Instead of inventing a new key
negotiation protocol, it uses DTLS for key establishment and algorithm
negotiation while having the same on-the-wire packet format as SRTP.

HTML versions can be found at:

http://scm.sipfoundry.org/rep/ietf-drafts/ekr/{draft}.html

The draft of most interest to this WG is probably
draft-tschofenig-avt-rtp-dtls-00 but you may find it helpful to read
draft-fischl-sipping-media-dtls-00 first for background.

-Ekr

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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 2 Mar 2006 16:19:19 -0800

On Mar 2, 2006, at 3:59 PM, Eric Rescorla wrote:

> of media encryption that works with early media and forking.

This is not true.  RFC 3830 does.

Mark
> This set of

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 02 Mar 2006 18:05:25 -0800

> This is not true.  RFC 3830 does.

Hmm... That wasn't quite what I took away from 3830. 

Can you walk me through the SIP call flows for using 3830 with
forking and early media?

Thanks,
-Ekr

---

From: Mark Baugher <[email-masked]>
Date: Thu, 2 Mar 2006 18:51:00 -0800

Eric,

> Can you walk me through the SIP call flows for using 3830 with

It's a short walk as I expect you know: 3830 can work with a single  
message (for all of its modes except for the Diffie-Hellman mode) or  
a round-trip exchange.  In the modes other than DH, the initiator  
sends the policy and a media key embedded in the SDP of the Invite.   
At this point, the responder has everything it needs to send media to  
the initiator.  The same is true in the case of forking.  The simple  
fact that 3830 works with a single message means that no response is  
needed to establish the SRTP crypto context.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Thu, 2 Mar 2006 20:44:19 -0800

On Mar 2, 2006, at 6:51 PM, Mark Baugher wrote:

> message (for all of its modes except for the Diffie-Hellman mode)  
> or a round-trip exchange.  In the modes other than DH, the  
> initiator sends the policy and a media key embedded in the SDP of  
> the Invite.  At this point, the responder has everything it needs  
> to send media to the initiator.  The same is true in the case of  
> forking.

Sorry, what I said is true for forking OR early media but I don't  
think 3830 supports both forking and early media.

Mark
> The simple fact that 3830 works with a single message means that no  
> response is needed to establish the SRTP crypto context.
>
> Mark
>>
>> Thanks,
>> -Ekr
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 03 Mar 2006 00:32:24 -0800

Hi Eric,

As promised in my other email, here is a review of the avt-rtp-dtls 
I-D (I'll follow-up with reviews on some of the others tomorrow).

1. Needs a motivation section.  I realize there is one in 
sipping-media-dtls, but I would like to see one here as well 
explaining why RTP over DTLS is needed or makes sense.

2. I have questions about DTLS-short and its equivalency to DTLS, but 
that's another draft and I will ask comments in the relevant forum 
(would it be TLS?).

3.  On the text in the last paragraph of Section 4:

"With these extensions negotiated, RTP over DTLS packets look
    identical to SRTP records with a 10-byte MAC value.  In fact, they
    cannot be distinguished without access to the DTLS or SRTP keying
    material.  In addition, since the RTP header is in the clear, header
    compression and debugging both work.  Note that DTLS running in SRTP
    compatibility mode has the same security properties as ordinary DTLS
    (with the truncated MAC); there is a reduction between the two
    protocols."

a) I am curious about how DTLS or SRTP packets are distinguished in 
the first place.  In case of SRTP, the destination, port ID and SSRC 
identifies the crypto context.  Why not talk about things in those 
terms and make it more concrete.

Why the need to be identical to SRTP packets?

b) There is no concept of SRTP records!

c) Is there a paper on the reduction between DTLS and DTLS-short?  Is 
DTLS-short an independent protocol or DTLS in SRTP compatibility mode?

4. Would like to see more on the subject of Section 5.  Can I 
conclude that there will be (2 * number of sources) DTLS 
sessions?  How many DTLS handshakes would that be? (Or is there a 
possibility of optimization?)

5. Section 6 has some fundamental errors regarding RFC 3711.  The 
statement that "SRTP uses a 4 byte MAC" is incorrect!  That entire 
section goes on to make comparisons based on that assertion, and that 
should be corrected.

I don't understand how the entire epoch and sequence number can be 
deleted in DTLS-short, but I will ask that in a separate email.

I reached the end of the draft, but have the question of the purpose 
of the draft itself.  I didn't see it specifying anything.  Is it an 
informational draft or is it just to specify:

"
In order to use DTLS/RTP in SRTP compatibility mode, implementations
    SHOULD negotiate:
    o  The TLS partial encryption extension with an InitialPlaintext
       value equal to the length of the RTP header.
    o  The DTLS implicit application data header.
    o  The TLS MAC truncation extension.
"

Shouldn't counter mode part of the list?

Anyway, I'll look forward to your clarifications.  Thanks in advance.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 03 Mar 2006 00:24:54 -0800

Eric,

After reviewing some of these drafts, I find them to be somewhat 
scant on details and it is hard for an independent observer to reach 
the same conclusions you have.  My observations are as follows (and I 
will provide detailed reviews of as many of these drafts as I 
can).  I do appreciate your expertise in the SEC area and in TLS/DTLS 
specifically, so please feel free to point out where I may have misunderstood.

First, as Mark points out, there has been a bundle of work trying to 
solve the early media and forking issues.

Second, it is not clear how DTLS or DTLS-SHORT addresses those 
issues.  Could you please elaborate?  (I have read the motivation 
section of sipping-media-dtls, but that's not convincing).

Next, you note that you are reusing DTLS, yet I find DTLS-SHORT to be 
a quite complex variation of DTLS, and I for one would like to see a 
security analysis of all the extensions and modifications to DTLS 
before we conclude that DTLS-SHORT is equivalent to DTLS.  It may be 
clear to the authors, but it is not clear from the text in the I-Ds.

DTLS or DTLS-SHORT do not have the same on-the-wire packet format as 
SRTP, unless you make liberal assumptions about optional fields.

SRTP also has certain capabilities that DTLS does not have.  Of 
course, as with DTLS-SHORT, you can continue to tweak DTLS to look 
and behave like SRTP.  But, it is not clear what DTLS offers that 
MIKEY+SRTP for instance don't, and why we need this elaborate 
exercise of tweaking DTLS to behave like SRTP, instead of just using 
the latter (it has been around for a long while now and a lot of 
other SDOs use it quite satisfactorily).  Please elaborate!

Regarding things SRTP does and DTLS does not support at the moment, 
SRTP allows reuse of master key for multiple senders, supports 
conferencing and broadcast distribution very well.  SRTP's ROC 
maintenance is much more clear and seems easier to process than the 
epoch+sequence number elimination between DTLS and DTLS-short 
protocols.  In SRTP, integrity verification comes before decryption 
and provisional processing of packets as in DTLS-SHORT or in SRTP (in 
case of ROC synchronization issues).  If checksum verification fails, 
there is no need to decrypt also during the trial-and-error process 
to guess the ROC (with the usual caveats of course).

thanks and regards,
Lakshminath

At 03:59 PM 3/2/2006, Eric Rescorla wrote:
>___From [email-masked] Fri Mar 03 04:33:16 2006
Date: Fri, 03 Mar 2006 10:33:07 +0100
From: Magnus Westerlund <[email-masked]>
To: AVT <[email-masked]>
Subject: Re: [AVT] Proposed addition of time alignment for AMR in RFC 3267 bis

Hi,

WG chair hat off!

Both David's and Chuck's email seem to me to relate to the same problem, 
which has to do with synchronized playback of multiple streams. Where I 
see two versions, multiple received streams need to be played backed at 
the same time, and the case where multiple units need to play back 
things in a synchronized way. Time alignment as existing today in 
circuit switched networks is not the same problem.

Let look at Time alignment in AMR. Its origin is the circuit switched 
GSM link for voice calls. That link enforces that speech is transmitted 
with a periodic time of 20 ms. The data must be available every 20 ms or 
you miss your time slot. As it is each base station that have this clock 
there would buffering of up to 20 ms in that base station to keep that 
schedule. To optimize this and remove this delay when possible a 
procedure "time-alignment" was created that allows the base station to 
request that the data delivery is done with a different phase to 
minimize the buffering delay.

Things worth noting about time-alignment. It is all about of providing 
data just in time. That exercise is difficult if there is varying delay 
between the transmitting party and the consuming party. That was not a 
problem for the circuit switched networks where also the links between 
the radio network controller and the base station had fixed delay. This 
becomes a bit more problematic in IP/UDP/RTP domain. My opinion is that 
time-alignment procedures in RTP is useless unless you apply the 
requirements of low delay variance to the underlying IP network. These 
requirements I think can be satisfied primarily in a well controlled 
environment, like a mobile operator's core network. Thus time alignment 
applicability is limited to certain scenarios.

The use of time-alignment does not remove the need for a jitter-buffer 
and to achieve high performance, and adaptive jitter-buffer. Which 
results in that you have some interacting mechanisms. The jitter-buffer 
will be part of the delay between the transmitting side and the 
consuming side. Thus any adjustment of the jitter-buffer that result in 
that delay changes results in a new optimal phase. This is an important 
consideration to handle.

I would also like to point out that time-alignment is only usable when 
the there is only one link having fixed time slots to adopt to between 
the AMR encoding entity and the decoding entity. So two GSM or UMTS 
links prevents this from being used.

I would also like to point out that any usage of time alignment or 
similar procedures becomes impossible in cases where one encoding is 
distributed to several receivers. It is strictly a procedure for point 
to point sessions. In multi-party environments one will have to rely on 
receiver side procedures.

If the WG thinks this feature with its limited applicability is worth 
pursuing, I would be in favor for a more general mechanism.

 From a glance through of 
http://tools.ietf.org/wg/avt/draft-hdesineni-avt-avpf-ccm-pd-extn-00.txt
I think the authors of this draft is after doing something similar. 
However also in this draft I think there is need for a consideration on 
the applicability of the mechanism. What assumptions it makes of the IP 
transport network. And what possibilities to action the sender and the 
receiver can do to handle the problem(s).

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 07 Mar 2006 20:47:12 -0800

Lakshminath,

Thanks for the really complete and detailed (and fast!) review.

There's a lot to respond to here and so it will take me a little
while, but I'll try to get you a good response ASAP.

Best,
-Ekr

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 07 Mar 2006 23:17:39 -0800

No problem Eric.  Take your time.  Thanks for the heads-up.

best regards,
Lakshminath

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Mar 2006 08:27:34 -0800

Lakshminath,

Thanks for your careful review. Sorry it took me so long to get
back to you. Here's a response to both your messages.

> solve the early media and forking issues.

Right. 

It seems to me that early media/forking don't work reliably in 3830 or
SDESCRIPTIONS as in the RFC-Ed queue, which is why you're seeing work
aimed fixing those problems. So, I certainly agree that there's been
work on that problem, but I'm not convinced that it's satisfactorily
solved.

> Second, it is not clear how DTLS or DTLS-SHORT addresses those issues.
> Could you please elaborate?  (I have read the motivation section of
> sipping-media-dtls, but that's not convincing).

So, the basic problem with early media and forking is that there's a
race condition (in the broad sense) between the completion of SIP
offer/answer and the start of the media. In DTLS/RTP the key
establishment happens in the media channel so there's no need to worry
about round-trips in the signalling channel.

> clear to the authors, but it is not clear from the text in the I-Ds.

I agree that we don't make this argument that clearly in the
drafts. The basic intuition to have is that all the transformations
specified in DTLS-SHORT can be done without having access to the
keying material. This means that the adversary could have made
those transformations himself, which severely limits the security
impact of the transformations. The major exception, which both
David and you raise, is that trying multiple values for the
packet sequence/epoch combination somewhat reduces the strength
of the MAC. However, an 80-bit MAC leaves plenty of room for
this kind of reduction, so I'm not overly worried about that.

Note that the partial encryption mode (not part of DTLS short)
isn't a non-cryptographic transformation, but we already have
partial coverage (we don't encrypt the header) and a NULL
cipher version of TLS so I don't think this is going to require
an enormous amount of non-obvious analysis, at least with a
fixed boundary.

> SRTP, unless you make liberal assumptions about optional fields.

I assume you're referring to extensions here? I don't have a good
intuition for how much variability there is with extensions in a given
connection. I'd note that our major design requirement here was to
enable header compression and debug tools, so if those work mostly OK,
then I'm not sure it's a catastrophe if the extensions are
encrypted. I'd definitely love to get input from AVT types on this
point.

> course, as with DTLS-SHORT, you can continue to tweak DTLS to look and
> behave like SRTP.  But, it is not clear what DTLS offers that
> MIKEY+SRTP for instance don't, and why we need this elaborate exercise
> of tweaking DTLS to behave like SRTP, instead of just using the latter
> (it has been around for a long while now and a lot of other SDOs use
> it quite satisfactorily).  Please elaborate!

Right. The problem here isn't SRTP proper but rather key management
for SRTP, which is turning out to be rather problematic (which,
again, is why you're seeing so many attempts to rework it at this
IETF mtg). DTLS's key management is clear and well understood,
but happens to be bound to a transport security protocol that's not 
as highly tuned as SRTP. DTLS-SHORT is an attempt to capture the
benefits of DTLS/TLS key management while getting acceptable
transport--though admittedly not quite as good--transport 
performance.

Re: your review of draft-tschofenig-avt-rtp-dtls

> explaining why RTP over DTLS is needed or makes sense.

No argument here.

> terms and make it more concrete.

I'm not sure I understand this question. Can you elaborate?

> Why the need to be identical to SRTP packets?

It's not an absolute need, but David McGrew and others have argued
eloquently for why it's desirable for secured RTP to look as much
as RTP as possible and we've taken that to heart.

> b) There is no concept of SRTP records!

Bad writing on my part. I meant packets.

> DTLS-short an independent protocol or DTLS in SRTP compatibility mode?

DTLS-short is a draft that specifies a set of low bandwidth extensions
to DTLS. "SRTP compatibility mode" is a profile of various DTLS
extensions that makes RTP over DTLS look as much like SRTP as we could
<figure out how to make it. Re: a reduction, I think it's pretty clear
that at least as far as passive attacks go, breaking these extensions
would imply a serious problem with TLS, so the only issue I know about
is the one David raised about MAC strength reduction and that's
clearly bounded by the number of times you retry.

> 4. Would like to see more on the subject of Section 5.  Can I conclude
> that there will be (2 * number of sources) DTLS sessions?  How many
> DTLS handshakes would that be? (Or is there a possibility of
> optimization?)

So, remember that DTLS has the concept of "session" (a master key,
basically) and "connection" (inherited from TLS) which is an
association with a given set of keying material. You can resume
a session established in one connection when initiating another
connection (i.e., skipping the public key ops). There is a 
bit of a race condition here if you try to establish them 
together, so naively you would get two sessions. However, you
could probably get some resumption hence some optimization.
I agree that a little more explanation is needed here, but 
session resumption is a pretty clearly understood feature of
TLS/DTLS.

> section goes on to make comparisons based on that assertion, and that

Agreed. The point we were trying to make was about packet size,
and so we chose the MAC size that was favorable to SRTP on
that score. But I agree we should use a 10-byte MAC.

> Shouldn't counter mode part of the list?

Yes. My bad.

Thanks,
-Ekr

---

From: Mark Baugher <[email-masked]>
Date: Sat, 18 Mar 2006 11:26:41 -0800

Eric,

On Mar 18, 2006, at 8:27 AM, Eric Rescorla wrote:

> aimed fixing those problems.

It's good that you're raising this issue.  If we're to begin some  
focused work on this topic in the RAI, then we need to get some  
agreement on what the problems are.  So this is a start.

I don't see reliability as being the issue at all if we couple SDP  
security descriptions (sdesc) with SDP security preconditions  
(sprecon).  I personally think that sprecon is a very good solution  
for sdesc early media.  Why do you say otherwise?  I know some  
reasonable people who disagree, but it's not related to any  
reliability concern to my knowledge.

> So, I certainly agree that there's been
>> issues.

If the race is between a response message sent through the signaling
channel versus an RTP packet through the media channel, then the
outcome is pretty much certain.  Hence all the interest in multiplexing
the media and the signaling.

I see the problem as one of initiating the key establishment from the
caller rather than the callee.  To me, the basic problem is that the
callee can't tell when the caller has received its keying materials
and thus can't send any media until it receives some ack from the
initiator.  Early media can't be supported when that acknowledgment
comes in the form of the caller's RTP packets.

In the forking case, the caller initiates a call with one entity and
ends up with N.  Thus, whatever authenticator the caller has chosen to
use for the callee no longer holds. Callee-initiated key exchange
informs the caller that it is establishing a multi-unicast session
rather than a unicast one and allows each callee to provide its
credentials to the caller.  sdesc+sprecon also solves this problem.
But there's disagreement among some SIP developers about the
complexity of sprecon.  What this debate is missing IMO is running code.

Mark
>> and
>> exercise
>> conclude