[Hipsec] existential forgeries and HIP DEX

Robert Moskowitz <rgm@htt-consult.com> Mon, 07 June 2010 20:20 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B443A67C0 for <hipsec@core3.amsl.com>; Mon, 7 Jun 2010 13:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_17=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_75=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1tnPNXjdd85 for <hipsec@core3.amsl.com>; Mon, 7 Jun 2010 13:20:53 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 1D53D3A65A6 for <hipsec@ietf.org>; Mon, 7 Jun 2010 13:20:52 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id F17BA68B64 for <hipsec@ietf.org>; Mon, 7 Jun 2010 20:13:24 +0000 (UTC)
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuxiZRTk4buY for <hipsec@ietf.org>; Mon, 7 Jun 2010 16:13:14 -0400 (EDT)
Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id B2B6268B21 for <hipsec@ietf.org>; Mon, 7 Jun 2010 16:13:14 -0400 (EDT)
Message-ID: <4C0D5491.6080406@htt-consult.com>
Date: Mon, 07 Jun 2010 16:20:33 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4
MIME-Version: 1.0
To: HIP WG <hipsec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Hipsec] existential forgeries and HIP DEX
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jun 2010 20:20:54 -0000

I am working out a challenge in HIP DEX on the cfrg list....

Note that HIP DEX does NOT have a cryptographic hash function.  It's 
goal is to succeed with only a CMAC primative for all message reduction 
needs.

http://www.ietf.org/id/draft-mcgrew-fundamental-ecc-03.txt explains that 
a cryptographic hash is needed on the message before signing to avoid an 
existential forgery.  Huh what is that?  So a little searching gets the 
definition where Malice can generate the same signature as Bob, using 
only the public key.

At first blush, that does not seem to be an issue here, because R1, I2, 
and R2 are always signed, so what if Malice could have generated them too?

Then I realized that with existential forgeries, the signature, by 
itself, cannot be trusted to prove ownership of the private key.  More 
is needed.  That *more* could be proof of using the private key, eg 
decrypting a secret encrypted with the public key.  So I worked out the 
following R1through R2 exchange:

Bob or 
Malice                                                                
Alice or Malice2

  Sign (Bob's PK, stuff)  -------->
<----------- Sign(Alice's PK, (stuff, Encrypt(Bob's PK, secret), 
MAC(secret))
Bob only                                                                 
     Alice Only
  Sign (Bob's PK, (stuff, Encrypt(Alice's PK, secret2), MAC(secret))  
-------->
<-----------     Encrypt (secret|secret2, data)  -------->

This is the best I have done (so far).  It deviates from BEX in that the 
final keying material is NOT available in I2, only in R2.  This means 
that KEYMAT needs to be run twice.  A 'special' run for I2 and R2, then 
the 'real' run for all subsequent packets.

This DOES simplify getting keying material from the Responder.  I was 
doing it optionally in R1, when the Responder had I's PK in an ACL or 
some other source.  This is cleaner.