[VOIPSEC] Key Negotiation for SRTP (Ahmar Ghaffar)

[Lakshminath Dondeti]

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.

Now, latency is an issue and so MIKEY, by design is a very efficient key 
management protocol.  If number crunching is still an issue, there might be 
scope for system-level optimizations and perhaps for protocol optimizations 
too.

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