Subject: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)

From: "Elwell, John" <[email-masked]>
Date: Mon, 30 Oct 2006 08:36:02 +0000

Some of the discussion on the long thread on "TLS meaning" has led me to
seek opinions on what does indeed control the lock icon, since we seem to
have consensus that a successful SIPS request is not grounds for showing the
lock icon.

The user surely will expect media to be secured end-to-end. By end-to-end, I
mean at least as far as the domain the user believes he/she is in
communication with. So there has to be some cryptographic assurance that the
entity with which the UA agrees keys for media security has the credentials
of the entity indicated by caller or connected party identity (From+Identity
or possibly PAI). This is probably a sufficient condition if key agreement
is carried out using D-H. If the key is transported, then an additional
condition is that the key is end-to-end encrypted, which for SDescriptions
means encrypted using S/MIME.

But what about the presence of B2BUAs, SBCs, etc. that do not have the
credentials of the end user but nevertheless terminate media security? Here
the UA could find that it does media negotiation with service-provider.net
rather than with the end user ([email-masked]). It seems the lock item
should not be displayed in this situation. Or maybe the user could be
consulted whether he/she accepts the certificate of the intermediary even
though it fails to identify the remote user.

Another situation is where a user is trying to contact
[email-masked] but gets back a From/Identity indicating
[email-masked] and media is secured as far as
service-provider.net. Does this constitute grounds for displaying the icon?

John

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 29 October 2006 21:26
> To: 'EKR'; 'David R Oran'
> Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; 
> 'Francois Audet'; 'Dean Willis'
> Subject: RE: [Sip] RE: TLS meaning
> 
> 
> 
> > -----Original Message-----
> > From: Eric Rescorla [mailto:[email-masked]]
> > Sent: Saturday, October 28, 2006 9:34 AM
> > >From a security perspective, SIPS has two important properties:
> > 
> > 1. It says to the client "you MUST talk to me over SSL".
> 
> I hope it doesn't say that.  I thought we had to use TLS. ;)
> 
> 
> > 2. It says to the proxies "I expect you to make the outgoing
> >    connection with TLS".
> > 
> > As Samir has observed, the second property can be provided with some
> > indicator in the SIP header. However, the first can only be provided
> > by putting the indicator in the reference which you hand 
> around (i.e.,
> > the SIP URI). This isn't to say it necessarily has to be a new URI
> > scheme--though it did in HTTP because HTTP doesn't have
> > parameters--but it's not clear to me that moving it to parameters
> > would really help.
> 
> I think the part some of us are worried about is it will inherit the
> perception of https: namely that the entire path from the 
> caller to the
> answerer is secure.  Just because an IETF doc says it's not 
> the same, and
> says it's not a lock icon, will not overcome the perception.  
> Even though an
> https connection is only secure to the TLS terminator (the 
> server or an
> offloader), and the back-end from there is not, the 
> assumption is the owner
> of the terminator takes on the responsibility from there (if 
> there is any
> responsibility).  And the terminator owner wanted to secure 
> it between the
> browser and the terminator, and they got that.
> 
> But SIP is neither HTTP nor SMTP.  The sips uri may end at a 
> pstn gateway,
> or an h323 IWF, or whatever.  It may become sip later, as 
> well.  The owner
> of the TLS terminator does not necessarily equal the owner of 
> the final UAS,
> nor the owner of the answerer.  How can the owner of the 
> terminator have any
> responsibility for something that may happen somewhere else, 
> unbeknownst to
> him?  How/why would someone who types in a sips uri for their 
> request not
> think it's like https?  
> 
> In some ways the perception problem is exacerbated by the uri 
> being the sips
> scheme.  If it were a require/proxy-require instead, it would 
> help alleviate
> that perception problem, IMO.  But then you're left with trying such a
> request without the foreknowledge of success probability that a
> business-card sips address would give you.
> 
> -hadriel
> 
> 
> _______________________________________________
> 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: "Brian Rosen" <[email-masked]>
Date: Mon, 30 Oct 2006 13:22:36 -0500

Okay, let's tackle some of these issues.

I think in order to be useful:
sips: means yes you must carry TLS through B2BUAs and anything else that
could create an unsecure link
sips: means fail if you terminate on a gateway that interworks to a non TLS
supported protocol, and the gateway must carry TLS through a protocol that
supports TLS.

Nothing else makes sense to me.

For B2BUAs and SBCs and other things, I think there is a simple test: if the
ciphersuite included encryption, is the signaling encrypted end to end?

For gateways, I think talking about interworking to non TLS secured
protocols is not what I want the sips success to mean.  It's not a secure
TLS hop by hop end to end.  This is especially true if the gateway is to the
PSTN.  It does mean that a gateway that interworked to, say H.323 could
succeed with sips if it was possible to determine that the H.323 signaling
was TLS protected all the way.

Brian

> From: Elwell, John [mailto:[email-masked]]
> Sent: Monday, October 30, 2006 3:36 AM
> To: 'IETF SIP List'
> Subject: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 30 Oct 2006 13:45:53 -0500

I have removed most of the attribution below because the question of 
who said it, or what exactly he said, is not my point at the moment.

At 01:22 PM 10/30/2006, Someone wrote:
>sips: means  ....

Having had several off line discussions with people who know their 
stuff very well about this SIPS issue, what has become very clear to 
me is that different participants have very different mental models 
of the relative roles and responsibilities of the proxies and the 
initiating / terminating UAs in the SIP exchanges.  And different 
understandings of what the expressed user desire is when they say "sips:".

This then results in people saying "nothing else makes sense to me."
In fact, I still am having trouble understanding some of the points 
of view, because of this model conflict.  (And I will readily admit 
that my mental model of what's going on may be wrong.  But I can't 
seem to get to another one.)

We then end up talking past each other.

Yours,
Joel M. Halpern

PS: I am deliberately being a bit vague on the model mismatches for 
two reasons.  Firstly, I think there are many more mismatches than 
just the ones between me and my correspondents.  Secondly, I really 
don't want to mischaracterise other people's arguments.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Oct 2006 14:11:29 -0500

I support John here. As stupid as it might seem, I think this little 
thing is likely to be very important. And figuring out what it takes to 
have it is a way at getting to underlying requirements for security in 
the protocol. Perhaps there are also other requirements for security, 
but at least this would provide one source.

So far I have heard that having a SIPS connection doesn't imply that one 
can show this lock icon. What isn't yet clear to me is if that means 
that SIPS is a necessary but insufficient condition, or if SIPS is in 
fact not even helpful for providing it. I suspect it isn't even helpful. 
If not, then what *is* driving the requirements for SIPS?

I think I would also extend John's proposal a bit. I think there *may* 
need to be different levels of security, where the lock icon corresponds 
to one of them. But this is a slippery slope, because if there are too 
many they become confusing to users. But too few of the wrong ones may 
not be useful in practice.

For instance, it may be that there is a need for "PSTN quality" 
security. (I imagine that *ought* to be the same as "none", but in 
practice I think the PSTN level security is better than basic 
unsecured-sip-over-internet security, so knowing you had this when 
connected to the PSTN could be helpful.) But a "really secure" (better 
than PSTN) would be a great way of motivating deployment of IP-based e2e 
telephony services.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Oct 2006 14:25:14 -0500

> ciphersuite included encryption, is the signaling encrypted end to end?

How does all of the above relate to John's question?
- Does having all of the above mean the little lock may be
   displayed? (no)

- is all of the above a necessary (but insufficient) condition
   to being able to display the little lock?

> was TLS protected all the way.

What does "all the way" mean here?

If a request is addressed to sips:[email-masked], and it reaches a 
server holding credentials for [email-masked] that acts as a UAS, 
does it matter what else that UAS does?

It could be a device with a speaker, that plays media to a stadium full 
of people. Or it could be a device that broadcasts media to all who will 
listen. Of it might offer the media to whoever it chooses, perhaps using 
SIP signaling to do so. Have any of those things broken the contract of 
the UAS? I don't think so.

It seems to me that once you have reached something authoritative for 
the request target, then all bets are off. The registrar and 
authoritative proxy have that role, though it has been muddled because 
we usually talk about that being a proxy rather than a UA for requests 
other than REGISTER.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 30 Oct 2006 14:26:56 -0500

I want sips to mean: we have protected the signaling by TLS from one end
through each and every entity to the other end, with the caveat that we only
have transitive trust in each leg that they are meeting this requirement.

With that in mind, I think defining the B2BUA as a hop, but not the last hop
is the correct interpretation.  Similarly, if one end is on the PSTN, then
you don't have TLS from end to end.  However, if you went from SIP to H.323,
but it was hop by hop TLS protected all along the path, than sips is
appropriate.

I think the distinction some of us are making is that while we agree that
some other hop by hop security mechanisms are appropriate, and those
mechanisms would use different mechanisms than all-TLS, sips meaning all TLS
is useful, and deployable, and we should clarify 3261 to achieve that. 

I think all of us in that position also take the position that doing
something else, beyond clarifying sips, is useful, and should be done, but
should be called something other than sips.  That is a lot more work.  I
don't hear any voices saying just clarify sips as TLS end to end with no
further work.  

