[VOIPSEC] Key Negotiation for SRTP (Ahmar Ghaffar)
mbaugher at cisco.com
Mon Aug 29 16:51:07 PDT 2005
On Aug 29, 2005, at 3:45 PM, Lakshminath Dondeti wrote
> MIKEY-NULL in my view is for debugging and initial deployment purposes.
Do you mean initial deployment inside a VPN of some sort?
> 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
I don't think so, either. I'm wondering about using PSK as the
principal authenticator. I don't understand exactly how that works in
a telephony system.
> I don't disagree that we'd need public key authentication
It's like Waiting for Godot. Phil Zimmerman has an alternative
approach that does not require one. That's yet another way to key
>>> Now, latency is an issue and so MIKEY, by design is a very efficient
>>> 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,
>>> If number crunching is still an issue, there might be
>>> scope for system-level optimizations and perhaps for protocol
>> I'd be interested to know if MIKEY run in NULL encryption mode needs
>> further "optimization."
>> cheers, Mark
>>> 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
>>>> 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
>>>> 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
>>>> promising in this regard and this is the direction in which
>>>> everybody should
>>>> be moving.
>>>> Voipsec mailing list
>>>> Voipsec at voipsa.org
>>> Voipsec mailing list
>>> Voipsec at voipsa.org
More information about the Voipsec