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

[[e-mail]]

Regards~~~

-Sujing Zhou

"Dan Wing" <[e-mail]> 写于 2012-04-17 23:42:36:

> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > 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.



> 
> 
> > 
> > 
> > Regards~~~
> > 
> > -Sujing Zhou
> > 
> > "Dan Wing" <[e-mail]> 写于 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: [e-mail] [mailto:[e-mail]]
> > > > 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
> > > >
> > > > [e-mail] 写于 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" <[e-mail]> 写于 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
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/mmusic
> > >
> > >
> > >
> 
> 
>