Subject: RE: [Sip] SIP Security mechanism?

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 26 Jul 2006 08:47:59 +0200

Hi Frank,

the method you are describing at least requires the usage of TLS to
protect the key exchange between Alice and Bob.  Moreover, you do need
to trust the proxies in between, as they have access to the keys
(assumed you send the key from Alice to Bob in the SDP). You may combine
the SIP_CERTS approach with draft-ono-sipping-smime-keyreuse-01.txt to
have one S/MIME encryption based on certificates and use the key-reuse
for the rest of the session. But as I wrote last time, the draft
regarding key-usage has expired  and I'm not sure if it will be updated.

Ciao
	Steffen

> -----Original Message-----
> From: Frank W. Miller [mailto:[email-masked]] 
> Sent: Saturday, July 22, 2006 3:58 AM
> To: Cullen Jennings
> Cc: [email-masked]
> Subject: Re: [Sip] SIP Security mechanism?
> 
> 
> 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
> 
> 
> On Fri, 2006-07-21 at 00:17 -0700, Cullen Jennings wrote:
> > 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.
> > >
> > > 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
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Frank W. Miller" <[email-masked]>
Date: Sat, 29 Jul 2006 11:23:37 -0400

Actually, I don't think TLS would be required and I don't think you need
to trust the proxies anymore than you do now.  Diffie-Hellman (if I
understand it correctly, which is not a certainty) essentially causes
the endpoints to dynamically generate public keys that have
corresponding private keys.  The receiver sends the public key to the
sender to be used for encryption and uses the private key for
decryption.  This mechanism would allow for the public keys to be passed
in the clear in the initial exchange and that means it could be used
with any type of transport.

The proposal has weaknesses (i.e. difficulties with authentication, MitM
attacks), but it does allow for simple key exchange that doesn't require
ANY infrastructure which should facilitate encryption of bodies if
proxies are present and entire messages if the UAs are B2B.  The
proposal is focused mainly on the difficulties associated with key and
certificate management that have been observed operationally.  By
eliminating that part of the process, perhaps encryption would become
more pervasive, which would be a good thing IMHO.

Thanks,
FM