I hear some people disagreeing that sips meaning TLS end to end is useful.
Some of those people want to simply deprecate sips and define something
else.  Others want to redefine sips to be something else.  The something
else is the same something else I want.

I think we all tend to be agreeing on what that something else should look
like: it should describe desired security properties, it should allow any
suitable mechanism to achieve that goal, it should involve some use of
Require/Supported.

Brian

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Monday, October 30, 2006 1:46 PM
> To: 'IETF SIP List'
> Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 30 Oct 2006 14:34:56 -0500

I pretty much agree with John.

I think the lock should mean BOTH the signaling and the media are protected
at least hop by hop.  I think sips is therefore a necessary, but
insufficient mechanism.

A really interesting question is whether S/MIME is acceptable as a
sufficient mechanism.  It surely is for some parts of signaling, but as a
practical answer, it can't protect all of the signaling.

I think we all agree SRTP is sufficient, but we don't yet agree on what a
sufficient key management mechanism for SRTP is.  I think if you have used
S/MIME or TLS on the signaling, that any of the key mechanisms I know are
sufficient.  

I'm not sure how we deal with SBCs in the media path.  I guess if the media
was protected end to end, even with a middlebox, then I think the lock icon
is okay.

I think the retargeting of [email-masked] to [email-masked] is an
acceptable condition for displaying the lock icon.  

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, October 30, 2006 2:11 PM
> To: Elwell, John
> Cc: 'IETF SIP List'
> Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Oct 2006 14:03:12 -0600

I really don't understand why people keep on bringing the padlock thing
again in the context of sips.

In a request-URI, sips is merely an indication that it is requested that
all the hops (except possibly the last one) forward this request over
TLS. 
RFC3261 uses a different URI scheme for that purpose as opposed to a
Require
header, but that's water under the bridge. That functionality is useful.

Many of us have explained over and over why being able to request that
a request be sent securely over TLS is useful.

There is no implication of padlock icons here, neigher for the sender or

the receiver.

There are many aspects to security, and it's not clear to me that the
role of IETF is to define the meaning of a padlock. Regardles, I can
think
of the following attribute: 

- Are MIME bodies (including SDP) encrypted end-to-end using S/MIME?

- Are selected parts of the SIP message itself and MIME bodies
(including SDP) 
  integrity protected end-to-end using SIP Identity (as per RFC 4474)?

- Are the whole SIP message itself and  MIME bodies (including SDP)
integrity 
  protected end-to-end using S/MIME (as per RFC 3993)?

- Is media encrypted end-to-end using SRTP?

- Is the key negotiation used for that secured end-to-end using
encryption (e.g., 
  MIKEY, SDESC with S/MIME).

- Is the identity of the user sending the request secured with
sip-identity (RFC 4474)?

- Are request mapped to a non-SIP network considered "secure" (e.g.,
PSTN, H.323, etc.)?

- Can we protect against B2BUA and the likes? 
- etc.

In short, there are many aspects to this, including (but not limited
to):

- Authentication of users

- Integrity protection

- Encryption of signalling

- Encryption of media

- End-to-end versus hop-by-hop

- Hop-of to another network (e.g., PSTN, H.323, etc.) 

- What cyphersuites are used

- etc.

It is not clear to me at all that we (SIP WG) can specify what the
padlock icon should be. 
Different network deployment may wish to convey different information to
end-users.

In some deployment, you may want an indication that everything is
encrypted/authenticated
end-to-end (security, media, identity, etc.) using a consolidated icon.
In other deployment,
maybe hop-by-hop is the desired behavior (e.g., inside an enterprise
where lawful intercept 
may be view as secure).

In some other deployment, you amy want different padlock icons for
different security
properties. Or different levels of security.

The point is, this is NOT SIPS. It's something else. If we decide to
tackle it or not
is another issue. I personally think it is a pretty tall order, and I'm
not sure
it's the mandate of IETF.  For now, I just want to ensure that we don't
confuse
padlock with SIPS.

Cheers.

> Sent: Monday, October 30, 2006 11:11 AM
> To: Elwell, John
> Cc: 'IETF SIP List'
> I support John here. As stupid as it might seem, I think this 
> little thing is likely to be very important. And figuring out 
> what it takes to have it is a way at getting to underlying 
> requirements for security in the protocol. Perhaps there are 
> also other requirements for security, but at least this would 
> provide one source.
> 
> So far I have heard that having a SIPS connection doesn't 
> imply that one can show this lock icon. What isn't yet clear 
> to me is if that means that SIPS is a necessary but 
> insufficient condition, or if SIPS is in fact not even 
> helpful for providing it. I suspect it isn't even helpful. 
> I think I would also extend John's proposal a bit. I think 
> there *may* need to be different levels of security, where 
> the lock icon corresponds to one of them. But this is a 
> slippery slope, because if there are too many they become 
> confusing to users. But too few of the wrong ones may not be 
> useful in practice.
> 
> security. (I imagine that *ought* to be the same as "none", 
> but in practice I think the PSTN level security is better 
> than basic unsecured-sip-over-internet security, so knowing 
> you had this when connected to the PSTN could be helpful.) 
> But a "really secure" (better than PSTN) would be a great way 
> of motivating deployment of IP-based e2e telephony services.
> 
> 	Paul
> 
> Elwell, John wrote:
> > Some of the discussion on the long thread on "TLS meaning" 
> has led me 
> > to seek opinions on what does indeed control the lock icon, 
> since we 
> > seem to have consensus that a successful SIPS request is 
> not grounds 
> > for showing the lock icon.
> > 
> > The user surely will expect media to be secured end-to-end. By 
> > end-to-end, I mean at least as far as the domain the user believes 
> > he/she is in communication with. So there has to be some 
> cryptographic 
> > assurance that the entity with which the UA agrees keys for media 
> > security has the credentials of the entity indicated by caller or 
> > connected party identity (From+Identity or possibly PAI). This is 
> > probably a sufficient condition if key agreement is carried 
> out using 
> > D-H. If the key is transported, then an additional 
> condition is that 
> > the key is end-to-end encrypted, which for SDescriptions 
> > credentials of the end user but nevertheless terminate 
> media security? 
> > Here the UA could find that it does media negotiation with 
> > service-provider.net rather than with the end user 
> ([email-masked]). 
> > It seems the lock item should not be displayed in this 
> situation. Or 
> > maybe the user could be consulted whether he/she accepts the 
> > certificate of the intermediary even though it fails to 
> identify the remote user.
> > 
> >> Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; 'Francois 
> >> Audet'; 'Dean Willis'
> caller to 
> >> the answerer is secure.  Just because an IETF doc says 
> it's not the 
> >> same, and says it's not a lock icon, will not overcome the 
> >> perception.
> >> Even though an
> server or 
> >> an offloader), and the back-end from there is not, the 
> assumption is 
> >> the owner of the terminator takes on the responsibility from there 
> >> (if there is any responsibility).  And the terminator 
> owner wanted to 
> >> secure it between the browser and the terminator, and they 
> got that.
> >>
> >> But SIP is neither HTTP nor SMTP.  The sips uri may end at a pstn 
> >> gateway, or an h323 IWF, or whatever.  It may become sip later, as 
> >> well.  The owner of the TLS terminator does not 
> necessarily equal the 
> >> owner of the final UAS, nor the owner of the answerer.  
> How can the 
> >> owner of the terminator have any responsibility for something that 
> >> may happen somewhere else, unbeknownst to him?  How/why 
> would someone 
> >> who types in a sips uri for their request not think it's 
> like https?
> >>
> >> In some ways the perception problem is exacerbated by the 
> uri being 
> >> the sips scheme.  If it were a require/proxy-require instead, it 
> >> would help alleviate that perception problem, IMO.  But 
> then you're 
> >> left with trying such a request without the foreknowledge 
> of success 
> >> probability that a business-card sips address would give you.
> >>
> >> -hadriel
> >>
> >>
> >> 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
> >>
> > 
> > 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
> > 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Oct 2006 15:54:56 -0500

> again in the context of sips.

The subject line was changed to protect the guilty (er - innocent). :-)

Seriously, while related its not exactly the same subject, so don't take 
it personally.

> header, but that's water under the bridge. That functionality is useful.

I think you have a good handle on having a clear definition of what SIPS 
means. IMO the question is, once that is settled, is how useful and 
important that is.

> a request be sent securely over TLS is useful.

Does it solve enough problems to be worth the trouble of getting deployed?

> think of the following attribute: 

It may not be necessary for the ietf to define this, or at least that it 
make the one and only definition. But it could be important to establish 
a framework within which it is clear how to make such definitions, and 
perhaps to make one definition to serve as a proof of concept and to 
help in understanding what dependencies there are on mechanisms such as 
SIPS.

> - Can we protect against B2BUA and the likes? 

I think I agree with these, though it may turn out that in practice all 
aren't necessary. Getting an idea of what it means to "protect against a 
B2BUA" could be very interesting.

> Different network deployment may wish to convey different information to

That could lead to some nasty interoperability issues when considering 
"networks" that interconnect. Maybe it is inevitable that there will be 
limited or no real security in cases like this, but I think there will 
be demand for some. (For really disconnected networks, such as for 
military command and control, interop probably isn't an issue and a 
special definition would be appropriate.)

> it's the mandate of IETF.  For now, I just want to ensure that we don't

I agree it probably isn't within the current charter. And I don't know 
where it would fall in a priority list. But I think it is something that 
will eventually need to be done, and I don't see who other than the ietf 
would be appropriate to do a general framework that could support 
interoperability over the internet.

	Paul

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 30 Oct 2006 16:54:48 -0500

The question is what "some other ... mechanisms are appropriate" means.
Presumably, if SIPS means something useful (either TLS end to almost 
end, or some other definition) our hope would be to teach users that 
if they want security they should use SIPS.
If we are going to teach them that, and we are going to restrict SIPS 
to TLS, then what does it mean to say that "some other hop by hop 
security mechanisms are appropriate?"  Does it mean that other 
measures are appropriate if the user didn't ask for security?  Does 
it mean that we should make up another hop-wise secure URI schema (I hope not.)

The users don't care about what actual protocol is used to provide 
the security.
And if they understand at all what a proxy is, and that there can be 
intermediate proxies, then they presumably don't care which 
intermediate proxies are in the path.
They presumably care that proxies do their job right, but that seems 
to me to be a proxy issue, not an end user issue.
And proving that the "right" thing happened is clearly a very 
different problem, with its own complications.

Let me turn this around and ask the opposite stupid question.
What breaks if we say
1) Every UAC and every proxy SHOULD utilize security on its requests 
to the next hop for all requests.
2) Every proxy must support TLS.  Every UAC must be able to invoke 
TLS.  (Already required I believe.)
3) Other mechanisms with equivalent security properties may be used 
instead of TLS to meet (1).

Then you don;t need SIPS.  And there is no downgrade attack.  I will 
acknowledge that
a) this is not what 3261 says
b) that the equivalence in 3 is complex, and may open the door to 
some folks making bad choices.  But we already leave that door open 
in other regards.  The best solution is to be clear about what the 
security properties are.

Probably there is some obvious and simple reason the above is a bad idea.
But this way it is no longer hammering at my skull for release.

Yours,
Joel M. Halpern

At 02:26 PM 10/30/2006, Brian Rosen wrote:
>I think the distinFrom [email-masked] Mon Oct 30 16:59:39 2006
Date: Mon, 30 Oct 2006 16:54:48 -0500
To: "'IETF SIP List'" <[email-masked]>
From: "Joel M. Halpern" <[email-masked]>
Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS 
  meaning)

The question is what "some other ... mechanisms are appropriate" means.
Presumably, if SIPS means something useful (either TLS end to almost 
end, or some other definition) our hope would be to teach users that 
if they want security they should use SIPS.
If we are going to teach them that, and we are going to restrict SIPS 
to TLS, then what does it mean to say that "some other hop by hop 
security mechanisms are appropriate?"  Does it mean that other 
measures are appropriate if the user didn't ask for security?  Does 
it mean that we should make up another hop-wise secure URI schema (I hope not.)

The users don't care about what actual protocol is used to provide 
the security.
And if they understand at all what a proxy is, and that there can be 
intermediate proxies, then they presumably don't care which 
intermediate proxies are in the path.
They presumably care that proxies do their job right, but that seems 
to me to be a proxy issue, not an end user issue.
And proving that the "right" thing happened is clearly a very 
different problem, with its own complications.

Let me turn this around and ask the opposite stupid question.
What breaks if we say
1) Every UAC and every proxy SHOULD utilize security on its requests 
to the next hop for all requests.
2) Every proxy must support TLS.  Every UAC must be able to invoke 
TLS.  (Already required I believe.)
3) Other mechanisms with equivalent security properties may be used 
instead of TLS to meet (1).

Then you don;t need SIPS.  And there is no downgrade attack.  I will 
acknowledge that
a) this is not what 3261 says
b) that the equivalence in 3 is complex, and may open the door to 
some folks making bad choices.  But we already leave that door open 
in other regards.  The best solution is to be clear about what the 
security properties are.

Probably there is some obvious and simple reason the above is a bad idea.
But this way it is no longer hammering at my skull for release.

Yours,
Joel M. Halpern

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Oct 2006 16:58:18 -0800

> you don't have TLS from end to end. 

According to RFC3261, I do -- the SIP endpoint is that PSTN
gateway.

With your argument, that PSTN gateway would have to reject
the SIPS call setup attempt, the originator would have to
send it via SIP, and possibly expose their signaling and
media to IP-based eavesdroppers (RFC4568 requires using
SIPS or S/MIME to protect the key in SDP), just because 
the last hop was the PSTN.  

