[VOIPSEC] Key Negotiation for SRTP

[Robert Moskowitz]

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.


Robert Moskowitz
Senior Technical Director
ICSA Labs, a division of Cybertrust, Inc.
W:      248-968-9809
F:      248-968-2824
VoIP:   248-291-0713
E:      rgm at icsalabs.com

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit