Subject: Re: [Sip] Question on SIP Security considerations for future extensions

From: "[email-masked]" <[email-masked]>
Date: Wed, 15 Aug 2007 09:39:37 -0500

With all due respect, I don't agree with this.  Its my opinion that the current model is well-understood and unsatifactory for many applications.  While I think its fine to spend some time clarifying the current model, I don't think that should hold up the development of an end-to-end mechanism as well.  That development can proceed in parallel and the sipsec draft is a good start in that direction.

To that end, after receiving the blessing of the majority of the authors, I'm posting a proposal I made to them regarding a mod to the sipsec draft that I believe would improve its ability to address true end-to-end security.

The idea is simple, rather than having the CONNECT message establish a "tunnel" through a series of proxies, CONNECT is used to trade addressing information between the UAs that then signal each other directly.  This proposal was made as modifications to the sipsec draft.  The draft is available as a standalone and as a diff to the current sipsec draft at the following links.  Comments are hoped for...

Thanks,

FM

https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fmiller/

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt&url2=http://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt

On Wed Aug 15 9:37 , Richard Barnes sent:

I'm replying to Dean's original message so that I'm not deep down in the

thread, but I'd like to point to one of Dean's later comments:

> Look, my question about security documentation for SIP extensions had

> nothing to do with SIPSEC and everything to do with documenting the

> current please-molest-me proxy-mediated transitive-faith-in-goodness

> I-believe-my-operator-cares-for-me model of SIP security. And we DO

> need to document this model better -- the question is how.

Here's my proposal:

First, we need to document the situation as it stands, given the proxy

model and security mechanisms defined in RFC 3261 and relevant

extensions. I.e., in the current system, here's the base

(please-molest-me) model, here's what proxies can do to screw you up in

this model, and here's the sorts of assurances you can get by employing

some security features.

Second, rather than requiring boilerplate in documents defining new

extensions, they should comment on how the extension affects the model

described in the above document -- either providing additional security

(e.g., by limiting proxy capabilities like SIPSEC) or by introducing

additional risks (e.g., by increasing proxy capabilities, like

answer-mode). This discussion could be a required subsection of the

Security Considerations section.

I think that this would encourage people to give explicit consideration

to the sorts of risks Sandy noted in the answer-mode draft, and to think

about how they might fix or avoid them.

--Richard

Dean Willis wrote:

> I'm having quite an interesting conversation with Sandy Murphy (cc'd)

> who was tasked by sec-dir to review one of our drafts

> (draft-ietf-sip-answermode). This draft has some rather interesting

> security issues, since if implemented incorrectly and then abused it

> could allow an attacker to "bug your phone" -- that is, turn it into a

> remote listening device. Similar attacks could also be used to run up

> the victim's connectivity bill, run down the device's battery, aggravate

> the "voice hammer" DOS attack, and so on.

> This lead us into a discussion of the SIP security model in general.

> Most SIP practitioners who have been at it for awhile know that if the

> proxies we have decided to trust suddenly decide to get malicious, then

> we're very much at their mercy. They can do all sorts of things,

> including routing our media through interceptors, mangling SDP payloads,

> injecting (or blocking) instant messages, altering presence information,

> and so on.

> But this aspect of SIP is not obvious to naive implementors, or even to

> less naive security types.

> Maybe every SIP extension document should include a boiler-plate

> reminder about the sensitivity of proxies, then go on to enumerate and

> describe the new ways that malicious proxies (should there be such a

> thing) can wreak havoc using the extension being documented.

> what do you folks think?

> 1) Could a reasonable "How you could be violated by trusted proxies that

> turn rogue" boilerplate be drafted?

> 2) Would the practice of repeating this in drafts help or hurt us?

> 3) Would it be useful for us to document how each extension could be

> used by a rogue proxy?

> --

> 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

_______________________________________________

Sip mailing list https://www1.ietf.org/mailman/listinfo/sip

