Subject: [Sip] Pub request for draft-ietf-sip-dtls-srtp-framework-03

From: Dean Willis <[email-masked]>
Date: Tue, 23 Sep 2008 02:28:00 -0500

We seem to be Done with the DTLS-SRTP Framework!

Here's the draft writeup for draft-ietf-sip-dtls-srtp-framework-03.
Please report any problems (like, maybe I cut-and-pasted the wrong
buffer again) to me and to the list. Thanks!

(1.a) Who is the Document Shepherd for this document?

SIP co-chair Dean Willis will act as the protocol shepherd for this
document.

Has the Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this version is
ready for forwarding to the IESG for publication?

Yes.

The SIP working group would like to request publication of the 
standards-track document draft-ietf-sip-dtls-srtp-framework-03. Here's 
the shepherd's writeup.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?

Yes. The document has been closely followed in several working groups,
and by several security-focused persons.

Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The reviews appear to be adequate.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

The reviews appear to be adequate.

(1.d) Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there
really is a need for it. In any event, if the WG has discussed those
issues and has indicated that it still wishes to advance the document,
detail those concerns here.

There were some concerns about the level of authentication
provided by this document in the face of E.164 numbers and
damage to RFC 4474 Identity done by SBCs. This was extensively
discussed in the WG and the compromise that was reached was
that this document would include a carefully crafted description
of the security properties it provided.

Has an IPR disclosure related to this document been filed? If
so, please include a reference to the disclosure and summarize the WG
discussion and conclusion on this issue.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The WG as a whole understands this document and the consensus
that it should move forward was reasonably strong.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media type
and URI type reviews?

There are several outdated references that can be corrected in the RFC
Editor process, but that do not otherwise impact this
specification. There are also some example IP addresses that are
inconsistent with current guidelines. An RFC Editor note will be
provided to correct these errors.

(1.h) Has the document split its references into normative and
informative?

Yes.

Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the strategy for their completion?  Are
there normative references that are downward references, as described
in [RFC3967]? If so, list these downward references to support the
Area Director in the Last Call procedure for them [RFC3967].

There is a normative reference to the informational-track RFC 3325. AS
this document provides the most widely-implemented mechanism for
identity expression in SIP and the security provided by this
specification is greatly dependent on the identity mechanism, a full
understanding of the limitations of RFC 3325 is required in order to
understand the impact to this specification if used with RFC 3325.

1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document?

This document has no IANA considerations.

If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries? Are the IANA registries
clearly identified?  If the document creates a new registry, does it
define the proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a reasonable name
for the new registry?  See [RFC2434]. If the document describes an
Expert Review process has Shepherd conferred with the Responsible Area
Director so that the IESG can appoint the needed Expert during the
IESG Evaluation?

   N/A.

(1.j) Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules,
MIB definitions, etc., validate correctly in an automated checker?

N/A.

(1.k) The
IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up? Recent examples
can be found in the "Action" announcements for approved documents.
The approval announcement contains the following sections:

Technical Summary

   This document is part of a suite of documents that specify a
   mechanism for keying the Secure Real-time Transport Protocol (SRTP)
   using Datagram Transport Layer Security (DTLS). Together, these
   protocols provide for in-band establishment of secure multimedia
   sessions without dependencies on external authentication
   infrastructures.  This document specifies the SIP framework for
   DTLS-SRTP. A companion document, draft-ietf-avt-dtls-srtp,
   specifies the SRTP portion.

Working Group Summary

   This document is a product of the Session Initiation Protocol
   (SIP) Working Group. It was developed in response to coordinated
   meetings held with several working groups, and in consideration of
   several competing specifications.

Document Quality

   There are at least two known implementations of earlier versions of
   this draft, one Open Source and one commercial. Several
   implementors have expressed interest in implementation and
   deployment of the final version.

Personnel

   The Document Shepherd for this document is Dean Willis, and the
   responsible Area Director is Cullen Jennings.

RFC Editor Note to Accompany Pub Request:

RFC Editor:

Please replace all occurrences of the string "192.168.1" with "192.0.2".

Please replace references to RFC 3280 with references to RFC 5280.

Please replace references to RFC 3546 with references to RFC 4366.

Please update any -draft references as appropriate.

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Schneider, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 23 Sep 2008 16:28:17 +0200

There is maybe one concern with the document in its current form: Is DTLS-SRTP as described now suitable as a media plane security solution for the 3GPP IMS?

A main problem here is the interworking with middleboxes, as described in draft-ietf-mmusic-media-path-middleboxes. This draft is mentionened in draft-ietf-sip-dtls-srtp-framework-03 in a way that makes me assume that following the recommendations of draft-ietf-mmusic-media-path-middleboxes is compliant with draft-ietf-sip-dtls-srtp-framework-03. However, ignoring draft-ietf-mmusic-media-path-middleboxes is also possible, which would lead to a poor interaction with middleboxes. It would be favorable to have the recommendations inside draft-ietf-sip-dtls-srtp-framework itself, and to emphasize that following theses recommendations will help making DTLS-SRTP work in scenarios with middleboxes.

A specific concern is: If ICE is not used, the passive side (the server in the DTLS handshake) must use a STUN connectivity check to open a pinhole (in a middlebox). In 3GPP/TISPAN scenarios it is likely that ICE and STUN do not work at the managed middleboxes (the SBCs) - such traffic may just be discarded. In particular, a STUN connectivity check may NOT trigger latching at an SBC. Sending of no-op RTP packets (see [I-D.ietf-avt-rtp-no-op]) however will trigger the latching. (Both methods are mentioned in draft-ietf-mmusic-media-path-middleboxes at equal ranks, but from the 3GPP/TISPAN and SBC interaction perspective, the "wrong" one was selected as mandatory in draft-ietf-sip-dtls-srtp-framework-03.)

Consider this scenario, showing a managed middlebox plus an unmanaged (e.g. residential) NAT/FW at the passive side:

     SIP     +-----------------+     SIP
  Signaling  |     SIP ALG     |  Signaling 
<----------->+-----------------+<---------------+
             |   MIDCOM Agent  |                |
             +-----------------+                |
                      ^                         |
       Policy rule(s) | and NAT bindings  +---------+      +----------+
                      v                   |     +---|----->| Endpoint |
    Media      +-------------+   Media    | NAT/FW  |      |    P     |
<------------->|  Middlebox  |<-----------|---------|----->|          |
               +-------------+            +---------+      +----------+

The MIDCOM agent will instruct the middlebox to relay the traffic of the session. But even after SDP offer and answer have been exchanged, the middlebox and MIDCOM agent will not know which IP address the residential NAT/FW is going to use for the media session. A STUN connectivity check sent by endpoint P would open a pinhole in the residential NAT/FW, but would be discarded by the middlebox. An RTP packet however, e.g. a no-op RTP packet, would typically cause latching at the middlebox, e.g. make the middlebox take the source IP address of the RTP packet as the media address of endpoint P.

Consequently, at least for 3GPP/TISPAN scenarios, no-op RTP packets should be used rather than STUN connectivity checks, and it would be favorable if the draft mentioned that, e.g. in the section "Latching Control Without ICE".
Maybe the best solution is to recommend  the no-op RTP packets for all scenarios without ICE.

