Subject: [Sip] SIPS question: How to prevent plaintext requests from being delivered to a UA

From: Dean Willis <[email-masked]>
Date: Fri, 06 Apr 2007 12:36:29 -0500

I'm pre-reviewing Francois' latest sips draft, and I'm perplexed.

Presume a UA wishes to receive only SIPS requests and not SIP requests.

This is important if we do not wish to reveal information about the UAS 
(most critically the identity of the user at this UAS) -- to 
packet-sniffers on the wire between UAC and UAS.

Previously it could do this by registering only a SIPS contact and not a 
SIP, and by using a SIPS AOR in registration.

    Because registering with a SIPS contact header field implies a
    binding to both a SIPS Contact and a corresponding SIP Contact . . .

means we simply can't satisfy this use case.

Just waiting for a request and then rejecting it if it didn't come in 
over TLS would not meet the requirement, since the plain text of the 
request would already have been sent, potentially compromising
information about the UAS.

Do we have a problem?

--
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: Eric Rescorla <[email-masked]>
Date: Fri, 06 Apr 2007 10:50:22 -0700

At Fri, 06 Apr 2007 12:36:29 -0500,
> information about the UAS.

It's probably useful here to take an analogy from the Web.

Amazon.com, to take one example, runs two web sites:

- The HTTP-based one which runs their catalog.
- The HTTPS-based one which they use for checkout.

If you're shopping and you go to checkout, they redirect you to
the HTTPS site. If you try to just go to the HTTPS site to shop
they redirect you to the HTTP site. If you mistakenly try to
do checkout with HTTPS, I suspect it pukes (many sites do),
even though the exposure has already happened. This is sort
of a necessary side effect of being willing to run both HTTPS
and HTTP. If you're never willing to run HTTP, then you need
your server not to listen on port 80. But actually this only
helps against passive attacks, since if a stupid person tries
to contact you over HTTP the attacker can just pose as you.
And of course if you're running on some sort of shared hosting
server, then the problem is even worse since the hosting server
may allow HTTP for others but not you. So, even the refuse to
listen on port 80 doesn't work.

The only real defense against this sort of downgrade is to only
give people URLs that start with https: and assume that they will
do the right thing.

So, mapping into the SIP domain, things look much more like the
hosting service example. You are connected to a SIP proxy which
may server SIP/TLS *and* SIP for other people. So, you can
certainly tell the proxy "don't accept anything for me not
over TLS" but as you say that only takes effect after he's
received the request. As long as the proxy is willing to do 
SIP-not-over-TLS then you can always be subject to this problem
(and even if it doesn't there's always the active attack I 
described above) and there's no instruction you could give the
proxy that would help (though the instruction could of course
restrict the proxy to talking to YOU via SIP/TLS).

As with https: the fix is that your AOR has to somehow signal
to everyone that you expect to be contacted over TLS. This is
what sips: does (though of course it's not the only way to do
it).

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 6 Apr 2007 13:32:37 -0700

Just like to point out that if a UA wants to receive all it stuff  
over TLS, it just forms only a TLS outbound connection - this is  
somewhat separate problems than sips.

On Apr 6, 2007, at 10:36 AM, Dean Willis wrote:

> This is important if we do not wish to reveal information about the  
> UAS (most critically the identity of the user at this UAS) -- to  
> Previously it could do this by registering only a SIPS contact and  
> not a SIP, and by using a SIPS AOR in registration.
>
> Just waiting for a request and then rejecting it if it didn't come  
> in over TLS would not meet the requirement, since the plain text of  
> the request would already have been sent, potentially compromising

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 6 Apr 2007 16:47:51 -0500

But it could address Dean's requirement however... 

Dean, should I put some wording about it in there? 

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Friday, April 06, 2007 13:33
> To: Dean Willis
> Cc: [email-masked]
> Subject: Re: [Sip] SIPS question: How to prevent plaintext 
> requests from being delivered to a UA
> 
> 
> Just like to point out that if a UA wants to receive all it 
> stuff over TLS, it just forms only a TLS outbound connection 
> - this is somewhat separate problems than sips.
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 6 Apr 2007 16:46:43 -0500

My very first draft of sips (individual draft) registered both SIP and
SIPS explicitely.

But people hated it (rightfully), and the group wanted the behavior in
the
draft, i.e., registering SIPS means that both SIP and SIPS will be
routed to
you. (And you may choose to reject SIP).

That's the group concensus. I think that was in Montreal.

So I say, no, there is no issue, because I've never heard that new
requirement
before... 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Friday, April 06, 2007 10:36
> To: [email-masked]
> Subject: [Sip] SIPS question: How to prevent plaintext 
> This is important if we do not wish to reveal information 
> about the UAS (most critically the identity of the user at 
> this UAS) -- to packet-sniffers on the wire between UAC and UAS.
> 
> 
> Previously it could do this by registering only a SIPS 
> contact and not a SIP, and by using a SIPS AOR in registration.
> 
> Just waiting for a request and then rejecting it if it didn't 
> come in over TLS would not meet the requirement, since the 
> plain text of the request would already have been sent, 
> potentially compromising information about the UAS.
> 
> Do we have a problem?
> 
> 
> --
> Dean
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Dean Willis <[email-masked]>
Date: Sat, 07 Apr 2007 00:25:20 -0500

> give people URLs that start with https: and assume that they will
. . .

> what sips: does (though of course it's not the only way to do

But the current draft doesn't. It implies that if you have a SIPS: AOR 
and a SIPS: contact registered to that AOR, that is still OK to send 
SIP: traffic. I requote:

So this is the equivalent of only giving people https:, and assuming 
that they will do the WRONG thing.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 07 Apr 2007 00:29:06 -0500

Cullen Jennings wrote:
> 
> Just like to point out that if a UA wants to receive all it stuff over 
> TLS, it just forms only a TLS outbound connection - this is somewhat 
> separate problems than sips.

That will indeed (if outbound is used) keep the outbound proxy from ever 
sending a request to the UA using UDP or TCP, and would address my 
concern (if outbound is used).

But not every UA has an outbound proxy.

What if we have UA to UA traffic, or "redirect to UA", and not an 
"outbound proxy" connection?

This comes up in the context of both classic SIP and P2PSIP.

The current draft says that if you have a SIPS: URI for somebody, it's 
OK to assume that the SIP: URI with matching user/domain parts points to 
the same place. It even (if I read this right) says that if you register 
only a a SIPS: contact, that there is a binding to the equivalent SIP: 
contact implied by the registration.

I think I'm looking to see something that says "If you only have a SIPS: 
  AOR, or there's only a SIPS: contact registered, then there is no 
reason to expect that a SIP: request sent to the equivalent will work, 
and that conformant systems MUST reject such a request.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 07 Apr 2007 00:57:06 -0500

> Dean, should I put some wording about it in there? 

I think it would be useful to mention this useful property of outbound.

I'd still like to make sure we really understand the implications for 
the non-outbound use case, and have a clear consensus that this is not a 
requirement we need to meet.

Maybe we really got this in the past, but if so I just missed it (of 
course, I miss a lot of stuff).

Maybe something as simple as "If you have a SIPS: URI for something you 
SHOULD try SIPS: before trying SIP:" would suffice.

Here's the use case I'm worried about again. The question is "Is this a 
problem we need to solve? If not, do we need to warn people that it is a 
problem we don't solve?"

Vice President Dick Cheney is back to hiding in bunkers.  His top-secret 
SIPS: phone registers its sips:[email-masked] AOR over a nice secure 
TLS connection with the nice secure SIP proxy hidden in some other 
bunker. Since there aren't any firewalls or NATs to worry about on this 
radio network, we don't use Outbound.

Meanwhile, dozens of Vice Presidential lookalikes hide in other bunkers, 
and all their SIPS: phones register to other AORs at that same proxy.

So far, we've given away nothing on the wire that tells Osama bin Laden 
which bunker has the real Dick Cheney, and which are lookalikes. So he 
doesn't know where to send the hijacked airliner.

Suddenly, somebody at the UN decides they need to ring up the VP, and 
send off a SIP: request, which hits the proxy. The proxy says "Hey this 
is a SIP: request, and I know that since he registered SIPS:, it's ok to 
forward this request. So the request goes out over the radio net, in 
unprotected UDP, carrying both a "To: sip:[email-masked]" that lets 
Osama know that this request is for the real VP, and a request URI (the 
registered Contact:) that tells him which bunker the real veep is hiding 
in. Kaboom.

Or, in a less contrived use case (since we know the VP would never use 
anything other than a special non-standards-compliant proxy that would 
use only sips:):

Alice and Bob use P2PSIP overlay ""example'net". Charlie is stalking 
Alice. He doesn't have credentials in the overlay, but he does have a 
WiFi sniffer which he takes coffeeshop to coffeeshop looking for Alice. 
He doesn't find ALice, but he does find Bob, and he waits for Bob to 
call her.

Alice is trying to be careful, so she uses the  secure peer protocol to 
PUT only her sips: contact into the overlay.

Bob uses the secure peer protocol to GET her sips: contact from the 
overlay. But Bob is a lazy slacker, so he downgrades to sip: and sends 
off an INVITE to Alice.

Charlie happens to be sniffing the traffic somewhere, either near Bob or 
near Alice. He might be able to deduce that there's a P2PSIP user on the 
net he's sniffing, but not that it is Alice. But when he sees Bob's 
request go by, he knows that node is Alice, and he knows what her IP 
Address is.

Alice's cover has just been blown.

What, if anything, do we need to say about problem in the draft?

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 7 Apr 2007 00:21:50 -0700

We can easily solve this just by using IPsec across the radio  
network :-) (Sorry, couldn't resist not saying that :-)

I don't know what I think of the actual text you are proposing we add  
- it might be fine, I doubt it achieves what you want, but more on  
that later....

However, I am pretty dubious about the use case - it is prosing there  
are going to be phones that are deployed to do TLS but don't do  
outbound - to do this they are going to have to have a certificate  
capable of acting as a SIP TLS server so it will need to assert their  
IP address or a DNS name that maps to their IP address. Although  
theoretically possible, this seems fairly unlikely - particularly for  
phones on a radio network.

So, on the "is this a problem we need to solve" - I think the answer  
is "not really".

But on, "do I see any problems with the proposed solution", I'm not  
sure - we have discussed this is the past and I can't remember what  
the reason were motivating the way it is now.

Following the use case you proposed, let say the INVITE from UN  
arrived at the proxy, it sent it over TLS to UA, and the UA put it's  
contact in the the 200 and sent it back to the proxy over TLS. Now  
the proxy sends it back to the UN over not over TLS, at this point,  
it seems like an attacker can once again find out the bunker by  
looking at the contact in the 200.

Or imagine your second case, and say Bob is not a slacker and does  
use TLS, but Charlie knows that Bob only calls Alice at that time and  
just looks at where the RTP packets are going.

Location privacy is a very hard thing to achieve and we have a bunch  
of drafts about that. I'm just not sure that we can get "sips" in a  
registered contact to mean "don't reveal my IP location information  
to bad guys". We are constantly trying to get the sips to mean more  
than it actually can. The whole discussion makes me very nervous.

more inline ...

Cullen <with my individual hat on>

On Apr 6, 2007, at 10:57 PM, Dean Willis wrote:

> Francois Audet wrote:
>> But it could address Dean's requirement however... Dean, should I  
>> put some wording about it in there?
>
> I'd still like to make sure we really understand the implications  
> for the non-outbound use case, and have a clear consensus that this  
> is not a requirement we need to meet.
>
> Maybe we really got this in the past, but if so I just missed it  
> (of course, I miss a lot of stuff).
>
> Maybe something as simple as "If you have a SIPS: URI for something  
> you SHOULD try SIPS: before trying SIP:" would suffice.

This seems like it would work for a UA but not sure it would for a  
proxy - once the proxy upgrades, now everyone before the proxy has to  
do sips too. Perhaps, I'm just all confused on this.

>
>
> Here's the use case I'm worried about again. The question is "Is  
> this a problem we need to solve? If not, do we need to warn people  
> that it is a problem we don't solve?"
>
> Vice President Dick Cheney is back to hiding in bunkers.  His top- 
> secret SIPS: phone registers its sips:[email-masked] AOR over a  
> nice secure TLS connection with the nice secure SIP proxy hidden in  
> some other bunker. Since there aren't any firewalls or NATs to  
> worry about on this radio network, we don't use Outbound.
>
> Meanwhile, dozens of Vice Presidential lookalikes hide in other  
> bunkers, and all their SIPS: phones register to other AORs at that  
> same proxy.
>
> So far, we've given away nothing on the wire that tells Osama bin  
> Laden which bunker has the real Dick Cheney, and which are  
> lookalikes. So he doesn't know where to send the hijacked airliner.
>
> Suddenly, somebody at the UN decides they need to ring up the VP,  
> and send off a SIP: request, which hits the proxy. The proxy says  
> "Hey this is a SIP: request, and I know that since he registered  
> SIPS:, it's ok to forward this request. So the request goes out  
> over the radio net, in unprotected UDP, carrying both a "To:  
> sip:[email-masked]" that lets Osama know that this request is  
> for the real VP, and a request URI (the registered Contact:) that  
> tells him which bunker the real veep is hiding in. Kaboom.
>
> Or, in a less contrived use case (since we know the VP would never  
> use anything other than a special non-standards-compliant proxy  
> that would use only sips:):
>
> Alice and Bob use P2PSIP overlay ""example'net". Charlie is  
> stalking Alice. He doesn't have credentials in the overlay, but he  
> does have a WiFi sniffer which he takes coffeeshop to coffeeshop  
> looking for Alice. He doesn't find ALice, but he does find Bob, and  
> he waits for Bob to call her.
>
> Alice is trying to be careful, so she uses the  secure peer  
> protocol to PUT only her sips: contact into the overlay.
>
> overlay. But Bob is a lazy slacker, so he downgrades to sip: and  
> sends off an INVITE to Alice.
>
> Charlie happens to be sniffing the traffic somewhere, either near  
> Bob or near Alice. He might be able to deduce that there's a P2PSIP  
> user on the net he's sniffing, but not that it is Alice. But when  
> he sees Bob's request go by, he knows that node is Alice, and he  
> knows what her IP Address is.
>

seems like there are lots more problems with location privacy stuff  
as discussed in 3323

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 07 Apr 2007 08:12:44 -0700

At Sat, 07 Apr 2007 00:25:20 -0500,
> that they will do the WRONG thing.

I don't understand the argument you're making here, probably because
"OK" isn't any kind of normative term. There are three relevant
actors here:

1. The registering user.
2. The proxy.
3. The caller.

You give the caller the sips: URI and I think the draft makes clear
that if you have a sips: URI you MUST NOT use SIP w/o TLS. The question
is what a proxy should do if a request comes in without TLS.

If you give people HTTPS and they try to contact the server over 
HTTP (recall that the servers need to support both TLS and non-TLS)
the server can do one of three things:

- Respond to the request anyway.
- Redirect the request
- Throw an error.

The damage of the data being sent over the net to the server is already
done.

Going back to the SIP case, the proxy has three options:

- Forward the request to the client anyway.
- Redirect to the SIPS AOR
- Throw an error.

Again, the damage of the data being sent in the clear over the net
to the proxy is already done. The text you quote above implies
the first choice, but it's not clear there's anything wrong with
that, especially as you can ensure that the connection from the
registering user to the proxy  is secure.

-Ekr

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 7 Apr 2007 10:47:28 -0500

Here is my take.

There is some text in there already that says that some proxies may have
policies of ONLY forwarding SIPS.

What I can do in the text is hightlight the "problem" you are talking
about,
and explain how it is solved:
- E.g., you can use outbound. Contrary to what Dean stated below,
Outbound is NOT
  just useful for NAT/Firewall traversal. It is also necessary for
supporting
  TLS when the UA does not provide a certificate (i.e., the server can't
establish
  the connection otherwise). This mean that your Dick Cheney example
will only
  be applicable if Dick Cheney has a certificate.
- Let say that Dick Cheney has a certifiate, and you do not use
Outbound. You
  could have a STANDARD proxy that has a policy of SIPS only (either
accross the
  board, or just for Dick Cheney). My view is that it would be a pretty
naive
  (and bad) product if you didn't have the mechanism in the proxy to
assign policies
  like this.

What I propose is that I discuss this in the draft. I really don't think
it needs 
protocol work. It's already solvable today. It's just good engineering. 

> Sent: Saturday, April 07, 2007 00:22
> To: Dean Willis
> Cc: Audet, Francois (SC100:3055); [email-masked]
> - it might be fine, I doubt it achieves what you want, but 
> more on that later....
> 
> However, I am pretty dubious about the use case - it is 
> prosing there are going to be phones that are deployed to do 
> TLS but don't do outbound - to do this they are going to have 
> to have a certificate capable of acting as a SIP TLS server 
> so it will need to assert their IP address or a DNS name that 
> maps to their IP address. Although theoretically possible, 
> this seems fairly unlikely - particularly for phones on a 
> radio network.
> 
> So, on the "is this a problem we need to solve" - I think the 
> answer is "not really".
> 
> But on, "do I see any problems with the proposed solution", 
> I'm not sure - we have discussed this is the past and I can't 
> remember what the reason were motivating the way it is now.
> 
> Following the use case you proposed, let say the INVITE from 
> UN arrived at the proxy, it sent it over TLS to UA, and the 
> UA put it's contact in the the 200 and sent it back to the 
> proxy over TLS. Now the proxy sends it back to the UN over 
> not over TLS, at this point, it seems like an attacker can 
> once again find out the bunker by looking at the contact in the 200.
> 
> Or imagine your second case, and say Bob is not a slacker and 
> does use TLS, but Charlie knows that Bob only calls Alice at 
> that time and just looks at where the RTP packets are going.
> 
> Location privacy is a very hard thing to achieve and we have 
> a bunch of drafts about that. I'm just not sure that we can 
> get "sips" in a registered contact to mean "don't reveal my 
> IP location information to bad guys". We are constantly 
> trying to get the sips to mean more than it actually can. The 
> whole discussion makes me very nervous.
> 
> more inline ...
> 
> >> But it could address Dean's requirement however... Dean, 
> should I put 
> >> some wording about it in there?
> >
> > the non-outbound use case, and have a clear consensus that 
> this is not 
> > a requirement we need to meet.
> >
> This seems like it would work for a UA but not sure it would 
> for a proxy - once the proxy upgrades, now everyone before 
> the proxy has to do sips too. Perhaps, I'm just all confused on this.
> 
> 
> >
> >
> > Here's the use case I'm worried about again. The question 
> is "Is this 
> > a problem we need to solve? If not, do we need to warn 
> people that it 
> > is a problem we don't solve?"
> >
> > some other bunker. Since there aren't any firewalls or NATs 
> to worry 
> > about on this radio network, we don't use Outbound.
> >
> lookalikes. 
> > So he doesn't know where to send the hijacked airliner.
> >
> > send off a SIP: request, which hits the proxy. The proxy says "Hey 
> > this is a SIP: request, and I know that since he registered SIPS:, 
> > it's ok to forward this request. So the request goes out over the 
> > radio net, in unprotected UDP, carrying both a "To:
> > sip:[email-masked]" that lets Osama know that this 
> request is for 
> > the real VP, and a request URI (the registered Contact:) that tells 
> > him which bunker the real veep is hiding in. Kaboom.
> >
> stalking 
> > WiFi sniffer which he takes coffeeshop to coffeeshop looking for 
> > Alice. He doesn't find ALice, but he does find Bob, and he 
> waits for 
> > Bob to call her.
> >
> protocol 
> > to PUT only her sips: contact into the overlay.
> >
> > Charlie happens to be sniffing the traffic somewhere, 
> either near Bob 
> > or near Alice. He might be able to deduce that there's a 
> P2PSIP user 
> > on the net he's sniffing, but not that it is Alice. But 
> when he sees 
> > Bob's request go by, he knows that node is Alice, and he knows what 
> > her IP Address is.
> >
> seems like there are lots more problems with location privacy 
> stuff as discussed in 3323
> 
> >
> > --
> > Dean
>

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 7 Apr 2007 13:18:49 -0500

Dean Willis has suggested that we should have a "sips" option-tag
defined for implementations that support the procedures of
draft-ietf-sip-sips.

This is standard practice to deal with backward compatibility.

In this particular case, it would be for implementations that
supported RFC 3261 before draft-ietf-sip-sips was standardized.
Those implementions are very likely to use procedurs that do not
comply with this specification (e.g., some may be using the
transport=tls
parameter, may be registering explictly both SIP and SIPS contacts, may
be using the last hop-exception, etc.). Proxies and UAs that support
these legacy
UAs would therefore use whatever coping techniques that would "work".

Unless there is a good reason NOT to define a sips option-tag for this 
purpose, I will include it in the next release. 

Comments?

---

From: Dean Willis <[email-masked]>
Date: Sat, 07 Apr 2007 13:45:12 -0500

> is what a proxy should do if a request comes in without TLS.

I'm not finding that. What I'm finding is text that says a user who is 
given a sips: URI can deduce a sip: URI from that and use it.

> The damage of the data being sent over the net to the server is already

Right.  The problem I'm trying to describe is -- do we need guidelines 
that prevent this damage from being done?

The HTTPS equivalent use case is:

Assume you are given an HTTPS URL for something. If you deduce an 
equivalent HTTP URL for that target and exercise it, any information 
sent is subject to interception by packet sniffers. If the HTTPS URL was 
for a "login" service, you might have just given away your password.

> registering user to the proxy  is secure.

The only way to ensure that the connection from the proxy to the 
registering user is secure is to "upgrade" the connection to SIPS. Just 
using TLS won't work, because there are possibly additional proxies 
between the proxy/registrar and the user. But upgrading to SIPS in a 
midstream proxy has issues that Francois and Jonathan have pointed out 
(like surprising the UAC, which might not support SIPS) or requires some 
B2BUA procedure from the proxy (like my old kludge-proxy did).

In the HTTP case as described above, we have a mitigating factor 
provided by TCP. Since HTTP and HTTPS both require a TCP connection and 
listen on different ports, the worrried server could just turn off its 
HTTP port. The client would fail to do a TCP open with the HTTP port, 
and would thus never send the sensitive information unprotected.

SIP has UDP, so there's no "open". Instead, (if a user or UAC deduces an 
equivalent SIP URI and uses it), the sensitive information could well 
just be blurted out, unprotected, in a UDP packet. And the only one 
listening for that packet is the interceptor, who is now a happy camper.

