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

From: William Marshall <[email-masked]>
Date: Tue, 12 Feb 2002 09:45:00 -0500 (EST)

I've always believed (maybe incorrectly) that one reason for
https was to prevent proxies from doing anything with the request,
thereby forcing it to be a pure client-server transaction.
Doesn't an http proxy merely tunnel a https: request, without
even seeing the Request-URI?  Wouldn't sips: be expected
to mean the same?  That seems a lot different from requesting
tls on every link.

Bill Marshall
[email-masked]

-----original message-----
From: "Peterson, Jon" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Tue, 12 Feb 2002 05:21:01 -0600
Subject: [Sip] 'sips' URI scheme (comments on proposal?)

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: "Peterson, Jon" <[email-masked]>
Date: Wed, 13 Feb 2002 20:04:41 -0600

Comments below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Wednesday, February 13, 2002 12:27 PM
> To: Peterson, Jon; [email-masked]
> Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?)
> 
[snip]
> 
> There are two "request forwarding modes" in SIP.
> 
> 1) basic forwarding:  take in the request, look at the Route header, pop
the
> Route header, 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.

Well, I disagree - I believe it is appropriate for type-2, we'd just need a
rule for it (something that was missing from my proposal). I think it is
perfectly reasonable to say something along the lines of:

- An entity that is performing 'retargeting' (on the basis of a 302 it has
received, or an internal location service) MUST NOT retarget the request to
a non-SIPS URI. So, if three Contact header fields are available in a 302,
all non-SIPS URIs should be discarded regardless of qvalue if the initial
request is for SIPS; if no SIPS URIs are available, the request fails. 

So I don't see how SIPS is incompatible with option 2 - we can define rules
for it. The question is whether or not this actually prevents intermediaries
from doing their jobs, or reduces the functionality of SIP.

The important thing here is that any entity that performs 'retargeting' does
so because it has some knowledge about how best to reach the resource
identified by the Request-URI - knowledge gleaned from their own location
service, maybe, or from a 302. While it might seem weird for the calling
party to dictate the sort of retargeting done in type-2 case (although I
don't think it's reasonable for me to want to be assured of the security of
my calls), surely it is appropriate for the -called- party to dictate that
sort of retargeting? If not, this begs a lot of questions about why the
retargeting is performed; is this retargeting occuring with the knowledge
and consent of the called party? SIPS as an AoR is distributed by parties
who want people to reach them over TLS - this entails a certain amount of
support and compliance. You won't tell people to try to reach you with a
SIPS AoR unless you will be registering SIPS contact addresses under that
AoR. And these registrations, I think, should be primary cause for
'retargeting'.

I don't think we want to champion a view of SIP in which intermediaries that
are not associated with either the calling or called party are 'retargeting'
requests arbitrarily. Ideally, 'retargeting' is the transformation of an
address of record to a contact address (which may in turn be an address of
record for another domain), and this should be driven by the registration
process - although there are also a limited set of caller-related
transformations that could take place at the caller's proxy, like expansion
of a speed-dial address. 'Retargeting' by unrelated intermediaries could
lead to surprising, undesirable, and insecure consequences, especially in so
far as the originator may never know the new form of the Request-URI (unless
intermediaries propagate the retargeting as a redirection all the way back
to the originator). I fear that this is a general SIP problem that is
certainly independent of the SIPS proposal; solving these concerns about
retargeting would, however, obviously be beneficial to SIPS.

> 
> 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?

I agree the first case is reasonable. The use of SIPS as a contact address
leads to the securing of individual hops rather than the entire signaling
path - we detailed exactly this in the proposal. You can register a SIPS
contact address under a SIP AoR.

It's unreasonable in the reverse instance because there is a difference
between an AoR and a contact address - AoRs can travel end-to-end in headers
like the To field that cannot be transformed by intermediaries - but
moreover, because we're defining that it should be different because we like
the property of requesting security for the entire signaling path. Hence the
rules we have suggested for the handling of SIPS.

> 
> 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 conacting a
> sips: URI.
> 
> --
> Dean Willis
> 
>

---

From: Phil Reynolds <[email-masked]>
Date: Fri, 15 Feb 2002 10:47:49 -0000

> I believe there are reasonable threats against SIP (at 
> least one of which is
> described in bis) that justify end-to-end confidentiality 
> of bodies. I'm not
> sure that I want intermediaries to be able to inspect or 
> potentially modify
> SIP bodies, especially SDP, for a number of reasons. I 
> think we need a base
> SIP mechanism to address this concern.

If you want your protocol to be capable of traversing multiple heterogeneous
networks then you must pass the network control information in such a way
that the routing devices can modify it as necessary. If you don't like this
then you are stuck with the naive world of single uniform address spaces
throughout the world or protocols that require all connections from the
client to the server, and not from server to client, and no connectionless
protocols.

