Skip to content

Commit

Permalink
Fixes
Browse files Browse the repository at this point in the history
  • Loading branch information
@grittygrease
grittygrease committed Mar 11, 2019
1 parent 18e085f commit 42a928c
Showing 1 changed file with 81 additions and 69 deletions.
150 changes: 81 additions & 69 deletions draft-sullivan-tls-opaque.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ author:
ins: H. Krawczyk
name: Hugo Krawczyk
organization: IBM Research
email: [email protected]
email: [email protected]
-
ins: O. Friel
name: Owen Friel
Expand Down Expand Up @@ -75,7 +75,7 @@ password-authenticated key exchange in TLS 1.3.
Note that this draft has not received significant security review and should not be the basis for production systems.

OPAQUE [opaque-paper] is a mutual authentication method that enables the establishment of an authenticated cryptographic key between a client and server based on a user's
memorized password, without ever exposing the password to servers or other entities other than the client machine and without relying on PKI. OPAQUE leverages a primitive called a Strong Asymmetrical Password Authenticated Key Exchange (Strong aPAKE) to provide desirable properties including resistance to precomputation attacks in the event of a server compromise.
memorized password, without ever exposing the password to servers or other entities other than the client machine and without relying on PKI. OPAQUE leverages a primitive called a Strong Asymmetrical Password Authenticated Key Exchange (Strong aPAKE) to provide desirable properties including resistance to pre-computation attacks in the event of a server compromise.

In some cases, it is desirable to combine password-based authentication with traditional PKI-based authentication as a defense-in-depth measure. For example, in the case of IoT devices, it may be useful to validate that both parties were issued a certificate from a certain manufacturer. Another desirable property for password-based authentication systems is the ability to hide the client’s identity from the network. This document describes the use of OPAQUE in TLS 1.3 {{!TLS13=RFC8446}} both as part of the TLS handshake and post-handshake facilitated by Exported Authenticators {{!I-D.ietf-tls-exported-authenticator}}, how the different approaches satisfy the above properties and the trade-offs associated with each design.

Expand All @@ -90,9 +90,9 @@ when, and only when, they appear in all capitals, as shown here.

# OPAQUE

In OPAQUE [opaque-paper], it is shown that a Strong Asymmetric Password-Authenticated Key Exchange (Strong aPAKE) can be constructed given an oblivious pseudo-random function (OPRF) and authenticated key exchange protocol that is secure against reverse impersonation (a.k.a. KCI). Unlike previous PAKE methods such as SRP {{?RFC2945}} and SPAKE-2 {?I-D.irtf-cfrg-spake2}}, which require a public salt value, a Strong aPAKE leverages the OPRF private key as salt, making it resistant to precomputation attacks on the password database stored on the server.
In OPAQUE [opaque-paper], it is shown that a Strong Asymmetric Password-Authenticated Key Exchange (Strong aPAKE) can be constructed given an oblivious pseudo-random function (OPRF) and authenticated key exchange protocol that is secure against reverse impersonation (a.k.a. KCI). Unlike previous PAKE methods such as SRP {{?RFC2945}} and SPAKE-2 {{?I-D.irtf-cfrg-spake2}}, which require a public salt value, a Strong aPAKE leverages the OPRF private key as salt, making it resistant to pre-computation attacks on the password database stored on the server.

TLS 1.3 provides a KCI-secure key agreement algorithm suitable for use with OPAQUE. This document describes three instantiations of OPAQUE in TLS 1.3: one based on digital signatures, one on Diffie Hellman key agreement, and one based on HMQV key exchange. Of the three instantiations, the only one that has known IPR considerations is HMQV.
TLS 1.3 provides a KCI-secure key agreement algorithm suitable for use with OPAQUE. This document describes three instantiations of OPAQUE in TLS 1.3: one based on digital signatures, one on Diffie-Hellman key agreement, and one based on HMQV key exchange. Of the three instantiations, the only one that has known IPR considerations is HMQV.

OPAQUE consists of two distinct phases: password registration and authentication. We will describe the mechanisms for password registration in this document but it is assumed to have been done outside of TLS. During password registration, the client and server establish a shared set of parameters for future authentication and two private-public key pairs are generated, one for the client and one for the server. The server keeps its private key and stores an encapsulated copy of the client’s key pair along with its own public key in an “envelope” that is encrypted with the result of the OPRF operation. Note that it is possible for the server to use the same key for multiple clients. It may be necessary to permit multiple simultaneous server keys in the even of a key rollover. The client does not store any state nor any PKI information.

Expand Down Expand Up @@ -146,46 +146,47 @@ We define several TLS extensions to signal support for OPAQUE and transport the
This document defines the following extension code points.

~~~~~~~~~~
enum {
...
opaque_client_auth(TBD),
opaque_server_auth(TBD),
(65535)
} ExtensionType;
enum {
...
opaque_client_auth(TBD),
opaque_server_auth(TBD),
(65535)
} ExtensionType;
~~~~~~~~~~

The opaque_client_auth extension contains a PAKEClientAuthExtension struct and can only be included in the CertificateRequest and Certificate messages. The opaque_client_auth extensioncontains a PAKEServerAuthExtension struct and can only be included in the ClientHello, EncryptedExtensions, CertificateRequest and Certificate messages, depending on the type.
The opaque_client_auth extension contains a PAKEClientAuthExtension struct and can only be included in the CertificateRequest and Certificate messages. The opaque_client_auth extension contains a PAKEServerAuthExtension struct and can only be included in the ClientHello, EncryptedExtensions, CertificateRequest and Certificate messages, depending on the type.

The structures contained in this extension are defined as:

~~~~~~~~~~
struct {
opaque identity<0..2^16-1>;
opaque OPRF_1<1..2^16-1>;
} PAKEShareClient;
opaque identity<0..2^16-1>;
opaque OPRF_1<1..2^16-1>;
} PAKEShareClient;
~~~~~~~~~~

~~~~~~~~~~
struct {
opaque identity<0..2^16-1>;
opaque OPRF_2<1..2^16-1>;
opaque vU<1..2^16-1>;
opaque EnvU<1..2^16-1>;
} PAKEShareServer;

struct {
select (Handshake.msg_type) {
ClientHello:
PAKEShareClient client_shares<0..2^16-1>;
OPAQUEType types<0..2^16-1>;
EncryptedExtensions, Certificate:
PAKEShareServer server_share;
OPAQUEType type;
}
} PAKEServerAuthExtension;

struct {
opaque identity<0..2^16-1>;
opaque OPRF_2<1..2^16-1>;
opaque vU<1..2^16-1>
opaque EnvU<1..2^16-1>;
} PAKEShareServer;

struct {
select (Handshake.msg_type) {
ClientHello:
PAKEShareClient client_shares<0..2^16-1>;
OPAQUEType types<0..2^16-1>;
EncryptedExtensions, Certificate:
PAKEShareServer server_share;
OPAQUEType type
}
} PAKEServerAuthExtension;

struct {
opaque identity<0..2^16-1>;
} PAKEClientAuthExtension;
opaque identity<0..2^16-1>;
} PAKEClientAuthExtension;
~~~~~~~~~~

This document also defines the following set of types;
Expand All @@ -197,29 +198,29 @@ This document also defines the following set of types;
OPAQUE-3DH-Cert(3),
OPAQUE-HMQV(4),
OPAQUE-HMQV-Cert(5),
} OPAQUEType;
} OPAQUEType;
~~~~~~~~~~

The `identity` field is the unique user id used to index the user’s record on the server. The types field indicates the set of supported auth types by the client. The OPRF_1 message is as defined in Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups [I-D.sullivan-cfrg-voprf]. The content of OPRF_1 is typically the result of the password hashed into a group element and blinded by an element known to the client. OPRF_2 is the OPRF_1 value operated on by the OPRF private key kU. vU is the public component of kU and EnvU is the envelope containing PrivU, PubS, and PubU. (Note that for groups, it may be more space efficient to only include PrivU and have the client derive PubU from PrivU). See {{example-oprf}} for details.

This document also describes a new CertificateEntry structure that corresponds to an authentication via a signature derived using OPAQUE. This structure serves as a placeholder for the PAKEServerAuthExtension extension.