Perhaps something like:

A user or a UAC that has been presented a SIPS: URI for a correspondent 
MUST NOT deduce an equivalent SIP URI and use it. Instead, they MUST use 
the SIPS URI. The rationale for this that the issuer of the SIPS URI 
chose SIPS instead of SIP because they need to have a higher level of 
security exercised when contacting them, and their callers are required 
  to respect that need. If the user or UAC instead uses the equivalent 
SIP URI, there is a risk of disclosure to non-trusted intermediaries of 
information sensitive to the holder of the URI, such as their currently 
registered Contact.

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 07 Apr 2007 12:22:20 -0700

At Sat, 07 Apr 2007 13:45:12 -0500,
> given a sips: URI can deduce a sip: URI from that and use it.

I don't agree with that interpretation of the text. The fact that
you *registered* both a SIP URI and a SIPS URI does not mean
that other users should convert a sips: URI to a SIP one.
Here's the relevant text from page 7:

   Although not mandated specifically in [RFC3261], the implication is
   that a resource described by a SIPS URI can not be "downgraded" to a
   SIP URI by just changing the scheme, unless it is the "last hop
   exception" described in Section 3.  This specification clarifies that
   a resource described by a SIPS URI MUST NOT be "downgraded" to a SIP
   URI by changing the scheme, or by sending the associated request over
   a non secure link, except for cases where the "last-hop exception"
   rule is in effect (in which case the Request-URI would be replaced by
   a SIP URI).

> for a "login" service, you might have just given away your password.

Yes, and you shouldn't do that.

> information sensitive to the holder of the URI, such as their currently 

I think the text I quoted implies this

-Ekr

---

From: Dean Willis <[email-masked]>
Date: Sun, 08 Apr 2007 15:01:30 -0500

>    rule is in effect (in which case the Request-URI would be replaced by

I believe that paragraph has changed in the current pre-draft to say:

    This specification mandates that a resource described by a SIPS
    Request-URI can not be "downgraded" to a SIP URI when a proxy is
    forwarding a request by changing the scheme, or by sending the
    associated request over a non secure link.  See Section 4.2.

This refers only to a PROXY making the downgrade, not a USER making the 
downgrade.

Section 3.2 Routing says:

    For example, consider the case of a UA that has registered with SIPS
    contact header field.  If a UAC later addresses a request using a SIP
    Request-URI, the proxy will forward the request addressed to a SIP
    Request-URI to the endpoint, as illustrated by message F13 in
    Section 5.3 and in Section 5.4.  The proxy forwards the request to
    the UA using a SIP Request-URI and not the SIPS Request-URI used in
    registration (and it does this by substituting the sip scheme to the
    sips scheme in the registered contact header field binding).  If the
    proxy did not do this, and instead used a SIPS Request-URI, then the
    response (e.g., a 200 to an INVITE) would have to include a SIPS
    contact header field.  That SIPS contact header field would then
    force the other UA to use a SIPS contact header field in any mid-
    dialog request, including the ACK (which wouldn't be possible if that
    UA did not support SIPS).

The preceding says that IF a user converts SIPS to SIP, then the proxies 
will forward the request. This is further supported  in the following:

Section 4.1.2 page 12 says:

    Because registering with a SIPS contact header field implies a
    binding to both a SIPS Contact and a corresponding SIP Contact, a UA
    MUST NOT include both the SIPS and the SIP version of the same
    contact header field in a REGISTER: it MUST only use the SIPS version
    in this case.  Similarly, a UA SHOULD NOT register both a SIP contact
    header field and a SIPS contact header field in separate
    registrations as the SIP contact header field would be superfluous.
    Note however that a UA could register first with a SIP contact header
    field (meaning it does not support SIPS), and later register with a
    SIPS contact header field (meaning it now supports SIPS).

    If a UA wants to ensure that no requests are delivered without using
    TLS on that last hop, the UA MUST use [I-D.ietf-sip-outbound].

If we are in proxyless scenario, then we aren't using outbound, and the 
"last hop" is the UA to UA hop. Since the only way we have in the 
current text  to assure that TLS is used on this last hop is to use 
outbound, and we aren't using outbound, then we have NO WAY to assure 
that this hop is done using TLS.

Later in 4.1.2 we have:

    Location services
    are therefore free to map from SIP to SIPS URIs as appropriate (see
    [RFC3261]/26.4.4).  When Bob registers, it therefore does not really
    matter if he is using a SIP or a SIPS AOR, since they both refer to
    the same user.

All of these, taken together, say to me that it is reasonable for a user 
who is handed a business card with only a SIPS URI on it to guess an 
equivalent SIP URI and use it, and that the infrastructure will route 
this request to the UAS. If that UAS is NOT using "outbound", then the 
last hop may well be traversed without TLS.

Consequently, in the case that (unknown to the orignating user) there 
ARE no proxies (such as a simple UAC-->Location Server(302)--->UAS flow,
the content of the request will be delivered unprotected toward the UAS.
If there is a tap on the Line (aka sniffer), then the conent of that 
request will be revealed.

This turns out to be pretty important in a P2PSIP world, where there 
might be a lot less proxies.

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 08 Apr 2007 13:22:29 -0700

At Sun, 08 Apr 2007 15:01:30 -0500,

> will forward the request.

No, it doesn't, since it's quite possible the user was GIVEN a 
SIP URI.

> that this hop is done using TLS.

And as I've pointed out several times now, the only TECHNICAL way
to do so is to tell the peer to use TLS.

> last hop may well be traversed without TLS.

Well, I don't agree with this interpretation, but luckily since
we're writing the spec rather than interpretating it, we don't
have to engage in a lot of exegesis. I assert that if you're
given only SIPS URI you MUST NOT attempt to map it to a SIP
URI. Is there anyone who disagrees with this? If not, then
why don't you propose some language that you believe would make
this clear.

-Ekr

---

From: Dean Willis <[email-masked]>
Date: Sun, 08 Apr 2007 23:08:15 -0500

> why don't you propose some language that you believe would make

I agree!

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Apr 2007 09:12:11 -0400

> request will be revealed.

If there are no proxies, then the message won't be put on the wire until 
the connection has been established. If the UAS doesn't want to receive 
messages using TCP alone, then it can construct its DNS entry to 
indicate that it only accepts TLS.

I guess this could be a problem if the UAS doesn't use an FQDN as its 
contact address.

Perhaps this points up a in what we mean by downgrading. When talking 
about a proxy-registrar->UAS connection, what we have meant, I think, is 
that an incoming sip request can be sent over tls for the last hop, 
thereby allowing a single connection to be used for incoming calls that 
are either sip or sips. That is quite different from using a sips URI to 
establish a non-TLS connection to the target.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 9 Apr 2007 16:11:41 -0500

> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: Sunday, April 08, 2007 13:22
> To: Dean Willis
> Cc: [email-masked]

I agree with Eric. 

I will clarify.

---

From: "Hisham Khartabil" <[email-masked]>
Date: Fri, 13 Apr 2007 12:31:17 +1000

I thought option tags were for extension, not updates that fix broken protocols.

Hisham

---

From: "Hisham Khartabil" <[email-masked]>
Date: Fri, 13 Apr 2007 13:11:32 +1000

This is somehow tied with Jonathan's thread related to retargetting
and downgrading from sips to sip (or upgrading). If we agree to
disallow both, then we are also disallowing what is being discussed in
this thread.

If a UAS wants to be contactable with over UDP or TCP/TLS, then it can
register with 2 contact headers.

Hisham

---

From: Dean Willis <[email-masked]>
Date: Thu, 12 Apr 2007 23:01:55 -0500

> disallow both, then we are also disallowing what is being discussed in
Not really.

Upgrading and Downgrading, in the context of Johnathan's argument, occur 
when a proxy which was presented a URI of one scheme changes it to the 
other scheme.

What the current text describes is that registration of a SIPS contact 
implicitly registers the equivalent SIP contact. This doesn't mean that 
any proxy can translate SIPS to SIP or SIP to SIPS. Instead, it means 
that a user who has registered just SIPS can receive both sorts of 
requests. If the request originates with SIP it will be delivered, just 
as it would if it originated SIPS.

So you could put both SIP and SIPS on your business card, and a caller 
could just pick one.

What I was worried about is what happens when a user who is given only a 
SIPS URI translates it to SIP and uses that to make a request. It may 
well be that the user was given only a SIPS URI because the called party 
really wants their incoming traffic secured. There's no way to 
COMPLETELY fix this, although it can be fixed from the serving proxy to 
UAS by either 1) use of outbound over TLS, or 2) going to a per-scheme 
registration as you propose.

So what I asked for is just additional guidance to the user to reinforce 
the idea that they should not make this mistake. Not that users are 
really governed by RFCs, but some of them will make fewer mistakes if 
this sort of guidance is given.
> register with 2 contact headers.

Personally, I liked per-scheme registration. The WG didn't.

The reason I like it is that it removes the incentive to assume that a 
URI of a different scheme than the one you were given to use is likely 
to work. This makes mistakes less likely to happen.

--
Dean

---

From: "Hisham Khartabil" <[email-masked]>
Date: Fri, 13 Apr 2007 19:40:42 +1000

You are right in what you say Dean, but one thing I gotta comment on
is that I really doubt that people will be giving out business cards
with 2 sip addresses, one with sip: scheme and the other with sips:
scheme.

I vision it as one sip address, scheme is not mentioned at all in the
business card. The UI of the phone allows the user to select "secure
call" or a check box. So the scenarios are:

- I register with sips only. You call me without selecting "secure
call". Your call would fail
- I register with sips only. You call me and select "secure call".
Your call would succeed
- I register with sip only. You call me without selecting "secure
call". Your call would succeed
- I register with sip only. You call me and select "secure call". Your
call would fail
- I register both schemes, all calls succeed

> Personally, I liked per-scheme registration. The WG didn't.

I thought that was what the group agreed. Or? Ekr suggested a MUST NOT
and no one objected.

Hisham

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Apr 2007 09:20:05 -0400

> this sort of guidance is given.

I don't think so. For one thing, its quite likely that there is no 
business card. The caller may well just guess the sip/sips address from 
an email address. And even if given a sips address, they might not 
understand what that is and mistype it as sip, or they might use sip 
because the client they are using doesn't support sips.

I don't see what harm is being done to the callee in this case. In 
normal cases he can detect that the call was placed via sip and simply 
refuse to answer. If there was any important info in the request that 
might have been observed, it is info of the *caller*, who knew he was 
making an insecure call.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Apr 2007 09:41:30 -0400

Hisham,

I don't understand how you expect the registering of two schemes to 
work. Suppose the phone needs to use outbound. Are you suggesting that 
it needs to establish one outbound connection for sips and a different 
one for sip? Why would anyone want to incur that extra cost compared to 
simply receiving both sip and sips calls over the same connection?

	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Apr 2007 09:42:54 -0500

Paul Kyzivat wrote:
  . . .

> might have been observed, it is info of the *caller*, who knew he was 

No, it is the info of the CALLEE that I am worried about.

Let's take the very first INVITE example from RFC 3665, "Alice Calls Bob 
Directly".

    INVITE sip:[email-masked] SIP/2.0
    Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    Max-Forwards: 70
    From: Alice <sip:[email-masked]>;tag=9fxced76sl
    To: Bob <sip:[email-masked]>
    Call-ID: [email-masked]
    CSeq: 1 INVITE
    Contact: <sip:[email-masked];transport=tcp>
    Content-Type: application/sdp
    Content-Length: 151

    v=0
    o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
    s=-
    c=IN IP4 192.0.2.101
    t=0 0
    m=audio 49172 RTP/AVP 0
    a=rtpmap:0 PCMU/8000

This message reveals that the target Bob is reachable at host 
"biloxi.example.com".

Since traceroute on biloxi.example.com may well give us a good idea of 
the physical location of biloxi.example.com, an interceptor picking up 
this message would have a good chance of being able to find Bob.

Assuming that  this message is sent unencrypted when used with SIP 
(instead of SIPS), it's relatively easy to intercept.

The interceptor didn't need credentials to get into a location server 
that might translate [email-masked] to [email-masked]. They 
didn't need credentials to look in a directory server. They just pulled 
the information "off the wire" in such a way that Bob will be unable to 
know how the interceptor got his location.

The ONLY defenses Bob has against this sort of thing are:
1) use an outbound proxy with TLS, which only works in some architectures
2) Train everybody that calls him to use SIPS instead of SIP.

I'm looking for ways to encourage #2, and don't feel that the current 
"SIPS registrations mean you want SIP and SIPS to reach you" is helpful.

What other tricks migt apply? DNS configuration on biloxi.example.com, 
maybe?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Apr 2007 09:47:56 -0500

> simply receiving both sip and sips calls over the same connection?

Why couldn't both the SIP and SIPS registration share one TLS connection?

Here's another question. Say Bob is registering to a location server 
(that sends a 302). Bob register only a SIPS contact.

Alice sends a SIP INVITE to the location server, targeting Bob's AOR.

Does the 302 that comes back point to a SIP or SIPS target?

With singular registration of SIPS, it has to have both, right?   Or 
does the location server return only a SIP contact for a SIP query and a 
SIPS contact for a SIPS query?

How would we register such that the location server returns only a SIPS 
response?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Apr 2007 10:58:49 -0400

Dean Willis wrote:
>> business card. The caller may well just guess the sip/sips address 
>> from an email address. And even if given a sips address, they might 
>> not understand what that is and mistype it as sip, or they might use 
>> sip because the client they are using doesn't support sips.
>>

*This* message only reveals that Alice *thinks* Bob is reachable at that 
address. Its no worse than intercepting an email from Alice to Charlie 
that mentions the sip (or sips) address of Bob.

If you want to prevent Alice from disclosing the address of Bob then you 
have a much harder problem. I don't think this is solvable in practice, 
nor do I think it needs to be solved.

> this message would have a good chance of being able to find Bob.

No. Only Bob's home proxy.

> know how the interceptor got his location.

I don't see how this discloses the address [email-masked], which 
is the only one that Bob has any chance of hiding. All Bob needs to do 
is be careful in what he puts into his *response* to the above invite. 
(E.g. He shouldn't put his contact address if he is rejecting the call, 
and he should ensure his address isn't mentioned in a H-I header.) If he 
is really paranoid about this he could simply refuse to send any 
response to the invite, and let it timeout.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 13 Apr 2007 10:10:24 -0500

We went through this in Montreal.

My initial draft worked that way, and people didn't like it.

If you register with 2 contacts, you may end-up getting a request
forked to these two contacts.

Also, my initial draft was quite complicated because of this.

I will also point out that we do NOT do this with UDP versus
TCP transport. 

> From: Hisham Khartabil [mailto:[email-masked]] 
> Sent: Thursday, April 12, 2007 20:12
> To: Audet, Francois (SC100:3055)
> Cc: Eric Rescorla; Dean Willis; [email-masked]
> This is somehow tied with Jonathan's thread related to 
> retargetting and downgrading from sips to sip (or upgrading). 
> If we agree to disallow both, then we are also disallowing 
> what is being discussed in this thread.
> 
> If a UAS wants to be contactable with over UDP or TCP/TLS, 
> then it can register with 2 contact headers.
> 
> Hisham
> 
> > > Subject: Re: [Sip] SIPS question: How to prevent 
> plaintext requests 
> > > from being delivered to a UA
> > >
> > > we're writing the spec rather than interpretating it, we 
> don't have 
> > > to engage in a lot of exegesis. I assert that if you're 
> given only 
> > > SIPS URI you MUST NOT attempt to map it to a SIP URI. Is there 
> > > anyone who disagrees with this? If not, then why don't 
> you propose 
> > > some language that you believe would make this clear.
> >
> > I agree with Eric.
> >
> > I will clarify.
> >
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> >
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 13 Apr 2007 10:10:56 -0500

This draft IS an extension because it changes the normative behavior of
RFC 3261. 

> Sent: Thursday, April 12, 2007 19:31
> Cc: [email-masked]; Dean Willis
> Subject: Re: [Sip] SIPS issue: Option tag
> 
> > transport=tls parameter, may be registering explictly both SIP and 
> > SIPS contacts, may be using the last hop-exception, etc.). 
> Proxies and 
> > UAs that support these legacy UAs would therefore use 
> whatever coping 
> > techniques that would "work".
> >

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 13 Apr 2007 10:23:33 -0500

> The interceptor didn't need credentials to get into a 
> location server that might translate [email-masked] to 
> [email-masked]. They didn't need credentials to look 
> in a directory server. They just pulled the information "off 
> the wire" in such a way that Bob will be unable to know how 
> the interceptor got his location.
> 

Euh, not. There is also 3)

3) Have a policiy in the proxy associated with Bob of not
   delivering anything but sips.

This whole debate is kind of ridiculous.

It all boils down to this: either the end-user (Bob) is responsible
for enforcing absolute privacy on the last hop, or (more likely), Bob's 
proxy is responsible for doing so. Or both.

The end-user mechanism is solved by Outbound. 

The m proxy mechanism is solved by the proxy not delivering
anything but SIPS in this case.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 13 Apr 2007 11:38:21 -0500

Exactly.

First three versions of the individual draft worked with multiple
contacts:
https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-audet-sip-sips-g
uidelines-00.txt 
https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-audet-sip-sips-g
uidelines-01.txt
https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-audet-sip-sips-g
uidelines-02.txt

Starting from -03 (individual), it shifted to the current model.
https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-audet-sip-sips-g
uidelines-03.txt

And again, with TCP and UDP today, we do NOT use explicit registration.

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Friday, April 13, 2007 06:42
> To: Hisham Khartabil
> Cc: Dean Willis; [email-masked]; Audet, Francois (SC100:3055)
> I don't understand how you expect the registering of two 
> schemes to work. Suppose the phone needs to use outbound. Are 
> you suggesting that it needs to establish one outbound 
> connection for sips and a different one for sip? Why would 
> anyone want to incur that extra cost compared to simply 
> receiving both sip and sips calls over the same connection?

---

From: "Hisham Khartabil" <[email-masked]>
Date: Sun, 15 Apr 2007 12:30:49 +1000

Its an update as far as I'm concerned, not an extension.

Hisham

---

From: Dean Willis <[email-masked]>
Date: Sun, 15 Apr 2007 22:48:42 -0500

On Apr 13, 2007, at 9:58 AM, Paul Kyzivat wrote:

> *This* message only reveals that Alice *thinks* Bob is reachable at  
> that address. Its no worse than intercepting an email from Alice to  
> Charlie that mentions the sip (or sips) address of Bob.
>

Trust me, the spooks look for those too.

> If you want to prevent Alice from disclosing the address of Bob  
> then you have a much harder problem. I don't think this is solvable  
> in practice, nor do I think it needs to be solved.

If Alice had just not sent the request via SIP, but used SIPS, the it  
would have been solved.
>
>> Since traceroute on biloxi.example.com may well give us a good  
>> idea of the physical location of biloxi.example.com, an  
>> interceptor picking up this message would have a good chance of  
>> being able to find Bob.
>

In the call flow described (from 3665) there is no home proxy.

THERE IS NO REQUIREMENT THAT SIP USERS HAVE A HOME PROXY AND I WOULD  
BE VERY HAPPY IF PEOPLE WOULD REMEMBER THAT!

But IF there had been a home proxy in this example, and the request  
were intercepted between Bob's home proxy and Bob, then it would  
reveal Bob's location as understood by Bob's home proxy.

>> The interceptor didn't need credentials to get into a location  
>> server that might translate [email-masked] to  
>> [email-masked]. They didn't need credentials to look in a  
>> directory server. They just pulled the information "off the wire"  
>> in such a way that Bob will be unable to know how the interceptor  
>> got his location.
>
> I don't see how this discloses the address [email-masked],  
> which is the only one that Bob has any chance of hiding. All Bob  
> needs to do is be careful in what he puts into his *response* to  
> the above invite. (E.g. He shouldn't put his contact address if he  
> is rejecting the call, and he should ensure his address isn't  
> mentioned in a H-I header.) If he is really paranoid about this he  
> could simply refuse to send any response to the invite, and let it  
> timeout.

It discloses"[email-masked]" by the very simple mechanism of  
including both "[email-masked]" and "[email-masked]" in a  
plain-text message. This disclosure occurs even if Bob never responds  
to the request, and even if bob never even RECEIVES the request.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sun, 15 Apr 2007 22:52:54 -0500

>    delivering anything but sips.

#3 only works if all the proxies between Bob and Bob's home proxy  
have this policy. For example, Bob's edge proxy may be different from  
Bob's home proxy.

> This whole debate is kind of ridiculous.

Only inasmuch as it illustrates how little this community understands  
information security.

> proxy is responsible for doing so. Or both.

I'm not talking about JUST the last hop. It might be the only hop,  
and there are possible leakages on the "first hop" as well.

> The end-user mechanism is solved by Outbound.

Only if an outbound proxy is used. P2P very well might not have  
outbound proxies. Remember, SIP DOES NOT REQUIRE YOU TO ALWAYS USE A  
PROXY.

--
Dean

---

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 16 Apr 2007 16:45:39 +1000

> simply receiving both sip and sips calls over the same connection?

Are you talking about flows? I'm not suggesting 2 different flows, not
TCP connections for that matter. Is there any restriction on using the
same flow-id for both?

Hisham

---

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 16 Apr 2007 16:47:51 +1000

> forked to these two contacts.

Not if the normative text says that the proxy MUST only retarget the
request to the contact that has the same security level.

Hisham

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 16 Apr 2007 08:47:42 -0500

> #3 only works if all the proxies between Bob and Bob's home 
> proxy have this policy. For example, Bob's edge proxy may be 
> different from Bob's home proxy.

Dean, the request in this scenario 
was sent out over non-TLS sent with sips in
the first place. The damage done.

If a proxy in the middle want to upgrade to sip, it can just
send a 3XX with Contact: sips

> 
> Only if an outbound proxy is used. P2P very well might not 
> have outbound proxies. Remember, SIP DOES NOT REQUIRE YOU TO 
> ALWAYS USE A PROXY.

Dean, the request was sent using SIP in the first place. If there
is no proxy, then the 3XX solution makes more sense.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Apr 2007 13:08:44 -0400

Dean Willis wrote:
>> If you want to prevent Alice from disclosing the address of Bob then 
>> you have a much harder problem. I don't think this is solvable in 
>> practice, nor do I think it needs to be solved.
> 

Unless Alice believes that the address itself is a secret to be 
protected, she may not protect it.

AFAIK, there has never been any expectation that the presence of "sips" 
in the URI carried an expectation that somebody possessing such an 
address keep it confidential. Quite to the contrary, I have assumed that 
the expectation was that it might be put on business cards, stored in 
directories, ENUM, etc.

>>> Since traceroute on biloxi.example.com may well give us a good idea 
>>> of the physical location of biloxi.example.com, an interceptor 
>>> picking up this message would have a good chance of being able to 
>>> find Bob.
>>
> THERE IS NO REQUIREMENT THAT SIP USERS HAVE A HOME PROXY AND I WOULD BE 
> VERY HAPPY IF PEOPLE WOULD REMEMBER THAT!

Its fine for there to be no home proxy. But if so, then Bob must 
publicize his actual address, and expect that bad guys may get access to it.

> But IF there had been a home proxy in this example, and the request were 
> intercepted between Bob's home proxy and Bob, then it would reveal Bob's 
> location as understood by Bob's home proxy.

I thought the idea was that Bob himself had only the sips address. So 
the link between Bob's home proxy and Bob would always be via TLS. So 
the message won't be intercepted on that leg. It would have to be 
intercepted before reaching his home proxy. And there it would only 
reveal his AOR.

>>> didn't need credentials to look in a directory server. They just 
>>> pulled the information "off the wire" in such a way that Bob will be 
>>> unable to know how the interceptor got his location.
>>
>> which is the only one that Bob has any chance of hiding. All Bob needs 
>> to do is be careful in what he puts into his *response* to the above 
>> invite. (E.g. He shouldn't put his contact address if he is rejecting 
>> the call, and he should ensure his address isn't mentioned in a H-I 
>> header.) If he is really paranoid about this he could simply refuse to 
>> send any response to the invite, and let it timeout.
> 
> plain-text message. This disclosure occurs even if Bob never responds to 
> the request, and even if bob never even RECEIVES the request.

I guess we are making some significantly different assumptions about 
what is going on.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Apr 2007 13:16:28 -0400

> TCP connections for that matter. Is there any restriction on using the

I was thinking two flows. If you meant only a single flow for both, then 
once concern is removed.

So you mean both a sip and sips contact would be registered over the 
same (tls) flow. As Francois said, he proposed this long ago and it was 
rejected for a bunch of reasons. The only benefit I can see to this is 
as a way to indicate a policy regarding whether sip requests are/aren't 
desired over this flow. Things will work just fine without that policy 
(the UAS can simply reject them if it wishes). It complicates a lot of 
things so I prefer to stick with what was already decided about this.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 16 Apr 2007 13:56:34 -0500

Thank you.

I agree with Paul. 

> Sent: Monday, April 16, 2007 10:16
> To: Hisham Khartabil
> schemes to 
> >> work. Suppose the phone needs to use outbound. Are you suggesting 
> >> that it needs to establish one outbound connection for sips and a 
> >> different one for sip? Why would anyone want to incur that 
> extra cost 
> >> compared to simply receiving both sip and sips calls over 
> the same connection?
> > 
> I was thinking two flows. If you meant only a single flow for 
> both, then once concern is removed.
> 
> So you mean both a sip and sips contact would be registered 
> over the same (tls) flow. As Francois said, he proposed this 
> long ago and it was rejected for a bunch of reasons. The only 
> benefit I can see to this is as a way to indicate a policy 
> regarding whether sip requests are/aren't desired over this 
> flow. Things will work just fine without that policy (the UAS 
> can simply reject them if it wishes). It complicates a lot of 
> >> >> Upgrading and Downgrading, in the context of 
> Johnathan's argument, 
> >> occur
> >> >> implicitly registers the equivalent SIP contact. This 
> doesn't mean 
> >> that
> >> >> requests. If the request originates with SIP it will be 
> delivered, 
> >> just
> >> >> What I was worried about is what happens when a user 
> who is given 
> >> only a
> >> >> well be that the user was given only a SIPS URI because 
> the called 
> >> party
> >> >> > If a UAS wants to be contactable with over UDP or 
> TCP/TLS, then 
> >> it can

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Apr 2007 00:37:05 -0500

> the first place. The damage done.
Huh? No, the request was sent SIP because the user or user's UA chose to 
downgrade from the SIPS URI they had been given.

> send a 3XX with Contact: sips

Sure. If there's a proxy in the middle, and the damage wasn't already 
done by leakage
> is no proxy, then the 3XX solution makes more sense.

Yes, that's exactly my point. If you're given a SIPS URI, use it. Don't 
downgrade to SIP. Ever. Not at a proxy, not at a UA, not at a user.

And text (which we have) that effectively says "If the user registers 
with SIPS it means they want to receive both SIP and SIPS requests" is
dangerously misleading, because it encourages the user to downgrade and 
expect it to work.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Apr 2007 00:47:29 -0500

> protected, she may not protect it.

Exactly my point. She needs to KNOW that if she's given a SIPS address, 
that it should be protected by using it only for SIPS requests.

>
> AFAIK, there has never been any expectation that the presence of 
> "sips" in the URI carried an expectation that somebody possessing such 
> an address keep it confidential. Quite to the contrary, I have assumed 
> that the expectation was that it might be put on business cards, 
> stored in directories, ENUM, etc.

True. But if I give you my private unlisted number for encrypted calls 
and you start posting it on web pages with text that says "For a good 
time, call" , I'm gonna be angry. And I'll be only marginally less angry 
if you start schlepping it across the net in unprotected SIP INVITEs.

> publicize his actual address, and expect that bad guys may get access 
But Bob may publicize his actual address only within the confines of a 
directory or location server that makes that address available only to 
authenticated and authorized parties.

Alice sends INVITE for Bob' s SIPS AOR to Bob's LS.
Bob's LS returns a WWW-Auth to Alice.
Alice replies with credentials.
Bob's LS returns a SIPS contact.
Alice sends a SIP INVITE to the equivalent contact.

This is perfectly legal by the current draft as I understand it, and 
Alice would expect that it would work.

But it will completely compromise the secrecy of Bob's AOR->Contact 
binding, and Bob has no way to say "DON"T DO THIS TO ME!".

> intercepted before reaching his home proxy. And there it would only 

No, that wasn't the case I was trying to (and apparently failing to) 
explain.
> I guess we are making some significantly different assumptions about 
Ah, that's probably true.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Apr 2007 00:53:25 -0500

Paul Kyzivat wrote:
> same (tls) flow. As Francois said, he proposed this long ago and it 
> was rejected for a bunch of reasons. The only benefit I can see to 
> this is as a way to indicate a policy regarding whether sip requests 
> are/aren't desired over this flow. Things will work just fine without 
> that policy (the UAS can simply reject them if it wishes). It 
> complicates a lot of things so I prefer to stick with what was already 
> decided about this.

No, this DOESN'T work fine, as the privacy of the UAS's AOR-to-Contact 
binding is compromised by sending the request from the UAC, even if the 
UAS rejects the request.

If the sender KNEW that the UAS only accepted SIPS, this compromise 
would not occur.

And if the sender is given only a SIPS URI for an AOR, the sender MUST 
assume that the UAS accepts only SIPS requests and MUST NOT send a 
request to that AOR using SIP. Otherwise, the privacy of the UAS's 
AOR-to-Contact binding might be compromised (and in security, one can 
assume that if it might be compromised, it probably has been-- It's 
tainted).

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Apr 2007 08:55:27 -0400

Dean,

I think you are trying to associate two distinct semantics with sips URI:
- that sessions established using this URI should be secured
   hop by hop from end to end
- that such a URI should be considered "unlisted" and so kept
   "secret".

IMO these semantics should not be conflated because:

- I may want to have a sip (or tel or IM or PRES) URI
   that is "unlisted", and I may want to have a sips URI
   that is "listed".

- The semantics of of being "unlisted" are likely to be
   just as hard to pin down as the semantics of sips for
   e22 security is. IMO we don't want to hold up the clarification
   of sips until that can be done.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Apr 2007 09:07:05 -0400

> binding is compromised by sending the request from the UAC, even if the 

The above is discussing *registrations*, which implies the presence of a 
registrar. In most cases, the UAC is not the registrar and does not have 
access to the location service used by the registrar. The UAC sends 
requests to the AOR. Those requests are serviced by something that does 
have access to the location service.

The UAC sending a request to the AOR does not compromise the UAS's 
Contact binding. That can be compromised in two ways:

- if the "home proxy" translates the AOR to the contact and then
   forwards the request over in insecure link. If its a sips contact
   we have already banned that.

- if the "home proxy" responds with a 3xx containing the registered
   contact of the UAS. If the request had been unsecured then the
   contact may indeed be compromised. (Note that doing this is
   considered a *feature* in a number of scenarios. For instance if
   the UAC has "guessed" at a sip AOR, and is then told it must use
   a sips AOR to contact this UAS.) This is a policy issue of whether
   the home proxy *should* disclose the contact addresses, and if so,
   with what constraints.

> If the sender KNEW that the UAS only accepted SIPS, this compromise 

How would the sender know that? I might be trying to call you by 
guessing your sip address from your email address.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 17 Apr 2007 08:51:32 -0500

> > was sent out over non-TLS sent with sips in the first place. The 
> > damage done.
> >
> >   
> Huh? No, the request was sent SIP because the user or user's 
> UA chose to downgrade from the SIPS URI they had been given.

No, the UA can not downgrade and still be compliant.

That is clear in the draft.

> > Dean, the request was sent using SIP in the first place. If 
> there is 
> > no proxy, then the 3XX solution makes more sense.
> >
> >   
> 
> Yes, that's exactly my point. If you're given a SIPS URI, use 
> it. Don't downgrade to SIP. Ever. Not at a proxy, not at a 
> UA, not at a user.

I think everybody agrees on this. 

So we are in agreement.

> dangerously misleading, because it encourages the user to 

Read the new version and let me know if it is still ambiguous, because
the text doesn't really say that. It has lots of information on how
to make it work if you do NOT wish to be reachable with SIP over
non-TLS.
Both from the perspective of the User and from the perspective of the 
Proxy.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 17 Apr 2007 08:53:27 -0500

Dean, you are talking about a different case.

Nobody is suggesting that if you are given a SIPS URI you
should also assume that a SIP URI will work.

I think it's pretty obvious. 

> Sent: Monday, April 16, 2007 22:53
> To: Paul Kyzivat
> Cc: Hisham Khartabil; [email-masked]; Audet, Francois (SC100:3055)
> over the 
> No, this DOESN'T work fine, as the privacy of the UAS's 
> AOR-to-Contact binding is compromised by sending the request 
> from the UAC, even if the UAS rejects the request.
> 
> If the sender KNEW that the UAS only accepted SIPS, this 
> compromise would not occur.
> 
> And if the sender is given only a SIPS URI for an AOR, the 
> sender MUST assume that the UAS accepts only SIPS requests 
> and MUST NOT send a request to that AOR using SIP. Otherwise, 
> the privacy of the UAS's AOR-to-Contact binding might be 
> compromised (and in security, one can assume that if it might 
> be compromised, it probably has been-- It's tainted).
> 
> --
> Dean
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Apr 2007 10:22:31 -0400

> I think everybody agrees on this. 

Well...

IMO its pointless to base any decisions on the assumption that everyone 
will conform to the above.

It sounds good until a user with a UA that doesn't support sips wants to 
call somebody that he only has a sips URI for. At that point his choices 
are:
- give up
- try the downgraded URI

If there is *any* chance that downgrading will work then a lot of users 
will try it. And even if there is *no* chance of it working some number 
of users will try it. And its quite likely that often the downgrading 
will be done by *mistake*, by somebody that does understand there is a 
difference between sip and sips.

And it probably *will* work in a lot of cases, because a lot of people 
will want to support both.

So, you can say that users SHOULD NOT do it, or MUST NOT do it, but 
assume that it will be done anyway.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 17 Apr 2007 09:38:02 -0500

Yes, and the UAS or it's proxy can reject the request. 

That is covered.

> Sent: Tuesday, April 17, 2007 07:23
> Cc: Dean Willis; [email-masked]
> >> Yes, that's exactly my point. If you're given a SIPS URI, use it. 
> >> Don't downgrade to SIP. Ever. Not at a proxy, not at a UA, 
> not at a 
> >> user.
> > 
> IMO its pointless to base any decisions on the assumption 
> that everyone will conform to the above.
> 
> It sounds good until a user with a UA that doesn't support 
> sips wants to call somebody that he only has a sips URI for. 
> At that point his choices
> are:
> - give up
> - try the downgraded URI
> 
> If there is *any* chance that downgrading will work then a 
> lot of users will try it. And even if there is *no* chance of 
> it working some number of users will try it. And its quite 
> likely that often the downgrading will be done by *mistake*, 
> by somebody that does understand there is a difference 
> between sip and sips.
> 
> And it probably *will* work in a lot of cases, because a lot 
> of people will want to support both.
> 
> So, you can say that users SHOULD NOT do it, or MUST NOT do 
> it, but assume that it will be done anyway.
> 
> 	Paul
>

---

From: "Charles Eckel \(eckelcu\)" <[email-masked]>
Date: Tue, 17 Apr 2007 08:29:16 -0700

I think this is different than listed vs. unlisted. 
If I register a SIPS URI with my registrar and receive only SIPS calls,
then no one except my registrar and perhaps the folks that successfully
contact me, know the details of my registration binding(s). A 3rd party
would not know who I am or who called me.
If someone calls me using SIP, all of this can be learned by a 3rd party
observing the traffic, even if I reject the request.
Note, I am assuming the SIP request was not sent via TLS for at least
one hop. If each hop uses TLS, then it really does not matter whether
the URI was SIP or SIPS.

Cheers,
Charles  

> From: Paul Kyzivat (pkyzivat) 
> Sent: Tuesday, April 17, 2007 5:55 AM
> To: Dean Willis
> Cc: [email-masked]
> requests from beingdelivered to a UA
> 
> Dean,
> 
> >> publicize his actual address, and expect that bad guys may 
> get access 
> >> to it.
> >>

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Apr 2007 12:40:31 -0500

>   of sips until that can be done.

What I'm trying to say is that if you were given a SIPS URI, you  
should use SIPS instead of SIP for that callee, because if you  
downgrade to SIP there could be negative consequences. One such  
negative consequence might be the disclosure of a name-to-address  
binding that the callee did not desire to have disclosed. Since we  
currently have no way to express that desire, the safest thing to do  
is to protect it where feasible.

In other words, "be conservative in what we send".

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Apr 2007 12:42:08 -0500

> That is clear in the draft.

It wasn't clear to me at the last reading. Maybe it is now.

> Both from the perspective of the User and from the perspective of the

Will do.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Apr 2007 12:45:12 -0500

On Apr 17, 2007, at 9:22 AM, Paul Kyzivat wrote:

>>> Don't downgrade to SIP. Ever. Not at a proxy, not at a UA, not at  
>>> a user.
>> I think everybody agrees on this. So we are in agreement.
>
> Well...
>
> IMO its pointless to base any decisions on the assumption that  
> everyone will conform to the above.
>
> It sounds good until a user with a UA that doesn't support sips  
> wants to call somebody that he only has a sips URI for. At that  
> point his choices are:
> - give up
> - try the downgraded URI
>
> If there is *any* chance that downgrading will work then a lot of  
> users will try it. And even if there is *no* chance of it working  
> some number of users will try it. And its quite likely that often  
> the downgrading will be done by *mistake*, by somebody that does  
> understand there is a difference between sip and sips.
>
> And it probably *will* work in a lot of cases, because a lot of  
> people will want to support both.
>

right.

My intent with some of my suggestions is to reduce the probability  
that it will work, thereby reducing the inclination to try it.

I think it may also be important to address mechanisms for making it  
obvious to the sender (as it already is to the home proxy, should  
there be one that is used with outbound) that it will not work.  
Separate registrations is one possible way to do this.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Apr 2007 12:46:32 -0500

> Yes, and the UAS or it's proxy can reject the request.

But what is NOT covered is a way to advise the sender that it is NOT  
likely to work. This would keep them from sending the request (and  
thereby creating the problem) in some use-cases.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 17 Apr 2007 12:47:34 -0500

> Separate registrations is one possible way to do this.

No, segregated registration will not work. It just would result in 
forking.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 17 Apr 2007 13:02:42 -0500

I am even more lost now.

If the user is given a SIPS URI, he should not assume that a SIP URI
will
also work. We all agree on that.

If you want to be reachable in by both sip and sips put both on your
business
card. If you only want sips, put sips. If you only want sip, put sip
only.

We've discussed ad nauseam how this can be rendered "on the wire". 

> Sent: Tuesday, April 17, 2007 10:47
> Cc: Paul Kyzivat; [email-masked]
> But what is NOT covered is a way to advise the sender that it 
> is NOT likely to work. This would keep them from sending the 
> request (and thereby creating the problem) in some use-cases.
> 
> --
> Dean
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Apr 2007 14:27:08 -0400

Dean Willis wrote:
>>>> Don't downgrade to SIP. Ever. Not at a proxy, not at a UA, not at a 
>>>> user.
>> It sounds good until a user with a UA that doesn't support sips wants 
>> to call somebody that he only has a sips URI for. At that point his 
>> choices are:
>> - give up
>> - try the downgraded URI
>>
>> users will try it. And even if there is *no* chance of it working some 
>> number of users will try it. And its quite likely that often the 
>> downgrading will be done by *mistake*, by somebody that does 
> My intent with some of my suggestions is to reduce the probability that 
> it will work, thereby reducing the inclination to try it.

I think it would be mildly interesting (low priority) to devise some way 
  of indicating that an address is to be treated as confidential. It 
would require a bunch of rules about who it may and may not be disclosed 
to, etc.

But I don't think the sips scheme is the right way to accomplish that.

	Paul

> obvious to the sender (as it already is to the home proxy, should there 
> be one that is used with outbound) that it will not work. Separate 
> registrations is one possible way to do this.
> 
> -- 
> Dean
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 17 Apr 2007 13:29:55 -0500

>   of indicating that an address is to be treated as 
> confidential. It would require a bunch of rules about who it 
> may and may not be disclosed to, etc.
> 

Agreed.

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 17 Apr 2007 14:02:30 -0500

Why we need for this SIPS URI scheme at all. Extend the 
http://www.ietf.org/rfc/rfc3840.txt  UA Capibility framework for this. 

Thx
Samir

>Sent: Tuesday, April 17, 2007 10:41 AM
>To: Paul Kyzivat
>Cc: [email-masked]
>What I'm trying to say is that if you were given a SIPS URI, 
>you should use SIPS instead of SIP for that callee, because if 
>you downgrade to SIP there could be negative consequences. One 
>such negative consequence might be the disclosure of a 
>name-to-address binding that the callee did not desire to have 
>disclosed. Since we currently have no way to express that 
>desire, the safest thing to do is to protect it where feasible.
>

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 18 Apr 2007 15:14:11 +1000

You can't stop users from trying it a sip uri if they were given a
sips uri. I doubt that people will know the difference between sips
and sip. They will get a telephone number or a telephone (sip)
address.

You can, however, make intermediaries block it by sending a 3xx or 4xx
response. I think this should be a MUST behaviour for proxies. The
caller can then be presented with the option "this call could not be
completed securely, would you like to try an insecure call".

The question I have is how does the UA that registers tell the home
proxy that it wants to be contacted on a sip uri, sips uri or both.
Paul does not like the multiple registration idea. How else?

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Apr 2007 11:08:45 -0500

> Paul does not like the multiple registration idea. How else?

That's another way of approaching the question I've been trying to ask.

A SIP registration means that the UA wants only SIP requests and can  
or will not handle SIPS.

It is proposed that a SIPS registration means that the UA can handle  
both SIP and SIPS requests.

How does a UA register to get only SIPS requests?

Francois' draft talks about this being set by proxy policy:

    Proxies MAY have their own policy regarding routing of requests to
    SIP or SIPS URIs.  For example, a proxy in a critical environment  
may
    be configured to only route SIPS.

I'm not entirely confident that this is adequate, and want some way  
for the registering UA to be able to declare that it only wants SIPS  
requests.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Apr 2007 12:29:57 -0400

Dean Willis wrote:
> A SIP registration means that the UA wants only SIP requests and can or 
> will not handle SIPS.
> 
>    SIP or SIPS URIs.  For example, a proxy in a critical environment may
> I'm not entirely confident that this is adequate, and want some way for 
> the registering UA to be able to declare that it only wants SIPS requests.

My first question is:

What fraction of users will want to do that?

I expect it is quite small. If I am right, forcing the remainder to 
register two contacts rather than one seems like a bad choice.

The only problem I can see with doing this by policy is that there is no 
standard for invoking the policy, and no guarantee than any particular 
registrar will support that policy. Nevertheless I don't consider this 
to be very much of a problem.

	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 18 Apr 2007 19:35:12 +0300 (EEST)

> register two contacts rather than one seems like a bad choice.

this is a common practice with http servers.  for example,
http://tutpro.com is refused, but https://tutpro.com is not.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 18 Apr 2007 20:23:28 +0300

Paul Kyzivat writes:

 > Sure. But SIP is not HTTP. I realize that in *theory* there could be 
 > lots of targets that only want to use SIPS. But in *practice* where are 
 > those going to come from? In general I want to be able to receive calls 
 > even if the caller is unwilling or unable to use SIPS.

i agree with you and don't see any use for sips.  tls transport, on the
other hand, is useful.  for example, i'm connected to a public wifi AP
and don't want the next guy to see whom i'm calling.  so i'll use sip
uri scheme, but tls transport.  that guarantees that i'm able to reach
my destination even if it only supports sip.

is it so that transport=tls does not exist?  if so, it is plain stupid.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Apr 2007 12:38:59 -0500

> is it so that transport=tls does not exist?  if so, it is plain  

You can do what you seem to want to do above without using  
transport=tls by using draft-ietf-sip-outbound and registering over a  
TLS connection.

This has the added benefit of providing TLS security on inbound  
requests, so that the "next guy" can not see who you are calling and  
he can not see who is calling you.

The use case I've been worrying about is what happens when there is  
no "outbound" proxy and we have a UA to UA flow.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 Apr 2007 12:59:25 -0500

To resolve this, we need to do the following:

- Decide if it is a requirement that the UA be able to tell its
  home proxy that it wants to be contacted ONLY by SIPS. (the
  other cases, SIP only and SIP+SIPS are already covered by the draft).
  As Dean point out, it is ALREADY doable on the Proxy side. Again,
  the question is "how does the client tell it's preference to the 
  proxy".
	- I'd like to see a clear articulation of why this is a
requirement.
	  Seems to me that systems that require that level of security
        would normally have this set-up as a policy on the proxy as
        opposed to the end-user (this is the error-prone end-user 
        problem, as exemplified by the Dick Cheney use case).

- In the affirmative, the next question is "WHY ISN'T sip-outbound an 
  adequate solution"?

	- I'd like to see a clear articulation of why sip-outbound isn't

	  an adequate solution. I am quite worried about proliferating 
        solutions

	- If we can get a good explanation of why we need something that
        is not sip-outbound, then we need to define the mechanism.

	- There was a proposal on the list that something like caller
        pref would be appropriate.

> Sent: Wednesday, April 18, 2007 09:09
> To: Hisham Khartabil
> Cc: Paul Kyzivat; [email-masked]; Audet, Francois (SC100:3055)
> A SIP registration means that the UA wants only SIP requests 
> and can or will not handle SIPS.
> 
> It is proposed that a SIPS registration means that the UA can 
> handle both SIP and SIPS requests.
> 
> I'm not entirely confident that this is adequate, and want 
> some way for the registering UA to be able to declare that it 
> only wants SIPS requests.
> 
> --
> Dean
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Apr 2007 12:46:07 -0400

I know there are exceptions (e.g. the military, and the President), but 
its my *assumption* that this will be a small number. (I don't know how 
to get real numbers on this.)

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 Apr 2007 13:31:40 -0500

Agreed.

And a system where the policy is not set up on the Proxy seems like a 
really bad idea to me for those cases.

So I don't see any problem needing fixing here. 

> Sent: Wednesday, April 18, 2007 09:46
> To: Juha Heinanen
> Cc: [email-masked]; Audet, Francois (SC100:3055); Dean Willis
> Sure. But SIP is not HTTP. I realize that in *theory* there 
> could be lots of targets that only want to use SIPS. But in 
> *practice* where are those going to come from? In general I 
> want to be able to receive calls even if the caller is 
> unwilling or unable to use SIPS.
> 
> I know there are exceptions (e.g. the military, and the 
> President), but its my *assumption* that this will be a small 
> number. (I don't know how to get real numbers on this.)
> 
> 	Paul
>

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 18 Apr 2007 21:33:59 +0300

> he can not see who is calling you.

good and thus one more reason to junk sips.  we can just say that a
proxy should use tls if it supports it.

 > no "outbound" proxy and we have a UA to UA flow.

that is a very rare case unless you have some kind of p2p sip setup.

-- juha

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 18 Apr 2007 13:39:14 -0500

>
>good and thus one more reason to junk sips.  we can just say 
>that a proxy should use tls if it supports it.
>

I am sure that Cullen must be listening this.

Thx
Samir

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2007 11:47:54 -0700

At Wed, 18 Apr 2007 21:33:59 +0300,
> proxy should use tls if it supports it.

For the nth time, this doesn't provide the same properties as sips,
which, to repeat, are:

1. The callee can indicate that he can be contacted via TLS.
2. The caller can indicate to every proxy that the messages
   should be carried over TLS or not at all.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 18 Apr 2007 13:55:13 -0500

In line.
Thx
Samir 

>For the nth time, this doesn't provide the same properties as 
>sips, which, to repeat, are:
>

With all respect, I have to state that Either use Require header in the
REGISTER message or extend the UA capability framework to be contacted
on the secure channel ONLY or both.
This doesn't enforce two contacts. 

I mentioned sometime back from my puristice view "THIS IS A SECURE
ROUTING REQUIREMENT and to be REACHABLE via SECURE CHANNEL". This needs
to be fullfilled with Proxy-Require and Require. We are seeing so many
issues with SIPS, as we put these together  in the RESOURCE PROPERTY
namely SIPS URI scheme. In HTTP there is VERY THIN line between RESOURCE
and ROUTING, so we don't see so many issues. Here in SIP we have VERY
THICK line between RESOURCE and ROUTING, so we are witnessing so many
issues. Again SIP != HTTP.

>   should be carried over TLS or not at all.

Same as above.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2007 13:19:08 -0700

At Wed, 18 Apr 2007 13:55:13 -0500,
> This doesn't enforce two contacts. 

The Require header is not enough because it needs to be indicated
*to the caller*.

As previously noted, this indicator needs to be in the URI in
order to provide referential integrity. Yes, some other mechanism
than SIPS could be used to place it in the URI, but it's not at
all clear to me that inventing something new there would offer
a significant advantage.

-Ekr

---

From: Ted Hardie <[email-masked]>
Date: Wed, 18 Apr 2007 13:47:25 -0700

>all clear to me that inventing something new there would offer

I think the advantage which Dean and others allude to is that it would allow
you to shrink from two URI schemes to one; it also might eliminate the
non-TLS SIPS exception cases in Section 26.2.2/26.4.4 of RFC 3261.   Those
may or may not be significant advantages, depending on how much
of a problem you see the SIP/SIPS conversion to be.

I think a lot of Dean's basic issue is covered in 26.4.4:

  End users will undoubtedly discern the difference between SIPS and
   SIP URIs, and they may manually edit them in response to stimuli.
   This can either benefit or degrade security.  For example, if an
   attacker corrupts a DNS cache, inserting a fake record set that
   effectively removes all SIPS records for a proxy server, then any
   SIPS requests that traverse this proxy server may fail.  When a user,
   however, sees that repeated calls to a SIPS AOR are failing, they
   could on some devices manually convert the scheme from SIPS to SIP
   and retry.  Of course, there are some safeguards against this (if the
   destination UA is truly paranoid it could refuse all non-SIPS
   requests), but it is a limitation worth noting.  On the bright side,
   users might also divine that 'SIPS' would be valid even when they are
   presented only with a SIP URI.

If a user is willing to knowingly try something that degrades security,
there is not much changing where the information resides in the URI
is going to do to improve the situation.  If you added a new uri-parameter
to handle this, it seems likely to me that the same user who shifts
from sips to sip is going to try stripping it off to see if the bare URI
still works.  It also seems less likely to me that people will put
heavily adorned URIs on business cards and the like; to me, that argues
for not shifting to a uri-parameter.  There may, of course, be other ways
of getting it into the URI, but that is the one that strikes me as most
likely.

			regards,
				Ted Hardie

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2007 13:53:42 -0700

At Wed, 18 Apr 2007 13:47:25 -0700,
Ted Hardie wrote:
> you to shrink from two URI schemes to one;

I'm not sure that this improves the situation much.

> it also might eliminate the

Well, those exception cases need to be removed in any case. The
current proposal is simply to remove them from SIPS by fiat.
Basically, ISTM that we're going to need something with essentially
the same semantics as it's being proposed SIPS have now...

> of getting it into the URI, but that is the one that strikes me as most

Yes, I agree with this analysis... But unless I misread your message,
this is an argument *for* SIPS.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 18 Apr 2007 16:45:36 -0500

Hi Eric,

  in-line. 

Thx
Samir

>
>The Require header is not enough because it needs to be 
>indicated *to the caller*.

Require header gives the semantics to LS (with or without Proxy) to use
the binding only for the request which comes securely to it. If request
doesn't come securely, then indicate some 4xx code to caller. If I have
misunderstood your point, please clarify.

>order to provide referential integrity. Yes, some other 
>mechanism than SIPS could be used to place it in the URI, but 
>it's not at all clear to me that inventing something new there 
>would offer a significant advantage.
>

Then extending the UA capability should be fine. As Contact header is
part of any hash computation like Identity. You can include Require /
Proxy-Require headers too. My biggest problem is SIPS alone doesn't
serve any meaningful purpose for the SIP infrastructre to be used. I
havenot heard anything for tel, im, pres URI. When we need
Proxy-Require etc for them, then why we want to carry on SIPS in its
current form.

Yes I feel we need something with CLEAR DEFINTION (cipher-suites etc) of
SECURITY. The SIPS as per 3261 is completely broken.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2007 14:54:46 -0700

At Wed, 18 Apr 2007 16:45:36 -0500,
> misunderstood your point, please clarify.

This doesn't get the job done for reasons that have been discussed
here many times:

1. The invitation has already been sent in the clear so the damage has
   already been done if there is anything sensitive in the invitation.
2. An active attacker can man-in-the-middle attack the connection
   and initiate a TLS connection to next-hop proxy, thus bypassing
   the check for TLS transport.

> SECURITY. The SIPS as per 3261 is completely broken.

Yes, you keep saying this, but I don't agree with you, and, as far
as I can tell, neither does most of the rest of the WG.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 18 Apr 2007 17:11:39 -0500

>
>This doesn't get the job done for reasons that have been 
>discussed here many times:
>

The INVITE has only the SIP AOR of the callee. SIP AOR is publicly
available etc on the business card. What else goes there ? 

If Caller wants the security, then he will be sending the requests
alltogether using TLS. 
If caller doesn't use the TLS etc, then it is for the proxy (responsible
for UAS) to reject the request. Require header etc gives the semantics
not to generate 3xx for UNSECURE calls for the UNSECURE INVITES. Is
there anything else ?

>   the check for TLS transport.

UAC --- P1 ---- P3 ----- UAS
                |
        P2 -----

If I understood your point correctly, how P2 can pretned himself as P1
to P3, and act on behalf of P1. Mutual authentication is in place.

>
>Yes, you keep saying this, but I don't agree with you, and, as 
>far as I can tell, neither does most of the rest of the WG.

For the now, I leave this for the coming time to decide with the next
version of draft. Generally ahead of the time, things are not liked by
people. 

What is your answer to tel, im, pres URIs first ?

---

From: Ted Hardie <[email-masked]>
Date: Wed, 18 Apr 2007 15:20:26 -0700

>this is an argument *for* SIPS.

I would put it more as an argument against the effectiveness of change,
but yes.
				Ted

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Apr 2007 17:27:46 -0500

On Apr 18, 2007, at 11:46 AM, Paul Kyzivat wrote:

>>  > I expect it is quite small. If I am right, forcing the  
>> remainder to  > register two contacts rather than one seems like a  
>> bad choice.
> Sure. But SIP is not HTTP. I realize that in *theory* there could  
> be lots of targets that only want to use SIPS. But in *practice*  
> where are those going to come from? In general I want to be able to  
> receive calls even if the caller is unwilling or unable to use SIPS.
>
> I know there are exceptions (e.g. the military, and the President),  
> but its my *assumption* that this will be a small number. (I don't  
> know how to get real numbers on this.)
>

I assume the opposite -- that once SIPS can be expected to work,  
everybody with at least half-a-working brain (and the paranoia that  
goes with it) will want to to use it exclusively.

If I could figure out how to get people to stop sending me  
unencrypted email (when they could as easily encrypt), I would.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Apr 2007 17:28:37 -0500

> that is a very rare case unless you have some kind of p2p sip setup.

I'm hoping it becomes much less rare, and would like for decisions  
made now in SIP not to screw it up.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Apr 2007 17:32:48 -0500

>    should be carried over TLS or not at all.

Except of course that when you register with SIPS, you are also  
declaring reachability by SIP.

Now, it just occurred to me that this might be softened by the  
assumption that "If TLS is usable, it will (MUST/SHOULD?) be used".  
Since if you registered SIPS then you MUST (by definition) be  
reachable by TLS, it would mean that TLS would be used exclusively.

So one a "properly compliant system", once you've registered SIPS,  
you'll never see SIP/UDP again.

But how likely is that to actually happen?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Apr 2007 17:35:53 -0500

> not to generate 3xx for UNSECURE calls for the UNSECURE INVITES. Is

What does the callee want?

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 Apr 2007 17:43:08 -0500

> Except of course that when you register with SIPS, you are 
> also declaring reachability by SIP.
> 
> Now, it just occurred to me that this might be softened by 
> the assumption that "If TLS is usable, it will (MUST/SHOULD?) 
> be used".  

Current text says "MUST". See section 4.2.

> So one a "properly compliant system", once you've registered 
> SIPS, you'll never see SIP/UDP again.
> 

Again, if you use sip-outbound (which is not-just-for-NAT), you can
enforce this. You don't "have" to use it of course, but it is 
available if you need it.

No need for a new mechanism IMHO.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2007 15:47:17 -0700

At Wed, 18 Apr 2007 17:11:39 -0500,
> available etc on the business card. What else goes there ? 

As Dean has been pointing out, the mere fact that someone is being called
is itself sensitive. For that matter, so may be their GRUU.

> not to generate 3xx for UNSECURE calls for the UNSECURE INVITES. Is

Again, that doesn't solve the problem because the data has already been
transmitted in the clear.

> to P3, and act on behalf of P1. Mutual authentication is in place.

I have no idea what you are talking about...

> What is your answer to tel, im, pres URIs first ? 

I don't understand why you think that this issue is dispositive.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 18 Apr 2007 17:45:40 -0500

>What does the callee want?

Different callee has different security requirements.

If I am US DOD then Callee wants to Security with AES256 as DOD
considers it as TOP SECRET. If I am any other guy, then I may be okay
with AES128. And If I am serving 911 (URN), then I am okay with any
plain simple text message coming. 

If I am situated in confidentiality/security sensitive geographic area
due to regulatory body there, then only integrity is provided. But here
it will be nice for the caller to know, that UAS is currently not
reachable with AES128 due to mobility etc.

So callee registers with his _ALLOWED_ / _DESIRED_ security level, using
REQUIRE or extending the UA capability and it is responsbility of the
Proxy serving the CALLEE to cater his desired level of security. If his
provider doesn't serve that, then callee will be switching his provider
too.

Thx
Samir

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Apr 2007 17:48:39 -0500

> No need for a new mechanism IMHO.

So let's explore this in the context of a UA to UA relationship  
without an outbound proxy, using our old friends Alice and Bob.

If Alice's UA supports TLS and she has a SIPS URI for Bob, it seems  
like (if your wording says what you think it says) that Alice's UA  
MUST use TLS when trying to contact Bob.

If Alice's UA supports SIPS and she has both a SIP and a SIPS URI for  
Bob, can she use either one as long as she uses TLS? Or does she have  
to use the SIPS URI?

If Alice has only a SIP URI for Bob, but his UA supports TLS, how  
does Alice's UA discover this? Does it have to try connecting via TLS  
first, and if that fails fall back to TCP or UDP?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Apr 2007 18:52:30 -0400

Dean Willis wrote:
>>>  > I expect it is quite small. If I am right, forcing the remainder 
>>> to  > register two contacts rather than one seems like a bad choice.
>> lots of targets that only want to use SIPS. But in *practice* where 
>> are those going to come from? In general I want to be able to receive 
>> calls even if the caller is unwilling or unable to use SIPS.
>>
> everybody with at least half-a-working brain (and the paranoia that goes 
> with it) will want to to use it exclusively.

A lot of communication just doesn't warrant security. I think there will 
be a long while that many won't be able to use sips.

In any case, even if the caller is able to use sips, it may still be 
impossible to establish a successful TLS session. Perhaps the callee 
uses a cert with a CA the caller doesn't support. In that case, the 
caller won't be able to call with sips, but may be able to call with sip.

	Paul

> If I could figure out how to get people to stop sending me unencrypted 
> email (when they could as easily encrypt), I would.
> 
> -- 
> Dean
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 18 Apr 2007 18:33:29 -0500

Hi Eric,

   in-line.

Thx
Samir

>
>As Dean has been pointing out, the mere fact that someone is 
>being called is itself sensitive. For that matter, so may be 
>their GRUU.

As of now, I am not an expert on current version of GRUU. I need to take
a look on that.
In the current email world, anyone can send the emails. What is the
protection there.

The confidentiality is driven by the caller. Callee cannot tell every
proxy on the earth, that please accept only Secure AOR for me. Even if
it does that, then there is still first hop (between CALLER and his
proxy) is open. This doesn't work. Callee can only dictate his serving
proxy.

>
>
>Again, that doesn't solve the problem because the data has 
>already been transmitted in the clear.
>

No, only the SIP AOR of the callee is transmitted. Rest all is Caller
Info, which should be owned (at his risk) by caller only.

>I have no idea what you are talking about...

TLS mutual authentication between the proxies.

>I don't understand why you think that this issue is dispositive.

SIP infrastructure is used for transporting this URI's also. So I much
more concerned.
As there is nothing for this. I don't know how many times this question
I need to raise.
Plain simple accept SIPS as per 3261 is broken, and we need something
more meaninful.

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 19 Apr 2007 10:12:44 +1000

On 19/04/07, Francois Audet <[email-masked]> wrote:
>         opposed to the end-user

This is an end user choice, imo. Not a choice of the service provider.
I want to decide if I receive secure calls or not, not the system.
(there are exceptional cases like the military).

Hisham

> (this is the error-prone end-user

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 Apr 2007 22:45:01 -0500

> So let's explore this in the context of a UA to UA 
> relationship without an outbound proxy, using our old friends 
> Alice and Bob.

Ok, assuming there are no proxies whatsoever in this case.

Alice does a DNS query and it resolves directly to Bob, or maybe some
p2p sip magic, and figures out where Bob is.

> If Alice's UA supports TLS and she has a SIPS URI for Bob, it 
> seems like (if your wording says what you think it says) that 
> Alice's UA MUST use TLS when trying to contact Bob.

Yes. That is correct. And SIPS too.

> If Alice's UA supports SIPS and she has both a SIP and a SIPS 
> URI for Bob, can she use either one as long as she uses TLS? 
> Or does she have to use the SIPS URI?

She can use whatever she wants, SIP or SIPS. If she uses SIPS
(which is recommended), then she MUST use TLS.

If she uses SIP, she SHOULD use TLS but doesn't have to. 

> If Alice has only a SIP URI for Bob, but his UA supports TLS, 
> how does Alice's UA discover this? Does it have to try 
> connecting via TLS first, and if that fails fall back to TCP or UDP?

She can try to establish a TLS connection to Bob if she wants, but it
may not work. She may not have Bob's user certificate for example. And
why would she only have a SIP URI if Bob is reachable with SIPS?

It's entirely up to her (or her UAC) to decide if she (it) wishes to
incur 
the cost "trying" TLS (and potentially sips although it doesn't change
anything in this p2p sceanrio) "all the time".

Since this p2p stuff and TLS assumes the existence of a global PKI 
based on user certs, I'm not sure why we are spending so much time on
it.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 Apr 2007 22:53:53 -0500

> (there are exceptional cases like the military).

At this point, Bob has the following options:

1) Reject any call addressed to SIP

2) Redirect any call addressed to SIP to SIPS (i.e, 301 to SIPS AOR or
302 to SIPS Contact)

3) Use SIP outbound to absolutely force the use of TLS (and avoid the
allege vulnerability of 
   in 1 and 2 above of your location being discovered by somebody
magically tapping in the 
   switch where you just just happen to be connected to at that moment).

4) Have an arrangement with your provider to do it for you (it's your
choice, you tell your
   service provider what you want) 

If I understand correctly, you think this is not good enough????

I'm really struggling to find a use case for this. Seriously. It seems
insanely far fetched.
If you are that worried about this, get a better service provider. Or
get your own domain 
name.

But if we really needed one, I think the caller pref idea is the best
one. Even if it
seems completely overkill to me.

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 19 Apr 2007 14:15:51 +1000

> 1) Reject any call addressed to SIP

Dean does not want the request to arrive at Bob's UA at all. I agree
with him on that.

> 2) Redirect any call addressed to SIP to SIPS (i.e, 301 to SIPS AOR or

Yes. That's what I want to be normative text (i.e, 301 to SIPS AOR),
but not the SIPS contact part.

>    switch where you just just happen to be connected to at that moment).

I thought outbound was solving a different set of problems, namely NAT
traversal. Why is it in the mix here? This is confusing. Copy the text
into your draft if you have to, but I don't have a NAT issue, I dont
want to implement outbound.

>    service provider what you want)

This must be mandated somehow. We cannot mandate implementations or
what a service provider provides to a customer, but we can however
make protocol rules. It is a vulnerability that we need to protect
against that we cannot ignore, no matter how small it is. It is not a
nice to have feature.

> I'm really struggling to find a use case for this. Seriously. It seems

This is absolutely not far fetched. I want to only be reached
securely. Calling directly between UAs or not having a home proxy with
outbound implemented is far fetched???

Hisham

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 Apr 2007 23:26:46 -0500

> Yes. That's what I want to be normative text (i.e, 301 to 
> SIPS AOR), but not the SIPS contact part.

Ok, I can certainly add some wording to that effect, i.e., that
if you DO NOT want to be reached with SIP, then a 301 to your AOR
with a SIPS scheme is in order. 

I will add to -04.

> I thought outbound was solving a different set of problems, 
> namely NAT traversal. Why is it in the mix here? This is 
> confusing. Copy the text into your draft if you have to, but 
> I don't have a NAT issue, I dont want to implement outbound.

That is not correct. Outbound is not only to solve NAT traversal
problems.

Outbound is also to support any cases where inbound connections
are not possible.

A perfect examples is when using TLS and only the Proxy has a 
certificate to provide (which is the typical case). That is 
explained, unfortunately not very clearly, at the beginning of
sip-outbound.

This is what I was refering too.

> This must be mandated somehow. We cannot mandate 
> implementations or what a service provider provides to a 
> customer, but we can however make protocol rules. It is a 
> vulnerability that we need to protect against that we cannot 
> ignore, no matter how small it is. It is not a nice to have feature.
>
> >
> securely. Calling directly between UAs or not having a home 
> proxy with outbound implemented is far fetched???

Will the 301 change address your concern?

If not, what else? You are giving lots of constraints. No home proxy,
and no outbound. Seems to me anybody can do a DNS query, find you and
shoot whatever they want at you.

---

From: Dean Willis <[email-masked]>
Date: Thu, 19 Apr 2007 13:26:19 -0500

> If she uses SIP, she SHOULD use TLS but doesn't have to.

Ok. Here we have a challenge.

We SHOULD use TLS, but we have no reason to expect it will work, and  
no mechanism (short of trying it) to see if it will work. I don't see  
any way to make this better, but I can still wish for one. If we are,  
in short, recommending that one always uses TLS, it would seem like  
we need to say more about how to discover its applicability with more  
efficiency.

 From one POV, trying it isn't that hard -- since it runs on a  
different port, we might get an ICMP port unreachable response fairly  
quickly if it just isn't there.

And DNS can help us discover if a proxy supports TLS.

Maybe the requirement here is something that should be pushed onto  
the discovery method (like DNS or P2P discovery). The problem here is  
that the registration model (which presumably influences how  
something might exist in order to be discovered) says registering  
SIPS means you can take SIPS and SIP. This makes it hard to leverage  
the registration model into a reasonable solution for the proxyless  
use case. If, on the other hand, a SIP registration meant you could  
get SIP (and implied, as it does, nothing about SIPS), and a SIPS  
registration meant you could get SIPS (and implied nothing about  
SIP), then it would be a lot easier to re-use registration to build a  
correct proxyless discover model.

> why would she only have a SIP URI if Bob is reachable with SIPS?

She might have only a SIP URI because that's what was printed on the  
business card, or because that's what she guessed from Bob's email  
address.

> based on user certs, I'm not sure why we are spending so much time on

because even self-signed certs would eliminate the particular attack  
I'm talking about. Sure, they don't give all the authentication  
functions of trusted-ca-signed certs, but the confidentiality  
protection is much better than SIP/UDP.

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2007 16:55:09 -0700

At Wed, 18 Apr 2007 18:33:29 -0500,
> Plain simple accept SIPS as per 3261 is broken, and we need something

Yes, this is the point on which we disagree. 

At this point we've been over this argument a number of times and we're
not convincing each other, so I don't see much point in continuing
this conversation.

-Ekr

---

From: "Ding, Zheng \(Derrick\)" <[email-masked]>
Date: Fri, 20 Apr 2007 14:54:27 +0800

Hi, All

I have a question:

One parameter in Q931: Network-Specific Facilities.

How to mapping it to SIP, I mean how to fill this value in SIP messages.

Thanks

Derrick

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 20 Apr 2007 16:38:07 +0800

Hi

NSF field is optional in SETUP and I don't think this field is really
required in SIP.  But there is a parameter "cic", which can be appended
to INVITE message for identifying the carrier.

Regards
Ranjit

-----Original Message-----
From: Ding, Zheng (Derrick) [mailto:[email-masked]] 
Sent: Friday, April 20, 2007 12:24 PM
To: [email-masked]
Subject: [SIP] a parameter mapping between Q931 and SIP

Hi, All

I have a question:

Thanks

Derrick

---

From: <[email-masked]>
Date: Fri, 20 Apr 2007 11:25:00 +0200 (CEST)

> How to mapping it to SIP, I mean how to fill this value in SIP messages.

Not defined, therefore not possible.

-franz

---

From: <[email-masked]>
Date: Fri, 20 Apr 2007 11:33:53 +0200 (CEST)

> ....  But there is a parameter "cic", which can be appended

Ranjit, where is "cic" defined?

- franz

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 20 Apr 2007 17:37:33 +0800

In this draft: Extensions to the "tel" URL to Support Number Portability
and Freephone Service : <draft-yu-tel-url-07.txt>  

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, April 20, 2007 3:04 PM
To: Avasarala Ranjit-A20990
Cc: [email-masked]; [email-masked]
Subject: RE: [SIP] a parameter mapping between Q931 and SIP
Importance: High

> ....  But there is a parameter "cic", which can be appended to INVITE 
> message for identifying the carrier.

- franz

---

From: "Gerald Yan" <[email-masked]>
Date: Fri, 20 Apr 2007 17:49:10 +0800

Updated.
RFC4694, Number Portability Parameters for the "tel" URI

Best regards
Gerald

-----邮件原件-----
发件人: Avasarala Ranjit-A20990 [mailto:[email-masked]] 
发送时间: 2007-04-20 17:38
收件人: [email-masked]
抄送: [email-masked]
主题: RE: [SIP] a parameter mapping between Q931 and SIP
重要性: 高

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, April 20, 2007 3:04 PM
To: Avasarala Ranjit-A20990
Cc: [email-masked]; [email-masked]
Subject: RE: [SIP] a parameter mapping between Q931 and SIP
Importance: High

- franz

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 20 Apr 2007 13:57:42 -0500

I propose to present my proposal in Chicago as a part of cipher-suite
updation, and then we can have the hum there. This will close the issue
either way. 

I think it should be acceptable by chairs and group. 

Thx
Samir  

>Sent: Wednesday, April 18, 2007 4:55 PM
>To: Srivastava, Samir (SC100:8826)
>Cc: Eric Rescorla; Juha Heinanen; [email-masked]; Paul Kyzivat; 
>Audet, Francois (SC100:3055); Dean Willis
>> As there is nothing for this. I don't know how many times this 
>> question I need to raise.
>At this point we've been over this argument a number of times 
>and we're not convincing each other, so I don't see much point 
>in continuing this conversation.
>
>-Ekr
>
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 20 Apr 2007 14:27:59 -0500

I got the personal request from others, whatever happens in the meeting,
that should achieve the consensus on the list too. I am firm believer of
this, as email list addresses the wider audience.

Thx
Samir

>From: Srivastava, Samir (SC100:8826) 
>Sent: Friday, April 20, 2007 11:58 AM
>To: Eric Rescorla
>Cc: [email-masked]; Juha Heinanen; Audet, Francois (SC100:3055); 
>Paul Kyzivat; Dean Willis
>Subject: RE: [Sip] SIPS question: How to prevent plaintext 
>I propose to present my proposal in Chicago as a part of 
>cipher-suite updation, and then we can have the hum there. 
>This will close the issue either way. 
>
>>Cc: Eric Rescorla; Juha Heinanen; [email-masked]; Paul Kyzivat; Audet, 
>>Francois (SC100:3055); Dean Willis
>>Subject: Re: [Sip] SIPS question: How to prevent plaintext requests 
>and we're 
>>not convincing each other, so I don't see much point in 
>continuing this 
>>conversation.
>>
>>-Ekr
>>
>>
>
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 20 Apr 2007 14:39:07 -0500

Let's clarify what your proposal is.

You are proposing that we have a hum on your proposal (whatever it is).

This in no way has any impact on the existing work of the WG, including
the draft-ietf-sip-sips draft.

Thanks.

> Sent: Friday, April 20, 2007 11:58
> To: Eric Rescorla
> Cc: Juha Heinanen; [email-masked]; Paul Kyzivat; Audet,

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 20 Apr 2007 14:56:57 -0500

Some audience say personaly and some openly on the list for not adopting
sip-sips as STANDARD track document. The claimed unanimity of the prague
is not depicted in the meeting minutes and on the list. It is still
highly contentious.

The next version of the draft is shaping up. Please wait. As I mentioned
earlier, I feel cipher-suites are needed and the Proxy-Require and
Require for that makes SIPS redundant.
There are other issues too, which you feel are beaten to death. 

Does the presentation of cipher-suite harm your work. If group likes my
proposal, then only it will be changed to INFORMATIONAL / BCP from
STANDARDS track which you are proposing currently. Though I had my own
reservation on any of these guidelines. That is my personal opinion.

I feel, there has been lot of discussion on the cipher-suites after
Montreal, and its presentation to the group is due. If chairs don't want
to allow it, then I am okay. I am leaving this to chairs to decide.

Thx
Samir

>From: Audet, Francois (SC100:3055) 
>Sent: Friday, April 20, 2007 12:39 PM
>To: Srivastava, Samir (SC100:8826); 'Eric Rescorla'; Keith 
>DRAGE ([email-masked])
>Cc: [email-masked]'; 'Dean Willis'
>This in no way has any impact on the existing work of the WG, 
>including the draft-ietf-sip-sips draft.
>
>Thanks.
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Apr 2007 13:25:11 -0700

At Fri, 20 Apr 2007 14:56:57 -0500,
> to allow it, then I am okay. I am leaving this to chairs to decide.

I have no objection to having your proposal presented and discussed 
in Chicago. I have a serious objection to holding draft-ietf-sip-sips
pending that discussion.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 20 Apr 2007 16:39:55 -0500

>
>I have no objection to having your proposal presented and 
>discussed in Chicago. I have a serious objection to holding 
>draft-ietf-sip-sips pending that discussion.

This is where we have contention. As I mentioned earlier if the current
SIPS cloud gets deployed where we don't have
1) Any cipher-suite information
2) No reverse channel to the UAC
3) Loss of confidentiality due to local geographic regions 
4) Other feature related issues, like what you will do when secure
dialog being replaced
   by unsecure dialog. Presence watchers can use unsecure channeel to
see presence information coming over the secure channel. In a nutshell
no feature control. Other demerits, I don't want to repeat.

Now request coming from the cloud, which addresses all the above, and
then it traverses through currently defined SIPS cloud. We are toast. We
don't have any of the above information. This will be very similar to
Current Secure SIP messages hit the Media Gateway to go to PSTN. We
don't know what is happening afterwards. We will be having another beast
to interoperate where we are missing the information. This is the center
point for deprecating the SIPS as per the current 3261. 

Thx
Samir

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 20 Apr 2007 16:41:43 -0500

No, this is where YOU have contention with the working group.

I agree with Eric. 

> Sent: Friday, April 20, 2007 14:40
> To: Eric Rescorla
> Cc: Audet, Francois (SC100:3055); [email-masked]; 
> [email-masked]; Dean Willis
> discussed in 
> >Chicago. I have a serious objection to holding draft-ietf-sip-sips 
> >pending that discussion.
> 
> This is where we have contention. As I mentioned earlier if 
> the current SIPS cloud gets deployed where we don't have
> 4) Other feature related issues, like what you will do when 
> secure dialog being replaced
>    by unsecure dialog. Presence watchers can use unsecure 
> channeel to see presence information coming over the secure 
> channel. In a nutshell no feature control. Other demerits, I 
> don't want to repeat.
> 
> Now request coming from the cloud, which addresses all the 
> above, and then it traverses through currently defined SIPS 
> cloud. We are toast. We don't have any of the above 
> information. This will be very similar to Current Secure SIP 
> messages hit the Media Gateway to go to PSTN. We don't know 
> what is happening afterwards. We will be having another beast 
> to interoperate where we are missing the information. This is 
> the center point for deprecating the SIPS as per the current 3261. 
> 
> Thx
> Samir
> 
> >
> >-Ekr
> >
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 20 Apr 2007 16:45:07 -0500

Can somebody from the group enlighten me how to do interoperability with
this ? Please talk in the concrete terms of engineering.

Thx
Samir 

>Sent: Friday, April 20, 2007 2:42 PM
>To: Srivastava, Samir (SC100:8826); 'Eric Rescorla'
>Cc: [email-masked]'; [email-masked]'; 'Dean Willis'
>> Subject: RE: [Sip] SIPS question: How to prevent plaintext requests 
>> This is where we have contention. As I mentioned earlier if the 
>> current SIPS cloud gets deployed where we don't have
>channeel to 
>above, and 
>> then it traverses through currently defined SIPS cloud. We 
>are toast. 
>> We don't have any of the above information. This will be 
>very similar 
>> to Current Secure SIP messages hit the Media Gateway to go 
>to PSTN. We 
>> don't know what is happening afterwards. We will be having another 
>> beast to interoperate where we are missing the information. This is

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Sun, 22 Apr 2007 03:03:11 +0200

I suggest you submit it in time to obtain discussion on the list, and
then we will see if it merits agenda time or not, based on the interest
displayed and the issues to discuss, versus charter items that will also
need agenda time. 

For as long as I can remember, we have never been able to satisfy all
the requests for agenda time.

Regards

Keith

> From: Samir Srivastava [mailto:[email-masked]] 
> Sent: Friday, April 20, 2007 7:58 PM
> To: Eric Rescorla
> Cc: [email-masked]; Juha Heinanen; Francois Audet; Paul 
> Kyzivat; Dean Willis
> requests frombeing delivered to a UA
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Sun, 22 Apr 2007 21:45:56 -0500

Thx for letting me know the process. 

But I am still waiting for some directions / answers to my yesterday's
posting for the interworking issue. It will be highly useful to the
group (atleast to me) what other experts think for addressing that
issue.

Thx
Samir

>From: Drage, Keith (Keith) [mailto:[email-masked]] 
>Sent: Saturday, April 21, 2007 6:03 PM
>To: Srivastava, Samir (SC100:8826); Eric Rescorla
>I suggest you submit it in time to obtain discussion on the 
>list, and then we will see if it merits agenda time or not, 
>based on the interest displayed and the issues to discuss, 
>versus charter items that will also need agenda time. 
>
>For as long as I can remember, we have never been able to 
>satisfy all the requests for agenda time.
>
>Regards
>
>Keith
>
> 
>
>> Cc: [email-masked]; Juha Heinanen; Francois Audet; Paul Kyzivat; Dean 
>> Willis
>> frombeing delivered to a UA
>> 
>cipher-suite 
>> updation, and then we can have the hum there.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Apr 2007 20:27:02 -0700

At Sun, 22 Apr 2007 21:45:56 -0500,
> group (atleast to me) what other experts think for addressing that

Well I for one, think that your assertions have been addressed adequately
both in person and on the list. I'm sorry you're not satisfied with the
answers, but I don't plan to go through it again absent some evidence
that your concerns are widely shared.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Sun, 22 Apr 2007 22:43:40 -0500

Fine, I will wait for the day when others will realize the issue. I hope
the day will come soon. 

Thx
Samir 

>Sent: Sunday, April 22, 2007 8:27 PM
>Cc: Drage, Keith (Keith); Eric Rescorla; [email-masked]; Juha 
>Heinanen; Audet, Francois (SC100:3055); Paul Kyzivat; Dean Willis
>Well I for one, think that your assertions have been addressed 
>adequately both in person and on the list. I'm sorry you're 
>not satisfied with the answers, but I don't plan to go through 
>it again absent some evidence that your concerns are widely shared.
>
>-Ekr
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Apr 2007 20:52:22 -0700

> I am sure that Cullen must be listening this.

Uh - I'm sort of reading it but I got to admit I'm not sure I am  
getting any information that is new. I'm sure Francois will summarize  
something that I can actually understand sooner or later.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Apr 2007 20:53:05 -0700

I started to write something then realized Ted had already done it -  
when SIP was first done, we could have done SIPS without using two  
schemes but given where we are now it would totally non backwards  
compatible during the transition period from one form to the other so  
I think Ted, Ekr, and I are all thinking that uses sips looks like  
the logical answer.

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 23 Apr 2007 13:57:30 -0500

>Sent: Sunday, April 22, 2007 8:53 PM
>To: SIP
>Cc: Audet, Francois (SC100:3055); Dean Willis
>I started to write something then realized Ted had already 
>done it - when SIP was first done, we could have done SIPS 
>without using two schemes but given where we are now it would 
>totally non backwards compatible during the transition period 
>from one form to the other so I think Ted, Ekr, and I are all 
>thinking that uses sips looks like the logical answer.
>
I think I am failing completely to get my views across the some of the
audience. I am nearing to my end of writing the emails on the list for
deprecating SIPS. No doubts why SKYPE is so successful with properiteray
protocols and they have done it so quickly. Within the standard body, we
are taking a long time to understand it. I don't know what to say.

As far as I interpret from the list, there are some CLAIMED DEPLOYMENT
of SIPS, which I call CHEAT. As feature set itself are broken. I hope
that there users were listening on the earlier postings, how much they
are broken. And they will be beating up their suppliers.

Where we are today, we have some vendors who have implemented it. They
just want to patch it with whatever logic they want to come up , And
create a lot of troubles for our kids to fix it. They just don't want to
accept their mistakes and bear the cost of the development. The cost
should be looked up in total. If the current state of SIPS gets
deployed, then we have to develop some interworking protocols with
USABLE feature set and USERS will be junking SIPS eventually. Today we
have to offset the cost of development only, but if we take the path of
patching it, we have more cost coming forward, network upgrades,
protocol interworking etc. 

I am hoping that Providers and Enterprise IT departments are listening
on this, whether they want broken feature set where their end users will
cursing them and they have to explain what feature works and what
doesn't work. If call is routed this path or that path, then don't
accept the security. Do the providers and Enterprise IT department want
this hussle to take or they want the complete nice solution with some
waiting time. Whatever we produce, it should be easily
undetstandable/implementable by the implementation community and usable
by the end users. I feel I have failed completely to get my point across
the some of the audience on this.

