Subject: [Sip] SIP Security mechanism?

From: [email-masked]
Date: Wed, 19 Jul 2006 14:17:47 -0500

I've been reading about the ZRTP lately.  I read Henning's comment at the IETF meeting about how S/MIME relies on the receiver's public key to be available to allow for encryption/decryption to work.

Why couldnt we put in place a mechanism that did a key exchange for SIP signaling similar to whats done in ZRTP (i.e. modified Diffie-Hellman) prior to any signaling traffic, then use the exchanged keys as the basis for S/MIME encryption of the bodies?  Or we could even get really carried away and use it to do encryption of the entire SIP message if the signaling did not traverse proxies?  This could be useful for encrypting UDP signaling, again if no proxy were involved.

Thoughts?
FM

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 19 Jul 2006 21:37:47 +0200

If you run a DH then the outcome is a symmetric key. S/MIME does not 
work with symmetric keys.

Ciao
Hannes

[email-masked] wrote:
> I've been reading about the ZRTP lately.  I read Henning's comment at
> the IETF meeting about how S/MIME relies on the receiver's public key
> to be available to allow for encryption/decryption to work.
> 
> Why couldnt we put in place a mechanism that did a key exchange for
> SIP signaling similar to whats done in ZRTP (i.e. modified
> Diffie-Hellman) prior to any signaling traffic, then use the
> exchanged keys as the basis for S/MIME encryption of the bodies?  Or
> we could even get really carried away and use it to do encryption of
> the entire SIP message if the signaling did not traverse proxies?
> This could be useful for encrypting UDP signaling, again if no proxy
> were involved.
> 
> Thoughts? FM
> 
> 
> _______________________________________________ Sip mailing list
> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
> development of the core SIP Protocol Use
> [email-masked] for questions on current sip Use
> [email-masked] for new developments on the application of sip
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Jul 2006 00:17:03 -0700

you might want to have a read of draft-ietf-sipping-certs-04 if your  
goal is to make sure that users can find the keys of other users for  
use with S/MIME

On Jul 19, 2006, at 12:17 PM, [email-masked] wrote:

>
>
> I've been reading about the ZRTP lately.  I read Henning's comment  
> at the IETF meeting about how S/MIME relies on the receiver's  
> public key to be available to allow for encryption/decryption to work.
>
> SIP signaling similar to whats done in ZRTP (i.e. modified Diffie- 
> Hellman) prior to any signaling traffic, then use the exchanged  
> keys as the basis for S/MIME encryption of the bodies?  Or we could  
> even get really carried away and use it to do encryption of the  
> entire SIP message if the signaling did not traverse proxies?  This  
> could be useful for encrypting UDP signaling, again if no proxy  
> were involved.
>
> Thoughts?
> FM
>
>

---

From: "Frank W. Miller" <[email-masked]>
Date: Fri, 21 Jul 2006 21:58:20 -0400

Thanks for the pointer.  I have scanned this draft over.

The goal of your draft is similar to what I'm targeting but slightly
different.  Please correct me if I am misunderstanding something.  The
draft (which is now draft-ietf-sip-certs-01 I believe) has the goal is
to provide a way to make the distribution of certificates more automated
by providing specific infrastructure that is based on simple user
actions.  The draft specifies publication and an event package that
allows for notification to interested User Agents of certificates.

The great benefit to this approach is its preservation of user
authentication.

My thought was much simpler.  Let me drop in a quote from the ZRTP
draft, draft-zimmermann-avt-zrtp-01.txt:

ZRTP is key agreement protocol which performs Diffie-Hellman key
   exchange during call setup in-band in the Real-time Transport
   Protocol (RTP) [1] media stream which has been established using some
   other signaling protocol such as Session Initiation Protocol (SIP)
   [11].  This generates a shared secret which is then used to generate
   keys and salt for a Secure RTP (SRTP) [2] session.

Although it uses
   a public key algorithm, it does not rely on a public key
   infrastructure (PKI).

Were we to put in place some sort of simple transaction that did this
key exchange before any other signaling, we could use the keys to do
encryption of the message bodies (similar to what S/MIME is doing)
without having to deal with PKI at all.  Since the main problem with the
use of S/MIME to date has been the certificate management, this approach
is also targeting the problem that your draft is.

However, there are a couple of differences.  First, your draft approach
preserves full S/MIME certificate based authentication, this approach
would likely not do that, it would be to allow for encryption only.  The
ZRTP draft proposes prompting the user with a short authentication
string for the media but I don't know if that would be useful for the
signaling.  Second, this approach would be much simpler, likely
requiring only a couple of messages between the UA endpoints.  It would
not require the centralized server elements that would be necessary for
the PUBLISH/SUBSCRIBE/NOTIFY components of your draft.

Consider the messages used to do key exchange in ZRTP (again from the
ZRTP draft):

 Alice                                      Bob
     |                                         |
     | Alice and Bob establish a media session.|
     |                                         |
     |                   RTP                   |
     |<=======================================>|
     |                                         |
     | Hello (ver,cid,hash,cipher,pkt,sas,Alice's ZID) F1
     |---------------------------------------->|
     |                             HelloACK F2 |
     |<----------------------------------------|
     | Hello (ver,cid,hash,cipher,pkt,sas,Bob's ZID) F3
     |<----------------------------------------|
     | HelloACK F4                             |
     |---------------------------------------->|
     |                                         |
     |        Bob acts as the initiator        |
     |                                         |
     |   Commit (Bob's ZID,hash,cipher,pkt,hvi) F5
     |<----------------------------------------|
     | DHPart1 (pvr,rs1IDr,rs2IDr,sigsIDr,srtpsIDr,other_secretIDr) F6
     |---------------------------------------->|
     | DHPart2 (pvi,rs1IDi,rs2IDi,sigsIDi,ssrtpIDi,other_secretIDi) F7
     |<----------------------------------------|
     |                                         |
     | Alice and Bob generate SRTP session key.|
     |                                         |
     |               SRTP begins               |
     |<=======================================>|
     |                                         |
     | Confirm1 (plaintext,sasflag,hmac) F8    |
     |---------------------------------------->|
     |    Confirm2 (plaintext,sasflag,hmac) F9 |
     |<----------------------------------------|
     | Confirm2AK F10                          |
     |---------------------------------------->|

They are generating keys for each of media streams here, i.e. an inband
message exchange is happening in each direction.  Something like this
could probably be simplified to just two messages for the signaling,
something like:

    Bob                             Alice
     |           HELLO                |
     |------------------------------->|
     |           200 OK               |
     |<-------------------------------|
     |                                |

This example uses a new method I made up called HELLO but I suppose this
could be folded into the INVITE transaction too, using a mechanism
similar to the 407.  The key that Alice is supposed to use to encrypt
the bodies sent to Bob would be in the HELLO and the key that Bob is
supposed to use encrypt the bodies sent to Alice would be in the 200 OK.

Is this clearer?  Does it make sense?  Its simpler but the
authentication may not be there.  That works for the media because you
can possibly recognize someone's voice.  In the signaling the
authentication thing may be a bigger issue.

FM