Subject: [Sip] media-security-requirements and lawful intercept

From: "Dan Wing" <[email-masked]>
Date: Tue, 6 Nov 2007 09:50:42 -0800

Other SDOs have lawful intercept requirements, which are currently
captured in requirement R24 in 
draft-ietf-sip-media-security-requirements-00:

   "R24:   The media security key management protocol SHOULD 
           NOT allow end users to determine whether their 
           end-to-end interaction is subject to lawful 
           interception."

DTLS-SRTP was selected by IETF as the IETF's preferred mechanism
to establish SRTP keys for unicast, point-to-point SRTP sessions.

There appear to be two methods to meet R24 with DTLS-SRTP.  They
are:

   a. provide a network element on every SRTP call which relays
      media, performs a DTLS handshake, and decrypts and re-encrypts
      SRTP, or;

   b. have endpoints perform key disclosure for every call (using a 
      technique similar to draft-wing-sipping-srtp-key), and perform
      validation of that disclosed key on every call.

If these methods to meet R24 are deemed acceptable to other SDOs,
we don't find any reason for those SDOs to reject IETF's decision
to use DTLS-SRTP as the preferred mechanism to establish SRTP
keys for unicast, point-to-point SRTP sessions.

Comments welcome.
-d

_______________________________________________
Sip mailing list  https://www1.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: "Elwell, John" <[email-masked]>
Date: Wed, 07 Nov 2007 11:17:00 +0000

Dan,

Speaking as an individual (not on behalf of another SDO), I don't
believe it is possible to satisfy R24.

With method a, the network element will not be able to provide
appropriate credentials to satisfy a user that he is in communication
with the remote user. Assuming RFC 4474 is used as the basis for
authentication, the certificate provided by the Authentication Service
acting on behalf of user A will sign the request and any self-signed
certificate from UA that will be used in the DTLS handshake. Any
substitution of that certificate by a network element would break the
signature. Any attempt at changing the From URI and Identity header
field by an Authentication Service acting on behalf of the network
element would presumably use a certificate for that domain, not a
certificate for user A's domain, so it would be clear to user B that the
call has come via that middle domain and is encrypted only as far as
that middle domain.

With method b, as already stated one of the users has to agree to
disclose its key.

John

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: 06 November 2007 17:51
> To: 'IETF SIP List'
> Subject: [Sip] media-security-requirements and lawful intercept
>

---

From: Narendra V <[email-masked]>
Date: Wed, 7 Nov 2007 07:52:39 -0800 (PST)

Hi,
  I have IWF scenario, H323 to SIP call. 
  The H323 endpoint is sending DTMF out of band of type UII 'signal'.
 When the user plays a digit the H323 endpoint sends a UII 'signal' with duration and the gateway translates this message into a SIP INFO containing digit code and duration. 
  Next the H323 endpoint send UII signal update message with change in signal duration. 
  Please let me know what should be the outgoing message (i.e. SIP INFO with new duration or no outgoing message).
  Thanks in advance.
  Regards,
  -Naren.
  
 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Dean Willis <[email-masked]>
Date: Wed, 7 Nov 2007 09:59:03 -0600

> With method b, as already stated one of the users has to agree to

Right. I think R24 is awkwardly worded, and should be something like:

    R24:   The media security key management protocol SHOULD NOT allow
           end users to determine whether a specific end-to-end
           interaction is being or will be lawfully intercepted.

We know that all calls in a 3GPP-type network are subject to lawful  
interception. The question is "Is this specific call being  
intercepted or is it more likely to be intercepted than any other call?"

This means that any visible mechanism (keys have to be disclosed or a  
decrypting relay agent) must be exercised for every call, otherwise  
the act of asking for a key on a specific would reveal that there is  
unusual interest in intercepting that specific call.

So, if we (IETF) were to define a mechanism whereby a caller could  
electively disclose session keys to a 3rd party (such as a recorder),  
and some service provider (or national regulator) were to make use of  
this mechanism mandatory for all calls over specific infrastructure,  
I think everybody would be as satisfied as they're going to get.

This does raise all sorts of questions like "What happens when two  
nodes cheat and report invalid session keys to the LI mechanism?",  
something that is obviously doable. But if you ponder it awhile, you  
realize that there's really nothing that can prevent two colluding  
nodes from applying a secondary encryption, just as there is no real  
way to prevent two speakers from talking in code. I once used a  
scrambler that clamped over a regular analog handpiece, did a A to D  
conversion, encrypted, converted the stream into FSK (sounded like  
fax), and inversed the process at the other end. That's why some  
countries made it illegal to use unlicensed fax machines and modems  
for a while -- anybody who was communicating securely needed to be  
investigated. It may also be why some countries originally refused to  
upgrade their filters and echo cancelers to support 14.4 modems. But  
that cat has long since gotten out of the bag and wandered off  
someplace. So the best the LI community can hope for is that the  
majority of nodes will cooperate and that auditing mechanisms will  
have some chance of detecting those that don't.

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Nov 2007 08:18:52 -0800

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Wednesday, November 07, 2007 3:17 AM
> To: Dan Wing; IETF SIP List
> Subject: RE: [Sip] media-security-requirements and lawful intercept
> 
> Dan,
> 
> with the remote user.

Method 'a' could be achieved if the interception (and DTLS handshake)
occurred within the originating domain, prior to the RFC4474
signature.  This can allow inserting the man in the middle at that
point.  This would need to be done for every call (not just 
calls being intercepted).

> Assuming RFC 4474 is used as the basis for

I agree that after the RFC4474 signature is created, other domains
can't become a man in the middle.

> With method b, as already stated one of the users has to agree to

The network can enforce that by blocking SRTP until the key is 
disclosed.  Some networks that block RTP until 200 Ok for fraud
prevention, and those same networks have LI requirements placed
on them by their government.  Those networks could, similarly, block
SRTP until the key is disclosed, and could validate that the 
supplied key does decrypt SRTP (especially SRTP that is protected
with an authentication tag).

-d

---

From: "Bhattacharyya, Dipankar" <[email-masked]>
Date: Wed, 7 Nov 2007 12:49:22 -0500

Hello Naren,

    I would assume that a SIP INFO on the same dialog with an increament
in CSeq and the message body will have the updated Signal Duration.

Regards,

-Dipankar.  

________________________________

From: Narendra V [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2007 9:53 AM
To: IETF SIP List
Subject: [Sip] UII to SIP INFO

Hi,

The H323 endpoint is sending DTMF out of band of type UII 'signal'.
When the user plays a digit the H323 endpoint sends a UII 'signal' with
duration and the gateway translates this message into a SIP INFO
containing digit code and duration. 

Next the H323 endpoint send UII signal update message with change in
signal duration. 

Please let me know what should be the outgoing message (i.e. SIP INFO
with new duration or no outgoing message).

Thanks in advance.

Regards,

-Naren.

---

From: "Fischer, Kai" <[email-masked]>
Date: Thu, 8 Nov 2007 09:20:26 +0100

> Sent: Mittwoch, 7. November 2007 17:19
> To: Elwell, John; 'IETF SIP List'

This might be a solution, but not a very attractive one, since every
call is intercepted and needs to be decrypted and encrypted again. One
argument for DTLS-SRTP is the end-to-end security capability, which will
be weakened for every call in this case.

> with an authentication tag).

How is it possible to perform a DTLS handshake if the RTP traffic /
ports are blocked? Are these blocking network components able to analyze
the first byte of the packets and to distinguish between RTP and DTLS
traffic?

Kai

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 08 Nov 2007 09:28:51 +0000

> Sent: 07 November 2007 16:19
[JRE] This wouldn't work if LI is not being done in the originating
domain. Enterprise UA issues INVITE request, enterprise proxy addes
Identity header field and forwards to public service provider, which
needs the possibility to intercept.

> with an authentication tag).
[JRE] I don't see how it could verify a key if the authentication tag is
not used. Maybe it is easier for SRTCP than for SRTP, but that might
involve some unacceptable delay before the first SRTCP packet arrives.
Having said that, I would have thought the authentication tag would
normally be used, since otherwise the security provided is rather
dubious.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 08 Nov 2007 09:41:30 +0000

Dean,

Yes, I tend to agree that key disclosure to an authority on all calls
passing through a domain with LI capability might be the way to go, but
even then I see problems.

A UA has home domain A that is not required to do LI (an enterprise,
say). On a call by call basis, the UA does not know whether the call
will be routed (directly or indirectly) to a particular domain B that
does LI (a carrier, say), so how does the UA find out that it needs to
report its key to carrier B (or C or D....)?

Also, by doing this, any notion of end-to-end security has gone out of
the window. If the key is disclosed to a third party, can the call
really be used for sending banking details etc.? Surely the business
world needs end-to-end security (or at least end-domain-to-end-domain
security), as we have with HTTPS?

John

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 07 November 2007 15:59
> To: Elwell, John
> Cc: Dan Wing; IETF SIP List
> Subject: Re: [Sip] media-security-requirements and lawful intercept
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 08 Nov 2007 08:48:50 -0500

I have been watching this discussion and getting confused.  (I tried
asking one person off list, and while I understand that person's
perspective, I am still confused about the discussion.)
I went back and re-read the document.

I also went back and re-read RFC 1984.
IETF policy is very clearly stated.  We are not to weaken security
mechanisms in order to enable interception.

So, as I read it, R24 seems to say that if you provide interception in
the protocol, then the presence or absence of such interception must not
be visible to the end user.  That by itself does not say we must provide
LI.  It certainly constrains any solution that claims to support LI.

Do folks read either R24 or some other requirement as mandating that the
IETF standardize an LI supporting solution?

Yes, I am aware that operators are required to provide LI.  And that if
the operator is providing  and mandating the cell phone, and the SIP
software on the cell phone, then one can argue that the operator must
provide meaningful LI (not just a trace of encrypted packets.)  But that
seems to me to be a choice the of the operator's deployment model.  If
the operator were not mandating the SIP stack, then they would not have
this issue.  (One can argue that we want the mechanism that they deploy
to be interoperable with the rest of the world.  But I think that has to
be done by the operator community chosing to constrain what they do, not
by constraining the internet secure RTP to be interoperable with an LI
regime.

There was some mention that the media recording requirement is relevant
to LI.  By my reading, that is an end-point recording capability
requirement that we want to have.  I doubt that the operators would
consider "ask the customer for the recording" an acceptable LI mechanism.

And asking the customer for the key on every call is clearly a
non-starter as a real-world solution to any of this.

Yours,
Joel M. Halpern

---

From: Dean Willis <[email-masked]>
Date: Thu, 8 Nov 2007 09:09:30 -0600

> even then I see problems.

No doubt.

> report its key to carrier B (or C or D....)?

The domain would have to get (and submit) the key for every call sent  
out through a regulated carrier.

I believe it's OK for a user to know whether a given call is being  
routed over a private network/Internet or is going through a  
regulated carrier, and therefore to know that any call being sent  
over the regulated carrier may be subject to LI.

> security), as we have with HTTPS?