Thx
Samir

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 23 Apr 2007 14:13:21 -0500

> Sent: Monday, April 23, 2007 11:58
> To: Cullen Jennings; SIP
> I think I am failing completely to get my views across the 
> some of the audience. 

That is a correct statement.

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 23 Apr 2007 14:17:04 -0500

BTW, it is _some_ of the audience. 

Thx
Samir 

>Sent: Monday, April 23, 2007 12:13 PM
>To: Srivastava, Samir (SC100:8826); Cullen Jennings; SIP
>Cc: Dean Willis
>some of the 
>> audience.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 23 Apr 2007 14:41:01 -0500

Below.

> Sent: Sunday, April 22, 2007 20:52
> Cc: SIP; Audet, Francois (SC100:3055)
> Uh - I'm sort of reading it but I got to admit I'm not sure I 
> am getting any information that is new. I'm sure Francois 
> will summarize something that I can actually understand 
> sooner or later.
> 

I'm not getting it either.

I think the summary is that Samir wants the group to stop its work
on draft-ietf-sip-sips, and reverse it's already made 
decision, in order to consider a proposal from him that
he hasn't submitted yet, involving indicating Cypher-suites 
explicitly and deprecating SIPS altogether.

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 23 Apr 2007 15:02:02 -0500

It will be coming soon as its in discussion with other folks privately.
BTW, we still have a lot of time before Chicago. And I don't work 100%
time on the IETF proposal writing.

My proposal is depicted in the cipher-suite draft roughly in the 00
version. I have shown so many times on the list that we need
cipher-suite indication, where our security adivisor doesn't seem to be
in the agreement. That version was not talking about the broken features
etc, which had been earlier discussed before San Diego a lot on the
list. 

And in the next version, I will be talking about the broken features
with respect to 3261. Your proposed patches are not the reference point
for it. And it is catching brokenness of SIPS as the focal point.

I was keeping silent, as I only wanted this to be progress as
BCP/INFORMATIONAL document and then proceed with my proposal. And
recently it was brought to my notice that is being pursed as STANDARD
track document, where I have disconnect and so I am putting more time on
this effort. 

Thx
Samir

>Sent: Monday, April 23, 2007 12:41 PM
>To: Cullen Jennings
>Cc: SIP
>I think the summary is that Samir wants the group to stop its 
>work on draft-ietf-sip-sips, and reverse it's already made 
>decision, in order to consider a proposal from him that he 
>hasn't submitted yet, involving indicating Cypher-suites

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Apr 2007 13:33:45 -0700

At Mon, 23 Apr 2007 15:02:02 -0500,
Samir Srivastava wrote:
> in the agreement. 

This confuses more than it illuminates.

There are two features being discussed here:

1. An indicator of which cipher suite was negotiated.
2. A signal that you want the next hop to negotiate a specific
   set of cipher suites.

I have no problem with the first feature, though I'm not sure it's
incredibly useful. I don't agree that the second feature is
particularly useful. The cases where it's relevant strike me as
fairly esoteric and unlikely.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 23 Apr 2007 16:06:56 -0500

My very simple requirement, which I posted recently to the Dean's
question on the what callee wants. And a lot of this, I explained
earlier.

1) If I am DOD, I want AES 256. As it is considered TOP SECRET by them.
If I am talking to bank then I want AES 256 (using KPML etc as it has
lot of valuable information). If a CEO of company A is in talks with CEO
of another company B, he will need AES 256 for all along. As the call
pattern tracking itself is more sensitive. As if Competetior of Company
of A knows that A and B are in talks, he can also come into the picture.
The damage varies on the size, content of talk (consider Page mode IM
too).

2) If I am making 911 call, I need my call to be setup even with the
plain text.

3) If I am small office owner in the downtown, then I might be okay even
with 3DES or 40 bit ciphers etc..

4) If I am a normal user, then I will need AES128 all along.

5) There are geographic regions, where ciphersuites just provide the
integrity and no confidentiality. If my UA moves to those regions, then
atleast the proxy sitting at the boundary should inform the request
needing back AES256, that it cannot be served.

I have given a lot of other reasons earlier. Like Cheater Proxy, the N+1
Cycle for new cipher-suite development etc..

My only request to the group is, please postpone the decision of SIPS
with patches as STANDARD track document, till I publish my next version
of the cipher-suite draft.

Thx
Samir 

>I have no problem with the first feature, though I'm not sure 
>it's incredibly useful. I don't agree that the second feature 
>is particularly useful. The cases where it's relevant strike 
>me as fairly esoteric and unlikely.
>
>-Ekr
>
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Apr 2007 14:23:40 -0700

At Mon, 23 Apr 2007 16:06:56 -0500,
> Cycle for new cipher-suite development etc..

Yes, you've posted this claimed requirement before, and as I said
before, I think it's a fairly unusual set of cases that's not important to
optimize for at this point. I don't see any evidence that you're any
closer to getting consensus on this requirement than you were in
Montreal.

> of the cipher-suite draft.

I oppose holding up the SIPS document for this. If your document is
done before the WG is finished with SIPS, then you should feel free
to ask people whether they prefer it your approach. Otherwise, SIPS
should move forward. This topic has been debated long enough.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 23 Apr 2007 16:42:27 -0500

>
>Yes, you've posted this claimed requirement before, and as I 
>said before, I think it's a fairly unusual set of cases that's 
>not important to optimize for at this point. I don't see any 
>evidence that you're any closer to getting consensus on this 
>requirement than you were in Montreal.
>

Okay, let me see what happens in Chicago on the cipher-suite front.

>> with patches as STANDARD track document, till I publish my next 
>> version of the cipher-suite draft.
>
>I oppose holding up the SIPS document for this. If your 
>document is done before the WG is finished with SIPS, then you 
>should feel free to ask people whether they prefer it your 
>approach. Otherwise, SIPS should move forward. This topic has 
>been debated long enough.
>

Even If I accept SIPS with AES128 all along with SIPS. I don't know how
the group wants to address the broken feature. Let me go one by one on
the features.

In the below call flow If PUA uses SIPS in M5. But M1 and others between
PA and Watcher uses only SIP. What PA/ESC should do ? Don't we need a
REQUIRE flag to enforce the feature control at PA / ESC . Does SIPS
_alone_ sufficient ?

          PUA                    PA                       WATCHER
         (EPA)                   (ESC)
           |                       |                         |
           |                       | <---- M1: SUBSCRIBE --- |
           |                       |                         |
           |                       | ----- M2: 200 OK -----> |
           |                       |                         |
           |                       | ----- M3: NOTIFY -----> |
           |                       |                         |
           |                       | <---- M4: 200 OK ------ |
           |                       |                         |
           |                       |                         |
           | ---- M5: PUBLISH ---> |                         |
           |                       |                         |
           | <--- M6: 200 OK ----  |                         |
           |                       |                         |
           |                       | ----- M7: NOTIFY -----> |
           |                       |                         |
           |                       | <---- M8: 200 OK ------ |

Thx
Samir

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Apr 2007 20:42:37 -0400

> 1) If I am DOD, I want AES 256. As it is considered TOP SECRET by them.

If you are the DOD, then you will control the whole network and insist 
that it use AES 256 uniformly, regardless of what is signaled.

> lot of valuable information).

*You* may know you are talking to a bank. But how does your UAC know 
that? Do you expect to have an "AES 256" button on the phone to signal this?

Its also possible that you didn't know when you made the call that it 
was to a bank. (It might just be a number on your missed-calls list.) 
Its quite possible that it is the *bank*, not you, that wants to ensure 
that the call is secure, because it has legal liability if it doesn't. I 
don't see how you intend to deal with that.

> If a CEO of company A is in talks with CEO

In general it becomes quite messy if you insist that the security policy 
to use for the call be specified by the caller and yet be dependent on 
the nature of both the caller and callee.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Apr 2007 20:49:35 -0400

> REQUIRE flag to enforce the feature control at PA / ESC . Does SIPS

In your example, PA is just an instance of a B2BUA. For purposes of this 
discussion it is little different from a conference focus or a lot of 
other things.

I think we have agreed that a B2BUA is a UA, and that if it satisfies 
the security requirements of a UA then it is done. What it does out its 
other side cannot be predicted.

Do do better, it will be necessary to develop specific rules for 
particular kinds of B2BUA. If you have ideas about how the secure info 
delivered to the PA using publish is to be secured on the notification 
side, then we need a new spec for it.

If that were done, I doubt it would say that all the notifies must 
adhere to the same security level that the publish had. More likely, 
there might be some kind of security tagging of elements of presence 
data, and then filtering rules that prevent certain secured data from 
being included in insecure notifications.

My main point is that such issues are largely orthogonal to the entire 
sips thing.

	Paul

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 23 Apr 2007 20:04:26 -0500

Being a UA, I don't want my presence information to be delivered on the
unsecure channels. Can I do that ? You might view it is a B2BUA but it
is not so in the vocabulary of SBC vendors as It doesn't create a
matching a dialog on the other side. Here it is triggering the another
operation.

Presence is one example, another is REG-EV watchers. Where we don't have
tagging option in the PIDF as we have in PUBLISH.

Thx
Samir

>Sent: Monday, April 23, 2007 5:50 PM
>Cc: Eric Rescorla; Cullen Jennings; SIP; Audet, Francois (SC100:3055)
>>> before, I think it's a fairly unusual set of cases that's not 
>>> important to optimize for at this point. I don't see any evidence 
>>> that you're any closer to getting consensus on this 
>requirement than 
>>> you were in Montreal.
>>>
>> 
>> Even If I accept SIPS with AES128 all along with SIPS. I don't know 
>> how the group wants to address the broken feature. Let me go one by 
>> one on the features.
>> 
>> In the below call flow If PUA uses SIPS in M5. But M1 and others 
>> between PA and Watcher uses only SIP. What PA/ESC should do 
>? Don't we 
>> need a REQUIRE flag to enforce the feature control at PA / 
>ESC . Does 
>> SIPS _alone_ sufficient ?
>
>In your example, PA is just an instance of a B2BUA. For 
>purposes of this discussion it is little different from a 
>conference focus or a lot of other things.
>
>I think we have agreed that a B2BUA is a UA, and that if it 
>satisfies the security requirements of a UA then it is done. 
>What it does out its other side cannot be predicted.
>
>Do do better, it will be necessary to develop specific rules 
>for particular kinds of B2BUA. If you have ideas about how the 
>secure info delivered to the PA using publish is to be secured 
>on the notification side, then we need a new spec for it.
>
>If that were done, I doubt it would say that all the notifies 
>must adhere to the same security level that the publish had. 
>More likely, there might be some kind of security tagging of 
>elements of presence data, and then filtering rules that 
>prevent certain secured data from being included in insecure 
>notifications.
>
>My main point is that such issues are largely orthogonal to 
>the entire sips thing.
>
>	Paul
>
>>           PUA                    PA                       WATCHER
>>          (EPA)                   (ESC)
>>            |                       |                         |

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 Apr 2007 12:42:16 -0700

After promising myself that I would not respond to the "Silly Thread  
of the Month" thread I find myself once again responding ...

I don't think most the WG thinks SIPS means what you would like it to  
mean.

I think there is one more common case you should consider - Alice  
dials a phone number and sends an INVITE with SIPS - this call gets  
routed to a PSTN GW - it does across the PSTN and goes to another GW  
to get routed to Bob's IP phone. This leg from the second GW to Bob's  
phone does not use TLS at all.  Most people in the WG think this is  
just fine.

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 24 Apr 2007 15:40:59 -0500

Fast forward on the time dimension, when you have complete IP network
and PSTN is gone, do we want to have a network cloud which carries the
same legacy of PSTN that missing the security level (cipher-suites),
reverse channel, feature control etc.

We cannot change the current PSTN, so we have to live with that. But
while designing security for the tommorrow's network do we want to
repeat the same mistake. PSTN doesn't have that because it was by nature
secure. Here security is after thought. It's inherent property of IP.

It may be silly but I don't find it embarrasing to discuss and clear the
issues. I may be having hurdles in other eyes, but may be in process of
clearing that hurdles, we might get something else.

Thx
Samir

>Sent: Tuesday, April 24, 2007 12:42 PM
>Cc: Eric Rescorla; Audet, Francois (SC100:3055); SIP
>After promising myself that I would not respond to the "Silly 
>Thread of the Month" thread I find myself once again responding ...
>
>I don't think most the WG thinks SIPS means what you would 
>like it to mean.
>
>I think there is one more common case you should consider - 
>Alice dials a phone number and sends an INVITE with SIPS - 
>this call gets routed to a PSTN GW - it does across the PSTN 
>and goes to another GW to get routed to Bob's IP phone. This 
>leg from the second GW to Bob's phone does not use TLS at all. 
> Most people in the WG think this is just fine.
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 24 Apr 2007 16:43:51 -0500

On Apr 24, 2007, at 2:42 PM, Cullen Jennings wrote:

> routed to a PSTN GW - it does across the PSTN and goes to another  
> GW to get routed to Bob's IP phone. This leg from the second GW to  
> Bob's phone does not use TLS at all.  Most people in the WG think  
> this is just fine.

Although it should be noted that we did debate this in detail, and  
some participants had advanced the idea that SIPS should never be  
degraded to a non-SIPS external protocol.

We ran into deep water trying to define exactly what this meant, and  
gave up by saying the responsibility for SIPS stops at the UAS. This  
makes makes it technically, if not morally, correct to build a B2BUA  
that adapts from SIPS to SIP.

While not satisfying to everybody on the list, I think we have a  
consensus that this is a least a sufficiently definable and bounded  
case that we can work with it for now.

I believe that this is however COMPLETELY orthogonal to and  
independent of the desire to request some specific variety or grade  
of cryptography on SIPS links and the related desire to inform the  
endpoints about the cryptography of those links. Since SIPS is not  
itself end-to-end, the openness (OPES) principle argues that we  
should at least tell the UAs what happened with their data.

I have however come to feel that this is a fairly pointless exercise  
since there is a far higher probability of leakage from alternative  
paths into the trusted (but possibly not trustworthy) proxies than  
there is of successful cryptographic attack on the links between  
those proxies. Given this, I find it far more interesting to discuss  
true end-to-end protection mechanisms such as SIPSEC. Such a  
mechanism would moot the need for UAs to tell proxies how to do their  
business, and would also moot the need for proxies to to tell UAs  
what the proxies have done, since UAs would both do and know exactly  
what happened. The same can be said for alternative proposals, such  
as request tunneling over a non-SIP P2P secured routing protocol.

In any case, unless there is a substantial change in consensus, we  
currently do not have a strong enough interest in solving these  
problems to justify investment of substantial working group time and  
energy. I encourage the authors of sipsec and ciphersuites to  
continue to develop their ideas and maintain them as individual  
drafts, because there may come a day when we find interest in either  
the problems they attempt to address or the solutions they attempt to  
define. It's even fair to point them out on the list occasionally,  
accept comments and discussion, and even every now and then (perhaps  
once per meeting cycle) ask what the current level of interest in the  
work is.

or to paraphrase a local aphorism: Hunting season's over for this  
dog, this year. You can quit throwing the training dummy at him for a  
while.

--
Dean Willis
Co-Chair