This list is for NEW development of the core SIP Protocol

Use [email-masked] for questions on current sip

Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 15 Aug 2007 08:30:05 -0700

I fully agree here. Only e2e security is real security and SIPS cannot
obfuscate this.

Thanks, Henry

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2007 9:40 AM
To: Dean Willis; Richard Barnes
Cc: sip List; Sandy Murphy
Subject: Re: [Sip] Question on SIP Security considerations forfuture
extensions

With all due respect, I don't agree with this.  Its my opinion that the
current model is well-understood and unsatifactory for many
applications.  While I think its fine to spend some time clarifying the
current model, I don't think that should hold up the development of an
end-to-end mechanism as well.  That development can proceed in parallel
and the sipsec draft is a good start in that direction.

To that end, after receiving the blessing of the majority of the
authors, I'm posting a proposal I made to them regarding a mod to the
sipsec draft that I believe would improve its ability to address true
end-to-end security.

The idea is simple, rather than having the CONNECT message establish a
"tunnel" through a series of proxies, CONNECT is used to trade
addressing information between the UAs that then signal each other
directly.  This proposal was made as modifications to the sipsec draft.
The draft is available as a standalone and as a diff to the current
sipsec draft at the following links.  Comments are hoped for...

Thanks,

FM

https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fm
iller/

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://svn.resipro
cate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.
txt&url2=http://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/s
ipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt

	I'm replying to Dean's original message so that I'm not deep
down in the 

	Here's my proposal:
	
	First, we need to document the situation as it stands, given the
proxy 
	model and security mechanisms defined in RFC 3261 and relevant 
	extensions. I.e., in the current system, here's the base 
	(please-molest-me) model, here's what proxies can do to screw
you up in 
	this model, and here's the sorts of assurances you can get by
employing 
	some security features.
	
	Second, rather than requiring boilerplate in documents defining
new 
	extensions, they should comment on how the extension affects the
model 
	described in the above document -- either providing additional
security 
	(e.g., by limiting proxy capabilities like SIPSEC) or by
introducing 
	additional risks (e.g., by increasing proxy capabilities, like 
	answer-mode). This discussion could be a required subsection of
the 
	Security Considerations section.
	
	I think that this would encourage people to give explicit
consideration 
	to the sorts of risks Sandy noted in the answer-mode draft, and
to think 
	about how they might fix or avoid them.
	
	--Richard

	
	
	> 3) Would it be useful for us to document how each extension
could be 
<http://sitemail.hostway.com/sitemail6/parse.pl?redirect=https%3A%2F%2Fw
ww1.ietf.org%2Fmailman%2Flistinfo%2Fsip> 
	> Use [email-masked]
