Subject: [Sip] draft-audet-sip-sips-guidelines-03.txt

From: "Francois Audet" <[email-masked]>
Date: Wed, 23 Aug 2006 16:53:39 -0500

Hi all,

I want to draw people's attention to a revision of the SIPS guidelines 
draft:
http://www.ietf.org/internet-drafts/draft-audet-sip-sips-guidelines-03.t
xt.

The intent is to re-issue this a a working group document as per
the decision in Montreal before the San Diego meeting. In the meanwile,
in light of the number of changes, here is an update.

This draft has been completely re-written in light of the 
decisions made in Montreal, and in light of what follows from these
decisions.

The key changes are as follows:

- Clarification of the meaning of SIPS, i.e., implies transitive trust.

- Clarification of the justification for the "last-hop exception rule".
  It does NOT mean that the terminating side may not support TLS (for
  example, for its own outbound requests). 

- SIP-outbound and Record-Route are required for enabling support
  of SIPS in practical deployments.

- SIP routing is independent of the scheme in the AOR and the transport.
It is
  the association of a AOR to a particular Contact in a Registration
that
  will determined if a request is routable with SIPS. This caused a 
  complete rewrite of the Registration section.

The good news is that after going through this significant rewrite of
the 
draft, with the new assumptions on routing, I believe that RFC 3261 is
not really as "broken" as initially tought (but it is indeed
"underspecified"). 
The drafts highlights a few nit-picks, but broadly, I think that we can
say 
that SIPS is implementable without significant normative changes to RFC
3261.

Please review and provide feedback.
_______________________________________________
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: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 24 Aug 2006 16:11:32 -0400

Minor comments:

Section 4 discusses "upgrades" and "downgrades", which is good because 3261
is ambiguous about it.  Not a big deal, but I think you should specify who
can do upgrading.  Obviously the UAC can decide to "upgrade" by just trying
a sips URI.  But if some proxy tries upgrading, and it fails, the UAC has no
way to make the proxy not try upgrading again the next time.  A proxy should
not just try without some reasonable foreknowledge of success?  (e.g., a
location service has such foreknowledge)

Also, does the (old) exception rule really mean downgrading, i.e. replacing
the req-URI with a SIP of the registered contact?  Or does it mean the
req-URI is still SIPS but the message is simply sent over non-TLS to the
UAS?

Section 3 last sentence says one may use Identity instead of or with sips,
implying identity is end-to-end.  It's not.  It's essentially
domain-to-domain or domain-to-end, IMO.  The signing proxy or something
before it can (and I'm fairly confident will in some cases) change things.

Section 3, page 5 says if a SIPS Request-URI was used, then the UAS would
have to support SIPS to generate a Bye, unless Record-Route is used.  Why
would a Record-Route solve that problem?  Per 3261 the Record-Route would
also have to be a SIPS URI, no? 

Editorial but important:
Sec 3, page 5: "This means that b@B, upon sending a new Request (e.g., a
BYE), will have to use a SIP URI (unless Record-Route is used)."  I assume
you meant SIPS.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Thu, 24 Aug 2006 15:17:30 -0500

> req-URI is still SIPS but the message is simply sent over non-TLS  

I'd really like to fix SIP so that contact-routing operations just  
add routes instead of replacing the request-URI. That would make  
several things much nicer.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 24 Aug 2006 18:27:26 -0500

> Minor comments:
> 
> Section 4 discusses "upgrades" and "downgrades", which is 
> good because 3261 is ambiguous about it.  Not a big deal, but 
> I think you should specify who can do upgrading.  Obviously 
> the UAC can decide to "upgrade" by just trying a sips URI.  
> But if some proxy tries upgrading, and it fails, the UAC has 
> no way to make the proxy not try upgrading again the next 
> time.  A proxy should not just try without some reasonable 
> foreknowledge of success?  (e.g., a location service has such 
> foreknowledge)

Agree. I need to ask some wording to this effect.

Basically, a proxy "upgrades" from SIP to SIPS when it has
legitimate reasons to do do. For example, if the binding
associated with the AOR is a SIPS Contact, it would 
"upgrade" the Request-URI to a sips URI. This is illustrated
in message F13 in section 10.2.

> Also, does the (old) exception rule really mean downgrading, 
> i.e. replacing the req-URI with a SIP of the registered 
> contact?  Or does it mean the req-URI is still SIPS but the 
> message is simply sent over non-TLS to the UAS?

I would say that the Request-URI would be sent to whatever
contact was used in Registration for the last hop, i.e., to
the sip URI.

> Section 3 last sentence says one may use Identity instead of 
> or with sips, implying identity is end-to-end.  It's not.  
> It's essentially domain-to-domain or domain-to-end, IMO.  The 
> signing proxy or something before it can (and I'm fairly 
> confident will in some cases) change things.

You are correct. I will make the change.

> Section 3, page 5 says if a SIPS Request-URI was used, then 
> the UAS would have to support SIPS to generate a Bye, unless 
> Record-Route is used.  Why would a Record-Route solve that 
> problem?  Per 3261 the Record-Route would also have to be a 
> SIPS URI, no?

You are correct: brain fart on my part. I was thinking of
something else. I'll remove the "(unless Record-Route is used)".
 
> Editorial but important:
> Sec 3, page 5: "This means that b@B, upon sending a new 
> Request (e.g., a BYE), will have to use a SIP URI (unless 
> Record-Route is used)."  I assume you meant SIPS.

Oops. My bad. Yes, it will be fixed.

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 29 Aug 2006 16:41:26 -0500

Hi,

Here are my comments on this draft in my first reading and I didn't read
the call flows.  

BTW, In the last ad-hoc security meeting consensus on SIPS was without
any discussion on Proxy-Require. Looked like me in the minority. 

This draft has still 8 OPEN ISSUES in 4 iterations and more ISSUES to
come /listed below. Group good luck with the plethora of text coming for
SIPS :-)

1) Draft is completely silent on the application usages like E911,
VoiceMail etc, and other secure transport protocols like DTLS. If DTLS
is not considered, it should be stated explicitly. Also we need a
separate section for B2BUA (Which some hates).

2) Page 4 Section 3 states "One may then wonder why TLS is mandatory
between UA a@A and Proxy A
   but not between Proxy A and UA b@B. The main reason is that RFC 3261
   [RFC3261] was written before [I-D.ietf-sip-outbound]."
   
   First the above should be Proxy B. And I would like to bring the
following text from 3261, Section 26.3.2.1 

      "Once the registration has been accepted by the registrar, the UA
   SHOULD leave this TLS connection open provided that the registrar
   also acts as the proxy server to which requests are sent for users in
   this administrative domain.  The existing TLS connection will be
   reused to deliver incoming requests to the UA that has just completed
   registration.

      Because the UA has already authenticated the server on the other
      side of the TLS connection, all requests that come over this
      connection are known to have passed through the proxy server -
      attackers cannot create spoofed requests that appear to have been
      sent through that proxy server."

   Which itself states that TLS connection SHOULD be kept alive. So
logic w.r.t. out-bound doesn't make more sense. Though 3261 doesn't
cover the case when Proxy and Registrar are not co-resident.

3) UA A, Proxy A etc should have the example names as specified in RFC
2606
   And it will be better if trapezoid of 3261 is taken.

4) The Following text from section 3 

   "This means that b@B, upon sending a new Request (e.g., a BYE), will
have
   to use a SIP URI (unless Record-Route is used).  This implies that
   b@B must understand SIPS in the first place, and must also support
   TLS (again, unless Record-Route happens to be used). "

   Here strict / loose routing will have different behaviors. Are there
any implementation of SIPS with strict Routing?

5) Quoting further from the section 3
   "The SIPS scheme implies transitive trust.  Obviously, there is
   nothing that prevents a proxy to cheat and pretend that TLS was used
   when in fact is was not (see RFC 3261/26.4.4). "

   Proxies cannot pretend use of TLS, unless two adjacent proxies
collaborate. Proxy at next hop can verify the Transport on which packet
is received with the transport being put by the proxy in via header.

6) In section 4,  

 "When a proxy is handling the 3XX, it can
   obviously not indicate anything to the user that it is being
   redirected from SIPS to SIP: therefore, it is RECOMMENDED that the
   proxy forwards the 3XX to the UAC instead of recursing, in order to
   allow for the UAC to take the appropriate action. "

   Why it is of RECOMMENDED strength? I would rather have it with
stronger strength. Implementers / Administrators may _not_ follow this,
and still they will comply with this standard (TBD). And UAC has no
control.

7) Going further in section 4, where it is describing the potential
algorithms for finding the e2e TLS by UAS last bullet reads

"If the dialog was "tentatively" secure, it is RECOMMENDED that the
security be checked by checking both the Via headers and the
Record-route, as described in 26.4.4/RFC 3261. "

 Record-Route is for the next request in the dialog. Only Via header
inspection is needed for this request. Record-Route should be removed.
If there is mismatch in these two what should be done?

8)Further in the next paragraph it states 
   "Some proxies MAY be configured to
   detect uncompliancies and reject unsecure requests.  For example, it
   could inspect Request-URIs, Path, Record-Route, To, From, Contacts
   and Via headers to enforce SIPS. "

  Why inspection of From Header ? 

9) In the next para, it is listing the usage of S/MIME. We have no
deployments of S/MIME and issues are listed in 3261 too. Why we keep
going to S/MIME now and then? IMHO, we need to have *DEPLOYABLE*
security.

10) In Section 5, in para 4 it is referencing the best-effort,
No-Security etc configuration policies. Are they covered in
Config-framework ? Whether we are going to have the separate config
framework for SIPS ?

11) In Section 5, in para 8 it states

   "It is therefore RECOMMENDED that UACs do not use any transport URI
   parameters in Contacts in REGISTER" .

   How does UAC show its preference among TCP/UDP/SCTP/DCCP ? It should
not use transport=tls parameter. If it is not allowed, then it should be
stated that 3263 based DNS procedures is the only choice. Look for the
scaling now, SIPS/SIP variable with outbound variables etc ?

12) Section 6, gives the example of INVITE, SUBSCRIBE, REFER for the
dialog creation etc. What will be done for PUBLISH, which is not a
dialog creating request and results in NOTIFY ? 3903 talks about the
SIPS but it is silent on when ESC gets the PUBLISH with SIPS and
WATCHERS have not subscribed with SIPS. The similar goes with REG-EVENT
too. It's a functionality for a new tag (TBD) in Require header, As UA
may not want it's secure contact/presence to be distributed over the
un-secure channels. It will open up Reg-id, and instance-id to
attackers.

13) Section 7 heading " Usage of tls and TLS parameters" is misleading.
Atleast to me TLS parameters means cipher-suite, digest, key size etc ?
Better can be "Usage of TLS as the transport parameter in SIP URI"

14) Section 7, bullet 4 states
 
"In a Request-URI, the transport parameter is useless in general
      because it is hop-by-hop." 

It needs more qualifiers w.r.t. Strict/loose Routing etc.

15) The description in Section 9 doesn't consider the text quoted above
from 3261, which is quoted above in 2).

16) This draft needs a lot of editorial cleaning too. e.g.

16.1) Section 1, para 2, second sentence has "I" only.

16.2) Section 3, para 5, last sentence " UAs that do not support TLS"
should have been "UAS that does not" 

16.3) Section 4, para 2, second last sentence
"Specifically, it says they" should have been "Specifically, it says
that they .."

16.4) Section 5, para 1, first sentence
"This section describes the registration procedures of SIP versus SIP"
Should be ".. SIPS versus SIP"

16.5) Section 5, para 2, first sentence
"Since upgrading from SIP to SIPS is allowed it other circumstances"
 Should be " ... in other circumstances"

16.6) Section 5, Para 3, should list the behavior for " SIP AOR and SIPS
Contact" and "SIPS AOR and SIP Contact" explicitly.

16.7) Section 5, Para 6, " SIPS schem:" should be scheme 
Also third party registration needs some discussion somewhere.

16.8) Section 6, Para 1, second sentence should not contain additional
"t" in the following segment " RFC 3261/8.1.1.8, t, if" 

16.9) Section 6, Para 1, next sentence has two "end" in the following
the remote end end  not support SIPS"

16.10) Section 7, bullet 1, last sentence "Since thet" should be "Since
then"

There is more editorial stuff, so I will wait for its cleanup first.

Thx
Samir

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 30 Aug 2006 09:49:52 -0400

Hi Samir, comments inline...

> -----Original Message-----
> From: Samir Srivastava [mailto:[email-masked]]
>

What else is there to require?  The sips scheme already requires a proxy to
follow sips rules.

> is received with the transport being put by the proxy in via header.

Here we go again.  :)  What you say is true - it takes 2 to conspire, and
that should be noted.  But of course such a "conspiracy" is not unlikely for
this use case. 

