RE: Security for RTP connections - some thoughts

["Dan Wing" <dwing@xxxxxxxxx>]

Your message below seems to say that using the media path is the better
place to perform key exchange to protect the media.  DTLS-SRTP, ZRTP, and
MIKEYv2, (and EKT, which we aren't currently discussing) all perform the key
exchange in the media path.  Those are the three protocols this RTPSEC group
is concentrating on to solve the unicast point-to-point key exchange.

-d
 

> -----Original Message-----
> From: Werner Dittmann [mailto:Werner.Dittmann@xxxxxxxxxxx] 
> Sent: Sunday, March 11, 2007 4:52 AM
> To: Dan Wing
> Cc: 'EKR'; ietf-rtpsec@xxxxxxxxxxxx
> Subject: Re: Security for RTP connections - some thoughts
> 
> My comments about SIP complexity were not bound to the security topic
> alone (this is why I said - "off topic").
> 
> Here are some arguments why I'm personally not keen to use SIP (or any
> other similar signalling protocol) to solve the keying problems.
> 
> SIP and other signaling protocols like XMPP or SS#7 based protocols
> were not designed with this type of "media channel security" in mind.
> Exchanging keys is a complete different task than signaling and has
> complete different requirements to the underlying protocols. Mixing
> both tasks in one protocol IMHO asks for trouble :-) .
> 
> And this "trouble" is shown in the numerous drafts floating around
> that discuss possible solutions.
> (Some of these drafts discuss some "esoteric" attacks. See below for
> an example how secure converstaion is implemented in todays products.)
> 
> 
> Just an "implementors" point of view:
> Extending SIP to cover "keying for SRTP" would IMHO be a quite large
> extension/modification for SIP and its behaviour. Because security
> is a basic feature these extensions have either to be fully 
> supported by
> the applications or the applications have to be transparent for the
> extensions. This has to be checked/implemented in _any_ existing and
> new SIP application and SIP node that is involved in session setup.
> Because security is a sensitive issue special care must be take here.
> As I said: if just one element fails security is gone. Thus keep the
> number of elements involved as low as possible. (Of course this is
> also true for any other signaling protocol that would be extended to
> support "keying for something").
> 
> 
> My conclusions here:
> - let the signaling protocols do what they can best
> - let key exchange protocols do what they can best
> - KEEP IT SIMPLE
> 
> 
> 
> 
> Here an example how secure communication is currently solved (sorry
> for the "advertisement"):
> 
> Siemens Gigaset SL965, the page link:
> http://gigaset.siemens.com/shc/0,1935,hq_en_0_136328_rArNrNrNr
> N,00.html
> 
> Using two phones you can have a completely encrypted, secure
> conversation. The whole setup of the secure channel is 
> _after_ signaling
> has done its work. It is up to the terminals (and of course 
> the end user
> who has to push the "secure" button) to create the secure 
> channel (it even
> works over old analog POTS).
> 
> Quotes from this page:
> ...
> The SL965 features an innovative digital signal processor 
> with the latest
> encryption standards including world first 3072-bit Public 
> Key generation
> for interception-proof conversations.
> ...
> The combination of synchronous and asynchronous encryption as well as
> secure hash algorithms ensures maximum security and a considerably
> accelerated encryption process.
> 
> The Gigaset SL965 features improved voice quality on secure calls and
> extended range while the entire key generation, authentication and
> encryption is handled completely in the handset itself for
> maximum security
> ...
> 
> 
> 
> Regards,
> Werner
> 
> 
> 
> Dan Wing wrote:
> > I don't understand how SIP's millions of lines of 
> specification make this
> > problem harder.  Most of the complexity with keying SRTP is 
> due to SIP
> > forking and SIP early media.  SIP forking has been around 
> forever - forking
> > was described in RFC2543 which was published in 2002.  
> Early media is mostly
> > caused by interacting with the PSTN, although there are 
> situations where it
> > occurs without any PSTN interaction, as well
> > (draft-stucker-sipping-early-media-coping).
> > 
> > If SIP is too complex, consider looking at XMPP (Jabber).  
> Google Talk uses
> > it, and XMPP supports and offer/answer model similar to 
> SIP's.  Many of the
> > same difficulties with keying SRTP exist with XMPP, though, 
> even without
> > SIP's forking.  For example, with XMPP, it still isn't 
> desirable to use
> > sdescriptions, and the three modes described in the original MIKEY
> > specification (RFC3830) don't work with XMPP, either due to 
> lack of a
> > network-wide PSK and the lack of a mechanism (on the 
> Internet) to get the
> > called party's certificate prior to initiating a call to them.
> > 
> > Meanwhile, much of the activity in the industry, and within 
> IETF, is around
> > SIP.  So I'm not sure why you want to deflect efforts to 
> consider non-SIP
> > keying when most everyone is interested in getting SIP calls secure.
> > 
> > -d
> > 
> > 
> >> -----Original Message-----
> >> From: owner-ietf-rtpsec@xxxxxxxxxxxx 
> >> [mailto:owner-ietf-rtpsec@xxxxxxxxxxxx] On Behalf Of 
> Werner Dittmann
> >> Sent: Saturday, March 10, 2007 5:46 AM
> >> To: EKR
> >> Cc: ietf-rtpsec@xxxxxxxxxxxx
> >> Subject: Re: Security for RTP connections - some thoughts
> >>
> >>
> >> I read that document  before and while I authored mine.
> >> The document describes the requirements for RTP security in
> >> conjunction with SIP and SIP call flows. It does not address
> >> environements where RTP is used without SIP. These
> >> be taken into consideration as well.
> >>
> >> Of course a RTP security solution shall (must) address the
> >> SIP stuff :-) but shall work for (S)RTP in general too.
> >>
> >> Due to the focus on SIP use cases it seems (at least to me)
> >> that people think "SIP is a mandatory prerequisite to setup RTP
> >> connections". This may lead to the assumption "why not use SIP
> >> mechanisms when we need RTP security". IMO this is an invalid
> >> assumption.
> >>
> >> This leads back to the question in my previous post:
> >>
> >> Security for SIP initiated RTP connections?
> >>   or
> >> Security for RTP in general?
> >>
> >> What is true for both cases:
> >>
> >> A good security design involves the smallest possible number
> >> of "participants" that deal with or handle security relevant
> >> data. Any unneccesary node complicates matters and makes the
> >> proof of security more complex.
> >>
> >>
> >>
> >> Just some off-topic thoughts here (regarding SIP and its
> >> extensions):
> >>
> >> Adding more and more extensions to SIP makes it more and
> >> more complex to design, implement, and test SIP aware
> >> applications such as SIP proxies, SIP user agents, SIP B2BUA
> >> applications etc.
> >>
> >> Several years ago (about 10 yrs or so) I listened to a
> >> presentation of Henning Schulzrinne where he emphasized the
> >> simplicity of SIP compared to the H.323 protocol familiy.
> >> These were the "good old days" - look at SIP now.
> >> IMO it is an implementors nightmare to deal with with this
> >> beast and to take care about all the extensions, header fields,
> >> when to copy headers, when to remove parts of headers during
> >> proxying forward or backward, and so on.
> >>
> >> And this ever growing complexity gives me "bad vibrations" with
> >> regard to security. Just thinking about how many hops (SIP proxies,
> >> various SIP applications) a SIP packet may pass on its travel to
> >> its destination makes me nervous. If you use SIP to transport
> >> security relevant data and if just _one_ of these hops does not
> >> behave 100%  correctly then security is gone. And we all know
> >> about software problems, don't we :-)  ?
> >>
> >>
> >> A nice statement found on Henning's SIP page (in some draft):
> >>
> >>  The Session Initiation Protocol (SIP) is a flexible, yet 
> simple tool
> >>  for establishing interactive connections across the 
> Internet. Part of
> >>  this flexibility is the ease with which it can be 
> extended. In order
> >>  to facilitate effective and interoperable extensions to SIP, some
> >>  guidelines need to be followed when developing SIP 
> extensions. This
> >>  document outlines a set of such guidelines for authors of SIP
> >>  extensions.
> >>
> >> IMHO every extension makes it less "simple" :-) .
> >>
> >> Regards,
> >> Werner
> >>
> >>
> >> Eric Rescorla wrote:
> >>> [Resent b/c of bounce...]
> >>> Werner Dittmann <Werner.Dittmann@xxxxxxxxxxx> writes:
> >>>
> >>>> Wow - quite a large number of e-mails after posting the 
> link to my
> >>>> document. This even outnumbered the daily spam :-) .
> >>>>
> >>>> After some sleep and re-reading some of the mails I'll try 
> >> to do some
> >>>> summary and "clear the dust". During this I take some 
> >> qoutes and ideas
> >>>> from the mails - a big "thank you" to all participants of the
> >>>> discussion.
> >>> At this point it might help for you to go back to the fairly
> >>> extensive discussion that's already been had on this topic
> >>> and is summarized in draft-wing-media-security-requirements.
> >>> I would also refer you to the minutes and/or audio of the
> >>> BOF in Montreal which was a major input to that document.
> >>>
> >>> -Ekr
> >>>
> >>>
> >