Moreover, draft-ietf-mmusic-media-path-middleboxes recommends:
   - to retry signaling (for key exchange) on the media path in a suitable way, if it has failed (REC #3)
   - to send an SDP answer as soon as possible, for example within a provisional SIP response (REC #4)
Wording reflecting these recommendations should be placed in section 6.7 of draft-ietf-sip-dtls-srtp-framework.

In section 5 of draft-ietf-sip-dtls-srtp-framework, where it is recommended for the answerer to take the active role, a hint should be added that in middlebox scenarios, where middleboxes block the media path before SDP offer and answer have been exchanged (and media before SDP answer will not work anyway), the answerer should take the passive role rather then starting a DTLS-SRTP handshake that will stall due to a blocking middlebox.

Peter 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von ext Dean Willis
> Gesendet: Dienstag, 23. September 2008 09:28
> An: [email-masked]
> Cc: CULLEN JENNINGS; [email-masked]
> Betreff: [Sip] Pub request for draft-ietf-sip-dtls-srtp-framework-03
> 
... 
> The reviews appear to be adequate.
...

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 23 Sep 2008 10:44:05 -0700

Peter, just wanted to ACK that I got this message and I will treat it  
as a IETF LC comment - we can work with folks to resolve the issue.

Cullen <in my AD role>

On Sep 23, 2008, at 7:28 , Schneider, Peter (NSN - DE/Munich) wrote:

> There is maybe one concern with the document in its current form: Is  
> DTLS-SRTP as described now suitable as a media plane security  
> solution for the 3GPP IMS?
>
> A main problem here is the interworking with middleboxes, as  
> described in draft-ietf-mmusic-media-path-middleboxes. This draft is  
> mentionened in draft-ietf-sip-dtls-srtp-framework-03 in a way that  
> makes me assume that following the recommendations of draft-ietf- 
> mmusic-media-path-middleboxes is compliant with draft-ietf-sip-dtls- 
> srtp-framework-03. However, ignoring draft-ietf-mmusic-media-path- 
> middleboxes is also possible, which would lead to a poor interaction  
> with middleboxes. It would be favorable to have the recommendations  
> inside draft-ietf-sip-dtls-srtp-framework itself, and to emphasize  
> that following theses recommendations will help making DTLS-SRTP  
> work in scenarios with middleboxes.
>
> A specific concern is: If ICE is not used, the passive side (the  
> server in the DTLS handshake) must use a STUN connectivity check to  
> open a pinhole (in a middlebox). In 3GPP/TISPAN scenarios it is  
> likely that ICE and STUN do not work at the managed middleboxes (the  
> SBCs) - such traffic may just be discarded. In particular, a STUN  
> connectivity check may NOT trigger latching at an SBC. Sending of no- 
> op RTP packets (see [I-D.ietf-avt-rtp-no-op]) however will trigger  
> the latching. (Both methods are mentioned in draft-ietf-mmusic-media- 
> path-middleboxes at equal ranks, but from the 3GPP/TISPAN and SBC  
> interaction perspective, the "wrong" one was selected as mandatory  
> in draft-ietf-sip-dtls-srtp-framework-03.)
>
> Consider this scenario, showing a managed middlebox plus an  
> unmanaged (e.g. residential) NAT/FW at the passive side:
>
>
> <------------->|  Middlebox  |<-----------|---------|----- 
> >|          |
> The MIDCOM agent will instruct the middlebox to relay the traffic of  
> the session. But even after SDP offer and answer have been  
> exchanged, the middlebox and MIDCOM agent will not know which IP  
> address the residential NAT/FW is going to use for the media  
> session. A STUN connectivity check sent by endpoint P would open a  
> pinhole in the residential NAT/FW, but would be discarded by the  
> middlebox. An RTP packet however, e.g. a no-op RTP packet, would  
> typically cause latching at the middlebox, e.g. make the middlebox  
> take the source IP address of the RTP packet as the media address of  
> endpoint P.
>
> Consequently, at least for 3GPP/TISPAN scenarios, no-op RTP packets  
> should be used rather than STUN connectivity checks, and it would be  
> favorable if the draft mentioned that, e.g. in the section "Latching  
> Control Without ICE".
> Wording reflecting these recommendations should be placed in section  
> 6.7 of draft-ietf-sip-dtls-srtp-framework.
>
> In section 5 of draft-ietf-sip-dtls-srtp-framework, where it is  
> recommended for the answerer to take the active role, a hint should  
> be added that in middlebox scenarios, where middleboxes block the  
> media path before SDP offer and answer have been exchanged (and  
> media before SDP answer will not work anyway), the answerer should  
> take the passive role rather then starting a DTLS-SRTP handshake  
> that will stall due to a blocking middlebox.
>
> Peter
>

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 23 Sep 2008 16:12:32 -0500

> as described now suitable as a media plane security solution for the 3GPP IMS?

What is the media plane, its X and Y dimensions?

Thanks, Henry

On 9/23/08 9:28 AM, "Schneider, Peter (NSN - DE/Munich)"
<[email-masked]> wrote:

> There is maybe one concern with the document in its current form: Is DTLS-SRTP
> as described now suitable as a media plane security solution for the 3GPP IMS?
> 
> A main problem here is the interworking with middleboxes, as described in
> draft-ietf-mmusic-media-path-middleboxes. This draft is mentionened in
> draft-ietf-sip-dtls-srtp-framework-03 in a way that makes me assume that
> following the recommendations of draft-ietf-mmusic-media-path-middleboxes is
> compliant with draft-ietf-sip-dtls-srtp-framework-03. However, ignoring
> draft-ietf-mmusic-media-path-middleboxes is also possible, which would lead to
> a poor interaction with middleboxes. It would be favorable to have the
> recommendations inside draft-ietf-sip-dtls-srtp-framework itself, and to
> emphasize that following theses recommendations will help making DTLS-SRTP
> A specific concern is: If ICE is not used, the passive side (the server in the
> DTLS handshake) must use a STUN connectivity check to open a pinhole (in a
> middlebox). In 3GPP/TISPAN scenarios it is likely that ICE and STUN do not
> work at the managed middleboxes (the SBCs) - such traffic may just be
> discarded. In particular, a STUN connectivity check may NOT trigger latching
> at an SBC. Sending of no-op RTP packets (see [I-D.ietf-avt-rtp-no-op]) however
> will trigger the latching. (Both methods are mentioned in
> draft-ietf-mmusic-media-path-middleboxes at equal ranks, but from the
> 3GPP/TISPAN and SBC interaction perspective, the "wrong" one was selected as
> mandatory in draft-ietf-sip-dtls-srtp-framework-03.)
> 
> The MIDCOM agent will instruct the middlebox to relay the traffic of the
> session. But even after SDP offer and answer have been exchanged, the
> middlebox and MIDCOM agent will not know which IP address the residential
> NAT/FW is going to use for the media session. A STUN connectivity check sent
> by endpoint P would open a pinhole in the residential NAT/FW, but would be
> discarded by the middlebox. An RTP packet however, e.g. a no-op RTP packet,
> would typically cause latching at the middlebox, e.g. make the middlebox take
> the source IP address of the RTP packet as the media address of endpoint P.
> 
> Consequently, at least for 3GPP/TISPAN scenarios, no-op RTP packets should be
> used rather than STUN connectivity checks, and it would be favorable if the
> draft mentioned that, e.g. in the section "Latching Control Without ICE".
> In section 5 of draft-ietf-sip-dtls-srtp-framework, where it is recommended
> for the answerer to take the active role, a hint should be added that in
> middlebox scenarios, where middleboxes block the media path before SDP offer
> and answer have been exchanged (and media before SDP answer will not work
> anyway), the answerer should take the passive role rather then starting a
> DTLS-SRTP handshake that will stall due to a blocking middlebox.
> 
> Peter 
>

---

From: "Schneider, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 24 Sep 2008 10:41:01 +0200

No smiley in the question, so: The media plane is just the set of all media paths. Shown as the line at the bottom of the SIP trapezoid, e.g. in Figure 1 in draft-ietf-sip-dtls-srtp-framework-03.txt .

The media plane security solution to be specified by 3GPP will comprise cryptographic procotocols for securing the media (like SRTP) as well as a key management protocol (or more than one). Because of the middlebox considerations 3GPP currently focusses on key management protocols that do not use the media path.

A 3GPP technical report on this (work in progress) can be found at
http://www.3gpp.org/ftp/Specs/archive/33_series/33.828/33828-081.zip

Peter

> Von: ext Henry Sinnreich [mailto:[email-masked]] 
> Gesendet: Dienstag, 23. September 2008 23:13
> An: Schneider, Peter (NSN - DE/Munich); ext Dean Willis; 
> Tschofenig, Hannes (NSN - FI/Espoo); Jason Fischl; [email-masked]
> Cc: Cullen Jennings; [email-masked]
> Betreff: Re: [Sip] Pub request for 
> draft-ietf-sip-dtls-srtp-framework-03
> 
> > following the recommendations of 
> draft-ietf-mmusic-media-path-middleboxes is
> > Maybe the best solution is to recommend  the no-op RTP 
> packets for all
> > scenarios without ICE.
> > 
> >    - to retry signaling (for key exchange) on the media 
> path in a suitable
> > way, if it has failed (REC #3)
> > Wording reflecting these recommendations should be placed 
> in section 6.7 of
> > draft-ietf-sip-dtls-srtp-framework.
> >

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Sep 2008 00:52:44 -0500

Schneider, Peter (NSN - DE/Munich) wrote:
> Because of
> the middlebox considerations 3GPP currently focusses on key
> management protocols that do not use the media path.

Translation: In order to prevent deployment of a secure system and
enable lawful, unlawful, and extralawful intercept, 3GPP is focusing on
key management protocols that expose the media key via the signaling
plane, and on implementations that expose the signaling plane to all
intermediaries.

Now, if THAT doesn't set Henry off, I don't know what will.  He's
probably been spied on by the Stasi, Ceaus,escu's Securitate, the KGB,
the CIA, AT&T, and for all I know, the NRA and KFC ;-). I forgive him
for being a little touchy about communications security.

And for you folks who trust your carriers to do the right thing:
Remember, you trusted Wall Street firms, UBS, Societe General traders,
etc. to do the right thing too. And they're the ones getting
trillion-dollar bailouts to pay the interest on last year's bonuses to
their executive teams.

Maybe Henry's right.

--
Dean

---

From: "Schneider, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 25 Sep 2008 09:50:36 +0200

> Von: ext Dean Willis [mailto:[email-masked]] 
> Gesendet: Donnerstag, 25. September 2008 07:53
> An: Schneider, Peter (NSN - DE/Munich)
> Cc: ext Henry Sinnreich; [email-masked]

Dean, I assume that you refer to the proposal to use SDES that is discussed in 3GPP. However, 3GPP does not focus on that approach. Other signaling path solutions are discussed in 3GPP that exclude all intermediaries from access to the key. Clearly, allowing lawful interception is a requirement for 3GPP, as is preventing "unlawful interception".

The middlebox issue is NOT a pretense for allowing only weak solutions for 3GPP. My proposals concerning the framework draft wouldn't make DTLS-SRTP any weaker, right? And making DTLS-SRTP more adequate for 3GPP/TISPAN scenarios would be a good thing, wouldn't it?

Peter

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 25 Sep 2008 14:35:00 -0500

> Clearly, allowing lawful interception is a requirement for 3GPP, as
> is preventing "unlawful interception".

Is there a protocol mechanism for distinguishing lawful intercept from
unlawful intercept?

If yes, it would be the greatest invention since the Internet!

Henry

On 9/25/08 2:50 AM, "Schneider, Peter (NSN - DE/Munich)"
<[email-masked]> wrote:

> Dean, I assume that you refer to the proposal to use SDES that is discussed in
> 3GPP. However, 3GPP does not focus on that approach. Other signaling path
> solutions are discussed in 3GPP that exclude all intermediaries from access to
> the key. Clearly, allowing lawful interception is a requirement for 3GPP, as
> is preventing "unlawful interception".
> 
> The middlebox issue is NOT a pretense for allowing only weak solutions for
> 3GPP. My proposals concerning the framework draft wouldn't make DTLS-SRTP any
> weaker, right? And making DTLS-SRTP more adequate for 3GPP/TISPAN scenarios
> would be a good thing, wouldn't it?
> 
> Peter

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Sep 2008 14:32:03 -0500

On Sep 25, 2008, at 2:50 AM, Schneider, Peter (NSN - DE/Munich) wrote:
>
> Dean, I assume that you refer to the proposal to use SDES that is  
> discussed in 3GPP. However, 3GPP does not focus on that approach.  
> Other signaling path solutions are discussed in 3GPP that exclude  
> all intermediaries from access to the key. Clearly, allowing lawful  
> interception is a requirement for 3GPP, as is preventing "unlawful  
> interception".

The two forms of interception cannot be technically differentiated.  
Anything that allows one allows the other.

The USA has recently shown that it is possible to convert unlawful  
intercept into lawful intercept retroactively, despite a  
constitutional bar on ex post facto laws. If you're going to break one  
law, you might as well break 'em all, right?

> The middlebox issue is NOT a pretense for allowing only weak  
> solutions for 3GPP.

I believe you.

> My proposals concerning the framework draft wouldn't make DTLS-SRTP  
> any weaker, right?

I'm not sure. Security is such a frail thing, and it is easy for  
unintended consequences to occur. You may well be right, but I'm a  
little slow to commit.  Further study is required.

> And making DTLS-SRTP more adequate for 3GPP/TISPAN scenarios would  
> be a good thing, wouldn't it?

It might, it might not. It depends on what your definition of  
"adequate" entails and which scenarios you are talking about. The  
requirements rejected by the IETF during the Media Security  
Requirements drafting arguably provide a proof case against this  
assertion.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 25 Sep 2008 14:32:09 -0500

Evil Bit anyone! 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Henry Sinnreich
> Sent: Thursday, September 25, 2008 12:35
> To: Schneider, Peter (NSN - DE/Munich); ext Dean Willis
> Cc: [email-masked]
> Subject: Re: [Sip] Pub request for 
> > Clearly, allowing lawful interception is a requirement for 
> 3GPP, as is 
> > preventing "unlawful interception".
> 
> Is there a protocol mechanism for distinguishing lawful 
> intercept from unlawful intercept?
> 
> >> enable lawful, unlawful, and extralawful intercept, 3GPP 
> is focusing 
> >> on key management protocols that expose the media key via the 
> >> signaling plane, and on implementations that expose the signaling 
> >> plane to all intermediaries.
> >> 
> > 
> > Other signaling path solutions are discussed in 3GPP that 
> exclude all 
> > intermediaries from access to the key. Clearly, allowing lawful 
> > interception is a requirement for 3GPP, as is preventing 
> "unlawful interception".
> > 
> > The middlebox issue is NOT a pretense for allowing only 
> weak solutions 
> > for 3GPP. My proposals concerning the framework draft wouldn't make 
> > DTLS-SRTP any weaker, right? And making DTLS-SRTP more adequate for 
> > 3GPP/TISPAN scenarios would be a good thing, wouldn't it?
> > 
> > Peter
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Schneider, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 25 Sep 2008 21:51:18 +0200

See inline

Peter

> Gesendet: Donnerstag, 25. September 2008 21:32
Allowing lawful interception does not imply allowing anyone to intercept the communication. You must have access control for the facilities that allow lawful interception. Compare this with the authentication service described in RFC4474 (SIP identity). Who controls that service, can mount a man in the middle attack that cannot be detected by the means provided by DTLS-SRTP.

> Requirements drafting arguably provide a proof case against this  
Well, making DTLS-SRTP more adequate for 3GPP/TISPAN scenarios (excluding lawful interception) without making it weaker would be a good thing - better now?

---

From: Eric Burger <[email-masked]>
Date: Thu, 25 Sep 2008 15:28:55 -0600

Let us try it another way:

In the U.S., we have a strong regime of lawful intercept, that  
includes the courts for wiretap orders and multiple, independent keys  
required to do the wiretap.

With all of this protocol and legal protections...

Most of the carriers executed unlawful intercept. Our answer was to  
give them blanket immunity.

Do not be surprised if soon it will be illegal to use cryptographic  
means to secure communications.

Thus...
Unless you have a written directive to ensure insecure communications,  
this model is hopelessly broken.

(signed with my cryptographic signature, if only so you can detect  
integrity degradation)

On Sep 25, 2008, at 1:51 PM, Schneider, Peter (NSN - DE/Munich) wrote:

> Allowing lawful interception does not imply allowing anyone to  
> intercept the communication. You must have access control for the  
> facilities that allow lawful interception. Compare this with the  
> authentication service described in RFC4474 (SIP identity). Who  
> controls that service, can mount a man in the middle attack that  
> cannot be detected by the means provided by DTLS-SRTP.
>
> Well, making DTLS-SRTP more adequate for 3GPP/TISPAN scenarios  
> (excluding lawful interception) without making it weaker would be a  
> good thing - better now?
>
>> --
>> Dean
>>

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 25 Sep 2008 17:09:05 -0500

Peter,

Eric makes here some valid points and I would like to repeat some well known
issues (forgive the repetition) of what intercept means to your network,
even if the facilities are presumably(!) well protected (how about bad
insiders?):

* Shopping is not safe if there is intercept
* Banking is not safe if there is intercept
* B-B financial transactions are not safe if there is intercept
* Private communications are not safe if there is intercept
* Private habits are not safe if there is intercept

But:

* Stalkers, extortionists, kidnappers and other criminals can get you
* Injured consumers and businesses can sue your pants off
* You break the privacy laws in the EU, US and elsewhere
* Someone may or will go to jail for the above and/or
Your network goes out of business for economic and legal reasons.

User will just avoid networks known or even only suspected of having
intercept.

Feel free to discuss these costs with your business development and legal
folks and make a return on investment analysis.

Much success!

Henry

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 25 Sep 2008 20:21:03 -0500

Peter,

Thanks for reminding me of this critical point:

>Allowing lawful interception does not imply allowing anyone to intercept
>the communication. You must have access control for the facilities
>that allow lawful interception.

This argument is simply not true given that all service providers lease
national and international facilities as part of "the network". Data center
capacity and services are also outsourced for countless reasons, so how do
you know for sure where your data is and who exactly is in charge of it?
Many vendors must also have access to critical network infrastructure, to
make it work at all, all the time.

I can only hope your trust in everybody in this very big ecosystem will not
lead to disappointment and worse :-)
(The missing smiley)

Now if you work for a law enforcement agency or the government and your life
really depends on communications security, I doubt you will trust your life
or fortune to services that have intercept built in.

Henry

On 9/25/08 2:51 PM, "Schneider, Peter (NSN - DE/Munich)"
<[email-masked]> wrote:

> Allowing lawful interception does not imply allowing anyone to intercept the
> communication. You must have access control for the facilities that allow
> lawful interception. Compare this with the authentication service described in
> RFC4474 (SIP identity). Who controls that service, can mount a man in the
> middle attack that cannot be detected by the means provided by DTLS-SRTP.
> 
> Well, making DTLS-SRTP more adequate for 3GPP/TISPAN scenarios (excluding
> lawful interception) without making it weaker would be a good thing - better
> now?
> 
>> --
>> Dean
>>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 25 Sep 2008 21:53:57 -0600

Peter,

This SBC latching is an interesting topic and has come up on some of  
the 3GPP/IETF joint conference calls. I view it as an issue to do with  
middle-box traversal for SIP media and somewhat tangential to DTLS- 
SRTP but that does not change the importance of discussing it.

The part I don't really understand is: Why can the SBC latch for RTP  
No-Op packets but not STUN? If you could provide any more information  
about this question in the context of 3GPP usages, I think that would  
be be helpful in deciding what to do.

Thanks, Cullen

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Sep 2008 00:32:37 -0500

> cannot be detected by the means provided by DTLS-SRTP.

Which is why DTLS-SRTP allows one to run the AS on the phone, and to  
verify the media-channel key fingerprint in voice or out-of-band. If  
you do this, you can (assuming your OS hasn't been hacked), detect  
MITM attacks to the extend currently provided for by our mathematics.  
That's a lot stronger than what you get by trusting the bored hourly  
worker down at the switching center.

> (excluding lawful interception) without making it weaker would be a  

That sounds pretty reasonable :-).

---

From: "Schneider, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 26 Sep 2008 09:42:58 +0200

Ok, you guys finally succeeded to convince me: Interception is bad for people!

See also one inline remark below.

Peter

> Gesendet: Freitag, 26. September 2008 07:33
> Betreff: Re: AW: [Sip] Pub request for 

Yes, I'm aware of that. If you do have a secure out-of-band channel, you are fine. And voice verification will also be a way for users (not for all, I'd assume).

