[VOIPSEC] Key Negotiation for SRTP (Ahmar Ghaffar)

[Lakshminath Dondeti]

Hi Mark,

How are you? :-)

At 04:07 PM 8/26/2005, Mark Baugher wrote:
>Lakshminath,
>
>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
>>management protocol.
>
>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.

best regards,
Lakshminath


>>If number crunching is still an issue, there might be
>>scope for system-level optimizations and perhaps for protocol optimizations
>>too.
>
>I'd be interested to know if MIKEY run in NULL encryption mode needs 
>further "optimization."
>
>cheers, Mark
>>
>>cheers,
>>Lakshminath
>>
>>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
>>>be moving.
>>>
>>>
>>>
>>>_______________________________________________
>>>Voipsec mailing list
>>>Voipsec at voipsa.org
>>>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>
>>
>>_______________________________________________
>>Voipsec mailing list
>>Voipsec at voipsa.org
>>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org