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

[[e-mail]]

Then do your support our draft being considered into a WG（mmusic） work 
item？


Regards~~~

-Sujing Zhou

"Dan Wing" <[e-mail]> 写于 2012-04-19 09:32:40:

> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Wednesday, April 18, 2012 5:48 PM
> > To: Dan Wing
> > Cc: [e-mail]
> > Subject: Re: RE: RE: RE: Hi, May I ask for your opinion on draft-zhou-
> > mmusic-sdes-keymod-01?
> > 
> > 
> > 
> > > >
> > > > 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
> 
> I now understand what you're proposing, thanks for explaining it this 
way.
> 
> That avoids a signaling round trip, but does require the Offerer and
> Answerer support keymod.  If either of them don't, the Offerer needs to
> always do a re-Invite.  So this appears a reasonable optimization to 
avoid
> always doing a re-Invite.
> 
> -d
> 
> 
>