> going to S/MIME now and then? IMHO, we need to have *DEPLOYABLE*

If that's the case, then SIPS is moot as well.  We have no deployments to
speak of, and it has so many caveats one wonders what security it ends up
providing beyond a feel-good story for RFCs. (sorry, didn't mean to go down
that rat-hole again, but I couldn't help it :)

-hadriel

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 30 Aug 2006 16:42:32 -0500

Hi Hadriel,

   Inline.

   I am leaving cipher-suite consideration with SIPS, till I publish
next version, and we get some consensus.

Thx
Samir

> 
> What else is there to require?  The sips scheme already requires a
proxy
> to

Problem is with retargeting etc, which is of the RECOMMENDED strength in
the draft. UAC doesn't have control, which I put in another comment.

> that should be noted.  But of course such a "conspiracy" is not
unlikely
> for

You agree two to conspire. So statement in the draft needs the
modification.
 
> that rat-hole again, but I couldn't help it :)

S/MIME is older than SIPS :-)

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 30 Aug 2006 19:20:47 -0500

Thanks for your comments Samir. I'll incorporate the obvious ones in
my next release.

I'm selecting a few ones here that needs further discussion.

> 1) Draft is completely silent on the application usages like 
> E911, VoiceMail etc, and other secure transport protocols 
> like DTLS. If DTLS is not considered, it should be stated 
> explicitly. 

We can not do this before (and if) SIP supports DTLS. As for if
SIPS would apply to DTLS, we haven't discussed that on the list
yet as it is premature.

> Also we need a separate section for B2BUA (Which 
> some hates).

Definitively not. There will be no section on B2BUAs.

>    Why it is of RECOMMENDED strength? I would rather have it 
> with stronger strength. Implementers / Administrators may 
> _not_ follow this, and still they will comply with this 
> standard (TBD). And UAC has no control.

I'll flag it as oppen issue. But you are correct, if we decide to use
RECOMMENDED instead of MUST, we MUST say why (my best guess would be
for not diverging unecessarily from RFC 3261).

I'd like input from the group. No strong opinion on my side.

> 7) Going further in section 4, where it is describing the 
> potential algorithms for finding the e2e TLS by UAS last bullet reads
> 
> "If the dialog was "tentatively" secure, it is RECOMMENDED 
> that the security be checked by checking both the Via headers 
> and the Record-route, as described in 26.4.4/RFC 3261. "
> 
>  Record-Route is for the next request in the dialog. Only Via 
> header inspection is needed for this request. Record-Route 
> should be removed.

Yeah, I'm not sure why we are talking about Record-Route here.

Paul Kyzivat, do you remember? I believe that was your wording.

> 10) In Section 5, in para 4 it is referencing the 
> best-effort, No-Security etc configuration policies. Are they 
> covered in Config-framework ? Whether we are going to have 
> the separate config framework for SIPS ?

Out-of-scope of this document.

>    How does UAC show its preference among TCP/UDP/SCTP/DCCP ? 

It does not show a preference. That's the whole point of the draft.

> 12) Section 6, gives the example of INVITE, SUBSCRIBE, REFER 
> for the dialog creation etc. What will be done for PUBLISH, 
> which is not a dialog creating request and results in NOTIFY 
> ? 3903 talks about the SIPS but it is silent on when ESC gets 
> the PUBLISH with SIPS and WATCHERS have not subscribed with 
> SIPS. The similar goes with REG-EVENT too. It's a 
> functionality for a new tag (TBD) in Require header, As UA 
> may not want it's secure contact/presence to be distributed 
> over the un-secure channels. It will open up Reg-id, and 
> instance-id to attackers.

Not following you.

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 30 Aug 2006 20:19:32 -0500

Hi Francois,

  In -line.

Thx
Samir
 
> SIPS would apply to DTLS, we haven't discussed that on the list

I agree DTLS is premature. And we know that DTLS does exist as standard
track RFC. I posted the use case for this too, Short Page Mode IM.
Either we can state that DTLS is considered completely out of scope for
SIP or it will be considered in the different document etc. Group needs
to close on UDP and DTLS sooner. This is the place where SIPS broken
with its current transport-parameter definition.

> Definitively not. There will be no section on B2BUAs.

So you are from the hate camp :-) and SBC/B2BUA is reality. Hadriel what
you say?
 
> I'd like input from the group. No strong opinion on my side.
Fine.
 
> Out-of-scope of this document.

Agreed. We need to see what group thinks on this as a separate draft or
taking SIPS to current drafts. I didn't go through config-framework.
Config-framework experts?

> It does not show a preference. That's the whole point of the draft.

Then we need to state that ONLY RFC3263 defined procedures will be
followed for determining the preferences now on.
 
> > instance-id to attackers.

Let me rephrase the use case.

"If UAC is particular about the security, then he would not like his
contacts to be sent over the un-secure channel to the SUBSCRIBERS of
REG-EVENT. With the tag (TBD) in Require header, he can control this. "

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 30 Aug 2006 23:49:15 -0400

> the draft. UAC doesn't have control, which I put in another comment.

When you say "retargeting" do you mean recursing on a 3xx, or the proxy
changing the req-URI due to local routing policies?  The former is all the
draft says a proxy is recommended not to do from sips to sip.  The 3xx case
is an interesting situation, since the sips UAS has essentially granted
permission to retarget to sip.  So you'd need a require header to tell the
UAS not to do that, vs. proxy require.

If you put a proxy-require, then all the proxies along the path have to
support that proxy-require.  That would be another barrier to getting sips
used.

If you meant retarget due to a local routing policy, then the UAC does not
have control, and adding a proxy-require won't give it to him.  The sips
scheme is essentially a faith-based model.  The UAC and UAS are putting
their faith into the proxies to do the right thing.  If a proxy decides it
knows better, due to local policy, then that same proxy would know better
about a proxy-require and ignore it too.

If a proxy retargets to a non-sips target, it probably has some good reason
(it thinks) for doing it.  For example, it wants to send your call to
voicemail which may be directly attached in the same rack, or it wants to
send your call to a local PSTN gateway, or to an operator, or whatever.
After all there's probably some reason people use retargeting proxies, no?

-hadriel

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 31 Aug 2006 08:40:04 +0300

Samir Srivastava writes:

 > > > Also we need a separate section for B2BUA (Which some hates).
 > > 

they may be reality, but have nothing to do with this draft.  b2bua
creates two separate sip dialogs and the draft applies to both
separately.  whatever mappings you do in your b2bua is not up to
standardization.

-- juha

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 30 Aug 2006 22:45:31 -0400

> So you are from the hate camp :-) and SBC/B2BUA is reality. Hadriel what

Oh I agree with Francois. :)  They should not be called out in this doc.
First there're a lot more b2bua's than just SBCs (for example, many app
servers I've seen become b2bua's for some scenarios), second because they're
UA's.  As a UAS they would do what the UAS does for sips, as a UAC they
would do what a UAC does for sips.  

No matter what you mandate my guess is they will do what their owners want
them to do.  For example, if their owners want them to send a sips request
over IPSEC instead, they will.  If their owners want them to act as a sips
transparent b2bua, they will.  Etc. 

-hadriel

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 31 Aug 2006 13:16:26 -0500

> them to do.  

On the same lines, Then Proxies can do whatever their
owners/administrators want them to do too.

Thx
Samir

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 31 Aug 2006 14:19:44 -0500

> First there're a lot more b2bua's than just SBCs (for 
> example, many app servers I've seen become b2bua's for some 
> scenarios), second because they're UA's.  As a UAS they would 
> do what the UAS does for sips, as a UAC they would do what a 
> UAC does for sips.  
> 
> No matter what you mandate my guess is they will do what 
> their owners want them to do.  For example, if their owners 
> want them to send a sips request over IPSEC instead, they 
> will.  If their owners want them to act as a sips transparent 
> b2bua, they will.  Etc. 

Exactly.

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 31 Aug 2006 16:06:16 -0500

Hi Hadriel,

In-line.

Thx
Samir

> support that proxy-require.  That would be another barrier to getting
sips

This is same as all the proxies in the path need to support SIPS. So I
don't see another barrier. This is a Proxy routing rule. So It will need
Proxy-Require. Looks like I am not following you for Require tag.

My issue was with the following text of Section 4, where strength was
RECOMMENDED.

Francois accepted the comment. And will be adding more text etc.

> After all there's probably some reason people use retargeting proxies,
no?

That's the one reason, we need reverse channel for indicating security
employed at each hop to UAC in the response.