Re: [Srtp-users] RE: [AVT] <From, To> and MKI, FRC 3711

[tal shahar <morgentuo at yahoo.com>]

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 <mbaugher@cisco.com> wrote:

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:

>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
>
>Mark Baugher wrote:
>
>>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:
>>
>>
>>
>>>Hi,
>>>
>>>My understanding is the following:
>>>
>>>Both mechanisms can be used whitin the same session. When using MKI,
>>> 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, is not required in this scenario. MKI
>>>is extracted from the received packet and used to retrieve the right key.
>>>
>>>Sylvain
>>>
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Ofer Goren
>&>>Sent: 11 mai, 2004 07:35
>>>To: avt@ietf.org; srtp-users@lists.sourceforge.net
>>>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
>>> lifetime simultaneously".
>>>
>>>As I understand it, both mechanisms can be used for the same session
>>>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.
>>>
>>>
>>>-------------------------------------------------------
>>>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
>>>Srtp-users@lists.sourceforge.net
>>>https://lists.sourceforge.net/lists/listinfo/srtp-users
>>>
>>
>>
>
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt



_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

---

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