~~~~~~~~~~
struct {
select (certificate_type) {
case OPAQUESign:
/* Defined in this document */
opaque null<0>

case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;

case X509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
struct {
select (certificate_type) {
case OPAQUESign:
/* Defined in this document */
opaque null<0>

case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;

case X509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
~~~~~~~~~~

We request that IANA add an additional type to the “TLS Certificate Types” registry for this OPAQUESign.
Expand All @@ -241,25 +242,35 @@ Upon receiving a PAKEServerAuth extension, the server checks to see if it has a
Given a matching key_share and an identity with a matching supported_group, the server returns its PAKEServerAuth as an extension to its EncryptedExtensions. Both parties then derive a shared OPAQUE key using

HMQV

~~~~~~~~~~~
C computes K = (g^y * PubS^e)^{x + d*PrivU)
S computes K = (g^x * PubU^d)^{y + e*PrivS

~~~~~~~~~~~
where d = H(g^x, IdS) and e = H(g^y, IdU), and IdU, IdS represent the
identities of user (sent as identity in PAKEShareClient) and server (EncryptedExtension or Certificate message). TODO: be more explicit about content of IdS.

3DH

~~~~~~~~~~~
C computes K = H(g^y ^ PrivU || PubU ^ x || PubS ^ PrivU || IdU || IdS )
S computes K = H(g^x ^ PrivS || PubS ^ y || PubU ^ PrivS || IdU || IdS )
~~~~~~~~~~~
IdU, IdS represent the identities of user (sent as identity in PAKEShareClient) and server (Certificate message).

H is the HKDF function agreed upon in the TLS handshake.

The result, K, is then added as an input to the Master Secret in place of the 0 value defined in TLS 1.3:

~~~~~~~~~~~
0 -> HKDF-Extract = Master Secret
~~~~~~~~~~~

becomes
K -> HKDF-Extract = Master Secret

~~~~~~~~~~~
K -> HKDF-Extract = Master Secret
~~~~~~~~~~~

In this construction, the finished messages cannot be validated unless the OPAQUE computation was done correctly on both sides, authenticating both client and server.

Expand All @@ -275,20 +286,20 @@ Upon receiving a PAKEServerAuth extension, the server checks to see if it has a
We define a new Certificate message type for an OPAQUE-Sign authenticated handshake.

~~~~~~~~~~
enum {
X509(0),
RawPublicKey(2),
OPAQUE-Sign(3),
(255)
} CertificateType;
enum {
X509(0),
RawPublicKey(2),
OPAQUE-Sign(3),
(255)
} CertificateType;
~~~~~~~~~~

Certificates of this type have CertificateEntry structs of the form:

~~~~~~~~~~
struct {
Extension extensions<0..2^16-1>;
} CertificateEntry;
struct {
Extension extensions<0..2^16-1>;
} CertificateEntry;
~~~~~~~~~~

Given a matching signature_scheme and an identity with a matching key type, the server returns a certificate message with type OPAQUE-Sign with PAKEServerAuth as an extension. The private key used in the CertificateVerify message is set to PrivS, and the client verifies it using PubS.
Expand Down Expand Up @@ -345,14 +356,15 @@ Let p be the prime order of the base field of the curve that is used (e.g. 2^256

1. r <-$ GF(p)
2. M := rH_1(P)
hash-to-curve(P) =
a. t1 = H("h2c" || label || I2OSP(len(x), 4) || P)
b. t2 = OS2IP(t1)
c. y = t^2 mod p
d. H_1(P) = map2curve_simple_swu(y)
e. M = rH_1(P)
3. Output (r, M)

H_1 = hash-to-curve(P) =
1. t1 = H("h2c" || label || I2OSP(len(x), 4) || P)
2. t2 = OS2IP(t1)
3. y = t^2 mod p
4. H_1(P) = map2curve_simple_swu(y)
5. M = rH_1(P)

The client keeps the blind r, and sends the OPRF_1 value M as an EllipticCurve point {{!TLS13}}.

## OPRF_2
Expand All @@ -366,8 +378,8 @@ The output Z of OPRF_2 is sent as an EllipticCurve point `[]` back to the client

When the client receives the output of OPRF_2, it derives the envelope decryption key using OPRF_Unblind followed by OPRF_Finalize.

1. N := (1/r)Z (OPRF_Unblind)
2. y := H_2(P, N) (OPRF_Finalize).
1. N := (1/r)Z (OPRF_Unblind)
2. y := H_2(P, N) (OPRF_Finalize).
Here, we require that N is serialized before it is input to H_2. The client can now stores (P, y) for future usage.


Expand Down

0 comments on commit 42a928c

Please sign in to comment.