Subject: [AVTCORE] Review of draft-ietf-avtcore-rtp-security-options-04

From: Alan Johnston <[email-masked]>
Date: Wed, 28 Aug 2013 13:32:09 -0500

Here's my review of draft-ietf-avtcore-rtp-security-options-04.

Summary:  The document is well-written and useful.  There are a few
technical issues to resolve but is otherwise ready to progress.

- Alan -

Numbers refer to sections in the document.

3.1.1:

It is surprising no mention is made of RFC 4474 in this section (or in the
whole document) as DTLS-SRTP keying relies on an integrity protected
signaling channel provided by RFC 4474.  When mentioning RFC 4474, it needs
to be pointed out that RFC 4474 is effectively being deprecated by the STIR
work and has proved to be undeployable and also ineffective for E.164
identities.

3.1.5:

Might be worth a single sentence about what makes ZRTP unique, such as:
 "ZRTP provides best effort encryption independent of the signaling
protocol and utilizes key continuity, Short Authentication Strings, or a
PKI for authentication."

5.1:

"There also exists a solution that enables the fingerprints to be bound to
identities established by the first proxy for each user [RFC4916]."  I
don't see how SIP connected identity relates at all to this.  Is this
perhaps meant to reference RFC 4474?

5.2:

"But, unless the application and its server is intending to compromise the
communication security, they can provide a secure and integrity-protected
exchange of the certificate hashes thus preventing any man-in-the-middle
(MITM) from inserting itself in the key-exchange."  This is possible, but
not trivial, and I doubt few WebRTC signaling channels will provide this.
 This statement needs some support for it to be included.

5.2:

Might also be worth a mention that ZRTP can be used to verify the
DTLS-SRTP fingerprints used without relying on any third parties as
described in draft-johnston-rtcweb-zrtp.

Nits:

2:

"it's" -> "its"

2.1:

"end-points verifiable identity" -> "end-point's verifiable identity"

---

From: Colin Perkins <[email-masked]>
Date: Thu, 29 Aug 2013 13:57:37 +0100

Alan,

Thank you for the review. Some comments inline.

Cheers,
Colin

On 28 Aug 2013, at 19:32, Alan Johnston <[email-masked]> wrote:
> Summary:  The document is well-written and useful.  There are a few technical issues to resolve but is otherwise ready to progress.
> 
> - Alan -
> 
> It is surprising no mention is made of RFC 4474 in this section (or in the whole document) as DTLS-SRTP keying relies on an integrity protected signaling channel provided by RFC 4474.  When mentioning RFC 4474, it needs to be pointed out that RFC 4474 is effectively being deprecated by the STIR work and has proved to be undeployable and also ineffective for E.164 identities.

I have added a reference to RFC 4474 in Sections 4.1.3 and 4.1.4 as a result of Dan Wing's comments. I'm not familiar with the STIR work, or the other issues, can you suggest text for Section 3.1.1?

> protocol and utilizes key continuity, Short Authentication Strings, or a PKI for authentication."

Done.

> 5.1:
> 
> "There also exists a solution that enables the fingerprints to be bound to identities established by the first proxy for each user [RFC4916]."  I don't see how SIP connected identity relates at all to this.  Is this perhaps meant to reference RFC 4474?

Yes, I think so.

> 5.2:
> 
> "But, unless the application and its server is intending to compromise the communication security, they can provide a secure and integrity-protected exchange of the certificate hashes thus preventing any man-in-the-middle (MITM) from inserting itself in the key-exchange."  This is possible, but not trivial, and I doubt few WebRTC signaling channels will provide this. This statement needs some support for it to be included. 

Dan Wing had comments on that section also, and it's been rewritten in the -05 version of the draft. That specific text has been removed, but that's not the only change, and I'd appreciate review to see if the new text makes sense.

> described in draft-johnston-rtcweb-zrtp.

I added a mention of ZRTP here.

> "end-points verifiable identity" -> "end-point's verifiable identity"

Fixed.

-- 
Colin Perkins
http://csperkins.org/

---

From: Alan Johnston <[email-masked]>
Date: Thu, 29 Aug 2013 08:47:57 -0500

Colin,

Thanks for making the changes.  A few comments below.

- Alan -

On Thu, Aug 29, 2013 at 7:57 AM, Colin Perkins <[email-masked]> wrote:

> > It is surprising no mention is made of RFC 4474 in this section (or in
> the whole document) as DTLS-SRTP keying relies on an integrity protected
> I have added a reference to RFC 4474 in Sections 4.1.3 and 4.1.4 as a
> result of Dan Wing's comments. I'm not familiar with the STIR work, or the
> other issues, can you suggest text for Section 3.1.1?
>

Here's the proposed charter for STIR:
http://datatracker.ietf.org/wg/stir/charter/

draft-jennings-dispatch-rfc4474bis discusses the problems with RFC 4474 and
some proposed changes.

I would suggest text in this section mention that DTLS-SRTP relies on an
integrity protected signaling channel based on RFC 4474, but that there is
proposed underway in the IETF to try to make this workable.

> > "There also exists a solution that enables the fingerprints to be bound
> to identities established by the first proxy for each user [RFC4916]."  I
> > "But, unless the application and its server is intending to compromise
> the communication security, they can provide a secure and
> integrity-protected exchange of the certificate hashes thus preventing any
> man-in-the-middle (MITM) from inserting itself in the key-exchange."  This
> is possible, but not trivial, and I doubt few WebRTC signaling channels
> will provide this. This statement needs some support for it to be included.
>
> Dan Wing had comments on that section also, and it's been rewritten in the
> -05 version of the draft. That specific text has been removed, but that's
> not the only change, and I'd appreciate review to see if the new text makes
> sense.
>

I will look it over when -05 is out.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 30 Aug 2013 07:53:53 +0200

Hi,

See below for proposal regarding Section 3.1.1.

On 2013-08-29 15:47, Alan Johnston wrote:
> On Thu, Aug 29, 2013 at 7:57 AM, Colin Perkins <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     >
>     > It is surprising no mention is made of RFC 4474 in this section
>     (or in the whole document) as DTLS-SRTP keying relies on an
>     integrity protected signaling channel provided by RFC 4474.  When
>     mentioning RFC 4474, it needs to be pointed out that RFC 4474 is
>     effectively being deprecated by the STIR work and has proved to be
>     undeployable and also ineffective for E.164 identities.
> 
>     I have added a reference to RFC 4474 in Sections 4.1.3 and 4.1.4 as
>     a result of Dan Wing's comments. I'm not familiar with the STIR
>     work, or the other issues, can you suggest text for Section 3.1.1?
> 
> 
> draft-jennings-dispatch-rfc4474bis discusses the problems with RFC 4474
> and some proposed changes.
> 
> integrity protected signaling channel based on RFC 4474, but that there
> is proposed underway in the IETF to try to make this workable.

I tried drafting some text for this. Feedback appreciated

   DTLS-SRTP key management can use the signalling protocol in four
   ways.  First, to agree on using DTLS-SRTP for media security.
   Secondly, to determine the network location (address and port) where
   each side is running a DTLS listener to let the parts perform the
   key-management handshakes that generate the keys used by SRTP.
   Thirdly, to exchange hashes of each side's certificates to bind these
   to the signalling, and ensure there is no man-in-the-middle attack.
   Finally to provide an assertable identity, e.g. [RFC4474] that can be
   used to prevent modification of the signalling and the exchange of
   certificate hashes.  That way enabling binding between the key-
   exchange and the signalling.

   This usage is well defined for SIP/SDP in [RFC5763], and in most
   cases can be adopted for use with other bi-directions signalling
   solutions.  It should be noted that there is work underway of
   revisiting the SIP Identity mechanism [RFC4474] in the STIR WG.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------