Banks take calls over the PSTN every day with less assurance of  
integrity and privacy. The proposed approach provides much better  
security -- with "how much better" being limited by the scope of the  
key distribution. Optionally, one could propose the use of public-key  
or identity based crypto to further defend the session key, for  
example only sending it after encrypting it with the public key of  
the intended recipient.

Many financial and legal operations record every call, and therefore  
need a recorder that is either "in the session with a key" or on a  
second session that gets a twinning of the media. Some courts might  
argue that the second-session recording is inadmissible because it  
might have been undetectably altered (it wasn't exactly the same  
packets as received by the other end), so there are business legal  
reasons to have the recorder in the main media path. Eventually we're  
going to have media-level non-repudiation issues, so if you're  
looking for a Ph. D. project, that would be a good place to look.

I'm sure the auditing organizations will require record keeping on  
where the key goes and which systems have access to it, just as they  
are beginning to require around all credit-card transactions.

Sure, I want my calls to be as secure as possible. But there are  
operational environments where end-to-end crypto just isn't going to  
work.

We're at a decision point here -- do we follow RFC 1984 to the  
fullest extent and design a secure protocol that will have limited  
applicability, or do we design a protocol with broader applicability  
that has explicitly negotiated key sharing?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 8 Nov 2007 09:34:23 -0600

On Nov 8, 2007, at 7:48 AM, Joel M. Halpern wrote:

...

> IETF standardize an LI supporting solution?

No requirement can mandate that the IETF standardize an LI solution  
(since we just can't and won't do that). The requirements draft is  
being revised to describe the related requirements as external to the  
IETF.

Our proposed response to their requirements is to say "With SRTP/ 
DTLS, the endpoints have the keys. If you want it, you have to ask  
them for it. Here's one approach that you might use to do this. We  
may use this same approach to allow recording."

The other alternative is that we do not explain this in the response.  
Then it's either up to them to figure out how to ask for the keys  
(which they can quite well do without us), or to instead use a  
different key negotiation mechanism (such as S-Descriptions). Either  
way, LI is still going to occur. It'll just do so in a manner that  
doesn't interoperate with IETF-standard nodes. And it will cause the  
mobile/regulated community to start writing their own private, not- 
necessarily-publicly documented extensions to or "profiles of"  IETF  
protocols, which is something we've been trying to avoid. This might  
all be acceptable, but we need to understand the consequences.

...

> consider "ask the customer for the recording" an acceptable LI  

I'd say that under RFC 1984 a mechanism whereby they can ask the  
customer to allow them to record is the most we can give them. It's  
up to them as to whether their policy allows calls to proceed in the  
absence of that permission.

> non-starter as a real-world solution to any of this.

Please explain the preceding.

Would the proposal not work?

Would the proposal have too much overhead to be cost-effective? It's  
got less overhead than the alternative of including (for every call)  
one or more media relays that act as  SRTP/DTLS endpoints, maintain  
two session keys per session, and decrypt/re-encrypt every packet. It  
has slightly more overhead than sending the media session key along  
the SIP path. It's also slightly more secure than sending the media  
session key along the SIP path.

Would the proposal fail to inform the user about the security  
constraints? From my POV, it is better for a user to say "Oh, I see  
this call is being routed over a regulated network, so the service  
provider and anybody they give the session key to can listen in"  
rather than to say "Oh, this call is being routed over a regulated  
network, and therefore I cannot use use any cryptography at all and  
anybody who can sniff my 802.11 packets can listen in."

What makes it a non-starter?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Nov 2007 10:50:18 -0500

Dean Willis wrote:

[snip]

> We're at a decision point here -- do we follow RFC 1984 to the fullest 
> extent and design a secure protocol that will have limited 

I don't want to see sip relegated to specialty applications and excluded 
from most common usage.

Having the key disclosure explicit to the UAs seems a better. I guess 
one might ask why a UA would ever agree to disclose its keys, but the 
answer clearly is that it might do so if it has no other option that 
allows making the call.

If it is explicit to the UA, then the UA can indicate to the user that 
the key has been disclosed for this call. (This is another aspect of the 
"lock icon" discussion that is still lurking out there.) Having an 
indication that the call is *eligible for LI* is different from knowing 
that it is being intercepted. It had better be legal to disclose that.

Calls via phones that are directly connected to a carrier would always 
indicate they are eligible for LI, so it might not be a very interesting 
datum. But phones connected to corporate systems might be subject to LI 
only for calls routed via a carrier, not for internal calls. So the 
indicator could be useful for deciding what to discuss or not discuss.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 08 Nov 2007 16:02:56 +0000

Dean,

More in-line.

John 

> Sent: 08 November 2007 15:10
> To: Elwell, John
> > passing through a domain with LI capability might be the 
> way to go,  
> > but
[JRE] He would need to be made aware of this somehow. Often he can't
tell in advance whether a call is to be routed via a carrier or not.

> example only sending it after encrypting it with the public key of  
[JRE] Yes, of course any key disclosure would itself need to be
protected. I guess I am reasonably happy with submitting a key to a
known law enforcement authority (or perhaps to my enterprise, which then
forwards it to a known law enforcement authority), but I am far less
happy about having to send it to any carrier that happens to get
involved in the routing of that outgoing or incoming call.

> operational environments where end-to-end crypto just isn't going to  
[JRE] I agree with most of what you say above, and within an enterprise
this is OK. After all, an RFC 4474 signature by example.com only
guarantees the integrity of the message from the example.com domain
onwards, and what happens in that domain, such as recording for auditing
purposes, is fair game. What I don't want to do is have some
intermediate domain getting in and decrypting the media, unless there is
some assurance that it is for authorised law enforcement purposes only.

> that has explicitly negotiated key sharing?
[JRE] I think we have to do the latter, but we should be very careful
what mechanism we select.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 08 Nov 2007 11:47:15 -0500

> I Said:
> and Dean responded:

So I will elaborate.

The issue with answering is that there are several different assumptions
that one might make about how this would work.  I am unlikely to cover
the cases other people may be thinking of.

So, assume first that the behavior is that the system asks the client
for the keys, and the client asks the user if it is acceptable to
deliver the keys.
As Dean observed, if you are going to do this and meet R24 (which is
clearly mandatory for any meaningful LI), then any network that might
ask for the key has to ask for it every time, whether it uses it or not.

If the users actually had a choice, then asking them might (barely) make
some sense.  But if the users can say no, then they should be trained to
always say no.  And then we don't have an LI solution.

So, if the user says no, when asked if the device can deliver the key,
then the user will not be permitted to make the call on that network.
Thus, the defined system behavior can be paraphrased as "Make it easy
for the system to ask for the key, and train the users to say yes
whenever they are asked for the key."

As far as I am concerned, that is NOT a secure solution.  That is a
pretense of security.  It would be more honest for such networks to
simply refuse to permit encrypted media at any time.

Yours,
Joel

PS: I don't know how the following complication further plays into it:
What stops the handset from delivering a false key?  I suppose we could
define a solution where there is an interface for the system to ask for
a key, and the system hands over whatever it feels like.  The carriers
can then try to ensure that their "approved handsets" hand over the real
key?

---

From: Ted Hardie <[email-masked]>
Date: Thu, 8 Nov 2007 09:11:40 -0800

At 10:50 AM -0500 11/8/07, Paul Kyzivat wrote:
>Dean Willis wrote:
>
>[snip]
>
>>We're at a decision point here -- do we follow RFC 1984 to the fullest extent and design a secure protocol that will have limited applicability, or do we design a protocol with broader applicability that has explicitly negotiated key sharing?
>
>I don't want to see sip relegated to specialty applications and excluded from most common usage.
>
>Having the key disclosure explicit to the UAs seems a better. I guess one might ask why a UA would ever agree to disclose its keys, but the answer clearly is that it might do so if it has no other option that allows making the call.

You mention below the "lock icon" problem, but that is a subset of the larger
mental model question.  How is the user who has no choices but: 

1) no call
2) a call for which it must divulge keys

to distinguish between that condition and "The security set-up for this call has failed. 
Do you wish to continue the call anyway?"  From at least one perspective, the
security set-up for the call has failed if the keys have been forced from the user;
they no longer have any assurance as to the confidentiality of the call. 
I strongly believe that the UI revelation of the key sharing would be minimal or
elided; in your scenario, at least, all carrier calls would have this marker as
a  base state.  Any warning that common must be expected to be ignored, and
a good UI designer is simply going to get it out of the attention field of the user.
In other words, this mechanism will likely be invoked with no attention from
the user, with the result that the security characteristics of the call will be
fundamentally different from the users' expectations.

So, what are we left with?  From my perspective, any work on this would have
to be explicitly done in the context of RFC 1984.  That may well mean setting
out a reasoned discussion of why the interoperability of the mechanism justifies
the work here.  If I hear you right, that statement would be something like:

"We judge  having a single signaling system to be of such
over-riding importance that the inclusion of an optional system for
the sharing of keys to support LI is justified.  We further strongly encourage the
development and deployment of systems which notify the end user when these
mechanisms have been invoked, as well as the deployment of systems which
do not include this optional mechanism.  While these latter systems will fail in
the presence of key demands, they will also serve as the most potent possible
reminder of the prevalence of potential surveillance."

But I think that statement needs to be in public, in a context that engages the
rest of the IETF and Internet community in an open discussion as to whether
need for a single signalling system does  over-ride the concerns expressed
in RFC 1984. 

Speaking personally, it does not do so for me.  Recent experience has shown
a tendency toward data mining approaches to interception that make me
believe that the inclusion of this mechanism will support the continuation
of an epic invasion of privacy that is loosely targeted, extraordinarily
easy to abuse, and for which over-sight has been minimal and public debate
gagged.  Hobbling a mechanism which can maintain privacy in such an
environment is irresponsible.  It is also contrary to the expressed wishes of
the IETF, as set forward in a document that was much debated.

Yes, I understand the problems that this presents, both for interoperability
and the action of lawful intercept.  But I believe that forcing a break here
is honestly the better choice for the Internet and for the future of IETF
technologies.  If we do not maintain at least one system capable of maintaining
privacy, we are  pushing  all communications users into a panopticon
future for their personal communications.

Speaking for me, personally, the costs are too high.  If the working group
does decide to move forward here, I will strongly urge early review by
the broader IETF community, as the consequences of this decision are not
light.

My thanks, Paul, for your reasoned statements; please do take my response
to be directed to you personally.
				regards,
					Ted Hardie

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Nov 2007 12:14:40 -0500

I think this could evolve into a situation where carriers subject to LI 
always request a key and refuse to carry the call unless they get it. If 
a call path can be found that doesn't involve such a carrier then a key 
won't need to be disclosed. People that want calls that can't be 
intercepted will then seek out a connection point where they can connect 
without giving their key.

A PBX in an office is an example. A worldwide enterprise that maintains 
its own network between offices is another example. (Of course that 
could be tunneled over a carrier network via VPNs and would (I think) 
still bypass the LI requirement of the carrier. But maybe not.)

It would be interesting to see when an organization doing that will be 
required to satisfy the LI requirements. Could the IETF manage its own 
VoIP network for use by ietf participants? Is it a matter of whether 
money changes hands? Or how closely affiliated the users are?

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Nov 2007 10:31:18 -0800

> needs the possibility to intercept.

Good point; I had only been considering handsets in IMS (3GPP)
networks.  I'll give that some more thought.

> [JRE] I don't see how it could verify a key if the 
> authentication tag is not used.  Maybe it is easier for SRTCP than for SRTP,

> but that might

Agreed.  And, today, all of the SRTP crypto suites in RFC3711 have an 
authentication tag and as far as I know everyone is using it.

However, it is my understanding that SRTP with Galois/Counter Mode (GCM) 
would not need (or use) an authentication tag.  I don't know how a GCM
key would be validated.  That was my concern there.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Nov 2007 10:32:55 -0800

> call is intercepted and needs to be decrypted and encrypted again.

Yes, I agree it is computationally expensive.

> One
> argument for DTLS-SRTP is the end-to-end security capability, 
> which will be weakened for every call in this case.

LI weakens end-to-end security, no matter the technique chosen.  Today
things are very weak (media is unencrypted).  Security Descriptions 
places trust on every SIP signaling element on the path.  DTLS-SRTP,
with the "a" technique, doesn't place trust on every element, but just
one.

> ports are blocked?

It isn't.  You would need to perform the DTLS handshake when the
RTP path is open, or you would need to perform the DTLS handshake
over RTCP (which is not part of the DTLS-SRTP specification set
at this point in time; there is an offline discussion about this
very problem with DTLS-SRTP and some solutions to that problem.  I
expect to see some email traffic on this specific issue shortly.)

> Are these blocking network components able to analyze

Today, they do not do that, because they do not need to do that.  
They could become capable of doing that.  It is my understanding that,
because today there is no need for those elements to do such
content-based filtering, only simple filters (allow/deny) have been
defined in the relevant specifications and only simple filters
have been implemented by vendors in product.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Nov 2007 10:33:23 -0800

Ted,

> ...
> Speaking for me, personally, the costs are too high.  If the 
> working group does decide to move forward here, I will strongly 
> urge early review by the broader IETF community, as the consequences 
> of this decision are not light.
> ...

Thanks for your email.  I agree this needs wider discussion and the
WG (and probably RAI as a whole) needs to decide what it wants to do.

The wider consequence, however, is not increased "epic invasion of 
privacy", as you state.  The wider consequence is that, without a
suitable mechanism that meets the needs of LI for SRTP, networks 
subject to LI will only ever be able to do RTP.  The choices, as I
see them, are (in order of least secure to most secure):

 1. everyone can listen to the call.  This is what we have today
    with RTP.  This allows 'epic invasion of privacy' by all 
    parties (governments, criminals, and anyone who is able to
    receive your RTP)
 2. every SIP entity learns the SRTP keys.  This is what would
    happen with Security Descriptions.  This allows 'epic 
    invasion of privacy' by any party that has control of any
    SIP entity your Invite (or its response) traversed.  That
    control could be legitimate or could be illegitimate 
    (government or criminal hacked into the SIP proxy).
 3. only a specific SIP entity learns the SRTP key.  This is
    what would happen in the two techniques I proposed at the
    beginning of this thread.  This allows 'epic invasion of
    privacy' by any party that has control of that specific
    SIP entity.  That control could be legitimate or could be
    illegitimate (government or criminal hacked into that 
    specific SIP proxy).
 4. IETF sticks with only doing DTLS-SRTP and provides no 
    guidance for how to meet LI requirements.

The choice, as IETF has always seen it, is to stick with IETF's first
principles [RFC1984, RFC2804] which is end-to-end crypto is best (4) and
market and legal requirements are not relevant to IETF's standards.  I agree
it is a laudable and worthy goal.  I could even agree that we should leave it
to other SDOs, who deal more closely with LI requirements, to determine how
those LI requirements can be met.  

Yet, IETF has also said that IETF owns the SIP standards (and related
standards).  

Taking your suggestion would mean we do (4) and have other SDOs decide if and
how to accomplish a weaker, LI-friendly solution (1, 2, or 3), and IETF should
not provide guidance for the most secure (3) of those remaining LI-friendly
approaches.  The result is undesirable:  millions of users will be unprotected
because they will only have plain RTP (1) or they will be vulnerable to every
SIP proxy on their path (2); (3) is difficult, and (4) will be undeployable by
licensed providers in many countries around the world.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Nov 2007 14:05:56 -0500

Ted - inline...

> fundamentally different from the users' expectations.

I agree with you that the UI for this is of critical importance for any 
of it to mean anything. That in fact is why I keep returning to the 
"lock icon" issue.

Its a difficult issue here because while it is critical, UIs are 
typically outside the scope that IETF deals with.

If the UI designs end up not displaying this information, or displaying 
it in such a way that it is not noticed, or is incomprehensible, then 
you are correct that the enemies of confidentiality will have won.

I can certainly *imagine* ways of building UIs for many devices that 
would comparable in effectiveness of the lock icon in browsers. (But not 
for *all* devices. Its unlikely that a good solution is possible for a 
black phone.)

It may indeed mean that some classes of devices, which are intended for 
use only on contexts where LI is universal, won't show an indication. I 
don't know that there is anything that can or should be done about that.

Its devices that have the chance to operate with/without LI that can 
benefit from an indicator.

> need for a single signalling system does  over-ride the concerns expressed

I don't pretend to understand the procedural issues here. I'll take your 
word for it.

> the IETF, as set forward in a document that was much debated.

I expect that I am philosophically in a position near to yours. I would 
prefer a world where all the communications were e2e encrypted with no 
possibility of interception, in spite of the class of problems that enables.

But I think that we are on the losing end of that argument, and that 
doing nothing about it is comparable to the ietf history of doing 
nothing about NAT. Better the evil we understand than the one that 
evolves without us.

> future for their personal communications.

Suppose we refused to bend here. Then the carriers that are subject to 
LI will either switch to a non-standard variant of our protocols that 
supports the key access, or will use some entirely different protocol.

And then, either I need one device to talk via carriers and a different 
device to talk using IETF means without the carriers, or else I need a 
device that supports both protocols. Requiring distinct devices seems 
impractical. If a single device supports both protocols, then we are 
back to the same UI issue.

But it gets worse. The choice to go over a carrier is often not made by 
the initiating device. The tendency will simply be to bury anchor the 
media in an SBC at the enterprise/carrier boundary and have the SBC 
disclose the key, totally masking the two cases. So this whole 
discussion seems moot unless it is possible to verify that you have 
negotiated keys with actual device of the person you are talking with, 
and not with some intermediary.

	Thanks,
	Paul

---

From: Ted Hardie <[email-masked]>
Date: Thu, 8 Nov 2007 11:21:38 -0800

>privacy", as you state.

This isn't actually what I said; I said we currently see an epic invasion
of privacy and key compromise supports that.  The meat of that section
of my email is probably:
 
"Hobbling a mechanism which can maintain privacy in such an
environment is irresponsible."

I agree with you that failing to provide any mechanism that maintains
privacy is not only worse than hobbling the available mechanism
but equally irresponsible.  If that wasn't clear before, I'm sorry, and
thanks for giving me the chance to make it clear now.

><snip>

>it is a laudable and worthy goal.

I don't think it is quite as bad as "market and legal requirements are
not relevant to IETF's standards".  I think it is closer to those requirements
being balanced against the usefulness of the network to its actual users.
By insisting that what we specify is actually able to meet the security
needs of the users, we make sure that there is at least one option on the
table that does.  Folks can implement and deploy that solution, possibly
without the carrier supported infrastructure of other solutions, and get
a clear expectation of the security available.

> I could even agree that we should leave it

Yes, it has.  It has said that in the context of RFC 1984, though, which was
written with lawful intercept clearly in view.  As I said before to Paul,
a considered review of whether this problem is sufficient to warrant revisiting
that may be in order; a part of that review would certainly be a review of
the hierarchy of issues such as you put forward.  I'm glad we agree that such
a discussion would involve the wider community.

>licensed providers in many countries around the world.

One consequence of specifying (4), at least in my mind, is that some deployments
actually use (4) as specified.  If we don't do what we can to keep that level of
security on the table, who will? 

That does have to be balanced against the possibility that the situation will
remain dire for an even larger number than if we specified 3; the
"mental model" problem there is how we express 3.  It's a little be compromised,
and that's like a little be pregnant.

Thanks very much for message and considered response.  As before,
this represents my personal opinion,
					regards,
						Ted Hardie

---

From: Dean Willis <[email-masked]>
Date: Thu, 8 Nov 2007 13:57:00 -0600

On Nov 8, 2007, at 11:14 AM, Paul Kyzivat wrote:

>
> It would be interesting to see when an organization doing that will  
> be required to satisfy the LI requirements. Could the IETF manage  
> its own VoIP network for use by ietf participants? Is it a matter  
> of whether money changes hands? Or how closely affiliated the users  
> are?

It all depends on which jurisdiction the people and machines happen  
to be in when served with a warrant, and who is doing the serving.

I've had to cough up student traffic at a university, employee  
traffic at a company, and customer traffic at an ISP. IETF would  
likely have the same experience.

--
Dean

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 8 Nov 2007 16:18:14 -0500

> I would prefer a world where all the communications were e2e 
> encrypted with no possibility of interception, in spite of the class of 
> problems that enables.
> 

