[VOIPSEC] Key Negotiation for SRTP
rgm at icsalabs.com
Fri Aug 26 12:47:26 BST 2005
At 10:29 AM 8/25/2005, Lakshminath Dondeti wrote:
>There is a new MIKEY mode
>(http://tools.ietf.org/wg/msec/draft-ietf-msec-mikey-rsa-r) that might
>change your opinion about (2). Turns out as per RFC 3830, the DH mode is
>optional and my guess is that it may not be part of all
>implementations. It is also more expensive than the other options of MIKEY
>(as you observe below).
I am quite behind on analysing all of the mikey modes, but I am
getting up to speed.
My first take on the DH method is that precomputation can be done, as
the parameters are sent, not negotiated. Thus the device can use
'quite time' to run up a set of keys for use when needed. Now all
that needs to be done at negotiation time is the actual DH operation,
which is less, computationally, than an RSA encrypt or decrypt
operation. This is of course at the expense of memory to hold the
keys. Plus in proper security construction, these keys must be held
in a place not accessable by other processes. Still worth considering.
As for the statement that DH is not good for group key distribution,
that is relatively easy to fix. That is after te DH-HMAC is done
(and btw, NIST is looking at keyed hashes faster and 'securer' than
HMAC), the joiner can be set the group key. This is something I am
proposing for 802.11s for a cleaner WiFi MESH keying environment.
Anyway I have more reading to do. If anyone is interested in talking
to me directly about the mikey options, send me a note. As wonderful
as this list is, our good moderator can get behind in releasing posts.
Senior Technical Director
ICSA Labs, a division of Cybertrust, Inc.
E: rgm at icsalabs.com
There's no limit to what can be accomplished if it doesn't matter who
gets the credit
More information about the Voipsec