Subject: RE: [Sip] A sips: trial balloon for you to shoot down

From: "Brian Rosen" <[email-masked]>
Date: Wed, 1 Nov 2006 09:54:54 -0500

While I have some reservations on allowing any mechanisms to substitute for
TLS, I too am happy with your proposal.

Brian

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2006 4:12 PM
> To: Dean Willis
> Cc: IETF SIP List
> Subject: RE: [Sip] A sips: trial balloon for you to shoot down
> 
> I'm happy with your proposal, as per your clarification.
> 
> I guess it would mean a new BCP document (plus some changes
> to my draft for some sips-related aspects).
> 
> 
> > -----Original Message-----
> > From: Dean Willis [mailto:[email-masked]]
> > Sent: Tuesday, October 31, 2006 12:40 PM
> > To: Audet, Francois (SC100:3055)
> > Cc: IETF SIP List
> > Subject: Re: [Sip] A sips: trial balloon for you to shoot down
> >
> >
> > On Oct 31, 2006, at 1:08 PM, Francois Audet wrote:
> >
> > >> -----Original Message-----
> > >> From: Dean Willis [mailto:[email-masked]]
> > >> Sent: Tuesday, October 31, 2006 10:21 AM
> > >> To: IETF SIP List
> > >> Subject: [Sip] A sips: trial balloon for you to shoot down
> > >>
> > >>
> > >> Ok, let me make a proposal, or perhaps remake one somebody
> > else has
> > >> made. I've lost track of who said what...
> > >>
> > >> I think we're now talking about a BCP for secure operations.
> > >>
> > >> 1) Implementations of SIP SHOULD use TLS as described in RFC
> > >> 3261 for all SIP traffic, including traffic using a sip:
> > URI scheme.
> > >> Failure to use TLS may result in disclosure of sensitive signaling
> > >> information to third parties. As a matter of local policy, some
> > >> deployments MAY use IPSEC or physically protected infrastructure
> > >> instead of TLS on specific links.
> > >> Examples where this might be appropriate include persistent IPSEC
> > >> relationships between proxies within an operational domain and
> > >> physically protected "private network" cables between a TLS
> > >> concentrator and the device it is fronting for.
> > >> Where TLS is not used, the implementor MUST exercise a
> > high level of
> > >> caution to provide adequate security and MUST preserve
> > operationally
> > >> equivalent protection of message integrity, privacy, and
> > participant
> > >> identity (authentication).
> > >
> > > That first recommendation seems to be completely independent from
> > > SIPS, right? Seems reasonable to me. That sounds like
> > BCP-material for
> > > sure. Something for a new document.
> > >
> > >> 2) When using the sips: URI scheme, implementations MUST
> > NOT exercise
> > >> the "last hop exception" for sips: processing described in
> > RFC 3261.
> > >> Most scenarios where this technique might have seemed
> > appropriate can
> > >> be better satisfied using a client-initiated TLS connection as
> > >> described in draft-ietf-sip-outbound. User agents that do not
> > >> implement both TLS and either terminate TLS connections or
> > exercise
> > >> draft-ietf-sip-outbound with a US-originated TOS connection to an
> > >> outbound will therefore not be able to exercise the sips:
> > URI scheme.
> > >> Failure to observe this requirement is likely to result in a
> > >> reduction of operational security below that expected from
> > the sips:
> > >> URI scheme.
> > >
> > > I like the idea of deprecating the last-hop exception. My makes the
> > > exact same case your are making here (but it falls short of
> > > deprecating the last-hop exception, because, the chair has
> > instructed
> > > me to not make normative changes). I'm assuming that making a
> > > normative change to RFC 3261 for this would require a new document.
> >
> > I'd argue that making a normative statement about how to best USE
> > 3261 is not the same as making a normative change to 3261.
> > Thus, this sort of behavioral requirement can be made in a
> > BCP, without it actually changing 3261 or being a
> > standards-track document.
> >
> > >
> > > What is not clear from this is if there are any
> > relationship with your
> > > proposal (1).  Specifically, I believe that most people
> > believe that
> > > sips does imply TLS (and does not allow for IPsec). Are you
> > proposing
> > > to change this so that (1) applies to sips as well?
> >
> > Nope. 1 is all about sip:. It is there to make sure that you
> > get the best possible security if you don't use sips:,
> > thereby allowing you to use sips: only when you want to make
> > the call to fail if TLS is not present on EVERY hop.
> > >
> > >> 3) Since some user-agents will not be able to exercise the sips:
> > >> scheme, implementations MUST anticipate the failure of sips:
> > >> requests and in general SHOULD use sips: only when it is
> > desired that
> > >> the request will not complete unless TLS will be used on each hop.
> > >> Since requests using the sip: URI scheme are (by
> > requirement 1 above)
> > >> expected to be as securely processed as the implementation
> > is able to
> > >> do, it is not suggested that one first try sips: and then
> > back off to
> > >> sip:.
> > >> In other words, if you're willing to settle for the best security
> > >> that can actually be provided, simply originate the request with a
> > >> sip: URI scheme.
> > >
> > > That is already covered in my draft (and in RFC 3261).
> > > No need to do anything else about it.
> > >
> >
> > No, this really say "Don't use sips: as your default
> > mechanism. Only use it when you REALLY REALLY want the call
> > to fail if EVERY link, including the last hop, is not TLS."
> > Again, it;s not a change the the specification of 3261 --
> > it's a guideline on how to best use it.
> > Behaviour needs reinforcing from time to time.
> >
> >
> > >> 4) User agent servers that terminate a request using the
> > >> sips: URI scheme MUST create any dependent requests using the
> > >> sips: URI scheme.
> > >> This preserves the commitments of the sips: scheme, and failure to
> > >> observe this constraint would give the appearance of sips:
> > security
> > >> where no such security exists. For example, this requirement means
> > >> that that back-to-back user agents bridging two sips: requests use
> > >> sips: on both sides. Furthermore, gateways to other protocols not
> > >> offering equally strong protections MUST NOT exercise the
> > >> sips: URI scheme. In particular, PSTN gateways MUST NOT use sips:,
> > >> since the PSTN itself does not offer equivalent
> > protections and there
> > >> is no ability to determine whether the PSTN segment might be
> > >> converted back to a sip: request somewhere downstream.
> > >
> > > I think this is likely to be somewhat controversial (the
> > pstn gateway
> > > limitation in particular).
> > >
> >
> > See discussion elsewhere -- without this requirement, sips:
> > is exactly the same wishful thinking that sip: is (ok, do
> > your best . . .) and might as well be deprecated.
> >
> > --
> > 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

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 01 Nov 2006 20:53:20 +0000

Samir,

When I submit confidential information to a web site over HTTPS I can check
the certificate and see that I am indeed sending information to MyBank.com
(of course, I have to trust MyBank.com to treat the information
appropriately once it gets there). Now if I want to do similar over a
SIP-initiated session, then likewise I want to see a caller/callee identity
signed by MyBank.com with media security bound to that identity in some way.
If instead I see a certificate for InterceptingServiceProvider.net, I will
be disinclined to submit confidential information and will find other ways
(e.g., HTTPS) to do the same thing. SIP becomes relegated to a PSTN
replacement or worse.

John 

> From: Samir Srivastava [mailto:[email-masked]] 
> Sent: 01 November 2006 20:28
> To: Paul Kyzivat
> Cc: IETF SIP List; Sanjay Sinha (sanjsinh); Dean Willis
> As far as I know, FCC will not let you deploy without CALEA 
> compliance.
> Am I out-of-date on this? 
> 
> IMHO, we will be having security with CALEA. This Security 
> notion is to
> avoid the Call Pattern tracking etc by attackers but the duly assigned
> authorities will be open to record the conversation.
> 
> My view is "Secure except subject to CALEA" .
> 
> Thx
> Samir
> 
> > From: Paul Kyzivat [mailto:[email-masked]]
> > Sent: Wednesday, November 01, 2006 12:22 PM
> > To: Srivastava, Samir (SC100:8826)
> > Cc: Brian Rosen; Hadriel Kaplan; Attila Sipos; Sanjay Sinha
> (sanjsinh);
> > Dean Willis; IETF SIP List
> > Is a call providing CALEA a secure call? Not in my book. Not if the
> only
> > two choices are "secure" and "insecure". If there are more than two
> > choices, then "secure except subject to CALEA" might be one of them.
> > 
> > 	Paul
> > 
> > Samir Srivastava wrote:
> > >
> > >> Samir Srivastava wrote:
> > >>> A thought to ponder
> > >>> When Calls on *IP only* are secured, how long PSTN / 
> MGW will last
> ?
> > >> To be cynical, if IP calls are really secured, then they will
> probably
> > >> be ruled illegal. Sellers of equipment and services will be
> forbidden
> > >> from offering this capability.
> > >>
> > >>
> > >
> > >   You need to have B2BUA in between providing CALEA. We need to
> specify
> > > B2BUA behavior.
> > >
> > > Thx
> > > Samir
> > >
> > >
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 01 Nov 2006 20:53:37 +0000

Francois,

The point about PSTN is that although it might be considered secure by some
people (although I have seen statements to the contrary), there is no way of
knowing what happens beyond the PSTN. There could be some other IP network
that does not apply security. Therefore there is always an element of doubt
over PSTN. However, if we retain SIPS (the need for which I am not yet
convinced of) then I think it is equally valid as far as the gateway, and
the job of indicating that there is some question mark over security beyond
the gateway should be addressed by some other means. As Paul says, an
identity such as sips:[email-masked] would tell you that you have
a secure connection to provider.com, and says nothing about what happens
beyond that.

John

> Sent: 01 November 2006 17:23
> To: Paul Kyzivat
> Cc: Sanjay Sinha ((sanjsinh)); IETF SIP List; Dean Willis
> > Sent: Wednesday, November 01, 2006 9:05 AM
> > Cc: Dean Willis; Sanjay Sinha ((sanjsinh)); IETF SIP List
> > Francois Audet wrote:
> > > There is a difference however between and SBC and PSTN 
> Gateway, in 
> > > that their security model are quite different.
> > 
> > I don't see the difference.
> > 
> > In either case, the call has reached a UA. From that point on 
> > you are trusting that the UA will do the right thing. The 
> > best you can do is determine the identity of that UA and 
> > decide if it is one you wish to trust.
> 
> The difference is that there is a level of "security" on 
> PSTN. You can't
> do IP address spoofing for example. You can't tap into a hub. 
> 
> (Yes, I know: there are ways to tap into analog lines too).
> 
> The point is that for many people, they are happy with the security
> level provided by the PSTN, but not with the one provided by IP
> telephony
> or SIP when there is no TLS/SRTP/whatever.
> 
> That's my point.
> 
> So, I can see that, as Michael Thomas said, putting all the 
> "attributes
> of security" into the letter "s" is not terribly useful.
> 
> On the specific issue of "is sips allowed" when you leave the 
> "network",
> I am a bit
> ambivalent.
> 
> I think if you are Leaving SIP and going to another IP protocol (say
> H.323) then we
> shouldn't allow SIPs.
> 
> However, for the PSTN case, I'm not sure. I think I'm ok either way. I
> think arguments
> on both sides are valid.
> 
>  
> 
> > If you have phone service from a provider that uses SBCs at 
> > its connection to the internet, when I call "you" I am really 
> > calling that SBC. All security and authentication properties 
> > are with it, not you or your devices. I must trust it. The 
> > same is true if I call a gateway.
> > 
> > 	Paul
> > 
> > >> Sent: Tuesday, October 31, 2006 9:23 PM
> > >> To: Sanjay Sinha ((sanjsinh))
> > >> Cc: IETF SIP List
> > >> On Oct 31, 2006, at 3:12 PM, Sanjay Sinha ((sanjsinh)) wrote:
> > >>
> > >>> It is my understanding is that SBC is esentially a B2BUA or
> > >> an IP-IP
> > >>> gateway, if one leg is SIP and another one is say,
> > >> H323/MGCP. A pstn
> > >>> gateway is termination point of IP leg signaling. It will 
> > have fxs/ 
> > >>> pots or a PBX interface on the other leg. So I can have 
> > an IAD with 
> > >>> pots phones hanging off of fxs port in a small branch
> > >> office and know
> > >>> that interface is secure/trusted.
> > >>>
> > >> Ok, that's fair. I wouldn't describe that as a PSTN 
> > Gateway so much 
> > >> as I would describe it as a multi-user UA that uses telephone 
> > >> handsets to implement its user interface devices.
> > >> By the same token, it would be OK to run sips: to a Mac 
> > that uses a 
> > >> Bluetooth headset, even though Bluetooth isn't TLS.
> > >>
> > >> By PSTN gateway, I mean a box that converts the SIP call into a 
> > >> signaled call on a PSTN line (especially a "trunk" line).
> > >>
> > >> Of course, once you stick an fxo line on that 
> multiuser-UA box and 
> > >> start pumping calls back into the P (that's Public) STN, 
> > you have a 
> > >> security problem again. This could easily happen with a 
> > PBX, so that 
> > >> could be a problem. It might be legit to say that a PBX 
> > simply can't 
> > >> do sips:, because it can't meet the security assurances of sips:.
> > >>
> > >> --
> > >> Dean
> > >>
> > >>
> > >>
> > >>
> > >> 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
> > >>
> > > 
> > > 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: "Attila Sipos" <[email-masked]>
Date: Wed, 1 Nov 2006 20:59:24 -0000

>> Internet with zero security to another domain, with another 
>> SBC and TLS from
>> that to the UAS.  Does that meet anyone's needs?  Does it 
>> have anything to
>> do with any sense of secure?

The scenario described could not be secure, of course not.
And no-one would argue with that.

However that is not the same as saying that SIPS can't be
considered "secure enough" for it's purpose.  There are
various levels of security but it all about what people
would consider acceptable.  I think a call going to a
SIPS/PBX gateway to a physically secure PBX to a phone
would be considered secure enough by most people.
An organization would probably consider their PBX to be secure
but would also like some security for SIP calls too.
SIPS should be able to provide this.

There are so many scenarios where SIPS would be useful
for a PBX gateway and even for a PSTN gateway.  It is
not about absolute security but about what is deemed
acceptable.

This issue is also about trust.  We have to trust
the things we're calling.  We have to trust the
people we're calling.  We make a secure call to them
and we trust that they're not going to broadcast 
what you're saying on their speakerphone.  We trust
that they don't mike up your call and put it out
on the PA.

It could also be a political thing.  People might consider
PSTN to be quite safe but might consider computer networks to
be unsafe.  So the solution is to use SIPS for the computer
network part of the call to give people some sense of security.

SIPS to PSTN/PBX/ISDN gateway calls have to considered
in the context of their environment.
1. what is the required level of security?
2. is there trust?
3. is there a benefit?

The second one is more important than anything.
What good is a company which offers a super secure solution
if no-one trusts them?

	Attila

>> From: Brian Rosen [mailto:[email-masked]]
>> Sent: 01 November 2006 18:50
>> To: 'Hadriel Kaplan'; Attila Sipos; 'Sanjay Sinha (sanjsinh)'; 'Dean
>> Willis'; 'IETF SIP List'
>> I think Dean's formulation is a sensible set of rules.  It's 
>> not airtight,
>> nor could it be.  It can be misinterpreted, accidentally or 
>> deliberately.  I
>> think the intent is clear, and I think the "Best Current 
>> Practice" language
>> is clear enough.  
>> 
>> I don't think that security across one set of UAC to UAS in 
>> the presence of
>> B2BUAs and gateways is useful to anyone.  I keep imagining 
>> TLS protection
>> from UAC to the edge of his own domain, through an SBC 
>> across the open
>> Internet with zero security to another domain, with another 
>> SBC and TLS from
>> that to the UAS.  Does that meet anyone's needs?  Does it 
>> have anything to
>> do with any sense of secure?  I think not.
>> 
>> Brian 
>> 
>> > From: Hadriel Kaplan [mailto:[email-masked]]
>> > Sent: Wednesday, November 01, 2006 11:57 AM
>> > To: 'Brian Rosen'; 'Attila Sipos'; 'Sanjay Sinha (sanjsinh)'; 'Dean
>> > Willis'; 'IETF SIP List'
>> > > From: Brian Rosen [mailto:[email-masked]]
>> > > Sent: Wednesday, November 01, 2006 11:14 AM
>> > >
>> > > Clearly, we don't agree.
>> > >
>> > > I would say that the PBX can't provide security to any 
>> other call, how
>> > > could
>> > > it possibly provide security to a sips call?  One end is 
>> insecure.
>> > 
>> > It did provide security for a sips session.  That session 
>> is between the
>> > UAC
>> > and the sips UAS.  The UAS is the end, as far as sip/sips 
>> is concerned.
>> > Are
>> > you suggesting sips is more than a specific uri scheme for SIP, and
>> > somehow
>> > a cross-protocol, universal fiat, based on an ambiguous 
>> definition of
>> > "secure"?  :)
>> > 
>> > Will the BCP start listing all device types and roles, and 
>> whether they
>> > are
>> > allowed to accept a sips request or not?  A Bluetooth 
>> handset is allowed
>> > to,
>> > a home cablemodem (IAD) with an FXO interface is allowed 
>> to, but if that
>> > IAD
>> > is classified as a PBX then not.  Unless that "PBX" is an 
>> open-source app
>> > in
>> > my house PC.  But if my PC gets moved, then it needs to 
>> stop accepting
>> > sips.
>> > 
>> > 
>> > This would be like classifying pornography.  "I know it 
>> when I see it."
>> > 
>> > -hadriel
>> 
>>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 02 Nov 2006 08:36:58 +0000

