[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Srtp-users] RE: [AVT] <From, To> and MKI, FRC 3711
hi
At 01:17 AM 5/12/2004, tal shahar wrote:
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 ?
Yes. At minimum, we'll likely have SRTP and SRTCP session keys derived
from the master keys (pg 9 of RFC 3711).
i.e. can it happen that for the same master key, different streams will
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
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 -
<http://movies.yahoo.com/showtimes/movie?mid=1808405861>Buy advance
tickets for 'Shrek 2'
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt