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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 22 Feb 2001 17:14:02 -0500

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.  There is
sentiment to allow integrity protection, which was done at in the
PacketCable specs.  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.

For hop-by-hop security between sip components, IPSEC or TLS is quite
satisfactory.  The concern is end-to-end, or possibly domain to domain
through an untrusted set of domains.  You want the usual suspects,
authentication, integrity protection and confidentiality, with a dose of
replay protection.  Some even want non-repudiation, but usually that has to
do with billing, and thus may not be entirely a sip issue.  I'd like to see
a better way to get the keys for the RTP (D-H perhaps).

Should you have expertise, you are welcome to work on this problem.
There is a mailing list ([email-masked]), and we traditionally
hold a bof-like meeting during each IETF meeting, to which all are welcome.

Brian

> -----Original Message-----
> From: Fleischman, Eric W [mailto:[email-masked]]
> Sent: Thursday, February 22, 2001 4:53 PM
> To: [email-masked]'
> Subject: [SIP] Need for encrypted VoIP and Conferencing communications
> 
> 
> Draft-ietf-sip-privacy-00.txt states that for SIP to be a 
> viable alternative to the current PSTN, SIP must support 
> certain popular telephony services offering privacy. However, 
> the draft does not address a SIP privacy need having a 
> substantially more compelling business case (for many 
> industries) than the services identified by this draft.
> 
> Specifically, if Internet-based collaboration, including 
> VoIP, is to replace traditional telephony alternatives, 
> including H.323-based conferencing, it is imperative that 
> sessions initiated by SIP be optionally encrypted to ensure 
> privacy protection. The requirement is that the parties 
> participating in a session must be known to the other session 
> participants, but that it be physically impossible for 
> non-participants to eavesdrop upon that session, including 
> thwarting all "man in the middle" exploits. The obvious 
> approach by which this can be done is to define a "session 
> encryption" alternative within SDP and a standard mechanism 
> for encrypting traffic carried by RTP. It isn't clear to me 
> whether SIP needs to be aware of the encrypted nature of this 
> traffic or not, hence this query to this mail list: Does SIP 
> need visibility into whether the session transports encrypt 
> their data or not? 
> 
> A related question is: where should the encryption be done? 
> Should it be done at the IPSec layer in a manner potentially 
> transparent to the higher level protocols or should it be 
> done at data level being conveyed by RTP -- or at some other 
> layer? I would be very appreciative to learn what work, if 
> any, members of this list have done to investigate these 
> types of issues.
> 
>  
> 
> _______________________________________________
> 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.
> 

_______________________________________________
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: Wed, 28 Feb 2001 08:48:48 -0800 (PST)

Rosen, Brian writes:
 > 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.

 > There is
 > PacketCable specs. 

   I believe this, as well as RTCP payload encryption are part
   of the SRTP proposal.

 > Key distribution has to be done with the call control

   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.

 > a better way to get the keys for the RTP (D-H perhaps).

   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.

   I generally object to hard wiring a
   single authentication/encryption scheme even beyond 
   not allowing Kerberos: it's seems quite possible and
   likely that it's not just end to end authentication that's
   important; we already know that we need to be able to do
   proxy challenges. If we had a single means of creating an
   attachment with the proper authentication credentials
   (possibly encrypted) for whatever entity in the 
   path desires a cryptographically transmogrified
   blob, we would kill two birds with one stone.

   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.

   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?

   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.