Dean,

Thanks. During all this long thread, this is the first time that anyone has
been able to articulate a convincing use case. Messages with content, as
opposed to situations where content is sent as media, do require different
considerations. So when sending an INVITE request for an audio call, I might
be content with best effort security because I can moderate what I say if
security isn't available. But when sending a MESSAGE request I need to know
in advance that it will be sent securely or not at all.

Therefore I think I will stop trying to shoot down your trial balloon, apart
from the point about PSTN, where I believe sips stops at the UAS, whatever
that UAS is (a view that seems to be shared by a number of others). Dealing
with whatever is beyond the UAS should be outside the scope of this BCP for
sips.

I do think we need to start considering where we go beyond this, including
reporting on the security state to both UAs.

John

> Sent: 01 November 2006 21:23
> To: Elwell, John
> Cc: IETF SIP List
> On Nov 1, 2006, at 3:03 PM, Elwell, John wrote:
> 
> > Dean,
> >
> > Not quite. See below.
> >
> > ...
> 
> > [JRE] If we have a sips scheme that mandates TLS on all hops  
> > (whatever TLS
> > might mean) and fails if it can't achieve it, I think there is an  
> > equal
> > argument for a mechanism that requests TLS on all hops but still  
> > succeeds
> > and tells me if any hop does not meet this requirement. So if we  
> > recommend
> > the sip scheme for achieving best effort, it still doesn't tell me  
> > if it
> > succeeded. Yes, what I want would be a new mechanism, but it would  
> > not be
> > substantially more difficult to define than the SIPS mechanism. I  
> > am having
> > a hard time rationalising why we should specify an all-or-nothing  
> > mechanism
> > (sips) but not a best effort mechanism. In other words I am having  
> > a hard
> > time understanding the use cases for sips. Maybe the lack of  
> > plausible use
> > cases is part of the reason it hasn't been deployed much.
> >
> 
> So sip: gives us a best effort connection without a reporting  
> mechanism. You want a best-effort connection with a new reporting  
> mechanism. I think that's useful. I also didn't say it was a 
> hard new  
> mechanism to define, just that it's beyond the scope of a BCP to  
> describe.
> 
> The use case for sips: hasn't changed (except a recommendation for  
> outbound-with-TLS instead of last-hop-excepting ) , and its obvious.  
> One uses sips: only when one is absolutely insistent that each SIP  
> hop be protected by TLS. This is very useful for MESSAGE requests,  
> registrations, presence publications, subscriptions, notifications,  
> and other usages where the SIP payload is the actual communication  
> being protected. It enables key-exchange within SIP for resulting  
> media sessions (although DH is still a better approach). And 
> it helps  
> to obscure the media descriptions, which doesn't protect the media  
> channel directly but does complicate the task of an eavesdropper.
> 
> There's clearly enough "use case" here for people to be deploying  
> sips: today. Just not enough specification for making those  
> deployments as meaningful as they could be.
> 
> --
> dean
>

---

From: "Attila Sipos" <[email-masked]>
Date: Thu, 2 Nov 2006 20:57:44 -0000

>> > Furthermore, I think this is a bad idea to be honest. I'd rather
>> > have the suggestion that someone made that requests with SIPoverTLS
>> > be forwarded to SIPoverTLS by proxies.

Is that the Proxy-Requires extension idea that you're
talking about?  I could live with that I guess.

But you'd want to make sure that if SIPS couldn't work
then SIP over TLS would be tried next then non-secure SIP.
Well, I don't know the details but I think we need a way for
PSTN to SIP users to get the best security possible.

Cheers,
Attila

>> Sent: 02 November 2006 19:19
>> To: Dean Willis; Attila Sipos
>> Cc: IETF SIP List
>> > Sent: Thursday, November 02, 2006 9:44 AM
>> > To: Attila Sipos
>> > Cc: IETF SIP List
>> > Attila aksed:
>> > > So, what you're saying that PSTN gateways should use a
>> > > sip: URI with transport=tls?
>> > >
>> > 
>> > I think so.
>> 
>> That would require a normative change to RFC 3261 which has 
>> deprecated transport=tls.
>> 
>> Furthermore, I think this is a bad idea to be honest. I'd rather
>> have the suggestion that someone made that requests with SIPoverTLS
>> be forwarded to SIPoverTLS by proxies.
>> 
>> I think we have 4 choices for PSTN Gateways:
>> 
>> 1 - SIPS is only valid if all hops are withing a SIP network. PSTN
>>     gateways would therefore not use SIPS. Gateways to H.323 wouldn't
>>     either, even if H.323 is secured (same thing for other 
>> protocols).
>> 
>> 2 - SIPS is valid withing an IP network. H.323 gateways could 
>>     use SIPS, provided they are using an equivalent security level on
>>     the H.323 side. PSTN gateways gateways would therefore 
>> not use SIPS.
>> 
>> 3 - SIPS is significant only withing a SIP network, and 
>> hop-off to PSTN
>>     or other networks such as H.323 ARE allowed (in the case 
>> of H.323,
>> it would
>>     require security). 
>> 
>> 4 - SIPS is significant only withing a SIP network, and 
>> hop-off to PSTN
>>     or other networks such as H.323 ARE allowed and in both 
>> cases, you
>>     would require the gateway network to use security. 
>> 
>> I think Brian Rosen favored 4. Personally, I prefer either 1 or 2.
>> 
>> There are quite different however. 
>> 
>> 1 is my farorite choice if we think that sips has a limitted 
>> life-span
>> and
>> will have limited deployment, and will eventually be replaced by
>> something better.
>> 
>> 2 is my favorite if we believe sips has a more long-term future.
>> 
>> > > Can we, possibly with Requires, enforce that all hops 
>> use the TLS?
>> > 
>> > We possibly could, but that would be a new SIP extension, not 
>> > part of the current sips: specification, and outside of the 
>> > scope of what could be done with an informational or BCP document.
>> 
>> Right.
>>

