A significant limitation in what you propose is that it requires Bob to
have a public key that Alice knows. In general we don't find that to be
the case in most telephony applications.
Thanks,
Paul
Vadim Lebedev wrote:
> I see,
> Well this particular attack could be prevented by adding a timestamp +
> key validity period into the encrypted material...
> This is still much cheaper than using SSL in signalling path.
> Actually the current approach (SSL in signalling path and rtp key in
> clear in SDP) seems to be weaker in case of compromised server - the
> bad guy will be able to actually HEAR,SEE and FAKE
> rtp streams.
>
>
> Anyway thanks a lot for the feedback
>
> Vadim
> Le 2 juin 09 à 18:55, Alexander Krassiev a écrit :
>
>> Man in a middle. Encrypted key can be stored and re-used by man-in-a-
>> middle to forge future conversations (to garble the stream). Further
>> enhancing your suggestion will bring us close to SSL/TLS I am afraid.
>>
>> On Jun 2, 2009, at 8:27 AM, Vadim Lebedev wrote:
>>
>>> Vadim Lebedev wrote:
>>>
>>> Any thoughts on this issue?
>>> I've just realised that this approach will make lawful interception
>>> REALLY complicated... Maybe this
>>> is the reason there is no an RFC covering it? Or am i missing
>>> something?
>>>
>>> Thanks
>>> Vadim
>>>
>>>> Hello,
>>>>
>>>> I've been reading various RFC describing tranmission of master key
>>>> for SRTP unside SDP's.
>>>> They require (like in rfc4568) the INVITE/200/ACK be transmitted
>>>> using
>>>> TLS to avoid key interception.
>>>>
>>>> I wonder why nobody proped following scheme:
>>>>
>>>> Alice generates a mester key, encrypts it wih Bob's public key and
>>>> signs it with her own private key.
>>>> The resulting material is stored in SDP which can be transmitted
>>>> ove
>>>> unsecure connection...
>>>> Bob receives the INVITE request extract the signed keye authenicate
>>>> the Alice signature and decodes the master key using his onw private
>>>> key....
>>>>
>>>>
>>>>
>>>> Thanks
>>>> Vadim
>>>>
>>>> _______________________________________________
>>>> Sip-implementors mailing list
>>>> Sip-implementors@lists.cs.columbia.edu
>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> Sip-implementors@lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
