Subject: Re: [MSEC] GDOI fix

From: "Catherine A. Meadows" <[email-masked]>
Date: Tue, 18 Dec 2001 14:09:09 -0500 (EST)

Mark:

Thanks much for your comments and suggestions.  Here are my responses:

> First, the
> KD does not necessarily end with an SPI but with key attributes, which
> include a key and some metadata about the key.  If this were always the
> case, would this prevent ATTACK 1?  

If the KD always ended with the metadata instead of the key, this would
prevent the attack, which requires that the signed
part of the GROUPKEY-PUSH message end in random data.

> I don't like having this restriction on
> the KD payload since attributes are optional by definition. 

I agree.  In order to keep the specification as modular as possible,
we want to avoid putting any restrictions on what the KD payload looks like.

 > Second, what
> do you think about placing the SEQ after the KD since a message having an
> invalid SEQ would be rejected?

I think that this would work against the first
attack.  Anything that would force the signed
part of GROUPKEY-PUSH to end in recognizable instead of random data
would prevent the first attack.

It would not work against the second attack, unless we also had
the group member sign I_r || I_i in the POP instead of I_i || I_r.
So if we decide that we want to defend against both the first and second
attacks by altering the position of the SEQ number, we should also have
the group member sign I_r || I_i in the POP.

> I don't think that Brian's solution of using different keys for signing
> GROUPKEY-PULL (aka REGISTRATION) messages is a bad idea.
> But I wonder if there is a more parsimonious solution.

Brian and I agreed on that, which is why he made that a SHOULD instead
of a MUST.  There was also some concern that not all installations would
have the ability to support two different keys.
So he also included a restriction
on the size of I_r and I_r which would guarantee that they would never
be long enough so that I_r || I_i could be used to spoof a GROUPKEY-PUSH
message.

Cathy

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