Re: [Cfrg] OPAQUE

Yoav Nir <ynir.ietf@gmail.com> Thu, 28 March 2019 05:19 UTC

Return-Path: <ynir.ietf@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 C4246120225 for <cfrg@ietfa.amsl.com>; Wed, 27 Mar 2019 22:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BLGCtnhZq0Z9 for <cfrg@ietfa.amsl.com>; Wed, 27 Mar 2019 22:19:25 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 126271201F3 for <cfrg@irtf.org>; Wed, 27 Mar 2019 22:19:24 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id k17so13226965wrx.10 for <cfrg@irtf.org>; Wed, 27 Mar 2019 22:19:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tdkvTcflrtb4m/hMjq+RWPx6/Re/rsfghIY6XZYHk+c=; b=IGXGH/8J3BmRnWOZf4QLPqggq31VVeJ73Nl9v2vqBaJZQdSzcx9Vidz6mI691TunrD RtOf/cKKNazzwWT4DCsmgnBvlHzHVO2yScqFlnC/wxYoO4L7CZrS1fUPgCsRD1/uYL/D CZ02C+IryrQ9kSRiohOTIyXsQXRrLgLF8ejF+PwMrIM9otZRElipFmD87VrHFt7UnNzW b6o8eL+3YQOpp+5RPaWmhR6tkJS1IPsJShr4HW6njVF6N+nVgS88+nx7igJgK6Q7qAxX 96EjXK9i14AYb/G12eMztNbeklYSX2jJHkEhwIawIIfeEdxrvl/eyC0/+TOL+9JVXtvr UtiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tdkvTcflrtb4m/hMjq+RWPx6/Re/rsfghIY6XZYHk+c=; b=lzomyN5fxbQ7MHjwSUFcFY9DtHQYezjIkHh09b+79x4qD43OGfw8bg0mRDzbyk3y5E TmRwauD5b95PgYr5EdHdPv48YheEYHtYYiwJLwyImsVk2QoMexTefWWXHcFeEub5fylR /ncsbmSUw3S8DwsMxTOiqag53n8mv8Qjp8pYdmpAgX0TkMlSBm9RizGNSnvWODujIi50 z8ltLAeYumIEliBx5AbRNI+FkXjH8LOeLC5g7UoUQ6UtYsdf+b0Kt+8SioL5Ik47F1hX iMhdJnyzuRkq0ZDPI6pmPcU23eTxu5930Gd6l5sHfah0KP4p5kMXL03PfTrhaTec4QrQ Pd6A==
X-Gm-Message-State: APjAAAWlPpeUd1vt/MPXL+tDk/csTscCAXSj3JlGfoS9UEzhT0pBML9P aZ3PMXJAjEHh9FO7Yv8YjW4=
X-Google-Smtp-Source: APXvYqyMluIm35RE2wIANsY9aDnnHR71dfGBj1KsVuqVnIZJU0inlSH8REKOYVRBa3T61dg0oTBfew==
X-Received: by 2002:adf:ed8a:: with SMTP id c10mr8884738wro.40.1553750363441; Wed, 27 Mar 2019 22:19:23 -0700 (PDT)
Received: from [10.31.1.243] (94-74-228-154.client.rionet.cz. [94.74.228.154]) by smtp.gmail.com with ESMTPSA id y5sm21148577wrw.23.2019.03.27.22.19.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 22:19:22 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <56944FD3-D23B-4283-AB3A-E51D89F97B89@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_52CDCA33-2DAF-452B-AD95-17B0591504F3"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Thu, 28 Mar 2019 06:19:21 +0100
In-Reply-To: <fc33f055-0e07-f433-147d-3850fbd42ee7@lounge.org>
Cc: Valery Smyslov <smyslov.ietf@gmail.com>, cfrg@irtf.org
To: Dan Harkins <dharkins@lounge.org>
References: <CACsn0ck_VbSNCDvYQXzuhMLqgO5R_cwPzMaMmQrENdv4D2=UAg@mail.gmail.com> <b0ac5609-6050-9def-fc8e-e23fd5c3177f@lounge.org> <00d301d4e4ba$82febe90$88fc3bb0$@gmail.com> <fc33f055-0e07-f433-147d-3850fbd42ee7@lounge.org>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/-_RKT6s81x8cWn9SMbSzvP6RXGk>
Subject: Re: [Cfrg] OPAQUE
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, 28 Mar 2019 05:19:27 -0000


> On 28 Mar 2019, at 0:05, Dan Harkins <dharkins@lounge.org> wrote:
> 
>  
>  Hi Valery,
> 
> On 3/27/19 9:31 AM, Valery Smyslov wrote:
>> Hi Dan,
>>  
>> it depends. Don't forget about EAP-based authentication in IKEv2,
>> that is clearly client-server oriented.
> 
>   That is true but in that case it would be EAP-OPAQUE which
> is EAP not IPsec.

It could be.  But if we’re able to handle user-chosen passwords well in regular IKEv2, I’d rather not ever bother with embedding EAP in IKEv2.

I think the chances of having strong PSKs in gateway-to-gateway or server-to-server scenarios are far better than the chances of having strong PSKs or passwords for remote access VPNs.  We’re even writing a document to automate that in I2NSF.

So ISTM that IKEv2 should handle both cases with a PAKE, and maybe that means we need both an augmented PAKE and a balanced PAKE. If forced to choose just one, I’d rather solve the problem of weak passwords and use an augmented PAKE.

Yoav