Jingle encryption (was: Re: [Standards-JIG] jingle archives)

Peter Saint-Andre stpeter at jabber.org
Thu Jan 26 20:26:03 UTC 2006


BTW, I was just talking with Phil Zimmerman at ETel. His Zfone software 
looks interesting. It works at the RTP level, so it is agnostic 
regarding the signalling layer (could be SIP, could be Jingle, could be 
whatever). More here (according to Phil, expect a beta release in late 
February or early March):

http://www.philzimmermann.com/EN/zfone/index.html

Peter

Scott Ludwig wrote:
> I wanted to point out that encryption is relevant on two levels -
> generic stream level encryption, as a generic service of Jingle p2p
> streams, and session type specific encryption, when a session type
> (such as audio) has specific format requirements (for example SRTP).
> 
> With generic stream level encryption, a new session type could take
> advantage of encryption support as provided by Jingle p2p streams,
> without having to implement an encryption mechanism. This would be a
> powerful, convenient feature.
> 
> Jingle-audio on the other hand wouldn't use Jingle encryption support
> because it has specific format requirements (RTP / SRTP). It would
> instead implement it's own encryption to get format compatibility.
> However at an implementation level, much could be shared between the
> two.
> 
> 
> On 12/17/05, Joe Hildebrand <hildjj at gmail.com> wrote:
>> DTLS? (http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt)
>> SRTP? (RFC 3711)
>>
>> This is something we should really ensure is interoperable with the
>> SIP world.  Can someone from that camp comment on what the cool kids
>> are doing?
>>
>>
>> On Dec 16, 2005, at 11:19 PM, Nolan Eakins wrote:
>>
>>> Hal Rottenberg wrote:
>>>>> Sip Security or encryption:
>>>>> http://mail.jabber.org/pipermail/jingle/2005-December/000051.html
>>>>> 3) Encryption (at some point -- not being defined right now...)
>>>>> It bothers me that security is often considered later rather than
>>>>> earlier, so
>>>>> I think we should at least have an idea where we are going here.
>>>> I want to point out that my company, and I'm sure others are the
>>>> same,
>>>> has a policy that unencrypted VOIP cannot be used for business
>>>> purposes.  Just wanted to throw that out there.
>>> I woke up just now thinking about how encryption, signing, etc.
>>> would fit into Jingle, and what about SOCKS5 since Jingle adds a
>>> 2nd OBD method? Glad to see Justin already brought up those
>>> concerns, but I didn't see them addressed.
>>>
>>> I can live with a 2nd OBD method, but having just one is simipler.
>>> Justin brought up some good thoughts about layering which may solve
>>> encryption with Jingle and file transfer.
>>>
>>> So how are we going to get Jingle encrypted? The RTP RFC lays it
>>> off onto either the app or the transport layer. Secure RTP would
>>> require more negotiation, and I'm failing to see how negotiating
>>> encryption would fit into Jingle's flow.
>>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060126/94e13d5e/attachment.bin>


More information about the Standards mailing list