Subject: [MSEC] a question about the new GDOI draft

From: Luca Venturi <[email-masked]>
Date: Fri, 5 Jul 2002 10:29:26 +0200

I see that in the new GDOI draft the decision has been taken to adopt
Solution 1 among Brian's proposals with the introduction of two complete
rekeys. The reason for this choice seems to be the will to avoid double
encryption for the TEK (and consequent computational additional efforts
for the involved hosts , not to mention the implementation difficulties)
that would be otherwise required in Solutions 2 and 3. 

At least these are the disadvantages mentioned by Brian himself, when he
wrote about super-encryption, as I am quoting from his original first
email: 

" ... Solution 2: Leave the KD payload intact. That is, allow it to
contain both the KEK and TEK keys. But require the TEK portion of the KD
payload to be super-encrypted with the new KEK. This maintains
efficiency, but requires extra processing to that portion of the KD
payload which is super-encrypted. This is a  minimal (but subtle) change
to the GROUPKEY-PUSH protocol. However it does add substantial
complexity to the construction and processing of the KD payload.

Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one
which would contain the KEK keys. The other would the TEK keys and be
super-encrypted with the new KEK. This is the most change to the draft,
but does provide the desired efficiency and is the cleanest overall
design. ... "

If things are like this, there's something I can't figure out:
double encryption (say, super-encryption) occurs also in the fourth
message of the GROUPKEY-PULL exchange, when the two parties agree on the
use the optional [KE_I] and [KE_R] payloads for the creation of an
additional Diffie-Hellman key. Indeed, in that case, according to
section 3.2.1 of the old draft, the KD payload is "xored" with the DH
key and the whole messagge is encrypted with the key from the SA
established during phase 1. 
That's quite the same that would occur to the KD payload of the
GROUPKEY-PUSH message in the case of Solutions 2 or 3. Why isn't it
possible to "xor" the part of the KD payload that contains the TEK with
the new KEK and finally to encrypt the whole message with the current
KEK?  That doesn't seem to add much more complexity than in the
described situation of the GROUPKEY-PULL phase. The same solution might
be taken for the PUSH message, in order to adopt one among Solutions 2
and 3, as I don't see the point in renouncing to the chance of using the
more efficient solution that consists of one single message for the
GROUPKEY-PUSH message (eventually splitting up the KD in two parts,
according to Solution 3, which provides "the desired efficiency and is
the cleanest overall design"). But maybe, there are other reasons that
lead to the choice of Solution 1, that I did not understand. I would
like to know someone else's opinion about this issue.

Best regards

Luca