Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips

From: "Francois Audet" <[email-masked]>
Date: Wed, 17 May 2006 17:50:21 -0500

I agree with Dean.

To me, using sips in Req-URI tells proxies forward the request on every
hop using TLS.

Receiving sips actually doesn't really tell you much, and you certainly
can't
extrapolate that "the call was secure".

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Wednesday, May 17, 2006 15:35
> To: Paul Kyzivat
> Cc: Audet, Francois [SC100:3055:EXCH]; IETF SIP List
> Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips
> 
> 
> 
> On May 17, 2006, at 4:35 PM, Paul Kyzivat wrote:
> 
> >
> > I guess if we know every hop uses SIPS, it means that we
> > transitively know that the callee has been verified to be who he  
> > claims to be, whoever that is. Is that enough?
> >
> 
> Nope. can't make that assertion. A UAC can establish 
> single-ended TLS  
> to a server that might not bother to do secondary 
> authentication, but  
> still be completely requirement with "TLS was used at every hop".
> 
> 
> > I thought that security of the session is an essential property of
> > SIPS - that if I use SIPS I can then safely do something like  
> > exchange media keys using sdescriptions. If that is a goal, 
> then we  
> > need to find a way for use of SIPS to provide that guarantee. That  
> > may or may not require use of TLS at every hop.
> 
> If the sdescriptions are revealed to every intervening proxy, 
> I don't  
> think you have much in the way of security. A proxy can be  
> identifiable (via TLS assertion) without being trustworthy.
> 
> --
> Dean
> 
> 
> 
> 

_______________________________________________
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: Wed, 17 May 2006 19:32:49 -0400

Based on what I am hearing, it seem like the best course might be to 
deprecate SIPS and begin work on something else that provides some 
useful security properties.

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 18 May 2006 09:23:16 +0300

> useful security properties.

exactly, juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 May 2006 23:37:14 -0400

Well, before we go and deprecate stuff let us not make the perfect the 
enemy of the good.

Yes, as Dean and others have pointed out, sips makes the assumption that 
all of the proxies along the path are "good", and that they have 
followed the rules about sips treatment. There is no dispute that this 
does NOT protect against attacks where the proxies are malicious and 
choose to ignore sips.

However, I will assert that ther type. I can't see 
any case where it would only accept sip and not sips. I can imagine 
cases (secure phone service) where it would only accept sips. However, 
as Juha points out in his mail, it can simply reject an incoming call 
which was received over sip. All your proposal does is push that 
rejection into the network. For what benefit?

-Jonathan R.

-- 
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 May 2006 23:37:14 -0400

However, I will assert that there are a lot of environments where it is 
a reasonable assumption to make that you are trusting the proxies. 
Remember, proper SIP operations depends on some level of trust on the 
proxies. For most deployments, I would assert that there is no reason 
that a proxy would properly perform normal SIP processing (forwarding of 
requests and so on), yet not honor sips for some malicious reason.

So, sure - there are some number of small cases where the security 
provided by sips is not sufficient because of an oddball trust 
relationship with the provider. If your enviroment is not such an 
environment, then sips isnt good enough and you'll need to use S/MIME. 
But S/MIME is a whole lot harder to deploy as we know, and I don't want 
to make that the ONLY choice.

*Assuming* you trust the proxies to obey sips, sips provides a lot of 
nice security properties. It protects me against outside attackers from 
pretty much doing anything - modifying calls, hijacking calls, detecting 
call patterns, and so on. I think thats worth preserving.

Thanks,
Jonathan R.

re are a lot of environments where it is 
a reasonable assumption to make that you are trusting the proxies. 
Remember, proper SIP operations depends on some level of trust on the 
proxies. For most deployments, I would assert that there is no reason 
that a proxy would properly perform normal SIP processing (forwarding of 
requests and so on), yet not honor sips for some malicious reason.

So, sure - there are some number of small cases where the security 
provided by sips is not sufficient because of an oddball trust 
relationship with the provider. If your enviroment is not such an 
environment, then sips isnt good enough and you'll need to use S/MIME. 
But S/MIME is a whole lot harder to deploy as we know, and I don't want 
to make that the ONLY choice.

*Assuming* you trust the proxies to obey sips, sips provides a lot of 
nice security properties. It protects me against outside attackers from 
pretty much doing anything - modifying calls, hijacking calls, detecting 
call patterns, and so on. I think thats worth preserving.

Thanks,
Jonathan R.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 May 2006 07:48:37 -0700

Part of the problem is that SIPS is being oversold as somehow similiar 
to https. It
simply is not in any way equivalent for the vast majority of https 
traffic. That alone
is a big problem, IMO, and we've had plenty of confusion on this list to 
amply
demonstrate the dangers of the oversell.

Second, I don't buy your assertion that there's some reason I should 
"trust" proxies,
and most especially when they cross domain boundaries -- and most doubly 
especially
when they cross into a service provider boundary. This is hardly black 
helicopter
paranoia at this point. It's these supposedly disinterested third 
parties that are a real
security danger, and SIP needs to deal with them. Saying that S/MIME is 
the answer
is not very satisfying because S/MIME has *no* deployment, nor does 
there seem
to be any movement toward it.

