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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, April 18, 2012 8:14 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?
> 
> 
> Then do your support our draft being considered into a WG（mmusic）
> work item？

It should be considered, yes.

-d


> 
> 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
> >
> >
> >