headers
Rohan Mahy | 1 Jun 2006 01:14
Picon

Re: Wacky thead of the month award goes to ... Re: draft-audet-sip-sips-guidelines: Meaning of sips

Michael,

You seem to have a mistaken impression that transport=tls means
something it does not/is actually useful.  Unfortunately,
transport=tls only affects the next hop, it interferes with NAPTR
selection of the actual underlying transport (TCP, UDP, SCTP, DCCP),
it looks really ugly in URIs, and it is a pain in the arse to enter on
a phone keypad.

I don't really believe the last two are a big deal, but the important
thing here is that sips: has the semantics that most folks think
transport=tls should have, but transport=tls actually does not have.

thanks,
-rohan

On 5/30/06, Michael Thomas <mat <at> cisco.com> wrote:
> Vijay K. Gurbani wrote:
>
> > Michael Thomas wrote:
> >
> >> My question is whether it's answer to _any_ problem. My last attempt at
> >> getting and answer was fruitless. What attacks do SIPS thwart in real
> >> life
> >> that honest operators and transport=tls doesn't? Real life good guy,
> >> bad guy situations would be helpful.
> >
> >
> > Sorry -- catching up after a forced, and not entirely un-welcome,
> > lull introduced by the weekend.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rohan Mahy | 1 Jun 2006 01:16
Picon

Re: Wacky thead of the month award goes to ... Re: draft-audet-sip-sips-guidelines: Meaning of sips

On the contrary Juha, the SIP server role can indicate it wants to the
client to use TLS by including the appropriate NATPR and/or SRV
records.

thanks,
-rohan

On 5/30/06, Juha Heinanen <jh <at> tutpro.com> wrote:
> Vijay K. Gurbani writes:
>
>  > A couple more: sips provides confidentiality of traffic
>  > and authentication of a proxy and registrar to a UAC.  Admittedly,
>  > one could do this with transport=tls, but this particular
>  > construct is deprecated in rfc3261.
>
> transport=tls is used in practise, because no other ways exist to tell
> that tls is to be used on the next hop.  there is thus still need for it
> and sips is not a replacement due to its end-to-end nature.
>
> -- juha
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sipping <at> ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
(Continue reading)

Permalink | Reply | 1 comment |
headers
Francois Audet | 1 Jun 2006 01:27
Favicon

RE: Wacky thead of the month award goes to ... Re: draft-audet-sip-sips-guidelines: Meaning of sips

I like it too, but I prefer 4 to 3, because 3 is too fuzzy to me, and it
has
been a source of confusion to many.

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com] 
> Sent: Wednesday, May 31, 2006 07:42
> To: Dean Willis
> Cc: Sip; Michael Thomas; Vijay K. Gurbani
> Subject: Re: Wacky thead of the month award goes to ... 
> Re:[Sip] draft-audet-sip-sips-guidelines: Meaning of sips
> 
> 
> Dean,
> 
> I really like your characterization of the alternatives here!
> 
> More below.
> 
> 	Paul
> 
> Dean Willis wrote:
> > 
> > On May 30, 2006, at 5:44 PM, Michael Thomas wrote:
> >>>
> >>> Dean has pointed out one answer to this; namely, "reduces the 
> >>> probability of an accidental downgrade by intermediate proxies 
> >>> between the UAC and the proxy responsible for the AOR, if those 
> >>> proxies bother to honor it."
> >>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francois Audet | 1 Jun 2006 01:28
Favicon

RE: Wacky thead of the month award goes to ... Re: draft-audet-sip-sips-guidelines: Meaning of sips

Yes, that does make a lot of sense to me.

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com] 
> Sent: Wednesday, May 31, 2006 07:49
> To: Dean Willis
> Cc: Cullen Jennings; Sip
> Subject: Re: Wacky thead of the month award goes to ... 
> Re:[Sip] draft-audet-sip-sips-guidelines: Meaning of sips
> 
> 
> Dean - you were on a roll yesterday. Again I violently agree.
> 
> Perhaps we need both SIPS and Proxy-Require:link-security. Then the 
> meaning of sips could be simplified. The sips is an indication of the 
> target's expectation, while the Proxy-Require is the caller's 
> expectation. The first node to place a sips URI into the R-URI would 
> also add the Proxy-Require, in order to honor the target's desires. 
> Proxies otherwise would simply honor the Proxy-Require. But the 
> Proxy-Require could also be used with tel or sip if that is what the 
> caller desires.
> 
> 	Paul
> 
> Dean Willis wrote:
> > 
> > On May 30, 2006, at 12:02 AM, Cullen Jennings wrote:
> >>
> >> I think that at the high level, the semantics of sips are 
> simple. We
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Thomas | 1 Jun 2006 01:38
Picon
Favicon