Whilst I agree that authenticating the "user identity" of the other end of
the call is important, I don't care which actual address the call actually
came from (anyway the user want's to hide this anyway -- hence the
proliferation of NAT firewalls), or how it got routed to me -- just that it
did. 
I would prefer that you added an extra body to the message that has the
user's certificate or whatever, to prove user identity, and leave the
routing information in-the-clear so the routers can do their stuff.

It is a serious oversight in SIP that the control, identity and content of
the message are intermingled in such a haphazard way.

---------------------------------------------------------
Phil Reynolds
Ridgeway Systems and Software
Tel: +44 118 938 1211
Fax: +44 118 935 4444
mailto:[email-masked]
http://www.ridgewaysystems.com

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 15 Feb 2002 14:10:11 -0600

A brief note below, a bit on the need for S/MIME.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Phil Reynolds [mailto:[email-masked]]
Sent: Friday, February 15, 2002 2:48 AM
To: [email-masked]'
Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?)

> I believe there are reasonable threats against SIP (at  least one of which
is 
> described in bis) that justify end-to-end confidentiality f bodies. I'm
not 
> sure that I want intermediaries to be able to inspect or potentially
modify 
> SIP bodies, especially SDP, for a number of reasons. I think we need a
base 

[Peterson, Jon] 

Everyone who wants to understand the motivation for S/MIME should be reading
the MIDCOM charter. I disagree that we're approaching this from a 'naive'
perspective - it is partially because we are mindful of transparent
intermediaries which alter SIP bodies that we think S/MIME is necessary.

Now, this isn't to say that the vendors who build these boxes or the
carriers who deploy them are misguided - making address spaces commensurate,
etc., is a laudable goal. But just as carriers have a prerogative to insert
these devices, I believe users should be able to controlwhether or not
intermediaries can alter the bodies of their requests. There are cases where
I would like to see a request fail because a middlebox is unable to modify
it - that way I'll at least know that it's there. Middleboxes make the same
changes in signaling whether they're helping you through a NAT or
simulcasting your call over satellite radio.

The important thing is that this is not an abstract concern - there are
boxes out there today that can and will modify SIP message bodies without
the knowledge of either of the endpoints in a call.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 15 Feb 2002 14:36:50 -0600

Some of the things that we can carry in SIP as MIME types that require
confidentiality are:

- Telephony signals (RFC 3204)

- Instant Messages (in MESSAGE)

- Whatever you place within INFO messages - DTMF, etc

I don't believe that any of the current proposals for Digest include
confidentiality. 

But leaving aside confidentiality for a moment, I want to be clear that the
current state of Digest enhancements, like S/MIME, is also one in which
there are uncertainties. Mutual authentication has some known challenges
(especially in the backwards e2m cases). Some of the header integrity
thinking (hBh vs e2e) has issues. How to handle keying is still up in the
area - several alternatives to the shared-secret approach have been
suggested, including extensible mechanisms. Some readers of bis have
suggested that we abandon Digest in HTTP Auth altogether for Digest in SASL
(opening the door to general SASL support in SIP).

Whatever else you might say about S/MIME, we have suggested a mechanism for
its usage, and no serious arguments have been raised along the lines of "if
you're going to do S/MIME, you should do it this way instead". The authors
would appreciate comments along those lines.

Jon Peterson
NeuStar, Inc.

---

From: [email-masked]
Date: Fri, 15 Feb 2002 15:19:17 -0500

From:  Tom Gray@MITEL on 02/15/2002 03:19 PM

The PSTN did indeed take the problem of signalling fraud very seriously and
aimed very high to correct it. The PSTN was extremely vulnerable to fraud when
it used in-band signalling in which customer and network signalling were
intermingled. The PSTN rectified this by going to an out-of-band signalling
structure with SS6 and SS7. One of the Internet's greatest assets is that it
allows in-band signalling which allows end users to create their own
applications This opens it to the type of fraud that were perpetrated on the
PSTN before the deployment of out-of-band signalling systems.  The classic blue
box fraud was an example of a customer sending the equivalent of an false BYE
message.

Michael Thomas <[email-masked]> on 02/15/2002 03:00:41 PM

To:   Jonathan Rosenberg <[email-masked]>
cc:   [email-masked] (bcc: Tom Gray/Kan/Mitel)

Jonathan Rosenberg writes:
 > > From: Michael Thomas [mailto:[email-masked]]
 > > Sent: Friday, February 15, 2002 11:48 AM
 > > To: EKR
 > > Cc: Michael Thomas; Peterson, Jon; 'Jari Arkko'; Juha Heinanen; Jonathan
 > > Rosenberg; Lawrence Conroy; Henry Sinnreich; [email-masked]
 > > Eric Rescorla writes:
 > >  > Michael Thomas <[email-masked]> writes:
 > >  > > You seem into falling into a false dichotomy that
 > >  > > if SMIME doesn't go into bis, we are now and
 > >  > > forever resigned to inadequate security for
 > >  > > SIP.
 > >  > I don't think it's a false dichotomy. Rather, it's a pretty
 > >  > accurate statement of the common pattern. To whit: WG produces
 > >  > a document with horrible security problems. Says, "we'll fix
 > >  > security later". Document passes. WG doesn't fix security.
 > >
 > > Are you actually claiming that SIP without SMIME
 > > would be "a document with horrible security
 > > problems"? I sure hope not, because if you are I
 > > think you need to get a grip; the current PSTN
 > > does exactly this today, and the world has not
 > > come to an end.
 >
 > The Internet is not the PSTN, of course.

   Yes, the Internet has conspicuously less
   security than the PSTN and yet it too still
   seems to function without news at 11:00. One
   thing we've learned, however, is that a sure
   way to keep the appalling status quo is to
   aim too high. Given where SIP is likely to
   be deployed, this is not only high, but
   aimed perpendicular to the earth's surface.

 > My perspective is that S/MIME provides one really, really
 > important security function. We have a monster hole right now,

   "Monster" is in the eye of the beholder.

 > IMHO, in that an eavesdropper can listen in on an INVITE,
 > and send fake BYE/re-INVITE or whatever to launch all kinds
 > of attacks.

   Still exists with SMIME.

 > An e2e TLS/IPSec solution is not sufficient, since
 > it is too fragile - there will always be hops without security.

   Fragile?

 > True e2e authentication is unachievable without PKI.

   False, false, false. First of all, e2e
   authentication in the small/medium/large is clearly
   achievable without PKI. Authentication in the
   large for complex cross domain relationships is
   now and remains a fantasy. It is pure
   speculation whether PKI's will deliver. Indeed,
   the mobile IP working group has been
   floundering for well over a year precisely
   because they improperly started from the false
   premise of global PKI's and the previous
   solution needed to be scraped once that was
   pointed out as a bogus premise.

   And *please* don't trot out the terrible web
   example again. You're talking about large PKI's
   in *clients*.

 > The solution
 > is a self-signed cert approach, where effectively only the user
 > that send the initial INVITE can ever send subsequent signaling.
 > I think that this is terribly important, and without a sensible
 > solution for it, the SIP security story for bis is not good
 > enough.

   PKI != self-signed certs. If you want a leap
   of faith solution, SMIME is an impediment, not
   a help.

 > Sure, we could have invented our own thing instead of S/MIME to
 > do this, but we would have gotten it wrong, it wouldn't be useful
 > for other things, as S/MIME is, and so on. S/MIME therefore seems
 > a good engineering choice to solve an important  problem.

   I happen to think that scalable/flexible proxy
   authentication is a lot more pressing problem.
   I don't think I'm alone. I've yet to hear
   anybody who is clamoring for the e2e problem.
   Yet, we get e2e SMIME with no list discussion
   either about the prioritization, or the
   solution. What gives?

 > Lastly, Mike, I hope you seriously do not believe that the editors
 > are acting inappropriately in our efforts to move forward with the
 > spec. We are doing everything we can do move with speed and within the
 > confines of the process. Getting consensus in this group is not trivial.

   I think that this got put in at the last minute
   without any working group involvement,
   especially by the people who have expressed
   interest in the problem. I've seen no
   inclination to address any of the concerns
   brought up, or consider alternatives. Why
   exactly am I supposed to not feel like this
   isn't being rammed down our throats?

            Mike

---

From: "James Undery" <[email-masked]>
Date: Sat, 16 Feb 2002 20:09:21 -0000

> > We have a MUST for Digest; I'm not sure what exactly 'enhanced Digest'
here
> > means. There have been a number of proposals for Digest enhancement, as
well
> > as a number for Digest replacement (I would group EAP and Digest-as-SASL
in
> > this category). Is there a particular draft that is the winner? Given
that
> > this matter seems somewhat contentious, I'm not sure this is necessarily
a
> > more expedient route than developing the mechanisms currently in the
> > specification.
>
> I believe most of the folks who have proposed digest enhancements have
> gotten together and joined efforts and there either is a draft in the
> directories
> or it will appear soon. James are you listening, maybe you can post a
link...

The first cut of draft is now at
http://www.ietf.org/internet-drafts/draft-undery-sip-auth-00.txt . It covers
mutual authentication between UAC-UAS, UAC-Proxy and UAS-Proxy; it has bid
down protection, various levels of integrity protection and can be used by
schemes other than digest (the bid-down protection needs nonces though
:-( ).

> Not that digest or its enhanced version are perfect either, but
nevertheless
> good candidates for a mandatory mechanism. And as you point out Jon,
> digest already is a MUST. That's good.

I'd like to echo that with Digest isn't perfect EAP strikes me as a far
better mechanism, hence the flexibility we tried to introduce to the draft.

James