---

From: "Sanjay Sinha \(sanjsinh\)" <[email-masked]>
Date: Thu, 2 Nov 2006 17:07:16 -0500

3 & 4 look similar to me.

One clarification. When you say pstn gateways should not use sips, what
does it mean? Does it mean that for a PSTN-SIP call, it should not use
sips even if all hops in sip network are secure? Or does it mean that it
acting as a UAS should reject a sips request?
If it is later, I agree with what John Elwell said.

Sanjay

>Sent: Thursday, November 02, 2006 2:19 PM
>Furthermore, I think this is a bad idea to be honest. I'd 
>rather have the suggestion that someone made that requests 
>with SIPoverTLS be forwarded to SIPoverTLS by proxies.
>
>    either, even if H.323 is secured (same thing for other protocols).
>
>    the H.323 side. PSTN gateways gateways would therefore not 
>use SIPS.
>
>3 - SIPS is significant only withing a SIP network, and hop-off to PSTN
>of H.323, it would
>4 - SIPS is significant only withing a SIP network, and hop-off to PSTN
>    or other networks such as H.323 ARE allowed and in both cases, you
>life-span and will have limited deployment, and will 
>eventually be replaced by something better.
>
>> > Can we, possibly with Requires, enforce that all hops use the TLS?
>> 
>> We possibly could, but that would be a new SIP extension, 
>not part of 
>> the current sips: specification, and outside of the scope of what 
>> could be done with an informational or BCP document.
>
>Right.
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 03 Nov 2006 07:11:22 +0000

Brian, 

> Can you give me a use case where sips does something useful 
> when one end is
> on the PSTN?

You could use SIPS to transfer something securely, in the SIP request, as
far as the UAS, for example SDescriptions.

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 03 Nov 2006 07:19:36 +0000

Hadriel,

Yes, and furthermore this ties in nicely with the concepts in
draft-rosenberg-rai-phones-numbers-00, which draws a big distinction between
a tel URI and sip/sips URI. A sip/sips URI in a Request-URI addresses the
SIP resource to which you want your request to be routed, so addressing to
sips:[email-masked];user=phone is effectively addressing a gateway
in example.com if +123456789 cannot be reached in the SIP network.

John

> Sent: 03 November 2006 04:18
> To: 'Brian Rosen'
> Cc: 'IETF SIP List'
> So far the explanation/argument of sips has been that sips is 
> not a synonym
> for human-to-human security.  It does not provide a lock icon.  It is
> nothing more than a mandate that each sip hop use TLS.  It is 
> just a uri
> scheme, which behaves like a require/proxy-require for 
> transport=tls.  It is
> nothing more than that.
> 
> Your proposal is that it become more than a uri scheme for 
> sip; that it
> become a human-level request for TLS or TLS-level of "secure" 
> (whatever that
> is defined as), regardless of the protocol.  That it reaches 
> something past
> the UAS, in some higher plane.  Almost like a require that the message
> headers (and really the body) not leave a cpu.  Or maybe a 
> new scheme called
> tls. :)
> 
> Don't get me wrong - I understand what you mean and why, but 
> SIPS isn't it.
> It would be a significant divergence from 3261 to define a 
> sips uri scheme
> as having such a property, to reach beyond the SIPS UAS, IMO. 
>  The uri in
> the sips request is not even the identifier of the SMS 
> receiver.  It is the
> identifier of the gateway.  If you reached that gateway using 
> TLS, then you
> succeeded.  
> 
> Does any URI or scheme mean more?  Http, https, email, ftp, etc. all
> identify the server/end of the protocol, not something beyond. (an
> interesting one would be tel - if there was a tels, that is) 
> 
> I think what you're really looking for is a new thing.
> 
> -hadriel
> 
> 
> > Sent: Thursday, November 02, 2006 5:39 PM
> > To: 'Paul Kyzivat'; 'Elwell, John'
> > Cc: 'IETF SIP List'; 'Francois Audet'; 'Dean Willis'
> > I guess the problem here is whether you consider the PSTN 
> to be secure, in
> > the sense of TLS, expressed in Dean's proposed wording.  If 
> you do, then
> > what you propose is consistent.
> > 
> when one end
> > is
> > I don't think anyone believes the PSTN is secure in 
> anything close to TLS
> > level security.  I sort of understand the issue of the IETF can only
> > control
> > the sip path, and what happens beyond is not in its 
> purview.  Using that
> > to
> > create meaningless mechanisms isn't helpful IMO.
> > 
> > Let's use the example cited a little while ago: a MESSAGE.  
> You clearly
> > could, at a gateway, convert that to SMS.  Does it make ANY 
> sense to call
> > that secure if it was TLS from UAC to a gateway, and then over a GSM
> > network
> > to a handset?  Isn't there a substantive difference between 
> that and TLS
> > protected MESSAGE all the way to the handset?  What earthly 
> good does it
> > do
> > to get sips to succeed if the last hop is not secure?  I 
> think if the
> > gateway knows its not the end of the signaling, then it has 
> to fail sips
> > if
> > it can't maintain TLS.
> > 
> > Brian
> 
>