We lack a mechanism for the PSTN gateway to say "it's 
secured up to me, and I'm the last hop and I can't 
make the PSTN do SIPS, sorry."  We only have a 
mechanism for the PSTN gateway to say "I can't do SIPS".

> However, if you went from SIP to H.323, but it was hop 
> by hop TLS protected all along the path, than sips is
> appropriate.

H.323 has a SIPS-like mechanism to ensure all of the
hops within H.323 are using TLS, including a PSTN
gateway?

-d

> I think the distinction some of us are making is that while 
> we agree that some other hop by hop security mechanisms 
> are appropriate, and those mechanisms would use different 
> mechanisms than all-TLS, sips meaning all TLS

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 30 Oct 2006 21:35:38 -0500

I'm not sure that's tenable.  When the request reaches the PSTN gateway, it
reached the UAS.  It would be practically impossible to define otherwise.
What would an IAD/MTA do, if it received a SIPS request but would be ringing
a POTS/FXS interface in the house?  What if that IAD were physically in the
CO?  What would a PBX do, key-system, etc.  Or even if it stayed IP - what
would a SIP-to-Skype inter-working gateway do, or an enterprise system that
controlled phones with skinny/unistim/whatever.  What would it mean if the
UAS used H.248 or MGCP to control media gateways while sending the
"signaling" securely using sigtrans over TLS?

SIPS asked for SIP over TLS.  When it reached the SIPS UAS, it got it.

-hadriel

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Monday, October 30, 2006 1:23 PM
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 30 Oct 2006 21:54:35 -0500

> the last hop was the PSTN.
Yes, I agree that's what you would have to do, which would be the same
circumstance if the first hop, which may very well be in a domain that you
can trust can't handle TLS.

This mechanism IS NOT EVERYTHING WE WISH IT COULD BE, but it's useful.
I think we need to be fairly practical, and I also think we need to think
about what it means to the system as a whole, and not JUST the UAC to UAS
connection.  If the signaling is not protected end to end, then it's not
"protected" and saying that a piece of it is protected is not interesting to
anyone.  You might as well say that there was at least one hop which was
protected.  I feel that the PSTN is not protected signaling via TLS, and
that's what sips means to me.  I think that is a useful mechanism, if it
really means TLS end to end.  I don't think it's very useful if all it means
is one arc of UAC to UAS if the actual call has two or three such arcs
joined by B2BUAs, or one end is a PSTN connection.

There may be some yet to be defined security mechanism that allows a more
nuanced expression of what is acceptable, and what was accomplished, but
that's not sips, at least in my opinion.

> mechanism for the PSTN gateway to say "I can't do SIPS".
Yes, I agree, but that is just the same, to me, as a proxy that can't do TLS
downstream, or a B2BUA that can't do TLS downstream.  I don't care WHY they
can't maintain secure signaling connections via TLS end to end, I just know
they can't.  That's what I want to know; my signaling is protected end to
end via a hop by hop TLS mechanism.

Brian

---

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 31 Oct 2006 07:46:22 +0100

> H.323 has a SIPS-like mechanism to ensure all of the hops 
> within H.323 are using TLS, including a PSTN gateway?
No, H.323 hasn't. H.323 supports using TLS to protect the call
signaling, which you can apply in a proxy like model or in a direct call
model. When you use an extra channel for call control, you can negotiate
to use TLS as protection meachnism via the call signaling channel, but
this is noly related for the next hop. To my knowledge, H.323 itself has
no meachnism like SIPS, which would require the gatekeeper to use TLS
for the next call signaling hop.   

Regarding the lock item as such, from my current perception using a web
browser, the lock icon  indicates, that I have a secure connection from
my browser to the server. As John wrote, I would expect the same
semantic from my SIP client covering both, signaling and media
connection.

Regards
	Steffen

> we agree 
> > that some other hop by hop security mechanisms are appropriate, and 
> > those mechanisms would use different mechanisms than all-TLS, sips 
> > meaning all TLS is useful, and deployable, and we should 
> clarify 3261 
> > to achieve that.
> > 
> > something else, beyond clarifying sips, is useful, and 
> should be done, 
> > but should be called something other than sips.  That is a lot more 
> > work.  I don't hear any voices saying just clarify sips as 
> TLS end to 
> > end with no further work.
> > 
> > Some of those people want to simply deprecate sips and define 
> > something else.  Others want to redefine sips to be something else.
> > The something
> > I think we all tend to be agreeing on what that something 
> else should 
> > look
> > like: it should describe desired security properties, it 
> should allow 
> > any suitable mechanism to achieve that goal, it should involve some 
> > use of Require/Supported.
> > 
> > Brian
> >

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 00:58:42 -0600

