Subject: [Sip] 'sips' URI scheme (comments on proposal?)

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 12 Feb 2002 05:21:01 -0600

As something of a last-minute feature to supplement the SIP security story,
the editors have been kicking around the idea of a TLS-specific URI scheme
known as SIPS, that would be used in URIs like: 'sips:[email-masked]'. We
believe that the SIPS scheme potentially has applicability to many of the
ways in which URIs are used in SIP architectures today, including in the
Request-URI, in addresses-of-record (which would appear in the To/From field
of messages), contact addresses (populating Contact headers, including those
of REGISTER methods), and Route headers. The SIPS scheme allows those fields
to designate secure resources.

First off, let's be clear that this is a TLS-specific feature; like HTTPS,
its ancestor, it signifies that the resource identified by the URI should be
contacted over TLS. TLS is a SHOULD for UAs, and thus support for these
procedures in UAs is conditional on support for TLS. Most powerfully, when
used for an address-of-record (the URI you put on your business cards, that
you put in the To/From field of requests you send, the address for which you
register), the scheme signifies that each hop over which the request travels
must be secured with TLS, or more precisely that:

- When a SIP entity attempts to forward a request whose Request-URI uses the
SIPS URI scheme, if the next hop cannot accept the request over a TLS
connection, the request MUST fail.

In effect, using SIPS in the Request-URI ensures that TLS is used on every
segment between the originator of the request and the destination. This is a
handy service, though admittedly one that is specific to architectures in
which it is desirable to use TLS for every hop. Note that users handing out
contact addresses today have no effective means of expressing a security
preference for TLS; if 'sip:[email-masked];transport=tls' is in the
Request-URI, the 'transport' parameter may be removed by the first hop that
dereferences the URI, and thus any subsequent hops might be unsecured -
however, it doesn't seem far-fetched that Alice might naively assume that
the transport parameters would pertain to the entire request path.

As an aside, this also hints at one of the benefits of the SIPS URI scheme:
transport is independent of TLS, and thus
'sips:[email-masked];transport=tcp' and
'sips:[email-masked];transport=sctp' are both valid. The proposal would
deprecate the use of ';transport=tls'.

There are of course multiple ways in which a client can attempt to forward a
request. Perhaps most commonly, a client deferences the Request-URI with a
DNS lookup, through the process described in draft-ietf-sip-srv-04. Provided
that we accept the SIPS URI proposal, the process described in sip-srv would
be updated to reflect the new URI scheme. We would probably create service
fields with distinct 'protocol' subfields. Today, in sip-srv-04, we use
SIP+D2T to indicate SIP over TCP, and SIP+D2S to indicate SIP over TLS in
the NAPTR records used to select a destination. Under this new model, we
would use SIPS+D2T to reflect SIP over TLS over TCP. The rules would be:

- When a SIP entity looks up the NAPTR resource record set corresponding to
the domain of a SIPS URI, it MUST discard all service fields that do not use
a SIPS 'protocol' subfield before selecting a resource - then, if no SIPS
service fields exist in the resource record set, the request MUST fail. If
the lookup is for a domain corresponding to a SIP URI, clients MUST follow
the standard NAPTR order and preference system for selecting a record. It is
RECOMMENDED that authors of NAPTR records make a SIPS record the most
preferred record. NAPTR records associated with proxy servers, redirect
servers and registrars MUST have a SIPS record.

The result will be that clients referencing SIPS URIs will not select
records that do not support SIPS. Note that s> ervers that would like to
refuse all requests that have not traveled over TLS can provision only SIPS
service fields in their NAPTR records. Also note that if a SIPS+D2T NAPTR
record results from a SIP URI lookup, then TLS will be guaranteed only for
the next hop (to the IP address/port/transport identified by the SIPS
record) - the Request-URI is not re-written after a DNS lookup, and SIPS
services > are NOT guaranteed for any subsequent hops in the signaling path.

If there are any Route headers associated with the request, clients defer
the derefencing of the Request-URI and obey the loose routing rules instead.
Since Route headers also contain URIs, these could use the SIPS scheme as
well. The use of SIPS in a Route header suggests that regardless of the
scheme of the Request-URI, the request should be sent over TLS to the entity
identified by the Route header's URI. However:

- A SIP entity MUST NOT send a request destined for a SIPS URI to any loose
routing entity designated by a SIP URI in a Route header. SIP entities
SHOULD support the conversion of SIP to SIPS URIs in Route headers to
support SIPS requests. Any loose routing entity that provides a SIP URI in a
Record-Route (or through any other means of populating Route headers in
clients) MUST be prepared to accept SIPS URIs, and the associated TLS
connections, in their stead.

Note that the process by which clients route requests to loose routing
entities may also involve the deferencing of the URIs in Route headers -
this process should follow the general rules for NAPTR record processing
given above.

Clearly, the operation of location services and registrars requires some
restrictions to ensure that this will work properly; if a SIP URI (for a
device without TLS support) could be registered under a SIPS
address-of-record, for example, that could guarantee that requests will fail
- but in that instance the user in question shouldn't be attempting to use a
SIPS AoR. The important rules are that:

- When a SIP entity registers contact addresses under a SIPS
address-of-record, these contact addresses MUST use the SIPS URI scheme. SIP
entities MAY register SIPS contact addresses under a SIP address-of-record
when appropriate.

Finally, there are a couple of limitations or restrictions we should be
mindful of:

- DNS lookups have a number of security problems that we will not be able to
fix here. Therefore, in the cases in which you dereference a URI by
resolving the domain with a NAPTR record, it is possible that an attacker
could tamper with NAPTR records in a way that degrades security (so they can
snoop on your signaling, maybe) or that just denies service. Fortunately,
SIPS in the Request-URI can at least make it explicit that a request should
fail if security is not available. Note that implementations could also keep
track of the security preferences of peers with whom they have longer-term
relationships - if a proxy that had a SIPS record yesterday doesn't have one
today, that could very well be a hint that something improper is afoot.

- Using TLS on every segment means that the terminating UAS will have to be
reachable over TLS. Today in the specification, UASs are not strongly
encouraged to accept incoming TLS connections, nor to have appropriate
certificates to assert their identity with TLS - this may be feasible for
some UASs (like PSTN gateways, which could use a site certificate), but not
for typical end-user phones. For that reason this mechanism most likely has
to rely on persistent TLS connections established upon registration that are
kept open indefinitely as a secure channel over which UASs can receive
requests. This UAS TLS architecture is already detailed in bis07; however,
it has some known scalability limitations.

- Pesky humans that use these protocols 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, on some devices they
could 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 could guess 'SIPS' would be valid
even when they are informed only of a SIP URI.

That sums up the major points about the proposal. Any comments?

Jon Peterson
NeuStar, Inc.

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Feb 2002 08:19:22 -0800 (PST)

> As something of a last-minute feature to supplement the SIP

   Is there no concept of feature freeze? The amount of
   things being added that have had next to no scrutiny
   is mind boggling. 

	   Mike

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 12 Feb 2002 11:51:06 -0500

Although at first glance the idea has merit, I'm inclined to agree with Mike
Thomas. If the intention is to include this proposal in the bis spec, it
should at the very least follow the process used for the loose routing
proposal with an I-D and a few weeks to review and comment before it gets
added to bis. That would require a delay of up to a month or more in our
current schedule. We are 6 days from concluding WG Last Call on bis, right?

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 12 Feb 2002 11:09:44 -0600

>    things being added that have had next to no scrutiny

Though it is an interesting proposition for some next phase. 
Let's focus and execute what we have now on the plate.

Thanks, Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Michael Thomas
> Sent: Tuesday, February 12, 2002 10:19 AM
> To: Peterson, Jon
> Cc: [email-masked]'
>  > As something of a last-minute feature to supplement the 
> SIP  > security story,
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>

---

From: Sean Olson <[email-masked]>
Date: Tue, 12 Feb 2002 09:07:31 -0800 (PST)

This is a very sudden change, but the sips:
scheme appears to have merit over a "transport=tls"
solution. I would prefer that the tls parameter at
least be deprecated in bis if the sips: scheme 
cannot be added. In any event, the sips: scheme
appears at first to provide a complete TLS solution
for SIP where the original transport parameter
did not.

/sean

--- Bob Penfield <[email-masked]> wrote:
> >  > As something of a last-minute feature to
> supplement the SIP
> >  > security story,
> >

=====
Sean Olson <[email-masked]>

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

---

From: Allison Mankin <[email-masked]>
Date: Tue, 12 Feb 2002 14:05:47 -0500

Jon, 

One thing that was lacking in your sips proposal was a
motivation that reflect the fact that security evaluation
(part of the ongoing AD review of bis) resulted in a push on
the editors for something like sips.  The reviews identified 
that enabling TLS through NAPTR and the SIP URI transport parameter
did not provide reference integrity for TLS use.  This led
to a request for development of additional mechanism.

The editors' process here is similar to responding to IETF Last 
Call, AD review, and IESG review comments, when these require 
changes, except that normally such changes are requested well after
IETF Last Call has concluded.  The Chairs and I are collaborating
to try to ensure that AD and IESG comments/issues are expressed
and handled earlier than normal, because of the 3GPP deadline.
(We also hope that the strong efforts by this WG to review
*everything* means that IETF Last Call has few or no surprises).

WG scrutiny is called for, but it should not surprise the
WG to see holes identified and proposals made for filling them,
even now.  Note that the process would be different if the
spec was going to Draft Standard at this time.

Allison Mankin
IESG Area Director for SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Feb 2002 01:24:58 -0500

