Re: [IPsec] PAKE selection: PACE

"Dan Harkins" <dharkins@lounge.org> Wed, 26 May 2010 17:29 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED5D3A67A6 for <ipsec@core3.amsl.com>; Wed, 26 May 2010 10:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.558
X-Spam-Level:
X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 xeTJtbZBYLCz for <ipsec@core3.amsl.com>; Wed, 26 May 2010 10:29:54 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id B1AC23A6979 for <ipsec@ietf.org>; Wed, 26 May 2010 10:29:54 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 88F7B1022404C; Wed, 26 May 2010 10:29:45 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 26 May 2010 10:29:46 -0700 (PDT)
Message-ID: <8a7891f3e8674b766ae45a2c51ed1578.squirrel@www.trepanning.net>
In-Reply-To: <201005261337.14090.dennis.kuegler@bsi.bund.de>
References: <201005261337.14090.dennis.kuegler@bsi.bund.de>
Date: Wed, 26 May 2010 10:29:46 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Dennis Kügler <dennis.kuegler@bsi.bund.de>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] PAKE selection: PACE
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 17:29:55 -0000

  Hi Dennis,

  I have read the PACE submission. I believe claim 1 of the SPEKE patent,
US 6,792,533, covers this protocol. If you do think otherwise, please
explain why.

  Also, in PACE you compute CIPH=E(Pwd, s) where E() is the encryption
function of some block cipher and Pwd is the shared password. You don't
mention the block cipher but some block ciphers have weak keys and most
take a fixed-length key. For a general specification like this I suggest
strengthening it by removing any kind of dependencies and also to bind
the parties to the exchange. I suggest using an "extraction" function with
the shared password and the identities of the two peers to distill the
entropy from the password, bind the identities, and derive a key with
which to do the encryption:

   k = Extractor(Pwd | max(ID-A, ID-B) | min(ID-A, ID-B))
   CIPH = E(k, s)

where max(x,y) and min(x,y) output an ordering their inputs in some
deterministic fashion, ID-A and ID-B are the identities of the two parties
to the exchange, and "|" is concatenation.

  regards,

  Dan.

On Wed, May 26, 2010 4:37 am, Dennis Kügler wrote:
> The evaluation of the PACE proposal according to the criteria draft is
> already
> contained in the draft itself
> (http://www.ietf.org/id/draft-kuegler-ipsecme-pace-ikev2-00.txt) for
> completeness and for convenience you'll find a copy below.
>
> PACE was designed to avoid existing patents (and is not patented) and to
> allow
> for implementations without any cryptographic restrictions other than that
> the primitives have to be secure on their own. A proof of the security of
> the
> protocol is available.
>
> PACE is currently used and standardized in the context of contactless
> smartcards, especially for electronic passports and ID-cards. The OpenPACE
> project also provides a patch to implement PACE on top of OpenSSL.
>
> Best regards,
>
> Dennis
>
>
>    SEC1:   PACE is a zero knowledge protocol.
>    SEC2:   The protocol supports perfect forward secrecy and is
>            resistant to replay attacks.
>    SEC3:   The identity protection provided by IKEv2 remains unchanged.
>    SEC4:   Any cryptographically secure Diffie-Hellman group can be
>            used.
>    SEC5:   The protocol is proven secure in the Bellare-Pointcheval-
>            Rogaway model.
>    SEC6:   Strong session keys are generated.
>    SEC7:   A transform of the password can be used instead of the
>            password itself.
>
>    IPR1:   The first draft of [TR03110] was published on May 21, 2007.
>    IPR2:   BSI has developed PACE aiming to be free of patents. BSI has
>            not applied for a patent on PACE.
>    IPR3:   The protocol itself is believed to be free of IPR.
>
>    MISC1:  One additional exchange is required.
>    MISC2:  The protocol requires the following operations per entity:
>            o  one key derivation from the password,
>            o  one symmetric encryption or decryption,
>            o  one multi-exponentiation for the mapping,
>            o  one exponentiation for the key pair generation,
>            o  one exponentiation for the shared secret calculation, and
>            o  two symmetric authentications (generation & verification).
>    MISC3:  The performance is independent of the type/size of password.
>    MISC4:  Internationalization of character-based passwords is
>            supported.
>    MISC5:  The protocol uses the same group as negotiated for IKEv2.
>    MISC6:  The protocol fits into the request/response nature of IKE.
>    MISC7:  The password-based symmetric encryption must be additionally
>            negotiated.
>    MISC8:  Neither trusted third parties nor clock synchronization are
>            required.
>    MISC9:  Only general cryptographic primitives are required.
>    MISC10: Any secure variant of Diffie Hellman (e.g. standard or
>            Elliptic Curve) can be used.
>    MISC11: The protocol can be implemented easily based on existing
>            cryptographic primitives.
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>