> supported protocol, and the gateway must carry TLS through a  

With https:, the user agent can tell when the above doesn't happen.

With sips:, it can't.

Is circuit switched telephony a gateway that interworks to a "non TLS  
supported protocol"?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 01:03:53 -0600

On Oct 30, 2006, at 1:11 PM, Paul Kyzivat wrote:
> So far I have heard that having a SIPS connection doesn't imply  
> that one can show this lock icon. What isn't yet clear to me is if  
> that means that SIPS is a necessary but insufficient condition, or  
> if SIPS is in fact not even helpful for providing it. I suspect it  
> isn't even helpful. If not, then what *is* driving the requirements  
> for SIPS?

I think what is driving the requirement for sips: is the property I  
described in an earlier message -- the originator user is asking the  
proxies to only transmit this request over a secured link, and not to  
transmit it if they can't assure that level of security. This is kind  
of like the check-box "Fragile" on a UPS mailing request, where  
you're warning the handlers that the contents are fragile and asking  
them to treat it carefully.

Of course, this sort of request sounds to me a lot more like a  
Requires/Proxy-Requires option tag, or a Caller Preferences tag, or  
some combination of those things, than it sounds like a URI scheme.  
But hey, we didn't know that yet when we were working on RFC 3261,  
and it seemed like we were talking about something that was kind of  
like https:, and thus sips: was born.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 01:10:17 -0600

On Oct 30, 2006, at 3:54 PM, Joel M. Halpern wrote:

> 1) Every UAC and every proxy SHOULD utilize security on its  
> requests to the next hop for all requests.
> Then you don;t need SIPS.  And there is no downgrade attack.  I  
> will acknowledge that

We lose the ability to demand security. That is, there'd be no way  
for a user to say "And if you can't send this securely, then don't  
send it!".

Of course, we could combine what you have above with an option-tag  
providing the "demand" function I describe, and you;d have everything  
that sips: currently gives without having to use the sips: URI scheme.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 31 Oct 2006 09:12:36 +0200

> like https:, and thus sips: was born.

exactly, and now it is high time to correct the mistake and deprecate
sips.

-- juha

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Oct 2006 07:20:37 -0500

While we currently have the ability to demand security, we actually 
have no way to reliably know whether we got it.
If we can not tell if it is being delivered, why is being able to ask 
for it better than expecting the system to always deliver it?

Yours,
Joel

PS: Just to be clear, the reason i say you can not tell if you got 
security is that even if we added extra recordings about what 
happens, I am pretty sure that two colluding proxies (such as a pair 
that have chosen to use IPSec instead of TLS, or have an old style 
telephony view and just trust their network and peering) will flat 
lie in order to deliver what they think is the service.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Oct 2006 07:03:07 -0800

>This mechanism IS NOT EVERYTHING WE WISH IT COULD BE, but it's useful.
FSVO "useful". If this mechanism were actually "useful", would we be having
this argument? Genuinely "useful" ideas have a tendency to route around the
IETF if it is perceived as being old and in the way. Genuinely "useful" 
ideas
also have a tendency to work out the initial ambiguities so that when 
it's time
to rev the spec they emerged from it's a matter of documenting current 
practices.

None of these things apply to SIPS. Indeed, the "useful" seems to be the 
enemy
of the useful.

       Mike

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Oct 2006 07:20:10 -0800

> Yes, I agree that's what you would have to do, which would be the
> same circumstance if the first hop, which may very well be in a
> domain that you can trust can't handle TLS.
>
> This mechanism IS NOT EVERYTHING WE WISH IT COULD BE, but it's
> useful.  I think we need to be fairly practical, and I also think we
> need to think about what it means to the system as a whole, and not
> JUST the UAC to UAS connection.  If the signaling is not protected
> end to end, then it's not "protected" and saying that a piece of it
> is protected is not interesting to anyone.  You might as well say
> that there was at least one hop which was protected.  I feel that
> the PSTN is not protected signaling via TLS, and that's what sips
> means to me.  I think that is a useful mechanism, if it really means
> TLS end to end.  I don't think it's very useful if all it means is
> one arc of UAC to UAS if the actual call has two or three such arcs

Ok.  Makes sense.

> There may be some yet to be defined security mechanism that allows a
> more nuanced expression of what is acceptable, and what was
> accomplished, but that's not sips, at least in my opinion.

Right.  What doesn't make sense, to me, is that we can only
express a binary value.  For example, when I'm at a coffeeshop
using their WiFi, I don't want to have to downgrade my 
connection to my proxy to SIP (from SIPS) just because I'm 
calling the PSTN.

> end via a hop by hop TLS mechanism.

