Subject: [Cfrg] Fwd: New Version Notification for draft-krawczyk-cfrg-opaque-06.txt

From: Hugo Krawczyk <[email-masked]>
Date: Sat, 20 Jun 2020 00:25:05 -0400

A new version of draft-krawczyk-cfrg-opaque is available.
It has an important change in the way secret information under the
envelope EnvU is protected.

There is no form of optional encryption or use of counter mode anymore.
Instead it defines a very specific mechanism:
Secret information included in EnvU is xor-ed with a pseudo random
pad derived from RwdU, and HMAC is computed on the concatenation of this
value
and any non-secret information included in EnvU. This simple mechanism
satisfies the encryption requirement of OPAQUE and obviates any need to
specify
other RKR-secure schemes. In particular, it eliminates the "temptation" to
use
non-RKR modes such as GCM. Performance considerations are insignificant
here as
EnvU requires encryption of very short plaintexts. Applications that require
sending additional information (e.g., non-OPAQUE user secrets stored at the
server) will use ExportKey (previously called KdKey) with any encryption
scheme of their choice. No RKR requirement in this case.
See Section 4 for the details.

This version also corrects a typo in the specification of SIGMA (the
identities
in messages K2 and K3 got mixed up in the version 05 of the draft).

Very important: This draft is still intended as a high level description of
the
protocol and its components. A detailed specification is underway and will
be
posted shortly as draft-irtf-cfrg-opaque. OPAQUE implementers should follow
the specifications in that document.

Hugo

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sat, Jun 20, 2020 at 12:20 AM
Subject: New Version Notification for draft-krawczyk-cfrg-opaque-06.txt
To: Hugo Krawczyk <[email-masked]>

A new version of I-D, draft-krawczyk-cfrg-opaque-06.txt
has been successfully submitted by Hugo Krawczyk and posted to the
IETF repository.

Name:           draft-krawczyk-cfrg-opaque
Revision:       06
Title:          The OPAQUE Asymmetric PAKE Protocol
Document date:  2020-06-19
Group:          Individual Submission
Pages:          26
URL:
https://www.ietf.org/internet-drafts/draft-krawczyk-cfrg-opaque-06.txt
Status:         https://datatracker.ietf.org/doc/draft-krawczyk-cfrg-opaque/
Htmlized:       https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-06
Htmlized:
https://datatracker.ietf.org/doc/html/draft-krawczyk-cfrg-opaque
Diff:
https://www.ietf.org/rfcdiff?url2=draft-krawczyk-cfrg-opaque-06

Abstract:
   This draft describes the OPAQUE protocol, a secure asymmetric
   password authenticated key exchange (aPAKE) that supports mutual
   authentication in a client-server setting without reliance on PKI and
   with security against pre-computation attacks upon server compromise.
   Prior aPAKE protocols did not use salt and if they did, the salt was
   transmitted in the clear from server to user allowing for the
   building of targeted pre-computed dictionaries.  OPAQUE security has
   been proven by Jarecki et al.  (Eurocrypt 2018) in a strong and
   universally composable formal model of aPAKE security.  In addition,
   the protocol provides forward secrecy and the ability to hide the
   password from the server even during password registration.

   Strong security, versatility through modularity, good performance,
   and an array of additional features make OPAQUE a natural candidate
   for practical use and for adoption as a standard.  To this end, this
   draft presents several instantiations of OPAQUE and ways of
   integrating OPAQUE with TLS.

   This draft presents a high-level description of OPAQUE, highlighting
   its components and modular design.  It also provides the basis for a
   specification for standardization but a detailed specification ready
   for implementation is beyond the scope of this document.

   Implementers of OPAQUE should ONLY follow the precise specification
   in the upcoming draft-irtf-cfrg-opaque.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat