Subject: RE: [SIP] Need for encrypted VoIP and Conferencing communications

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 1 Mar 2001 01:45:15 -0500

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 11:49 AM
> To: Rosen, Brian
> Cc: 'Fleischman, Eric W'; [email-masked]'
> Subject: RE: [SIP] Need for encrypted VoIP and Conferencing
> communications
> 
> 
> Rosen, Brian writes:
>  > We have been trying to develop some upgrades to the security of
>  > sip, without much success.  We have had interest at 
> meetings, but no
>  > proposals or list discussion.
>  > 
>  > Encryption of RTP is defined, and believed to be adequate.  
> 
>    Surely you're not talking about the encryption in RFC 1889?
> 
>    Help is on the way with draft-ietf-avt-srtp-00 though.

Mike - you most forgive those of us who are not as knowledgeable as you, and
the rest of the security community, in the area of understanding the
strengths and weaknesses of security protocols. I think it would be far more
helpful to post a note with a few bullet points listing the issues with
rfc1889 security and how srtp solves them. I am aware of one, which is that
srtp uses a stream cipher, which has better replay attack prevention. The
rfc1889 mechanism runs a block cipher on each RTP packet independently,
which means it can be replayed when the SN rolls over. Is that correct?

>  > Key distribution has to be done with the call control
>  > (sip).  The mechanism currently used is to carry the keys in SDP, 
>  > which implies that the SDP has to itself be encrypted.  
> The PGP mechanisms
>  > in present SIP will allow you to do that, but we believe that such
>  > mechanisms are insufficient.
> 
>    I would say that it's mostly to do with the lack of 
>    integration with MIME more than anything else that
>    make the current PGP solution less than adequate.

There is certainly that, but there is another issue. If we assume a key
exchange by simply encrypting the session key in the MIME body, then I need
to know the public key of the eventual recipient before I send the message.
This means that if the INVITE is forwarded, my initial guess at the eventual
recipient is wrong, the body can't be decrypted, and thats bad. I'd prefer
to see a mechanism that got around this problem.

>    I believe that if we can secure e-2-e MIME attachments
>    within SIP. The larger question is whether we have a
>    single MUST/SHOULD (say, SMIME or PGP in MIME), or
>    whether we should allow for several MAY's. I'm conflicted
>    by this because although I think that things are already
>    way too complex, neither SMIME or PGP allow for Kerberos
>    credentials. Ick. The alternate is to allow
>    many different kinds of schemes and require
>    negotiation... double ick.

Just as much an ick as not selecting a baseline codec for media. Despite
that it sort of works - selection is done by providers in their RFPs. I
think this problem is just as troublesome as that one.

>    What it seems to me that we need is something
>    that is authentication-system neutral for the
>    MIME attachments --  sort of in the spirit of
>    EAP for PPP. Disclaimer: I do not follow the
>    SMIME stuff. However, draft-ietf-smime-symkeydist-02 
>    seems to be on the right general track, but 
>    there are other possible avenues as well: 
>    RFC 2712 describes a means of doing Kerberized
>    TLS which basically replaces X.509 credentials
>    with Kerberos credentials... same could
>    probably be done for SMIME.

How does that solve the problem? Now your credentials are dependent on a
kerberos authentication system.

> 
>    So, unfortunately, I'm pretty deep into
>    solution space here, but I do have one question
>    which should drag us back into the requirements
>    space: is there any encryption/authentication 
>    need for which a MIME attachment would *not* be
>    suitable as the envelope, given enough
>    flexibility with the attachment authentication
>    and crypto-systems?

For the purposes of encrypting the MIME attachment for exchanging a session
key for RTP, I have a problem as described above.

> 
>    It sure seems like it would be a clean solution
>    to me to allow any proxy/UA to just add an
>    attachment which is directed toward something
>    else farther downstream of the method or
>    response. If nothing else, it would stop all
>    of this feature creep of special headers for
>    this and that encryption/authentication need.

Well, a proxy really couldn't add an attachment since there is no way for a
downstream proxy to challenge an upstream one. The only thing we can do is
have a downstream proxy challenge a UA.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 1 Mar 2001 09:43:49 -0800 (PST)

> which means it can be replayed when the SN rolls over. Is that correct?

   Well, the first huge problem with RFC1889 is that it
   only allows for DES. Oops. SRTP attempts to solve the
   following problems:

   1) It's payload encryption (as opposed to RTP
      header+payload encryption), so CRTP and its 
      ilk will still work
   2) It uses the new AES (Rinjdael) cipher, and
      allows for new ciphers in the future
   3) It specifies a means of putting an integrity
      check on the payload (1889 was silent on
      this matter)
   4) It has the ability to use seekable stream
      ciphers as a drop in replacement for AES
   5) It specifies RTCP crypto
   6) It specifically deals with replay attacks
      (1889 was silent on that matter)
  
   Maybe a few other things I'm forgetting.

 > to see a mechanism that got around this problem.

   Well, that sort of strikes me as trying to
   exceed the speed of light. The only thing that
   you can do in the initial INVITE when you don't
   know the ultimate destination (which is the
   normal case), is that the UAC can sign the 
   blob to prove that it sent it. You can't
   do anonymous encryption.

   If that's not enough protection, then you just
   have to wait for a contact header which tells
   you the ultimate destination. I don't see any
   way around this, barring the multicast keying
   folks pulling something _really_ big out of
   their hat.
 
 > think this problem is just as troublesome as that one.

   So let me understand: are you saying that by
   virtue of the fact that we allow MIME
   attachements, they can place which ever ones
   (sensible or not, we're not the protocol
   police) in the message, and if they wanted to 
   put mime/pgp attachment in that would be OK
   so long as all parties agreed out of band?

   Maybe we're not communicating here: my concern 
   is that there needs to be a base level means of 
   telling the receiver which authentication/encryption
   schemes you are prepared to use so that the
   other side (UAS, proxy) can know how to
   respond. All of this secret decoder ring
   handshaking with RFP's frightens me on the
   end to end interoperability front.

 > kerberos authentication system.

   No, no, I think you're misunderstanding me:
   what I want is an attachment format which
   allows for many authentication/crypto schemes,
   including schemes based on certs and public key
   crypto, shared symmetric key (digests,
   encrypted), kerberos, and whatever other crypto
   things we can possibly jam in there. 

 > key for RTP, I have a problem as described above.

   You mean about not being able to ship in the
   initial INVITE? Your problem is much larger
   than how to transport the encrypted bits. 

 > have a downstream proxy challenge a UA.

   Fine, but I don't think it follows that a proxy
   couldn't add an attachment though. I'm mainly 
   thinking aloud here: I'm not wedded to the idea
   of putting all of the crypto based stuff in
   attachments... I was wondering if this might
   actually be a little bit cleaner: right now we
   don't have the ability for proxies or UAS's to
   place a cryptographically munged blob into a
   response. Saying that anything that wants to
   insert such a cryptographic blob should use
   a mime attachment would at least give a
   consistent vessel so that we aren't
   constantly ratholing on the combinatorics of
   authentication and crypto systems.

		      Mike

---

From: Colin Perkins <[email-masked]>
Date: Thu, 01 Mar 2001 14:36:02 -0500

> > which means it can be replayed when the SN rolls over. Is that correct?

I believe so. 

>   only allows for DES. Oops. 

It specified DES as default, but noted that "Other encryption algorithms
may be specified dynamically for a session by non-RTP means". RFC 1890
defined one such method for specifying different algorithms which can be
used with SDP.

>                              SRTP attempts to solve the
>   following problems:
>

RFC 1889 specifies RTCP crypto, although the other issues you note are
present. 

>   Maybe a few other things I'm forgetting.

Colin
(clarifying for accuracy -- I think SRTP is good work...)