Subject: Re: [MSEC] GDOI fix

From: Ran Canetti <[email-masked]>
Date: Wed, 19 Dec 2001 18:19:02 -0500

I'm not sure I completely follow the attack below but in any case I very
much agree with the conclusion - the GROUPKEY-PUSH signature text should 
have a leading identifier also.  (This indeed is in agreement with the
general "design principle".)
 
Please congratualate your protocol analyzer, :)

Ran

> From [email-masked] Wed Dec 19 15:16:05 2001
> 
> Ran:
> 
> Thanks!  It wasn't my catch, though, but the NRL Protocol Analyzer's.
> 
> I agree, prepending a special string to the POP challenge when it
> is signed by the GCKS or by the SPI would work, but only if a different
> special string (such as "push") was prepended to the GROUPKEY-PUSH
> message when it is signed by the GCKS.  That is because the
> signed part of the GROUPKEY-PUSH message is HDR, SEQ, KD,
> and HDR begins in a random number, the SPI, which is supplied
> by the GCKS.  So all a bad guy would have to do to get the GCKS
> to sign a forged GROUPKEY-PUSH message would be to send it an Ni
> of the form HDR, SEQ, KD', where HDR begins in a SPI of the
> form "pop" || random stuff.  The group member who verifies the signature
> presumably is just going to accept that the SPI is random, without
> chcking that it begins with "pop".  If we have the GCKS sign
> "push", HDR, SEQ, KD instead, that will prevent that.
> 
> All in all, I think I like the idea of prepending special fields to all
> signed messages the
> best.  It's easy for the verifier to check for, and if for some reason
> it's necessary to add new signed messages to GDOI, it's easy to prepend
> special strings to them too without having to worry about whether or not
> what you're doing  breaks the defenses against this sort of attack
> that you'd already built into the protocol.
> 
> Cathy
> 

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

---

From: Brian Weis <[email-masked]>
Date: Wed, 19 Dec 2001 17:17:00 -0800

Hi Ran & Cathy,

Thanks for your analysis on finding ways to mitigate the attacks. We
could either prepend or append a string to the POP data as you suggest. 

But prepending won't be possible for the GROUPKEY-PUSH message since the
message must start with a HDR payload, and the HDR is a standard ISAKMP
header. (That would be like adding a string before an IKE message HDR.)
We could however append a specific value to the GROUPKEY-PUSH protocol,
for example at the end of the KD payload.

I assume that it makes no sense to prepend in one case and append in the
other.

So I propose implementing the earlier suggestion of appending a string
to the data signed in the POP:
	(N_i || N_r || "pop")

and adding the following key semantics to the KD payload:

1. Add a new KD payload type in section 5.5:

	    o Key Download (KD) Type (1 octet)  -- Identifier for the Key Data
field of this Key Packet.

                    Key Download Type        Value
                    -----------------        -----
                    RESERVED                   0
                    TEK                        1
                    KEK                        2
                    LKH                        3
                    OFT                        4
                    REKEY_MARKER               5                <-----
NEW
                    RESERVED                  6-127
                    Private Use             128-255

2. Text would be added requiring that the PUSH_MARKER must be the last
key packet in the KD payload.

3. The REKEY_MARKER type has the following attributes:
   a. SPI Size must be 0.
   b. SPI must be 0
   c. Key Packet Attributes must be "rekey".

I don't really like encumbering the KD payload this way, but it does
save the processing of a whole new payload type for the protocol.

Does that sound sufficient?

Thanks,
Brian

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]