[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.
- [Hipsec] existential forgeries and HIP DEX Robert Moskowitz