Subject: RE: [AVT] <From, To> and MKI, FRC 3711

From: "Sylvain Latulippe" <[email-masked]>
Date: Tue, 11 May 2004 08:56:56 -0400

Hi,

My understanding is the following:

Both mechanisms can be used whitin the same session. When using MKI, <From, To> mechanism can be used by the sender side for synchronizing key transitions (re-keying).

For example:

A session is started and 2 keys (KEY_1 and KEY_2) are given to the session.

Session parameters:
KEY      FROM    TO        MKI
KEY_1    0       10        1 
KEY_2    11      x         2

The sender uses KEY_1 to encrypt packets with index 0 to 10. MKI = 1 is also appended to packets 0 to 10. When building packet with index 11, the sender switches to KEY_2 and appends MKI = 2 to the packet.

On the receiver side, <From, To> is not required in this scenario. MKI is extracted from the received packet and used to retrieve the right key.

Sylvain

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Ofer Goren
Sent: 11 mai, 2004 07:35
To: [email-masked]; [email-masked]
Subject: [AVT] <From, To> and MKI, FRC 3711

Hi.

In RFC 3711, section 8.1.1, it says that "using the MKI does not exclude using <From, To> key
   lifetime simultaneously".

As I understand it, both mechanisms can be used for the same session simultaneously. However, does the <From, To> mechanism is MANDATORY to be used every time (whether <From, To> is used or not), or can I omit it if I'm using MKI?

Thanks,

Ofer.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Mark Baugher <[email-masked]>
Date: Tue, 11 May 2004 08:28:29 -0700

hi
   Using both mechanisms is a lot of complexity and I'm hard pressed to 
find examples of when we would need two mechanisms, which do the same 
thing.  I don't like that final sentence in 8.1.1 in RFC 3711 because 
complexity undermines security and using both mechanisms is complex.

   From/To has the advantage of not adding a field to the packet, but it 
has the disadvantage of insecure interactions with the AES counter mode 
transform.  MKI adds a field but does not suffer from this problem.  I 
would choose one or the other but not both.

   As it is described below, use of both mechanisms is superfluous AFAICT.

Mark

At 05:56 AM 5/11/2004, Sylvain Latulippe wrote:

>Both mechanisms can be used whitin the same session. When using MKI, 
><From, To> mechanism can be used by the sender side for synchronizing key 
>transitions (re-keying).
>
>For example:
>
>The sender uses KEY_1 to encrypt packets with index 0 to 10. MKI = 1 is 
>also appended to packets 0 to 10. When building packet with index 11, the 
>sender switches to KEY_2 and appends MKI = 2 to the packet.
>
>On the receiver side, <From, To> is not required in this scenario. MKI is 
>extracted from the received packet and used to retrieve the right key.
>
>Sylvain
>
>
>
>
>As I understand it, both mechanisms can be used for the same session 
>simultaneously. However, does the <From, To> mechanism is MANDATORY to be 
>used every time (whether <From, To> is used or not), or can I omit it if 
>I'm using MKI?
>
>Thanks,
>
>Ofer.
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Sleepycat Software
>Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
>deliver higher performing products faster, at low TCO.
>http://www.sleepycat.com/telcomwpreg.php?Fromdnemail3
>Srtp-users mailing list
>[email-masked]
>https://lists.sourceforge.net/lists/listinfo/srtp-users

---

From: Mats Näslund <[email-masked]>
Date: Tue, 11 May 2004 21:49:42 +0200

Hi

What I think Mark refers to is a situation in which

- several SRTP streams share a master key, and,
- re-keying is based on From-To values.

If you use SRTP in this way (which RFC3711 recommends against)
the receiver may in some cases have problem determining the correct
key. However, there is really no "extra" security problems involved.
What *could* happen is a so-called two-time pad, but this would be
caused by a misstake by the sender, not by the receiver. Furthermore,
this key sharing is not allowed in RFC3711, unless you can guarantee
distinct SSRCs for the RTP sessions sharing the key. Whence, if you
(somehow) could guarantee such SSRC-distincness, two-time pads would
anyway not occur.

Cheers

/Mats

---

From: Mark Baugher <[email-masked]>
Date: Tue, 11 May 2004 16:28:22 -0700

Yes, I think calling the interactions "insecure" as I did is not
accurate.  There is the following issue as I see it:  An SRTP master
key can be associated with one or more session keys each having its
own sequence-number space.  So the master key per se does not have
a sequence-number space but from-to is used to determine when to
change master keys.  If the master key is always in one-one
relationship with a session key, then there is no ambiguity.
But if the master key is used to derive two or more session keys,
then the from-to is not well defined.

Is this "insecure?"  Probably not.

Mark
space.  So from-to works on
At 12:49 PM 5/11/2004, Mats Näslund wrote:

>>><From, To> mechanism can be used by the sender side for synchronizing 
>>>key transitions (re-keying).
>>>
>>>For example:
>>>
>>>also appended to packets 0 to 10. When building packet with index 11, 
>>>the sender switches to KEY_2 and appends MKI = 2 to the packet.
>>>
>>>On the receiver side, <From, To> is not required in this scenario. MKI 
>>>is extracted from the received packet and used to retrieve the right key.
>>>
>>>Sylvain
>>>
>>>
>>>
>>>
>>>simultaneously. However, does the <From, To> mechanism is MANDATORY to 
>>>be used every time (whether <From, To> is used or not), or can I omit it 
>>>if I'm using MKI?
>>>
>>>Thanks,
>>>
>>>Ofer.
>>>
>>>

---

From: tal shahar <[email-masked]>
Date: Wed, 12 May 2004 01:17:31 -0700 (PDT)

hi Mark
I'm not sure I understand your point
do you suggest that one master key can have a few sets of SRTP session keys simultaniously in use ?
i.e. can it happen that for the same master key, different streams will have different SRTP session keys
I'm asking this since the procedure of deriving a session key from a given master key does not include the use of SSRC - therefore I dont understand how different streams will have different session keys.
as for the <from, to>, as far as I understand ,this value is used to define a master key "life time" ,it doesnt help you define a sequence number space per a session key ?

Mark Baugher <[email-masked]> wrote:

Mark
space. So from-to works on
At 12:49 PM 5/11/2004, Mats Näslund wrote:

>>> mechanism can be used by the sender side for synchronizing 
>>>On the receiver side, is not required in this scenario. MKI 
>>>Subject: [AVT] and MKI, FRC 3711
>>>
>>>
>>>Hi.
>>>
>>>In RFC 3711, section 8.1.1, it says that "using the MKI does not exclude 
>>>using key
>>>simultaneously. However, does the mechanism is MANDATORY to 
>>>be used every time (whether is used or not), or can I omit it 
>>>if I'm using MKI?
>>>
>>>Thanks,
>>>
>>>Ofer.
>>>
>>>

---------------------------------
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'

---

From: Mark Baugher <[email-masked]>
Date: Wed, 12 May 2004 13:24:02 -0700

hi

>keys simultaniously in use ?

Yes.  At minimum, we'll likely have SRTP and SRTCP session keys derived 
from the master keys (pg 9 of RFC 3711).

>have different SRTP session keys

Yes, beyond SRTP and SRTCP (see pg 10).

>I'm asking this since the procedure of deriving a session key from a given 
>master key does not include the use of SSRC - therefore I dont understand 
>how different streams will have different session keys.

The keystreams are differentiated with the SSRCs, not the keys themselves 
(see pg 21).

>as for the <from, to>, as far as I understand ,this value is used to 
>define a master key "life time" ,it doesnt help you define a sequence 
>number space per a session key ?

My point is that <from, to> are sequence numbers, or extended sequence 
numbers computed from the SEQ and the ROC.  SRTP streams have sequence 
numbers and there is the _potential_ for a problem or at least some 
additional complexity when you derive multiple session keys (for individual 
streams) from a given master key since you at least have to signal which 
sequence number space is being used for the from-to.

Mark

>> >>>This SF.Net email is sponsored by Sleepycat Software>>>Learn 
>> developer strategies Cisco, Motorola, Ericsson & Lucent use to
>Yahoo! Movies - 
><http://movies.yahoo.com/showtimes/movie?mid=1808405861>Buy advance 
>tickets for 'Shrek 2'