Subject: RE: [MSEC] GDOI fix

From: "David A. Mcgrew" <[email-masked]>
Date: Thu, 3 Jan 2002 05:08:30 -0800

Ran, Cathy,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ran Canetti
> Sent: Wednesday, December 19, 2001 11:47 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [MSEC] GDOI fix
>
>
>
>
> Hi Cathy,  Good catch!
> These are indeed potentially bad attacks.
>
> Fortunately, they are easy to thwart, as you noted in your mail:
>
> >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.
>
> I agree - all that has to be done is when the GCKS signs a POP challenge,
> it should add to the signed text a reserved string that is
> interpreted as the
> message "this is a signature on a POP challenge".
> This way, the POP signatures will be worthless as GROUPKEY-PUSH signatures
> and the attacks will be thwarted.  I'd suggest though that:
> -The special string will be prepended rahter than appended, to avoid
> potential decoding ambiguities.
> -The special string be a bit more distinctive, again to avoid mistakes.
> How about, say, the string "POP" in ascii.
>
>
> (A general lesson for us in protocol design: When using a signature in a
> protocol, make sure to add a special string that ties the signature to its
> particular use in the protocol.)

right, I agree that what we have here is a test case for a fundamental law,
so to speak. "Each use of an authentication key to protect data within a
protocol MUST protect the information about the type of data and/or how to
decode that data."  Any chance that the protocol analyzer can help elucidate
such rules for us?

This principle applies to other crypto services as well.  Clearly symmetric
authentication can be undermined if a message of type A can be substituted
for a message of type B without detection, and the same for non-repudiation.
I'm not sure if a similar principle applies for confidentiality.  It might
provide strength against chosen ciphertext/plaintext attacks, but I'm not
sure that it's really necessary.

Encodings in crypto protocols are an interesting topic, Manger's attack on
OAEP implementations (which works by causing a failure in the
integer-to-octet conversion) being a fun example of the problems a protocol
designer can get into.

David
[email-masked]

>
> (A first place to implement the above lesson: Add a similar string also
> to the POP signature by the group member.)
>
>
> Ran
>
>
> _______________________________________________
> msec mailing list
> [email-masked]
> http://www.pairlist.net/mailman/listinfo/msec

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