I am interested in working on a mechanism that allows 
signaling that condition.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Oct 2006 11:33:42 -0500

Brian,

With your expectation about the meaning of SIPS, what is your attitude 
about TLS offloaders? The link from the offloader to the server isn't 
TLS. Does that mean a server using an offloader can't support SIPS?

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Oct 2006 11:33:42 -0500

Brian,

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 10:44:56 -0600

On Oct 31, 2006, at 6:20 AM, Joel M. Halpern wrote:

> If we can not tell if it is being delivered, why is being able to  
> ask for it better than expecting the system to always deliver it?
>
>

I've been told it comes down to trust. You just don't use sips: to  
talk to a proxy you don't trust to do the right thing.

Common SIP deployment scenarios posit a high level of trust between  
user and "home" or "outbound" proxy in many other ways. It is no  
great leap to assume that a proxy you are trusting in all these other  
ways will, if asked nicely, honor your request for "secure"  
treatment. If you can't trust a proxy to do this for you, there's all  
sorts of other stuff you can't trust it to do, and you probably  
shouldn't be using it as a home or outbound proxy in a conventional  
SIP deployment.

I've been proposing changing SIP so that many of these assumptions  
are no longer required, but in the absence of those changes, one  
could reasonably argue that sips: is as strong as the rest of the  
security model, because it's based on exactly the same trust  
assumptions. Personally I take that more as an argument against the  
current SIP security model than as an argument for the strength of  
sips:, but one could work with it either way.

> happens, I am pretty sure that two colluding proxies (such as a  
> pair that have chosen to use IPSec instead of TLS, or have an old  
> style telephony view and just trust their network and peering) will  
> flat lie in order to deliver what they think is the service.

Yep. That's a point a I think I've been asserting for quite some time.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 10:57:42 -0600

> connection to my proxy to SIP (from SIPS) just because I'm

That's why I keep saying this looks like a caller-preferences or  
Proxy-Require problem problem, not a URI scheme problem.

You could get what you want in the above case by having a Proxy- 
Require: TLS, where this forces any proxy in the loop to use TLS in  
and out.

A Require: TLS might actually transit SBCs, by requiring any UA in  
the loop to use TLS for induced requests.

> signaling that condition.

Would the Require and Proxy-Require I roughly describe above address  
you concerns?

--
Dean

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 31 Oct 2006 12:49:47 -0500

So if we're going to trust the proxies, why don't we trust them to decide
what is "secure", instead of mandating TLS?  I mean why would you trust them
to implement the tls profile correctly, follow 3261 and Francois'
clarity-draft, not downgrade, etc., but not trust them to implement IPSec
correctly?  If the proxy decides the next-hop is secure, and the next-hop
proxy decides it's previous-hop is secure, why is that not enough?

-hadriel

> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2006 11:45 AM
> To: Joel M. Halpern
> Cc: 'IETF SIP List'

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 31 Oct 2006 12:49:47 -0500

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Oct 2006 10:17:47 -0800

> Would the Require and Proxy-Require I roughly describe 
> above address you concerns?

They're close.  What I'd like is the ability to get TLS
everywhere I can, and still allow a call to complete
in the event a hop or two couldn't get TLS.  With 
Require, I believe a proxy will not forward the INVITE 
if it can't provide TLS on that next hop, right?

-d

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 14:30:58 -0600

> if it can't provide TLS on that next hop, right?

Right. So now you're more into the realm of Caller-Preferences.

But if we made SIP guidance "Use TLS (or rough equivalent) if you  
can, and only use a plain connection if you have alternative" for all  
calls, wouldn't that default to what you're asking for?

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Oct 2006 13:10:58 -0800

> can, and only use a plain connection if you have alternative" 
> for all calls, wouldn't that default to what you're asking for?

Yes.  That should be standard operating procedure.

-d

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Oct 2006 16:54:10 -0500

But, as the security folks have said many times, in many places 
"trust is not transitive."  The fact that I trust my first proxy to 
do the right thing does not mean that I trust all the proxies it 
trusts.  And it most certainly does not mean that I trust all the 
proxies that those proxies trust.

So saying that SIPS allows me to demand something and expect to get 
it not only requires a high level of local trust (a not unreasonable 
thing in many contexts) but a high level of transitive trust, which 
is not justifiable.

Yours,
Joel M. Halpern

PS: The example that has helped me understand the weakness of 
transistive trust is the issue of source IP fitlering.  it needs to 
be done a t the ingress ISP.  ISPs can peer with only those other 
ISPs they trust.  But it turns out no matter how you do it, some 
folks you need to trust end up choosing to trust other folks, who in 
turn don't do the filtering.