<javascript:top.opencompose([email-masked]','','','')
>  for questions on current sip
	> Use [email-masked]
<javascript:top.opencompose([email-masked]','','','')>  for new
developments on the application of sip

	
	_______________________________________________
	Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
	This list is for NEW development of the core SIP Protocol
	Use [email-masked]
<javascript:top.opencompose([email-masked]','','','')
>  for questions on current sip
	Use [email-masked]
<javascript:top.opencompose([email-masked]','','','')>  for new
developments on the application of sip

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 15 Aug 2007 18:18:21 +0200

Frank,

Some comments on the draft you refer to below:

1 - why insert (Proxy-)Require: sipsec? it will not work through currently 
deployed proxies, while section 6.6 does not require any new proxy behavior. 
Perhaps because 6.3 requires proxies to process mutulated responses, but

2 - why make the CONNECT response different than a normal SIP response? 
doing that makes it incompatible with current infrastructure, while 
providing little benefit

3 - section 6.5 UAS behavior should probably say that a Contact MUST be 
present in CONNECT response, and that it SHOULD be sips:
4 - would be nice to have a mechanism to encrypt the Contact URI in the 
response, specifically for the caller. An incoming request to a contact that 
was sent encrypted gives higher trust. At least it should be integrity 
protected somehow.
5 - would it be beneficial to make a link to the sip-certs work 
(http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-04.txt)? For 
example, in the CONNECT method the caller could provide a reference to its 
certificate server (integrity-protected as part of the body for example)

6 - 6.3 should state that CONNECT is not a dialog creating request. 
Consequently, 6.5 should state that UAS MUST ignore any Record-Route headers 
present (and so not reflect them in the CONNECT response, although this 
might interfere with proxy functionality - but that's kind of the point, 
right?)

7 - You could consider providing guidance on information that is not 
relevant to the CONNECT request, but needed to make requests / responses 
well formed. For example, you could specify default values for To and From 
URIs (say [email-masked])

8 - Given that the Contact URIs need to be globally reachable (I guess how 
that is achieved should remain out of scope), they should be marked as 
(temporary?) GRUUs (i.e. include 'gr=xxx')

Regards,
Jeroen

----- Original Message ----- 
  From: [email-masked]
  To: Dean Willis ; Richard Barnes
  Cc: sip List ; Sandy Murphy
  Sent: Wednesday, August 15, 2007 4:39 PM
  Subject: Re: [Sip] Question on SIP Security considerations forfuture 
extensions

  With all due respect, I don't agree with this.  Its my opinion that the 
current model is well-understood and unsatifactory for many applications. 
While I think its fine to spend some time clarifying the current model, I 
don't think that should hold up the development of an end-to-end mechanism 
as well.  That development can proceed in parallel and the sipsec draft is a 
good start in that direction.

  To that end, after receiving the blessing of the majority of the authors, 
I'm posting a proposal I made to them regarding a mod to the sipsec draft 
that I believe would improve its ability to address true end-to-end 
security.

  The idea is simple, rather than having the CONNECT message establish a 
"tunnel" through a series of proxies, CONNECT is used to trade addressing 
information between the UAs that then signal each other directly.  This 
proposal was made as modifications to the sipsec draft.  The draft is 
available as a standalone and as a diff to the current sipsec draft at the 
following links.  Comments are hoped for...

  Thanks,

  FM

    Here's my proposal:

    --Richard

------------------------------------------------------------------------------

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Aug 2007 12:20:24 -0500

Actually, that is false in many cases.
 
It depends what you are trying to do, and who do you trust. 
 
There are many cases where I'd put a lot more trust in the proxies than
"the guys at the end of the lines". 
 
Who has the responsibility for Security is really what should drive the
solution.
 
An e2e model makes a lot of sense when the people that are engaged in
the session are the ones with the incentive for the session to be
secure. If Henry wants to talk to me, and we both want our session to be
secure, then that's the right model.
 
An e2e model does not make any sense when the people that are engaged in
the session don't care or are not savvy enough. For example, if I'm an
Enteprise IT manager (or operator of a Government internal network), I
may decide that I want all sessions between all my users to be secure
despite them. As the IT manager, I'd be responsible if a rogue employee
spies on collegue, regardless of how careless the other employees are.
 
I think it is important to be very clear on what we are trying to
achieve when talking about e2e (sipsec) or hop-by-hop (sips). They are
not meant to solve the same problem. 

	From: Henry Sinnreich [mailto:[email-masked]] 
	Sent: Wednesday, August 15, 2007 08:30
	To: [email-masked]; Dean Willis; Richard Barnes
	Cc: sip List; Sandy Murphy
	Subject: RE: [Sip] Question on SIP Security considerations
forfuture extensions

	I fully agree here. Only e2e security is real security and SIPS
cannot obfuscate this.

	Thanks, Henry

	Subject: Re: [Sip] Question on SIP Security considerations
forfuture extensions

	With all due respect, I don't agree with this.  Its my opinion
that the current model is well-understood and unsatifactory for many
applications.  While I think its fine to spend some time clarifying the
current model, I don't think that should hold up the development of an
end-to-end mechanism as well.  That development can proceed in parallel
and the sipsec draft is a good start in that direction.

	The idea is simple, rather than having the CONNECT message
establish a "tunnel" through a series of proxies, CONNECT is used to
trade addressing information between the UAs that then signal each other
directly.  This proposal was made as modifications to the sipsec draft.
The draft is available as a standalone and as a diff to the current
sipsec draft at the following links.  Comments are hoped for...

	Thanks,

	FM

	

		I'm replying to Dean's original message so that I'm not
deep down in the 
		thread, but I'd like to point to one of Dean's later

		Here's my proposal:
		
		First, we need to document the situation as it stands,
given the proxy 
		model and security mechanisms defined in RFC 3261 and
relevant 
		extensions. I.e., in the current system, here's the base

		(please-molest-me) model, here's what proxies can do to
screw you up in 
		this model, and here's the sorts of assurances you can
get by employing 
		some security features.
		
		Second, rather than requiring boilerplate in documents
defining new 
		extensions, they should comment on how the extension
affects the model 
		described in the above document -- either providing
additional security 
		(e.g., by limiting proxy capabilities like SIPSEC) or by
introducing 
		additional risks (e.g., by increasing proxy
capabilities, like 
		answer-mode). This discussion could be a required
subsection of the 
		Security Considerations section.
		
		I think that this would encourage people to give
explicit consideration 
		to the sorts of risks Sandy noted in the answer-mode
draft, and to think 
		about how they might fix or avoid them.
		
		--Richard

		
		
		Dean Willis wrote:
		> Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
<http://sitemail.hostway.com/sitemail6/parse.pl?redirect=https%3A%2F%2Fw
ww1.ietf.org%2Fmailman%2Flistinfo%2Fsip> 

		
		_______________________________________________
		Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
		This list is for NEW development of the core SIP
Protocol
		Use [email-masked]
<javascript:top.opencompose([email-masked]','','','')
		Use [email-masked]

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 15 Aug 2007 19:23:05 +0200

Frank,

Elaborating on:

Suppose the UAS would include a new header "Secure-Contact" containing a 
contact URI encrypted using a key that the caller passed in its CONNECT 
request. That would provide:
- a means for the UAC to check the integrity of the contact
- a means for the UAS to verify that the caller is the same as the party 
that CONNECTed before (i.e. by including some unique bits in the contact 
URI)
- a way to avoid B2BUA elements blocking CONNECT by not forwarding the UAS 
Contact header

Furthermore, the draft could talk about how the UAS could specify a 
different machine than itself, for example a proxy with which it maintains 
an outbound connection. This could be a different proxy than the one through 
which the CONNECT came in. It could also be a proxy with which the UAS 
maintains a non-SIP connection (say a VPN/IPSec connection). Such a proxy 
might not be able to present a certificate on behalf of the UAS, but at 
least it would provide a mechanism to side step the SIP proxy infrastructure

Regards,
Jeroen

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Aug 2007 12:26:25 -0500

I view this as an "optimization" of the original draft.
 
The real question is "Are there cases where the original draft would
work, but not Frank's draft". At first glance, one may say, "yes, with
symmetric NATs for example". But in this case, media wouldn't work
either (unless you have a TURN server). If you have that luxyry, then it
may be better. However, there are cases like IM that only use a
signalling channel where the first draft would be simpler.
 
My gut feel is that we should try to use Frank's optimization when
possible (i.e., when plain STUN works), and then decide if we keep the
existing mechanism (tunnelling through proxies or use a seperate TURN
server) later.
 
Interestingly enough, this is quite analogous to the ICE vs.
"hole-punching" debate of a few weeks ago.

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Wednesday, August 15, 2007 07:40
	To: Dean Willis; Richard Barnes
	Cc: sip List; Sandy Murphy
	Subject: Re: [Sip] Question on SIP Security considerations for
future extensions

	Thanks,

	FM

	

		
		
		Here's my proposal:

		

		--Richard

		
		
Protocol

		
		Use [email-masked]

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 15 Aug 2007 19:00:24 -0400

Comment on the draft:
I think you should specify exactly what the automated validity check of the
certificate is.  AFAIK, it is rare for a user PC to have a cert with any
useful identity signed by a well-known cert authority, and that’s a big
roadblock for this thing.  One thing you could do is use a similar trick to
what zrtp used, such as to have the application on each side present the
user with a shortened string form of the fingerprint, for them to read out
to each other if they feel paranoid. At least that way self-signed certs
could be useful in some cases. (won’t work for IM though)  

-hadriel

________________________________________
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2007 10:40 AM
To: Dean Willis; Richard Barnes
Cc: sip List; Sandy Murphy
Subject: Re: [Sip] Question on SIP Security considerations forfuture
extensions

https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fmille
r/

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://svn.resiprocate
.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt&url2
=http://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fmille
r/draft-gurbani-sip-sipsec-fmiller-00.txt

Here's my proposal:

--Richard

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 15 Aug 2007 19:09:06 -0400

I don't see how the contact encryption would prove anything about either
side.  A middle-man can just as easily use the key from the Connect message
to encrypt its own contact URI.  

As for the last point, any b2bua or proxy wanting to block the Connect would
simply block the Connect (reject it with a 420 or 501, for example).  They
don't need to muck with the contact.

-hadriel

  _____  

From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2007 1:23 PM
To: [email-masked]
Cc: sip List
Subject: Re: SIPSEC comments (Was Re: [Sip] Question on
SIPSecurityconsiderations forfuture extensions)

Frank,

Elaborating on:

 

Regards,

Jeroen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 16 Aug 2007 01:25:33 +0200

Hadriel,

MITM encrypting its own URI: true, but it would not be able to determine 
which Contact URI the UAS proposed (it could be different from the UAS' own 
IP address+port). If the MITM would try to impersonate the caller while 
"guessing" the Contact, the UAS would detect that the request URI did not 
contain its magic bits. The UAS could formulate these bits such that it can 
correlate a request after CONNECT with an earlier CONNECT, and refuse all 
"out-of-the-blue" requests (and do things like enforce a maximum time 
interval, etc.)

My point about the additional benefit of using a header different from 
"Contact", is that current B2BUA implementations (e.g. SBC) typically insert 
their own Contact. However, some do pass headers unknown to them, so a new 
header could survive a B2BUA that would otherwise 
unknowingly/unintentionally block a CONNECT.

Regards,
Jeroen

  ----- Original Message ----- 
  From: Hadriel Kaplan
  To: 'Jeroen van Bemmel' ; [email-masked]
  Cc: 'sip List'
  Sent: Thursday, August 16, 2007 1:09 AM
  Subject: RE: SIPSEC comments (Was Re: [Sip] Question on 

  As for the last point, any b2bua or proxy wanting to block the Connect 
would simply block the Connect (reject it with a 420 or 501, for example). 
They don't need to muck with the contact.

  -hadriel

  Frank,

  Elaborating on:

  Regards,

  Jeroen

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 15 Aug 2007 21:55:05 -0400

_____  

From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2007 7:26 PM
To: Hadriel Kaplan; [email-masked]
Cc: 'sip List'
Subject: Re: SIPSEC comments (Was Re: [Sip] Question on
SIPSecurityconsiderations forfuture extensions)

Hadriel,

Ahh, I think I understand what you mean - essentially stick a timed cookie
param in the contact-uri or this header so that the UAS knows the incoming
Invite was from a previous Connect.  So not really stopping a MITM as much
as just un-authorized Invites?  I don't think it really stops MITM because
the MITM will get the 200 ok of the Connect and thus know the
contact/req-uri to use for the Invite.  It's really the cert verification
before the Invite that would prevent MITM, and thus my question in another
email of what that verification would be.  One could actually have the UAC
and UAS stick their cert fingerprint in the Connect header, so that the
UAS/UAC can check the new TLS connection is from that previous Connect,
before even receiving an Invite. (but it would still not stop a MITM unless
there was some way to verify the cert's validity)

Ahh, got it.  But if a b2bua wanted to let the Connect happen it would get
out of the way and not replace the contact.  (but of course I don't think a
b2bua would want to let that happen, because I don't think their owners
would want to let it happen - and they have the control to stop it)

Regards,

Jeroen

----- Original Message ----- 

From: Hadriel <mailto:[email-masked]>  Kaplan 

To: 'Jeroen van Bemmel' <mailto:[email-masked]>  ; [email-masked] 

Cc: 'sip List' <mailto:[email-masked]>  

-hadriel

  _____  

Frank,

Elaborating on:

 

Regards,

Jeroen

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 15 Aug 2007 22:29:23 -0600

Thanks for the comments.
 
Let me first describe how we got to this point.  Hopefully that will
help when people start to make comments.
 
When I read the sipsec draft, it struck me that there was the
opportunity to provide a real end-to-end solution as I've proposed based
on the CONNECT method.  I contacted Vijay and asked for the XML for the
draft.  I spent some time sketching what I was thinking about within the
context of the draft XML and sent it to Vijay, Francois, and Dean.  I
purposely did not fill in all the details because I suspected that there
would be discussion about it and so wanted to wait until there was some
indication that adding details would be fruitful.  There has been some
discussion as was alluded to by Francois in another email.  Mainly, the
question seems to be if this should be noted as an optimization to the
originally proposed mechanism or should replace the originally proposed
mechanism.
 
All this took place in private emails among the four of us and I did not
want to post it on the list until the authors were comfortable with
that.  So, when this discussion thread around security came up, it
contained some interesting points that were relevant to the proposal.  I
asked the authors if it would be ok to post the links and they said fine
and so here we are.
 
All that said, my opinion would be similar to what Francois sent
earlier.  I believe this should be the default mechanism and that the
proxy tunneling machinery, if kept at all, should be used only in
situations where some network topology forces it.  However, the draft
belongs to the authors and they need to determine what happens next.  If
this change is incorporated, I would have opinions on the comments that
you made and I'll respond inline here:
 
Thanks,
FM

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2007 10:18 AM
To: [email-masked]
Cc: sip List
Subject: SIPSEC comments (Was Re: [Sip] Question on SIP Security
considerations forfuture extensions)
 
Frank,

1 - why insert (Proxy-)Require: sipsec? it will not work through
currently deployed proxies, while section 6.6 does not require any new
proxy behavior. Perhaps because 6.3 requires proxies to process
mutulated responses, but
 
FM: That's legacy from the original draft.  We can revisit that I think.
It may not make sense with this approach.

FM: As mentioned, I was sketching the basics of the solutions.  Specific
responses can be changes as needed.

FM: I agree.
 
4 - would be nice to have a mechanism to encrypt the Contact URI in the
response, specifically for the caller. An incoming request to a contact
that was sent encrypted gives higher trust. At least it should be
integrity protected somehow. 
 
FM: I don't have strong feelings on this.  I think that encrypting this
URI might yield implementation complexity that may not buy much.
 
5 - would it be beneficial to make a link to the sip-certs work
(http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-04.txt)? For
example, in the CONNECT method the caller could provide a reference to
its certificate server (integrity-protected as part of the body for
example)
 
FM: I'm sure there will be lots of discussion about this.  I do think
that self-signing should be allowed so that parties that want to use it
can.
 
6 - 6.3 should state that CONNECT is not a dialog creating request.
Consequently, 6.5 should state that UAS MUST ignore any Record-Route
headers present (and so not reflect them in the CONNECT response,
although this might interfere with proxy functionality - but that's kind
of the point, right?)
 
FM: I agree.
 
7 - You could consider providing guidance on information that is not
relevant to the CONNECT request, but needed to make requests / responses
well formed. For example, you could specify default values for To and
>From URIs (say [email-masked])
 
FM: I think there is a lot more specification that needs to be done.
 
8 - Given that the Contact URIs need to be globally reachable (I guess
how that is achieved should remain out of scope), they should be marked
as (temporary?) GRUUs (i.e. include 'gr=xxx')
 
FM: If there was ever an application for GRUUs, this has to be it.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 17 Aug 2007 15:38:26 -0700

The guys are you and me :-)

If it's an enterprise network, then the enterprise network is the
endpoint and we agree here.

Now what about all those service provider networks in the middle?

Henry

From: Francois Audet [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2007 12:20 PM
To: Henry Sinnreich; [email-masked]; Dean Willis; Richard Barnes
Cc: sip List; Sandy Murphy
Subject: RE: [Sip] Question on SIP Security considerations forfuture
extensions

	

	Thanks, Henry

	 

	Thanks,

	FM

	

		
		
		Here's my proposal:

		

		--Richard

		
		
Protocol

		
		Use [email-masked]

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 17 Aug 2007 17:41:01 -0500

Which service providers in the middle? :^)
 
All that is needed is an IP network.

	From: Henry Sinnreich [mailto:[email-masked]] 
	Sent: Friday, August 17, 2007 15:38
	To: Audet, Francois (SC100:3055); [email-masked]; Dean
Willis; Richard Barnes
	Cc: sip List; Sandy Murphy
	Subject: RE: [Sip] Question on SIP Security considerations
forfuture extensions

	>There are many cases where I'd put a lot more trust in the
proxies than "the guys at the end of the lines". 

	If it's an enterprise network, then the enterprise network is
the endpoint and we agree here.

	Now what about all those service provider networks in the
middle?

	Henry

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 19 Aug 2007 11:18:33 -0700

Francois, thanks for the note!

Sorry, since I had forgotten the possibility of the private network
proxy being compromised:

-          If it is a financial institution , it is an open door to
steal money,

-          If it is a law enforcement organization, the agents will get
killed,

-          SIPS for proxies is just as bad for any private network as
well as for service providers and their customers.

>From this perspective, any intermediary is either an invitation for some
bad or outright dangerous behavior.

SIPS cannot obfuscate that the only security is e2e. Any intermediary is
vulnerability.

Henry

Sent: Friday, August 17, 2007 5:41 PM

	

	Henry

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 20 Aug 2007 11:51:56 -0500

I don't know, but my proxie's administrator is a lot more competent and
trusworthy at setting up security properly than the average Joe on the
internet. And I don't know what IT person would be stupid enough to
trust its users.
 
Now, perhaps savvy users would want their own overlay of end-to-end
security. That would be fine too.

	Sent: Sunday, August 19, 2007 11:19

	Sorry, since I had forgotten the possibility of the private
network proxy being compromised:

	-          If it is a financial institution , it is an open door
to steal money,

	-          If it is a law enforcement organization, the agents
will get killed,

	-          SIPS for proxies is just as bad for any private
network as well as for service providers and their customers.

	From this perspective, any intermediary is either an invitation
for some bad or outright dangerous behavior.

	SIPS cannot obfuscate that the only security is e2e. Any
intermediary is vulnerability.

	Henry

	To: Henry Sinnreich; [email-masked]; Dean Willis; Richard
Barnes

		

		From: Henry Sinnreich [mailto:[email-masked]] 
		Sent: Friday, August 17, 2007 15:38
		To: Audet, Francois (SC100:3055); [email-masked];
Dean Willis; Richard Barnes
		Cc: sip List; Sandy Murphy
		Subject: RE: [Sip] Question on SIP Security
considerations forfuture extensions

		>There are many cases where I'd put a lot more trust in
the proxies than "the guys at the end of the lines". 

		If it's an enterprise network, then the enterprise
network is the endpoint and we agree here.

		Now what about all those service provider networks in
the middle?

		Henry