What it seems to me that is needed is getting back to the end to end 
principle, or
as end to end as is practicable. If you use intermediate and untrusted 
proxies for
routing, use the routing to get there, but start up a direct 
conversation with the
UAS ideally, or a UAS delegated proxy if necessary. And don't send keys and
other goodies until you've done that. _That_ might qualify as SIPS, but 
what
you have now is dangerously misleading.

       Mike

Jonathan Rosenberg wrote:

> Yes, as Dean and others have pointed out, sips makes the assumption 
> that all of the proxies along the path are "good", and that they have 
> However, I will assert that there are a lot of environments where it 
> is a reasonable assumption to make that you are trusting the proxies. 
> that a proxy would properly perform normal SIP processing (forwarding 
> of requests and so on), yet not honor sips for some malicious reason.
>
> But S/MIME is a whole lot harder to deploy as we know, and I don't 
> want to make that the ONLY choice.
>
> nice security properties. It protects me against outside attackers 
> from pretty much doing anything - modifying calls, hijacking calls, 
> detecting call patterns, and so on. I think thats worth preserving.
>
> Thanks,
> Jonathan R.
>
> Juha Heinanen wrote:
>
>> Paul Kyzivat writes:
>>
>>  > Based on what I am hearing, it seem like the best course might be 
>> to  > deprecate SIPS and begin work on something else that provides 
>> some  > useful security properties.
>>
>> exactly, juha
>>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 19 May 2006 12:26:06 -0500

I agree completely with Jonathan on this one.

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Thursday, May 18, 2006 20:37
> To: Juha Heinanen
> Cc: Paul Kyzivat; IETF SIP List; Audet, Francois 
> [SC100:3055:EXCH]; Dean Willis
> > to
> > Use [email-masked] for questions on 
> current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> 
> --

---

From: Dean Willis <[email-masked]>
Date: Fri, 19 May 2006 18:58:35 -0500

On May 18, 2006, at 10:37 PM, Jonathan Rosenberg wrote:

> Well, before we go and deprecate stuff let us not make the perfect  
> the enemy of the good.
>
> that all of the proxies along the path are "good", and that they  
> have followed the rules about sips treatment. There is no dispute  
> that this does NOT protect against attacks where the proxies are  
> malicious and choose to ignore sips.
>
> However, I will assert that there are a lot of environments where  
> it is a reasonable assumption to make that you are trusting the  
> proxies. Remember, proper SIP operations depends on some level of  
> trust on the proxies. For most deployments, I would assert that  
> there is no reason that a proxy would properly perform normal SIP  
> processing (forwarding of requests and so on), yet not honor sips  
> for some malicious reason.
>
> environment, then sips isnt good enough and you'll need to use S/ 
> MIME. But S/MIME is a whole lot harder to deploy as we know, and I  
> don't want to make that the ONLY choice.
>
> *Assuming* you trust the proxies to obey sips, sips provides a lot  
> of nice security properties. It protects me against outside  
> attackers from pretty much doing anything - modifying calls,  
> hijacking calls, detecting call patterns, and so on. I think thats  
> worth preserving.
>

I'm thinking about this from the perspective of P2P-SIP, where one  
reasonable use case is to make almost every user on the net a  
"proxy". I'd sure like to think that they could neither see nor  
twiddle my signaling as it passes through them.

But in any case, doing the "all compliant proxies MUST only forward  
SIPS request over TLS, or reject them" modifier still doesn't really  
help. I'd hope (haha) that any reasonable proxy would forward any  
traffic over a protected link if at all possible, and would only fall  
back to a non-protected link if thats all that was available. But the  
"tls only" thing prohibits IMS systems, which have reasonably robust  
security on the UA to P-CSCF link, from honoring SIPS requests at all  
-- thereby requiring use of plain SIP and degrading the effective  
security.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 20 May 2006 08:09:17 +0300

Dean Willis writes:

 > But the  

sorry, but you have wrong mailing list.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 May 2006 09:30:15 -0400

> call patterns, and so on. I think thats worth preserving.

So, what should use of SIPS promise, now can that promise be fullfilled, 
and what does that have to do with TLS?

In HTTPS, there is a guarantee that the target possess a cert tied to 
the URI. The analogous property for SIPS could be that the target 
possess a cert for the user&domain of the URI. Is that reasonable? 
Probably not. A UA that has registered probably won't have a cert for 
itself. Alternatively, the property could be that some server on the 
path holds a cert for the domain. That at least should be achievable, 
much like SIP Identity.

Then there is also an expectation of some kind of security and 
confidentiality for the signaling. In the case of HTTPS, TLS provides 
this. Because its end to end, its natural to tie the mechanism to the 
result. In the case of SIPS, since it typically isn't going to be e2e 
anyway, there isn't any great benefit to tying this goal to the 
mechanism. Since it is necessary to trust the intermediates to do the 
right thing to provide security and confidentiality, why isn't it 
reasonable to trust them to choose a mechanism as well? What is so 
special about TLS? This is reflected currently in 3261 by the option to 
use something other than TLS between the home proxy and the UAS. But I'm 
not clear why there is a restriction on the path from the UAC to the 
home proxy of the UAS. I think all that is important is that mechanisms 
that provide security and confidentiality be used, and that authority of 
the home proxy over the domain be validated.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 22 May 2006 10:18:00 -0500

