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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 23 Jun 2006 19:48:59 +0100

(as chair)

WG document has been issued as http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-00.txt

We are currently updating the charter with new dates, which look like they should be the end of 2007, given the significant amount of work to be done.

regards

Keith

> -----Original Message-----
> From: Samir Srivastava [mailto:[email-masked]]
> Sent: 23 June 2006 18:55
> To: Michael Hammer (mhammer); Paul Kyzivat (pkyzivat); Elwell, John
> Cc: IETF SIP List; Vijay K. Gurbani
> Subject: RE: [Sip] The SIPSEC URI I-D
> 
> 
<snip>

> What is happening on SAML. There was group hum, and then people were
> saying that we don't have problem. What is the current status 
> on that.. 
> 
<snip>
> 
> Thx
> Samir
> 
>  
> 
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[email-masked]] 
> Sent: Thursday, June 22, 2006 9:52 AM
> To: Paul Kyzivat (pkyzivat); Elwell, John
> Cc: IETF SIP List; Vijay K. Gurbani
> Subject: RE: [Sip] The SIPSEC URI I-D
> 
> But, if there were such thing as a PSTN-SECURITY defined for IP, then
> PSTNs would then require that as part of connecting to the 
> legacy PSTN.
> 
> These sort of arguments can be self-fulfilling prophecies.
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat (pkyzivat)
> > Sent: Thursday, June 22, 2006 11:22 AM
> > To: Elwell, John
> > Cc: IETF SIP List; Vijay K. Gurbani
> > Subject: Re: [Sip] The SIPSEC URI I-D
> > 
> > 
> > 
> > Elwell, John wrote:
> > > 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.
> > 
> > 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
> > 
> > > 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
> > > 
> > 
> > _______________________________________________
> > 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
> 
> _______________________________________________
> 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