---

From: "Schneider, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 30 Sep 2008 22:54:15 +0200

Cullen,

sorry this took some time, and maybe the answer is not fully satisfactory. I could NOT adduce evidence that middleboxes generally don't latch on a connectivity check as described in the ICE-draft. Rather, it seems that existing implementations can be configured to do so. 

However, in 3GPP/TISPAN it is recommended that terminals, if ICE is not supported, use empty (no payload) RTP packets for maintaining NAT bindings: A reference for this is the document

   3GPP TS 24.229 V8.5.0 (2008-09)
   "IP multimedia call control protocol based on
   Session Initiation Protocol (SIP) and Session
   Description Protocol (SDP)"
   http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-850.zip 

which is valid for TISPAN as well as for 3GPP (from Release 8, to be freezed by the end of this year).

In its (normative) Appendix K5.2.1, the document talks more generally about the keepalive for NAT bindings (i.e. not only for the initial establishing of the binding). It states that ICE should be used, but "In the case where keepalives are required and the other end does not support ICE ..., the UE [user equipment] shall send an empty (no payload) RTP packet with a payload type of 20 as a keepalive ...".

So middleboxes that take this behaviour of user equipment into account will latch on RTP packets. Assuming that the "STUN [I-D.ietf-behave-rfc3489bis] connectivity check" mentioned in the DTLS-SRTP-framework-draft is in fact the connectivity check described in the ICE-draft, middleboxes may let such requests pass and even latch on it, depending on the configuration. (Maybe the framework-draft could use a wording that makes more clear that "Latching control without ICE" still uses a method that is rather described in the ICE-draft than in draft-ietf-behave-rfc3489bis to which the framework-draft refers in the text.)

To conclude: In order to make DTLS-SRTP usable in more scenarios, it (still) seems favorable to me to allow (in the case ICE is not used) the usage of empty RTP packets rather than make the "STUN connectivity check" mandatory if the DTLS handshake stalls.

I feel that my other comments (see my original posting below) are still valid, in particular giving more weight to the recommendations from draft-ietf-mmusic-media-path-middleboxes by placing text reflecting these recommendations into the framework draft.

Peter 

> Von: ext Cullen Jennings [mailto:[email-masked]] 
> Gesendet: Freitag, 26. September 2008 05:54
> Cc: ext Dean Willis; Hannes Tschofenig; Jason Fischl; Eric 
> Rescorla; SIP List
> >   - to send an SDP answer as soon as possible, for example 
> within a  
> > provisional SIP response (REC #4)
> in section