Subject: [Stox] SIPS URIs and SIP/XMPP gateways - WAS: review: stox-core-04

From: <[email-masked]>
Date: Fri, 27 Sep 2013 11:43:14 +0000

Hi,

There was many years ago a lot confusion and discussion about the semantics of the SIPS URIs.

Robert, Cullen: I recall you were there :-) Would you have guidance to the STOX WG how SIPS URIs should be dealt with when SIP/XMPP gateways are involved. Please check Peter's exact question from below.

Regards,
	Markus

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Peter Saint-Andre
> Sent: 24 September, 2013 02:55
> To: Salvatore Loreto
> Cc: [email-masked]
> Subject: Re: [Stox] review: stox-core-04
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 9/20/13 3:39 AM, Salvatore Loreto wrote:
> > I have reviewed the core-04 draft, and I think that is almost ready
> > for the WGLC
> >
> > I have one general comment (btw I apologize in advance if this has
> > already been discussed and I have overlooked or forgot it) and it is
> > about the fact that draft does not talk at all about the inter working
> > when secure URIs are involved. I think that at least we should say
> > something about in the Security consideration.
> 
> Good catch. After reading and re-reading Section 26.4.4 of RFC 3261, I have to
> admit that I'm not sure exactly how SIP entities are supposed to handle SIPS
> URIs. Even if we understand those requirements, I'm also not sure how they
> would apply to the XMPP side of the communications path. At the least, it
> seems we'd want to specify that if the To header or Request-URI is a SIPS
> URI, then the SIP-to-XMPP gateway needs to connect to the XMPP server
> over a TLS-protected stream. However, do we also need to stipulate that the
> XMPP server-to-client connection is TLS-protected? If so, how would the
> gateway associated with the XMPP server ensure that? (The gateway might
> be an external component of the XMPP server, without control over how the
> XMPP server communicates with XMPP clients.)
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJSQNS6AAoJEOoGpJErxa2pueYQAJFMEL4C00F37XDdk9uvA
> DsP
> 3MM9Si1gIYTmIdI4bW4HY8A5LfggByoT17SD/fYjDoescHfhxO4nb8EP/ElUq0lY
> uTeUBl9fi+PQUwQweZS4O/inQAucUTWjf6NAk3x4ETN6ct0dUwXgzj1avmu7o
> O9G
> t4STEtxtxSHMMjFUacCyHxTYp0b9fSCExUScsGHeM7RJtS4oUrxI8Rb8QNDH8b
> ZV
> CFo52opkkYBkjZFfIjMGHLzrMNR66G0C9Cbvx+SIy1hhM2iCqWtS50+KMcWBz
> g7c
> Vog96pNL/li27U18ZAR5kXMT7hbNj/eV2Na6WXPw0ITJ1LtcR2TNbyvJ66U//b0
> g
> Ba5R6Dwk7QfBjW1MQ1W79VOZsRga9RYjEuxKtJ+acZeoL/kLSikEZn0o1N+FXtz
> t
> A0sR0Hovx6jyPDodkrP4R62uhdUdDWXIcLgVOiNTtS9Hbu+RPhDOmsvAA/OyF
> t23
> u8nqBLocb57Mxwvk2b9FMGrBa5aQD2dsSiyfEXtMDlOYlxlBYa7vBoVyI8GPLIb
> m
> sTRPDjN0NvAmokzSWlcA8T2PwnXu06N3UOctw7eVZPoFIE6yk0t/kMNhofMx
> q/EV
> 4K+tnU1I3w/irDTYA8g3zRfCpbs+RlmGG9pgpN9iOFdas9AQe1jS1rZp3H8C/TG
> U
> DM4DbC4CrD0Itj2y0pBp
> =VUg1
> -----END PGP SIGNATURE-----
> _______________________________________________
> stox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stox

---

From: Robert Sparks <[email-masked]>
Date: Fri, 27 Sep 2013 08:46:47 -0500

(Adding Jon)

Peter - is there nothing in XMPP that lets a client say "I want this to 
use secure transports only - have it fail rather than use an insecure 
transport anywhere along its delivery path?"

That's the primary property you should discuss. Without putting a lot of 
thinking into it, I suspect that if you _don't_ have a way to express 
that available (which is what I'm taking away from your last sentence), 
the right guidance in the document is to refuse to gateway a SIP request 
that expresses that requirement.

Maybe Jon has a different opinion?

We can dive into the details of where to look for a sips: URI once we 
think we're on the same page on that high level principle.

RjS

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 27 Sep 2013 10:14:31 -0600

On 9/27/13 7:46 AM, Robert Sparks wrote:
> (Adding Jon)
> 
> Peter - is there nothing in XMPP that lets a client say "I want
> this to use secure transports only - have it fail rather than use
> an insecure transport anywhere along its delivery path?"

No. That doesn't mean we don't need it (although in general people
have thought we *wouldn't* need it if we could just define an
end-to-end encryption method that solve all the relevant use cases).

> That's the primary property you should discuss. Without putting a
> lot of thinking into it, I suspect that if you _don't_ have a way
> to express that available (which is what I'm taking away from your
> last sentence), the right guidance in the document is to refuse to
> gateway a SIP request that expresses that requirement.

Indeed, that seems correct.

Thanks for the guidance.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 29 Sep 2013 19:55:57 -0600

On 9/27/13 10:14 AM, Peter Saint-Andre wrote:
>> this to use secure transports only - have it fail rather than
>> use an insecure transport anywhere along its delivery path?"
> 
>> That's the primary property you should discuss. Without putting
>> a lot of thinking into it, I suspect that if you _don't_ have a
>> way to express that available (which is what I'm taking away from
>> your last sentence), the right guidance in the document is to
>> refuse to gateway a SIP request that expresses that requirement.
> 

Here is proposed text:

   As specified in Section 26.4.4 of [RFC3261], a To header or a
   Request-URI containing a SIPS URI is used to indicate that all hops
   in a communication path need to be protected using Transport Layer
   Security [RFC5246].  Because XMPP lacks a way to signal that all hops
   need to be encrypted, if the To header or Request-URI of a SIP
   message is a SIPS URI then the SIP-to-XMPP gateway MUST NOT translate
   the SIP message into an XMPP stanza and MUST NOT route it to the
   destination XMPP server.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Robert Sparks <[email-masked]>
Date: Mon, 30 Sep 2013 08:37:10 -0500

>     the SIP message into an XMPP stanza and MUST NOT route it to the
wfm. You might also talk about not using sips when going XMPP->SIP.
If you haven't found it already, see also RFC5630.

RjS
> iQIcBAEBAgAGBQJSSNotAAoJEOoGpJErxa2pAbMQALNKvkSDQLr5yj/4GBaR0qep
> AMI3pFQ9DdjYPQHaNt/OZRJ22K0XfSbRTEHPRsuld1r2vmMLKRoCh6dxc35TGCYw
> 5DyolpraQfPE+3zBvlLONtisIbTxNeha20taL6Sbb67pnLJ8xPArn/yHY56Pwq30
> PRcffweaNEBlIB26nGiEKshTn/zdmhls59lW6tM+1NuO0DsYdydtO8Ikm4PjLFST
> GoEihN06Uttw3Jgt08kl1q6fsy3GAjsUaikItjijuKGhQG598YQTE7SbKqxo5mwX
> h5FT+mdTsGO9lPvPg/+MqMAcXFZOHFbixHMNK/kHmDnnDBbq3EOyDj7Jtn5RuSbw
> OSgz0vXtmJnCrWkMHMmZtJdS9ixYu3/FEbolagjGte2Ug+1atO8kJPn0zXgZsMk2
> qg3eK2SpRjWrT7aB8mC9Pquj0YSL6KXUDW4G7it16XGd0mome0FqdNjBWXmnBEfK
> 5C7vGTXbp9xswLPki/ga3i9dM1scSnKOsL16MaTOysAyNZAelcwB7Xgds5AJGN5g
> qJ/sLpzTagC1njDulceHHnTYqS9gnkeR1lBcnBsuS6baDtWBcHDfI8vdpu5qQm8k
> 1QTDnkFjTBeij3PF1SCcP8M2bIYJhwnaaC0Vp8SmygvgaWiD4ttJinC6PlBuY9MQ
> guqUK2QaJI+SvnADH69K
> =aHme

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 30 Sep 2013 15:43:33 +0200

> If you haven't found it already, see also RFC5630.

Agree. It will help a lot of developers to explain that even if you find NAPTR
records indicating that a destination ONLY supports TLS connections,
you will look up _sips._tcp in SRV but this does NOT mean that you are going
to use a SIPS: uri. The _sips SRV tag and the SIPS: uri are unfortunately
very similar but not directly related in a confusing way :-)

/O

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 30 Sep 2013 08:56:46 -0600

> very similar but not directly related in a confusing way :-)

Thanks for the notes. I'll review those today.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/