Subject: RE: [Sip] The SIPSEC URI I-D

From: "Elwell, John" <[email-masked]>
Date: Thu, 22 Jun 2006 10:48:59 +0100

Paul,

Ironically, it is on calls to/from the PSTN where it will be most difficult
(probably impossible) to assert PSTN-SECURITY. We might determine this for
the local SIP hop from the caller/callee to the PSTN gateway. We have no
idea what happens beyond the PSTN, where there could be an unsecured IP hop.

John

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 21 June 2006 00:35
> To: Vijay K. Gurbani
> Cc: IETF SIP List
> Subject: Re: [Sip] The SIPSEC URI I-D
> 
> 
> 
> Vijay K. Gurbani wrote:
> > Paul Kyzivat wrote:
> >> Vijay,
> >>
> >> Thanks for taking the first step!
> > 
> > Paul: Thanks for a reading of the draft!
> > 
> >> 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 can't say you are wrong; but other environments (P2P?) may find
> > the requirements a bit more attractive.
> > 
> >> 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)
> > 
> > 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.
> 
> 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
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Thu, 22 Jun 2006 11:21:50 -0400

> idea what happens beyond the PSTN, where there could be an unsecured IP hop.

Well, I don't know much (if anything) about the details of the PSTN 
network. My impression is that, often, it provides better security than 
IP over the internet, that is provided by transitive trust over parties 
that must be vetted in some way to be connected.

One hole in that (I suppose there are many) is that the PSTN currently 
does allow PSTN interconnect with VoIP systems that may have no security 
at all.

So maybe the security of the PSTN is in fact the same as INSECURE. If 
so, there may still be a place for a transitive trust level of security 
that has some legal teeth behind it.

	Paul