Hi Peter,
On Mar 2, 2009, at 2:03 PM, Peter Saint-Andre wrote:
[sent to [email protected] with cc's for non-list-members]
The "XTLS" specification that Dirk Meyer and I have been working on
enables two entities to establish TLS over a Jingle transport method
before exchanging application data over the transport:
http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-00
The primary use case we've had in mind is secure end-to-end XML
streams
over a streaming transport such as in-band bytestreams (mainly for the
purpose of encrypted text chat). However, this protocol could also be
used to secure a datagram transport such as UDP via DTLS (instead of a
streaming transport via TLS). In fact the signalling is quite
similar to
DTLS-SRTP:
http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework
http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp
In particular, the XTLS <fingerprint/> element would map to the SDP
a=fingerprint line, as shown in the following pseudo-examples (I have
not checked all the specifics so there might not be a complete mapping
between the XMPP and the SIP+SDP).
<iq from='[email protected]/orchard'
id='xn28s7gk'
to='[email protected]/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:0'>
action='session-initiate'
initiator='[email protected]/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='xmlstream'>
<description xmlns='urn:xmpp:jingle:apps:xmlstream:0'/>
<transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
<candidate component='1'
generation='0'
id='a9j3mnbtu1'
ip='10.1.1.104'
port='13540'/>
</transport>
<security xmlns='urn:xmpp:jingle:security:xtls:0'>
<fingerprint>RomeoX509CertificateHash</fingerprint>
<method name='x509'/>
<method name='srp'/>
</security>
</content>
</jingle>
</iq>
INVITE sip:[email protected] SIP/2.0
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=843c7b0b
Via: SIP/2.0/TLS ua1.montague.lit;branch=z9hG4bK-0e53sadfkasldkfj
Contact: <sip:[email protected]>
Call-ID: 6076913b1c39c...@revmtepg
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 1181923068 1181923196 IN IP4 ua1.montague.lit
s=example1
c=IN IP4 ua1.montague.lit
a=setup:actpass
a=fingerprint: SHA-1 RomeoX509CertificateHash
t=0 0
m=audio 6056 RTP/AVP 0
a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1
I see a few differences here that we might want to harmonize:
1. The a=fingerprint line specifies the hashing algorithm used,
whereas
the XTLS <fingerprint/> element does not. We could easily add an
'algo'
attribute to the <fingerprint/> element.
I think that's a good idea for crypto-agility (at least).
2. The XTLS <security/> element enables a party to provide a hint
about
which TLS methods might be used (e.g., "x509" or "srp"), whereas no
SDP
methods are defined for that functionality. I could work with the
authors of DTLS-SRTP to include something along these lines.
What would we recommend that a receiver of the <security/> element do,
based on this hint? Not attempt a connection if it doesn't support
the desired method, or if it lacks a cert or password to provide
proper authentication?
best,
David
Feedback is welcome. I will look into incorporating some of this
thinking into the Jingle RTP Sessions specification:
http://xmpp.org/extensions/xep-0167.html
Peter
--
Peter Saint-Andre
https://stpeter.im/
