Jingle encryption (was: Re: [Standards-JIG] jingle archives)
brian.raymond at je.jfcom.mil
Fri Jan 27 17:00:50 UTC 2006
This might add more confusion to the discussion but here is a little
information from my experiences working SIP/H.323 solutions.
I have seen a lot of the work being done lately revolve around using SRTP
for encryption of the media. There is some disagreement on key negotiation
depending on the protocol. In SIP I have been closest to solutions which use
MIKEY for keying however I have seen TLS SIP messages with crypto extensions
done a number of different ways to pass the key, and S/MIME. Zfone takes yet
another approach and uses RTP header extensions to do a Diffie-Hellman
exchange. In H.323 the H.235 series of specifications include profiles for
methods of key exchange and media encryption. SRTP has recently picked up
steam in that arena as well and I have seen MIKEY used (H.235.7) for key
management however there are some other methods as well.
On 1/26/06 3:26 PM, "Peter Saint-Andre" <stpeter at jabber.org> wrote:
> 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):
> 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
>> 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:
>>>>>> 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
>>>>> 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.
More information about the Standards