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

> -----Original Message-----
> From: zhou.sujing <at> zte.com.cn [mailto:zhou.sujing <at> zte.com.cn]
> Sent: Tuesday, April 17, 2012 7:49 PM
> To: Dan Wing
> Cc: mmusic <at> ietf.org
> Subject: RE: RE: RE: Hi, May I ask for your opinion on draft-zhou-
> mmusic-sdes-keymod-01?
> 
> 
> Regards~~~
> 
> -Sujing Zhou
> 
> "Dan Wing" <dwing <at> cisco.com> 写于 2012-04-17 23:42:36:
> 
> > > -----Original Message-----
> > > From: zhou.sujing <at> zte.com.cn [mailto:zhou.sujing <at> zte.com.cn]
> > > Sent: Monday, April 16, 2012 10:10 PM
> > > To: Dan Wing
> > > Subject: 答复: RE: Hi, May I ask for your opinion on draft-zhou-
> mmusic-
> > > sdes-keymod-01?
> > >
> > >
> > > Yes，the offer cannot determin if re-trageting or forking are
> occuring.
> > > I added a new parameter "keymod" with NULL　value in the offer
> message
> > > (in 01 version) no matter wich scenarios,
> > > to inform the answerer that
> > >
> > >  "Hi, I am kind of concerned about my outgoing
> > > message be intercept by some intermediates, so I am ready to accept
> any
> > > answer message with
> > > keymod parameter, if you send values in keymod parameter, I can
> update
> > > my key accordingly"
> > >
> > > It is up to the answerer to decide if it will send keymod parameter
> > > with valid value.
> > >
> > > If the answer does not care, it can send keymod with NULL value,
> and
> > > this case is the same as the current SDES;
> > > If the answer cares, it can send keymod with non-NULL value, and
> this
> > > case is what our document is solving.
> > >
> > > The answerer may be able to detect it is in a re-targeting/forking
> > > scenario, and be triggered to send keymod;
> > > Or, the answerer could not detect the situation, and be encouraged
> to
> > > send keymod, because offerer asked for.
> >
> > The offerer should just always issue a re-Invite with a new a=crypto
> key.
> >
> > I guess you are trying to optimize that so that the offerer and
> answerer
> > somehow determine if a re-Invite might be necessary?  Why not
> generalize
> > that optimization, so that the answerer indicates "re-direct
> occurred" and
> > indicates "forking occurred"?  That could be useful for this SDESC
> re-Invite
> > optimization, and could be useful elsewhere.  However, I believe it
> is
> > impossible for the Answerer to reliably determine if a re-direct
> occurred or
> > if forking occurred, which is why I have doubt that the proposal in
> your I-D
> > can work as you hope.
> >
> > -d
> 
> Let the offerer send a re-Invite or an UPDATE with a new a=crypto key
> is indeed an solution.
> But it require more roundtrips.
> 
> Our motivations are
> -to optimize the procedure
> -to enhance the security of SDES
> 
> your question is around the applicability of the optimized procedure.
> In the case of re-direct occurs, the anwser always knows it is a re-
> directed call,should no problem, our 00 draft works.
> In the case  of forking, the answer does not know it is a forked call,
> our 00 draft does not work in this case.
> 
> Our 01 verion does not let answer alone to determin if a re-direct or a
> forking occur.
> Instead, our 01 version is a general upgrade to current SDES protocol,
> that will come to our
> another motivation :enhance the security of SDES
> 
> 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?

-d

> 
> 
> 
> >
> >
> > >
> > >
> > > Regards~~~
> > >
> > > -Sujing Zhou
> > >
> > > "Dan Wing" <dwing <at> cisco.com> 写于 2012-04-17 05:14:58:
> > >
> > > > I don't see how sending additional parameters solves the problem.
> > > >
> > > > The problem is the offerer cannot determine if re-targeting or
> > > forking
> > > > occurred, and thus cannot determine if it needs to send a new
> > > (updated)
> > > > offer.  The only solution is to always send a new offer.
> > > >
> > > > -d
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: zhou.sujing <at> zte.com.cn [mailto:zhou.sujing <at> zte.com.cn]
> > > > > Sent: Monday, April 16, 2012 12:29 AM
> > > > > To: Dan Wing
> > > > > Subject: Hi, May I ask for your opinion on draft-zhou-mmusic-
> sdes-
> > > > > keymod-01?
> > > > >
> > > > >
> > > > > Hi, Wing,
> > > > >
> > > > >   I　have updated my draft incorporating your question.
> > > > > http://tools.ietf.org/html/draft-zhou-mmusic-sdes-keymod-01
> > > > >   May I ask for your opinion and interest in it?
> > > > >
> > > > > Thank you!
> > > > >
> > > > > Regards~~~
> > > > >
> > > > > -Sujing Zhou
> > > > >
> > > > > mmusic-bounces <at> ietf.org 写于 2012-03-21 09:32:40:
> > > > >
> > > > > >
> > > > > > Hi， Wing
> > > > > >
> > > > > >     Your point is good, I may update our draft (in 01
> version)
> > > like
> > > > > > the following paragraph:
> > > > > > " 3.1.  Generating the Initial Offer - Unicast Streams
> > > > > >
> > > > > >    The generation of the initial offer for a unicast stream
> MUST
> > > > > follow
> > > > > >    that of the crypto attribute RFC4568 [RFC4568], and MAY
> > > > > >
> > > > > >    also include an additional "keymod" parameter with keymod-
> val
> > > > > being
> > > > > >    NULL.  It indicates to the ultimate answerer that the
> offerer
> > > > > wants
> > > > > >    to employ the mechanism specified in
> > > > > >
> > > > > >    this document, a key agreement mechanism with a higher
> > > security
> > > > > level
> > > > > >    than the original SDES.
> > > > > > "
> > > > > > So that answerer does not need to know it is in a re-
> targeting or
> > > > > > forking scenario,
> > > > > > it is offerer suggesting use keymod mechanism.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Regards~~~
> > > > > >
> > > > > > -Sujing Zhou
> > > > > >
> > > > > > "Dan Wing" <dwing <at> cisco.com> 写于 2012-03-18 10:43:42:
> > > > > >
> > > > > > > To be effective, draft-zhou-mmusic-sdes-keymod needs the
> > > Answerer
> > > > > to send
> > > > > > > the "keymod" extension if it knows, or believes, the INVITE
> was
> > > re-
> > > > > targeted
> > > > > > > or forked.  I have two questions:
> > > > > > >
> > > > > > > I see for the described re-targeting case (Section 5.1 of
> > > > > > > draft-zhou-mmusic-sdes-keymod-00), a "cause" parameter
> > > [RFC4458]
> > > > > can be a
> > > > > > > useful indicator that a call was re-targeted.  Is the
> "cause"
> > > > > parameter
> > > > > > > always present when a call is re-targeted?
> > > > > > >
> > > > > > > How does the Answerer know if a call was forked?
> > > > > > >
> > > > > > > -d
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > mmusic mailing list
> > > > > > mmusic <at> ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/mmusic
> > > >
> > > >
> > > >
> >
> >
> >

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic