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

From: [email-masked]
Date: Wed, 18 Apr 2012 10:48:48 +0800

Regards~~~

-Sujing Zhou

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

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > 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" <[email-masked]> 写于 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: [email-masked] [mailto:[email-masked]]
> > > > 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
> > > >
> > > > [email-masked] 写于 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" <[email-masked]> 写于 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
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/mmusic
> > >
> > >
> > >
> 
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 18 Apr 2012 06:34:46 -0700

> Sent: Tuesday, April 17, 2012 7:49 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: RE: RE: RE: Hi, May I ask for your opinion on draft-zhou-
> mmusic-sdes-keymod-01?
> 
> 
> Regards~~~
> 
> -Sujing Zhou
> 
> > > Subject: 答复: RE: Hi, May I ask for your opinion on draft-zhou-
> mmusic-
> > > sdes-keymod-01?
> > >
> > >
> > that optimization, so that the answerer indicates "re-direct
> occurred" and
> > 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.
> 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.
> 
> established with contribution from both peers,otherwise we will get
> into trouble

Which involves the same number of (signaling) round-trips, right?

-d

> > > > > > So that answerer does not need to know it is in a re-
> targeting or
> > > > > > forking scenario,

---

From: [email-masked]
Date: Thu, 19 Apr 2012 08:47:35 +0800

> 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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 18 Apr 2012 18:32:40 -0700

> Sent: Wednesday, April 18, 2012 5:48 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: RE: RE: RE: Hi, May I ask for your opinion on draft-zhou-
> mmusic-sdes-keymod-01?
> 
> 
> 
> > >
> In my opinion, the new method does not add extra round trips, it has
> the same round trips with
>         inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 ---
> >k1
>         keymod:rand|xor|
>        inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32; ---
> >k2

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

---

From: [email-masked]
Date: Thu, 19 Apr 2012 11:13:37 +0800

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

Regards~~~

-Sujing Zhou

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Apr 2012 08:26:03 -0700

> Sent: Wednesday, April 18, 2012 8:14 PM
> To: Dan Wing
> Cc: [email-masked]
> 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

> > > > > the outgoing key from offerer to answerer is derived from k1
> and
> > > keymod