> sorry, but you have wrong mailing list.

Excuse me? I suppose this is some sort of snide comment implying that  
we've been overrun by IMS worshippers again?

If IETF makes the change proposed by Jonathan (TLS must be end to  
end) it will have the side-effect of reducing the effective security  
available when talking from "new IETF SIP systems" to "existing IMS  
SIP systems". This may suggest that we consider alternatives.

We (the IETF) have formal relations with other bodies that consume or  
specs, like 3GPP. We can't go and change a specification in a way  
that pulls the rug under them without at least considering the  
implications. If you don't like it, take it up with the IESG and IAB  
and see if you can get the cooperation agreement retracted.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 22 May 2006 10:21:41 -0500

On May 22, 2006, at 8:30 AM, Paul Kyzivat wrote:

>
>
> So, what should use of SIPS promise, now can that promise be  
> fullfilled, and what does that have to do with TLS?
>
> In HTTPS, there is a guarantee that the target possess a cert tied  
> to the URI. The analogous property for SIPS could be that the  
> target possess a cert for the user&domain of the URI. Is that  
> reasonable? Probably not. A UA that has registered probably won't  
> have a cert for itself. Alternatively, the property could be that  
> some server on the path holds a cert for the domain. That at least  
> should be achievable, much like SIP Identity.

That second property -- that some server on the path holds a cert for  
the domain, is exactly the property we have now for sips as I  
understand it.

> confidentiality for the signaling. In the case of HTTPS, TLS  
> provides this. Because its end to end, its natural to tie the  
> mechanism to the result. In the case of SIPS, since it typically  
> isn't going to be e2e anyway, there isn't any great benefit to  
> tying this goal to the mechanism. Since it is necessary to trust  
> the intermediates to do the right thing to provide security and  
> confidentiality, why isn't it reasonable to trust them to choose a  
> mechanism as well? What is so special about TLS? This is reflected  
> currently in 3261 by the option to use something other than TLS  
> between the home proxy and the UAS. But I'm not clear why there is  
> a restriction on the path from the UAC to the home proxy of the  
> UAS. I think all that is important is that mechanisms that provide  
> security and confidentiality be used, and that authority of the  
> home proxy over the domain be validated.

I concur.

I would still like to have a mechanism that assures end-to-end and  
that the UAS holds a cert for the username/domain combo, but sips:  
isn't currently that mechanism.

--
Dean

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 22 May 2006 11:49:08 -0400

I admit I'm late to this discussion, but it seems to me that there is a
reasonable purpose to which sips can be put:

Provide assurance of a reasonable level of security between the caller
and the callee, unless one of the servers under control of either the
caller or the callee (or their agents, or organizations delegating their
domain names or certifying their certificates) has been subverted.

Specifically, it protects against passive packet sniffing to, let us
say, the 40-bit key level.

This seems to me to a minimal definition of a practically useful level
of security of this sort, and I can envision it being implemented,
though I can't enumerate all the details, and I can see the mechanism
activated by using a sips: request-URI.

But I can't see how security could be established in the reverse
direction, how the callee could have assurance that the call originated
from the From: URI.  And without that, I can't see how we could describe
what the sips mechanism guarantees in a way that is strong enough to be
practically useful, as the callee wouldn't know the set of server that
it is trusting.

But perhaps someone else has a solution to that problem.

Dale

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 22 May 2006 11:12:28 -0500

Dean Willis wrote:
[...]
> the domain, is exactly the property we have now for sips as I  
[...]
> I would still like to have a mechanism that assures end-to-end and  that 
> the UAS holds a cert for the username/domain combo, but sips:  isn't 
> currently that mechanism.

I have been capturing the traffic on this thread to summarize
in an updated sip-tls-use draft.  Besides the core meaning of
sips itself (which Francois' draft is handling), a fair amount
of traffic has been dedicated to the general drawbacks of using
TLS in SIP, why the same drawbacks may not exist for IMS, etc.
I will issue a new revision of the draft incorporating these
discussions before the Montreal IETF.

Thanks,

- 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: Aki Niemi <[email-masked]>
Date: Mon, 22 May 2006 21:17:17 +0300

> domain names or certifying their certificates) has been subverted.

But what is reasonable here anyway? Is it something that reasonably
allows me to show to a user a lock icon in a call dialog? I don't think
it is. At least not in the same way a lock icon is used in a browser.
(This is, even if trust for the domain's cert was achieved via
leap-of-faith, it's still secure.)

When would a user choose to use sips instead of sip? I can't think of a
usage where the assurance given by sips alone would meet the lock icon
test; however, TLS is usable in all of them. (For example, I read my
personal email over imaps, even though I'm fully aware none (or very
few) of the email is sent via TLS).

So given that sips as opposed to sip is above all else a strong
indication to the *human* user about security, anything less than e2e is
not going to cut it. So it doesn't matter how each hop of a hop-by-hop
path is secured, it's still not lockworthy for me.

To make sips really useful (again thinking of the lock icon here), and
given *real* security for a call requires that the media streams are
secure, then if anything, sips should mean secure media must be used.
But then that requires a whole lot more than requiring a specific
transport between SIP nodes.

Cheers,
Aki

---

From: Michael Thomas <[email-masked]>
Date: Mon, 22 May 2006 11:27:14 -0700

>path is secured, it's still not lockworthy for me.

Is it really intended for _direct_ human consumption? I sure hope not.

>transport between SIP nodes.

I don't really think this follows: the decision to put up the "lock" 
icon could
and probably should weigh a lot of factors, and it's not always going to 
yeild
the same result for all situtations. For example, when starting a 
"secure" session
for, oh say, the Kremlin to the Whitehouse, I'm pretty sure that nothing 
short
of S/MIME is going to do.

          Mike

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 22 May 2006 13:48:59 -0500

> the domain, is exactly the property we have now for sips as I 

Quite so.  At the Dallas IETF, Derek and I had a sidebar
conversation on TLS and SIP where he mentioned that we even
have cases where outbound is used to pin a sips URI without the
UA behind the proxy having a cert.

> help. [...] But the "tls only" thing prohibits IMS systems, which
> have reasonably robust security on the UA to P-CSCF link, from
> honoring SIPS requests at all -- thereby requiring use of plain SIP
> and degrading the effective security.

This is interesting; so you are in favor of keeping the last
hop behavior as specified in Section 26.2.2 of rfc3261?  But I
don't see the problem if on a P-CSCF -> UA link the security
property is downgraded to sip; the link is protected through
IPSec anyway.  Degrading the security property from sips to sip
on the UA -> P-CSCF link seems more of a concern, though.

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 May 2006 15:30:01 -0400

> Is it really intended for _direct_ human consumption? I sure hope not.

Probably not. It is indeed the hypothetical lock icon on the phone that 
is really going to matter.

> of S/MIME is going to do.

I suspect that the lock icon will be driven by policy in the UAs, and 
that in many cases will be coupled to the service provider policies.

In general nobody seems to know how to deploy a practical system that 
uses S/MIME as the mechanism for this. Some people (myself included) had 
been thinking (falsely it apparently turns out) that SIPS was at least 
part of the mechanism for providing that lock icon. (Also need media 
security, perhaps using sdescriptions over the secure signaling path.)

I think we need *some* mechanism that can provide the lock icon in 
plausible deployments.

	Paul

---

From: Michael Thomas <[email-masked]>
Date: Mon, 22 May 2006 12:49:33 -0700

Paul Kyzivat wrote:

> uses S/MIME as the mechanism for this. Some people (myself included) 
> had been thinking (falsely it apparently turns out) that SIPS was at 
> least part of the mechanism for providing that lock icon. (Also need 
> media security, perhaps using sdescriptions over the secure signaling 
> path.)

I'm afraid that this is "elephants all the way down". It's been a while 
since
I looked but AFAIK sdescriptions doesn't scale any better to clients, 
the basic problem
being interdomain credentials which scale to users in _any_ form.

> I think we need *some* mechanism that can provide the lock icon in 

Why? Seriously. Maybe the fallacy is that we're striving for a binary
value when reality wants it to be a scale. Or even that we show people
at all.

       Mike

---

From: Dean Willis <[email-masked]>
Date: Mon, 22 May 2006 17:23:06 -0500

On May 22, 2006, at 1:48 PM, Vijay K. Gurbani wrote:
> hop behavior as specified in Section 26.2.2 of rfc3261?

I believe so. If I recall correctly, that section was left in at my  
insistence during the final editing of RFC 3261.

> But I

But, as a caller, how do you KNOW it was protected by IPSEC? You at  
least have assurances (however meaningless) from RFC 3261 that it was  
TLS as far as the "proxy responsible for the AOR". You don't even  
have those vague (and probably meaningless) assertions from RFC 3261  
on the P-CSCF to UA link. Yes, you have other assertions "It's  
SUPPOSED to be IPSEC) from the IMS spec set, but we know nobody ever  
actually implements that stuff anyhow, right?

I maintain that until you have end to end knowledge of the  
protection, proven by a cert believed to you to be held by the far- 
end UA (or something equivalent), all you have is a warm feeling and  
not a believable indication of security

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 22 May 2006 18:10:58 -0500

That's section is actually not too bad. It specifically explains what
it means for the "last hop to be secure".

It's the other places in the document that are less obvious.

> Sent: Monday, May 22, 2006 15:23
> To: Vijay K. Gurbani
> Cc: IETF SIP List
> > This is interesting; so you are in favor of keeping the last hop 
> > behavior as specified in Section 26.2.2 of rfc3261?
> 
> > don't see the problem if on a P-CSCF -> UA link the 
> security property 
> > is downgraded to sip; the link is protected through IPSec anyway.  
> > Degrading the security property from sips to sip on the UA 
> -> P-CSCF 
> > link seems more of a concern, though.
> >
> 
> 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, 22 May 2006 19:12:34 -0400

