Re: [MMUSIC] Hi, May I ask for your opinion on draft-zhou-mmusic-sdes-keymod-01?

[[e-mail]]

> > 
> > Generaly it is preferable the session key  between two peers  be
> > established with contribution from both peers,otherwise we will get
> > into trouble
> > as  SDES now in the scenarios of re-targetting and forking.
> > Our 01 version actually suggests to change the unidirectional key
> > transport in SDES into a key agreement(indicated by "keymod"):
> > offerer provides: k1
> > answer provides: keymod value
> > the outgoing key from offerer to answerer is derived from k1 and 
keymod
> > value no matter in which situation.
> > Re-targeting and forking  happen to be the scenarios that especially
> > benefit from the change.
> 
> Which involves the same number of (signaling) round-trips, right?

In my opinion, the new method does not add extra round trips, it has the 
same round trips with 
the current SDES without re-INVITE or UPDATE.

offerer-->answerer:INVITE
       a=crypto:1 AES_CM_128_HMAC_SHA1_80
        inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 --->k1
        keymod:rand|xor|
offerer<--answerer:Response
       a=crypto:1 AES_CM_128_HMAC_SHA1_32
       inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32; --->k2
       keymod:rand|xor|WVNfX19zZW1jdGwgKCkgew==         ->keymod value

after the single round,
    k1 and keymod value-->k1' to protect session from offerer to answerer
   k2 -->  to protect session from answerer   to offerer

> 
> -d