Re: Wacky thead of the month award goes to ... Re: draft-audet-sip-sips-guidelines: Meaning of sips

You're undoubtably right -- I've been wondering about this -- so let me 
say that
my problem is with anything that supposedly dictates security beyond 
what the
next hop is but cannot be verified by the would be dictator.

Barring end to end security of some form, anything that purports to 
elevate the
authenticity and/or confidentiality of the signaling is bound to be 
misinterpretred,
and that's what sips real sin is. If this is really a BCP -- which I'm 
becoming
convinced is the only way to reasonably sell -- not oversell -- this 
desire, then
we should work in that direction. Signaling for security that one has no 
means
of verifying is just plain dumb.

       Mike

Rohan Mahy wrote:

> Michael,
>
> You seem to have a mistaken impression that transport=tls means
> something it does not/is actually useful.  Unfortunately,
> transport=tls only affects the next hop, it interferes with NAPTR
> selection of the actual underlying transport (TCP, UDP, SCTP, DCCP),
> it looks really ugly in URIs, and it is a pain in the arse to enter on
> a phone keypad.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Cullen Jennings | 1 Jun 2006 06:57
Picon
Favicon
Gravatar

Re: Wacky thead of the month award goes to ... Re: draft-audet-sip-sips-guidelines: Meaning of sips


Excellent question (definitely falls in my not wacky category)

On May 30, 2006, at 6:17 AM, Michael Thomas wrote:

> Cullen Jennings wrote:
>
>> sips is not the answer to every problem.
>
> My question is whether it's answer to _any_ problem. My last  
> attempt at
> getting and answer was fruitless. What attacks do SIPS thwart in  
> real life
> that honest operators and transport=tls doesn't? Real life good  
> guy, bad guy
> situations would be helpful.
>
>       Mike

I agree with your comment that as long as people can't say what they  
are trying to accomplish, saying sips does or does not meet that is  
pretty meaningless.

The problem with transport=tls is that it only applies to one hop and  
has no semantics that it get applied to the retarget. If it did, then  
it would mean about the same as sips.

I think it is fairly clear there are cases where you want to make  
sure each hop is confidential protected and it is reasonable to trust  
the proxies. Let me provide a simple example. In several cases we end
(Continue reading)

Permalink | Reply | 1 comment |
headers
Cullen Jennings | 1 Jun 2006 07:00
Picon
Favicon
Gravatar

Re: Wacky thead of the month award goes to ... Re: draft-audet-sip-sips-guidelines: Meaning of sips


This suggestion is certainly not in the wacky category so my  
apologies for the subject line :-)

What you are suggesting here may have possibly been a much better  
design than what we have. There would be several advantages (like  
being able to specify more about the level of protection).

The issues with it were that we were passing URI around between  
things. Take a REFER for example - now I suppose that you could embed  
the requires into the URI but in practice theses don't get processed.  
A contact getting copied out of one dialog and into some new dialog.  
A subscribe that sets up a notify. There are many examples. There was  
also the questions of what level of granularity we needed to be able  
to describe the level of protection. I think the feeling at the time  
was that one very rough cut (reduced to a single bit) could work for  
many things given the transitive trust assumptions that were  
intrinsic in any security based on hop by hop.

The questions we are at now is, given the choices we made, would it  
be possible to even change this. The backwards compatibility issues  
are not so much the places were we did something specific for a URL  
but all the places that we allowed URL to be copied we would need to  
think about how the protection parameters associated with them got  
copied.

I'm not saying that this path is not worth thinking about it -  
perhaps we can figure something out along these lines.

On May 30, 2006, at 4:04 AM, Christer Holmberg ((JO/LMF)) wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cullen Jennings | 1 Jun 2006 07:00
Picon
Favicon
Gravatar

Re: Wacky thead of the month award goes to ... Re: draft-audet-sip-sips-guidelines: Meaning of sips


On May 30, 2006, at 2:35 PM, Dean Willis wrote:

> On May 30, 2006, at 12:02 AM, Cullen Jennings wrote:
>>
>> I think that at the high level, the semantics of sips are simple.  
>> We want it to mean that every hop from the UAC to the UAS was  
>> integrity and confidentiality protected at a reasonable level  
>> assuming transitive trust. This can be very useful. At the more  
>> fine details level, we have some parts that are unclear in how to  
>> implement it, we probably have some bugs in the spec, and perhaps  
>> we even one place where we made a bad choice that we may correct.  
>> I'm very keen on this draft - I want it to try and sort out the  
>> details that are missing or wrong.
>>
>
>
> "Correcting" the "bad choice" in the proposed way would be counter  
> to the semantics you give above.
>
> It's been proposed that we should change RFC 3261 to require that,  
> if sips: is used, then TLS MUST be used on all hops. This runs  
> afoul of architectures where some other mechanism, notably IPSEC,  
> is used on some hops.
>
> If we make this proposal a requirement, we end up in in a situation  
> where we frequently cannot use sips: on the UAC to serving-proxy  
> hops because some other security mechanism is used on the back side  
> of the serving proxy. And since sips: is the only "please secure  
> me" indicator we have, this means that we have no way to request
(Continue reading)

Permalink | Reply | 6 comments |
headers
Cullen Jennings | 1 Jun 2006 07:01
Picon
Favicon
Gravatar

Re: Wacky thead of the month award goes to ... Re:


I certainly agree we need to deal with some end to end problem - the  
raisec mailing list and several other WGs are trying to figure out  
ways to make the keying of SRTP media work. I will point out that in  
3261, the solution for end to end is not sips but is S/MIME. We have  
been trying to deal with issues around S/MIME for a long time. Part  
of this has focused on making certificate management easier and  
cheaper. The Identity work has provided close to end end type  
integrity without S/MIME. We have been looking at SAML for certain  
types of assertions. We defined AIB for certain types of end to end  
assertions.

On May 30, 2006, at 7:24 AM, fwmiller <at> cornfed.com wrote:

>
>
> This is a nice encapsulation of the capabilities that are there.   
> While I agree that depracating sips is probably not useful, its  
> also clear IMHO that something needs to be put in place to allow  
> for end-to-end secure signaling.  If sips can be morphed simply to  
> do that then lets do it.  If it can't, lets forget about sips and  
> figure out a way to solve the end-to-end problem.
>
> The end-to-end problem is hard given the basic architecture of SIP  
> but is also the problem that once solved will really boost the  
> usefulness of SIP in general, again, IMHO.
>
> FM
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cullen Jennings | 1 Jun 2006 07:01
Picon
Favicon
Gravatar

Re: Wacky thead of the month award goes to ... Re: draft-audet-sip-sips-guidelines: Meaning of sips

this reply is not really all that relevant, I don't know why I am  
sending it but I will :-)

On May 30, 2006, at 2:35 PM, Dean Willis wrote:

> But in any case, sips: remains only a marginal indicator of  
> security. It's kind of like a note by the door of the office that  
> says "Last one out, please lock the door". If somebody forgets, or  
> choses not to, the door isn't locked, and nobody else knows.

Most security is only as strong as the weakest link and often no one  
knows when the weakest link has failed. I don't know why you use the  
word "indicator", if we think that sips is somehow a indicator to end  
users that they get something like an end users might think of as  
"secure", then clearly sips does not provide that.

> It's not the lack of security that gets me -- it's the lack of  
> KNOWING that there is no security. Our current usage of sips: is no  
> more secure and generally applicable to the Internet than the trust- 
> domain protections around the privacy of P-Asserted-Identity are,  
> and we made that a P-header.

I think there are some significant differences here. RFC 3325  
requires that you have contracts between two parties that are using  
this (the SPEC(T)) or you can be in violation of privacy laws in  
several countries. There is no case where you need a contract between  
two domains doing sips. It true that you can only trust things in so  
much you trust the person you contact. That is the nature of  
communications - just because you can perfectly encrypt your email to  
me does not mean I don't print it out and pin it the bathroom wall.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane