RE: [Sip] SIP Security mechanism?

["Michael Hammer \(mhammer\)" <[e-mail]>]

Frank,

My post did not address your main question.  If I understand your
requirements correctly, then yes it could be applied to arrive at a
shared key for encryption rather than worrying about key compromise
during transmission.  Francois Audet and Dan Wing had also written an
extensive draft comparing multiple proposed mechanisms for media
security and there may be other requirements not met.  I seem to
remember D-H being in there somewhere:

Evaluation of SRTP Keying with SIP:  draft-wing-rtpsec-keying-eval-01

Might be worth a look for similar issues.

Mike


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Thursday, August 03, 2006 1:42 PM
> To: Michael Hammer (mhammer); [e-mail]; Fries, Steffen
> Cc: Cullen Jennings (fluffy); [e-mail]
> Subject: RE: [Sip] SIP Security mechanism?
> 
> 
> 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\)" <[e-mail]> 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:[e-mail]]
> > > Sent: Saturday, July 29, 2006 11:24 AM
> > > To: Fries, Steffen
> > > Cc: Cullen Jennings (fluffy); [e-mail]
> > > 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:[e-mail]]
> > > > > Sent: Saturday, July 22, 2006 3:58 AM
> > > > > To: Cullen Jennings
> > > > > Cc: [e-mail]
> > > > > 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, [e-mail] 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 [e-mail] for questions on 
> > > > > > > current sip Use [e-mail] 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 
> > > > > [e-mail] for questions on current sip 
> > > > > Use [e-mail] 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 
> > > > [e-mail] for questions on 
> current sip Use 
> > > > [e-mail] 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 
> > > [e-mail] for questions on current sip Use 
> > > [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip