Subject: RE: [Sip] SIP Security mechanism?

From: [email-masked]
Date: Thu, 3 Aug 2006 12:41:47 -0500

Thanks for clarifying.  I am obviously not an expert in DH so this additional description is great.  I understood it enough to recognize the underlying semantic which sounds like it is still valid with this clarification in specific terminology.  I guess that means my question still stands.  Is the use of this technology interesting for use in the encryption of SIP message bodies when SIP messages pass through proxies and could it perhaps be used to encrypt entire messages if the signaling is between UAs directly?  This could be a nice mechanism to allow for encryption with UDP transports.

The authentication problem remains.  IIRC, the ZRTP draft treats this two ways.  First, since its targeted at media it assumes that you can do at least some "voice recognition" when you make a voice call.  Second, it includes a cheesy little "authentication string" (whatever that is) that can be sent through the secure channel once encryption is in place.  I'll admit to not completely understanding how that would be implemented.  In any event, I think decoupling authentication from encryption still gives some value.

Perhaps I should scratch out a draft outline based on my last email.  I've actually looked over the S/MIME section of 3261 hoping to determine how hard it would be to "substitute" the (what I'll call) keys generated by DH for the certificates in S/MIME.  I'm still thinking about it.

Regards,
FM

------------------------------------------------
On Thu, 3 Aug 2006 10:39:54 -0400, "Michael Hammer \(mhammer\)" <[email-masked]> wrote:

> Frank,
> 
> This is not an accurate depiction of Diffie-Hellman.  Use of the terms
> public key and private key are misleading.  Both parties generate a
> secret, derive a value from that, pass the derived value, then do
> another operation with the exchanged values to come up with the same
> *secret* key.  A more detailed explanation follows:
> 
> The Diffie-Hellman algorithm's purpose is to enable two parties to
> independently generate the same key to secure subsequent messages.  The
> parties exchange values in the clear that are derived from values kept
> secret by each party.  Both parties start off with a prime number Q and
> A, which is a primitive root of Q.  These may be generated by one side
> and passed to the other in the clear.  Each side then chooses a number
> X, kept private, and calculates Y=AX mod Q, then they exchange Y values.
> Each party can now generate the key K=YX mod Q using their private X and
> the other party's Y value.  (Party 1:  K=Y2X1 mod Q, Party 2: K=Y1X2 mod
> Q)  Both parties have the same key because the two YX values are
> equivalent to K=AX1*X2 mod Q by the rules of modular arithmetic.  The
> strength of the algorithm is derived from the difficulty, when using
> large prime numbers, to calculate the discrete logarithm of Y to get
> either X value.
> 
> The end result is that you have a secure connection to *someone*.  It
> doesn't help you know who that someone is.  Usually additional exhanges
> across that secure channel are used to do authentication.  Hope this
> helps.
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: Frank W. Miller [mailto:[email-masked]] 
> > Sent: Saturday, July 29, 2006 11:24 AM
> > To: Fries, Steffen
> > Cc: Cullen Jennings (fluffy); [email-masked]
> > Subject: RE: [Sip] SIP Security mechanism?
> > 
> > 
> > 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
> > 
> > 
> > 
> > On Wed, 2006-07-26 at 08:47 +0200, Fries, Steffen wrote:
> > > 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
> > 
> > 
> > _______________________________________________
> > 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: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 3 Aug 2006 14:53:30 -0400

Hi Frank,
I'm not sure what the point of it would be.
Authentication (and non-repudiation) is the really hard part, and the prize.

ZRTP ultimately relies on the user reading out the SAS, or else a MiTM can
do b2b-zrtp and no one would be the wiser. (it would be quite expensive
though)  Voice recognition is meaningless if all I want to do is monitor,
and people presumably call strangers a lot (like their bank).

The same would be true of your proposal.  There is nothing authenticating
the encryptor/decryptor is who she claims to be.  That's the value of certs.
(and they freshen your breath)  

I think you said the benefit of this is "perhaps encryption would become
more pervasive".  TLS provides you that (and more), yet it's not pervasive.
It's not end-2-end, but then neither is your mechanism ultimately. 

You also said "you don't need to trust the proxies anymore than you do now".
I actually agree, in that I think you have to trust your proxies a lot now.
Ironically, it's actually the proxies who don't fully trust you.  ;)

But I assume you meant you don't have to trust them, and I don't think
that's true - because they would be the perfect MiTM against your mechanism.

-hadriel

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, August 03, 2006 1:42 PM
> To: Michael Hammer (mhammer); [email-masked]; Fries, Steffen
> Thanks for clarifying.  I am obviously not an expert in DH so this
> additional description is great.  I understood it enough to recognize the
> underlying semantic which sounds like it is still valid with this
> clarification in specific terminology.  I guess that means my question
> still stands.  Is the use of this technology interesting for use in the
> encryption of SIP message bodies when SIP messages pass through proxies
> and could it perhaps be used to encrypt entire messages if the signaling
> is between UAs directly?  This could be a nice mechanism to allow for
> encryption with UDP transports.
> 
> The authentication problem remains.  IIRC, the ZRTP draft treats this two
> ways.  First, since its targeted at media it assumes that you can do at
> least some "voice recognition" when you make a voice call.  Second, it
> includes a cheesy little "authentication string" (whatever that is) that
> can be sent through the secure channel once encryption is in place.  I'll
> admit to not completely understanding how that would be implemented.  In
> any event, I think decoupling authentication from encryption still gives
> some value.
> 
> Perhaps I should scratch out a draft outline based on my last email.  I've
> actually looked over the S/MIME section of 3261 hoping to determine how
> hard it would be to "substitute" the (what I'll call) keys generated by DH
> for the certificates in S/MIME.  I'm still thinking about it.
> 
> Regards,
> FM
> 
> 
>

---

From: "Frank W. Miller" <[email-masked]>
Date: Thu, 03 Aug 2006 20:54:07 -0400

> Authentication (and non-repudiation) is the really hard part, and the prize.

Agreed, but end-to-end encryption of the bodies is also hard given the
basic architecture of SIP and valuable.  S/MIME does that job but there
is the problem of managing certs (spearmint for me thanks).  This
proposal is basically laser focused on providing an alternative to
S/MIME that doesn't require central cert/key management, nothing more.
It gives up on S/MIME centralized style authentication to do that.  That
may or may not be interesting.

> It's not end-2-end, but then neither is your mechanism ultimately. 

This proposal could be made end-to-end if some form of authentication
were built on top of it.  That cannot be said of TLS unless S/MIME or
something like this is used in conjunction with it.

> that's true - because they would be the perfect MiTM against your mechanism.

All true. However, your statement is not an implication.  Just because
the proxies are perfect MitM attackers for lots of things including this
proposal, doesn't mean that that type of attack cannot be defeated if
this type of encryption is used.  Again, were some end-to-end
authentication protocol put in place above this type of encryption, it
would solve this problem.  S/MIME solves that with centralized cert
management but thats not the only way to do authentication.

Your discussion is actually crystallizing the thought that perhaps
encryption and authentication should be separated architecturally.  This
would allow for various types of encryption and various types of
authentication to be used as required for a given application.  This
would also allow for situations where authentication is not required but
encryption is needed to be implemented separately from those situations
that require both.

I can think of situations where encryption with essentially implicit
authentication are possible.  Consider a military wireless network for
example.  In such a case, the underlying signal in space provides
implicit authentication but there can never be enough layers of
encryption.  One might argue that if you're going to go to the trouble
to encrypt, why not do authentication?  I think the problem is just what
we've seen, managing central repositories of cert information is hard in
practice.

Hope I'm not rambling on too much now...

FM

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 4 Aug 2006 23:45:24 -0400

> Sent: Thursday, August 03, 2006 8:54 PM
>
> basic architecture of SIP and valuable.  

Yeah, but whether it's valuable or not is the question.  If it doesn't
authenticate, then it's not end-to-end.  Because I guarantee you if it
becomes popular then certain boxes will terminate it, view and/or modify the
body, and re-encrypt.  They won't do it for malicious purposes (well, some
people think what they do is evil, but that's another story).  But my point
is any box could do that; in fact every box could do that, and the 2 ends
would never know.

> S/MIME does that job but there
> is the problem of managing certs (spearmint for me thanks).  

(Speermint is a different WG. ;)  

I actually don't think S/MIME's failure was because of a PKI.  Well, maybe
that was part of its initial downfall, but now it's too late.  Too many
middle-boxes want to see SDP, and some of them need to modify it.  It's not
that the vendors who make them _want_ to do that, it's because the people
who buy them want them to do it, to perform certain functions.  It's a
market decision, not up to a standards body. (BTW, I'm not just talking
about SBCs here) 

If you want to use those people's services, you have to let them see SDP.
If you don't, then send your SIP direct end-to-end.  And when you do that
you might as well use TLS instead of SDP encryption.  If you don't send it
direct, then you won't know if anything in between has modified the data or
not, because you're not authenticating it.

> something like this is used in conjunction with it.

Yup, I know.  My point was it's the authentication that's the key. (pun
intended)  Without that it's not worth it, IMHO.  Actually, even with that I
think its scope is limited.  You are making an assumption that the ends are
more trustworthy than the middle.  The guys who own the middle see it the
other way around.  The guys who own a middle and a population of ends trust
the middle the most, their ends next, and the rest of the internet the
least. (for example, an Enterprise or a home phone provider)
But that's just my warped view.  I'm one of the "bad" guys.  ;)

> encryption is needed to be implemented separately from those situations

Authentication without encryption has value.  
And encryption without authentication has value too in some cases. (media is
actually a decent example of this I think)  But for MIME attachments in SIP?
Don't get me wrong, I'm fine with better-than-nothing security mechanisms -
I just think there needs to be an issue worth addressing, and worth the
cost/trouble to do it.  In my mind what you're proposing would end up being
close to hop-by-hop in the real world (mine of course), and at that point
I'd rather just use TLS.  What we need is to figure out how to get TLS used
broadly.  

> encryption.  

God I sure hope they don't think the underlying signal provides all the
authentication they need.  And their needs are quite a bit more than most
people's.  I don't mean we couldn't all do better with their level of
paranoia, just that it's not free, and different markets tend to have a
different cost burden they're willing to live with for security.

> One might argue that if you're going to go to the trouble

I think the problem is slightly different.  The problem is varying, but one
of the big ones I think is its just not easy to put and manage certs on
every PC/phone (at least certs you can trust).  How frequently is TLS mutual
authentication performed?  Most of the time certs are just on servers, and
it takes a higher-level authentication for the server to authenticate the
client.  For example a login password/challenge (shared secret) through the
application riding on TLS.

> Hope I'm not rambling on too much now...

I can ramble with the best of them. :)

-hadriel