I'll also add that the editors have been doing everything we can to get
these kinds of changes and feedback posted to the list ASAP for broader
comment. This item in particular came up only in the past few days, and
was brought to the list even before consensus amongst the editors was
reached, in order to get maximum air time with the group.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 12 Feb 2002 18:29:56 +0000

>Let's focus and execute what we have now on the plate.
Hi Folks,
    I understand the concerns/frustrations.
However, Sean suggests that initial work consists ONLY of deprecating
";transport=tls". AFAIK, that's all that needs to be done in the bis WGLC.
(this is not so much adding yet another thing as removing a carbuncle :).

The introduction of a new URL scheme looks good to me. I don't understand
why it's a "core" bis issue and could give people (more) ulcers - it's a new
scheme, not "sip:", so I would have thought that this is ideal for a further
draft, using bis as its reference. Hence I'm confused at the strong reaction.
Does even its own mother love ";transport=tls"?

If the proposal is to lose this, I'll second that as I've never liked the
overloading (and a future sips: doc appears to do all it could be expected
to achieve, and more).

best regards,
    Lawrence

-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Feb 2002 10:43:21 -0500

Lawrence Conroy wrote:

> Does even its own mother love ";transport=tls"?

It needs to be core, since the baseline sip security mechanism is not
viewed as sufficiently good without it. The same argument could have
been made for any of the security stuff, smime, for example. It was put
into bis for the same reason.

Thanks,
Jonathan R.

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 13 Feb 2002 18:09:13 +0200

> into bis for the same reason.

i have seen sip UAs that support basic authentication together with tls
and digest authentication without any transport layer security, but i
haven't heard of any that would do smime.

is there any?  if not, then does it make sense to have smimi in the bis.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 13 Feb 2002 14:27:15 -0600

> the transport parameters would pertain to the entire request path.

There are two "request forwarding modes" in SIP.

1) basic forwarding:  take in the request, look at the Route header, pop the
Route hedader, and send the request on towards the target given in the
request-URI.

2) Change the request-URI to indicate a different target. This could turn it
into a sip: URL, a tel: URL, or potentially something else.

The proposed sips behavior seems fine for type-1 forwarding. However, it
doesn't seem appropriate for the calling party to be able to dictate what
sort of retargeting can be dome in the type-2 scenario.

It also seems reasonable that  a proxy could retarget an incoming sip: or
tel: URL to a sips: URL. For example, consider my phone system. Incoming
phone calls tickle my gateway, which sends an appropriate INVTE to a sip:URL
of "sip:phone-number@defaultproxy." Let's say I have a sips contact
registered at defaultproxy. The proxy should be able to forward that INVITE
over TLS to the registered contact. This is a very reasonable application,
since my gateway and proxy are in a trusted private network, and my PC is
roaming on some public network.

So if this is reasonable, why isn't the inverse?

In the typical calling scenario, a proxy transforming a sips: URI into
another URI SHOULD prefer transforming into another sips: URI, but making
that a MUST is just completely bogus from an application capability point of
view.

So, I would propose that we need a clarification that allows application
level retargeting of a request initially sent with a sips: URI to a new
target which may or may not be a sips: uri, and distinguish this from the
basic proxy operation, which requires use of TLS for requests conating a
sips: URI.

--
Dean Willis

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Feb 2002 16:01:14 -0800 (PST)

> is there any?  if not, then does it make sense to have smimi in the bis.

   I don't think so. The addition of SMIME seems to
   be a solution in search of problem. Also: SMIME
   is a complete pig. I can't imagine any low end
   UA's implementing it. It certainly doesn't
   deserve "SHOULD" status.

		    Mike

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 15 Feb 2002 08:02:49 +0200

Michael Thomas writes:

 >    The addition of SMIME seems to

then lets get rid of it completely.  it makes no sense to have dead wood
in the bis.  if need arises, one can always write a separate i-d about
smime.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Feb 2002 01:12:54 -0500

> in the bis.  if need arises, one can always write a separate i-d about

It was added in to fill security holes that were deemed sufficiently
big, that sip could not pass without an answer for them. The nice thing
about it is that we didn't have to invent anything new to do it.
Perfect? no. Works everywhere? certainly not. Covers the holes and gives
us additional capabilities with low protocol engineering costs? YES.

-Jonathan R.

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 15 Feb 2002 08:25:41 +0200

Jonathan Rosenberg writes:

 > big, that sip could not pass without an answer for them.

it makes no sense to invent something just to make the i-d pass the
review.  what is included in the base sip spec, must have wide industry
support and real examples of working products.

-- juha

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 15 Feb 2002 10:28:24 +0200

>    UA's implementing it. It certainly doesn't

I kind of like the opportunistic SMIME scheme in Bis. However,
I do agree with you that it's not a low-end thing. My personal
recommendation would be either a MAY or a separate RFC.

Jari