> being interdomain credentials which scale to users in _any_ form.

As I understand it, once you have signaling secure enough to suit you, 
sdescriptions allows you to establish a media session that is more or 
less of equal security. I don't see why it has any scaling issues.

hop by hop security via providers, plus sdescriptions, would seem to 
give reasonable security from anybody who hasn't penetrated the provider 
  transitive trust network.

While I'd like to be secure from the guys (in white hats?) who get to 
decide which laws apply to them and tell the providers to give them 
everything, I'll settle for being protected from the rest of the bad 
guys, for now. Its better than all VoIP going out over the internet in 
the clear.

> value when reality wants it to be a scale. Or even that we show people

You mean like a lock icon in colors from red to green or something? How 
would you know how red or green to make it? I think that would just 
confuse people.

If we are not going to provide any indication of privacy, then why 
bother with things like TLS at all?

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 May 2006 18:53:35 -0700

Identity?

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 May 2006 18:53:29 -0700

On May 22, 2006, at 12:30 PM, Paul Kyzivat wrote:

> I suspect that the lock icon will be driven by policy in the UAs,  
> and that in many cases will be coupled to the service provider  
> policies.
>
> In general nobody seems to know how to deploy a practical system  
> that uses S/MIME as the mechanism for this. Some people (myself  
> included) had been thinking (falsely it apparently turns out) that  
> SIPS was at least part of the mechanism for providing that lock  
> icon. (Also need media security, perhaps using sdescriptions over  
> the secure signaling path.)
>

I think that is one of the topics this whole rtpsec list needs to  
figure out - what are *all* the parts one needs to get to this and  
what would it mean. Clearly sips by itself will not provide this -  
actually it is not clear that sips helps at all this this though it  
is useful for a bunch of other things like trying to make sure your  
INVITE is not misrouted.

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 23 May 2006 09:54:35 +0300

this discussion has clearly revealed that meaning of sips uri scheme is
not well defined in rfc3261 and that there exist wide confusion and
conflicting opinions about it.

as i mentioned earlier, sips was added to rfc3261 at the very last
minute, which clearly was a mistake.  sip working group must have guts
to admit it and act accordingly.

since there is no indication that an easy fix could exist, i therefore
propose deprecating sips uri scheme until it is well defined and can be
reintroduced.  this would be a big benefit to sip implementors.

-- juha

---

From: Aki Niemi <[email-masked]>
Date: Tue, 23 May 2006 11:01:54 +0300

> Is it really intended for _direct_ human consumption? I sure hope not.

I think directly in a sense that a user might need to make a decision
between two addresses in, say, a business card or a phonebook contact:

Tel (Internet): sip:[email-masked]
Tel (Internet, Secure): sips:[email-masked]

> of S/MIME is going to do.

Perhaps, but then again SIP identity, and MIKEY'd SRTP might suffice if
it was President Halonen from Helsinki calling the Whitehouse. ;)

Like Cullen pointed out, this may ultimately be something rtpsec needs
to address; in any case I think we agree hop-by-hop TLS alone is not
enough to call it sips or lockworthy.

Cheers,
Aki

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 24 May 2006 13:54:58 -0400

> conflicting opinions about it.

Possibly the only certain fact about sips!

> reintroduced.  this would be a big benefit to sip implementors.

That sounds like a good idea to me.  But can we retract that feature
from the market at this point?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 May 2006 14:06:18 -0400

>> reintroduced.  this would be a big benefit to sip implementors.

I proposed the same thing earlier in the thread. But after further 
discussion I think that is at least premature. I think there is still a 
possibility of keeping it and providing an adequate definition. (In 
other words, keep the name and replace everything else.)

But I think we are not yet close to an understanding of what an adequate 
definition would be.

> from the market at this point?

I'm far from sure what feature it is that we would be retracting. At 
best I imagine there are a bunch of distinct and non-interoperable 
features using the same scheme.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 24 May 2006 13:56:46 -0500

> features using the same scheme.

At the last SIP bakeoff, there were 73 distinct SIP implementations,
out of which 30 supported TLS.  As per the notes on TLS
implementation from the bakeoff, Robert wrote that:

   There was significant testing of TLS and SRTP. TLS
   interoperability  is solidifying.

So, at the very least SIP entities are increasingly supporting
TLS.  Whether or not they do the right thing -- whatever that may
be -- in the context of a sips scheme is a different thing.
The discussion to date appears to indicate that there exists
problems, the most severe of which appears to be the end-to-end
security semantics versus the hop-by-hop.

Thanks.

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 May 2006 16:30:12 -0400

I wasn't talking about problems with TLS. It is the "sips" semantics 
that are so ambiguous that I am doubtful we can even consider it a 
common feature. That was the point of Francois' work, which has served 
to expose how much difference of opinion there is. *Anything* we do to 
firm up SIPS is likely to break *all* the existing implementations of SIPS.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 24 May 2006 16:29:17 -0500

Paul Kyzivat wrote:
> common feature. That was the point of Francois' work, which has
> served to expose how much difference of opinion there is. *Anything*
> we do to firm up SIPS is likely to break *all* the existing
> implementations of SIPS.

Francois' work has indicated an ambiguity in sips, yes.  But I
don't think it's all downhill.  There are security properties that
folks are looking from sips that simply won't happen.  These
are things like magically showing a locked icon on a sips URI,
or sending sdescriptions end-to-end in a secure manner, or
mandating that all hops -- even the last hop -- be secured through
TLS.

But there are other problems that may be solveable.  For instance,
requiring proxies to redirect instead of recurse on being
presented with a sip URI when they started with a sips URI,
solidifying use of sips as an AoR, solving the mess of
registrations mentioned in Section 4 of Francois' draft, try to
close the upgrading gaps in Section 26.4.4 where an intermediary
upgrades a sip URI to a sips URI, thereby giving an illusion to
the UAS that TLS was used from beginning to end (the UAS could
look at the Via headers to figure that out, for instance),
maybe abolishing upgrading and downgrading completely, and
so on

And finally, implementers put TLS to support sips; thus when I
see that the number of TLS implementations are increasing at
the bakeoffs, and that TLS interoperability is solidifying,
that means to me that at least some aspects of sips are
well understood by the implementation community to solidify
this interoperability.  They could be as simple as ensuring
that all hops used TLS on seeing a sips URI as the next
hop URI.  It's the corner cases that we should pay attention to
and provide guidance on, or deprecate.  Not the sips scheme
itself.

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 May 2006 18:33:01 -0400

Vijay K. Gurbani wrote:
> But there are other problems that may be solveable. 
...

Yeah, maybe it will be possible to get to the point where, if none of 
the hops is lying, then it is known that all hops use TLS. And maybe 
that means you know with some certainty that you are connected to 
something that elements you (transitively) trust claim is authorized to 
act on behalf of the address you called.

But that is pretty much useless unless you can also be certain the media 
is connected to that same place.

Is that kind of connection sufficient to exchange SRTP media keys via 
sdescriptions, and then be confident that your media is securely and 
privately connected to whatever the target wants it to be connected to? 
(Again assuming that you trust all the intermediate hops to honor your 
wishes.)

*If* that is the case, then maybe it is worth doing and worthy of 
bestowing that lock icon. If that isn't the case, then I fail to see the 
point of doing it at all.

	Paul

> For instance,

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 24 May 2006 17:56:23 -0500

[...]
> point of doing it at all.

We should not claim that sips is capable of locking the icon.  We
should not claim that sips is capable of solving the prisoner's
dilemma problem; it is not.  It is not capable of an end-to-end
security model.  It will not work in an adverserial network
where no one trusts anyone else.

Correct me if I am wrong, but we did not design SIP to
work in a completely adverserial network.  We trust our proxies to
"do the right thing"  -- be that forking to multiple endpoints
or doing a transport conversion, or interfacing to the right
location server, or simply proxying our requests in a sane
manner.

But, assuming that we get beyond this blocking point, much
as we bestow trust in our proxies to do the right thing, I
don't see the harm in using sips in a hop-by-hop security
model *as long as we enunciate what the drawbacks are*.  What
has been missing thus far has been the notion of where
does sips and TLS help and where they don't.  The last set
of drafts coming out on this subject has, at the very least,
shed some light on this.

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 May 2006 19:33:23 -0400

Vijay K. Gurbani wrote:
>> something that elements you (transitively) trust claim is authorized 
>> to act on behalf of the address you called.
> [...]
>> bestowing that lock icon. If that isn't the case, then I fail to see 
>> the point of doing it at all.
> 

I think we may be on almost the same page.

I agree that trust in the proxies is reasonable in many environments. I 
suspect I am more willing than you are to bestow the lock icon in such a 
situation.

> model *as long as we enunciate what the drawbacks are*. 

I agree. But here I go a little further. It must be possible to boil 
this down into something (e.g. the lock icon) that can be communicated 
to the end user, and understood. If the system sometimes establishes 
calls with SIPS, and other times with SIP, there is no benefit unless 
there is a perceptible difference to the user. If the user gets no 
benefit from SIPS, then why bother with it.

I can only see a few benefits to the user that are worth the trouble:

- a guarantee that they are talking to the intended target
- a guarantee that nobody other than the other party in the call
   has access to the media. (Well, maybe we also have to also
   allow the network operator(s), their agents, and government
   agencies access.)

I would be inclined to use the lock icon when both of the above hold. 
I'm not sure there is enough value in telling the user about the first 
if the second doesn't hold to confuse the issue by having two levels of 
security.

The downside of course is that if you start telling users they sometimes 
get these benefits then they will ask why they don't *always* get them.

> What

The meaning of the security indicator does need to be clearly explained 
to users. If it is, and if the property it provides is indeed a valuable 
one, then it will be worthwhile.

Having a well defined meaning for SIPS is also important, if it is a 
stepping stone to the bigger goal. If a meaning is chosen that doesn't 
help provide something helpful to the user then we might as well not bother.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 24 May 2006 20:05:19 -0500

I agree with what Vijay is saying.

Deprecating sips will do no good.

We just need to explain what sips means (and doesn't mean).

And, yes, it does NOT mean a reliable lock icon. If we need a lock
icon, that's something different.

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: Wednesday, May 24, 2006 15:56
> To: Paul Kyzivat
> Cc: Sip
> We should not claim that sips is capable of locking the icon. 
>  We should not claim that sips is capable of solving the 
> prisoner's dilemma problem; it is not.  It is not capable of 
> an end-to-end security model.  It will not work in an 
> adverserial network where no one trusts anyone else.
> 
> work in a completely adverserial network.  We trust our 
> proxies to "do the right thing"  -- be that forking to 
> multiple endpoints or doing a transport conversion, or 
> interfacing to the right location server, or simply proxying 
> our requests in a sane manner.
> 
> has been missing thus far has been the notion of where does 
> sips and TLS help and where they don't.  The last set of 
> drafts coming out on this subject has, at the very least, 
> shed some light on this.
> 
> - vijay
> --

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 25 May 2006 08:39:46 +0300

> be -- in the context of a sips scheme is a different thing.

transport=tls is fine.  it is sips that nobody knows what it means.

-- juha

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 25 May 2006 14:03:00 -0500

> transport=tls is fine.  it is sips that nobody knows what it means.

transport=tls was fine in the days when TCP was the only transport
over which TLS could be used.  It's use now would be ambigious,
given DTLS -- which I note just became RFC4347 last mont -- and
the potential of using TLS over SCTP.

I would think that transport=tls, if we were to resurrect it and
make it legal ABNF, would cause more ambiguity.  Which transport
did we mean -- TLS over TCP?  UDP?  SCTP? ...?

Thanks.

- vijay

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 25 May 2006 22:13:19 +0300

> did we mean -- TLS over TCP?  UDP?  SCTP? ...?

if tls is not good, invent another name for tls/tcp or tls/sctp.  my
point is that SIPS uri scheme is useless, but there is value in tls
transport over tcp.

-- juha

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 25 May 2006 14:47:14 -0500

Juha Heinanen wrote:
> point is that SIPS uri scheme is useless, 

I guess that's where the disconnect is.  I, and at least Francois
and maybe Jonathan don't see it as entirely useless.  It probably
has no purchase in an end-to-end security model (displaying a bunny-
less padlock), but assuming we iron the kinks out, it plays within
our hop by hop trust model.

Thanks,

- vijay

---

From: Aki Niemi <[email-masked]>
Date: Fri, 26 May 2006 13:16:24 +0300

> our hop by hop trust model.

Can you elaborate what use case you have that requires/benefits from
SIPS, then?

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Fri, 26 May 2006 13:24:13 +0300

>   allow the network operator(s), their agents, and government

Agree 100%.

> if the second doesn't hold to confuse the issue by having two levels of

Agree.

> get these benefits then they will ask why they don't *always* get them.

Right. This is why I personally don't see the value in a different URI
scheme at all. If the user is given a choice to call [email-masked]
securely or insecurely, it's a no-brainer, and the sip URI scheme will
sink into oblivion eventually.

Maybe there's some value in an indication as a means to aid in
protecting against bid-down, but I'm not sure exactly how that would
work either.

> help provide something helpful to the user then we might as well not

I'm again in violent agreement here.

Cheers,
Aki

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 26 May 2006 09:46:04 -0500

> Can you elaborate what use case you have that requires/benefits from

Aki: See Jonathan's post on the benefits of sips:
   http://www1.ietf.org/mail-archive/web/sip/current/msg14342.html

The use case revolves around trust in our intermediaries; Brian
beat me to an an example.

Obviously there are kinks to iron out, like securing the last
hop.  Dean has expressed an opinion that we should leave
the last hop security specified as-is.  So some work would be
needed to reach consensus here.

But let's take a look at a possible attack scenario across this
transitive trust model.  Before going deeper, I think we all
agree that things like sdescriptions and keying materials should
not be exchanged through a TLS-protected proxy chain.

So, P1 --> P2 --> P3 --> P4 is a set of proxies.  P1 sends
request over TLS to P2.  P2 lies and puts SIP/2.0/TLS in
the Via header that it inserts, but sends it to P3 over TCP.
P3 accepts request over TCP, notes that the topmost Via says
TLS, but still continues to process the request towards
P4!  It could of course, reject the request right there, and
thus stop this attack.  For such a weak link attack to succeed,
both P2 and P3 will have to conspire (or P3 would have to be a
badly programmed proxy that does not know any better).
Collusions such as this across autonomous network boundaries
would be hard, I would think.  Especially if the SIP proxies at
P2 and P3 were of different genealogies.

Thanks,

- vijay

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 26 May 2006 19:53:31 +0300

Vijay K. Gurbani writes:

 > the last hop security specified as-is.  

no way.  my sip phone can connect to my providers proxy from anywhere in
the world and i must be able to get that last hop protected is caller
has specified sips.

-- juha

---

From: Alan Jeffrey <[email-masked]>
Date: Fri, 26 May 2006 12:19:33 -0500

Some thoughts on the requirements for SIPS...

It seems to me that there are two distinct scenarios: SIPS between hosts 
in the same administrative domain, and SIPS across administrative 
domains.  RFC3261 already distinguishes these in the special case of the 
final proxy<->UE hop, but doesn't do so between proxies in the middle of 
the network.

In the case of SIPS crossing administrative domain, there is a clear 
argument for requiring some form of encryption: whether that's TLS-only 
or allows DTLS, IPsec, or other means is still up for argumentation, but 
the case for integrity and confidentiality protection is clear.

Less clear is the case within one administrative domain.  Examples where 
it might make sense to allow intra-domain SIPS traffic to be transported 
unencrypted include:

a) SIPS traffic from a proxy to an application server such as voice 
mail: especially in the case where the AS is physically located in the 
same secured room.  It seems odd to require the traffic to be encrypted, 
then re-encrypted to travel a few feet across an ethernet cable in a 
locked room :-)

