[VOIPSEC] Key Negotiation for SRTP (Ahmar Ghaffar)
ldondeti at qualcomm.com
Mon Aug 29 23:45:58 BST 2005
How are you? :-)
At 04:07 PM 8/26/2005, Mark Baugher wrote:
>On Aug 26, 2005, at 2:11 PM, Lakshminath Dondeti wrote:
>>Wow, that's a loaded statement about one new MIKEY mode and a claim "things
>>never get done" about the IETF. These are not research projects and not
>>about one-upping previous proposals. If you read the I-D, we are trying to
>>solve some real-world problems. The IETF is an open forum; if something
>>needs to be done, contributions along the lines of requirements and/or
>>solutions are always welcome.
>>Sdescriptions is an interesting alternative, but as has been pointed about,
>>it is not an end-to-end security protocol, and would need something like
>>S/MIME etc. Hop-by-hop security (as with SIP/TLS) is not sufficient.
>There will always be hop-by-hop security dependencies, e.g. each hop knows
>something about who is calling whom so there's a little privacy give
>away. Still, we want the media strictly private among caller and
>callee(s). We can get that using Diffie Hellman, but this must be
>authenticated. For all practical purposes, the only way you can do
>end-to-end authentication is with a public key infrastructure.
>sdescriptions uses PKC via S/MIME (PGP/MIME might also be used to great
>benefit). MIKEY uses it directly. That is the only difference regarding
>end-to-end security and it's not much of a difference at all. Oh, there
>is another difference, which is a real one: sdescriptions does not
>support pre-shared key (I don't understand how this can ever be secure)
>and NULL MIKEY is redundant when channel security such as sips is used. I
>know sips is a favorite whipping boy among security types, but PSK is
>arguably much worse in a wide range of practical deployments.
MIKEY-NULL in my view is for debugging and initial deployment purposes.
If a PSK has a lifetime, is that mode ok in your opinion? I am thinking of
the option to use the RSA mode to establish a PSK to amortize the cost of
RSA ops (this is a very useful feature for known callees). Since the PSK
is not based on human selected passwords or passphrases, the common
security issues with PSKs don't apply in that case.
I don't disagree that we'd need public key authentication infrastructure.
>>Now, latency is an issue and so MIKEY, by design is a very efficient key
>I think of MIKEY as a one or two-round IKE. That's efficient in terms of
>message bandwidth, but it is another state machine to be maintained,
>another system to be tested and supported. That's true of an S/MIME or
>PGP/MIME system as well, but we are going to need an S/MIME or PGP/MIME
>system anyway in order to protect the integrity of the signaling end-to-end.
Yes, there is "implementation complexity" with MIKEY. From what I have
seen on this list, e2e signaling protection seems quite far away.
>>If number crunching is still an issue, there might be
>>scope for system-level optimizations and perhaps for protocol optimizations
>I'd be interested to know if MIKEY run in NULL encryption mode needs
>>At 10:51 AM 8/26/2005, Ahmar Ghaffar wrote:
>>>Looking at the new MIKEY mode your mentioned helps me understand why things
>>>never get done at IETF and why there are always loose ends. Mr. A proposes
>>>something with ambiguities and then Mr. B proposes something claiming to be
>>>better with little tweaks to A's proposal. This draft is more or less like
>>>the public-key mode of MIKEY, and doesn't really solve the latency issue.
>>>You still have to do number crunching here. So if number crunching is to be
>>>done anyway then in my opinion its better to have secure SIP signaling via
>>>TLS/SSL and send the encryption keys in clear text with other SRTP
>>>parameters (key lifetime, MKI etc) in SDP. The SDP description draft for
>>>SRTP from Cisco (draft-ietf-mmusic-sdescriptions-11.txt) looks really
>>>promising in this regard and this is the direction in which everybody should
>>>Voipsec mailing list
>>>Voipsec at voipsa.org
>>Voipsec mailing list
>>Voipsec at voipsa.org
More information about the Voipsec