Subject: [Sip] The SIPSEC URI I-D

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 19 Jun 2006 09:32:56 -0500

Folks: Based on the "wacky thread with the hopping bunny"
discussions, an I-D has been submitted on the SIPSEC URI.  Until
it appears in the archives, you can grab a copy from:

http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-sipsec-00.txt
http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-sipsec-00.html

Comments and feedback welcome.

Thank you.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jun 2006 20:12:49 -0400

Vijay,

Thanks for taking the first step!

My first comment is that I question whether the requirements you have 
proposed are the right ones. While they might be sufficient, I suspect 
that in many environments a solution meeting those requirements will be 
unacceptable. I suspect that a less ambitious set of requirements may 
still be a useful improvement over the current state of affairs and be 
more widely implementable.

Specifically, a guarantee that depends on hop-by-hop trust may be quite 
acceptable if it at least guarantees:
- nobody but the endpoints and intermediaries on the signaling path
   can see the signaling
- nobody but the endpoints and intermediaries on the signaling path
   have the keys to the media
(Both assuming you trust the intermediaries)

This is (just a little) more than SIPS. But I think it is comparable to 
what is available from the PSTN, and so could be advertised as "just as 
good".

Going back to your proposals, I was thinking maybe your SIPSEC URI 
scheme might just be used as the contact in a target refresh request. I 
think that would solve a number of the problems, though perhaps 
introducing some new ones. Used this way, a session would be established 
normally and then a reINVITE or UPDATE used to negotiate an e2e secure 
signaling session. Then the keys for a media session would be exchanged.

This would perhaps normally be opportunistic. If required then 
callerprefs could be used to exclude those that can't or don't want to play.

The caller could make a normal, insecure, offer. If the answerer wants 
security, it could accept the request but refuse all the media. Once the 
session is established, one side would send a target refresh using 
SIPSEC, (or maybe SIPS would be enough here). In that exchange the 
media, including keys, would be negotiated.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 20 Jun 2006 16:52:54 -0500

> Thanks for taking the first step!

Paul: Thanks for a reading of the draft!

> unacceptable. 

I can't say you are wrong; but other environments (P2P?) may find
the requirements a bit more attractive.

> (Both assuming you trust the intermediaries)

I thought that trusting the intermediaries was the basic problem,
since nothing short of an end-to-end cert exchange would suffice.
As the draft now states, the intermediaries are used to rendezvous,
but then they become conduits to opaque information flowing between
the endpoints.

> callerprefs could be used to exclude those that can't or don't want to 

Right.

> media, including keys, would be negotiated.

Right.

Thanks, Paul.

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Jun 2006 19:35:16 -0400

Vijay K. Gurbani wrote:
>> that in many environments a solution meeting those requirements will 
>> be unacceptable. 
> 
>> Specifically, a guarantee that depends on hop-by-hop trust may be 
>> quite acceptable if it at least guarantees:

Well, in retrospect, its obvious we can't talk about whether these 
requirements are correct or not. There may be different sets of correct 
requirements.

Your requirements are stronger than what I was suggesting. In a perfect 
world I would rather have a system built to your requirements.

The current status quo is considerably worse than relying on trusted 
intermediaries. I would rather have have a lesser set of requirements 
that actually get implemented on the systems that people use. E.g. I 
would like something that gets implemented on Vonage and its cousins, 
and IMS and its cousins. Anything that gets implemented as a replacement 
for "regular phone service". If it is "as good as" the security of 
"regular phone service" then it is a big improvement over what we have now.

After I responded the other day I was thinking that one thing we lack is 
some concrete use cases to measure this against. Here are some initial 
thoughts on that:

- There exist a set (one or more) copywrited/branded icons corresponding
   to various levels of security. Each has a thorough specification of
   what guarantees that particular icon denotes.

- devices / software loads for devices are certified for the right to
   display one of these icons. To achieve certification the device must
   have been verified that it follows the appropriate specifications.

- when a user originates or terminates a call, the device displays
   a security icon iff the call conforms to the corresponding spec.

- some devices may be configurable to accept a call only if the call
   will conform to particular security specifications.

- some devices may be configurable to only complete a call it
   originates if the call will conform to a particular security spec.
   (Ideally the call will only be offered to those that can conform.)

That is all very generic. Based on a framework like that we can then 
discuss what particular security specifications make sense, and how many 
of them it makes sense for there to be for general use. I am having 
difficulty imagining more than three levels being useful, and even three 
is a stretch:

- SECURE

   You know for certain the identity you are connected to
   (though it might not be who you thought you were calling.)
   Not even the NSA can tap your call.

- PSTN-SECURITY

   You are assured that your device, in conjunction with
   others, performed due diligence (documented) in determining
   the identity displayed (if any) for the connected party.
   Your provider and its trusted peers, most likely including
   legal authorities, may intervene and tap. They are legally
   bound regarding what they will do.
   There is assurance that others cannot intervene tap your call.

- INSECURITY

   You can count on no security at all.
   (This is what a lot of SIP calls provide today.)

If PSTN-SECURITY began to be offered, people would likely start to ask 
why a system doesn't always offer something at least that good. The only 
answers that would hold much water are:
- not our fault. we can do better if the other end can.
- this is cheap (i.e. free) and you get what you pay for

I expect PSTN-SECURITY would become the low bar, at least for any paid 
service. And as long as many calls have one end in the PSTN, there will 
be many that can't do better than that, so it is an important level of 
security to offer. SECURE then can become a premium service.

	Paul