If our work here becomes irrelevant, it will be because it doesn't do what end users want, not because we've been insufficiently obsequious to the tyrant-of-the-month. Carriers, however broadly the definition of that term may be creeping in some principalities, have certain obligations which are not at all intrinsic to the operation of a protocol like SIP, and we cannot assume that SIP's fate is determined by its success in that arena alone.

> supports the key access, or will use some entirely different protocol.

As has been already pointed out in this thread, RFC4474 (and any larger security architecture relying on it) invests the domain responsible for your AoR with significant trust and responsibility. That domain can insert men-in-the-middle willy-nilly. This seemed architecturally reasonable because you need to trust them anyway, for example, to route calls to you and so on; the sorts of entities to whom LI requirements apply would tend to be the operators of such domains, incidentally. The truly paranoid can of course operate their own domains, personally administer every device, and as such need only trust themselves to make use of RFC4474. This casts the problem exactly how it should be, I think - as an administrative problem. How you deploy and use these tools determines who you need to trust and where there are potential avenues for adversaries to interfere with your security.

Any attempt to cast this as an engineering problem, something that can be fixed or broken at a protocol level, is in my opinion misguided.

Speaking more specifically to R24, my opinion is that a SIP user should be able to ascertain whether or not a certain set of security features have been invoked. If those features have been invoked, then the user might draw the conclusion that it is unlikely, barring some breakthrough in higher mathematics, that someone is able to listen in on their conversation. This is entirely orthogonal to whether or not someone might be intercepting and recording ciphertext media (something the user cannot hope to ascertain), nor whether or not his administrative domain has been compromised (also something the user probably cannot ascertain, even if he runs his own server in a sealed bunker in Montana, given the potential capabilities of adversaries) and his keys plundered. The protocol, and consequently the end user, cannot hope to be privy those lapses. As such it's hard for me to see what the problem is with R24.

If, of course, that set of security features cannot be invoked, the user might draw the conclusion that it is quite likely that someone is listening in on his conversation, and R24-types might find that worrisome. But it is no more likely that the baleful eye of surveillance is scrutinizing the user in this case, really. Inability to invoke those features cannot be said to inform the user that this interaction is "subject to lawful interception" or whatever. Lack of the support for the security features is a much more likely culprit.

So, my question is, what's the engineering problem?

Jon Peterson
NeuStar, Inc.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 08 Nov 2007 21:30:19 +0000

Dan,

Thanks for classifying the options. I just wonder whether there is a
subdivision of 3. With 3, I could negotiate keys with a decrypting
relay, but I really have no idea what happens beyond that relay. Or I
can negotiate keys end-to-end where media is sent via a non-decrypting
relay, which copies the encrypted media to a decrypting entity (not
necessarily a SIP entity) to which I have disclosed the key. That
decrypting entity could be in even be in the domain of the law
enforcement authorities rather than a SIP service provider. Of course,
verification that the key is correct then has to be done by the
decrypting entity more or less in real time, with feedback to the SIP
service provider if it believes the key to be incorrect, so that the
call can be stopped. Did you have one of both of these in mind for
option 3?

John

> Sent: 08 November 2007 18:33
> To: 'Ted Hardie'; 'Paul Kyzivat'; 'Dean Willis'
> Cc: 'IETF SIP List'; Elwell, John

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Nov 2007 16:37:30 -0500

Dean Willis wrote:
> It all depends on which jurisdiction the people and machines happen to 
> be in when served with a warrant, and who is doing the serving.
> 
> I've had to cough up student traffic at a university, employee traffic 
> at a company, and customer traffic at an ISP. IETF would likely have the 
> same experience.

It doesn't matter if you don't have the info.

The question is: when can they come and tell you that you must install 
LI hooks into your system?

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 8 Nov 2007 15:42:42 -0600

> From: Paul Kyzivat [mailto:[email-masked]] 
> 
> The question is: when can they come and tell you that you 
> must install LI hooks into your system?
> 

(9/11) Whenever the (9/11) government decides to do so (9/11).
Otherwise, (9/11) the terrorists (9/11) win.

Seriously. There's no way of knowing when a law may change. The key here
really isn't so much collecting the data, by the way. You can collect
the data, it's reporting the keys to interpret the data.

Regards,
Brian

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 8 Nov 2007 15:47:35 -0600

> From: Fischer, Kai [mailto:[email-masked]] 
> 
> How is it possible to perform a DTLS handshake if the RTP 
> traffic / ports are blocked? Are these blocking network 
> components able to analyze the first byte of the packets and 
> to distinguish between RTP and DTLS traffic?
> 
> Kai

There's a separate document on the way that talks about this. Stay
tuned.

Regards,
Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Nov 2007 16:49:45 -0500

> the data, it's reporting the keys to interpret the data.

Understood. My question was essentially "what kind of usage would be 
found sufficiently offensive that the law would be changed to require a 
new class of network to do LI, including reporting of keys.?"

Apparently at the moment communications within a private enterprise, 
even a distributed one with VPN interconnects via carriers, hasn't 
resulted in demanding that enterprises support LI.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 8 Nov 2007 16:03:14 -0600

> Sent: Thursday, November 08, 2007 3:50 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Dean Willis; IETF SIP List; Joel M. Halpern
> >> The question is: when can they come and tell you that you must 
> >> install LI hooks into your system?
> >>
> > 
> > Seriously. There's no way of knowing when a law may change. The key 
> > here really isn't so much collecting the data, by the way. You can 
> > collect the data, it's reporting the keys to interpret the data.
> 
> Understood. My question was essentially "what kind of usage 
> would be found sufficiently offensive that the law would be 
> changed to require a new class of network to do LI, including 
> reporting of keys.?"

I don't think this is the way governments look at the problem. Voice
traffic, on the face of it, is not a particularly offensive usage but it
obviously has LI requirements. It's more a matter of technical
feasibility. As a common carrier, operators have the only technically
feasible point of collection for this type of data because they are the
transport provider. If all of your voice communications were able to be
collected outside of the provider network, I don't think they'd care so
much to force providers to give them LI capabilities.

I don't think that's as strongly the case with wireline VoIP because
your service provider could be entirely different from your transport
provider in markets where there are a large number of ISPs and they'll
want to collect all of your traffic, not just RTP packets. 

When you look towards cellular wireless, your service provider is again,
vertically integrated with your transport provider (at least today).

That said, the government certainly isn't going to relax any existing
capabilities to perform legal intercept. So even if a traditional
operator starts providing VoIP service to subscribers that utilize an
ISP not owned by that operator the government isn't going to say "oh,
you don't need to support LI anymore" because there's always the CYA
element to be considered.

As long as they can control the chokepoints in the network to ensure
that they can capture the traffic they need, and they have the keys
reported to them to interpret the material if someone in the network has
them (or is compelled to make sure that they get them if technically
feasible) then there's going to be a requirement to report that
information.

> 
> Apparently at the moment communications within a private 
> enterprise, even a distributed one with VPN interconnects via 
> carriers, hasn't resulted in demanding that enterprises support LI.

No, because their ISPs are required to cooperate with law enforcement
and another aspect of LI is that you don't want the target of the
intercept to be aware that they're being intercepted. It'd have been
pretty tough for the FBI to go to ENRON and tell them that they'd like
to collect all of their VPN traffic as part of an SEC investigation, so
they go to the ISP instead.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Nov 2007 17:11:45 -0500

Jon,

> If, of course, that set of security features cannot be invoked, the user might draw the conclusion that it is quite likely that someone is listening in on his conversation, and R24-types might find…

The capability you mention here is perhaps a better statement of what I 
was trying to get at.

It has the same properties - namely that I can make the call whether big 
brother is in the picture or not, and then decide what I am willing to 
say based on my degree of confidence that he can't be deciphering what I 
say.

> So, my question is, what's the engineering problem?

We have a growing collection of security components. AFAIK we still 
don't have a combination sufficient for my phone to indicate to me that 
"this is who your are talking to, and nobody can listen in".

I guess we might have "can't say who you are talking with, but nobody 
can listen in". That in itself is of some utility.

And maybe with sip identity we have "somebody you trust says you are 
talking to X, and nobody can listen in to whoever you are talking to".

As you know, I'm not a security wonk, so I might not have this right. 
There is a gap between what the security building blocks provide and 
assertions that are useful for making decisions about if and how to use 
a communication channel without giving away more than you want to. I 
don't know if that is an engineering problem, or whether its an IETF 
problem, but it is a problem.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Nov 2007 17:16:36 -0500

> they go to the ISP instead.

But the end effect is that if the enterprise starts encrypting all of 
its voice traffic over the VPN then tapping the ISP isn't going to help 
much in getting a tap.

So if that starts happening much will the Feds insist that enterprises 
turn over the keys to their VPNs and to each voice session?

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 8 Nov 2007 16:34:06 -0600

> Sent: Thursday, November 08, 2007 4:17 PM
> enterprise, 
> > to collect all of their VPN traffic as part of an SEC 
> investigation, 
> > so they go to the ISP instead.
> 
> But the end effect is that if the enterprise starts 
> encrypting all of its voice traffic over the VPN then tapping 
> the ISP isn't going to help much in getting a tap.
> 
> So if that starts happening much will the Feds insist that 
> enterprises turn over the keys to their VPNs and to each 
> voice session?
> 
> 	Paul
> 

Yeah, I'm sure they could. This is all very cat and mouse. I don't know
that it's going to get us anywhere to continue down this path. Everyone
can spot imperfections in the various LI schemes. The bottom line here
is that there are a lot of users out there on networks that have LI
requirements today and the question is, do we want SIP to wind up
reverting to party-line type behaviors on these networks.

Regards,
Brian

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Nov 2007 15:14:17 -0800

> Sent: Thursday, November 08, 2007 1:30 PM
> To: Dan Wing; Ted Hardie; Paul Kyzivat; Dean Willis
> Cc: IETF SIP List

Yes, for (3) I am considering the two cases which you are describing
above.  I believe those are the same two cases I had mentioned at the
beginning of this thread:

(this is the decrypting relay you describe above.)

(this is where you disclose SRTP keys and something validates them.)

-d

---

From: Dean Willis <[email-masked]>
Date: Thu, 8 Nov 2007 18:36:25 -0600

> carriers, hasn't resulted in demanding that enterprises support LI.

Yes, it has. There's no CALEA requirement for enterprises, but they  
are subject to LI orders. LI may not be useful if the nodes in  
question are "really secure", but few enterprises have "really  
secure" systems. In my consulting days I had to help a number of  
enterprises implement intercept orders. Such orders can be very  
creatively written and darned hard to implement. But if you don't  
convince the issuing judge you're making a good effort, it's off-to- 
jail-for-contempt-of-court time . . .

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 8 Nov 2007 18:39:37 -0600

On Nov 8, 2007, at 4:11 PM, Paul Kyzivat wrote:

>
> I guess we might have "can't say who you are talking with, but  
> nobody can listen in". That in itself is of some utility.
>
> And maybe with sip identity we have "somebody you trust says you  
> are talking to X, and nobody can listen in to whoever you are  
> talking to".
>

Right. But between "all" and "nothing" there's some middle ground:  
"Nobody who hasn't been authorized to do so by your regulated  
provider can listen in". This is the middle ground they're asking us  
to fill in.

Do we want to go there, or is it all-or-nothing?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 8 Nov 2007 18:43:59 -0600

On Nov 8, 2007, at 4:16 PM, Paul Kyzivat wrote:

>> investigation, so
> But the end effect is that if the enterprise starts encrypting all  
> of its voice traffic over the VPN then tapping the ISP isn't going  
> to help much in getting a tap.
>
> enterprises turn over the keys to their VPNs and to each voice  
> session?
>

Yes. That is exactly how the orders will read. Or, they will insist  
that the IT department hang a black box on a flood port, or that the  
enterprise install a specific software patch. I've also seen orders  
that just demanded clear-text transcripts, recordings, etc. And  
orders for the entire contents of a hard drive. Decrypted. Why do you  
think your IT department restricted which crypto you could use?

What do you think those corporate IT push-the-patch-to-the-user  
packages are about? Sometimes corporate IT gets an order to "install  
this package on the PC used by Joe Smith without him knowing."

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 09 Nov 2007 08:32:41 +0000

Jon,

I go along with your explanation, but I still think it leaves the
following problem. User A in domain A (e.g., an enterprise) makes a call
to/from user B in domain B, via carrier domain C. What you describe
works if domain A or domain B needs to apply LI (or record the call for
any other reason - there are plenty of legitimate business reasons). I
think we don't regard domains A and B as MitM. After all, we rely on
domains A and B to provide the Authentication Service for RFC 4474. The
issue is when domain C tries to interfere with end-to-end security in
order to support LI. I do have a problem with this, because I think it
undermines legitimate business security needs.

If domain C intervenes only when a LI warrant exists for one of the
users, I don't personally have a problem. But this violates R24, which
some people seem to think is important.

If domain C intervenes all the time (either by terminating encryption in
domain C, so that user A and user B see the source of security keying
material as domain C, or by demanding submission of the key to domain C
before admitting the call), I think this is of real concern. It means
businesses cannot have the security they need when, for various reasons,
they are forced to go via a domain C.

So I don't think we should do anything special towards meeting R24 at a
domain C. Although not the IETF's job, those concerned should work with
carriers and regulators to avoid situations where a domain C can prevent
normal end-to-end security on calls not subject to an LI warrant.

Concerning the engineering problem to be solved, there probably isn't
one if we agree that R24 does not apply to a domain C.

John

> From: Peterson, Jon [mailto:[email-masked]] 
> Sent: 08 November 2007 21:18
> To: Paul Kyzivat; Ted Hardie
> Cc: IETF SIP List; Elwell, John; Dan Wing; Dean Willis
> If our work here becomes irrelevant, it will be because it 
> doesn't do what end users want, not because we've been 
> insufficiently obsequious to the tyrant-of-the-month. 
> Carriers, however broadly the definition of that term may be 
> creeping in some principalities, have certain obligations 
> which are not at all intrinsic to the operation of a protocol 
> like SIP, and we cannot assume that SIP's fate is determined 
> by its success in that arena alone.
> 
> As has been already pointed out in this thread, RFC4474 (and 
> any larger security architecture relying on it) invests the 
> domain responsible for your AoR with significant trust and 
> responsibility. That domain can insert men-in-the-middle 
> willy-nilly. This seemed architecturally reasonable because 
> you need to trust them anyway, for example, to route calls to 
> you and so on; the sorts of entities to whom LI requirements 
> apply would tend to be the operators of such domains, 
> incidentally. The truly paranoid can of course operate their 
> own domains, personally administer every device, and as such 
> need only trust themselves to make use of RFC4474. This casts 
> the problem exactly how it should be, I think - as an 
> administrative problem. How you deploy and use these tools 
> determines who you need to trust and where there are 
> potential avenues for adversaries to interfere with your security.
> 
> Any attempt to cast this as an engineering problem, something 
> that can be fixed or broken at a protocol level, is in my 
> opinion misguided.
> 
> Speaking more specifically to R24, my opinion is that a SIP 
> user should be able to ascertain whether or not a certain set 
> of security features have been invoked. If those features 
> have been invoked, then the user might draw the conclusion 
> that it is unlikely, barring some breakthrough in higher 
> mathematics, that someone is able to listen in on their 
> conversation. This is entirely orthogonal to whether or not 
> someone might be intercepting and recording ciphertext media 
> (something the user cannot hope to ascertain), nor whether or 
> not his administrative domain has been compromised (also 
> something the user probably cannot ascertain, even if he runs 
> his own server in a sealed bunker in Montana, given the 
> potential capabilities of adversaries) and his keys 
> plundered. The protocol, and consequently the end user, 
> cannot hope to be privy those lapses. As such it's hard for 
> me to see what the problem is with R24.
> 
> If, of course, that set of security features cannot be 
> invoked, the user might draw the conclusion that it is quite 
> likely that someone is listening in on his conversation, and 
> R24-types might find that worrisome. But it is no more likely 
> that the baleful eye of surveillance is scrutinizing the user 
> in this case, really. Inability to invoke those features 
> cannot be said to inform the user that this interaction is 
> "subject to lawful interception" or whatever. Lack of the 
> support for the security features is a much more likely culprit.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Nov 2007 07:55:35 -0500

Dean Willis wrote:
> "Nobody who hasn't been authorized to do so by your regulated provider 
> can listen in". This is the middle ground they're asking us to fill in.
> 

Well, that is one of the issues isn't it?

I have mixed feelings whether the middle ground is any better and nothing.

So I don't know. But either way, I think these need to be turned into 
meaningful assertions that can be verified.

We have similar situations with callerid. There are a variety of 
mechanisms used to provide info that is presented as "callerid". These 
have a wide range of trustworthiness. I would like to have a way to 
determine the kind of assertion that goes with a callerid when it is 
displayed to me.

	Thanks,
	Paul

---

From: Ted Hardie <[email-masked]>
Date: Fri, 9 Nov 2007 08:40:26 -0800

>some people seem to think is important.

And, as some people have pointed out, they may have to intervene
every time if they are to meet a legal demand that the LI not be
detectable by the end user.  

>one if we agree that R24 does not apply to a domain C.

I would personally be happy with that result.  I think the engineering problem
for anyone who believes it *must* apply to C is a hard one:  designing a system
which 1) allows C to intercept encrypted material 2) allows C to present
unencrypted material to the LI requestor 3) does not require C to ask for
the keys to every flow to hide the LI (to maintain the privacy of the flows
not subject to the LI) and 4) does not reveal C's action to A or B. 

I am not sure that it admits of a solution that does not require a lot of computational
power on the part of C (or, if the burden in 2 shifts to the LI requester, on the part of
the LI requester)

			regards,
				Ted

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 Nov 2007 21:06:38 -0600

> not subject to the LI) and 4) does not reveal C's action to A or B.

I don't think C needs to go to that extent. All C can reasonably do  
is ask A and B for the session key. If A and B are not forthcoming, C  
is free to re-negotiate its peering contract between A and B. And  
that's how the business works today.

If we assume that A and C are also regulated operators, then in most  
jurisdictions they're going to have keys for every session, and it's  
up to their regulators to decide what peers they share keys with and  
what peers they don't.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 10 Nov 2007 12:00:18 -0500

I wish I could agree that the likelihood of the irrelevancy of our work 
is tied to its meeting the needs of end users. Unfortunately, I think 
the reality is more complex than that. Frankly I think the vast majority 
of end users don't care at all about this problem, and will not likely 
choose one provider over another based on the fact that they provide 
security that protects against malicious proxies or what have you. Keep 
in mind that the PSTN provides "security" for voice which is far worse 
even than what sdescriptions provides. My sense of what users probably 
want is enough security to make sure that some kid on the wifi hotspot 
can't pick off their credit card numbers when they call their bank from 
Starbucks. Any of our existing security solutions provide that.

The customers of our protocols are the enterprises and service providers 
that deploy them. If we deliver protocols that they cannot use, because 
they do not meet their needs in terms of LI (or other network 
functions), they'll just use something else that does meet their needs. 
That solution is likely to be what it already is - mostly sdes, along 
with the security weaknesses it comes with. And furthermore it won't 
interoperate since other SP or enterprises will choose MIKEY and we'll 
be in the same mess we are today.

I think our engineering challenge is to provide a solution which gives 
the maximum security possible in an environment where LI exists - 
because it will exist, like it or not. Furthermore, that solution has to 
be relatively cost effective to deploy compared to the alternative. For 
example, if our solution REQUIRES every single call to be decrypted and 
re-encrypted, this is going to be way more expensive to the deployers of 
our protocols than sdescriptions. Also keep in mind that its not just 
voice - but video (ideally hi-def) that is coming down the road, which 
will make that decrypt/re-encrypt function even more expensive. So why 
would they choose this new protocol over sdescriptions? sdes will be 
cheaper to deploy, it will provide security good enough to meet the 
user's needs, and they can deal with interop via SBCs on the boundary. 
If we want to do better than that, we better provide an alternative that 
is more palatable.

Thanks,
Jonathan R.

Peterson, Jon wrote:
>> encrypted with no possibility of interception, in spite of the
>> class of problems that enables.
>> 
>> But I think that we are on the losing end of that argument, and
>> that doing nothing about it is comparable to the ietf history of
>> doing nothing about NAT. Better the evil we understand than the one
>> that evolves without us.
> 
> If our work here becomes irrelevant, it will be because it doesn't do
> what end users want, not because we've been insufficiently obsequious
> to the tyrant-of-the-month. Carriers, however broadly the definition
> of that term may be creeping in some principalities, have certain
> obligations which are not at all intrinsic to the operation of a
> protocol like SIP, and we cannot assume that SIP's fate is determined
>> Suppose we refused to bend here. Then the carriers that are subject
>> to LI will either switch to a non-standard variant of our protocols
>> that supports the key access, or will use some entirely different
>> protocol.
> 
> As has been already pointed out in this thread, RFC4474 (and any
> larger security architecture relying on it) invests the domain
> responsible for your AoR with significant trust and responsibility.
> That domain can insert men-in-the-middle willy-nilly. This seemed
> architecturally reasonable because you need to trust them anyway, for
> example, to route calls to you and so on; the sorts of entities to
> whom LI requirements apply would tend to be the operators of such
> domains, incidentally. The truly paranoid can of course operate their
> own domains, personally administer every device, and as such need
> only trust themselves to make use of RFC4474. This casts the problem
> exactly how it should be, I think - as an administrative problem. How
> you deploy and use these tools determines who you need to trust and
> where there are potential avenues for adversaries to interfere with
> your security.
> 
> Any attempt to cast this as an engineering problem, something that
> can be fixed or broken at a protocol level, is in my opinion
> misguided.
> 
> Speaking more specifically to R24, my opinion is that a SIP user
> should be able to ascertain whether or not a certain set of security
> features have been invoked. If those features have been invoked, then
> the user might draw the conclusion that it is unlikely, barring some
> breakthrough in higher mathematics, that someone is able to listen in
> on their conversation. This is entirely orthogonal to whether or not
> (something the user cannot hope to ascertain), nor whether or not his
> administrative domain has been compromised (also something the user
> probably cannot ascertain, even if he runs his own server in a sealed
> bunker in Montana, given the potential capabilities of adversaries)
> and his keys plundered. The protocol, and consequently the end user,
> cannot hope to be privy those lapses. As such it's hard for me to see
> what the problem is with R24.
> 
> If, of course, that set of security features cannot be invoked, the
> user might draw the conclusion that it is quite likely that someone
> is listening in on his conversation, and R24-types might find that
> worrisome. But it is no more likely that the baleful eye of
> surveillance is scrutinizing the user in this case, really. Inability
> to invoke those features cannot be said to inform the user that this
> interaction is "subject to lawful interception" or whatever. Lack of
> the support for the security features is a much more likely culprit.
> 
> Jon Peterson NeuStar, Inc.
> 
> 
> _______________________________________________ Sip mailing list
> https://www1.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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Frank W. Miller" <[email-masked]>
Date: Sat, 10 Nov 2007 15:48:21 -0700

I could not disagree more.

The purpose of our work in IETF forums is not to pander to the service
providers and the strongarm tactics that the government uses to control
them.  It is to provide the best possible protocol that enables as many
uses as possible.  You yourself have always stated that SIP is general
and should support a wide variety of uses cases.  Why is that different
now with security?

Our security requirements and implementation MUST include use cases that
involve true end-to-end security that does not include the ability for
eavesdropping of any kind, let alone LI.

To support this, I would point at the applications I am seeing with my
employer, since you have focused on the needs of yours.

We build military radios.  Those radios are moving towards the use of
VoIP and want to leverage SIP for many reasons.  There are MANY
situations in these environments where end-to-end security is an
absolute requirement, in many cases, with NSA Type I encryption to boot.
If the protocol does not include these capabilities, others will be
needed to support these requirements and interoperability will suffer.

While we may provide scenarios where LI can be accomplished, we cannot
define the protocol in a way that precludes the ability to do end-to-end
security.

FM

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, November 10, 2007 10:00 AM
To: Peterson, Jon
Cc: IETF SIP List; Paul Kyzivat; Elwell, John; Dan Wing; Dean Willis
Subject: Re: [Sip] media-security-requirements and lawful intercept

is more palatable.

Thanks,
Jonathan R.

---

From: Ted Hardie <[email-masked]>
Date: Sat, 10 Nov 2007 18:10:35 -0800

At 12:00 PM -0500 11/10/07, Jonathan Rosenberg wrote:
>
>The customers of our protocols are the enterprises and service providers that deploy them.

They may be among the customers of our protocols, but they are neither the
only customers nor the most important ones.  We build end-to-end protocols;
in this case, one which enables person-to-person communications over
extremely varied infrastructures.  If we do not keep that in mind and deliver
a protocol that enables that person-to-person communication to be secure,
our reasoning for that protocol choice will not matter.  We will have failed
our main customer.

Yes, the features may be rarely used, and many end-user customers may neither
know nor care that they are even available.  But there are customers
who would use them if available, and there may well be more as the
feature gets easier to use and the need more evident.  If we do not
build the system with *them* in mind, who will? 

You argue that LI will exist, like it or not.  I don't think anyone here is blind
to that reality.  But there is a serious difference between designing a system
which maximizes the security of its end users, knowing that there are mechanisms
which may still compromise it, and designing a system to be palatable to those
who intend to.  There are increasing numbers of governments who treat any
attempt to maintain personal privacy as thwarting their security interests,
rather than seeing maintaining their citizens' privacy interests as part of their duty.
I have no interest in making their bites at our privacy palatable, and I have no
interest in pretending otherwise.

Again, this is my personal view, and not meant in any way as disrespect to you,

				regards,
					Ted Hardie

---

From: "Dean Willis" <[email-masked]>
Date: Sun, 11 Nov 2007 01:47:27 -0600

> eavesdropping of any kind, let alone LI.

So when your service provider asks you for your session key, do not tell them. Whether they allow the call or not, we're all happy because our principles and 
use cases have been upheld. However, some people DO want to use service providers that will require key disclosure. Should we deny their use case?

The approach Dan has suggested allows the user to decide whether or not they wish to disclose their keys. And it allows service providers to decide whether or 
not they will require the disclosure of session keys. It works in enterprises that are subject to auditing. It also works in regulated networks subject to LI. 
And it works in classified networks with maximal security requirements. It does all this with one code base, one protocol, and full interoperability between 
domains.

What use cases does this exclude?

--
dean

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 11 Nov 2007 07:12:11 -0800

I would like to add another law enforcement perspective with two usage
scenarios to what Ted Hardie says here below about the MUST have e2e
security:

- Law enforcement will not be able to protect us since the bad guys will
find out who they are and kill them first,

- The financial system will have to revert to personal contacts only and
armored carriers for everything. Or do you trust personal banking and
fund transfers through ISPs that do deep packet inspection?

Is this the type of society our engineers feel comfortable to enable?
Or is it our duty to explain these consequences to law makers?

Thanks, Henry

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Saturday, November 10, 2007 8:11 PM
To: Jonathan Rosenberg; Peterson, Jon
Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dan Wing; Dean Willis
Subject: Re: [Sip] media-security-requirements and lawful intercept

>The customers of our protocols are the enterprises and service
providers that deploy them.

They may be among the customers of our protocols, but they are neither
the
only customers nor the most important ones.  We build end-to-end
protocols;
in this case, one which enables person-to-person communications over
extremely varied infrastructures.  If we do not keep that in mind and
deliver
a protocol that enables that person-to-person communication to be
secure,
our reasoning for that protocol choice will not matter.  We will have
failed
our main customer.

Yes, the features may be rarely used, and many end-user customers may
neither

You argue that LI will exist, like it or not.  I don't think anyone here
is blind
to that reality.  But there is a serious difference between designing a
system
which maximizes the security of its end users, knowing that there are
mechanisms
which may still compromise it, and designing a system to be palatable to
those
who intend to.  There are increasing numbers of governments who treat
any
attempt to maintain personal privacy as thwarting their security
interests,
rather than seeing maintaining their citizens' privacy interests as part
of their duty.
I have no interest in making their bites at our privacy palatable, and I
have no
interest in pretending otherwise.

Again, this is my personal view, and not meant in any way as disrespect
to you,

				regards,
					Ted Hardie

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 Nov 2007 10:37:44 -0500

This sounds great.  But the reality seems to me to actually not match
this perspective.

Firstly, a solution with a mechanism for requesting a key by a third
party is clearly introducing security complexity, which seems to imply
security vulnerability from all the things I have read.

More importantly, a solution in which as a practical deployment we teach
the users to say "yes, deliver a copy of my key" when asked seems a
recipe for an insecure system even if each and every protocol component
is secure.  This makes me very uncomfortable.

Yours,
Joel M. Halpern

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 11 Nov 2007 16:47:08 +0100

This list is NOT for discussing the woes of society at large.

Please go back to the scope of this thread which is discussing the
contents of the media security requirements document.

Regards

Keith 

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Sunday, November 11, 2007 3:12 PM
> To: Ted Hardie; Jonathan Rosenberg; Peterson, Jon
> I would like to add another law enforcement perspective with 
> two usage scenarios to what Ted Hardie says here below about 
> the MUST have e2e
> security:
> 
> - Law enforcement will not be able to protect us since the 
> bad guys will find out who they are and kill them first,
> 
> - The financial system will have to revert to personal 
> contacts only and armored carriers for everything. Or do you 
> trust personal banking and fund transfers through ISPs that 
> do deep packet inspection?
> 
> They may be among the customers of our protocols, but they 
> are neither the only customers nor the most important ones.  
> We build end-to-end protocols; in this case, one which 
> enables person-to-person communications over extremely varied 
> infrastructures.  If we do not keep that in mind and deliver 
> a protocol that enables that person-to-person communication 
> to be secure, our reasoning for that protocol choice will not 
> matter.  We will have failed our main customer.
> 
> Yes, the features may be rarely used, and many end-user 
> customers may neither know nor care that they are even 
> available.  But there are customers who would use them if 
> available, and there may well be more as the feature gets 
> easier to use and the need more evident.  If we do not build 
> the system with *them* in mind, who will? 
> 
> You argue that LI will exist, like it or not.  I don't think 
> anyone here is blind to that reality.  But there is a serious 
> difference between designing a system which maximizes the 
> security of its end users, knowing that there are mechanisms 
> which may still compromise it, and designing a system to be 
> palatable to those who intend to.  There are increasing 
> numbers of governments who treat any attempt to maintain 
> personal privacy as thwarting their security interests, 
> I have no interest in making their bites at our privacy 
> palatable, and I have no interest in pretending otherwise.
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Frank W. Miller" <[email-masked]>
Date: Sun, 11 Nov 2007 09:48:28 -0700

I suppose that even if some third-party key management scheme is
adopted, ZRTP will still exist.

My point is that in this requirements, there are so many and they appear
to be fairly random in their ordering and what they are targeting the
way the draft is written that I would be concerned that some requirement
or combination of requirements would preclude and end-to-end solution.
While Section 5 does make an effort to try to group them, it seems a bit
more philosophical rather than focused on actually rounding up sets of
the requirements in Section 4.

At a minimum, I would recommend the following before further discussion
is had.  Move Section 5 before Section 4 and call it Architectural Basis
or something like that.  Then partition the requirements that are
currently in Section 4 based on that discussion.  The goal would be to
make sure there aren't any sneaky interactions between the requirements.

Also, as an aside, I would recommend that anyone that is not familiar
with SCIP should try to become familiar with it.  Those protocols follow
closely what is done currently with PSTN based STU/STEs, bringing that
operational paradigm to the packet world.  The operational approach
described by that protocol design is reflective of one set of
requirements used by the military and intelligence communities for
secure communications.

FM

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Sunday, November 11, 2007 12:47 AM
To: [email-masked]
Cc: Jonathan Rosenberg; Jon Peterson; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Sip] media-security-requirements and lawful intercept

> eavesdropping of any kind, let alone LI.

So when your service provider asks you for your session key, do not tell
them. Whether they allow the call or not, we're all happy because our
principles and 
use cases have been upheld. However, some people DO want to use service
providers that will require key disclosure. Should we deny their use
case?

The approach Dan has suggested allows the user to decide whether or not
they wish to disclose their keys. And it allows service providers to
decide whether or 
not they will require the disclosure of session keys. It works in
enterprises that are subject to auditing. It also works in regulated
networks subject to LI. 
And it works in classified networks with maximal security requirements.
It does all this with one code base, one protocol, and full
interoperability between 
domains.

--
dean

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 11 Nov 2007 14:47:06 -0800

At Tue, 6 Nov 2007 09:50:42 -0800,
> keys for unicast, point-to-point SRTP sessions.

Wow, this sure produced a lot of discussion. I'd like to make a few
points:

1. It's not clear to me that people are correctly parsing LI
   requirements. I'm not an expert on CALEA, let alone laws in other
   countries, but it's not my understanding that there is any
   regulatory requirement that forces carriers of voice or data
   traffic to arrange for disclosure of plaintext when they don't have
   the keys. I.e., if I buy data service from Comcast and choose to
   run a VPN, there is no requirement that Comcast somehow obtain the
   keys to deliver them to the FBI.

   It's less clear to me what the requirements are for 3G-style
   carriers when the endpoints are doing the crypto. I.e., I'm quite
   certain that if AT&T terminates the crypto they need to provide the
   plaintext on request, but a lot less certain that they need to
   provide the plaintext if the crypto is end-to-end.

2. It's extremely difficult to guarantee that the keys for
   communication are being properly escrowed in the face of the
   possibility that one or both of the communicating parties is
   cheating. This is especially difficult if you want to avoid having
   real-time access to the escrow keys used to encrypt the traffic
   keys, which is generally good practice.  So, I would be very
   surprised if there were any regulatory requirement that LI work in
   the face of endpoint cheating.

3. Given (2) above, I don't see how R24 can be achieved, since
   two cooperating peers can always guarantee that their plaintext
   is not subject to LI if they can arrange for any side channel
   for key agreement.

4. I don't actually think there's any protocol engineering required
   here. The problem of how to arrange for TLS traffic key disclosure
   to third parties without modifying the wire protocol has been quite
   extensively studied and a broad variety of approaches exist,
   covering a range of levels of active/passiveness, real-timeness,
   cooperation from the endpoints, etc. Techniques exist which are
   significantly better than those indicated by Dan. For instance,
   consider that if you have the TLS server's private key and you're
   doing RSA, you can do completely passive inspection with no
   cooperation from either side. Another example would be [GBGP03]. 

   Also, as Jon Peterson observed, the owner of the namespace can
   always enforce any restrictions that it wants. It's possible that
   imposes significant performance costs, but it's not clear that
   that's true in all cases with clever implementation. 

   I don't really have time right now to go into any of this stuff
   in more detail, but I'd certainly be happy to sit down with
   anyone who cares in YVR and explain the state of the art. I don't
   really see that this is really relevant to what happens in this
   WG, though.

-Ekr

[GBGP03] E.-J. Goh, D. Boneh, P. Golle, B. Pinkas",
	 The Design and Implementation of Protocol-Based Hidden
	 Key Recovery", 2003.

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 11 Nov 2007 18:30:48 -0800

> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: Sunday, November 11, 2007 2:47 PM
> To: Dan Wing
> Cc: 'IETF SIP List'

Timothy Dwight posted a followup on 3GPP's requirement that should
be helpful on those points.  What remains unsaid in that quoted text 
is crypto performed by the endpoint itself (as with DTLS-SRTP).

We could navel-gaze how governments might view that, or look at this
from a business perspective:  If you are a service provider, and you're
looking at RTP, SRTP with Security Descriptions, or SRTP with DTLS-SRTP,
what is the business opportunity versus business risk of adopting each
of those technologies.  The business opportunity is pretty straightforward:
would you get more subscribers if you offered a secure service.  The 
business risk is more murky:  will a government agency decide you still
need to provide decryption keys, because you still obstensibly "own" the
endpoint (afterall, a cellular provider does own the radio license for 
that endpoint).

>    is not subject to LI if they can arrange for any side channel

It is well-acknowledged that two cooperating peers can establish 
their own private communication, over the top of whatever communications
channel they can set up normally.

>    cooperation from either side.

I am aware of that technique; however, for SIP calls with the offer
in the in the Invite, you could only intercept outgoing calls, 
because incoming calls cause your intercept target to be the TLS
client.  I don't believe that technique is viable to meet R24.

> Another example would be [GBGP03]. 

I was not aware of that technique; thanks for the pointer.  That
technique seems useful.

(Direct link, 
http://crypto.stanford.edu/~pgolle/papers/escrow.pdf)

>    anyone who cares in YVR and explain the state of the art.

Thanks for the offer.

> I don't

If 3GPP decides to use something other than DTLS-SRTP, we will have
two standards for SRTP keying -- the IETF standard and the non-IETF
standard.  I do not consider that desirable.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 11 Nov 2007 20:31:42 -0800

...
> is crypto performed by the endpoint itself (as with DTLS-SRTP).

Tim mentioned to me privately that his posting to SIP is being held 
up; here is the content:

    From: Dwight, Timothy M (Tim) <[email-masked]>
    To: Eric Rescorla; Dan Wing
    Cc: IETF SIP List
    Subject: RE: [Sip] media-security-requirements and lawful intercept

    On point #1, 3GPP 33.106 says under "Security of Processes":

    "NWOs/APs/SvPs shall not be responsible for decrypting, or
    ensuring the LEA's ability to decrypt, any communication
    encrypted by a subscriber or customer, unless the encryption
    was provided by the NWOs/APs/SvPs and the NWOs/APs/SvPs
    possesses the information necessary to decrypt the
    communication or the NWOs/ APs/SvPs provides encryption keys
    but does not provide the encryption itself. In the case that
    the NWOs/ APs/SvPs provides encryption keys to the subscriber
    or customer but does not provide the encryption itself, the
    NWOs/ APs/SvPs shall provide the keys to the LEA if required
    by national regulations."

    The same text is found in ETSI TISPAN TS 133 106.

    tim

-d

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Sun, 11 Nov 2007 23:22:33 +0000

"NWOs/APs/SvPs shall not be responsible for decrypting, or ensuring the
LEA's ability to decrypt, any communication encrypted by a subscriber or
customer, unless the encryption was provided by the NWOs/APs/SvPs and
the NWOs/APs/SvPs possesses the information necessary to decrypt the
communication or the NWOs/ APs/SvPs provides encryption keys but does
not provide the encryption itself. In the case that the NWOs/ APs/SvPs
provides encryption keys to the subscriber or customer but does not
provide the encryption itself, the NWOs/ APs/SvPs shall provide the keys
to the LEA if required by national regulations."

tim

> Sent: Sunday, November 11, 2007 4:47 PM
> To: Dan Wing
> Cc: 'IETF SIP List'

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 12 Nov 2007 12:30:34 +0100

> I am aware of that technique; however, for SIP calls with the 
> offer in the in the Invite, you could only intercept outgoing 
> calls, because incoming calls cause your intercept target to 
> be the TLS client.  I don't believe that technique is viable 
> to meet R24.
> 
> I was not aware of that technique; thanks for the pointer.  
> That technique seems useful.
> 
> (Direct link,

This is an interesting paper, but doesn't it require also some form of
cooperating client (as required in draft-wing-sipping-srtp-key) as it
would be necessary to exchange at least one of the SSL libs of the
clients?

Ciao
	Steffen

> If 3GPP decides to use something other than DTLS-SRTP, we 
> will have two standards for SRTP keying -- the IETF standard 
> and the non-IETF standard.  I do not consider that desirable.
> 
> -d
> 
> 
> > -Ekr
> > 
> >

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Nov 2007 04:38:00 -0800

At Mon, 12 Nov 2007 12:30:34 +0100,
> would be necessary to exchange at least one of the SSL libs of the

I'm not aware of any technical mechanism for secure doing end-to-end
encryption of traffic that also allows key disclosure to some external
entity in the middle without modifying the client (SDESCRIPTIONS
doesn't require modification this because it's not e2e secure: it 
*always* discloses the key to an intermediary).

My point was not that one ought to pursue mechanisms allowed key
disclosure without modifying the client but that one could design
mechanisms that could be implemented solely in the client software
without explicitly modifying the wire protocol. This means that
clients (or, rather vendors) wish wish to enable key disclosure can do
so without any new protocol design work from IETF.

-Ekr

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 12 Nov 2007 14:05:02 +0100

> Sent: Monday, November 12, 2007 1:38 PM
> To: Fries, Steffen
> Cc: Dan Wing; Eric Rescorla; IETF SIP List
> I'm not aware of any technical mechanism for secure doing 
> end-to-end encryption of traffic that also allows key 
> disclosure to some external entity in the middle without 
> modifying the client (SDESCRIPTIONS doesn't require 
> modification this because it's not e2e secure: it
agreed

> My point was not that one ought to pursue mechanisms allowed 
> key disclosure without modifying the client but that one 
> could design mechanisms that could be implemented solely in 
> the client software without explicitly modifying the wire 
> protocol. This means that clients (or, rather vendors) wish 
> wish to enable key disclosure can do so without any new 
> protocol design work from IETF.
okay, understood. My fear here would merely be for the explicit case
with DTLS, that if the general functionality of DTLS is included as part
of the operating system, like it has been done in the past with SSL/TLS,
the key disclosure may become available for every application using this
library once somebody enabled key disclosure for one specific
application (taken the approach described in the paper you referenced).
If it is only an application specific functionality not influencing any
other application running on the host, I'm with you.

Steffen

---

From: Richard Barnes <[email-masked]>
Date: Mon, 12 Nov 2007 10:21:02 -0500

To paraphrase Tim / 33.106, the entities are only required to provide 
decryption in the following cases:

1. The encryption was provided by NWOs/APs/SvPs AND the NWOs/APs/SvPs 
possesses the information necessary to decrypt the communication.

2. NWOs/APs/SvPs provides the encryption keys but does not provide the 
encryption itself

It seems like neither of these is necessarily the case when the 
endpoints use an end-to-end secure key negotiation mechanism: Since the 
endpoints are agreeing on keys between themselves, you're never in case 
(2).  With regard to case (1), even if the provider builds the 
encryption system into the terminal, without some additional key 
disclosure mechanism, they won't have the information necessary to 
decrypt the communication.

So it doesn't seem like there's any technical issue at all, based on 
this requirement.  The service provider is just required to provide 
access to what he has access to, even if that's just encrypted traffic 
with no keys.

--Richard

---

From: Dean Willis <[email-masked]>
Date: Mon, 12 Nov 2007 18:14:37 -0600

> so without any new protocol design work from IETF.

That's true, unless they wish to do so using protocols that are  
controlled by the IETF.

For example, let's say we're talking about SIP phones. It's quite  
reasonable to consider using some part of SIP for the key disclosure,  
since SIP has already solved the how-to-find-the-endpoint-across-a- 
NAT problem, and since SIP already has lots of data-transport  
capabilities. One might be tempted to use a SIP EVENT package (under  
RFC 3325) to do this. But according to IETF procedure (RFC 3427),  
defining a SIP EVENT package requires an informational or standards  
track RFC.

So, the regulated operators now have to decide -- do they make their  
own fully-proprietary SIP extension in violation of the agreements we  
have with them about collaboration?

Or do they reinvent a large part of the SIP infrastructure as a new  
protocol in order to meet their requirements?

Once they've gone down either path, what's to keep them from going  
further down that path, resulting in protocol fragmentation and  
lesser value from the Internet?

We can't stop them from doing lawful intercept. We can help them do  
it in the least dangerous way possible. And we can stop (or at least  
delay) fragmentation of the protocol suite. But doing so requires  
some level of compromise of values many of us hold dear.

Personally, I'd be fairly by a show-of-unity that causes the IETF to  
conclude that LI via key disclosure is such a dangerous idea that we  
will neither help the other SDOs do it now allow them to document the  
so-doing using our protocols and extension registration facilities.

But before we make that decision, we need to understand the  
implications and impact of what we're deciding. This is non-trivial,  
and the repercussions will reach the furthest ends of the Internet,  
in both space and time.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Nov 2007 15:17:31 -0600

> standard.  I do not consider that desirable.

Why should crypto be different than the underlying protocol? The 
bifurcation between "IETF SIP" and "3GPP SIP" already exists in the market.

<http://www.nostrum.com/~adam/images/too-late.png>

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Nov 2007 14:24:47 +0100

>Why should crypto be different than the underlying protocol? 
>The bifurcation between "IETF SIP" and "3GPP SIP" already 
>exists in the market.
> 

I don't understand this "IETF SIP" versus "3GPP SIP" thing.

"3GPP SIP" is a SIP profile, including a number of SIP extensions, all
done in IETF. There is nothing which a non-3GPP entity can't use.

What is "IETF SIP"? What do I have to implement in order to be "IETF
SIP" compliant? RFC3261? RFC3261 plus each and every extension out
there?

Also, DTLS-SRTP is not the only mechanism defined in IETF for key
management. The 3GPP might come to a conclusion based on their
requirements that one of the other IETF mechanisms is better suited.
This would then also only be a profiling of IETF, and not diverge from
IETF.  

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Wed, 21 Nov 2007 08:18:22 -0600

> done in IETF. There is nothing which a non-3GPP entity can't use.

I said the bifurcation exists _in_ _the_ _market_. Did you follow the 
link I included? It's extraordinarily relevant. If you need more 
context: these are screenshots from the SIP account configuration 
screens on the Nokia E61:

We can argue over whether the split is real on the technical level (and there are several reasons that it is -- for example, using SigComp without proper signaling of the intention to do so ahead of time), but it's all a moot point: products are already being designed with two distinct modes of operation.

> SIP" compliant? RFC3261? RFC3261 plus each and every extension out

RFC 3261 plus proper negotiation of any extensions you choose to 
support. More emphatically: any behavior that is not in 3261 or its 
references needs to be explicitly negotiated before it is engaged. This 
applies to both clients and network servers.

Need something more clear-cut? Something you can apply empirically? 
Here's a litmus test for you: if the initial signaling between two 
network elements can't negotiate down to base SIP without any 
extensions, then it's no longer SIP.

/a

---

From: <[email-masked]>
Date: Thu, 22 Nov 2007 10:22:12 +0200

Hi,

Perhaps this thread is not worth continuing for long, so 
please feel free to cut it down, but there are a few

>extensions, then it's no longer SIP.

What you say above implies that if there is a NAT between those two
network elements so that the communication between those can only
be established with help of rport extension, then the result is
no longer SIP.

Well ... you could start arguing that there are extensions and
extensions ... but the bottom line is that the simplicity of
the test is lost with any exceptions. Unfortunately the world
is a bit complex to fit simple rules.

>references needs to be explicitly negotiated before it is 
>engaged. This applies to both clients and network servers.

Concept of dynamic negotiation is architecturally nice, but
unfortunately often undesirable in practical deployments.
The registration procedure between a full-fledged UA and a
typical SIP network deployment would look like this:

1. UA sends DHCPINFORM for SIP Option to find local SIP proxy
2. DCHP server answers that it has no value for SIP Option
3. UA sends OPTIONS request to SIP proxy resolved from the
   host part of the AOR
4. Proxy responds to OPTIONS and tells e.g. that it does not
   support sigcomp or sec-agree
5. UA sends REGISTER request without compression or requiring
   sec-agree, containing Require: outbound
6. Registrar responds with 420 Bad extension, Unsupported: Outbound
7. UA sends REGISTER again after removing extensions which
   the registrar did not support
8. Registrar responds with 401
9. UA sends REGISTER again with proper credentials
10. Reistrar responds with 200 OK
11. UA sends SUBCRIBE for reg-event
12. Network responds with 489 Bad Event (or in worst case loops
    the SUBSCRIBE back to the UA as it contains the AOR of the
    user as its Request-URI)

In practice the service provides most often do not want all 
this to happen but instead would like to configure the UAs
to suppress any extensions which the deployment does not support.

>We can argue over whether the split is real on the technical 
>level (and there are several reasons that it is -- for 
>example, using SigComp without proper signaling of the 
>intention to do so ahead of time), but it's all a moot point: 
>products are already being designed with two distinct modes of 
>operation.

Having working at Nokia I can give some perspective to the
design of this UI. Even if the E61 product is relatively new
the concept of the split was created a few years ago when the
world looked polarized like this:

3GPP was promoting IMS as a SIP profile, mandating extensions
like RFC 3310 (HTTP Digest AKA), RFC 3327 (Path) RFC 3329 (sec-agree),
RFC 3455 (P-headers), RFC 3489 (Compressing SIP), RFC 3608 (service
route)
and RFC 3680 (reg-event). This is a whole bunch of things to be
implemented, but the behaviour of the environment was supposed
to be quite deterministic.

IETF was promoting a toolbox approach for SIP so that service
providers were able to deploy any combination of extensions.
In practice however most of the deployments supported minimum
amount of extensions and there was a requirement for the UA
to cope with such deployments with minimal amount of config
settings and minimum amount of dynamic negotiation.

Thus the design team ended up with two modes, one for each
environment to control whether or not certain extensions
would be applied. The modes mostly defined some default
values, which thereafter could be separately changed with
the UI, but usage of a few extensions was hardcoded by the
mode.
----

Whether that design was good or bad is another subject of
discussion but with the knowledge of today it is clear that
the "SIP" world is not polarized between IETF and 3GPP but
fragmented to a number of different environments like:

- Every SIP service provider tends to define their own SIP
  profile which they wish the UAs to comply as close as possible
- Some providers even create their own proprietary extensions
  (like Yahoo for authentication)
- "Cellular IMS" like the original 3GPP IMS
- "CableLabs IMS" promoting new NAT traveral techniques to IMS
- "Fixed Broadband IMS" of ETSI TISPAN style
- "Early IMS" implementations supporting just a subset
   of extensions defined for 3GPP IMS
- and so on ...

Thus all this means that design of an SIP UA aiming to worldwide
coverage of different SIP-based deployments is an enormously
complex task. Autoconfiguration solutions would be highly
desirable to manage the complexity, but unfortunately for
that there is no unified solution: many VoIP providers
use TFTP or manual configuration while cellular IMS operators 
may rely on factory settings, OMA Device Management or OMA Client 
Provisioning and in IETF the SIP Configuration Framework is 
still on drawing board ...

Having a world with one unified "SIP" approach is a nice
dream, but unfortunately the reality is already far from
that and there are only some weak signs of convergence :(

Regards,

Erkki

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 22 Nov 2007 11:28:39 +0100

Hi,

><http://www.nostrum.com/~adam/images/too-late.png>

I did follow the link. My question was not directly towards you. It was
a more generic question, because this IETF SIP versus 3GPP SIP thing
comes up quite often.

>We can argue over whether the split is real on the technical level (and
there are several reasons that it is -- for example, using SigComp
without proper signaling of the intention to do so ahead of time), but
operation.

I think that SigComp is a special case. SigComp is needed when you
connect to IMS using certain access technologies (I don't think SigComp
is mandatory for all IMS access technologies), so you need to study what
the requirements are for those access technologies. It's not necessarily
something you negotiate in SIP - it's a "pre-condition".

>applies to both clients and network servers.

Just because you are able to negotiate it doesn't mean that you are able
to fulfill the requirements the operator has.

>extensions, then it's no longer SIP.

If that is true, everything would work with 3261, and we wouldn't need
any extensions...

There are reasons we have defined extensions, and way to require support
of them, and that is because they are needed in certain environements,
and for certain services, features and use-cases. That is nothing 3GPP
specific - anyone designing/deploying a SIP based network and services
may require certain extensions in order to make things work.

Regards,

Christer