[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Regarding Bill's draft... another Bill's open issues with

-----BEGIN PGP SIGNED MESSAGE-----

content-type: text/plain; charset=us-ascii

   > From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
   >    More importantly, the attack requires a large number of different
   >    chosen-messages.  Since it is not possible for an attacker to "choose"
   >    the parameters being verified, this attack is impossible.
   >
   > That's not at all clear to me.  In particular, it seems that in a
   > system using per-user or per-transport-connection SPI's, an active
   > attacker could easily induce a system to create large numbers of SPI's
   > with a third party, each having similar, but not identical parameters.
   >
   I am not following you; since it's apparently easy, please give a
   concrete example of such an exchange.

Ok.  Here's an abstract overview.  If this is too abstract for you,
I'll refine this into something more concrete.

Assume that there's a replicated service which we wish to attack:

	client  <---->  server A   <----->  server B

Assume that we are a legitimate client of this replicated service, but
are only authorized to change a few things in the service's database.

As a legitimate user of this service, we can tweak its database at one
site; that site will then "push" our changes to the other sites, and
we can then snoop on the network traffic that results.

Assume the service is implemented on a set of hosts which implement
per-transport-connection SPI's, and the replicas only keep connections
open when they have a change to propagate between the replicas.

Then, each replication "push" will occur on a separate SPI, and a
change-message exchange will occur prior to each push and subsequent
to each push to set up and then tear down the new SPI.

Thus, as I said earlier, we can induce a system to create and destroy
a large number of SPI's with a third party to provide us with a large
number of chances to attack the hash function used to validate the
Photuris change_message protocol.

   > I'm sorry, but a keyed hash and a hash over a key and some other data
   > are *NOT* necessarily the same thing.  Hash(concat(key,data,key)) is just 
     one
   > way to implement a keyed hash -- it's not necessarily the *best* way.
   >
   Never-the-less, it is _one_ way, and at this time is the one with field
   experience and both qualitative and quantitative analysis.

I'm not saying "change the bit level encoding".  I'm saying "move the
abstraction boundary" -- at the layer within Photuris where you
dispatch to a particular keyed hash algorithm, keep the key separate
from the data; under the covers, it can combine it exactly as it's
specified in photuris-09, or in a new way.

   And I don't understand your latter assertion, as Photuris has clear and
   clean extension mechanisms.

Maybe to you; I had difficulty figuring out from photuris-09 where the
abstraction boundary was between the various transforms and their
uses.

   > Why?  That's exactly what photuris is doing today! It's doing a keyed
   > hash using the shared secret as the "key" and other fields as the
   > "data".
   >
   I don't see any "data" or "hash" in your suggestion.  If you are
   suggesting that Photuris use the same method that it does today, then we
   are in complete agreement.

Here is a concrete suggested wording change to address the primary problem.  
If you accept this change (which I doubt), I'll supply wording to fix up the
other places which use hash(concat(key,data,key))

Change 6.1.7 to the following text:

6.1.7.  Integrity Verification

   This message is authenticated using the Validity-Method indicated by
   the current Scheme-Choice.  It is separate from any authentication
   specified for Security Associations (see "Exchange Scheme List").

   The Verification field is calculated using the specified
   Validity-Method keyed hash, given the computed shared secret
   as a key, and the following concatenated values as the input data:

    + the Initiator Cookie,
    + the Responder Cookie,
    + the SPI Owner (receiver) Identity Verification,
    + the SPI User (sender) Identity Verification,
    + the Type, LifeTime and SPI,
    + the Attribute-Choices following the Verification field,

   Note that the order of the Identity Verification fields is different
   in each direction.

   If the verification fails, the users are notified, and a Photuris
   Error_Message (Type 7, Code 3) is sent, without adding or deleting
   any Security Associations.  On success, normal operation begins with
   the authentication and/or encryption of user datagrams.

Add section 6.1.8:

6.1.8.  Validity Methods
   Each exchange scheme specifies a particular validity method to use
   to authenticate subsequent change_message packets.

   Validity Methods are keyed hash functions, supplied with two
   inputs:
	a key			(a sequence of bytes)
	the data to be hashed	(a sequence of bytes)

   They produce a single output: 

	a hash value (a multiple precision integer)

   It should be infeasible to determine the value of the key
   given a large number of (data, hash) pairs.

- ---
Change the paragraph of Section 9.5 starting with "Validity Method"
to:
- ----

Validity-Method

      When specified as a Validity-Method, an MD5 hash is calculated
      over the concatenation of
	the supplied key
	the supplied data
	the supplied key again.

      Neither occurance of the key is padded to any particular
      alignment.

      The resulting Verification field is 128-bits (18 octets including
      Size).




-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMS5WVFpj/0M1dMJ/AQGoVQP8CCSX5ZoF55MLk16rj8eV3CwjGZvk4ZoK
871e1hLoHz4HN6M7cY1LWS+LfBrYZ/Ep1uNucTr7LVsLheWiUFIk67RJm6GJTdks
+FqsZ+JrqAwmXE7XVboTmhXkyywK710XSQmjrl8OlUUHuaf5jD7alSpwXBBVgOvZ
7y6wtNMIQ7E=
=biCa
-----END PGP SIGNATURE-----
References: