[Cfrg] Integration of OPAQUE in IKEv2
Hugo Krawczyk <hugo@ee.technion.ac.il> Thu, 12 September 2019 01:31 UTC
Return-Path: <hugokraw@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F40D12001A for <cfrg@ietfa.amsl.com>; Wed, 11 Sep 2019 18:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jir_-hVEjOG for <cfrg@ietfa.amsl.com>; Wed, 11 Sep 2019 18:31:07 -0700 (PDT)
Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACC7120013 for <cfrg@ietf.org>; Wed, 11 Sep 2019 18:31:06 -0700 (PDT)
Received: by mail-io1-f43.google.com with SMTP id h144so50548394iof.7 for <cfrg@ietf.org>; Wed, 11 Sep 2019 18:31:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+jZt35LPAFn0wQ+shtw/NeIJDy1hXBQ8LtoVUiWuvno=; b=GBcNPEXGykpp3AUdHgG/RBY8clW5tSVSMqsKFgzhjHbcCIc9YtQt7iTevFdpQP8HAu gnL+V8mdjdBfutOe8csXNJyQgeS+xzSI8ZmsddFJ6j+jV20DutWUZjgKGRC7/lELkAWM Cq2v3cgtK91LXEPyWng8V4fAcpuLGUVApGWm31IHwPHQTUhiGbeEVOHGNx/qeDvtAP81 zJSFZ8KFPeHjYKB+u5P8785AlEJ4AzVc1XU4H1HOEP1GZ3LpasibsF2oLaghikMaJI6z oSGoxhXqITVWe/ytC7Pj4Wv29SZRiFUeUBU1nITB3RcloQABz0gtvjS3QZFO6BhLAiV/ tBEQ==
X-Gm-Message-State: APjAAAUJeZ0u47ZdRjn8bUlWF/hEj9zlxzDrEy19ka+M6Ajct8xHw3i4 P9NWvELvcGJKmX9lcy3V6kkQYBFBLCZFGlqHy4bfc0hC5Eg=
X-Google-Smtp-Source: APXvYqyKCwt/YjWCk7xWrcIeKB5GBmUzR1jv35ewcsL+YgQt+ZEmXnXXxXJrm9jhjOs6Eg/1AALjCC5S6TZkk5L51Rw=
X-Received: by 2002:a6b:784a:: with SMTP id h10mr1321966iop.39.1568251865998; Wed, 11 Sep 2019 18:31:05 -0700 (PDT)
MIME-Version: 1.0
References: <0791DF4A-098E-4753-B886-BFC2D7DA1F97@gmail.com>
In-Reply-To: <0791DF4A-098E-4753-B886-BFC2D7DA1F97@gmail.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Wed, 11 Sep 2019 21:30:42 -0400
Message-ID: <CADi0yUN=+mX80ESTnttgVYk+mT3jTWZ=mcqB28T5YmdRQZ1bhw@mail.gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>, Valery Smyslov <smyslov.ietf@gmail.com>
Cc: "<cfrg@ietf.org>" <cfrg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000642c86059251178f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/7NJgf6Pb3-l_nCEeVw1hexKQHHo>
Subject: [Cfrg] Integration of OPAQUE in IKEv2
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Sep 2019 01:31:10 -0000
Hi Yoav and Valery, thanks for your extensive analysis of the different PAKE candidates. I would like to clarify some issues regarding the way you envision the integration of OPAQUE in the context of IKEv2. Let me first refer to Yoav's analysis https://mailarchive.ietf.org/arch/msg/cfrg/PWhIOQKBHapZ1Rpbd7Brr_JFIg8 where he says: > OPAQUE spends one round-trip on sending IDi and receiving EnvU and vU. > OPAQUE spends another round-trip on the OPRF protocol. > OPAQUE spends yet another round-trip for a KE exchange. > The final IKE_AUTH flow uses the generated key for the AUTH payloads. > Altogether 5 round-trips (or IKE_AUTH exchanges) are needed for user > authentication. This mimics the modular description in the OPAQUE draft that shows the different logical components. However, these components need not be run sequentially but rather in parallel, namely, piggybacking the OPRF to any existing AKE protocol. This is exemplified in the OPAQUE draft for any AKE with 3 flows as follows: Generic OPAQUE with 3-message KE: o C to S: Uid, alpha=H'(PwdU)*g^r, KE1 o S to C: beta=alpha^kU, vU, EnvU, KE2 o C to S: KE3 Thus, one can integrate OPAQUE with IKEv2 at the cost of a single additional message from C to S, and no change to the AUTH mechanics. Here is how it would look (I keep Yoav's notation and add the OPAQUE elements in < ... >). The only changes to regular IKEv2 are piggybacking the elements alpha, beta, vU, EnvU to the existing IKEv2 flows and adding the last client-to-server flow with the AUTH value. User Server ------------------------------------------------------------------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, HDR, SK {IDi, [IDr,] SAi2, TSi, TSr <alpha>} --> <-- HDR, SK {IDr, AUTH, <beta, vU, EnvU>} HDR, AUTH --> Server's AUTH needs no change, except that the signature is computed with the server's key authenticated under EnvU, and client's AUTH in the added flow is computed under the user's key under EnvU. The first two flows don't change (except maybe for a HDR type indicating password authentication). The value IDi is used to transfer user's account information (whose privacy is protected against passive adversaries by virtue of the DH exchange (KEi, KEr)). As you can see, my depiction above is quite similar to the way Valery Smyslov https://datatracker.ietf.org/doc/html/draft-smyslov-ikev2-pake integrates OPAQUE with IKEv2, with two notable differences. Valery's version (top of page 10 in the draft) takes three round trips (instead of 2.5) as he delays the server's AUTH to an additional sixth flow. In contrast, I include this information in the fourth flow. More significantly, Valery re-defines the AUTH values as AUTHi = sig(PrivU, <InitiatorSignedOctets>) AUTHr = sig(PrivS, <ResponderSignedOctets>) This is not necessary. One can keep IKEv2's AUTH unchanged (as I said, only the public keys change from certificate-based to EnvU-based). Actually, defining AUTH i/r as above would not be secure (it departs from the necessary logic of SIGMA-R underlying IKEv2). Finally, responding to one of the points of Yoav, the password registration procedure only takes 3 flows (C to S, S to C, C to S). The common point to the above comments is that integrating OPAQUE into an existing protocol should be quite painless. You just need to piggyback the two OPRF messages and EnvU to the existing key exchange flows. Assuming extensibility of the protocol to accommodate the above elements, the cost would be at most one additional flow for user's explicit authentication. Computation-wise it's just one exponentiation for the server and two for the client (with one or both of these exponentiations using a fixed base), plus a hash into the curve by the client. Let me know if the above makes sense to you and whether I missed something significant about the way IKEv2 works. Thanks again! Hugo >
- [Cfrg] Review of the PAKE proposals Yoav Nir
- [Cfrg] Integration of OPAQUE in IKEv2 Hugo Krawczyk
- Re: [Cfrg] Integration of OPAQUE in IKEv2 Valery Smyslov
- Re: [Cfrg] Integration of OPAQUE in IKEv2 Hugo Krawczyk
- Re: [Cfrg] Integration of OPAQUE in IKEv2 Yoav Nir
- [Cfrg] Review of the Balanced PAKE proposals Karthik Bhargavan
- Re: [Cfrg] Review of the Balanced PAKE proposals Hao, Feng