Subject: [MSEC] Question on draft-ietf-msec-newtype-keyid

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 17 Oct 2005 17:10:28 -0700

(I am asking the following Q's as an MSEC contributor)

In reviewing the proposed changes to MIKEY specified in msec-newtype-keyid, 
I wonder if this draft is making a fundamental change to RFC 3830.  My 
understanding has been that MIKEY is a point to point protocol.  While 
writing what is now 4046, we worked with the assumption that MIKEY doesn't 
have a rekey message that is broadcast/multicast to the group.  Instead, 
rekey entails, from 3830 "
Note that
MIKEY does not provide re-keying in the GKMARCH sense, only updating
    of the keys by normal unicast messages."  BTW, is multicast abnormal? :-)

Unless I am misreading, the 3GPP intended use of newtype-keyid is doing 
exactly the opposite of the above statement, which is to use MIKEY to send 
a new group key protected with the previous group key.  Nothing wrong with 
that, GDOI and GSAKMP do this.  But, I wonder whether 3830 needs to be 
revised since the extensions are *contradicting* original text.

The other issue, which is more urgent is that the newtype-keyid needs an 
update to the security considerations section.  The proposed modification 
being quite different from MIKEY as in 3830 brings up very important 
security issues.  GDOI and GSAKMP are good references in identifying these 
issues.  My understanding of the 3GPP use is that the key update messages 
are not signed, instead only protected with a MAC.  What are the 
implications of that?  Note that SRTP packets might be source authenticated 
with TESLA, so group authentication of key update messages might be an 
interesting proposition!

Thoughts?

thanks and regards,
Lakshminath 

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec