Subject: [MSEC] GDOI fix

From: "Catherine A. Meadows" <[email-masked]>
Date: Mon, 17 Dec 2001 17:09:19 -0500 (EST)

Hi everybody:

Brian Weis gave a brief account of a possible attack on GDOI that
I had found at the msec
meeting last Friday, along with a fix.  There were more questions about this
than could be answered in such a short time, so I promised to send a more
in-depth account to the list.  

I actually found two attacks.  One relies on more assumptions than the other,
so I will discribe the simpler one first.

ATTACK 1:

There are two places where digital signatures are used in GDOI.  One
is where the GCKS sends the signed GROUPKEY-PUSH message. and the other
is the optional use of Proof-of-Possesion signatures in the GROUPKEY-PULL
protocol, in which member and/or GCKS may sign the concatenation I_i || I_r
where I_i is a nonce supplied by the initiator (the member)
and I_r is a nonce supplied by the responder (the GCKS). 

Under certain circumstances, it is possible for a dishonest group
member to trick a GCKS into signing a bogus GROUPKEY-PUSH message
when it thinks it is signing a POP.  Recall that the GROUPKEY-PUSH message
is of the form:

HDR*, SEQ, SA, KD, [CERT,] SIG

where the signed portion is HDR, SEQ, KD, [CERT]
The format of the KD is not specified, but it is likely to end in
a random number (that is, a key).  So, if the optional CERT is
not included, the signed message is likely to end in a random number.

A dishonest member can use this fact to spoof a GROUPKEY-PUSH message
in the following way, assuming that the following assumptions hold:

A.  The GCKS uses the same signature key to sign both its POP
and the GROUPKEY-PUSH message.

B.  The nonce N_r supplied by the GCKS in the GROUPKEY-PULL protocol
is no longer than the random number that could be found at the end of
a KD.

C.  Even with the above restriction on the length of N_r, the GCKS
will accept an N-i such that the length of N_i || N_r is the same
as that of a possible GROUPKEY-PUSH message.

Then the attack is as follows:

1.  A dishonest group member initiaties a GROUPKEY-PULL protocol,
but the N_i it supplies to the GCKS is of the form

HDR, SEQ, KD'

where KD' is a KD minus a portion at the end whose length is equal to
the N_r supplied by the GCKS.

2.  The GCKS returns a signature SIG on

HDR, SEQ, KD' || N_r

3.  The member encrypts the message and the signature with the current
KEK (which it will know since it is a member of the group), to obtain

HDR* SEQ, KD' || N_r, SIG

and sends it out as a GROUPKEY-PUSH message.

Note that the dishonest member has no control over the last part
of the fake KD, since this is supplied by the GCKS.  However, it would
still be enough to mislead the other group members.

The recommendations Brian had for changes to the document were to 

i.  suggest that GCKS's use different signature keys and/or hash functions
when signing POP's than when signing GROUPKEY-PUSH messages.

ii. put an upper bound on the size of N_i and N_r, so that N_i || N _r
would always be shorter than the shortest possible GROUPKEY-PUSH message.

Mark Baugher also asked if having  the GCKS sign N_r || N_i  (insted of
N_r || N_r) when signing the POP
would prevent the attack.  However, this would not work, because HDR, SEQ, KD
begins, as well as ends, in a random number: the 16-octet SPI.  Thus
the dishonest member could mount the same attack by replacing part or
all of the SPI with N_r instead of part of the KD.

It also occurred to me, after following the discussion on IPSEC, that it
would be possible to foil this attack by requiring POP signatures
to be on the two nonces followed by some short non-random field.  Thus,
POP_I could be over (N_i || N_r || 0 ) and POP_R could be over
(N_i || N_r || 1), although we might want to use different integers
besides 0 and 1, since those are the ones currently being used by JFK.
If we don't want to put a limit on the nonce sizes for whatever reason,
this could be preferable.

__________________________________
ATTACK 2

I also found another attack, which is converse of the one I presented
above.  It requires more assumptions than the first attack, so it is
less of a threat, but I include it because it does not require that much
more (if any) further change to the protocol to protect against it as well.

Suppose that the following assumptions hold:

A'. there is a group
member that is also a GCKS, and that uses the same key for signing
POPs as for signing GROUPKEY-PUSH messages.
B'. a pairwise member/GCKS key is compromised, so that a bad guy is able to
impersonate a GCKS to a member, although it does not know the GCKS's signature
key. 
C'. the N_i generated by the group member/GCKS when it initiates
a GROUPKEY-PULL protocol is no larger than a SPI
D'. Even with the above restriction on the length of N_i, a group member
will accept an N_r such that the length of N_i || N_r is the same
as that of a possible GROUPKEY-PUSH message.

1. The group member, Alice, (who is also a GCKS) initiates a GROUPKEY-PULL protocol
with the bad GCKS.  The bad GCKS, Eve,  sends a nonce N_r of
the form HDR', SEQ, KD  where HDR is is the HDR minus an initial portion
equal in length to the N_i that would be generated by the group member/GCKS.

2. Alice signs the POP  N_i || N_r =
N_i || HDR', SEQ, KD

3.Eve encrypts N_i || HDR', SEQ, KD, SIG with the current KEK, and
is able to pass off the message as a legitimately signed GROUPKEY-PUSH
message.  Note that Eve also has total control over what the KD looks like.

This attack is somewhat less likely than the other one, since it requires
that a principal act both as GCKS and member, and that it use the
same signing key for both roles, and that a pairwise key is compromised.
However, the same restriction on length that prevents the first attack
will also prevent this one.  If we instead wanted to use the option
of including a non-random field in each message, we would have to
either include such a non-random field in the beginning as well as the
end of the message, or reverse the order of N_i and N_r in the POP
message signed by the group member.

Hope that this helps,

Cathy 

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

---

From: Mark Baugher <[email-masked]>
Date: Tue, 18 Dec 2001 10:30:10 -0800

Cathy
   Thanks a lot, this is very helpful.  I am still unclear about the second 
attack.
But before delving into that, I have a couple of questions.  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?  I don't like having this restriction on
the KD payload since attributes are optional by definition.  Second, what
do you think about placing the SEQ after the KD since a message having an
invalid SEQ would be rejected?

   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.

thanks, Mark