b) Proxy farms which use an external TLS accelerator to offload the TLS. 
  In the HTTP world, these are often deployed non-transparently, meaning 
that the TLS accelerator acts as a proxy, speaking HTTPS externally and 
HTTP internally.  (Microsoft has added a Front-End-Https header to HTTP 
to notify the back-end server that the external connection was 
TLS-secured, although it passes little information about the state of 
the TLS connection, e.g. the certificate chain authenticating it.)

In cases like these, I'd find it difficult to argue that the additional 
security guarantees of TLS are worth the expense.

Just my tuppence worth...

Alan.

PS: Shouldn't the "hop-by-hop bunny" icon use the rabbit from Monty 
Python and the Holy Grail?

-- 
Alan Jeffrey                                           +1 630 224 0175
Bell Labs, Lucent Technologies   http://cm.bell-labs.com/who/ajeffrey/
_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Fri, 26 May 2006 13:35:42 -0700

> P2 and P3 were of different genealogies.
The more I think about this the more I do know what real life
problem SIPS thinks it's solving. Can somebody be so kind as to
tell me? Not what SIPS might provide, but what real life attacks
it prevents that are uniquely due to SIPS (ie, different from 
transport=tls).

       Mike

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 26 May 2006 15:58:33 -0500

> it prevents that are uniquely due to SIPS (ie, different from 

For this particular attack, assume that you did not have sips;
only transport=tls.  Then, there would not be a way for P1
to indicate to P2 that P2 should use TLS towards P3 (since
the informal consensus in the group appears to be that
transport=tls, were it resurrected, would mean protect the
traffic towards the next hop only).

With sips, at the very least, you have the notion that all
well behaving intermediaries would use TLS towards the
destination.  If we do away with the notion of upgrading sip
URI to sips and disallow downgrading sips to sip, at least a
host receiving a request with a sips URI can be certain that
TLS was used on every hop.

Now, as a matter of course, we could do away with sips by
making TLS the preferred transport such that all entities
used TLS first (over any transport that supports it), before
trying a non-TLS transport.  But then you loose the ability
to know whether TLS was used at every hop.

Thanks,

- vijay

---

From: Michael Thomas <[email-masked]>
Date: Fri, 26 May 2006 14:02:11 -0700

Vijay K. Gurbani wrote:

> For this particular attack, [...]

What particular attack?

       Mike

> assume that you did not have sips;

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 26 May 2006 16:09:25 -0500

>> For this particular attack, [...]

The one you had replied to in my email ... let me see -- the
mail archive is not yet updated, so I will cut-and-paste
from your previous email:

Michael Thomas <[email-masked]> wrote:
> Vijay K. Gurbani wrote:
> 
>> 
>> So, P1 --> P2 --> P3 --> P4 is a set of proxies.  P1 sends request
>> over TLS to P2.  P2 lies and puts SIP/2.0/TLS in the Via header
>> that it inserts, but sends it to P3 over TCP. P3 accepts request
>> over TCP, notes that the topmost Via says TLS, but still continues
>> to process the request towards P4!  It could of course, reject the
>> request right there, and thus stop this attack.  For such a weak
>> link attack to succeed, both P2 and P3 will have to conspire (or P3
>> would have to be a badly programmed proxy that does not know any
>> better). Collusions such as this across autonomous network
>> boundaries would be hard, I would think.  Especially if the SIP
>> proxies at P2 and P3 were of different genealogies.
>> 
> The more I think about this the more I do know what real life problem
> SIPS thinks it's solving. Can somebody be so kind as to tell me? Not
> what SIPS might provide, but what real life attacks it prevents that
> are uniquely due to SIPS (ie, different from transport=tls).
> 
> Mike

Thanks,

- vijay

---

From: Michael Thomas <[email-masked]>
Date: Sat, 27 May 2006 10:12:56 -0700

> from your previous email:

That's not what I'm asking for. I'm asking for a real life scenario that 
SIPS
prevents a real life attack that cannot be thwarted with transport=tls. 
As far
as I can tell, SIPS doesn't seem to be adding anything other than a hope and
a prayer.

       Mike

---

From: Dean Willis <[email-masked]>
Date: Sat, 27 May 2006 22:04:06 -0500

> as I can tell, SIPS doesn't seem to be adding anything other than a hope 

sips: 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.

As far as I can tell, that's all it does.

--
Dean