Merge pull request #178 from maxyakimakha/spake2

Authentication via SPAKE2

index.bs

@@ -439,103 +439,67 @@ pre-shared key (PSK) ease of input for the user and supported PSK input methods.
 The agent with the lowest PSK ease of input presents a PSK to the user when the agent
 either sends or receives an authentication request.  In case both agents have the same
 PSK ease of input value, the server presents the PSK to the user.  The same pre-shared key
-is used by both agents to issue an authentication request.
+is used by both agents.  The agent presenting the PSK to the user is the PSK presenter,
+the agent requiring the user to input the PSK is the PSK consumer.
 
 PSK ease of input is an integer in the range from 0 to 100 inclusive, where 0 means
 it is not possible for the user to input PSK on this device and 100 means
 that it's easy for the user to input PSK on the device.  Supported PSK input methods
 are numeric and scanning a QR-code.  Devices with non-zero PSK ease of input must
 support the numeric PSK input method.
 
-In order for one agent (the challenger) to authenticate another (the responder),
-the challenger may send an authentication-request message and expect an
-authentication-response message to be sent back from the responder.  To
-mutually authenticate, this mechanism is used twice, once by each side acting as
-the challenger.  This mechanism assumes the agents share a low-entropy secret,
-such as a number or a short password that could be entered by a user on a
-keyboard or TV remote control.
-
-For all messages and objects defined in this section, see Appendix A for the full
-CDDL definitions.
-
-The challenger sends an auth-request-hkdf-scrypt-psk message with the following values:
-
--   salt: 32 random bytes.  This salt is used in HKDF, so see
-    https://tools.ietf.org/html/rfc5869#section-3.1 for more details on how this
-    value should be generated.
-
--   cost: log base 2 of the cost parameter (N) for scrypt defined in [RFC
-    7914 section 2](https://tools.ietf.org/html/rfc7914#section-2).  It must be
-    greater than or equal to 14 (to avoid being too weak) and less than or equal
-    to 128 (the limit defined by scrypt).  A value of 15 is recommended (an
-    scrypt N of 2^15 or 32768).
-
-The responder replies with an auth-response-hkdf-scrypt-psk-result message with
-the following values:
-
--   result:  If the responder was able to calculate proof of possession of the
-    shared secret, and if it failed, why it failed.
-
--   proof: The result of running the authentication mechanism.  The steps for
-    hkdf-of-scrypt-of-psk are described below.
+For all messages and objects defined in this section, see Appendix A for
+the full CDDL definitions.
 
-The challenger verifies the proof and sends the responder an auth-status message
-with the following values:
+The default authentication method is
+\[SPAKE2](https://tools.ietf.org/html/draft-irtf-cfrg-spake2-08) with
+the following cipher suite:
 
--   result:  If the challenger was able to authenticate the responder or not,
-    and if not, why not.
+1. Elliptic curve is [Curve25519](https://tools.ietf.org/html/rfc7748#page-4).
+2. Hash function is \[SHA-512](https://tools.ietf.org/html/rfc6234).
+3. Key derivation function is \[HKDF](https://tools.ietf.org/html/rfc5869).
+4. Message authentication code is \[HMAC](https://tools.ietf.org/html/rfc2104).
+5. Password hash function is SHA-512.
 
-The challenger must limit the time the responder has to send a response to 60
-seconds (to avoid the possibility of brute-force attacks.)
+Open Screen Protocol does not use a memory-hard hash function to hash PSKs
+with SPAKE2 and uses SHA-512 instead as the PSK is one-time use and
+is not stored in any form.
 
+SPAKE2 provides explicit mutual authentication.
 
-For hkdf-of-scrypt-of-psk, the proof is calculated using the following steps:
-
-1. Let secret be the pre-shared secret.
-
-2. Let N be 2 to the power of of the cost from the authentication-request
-     message.
-
-3. Let r be 8.
-
-4. Let p be 1.
-
-5. Let keyLength be 32.
-
-6. Let scryptResult be the result of running
-     [scrypt](https://tools.ietf.org/html/rfc7914) on secret with cost parameter N,
-     block size r, parallelization parameter p, and derived key length of
-     keyLength.
-
-7. Let hashFunction be sha-256.
+This authentication method assumes the agents share a low-entropy secret,
+such as a number or a short password that could be entered by a user on a
+phone, a keyboard or a TV remote control.
 
-8. Let salt be the salt from the authentication-request message.
+SPAKE2 is not symmetric and has two roles, Alice (A) and Bob (B).
+The client acts as Alice, the server acts as Bob.
 
-9. Let info be a 64-byte array containing certificate fingerprint pair with the following values:
+The messages used in this authentication method are: auth-spake2-need-psk,
+auth-spake2-message, auth-spake2-confirmation and auth-status.
+SPAKE2 describes in detail how auth-spake2-message and auth-spake2-confirmation
+are computed.
 
--   Bytes 0-31 of the array are the challenger's fingerprint: The result of running
-    sha-256 on the Distinguished Encoding Rules (DER) form (see
-    https://tools.ietf.org/html/rfc8122#section-5) of the certificate used by
-    the challenger in the QUIC crypto handshake during connection establishment.
+If the PSK presenter wants to perform authentication, the PSK presenter
+starts the authentication process by presenting the PSK to the user and sending
+a auth-spake2-message message. When the PSK consumer receives
+the auth-spake2-message message, the PSK consumer prompts the user for the PSK
+input if it has not done so yet.
 
--   Bytes 32-63 of the array are the responder's fingerprint: The result of running
-    sha-256 on the Distinguished Encoding Rules (DER) form (see
-    https://tools.ietf.org/html/rfc8122#section-5) of the certificate used by
-    the responder in the QUIC crypto handshake during connection establishment.
+If the PSK consumer wants to perform authentication, the PSK consumer
+sends a auth-spake2-need-psk message to the PSK presenter to start authentication
+process and prompts the user to input the PSK. If the PSK presenter receives
+a auth-spake2-need-psk message after starting authentication from their side,
+the PSK presenter ignores the auth-spake2-need-psk message.
 
-9. Let proof be the result of running
-     [\HKDF](https://tools.ietf.org/html/rfc5869) on scryptResult with
-     both the extract and expand steps, hash function hashFunction,
-     application-specific info, and output key length keyLength.
+After the user inputs the PSK into the PSK consumer, the PSK consumer computes
+and sends a auth-spake2-message.
 
-To verify that the responder's proof is correct, the challenger makes the same
-calculation of the proof and compares the result. If the results are the same,
-the challenger considers the responder authenticated, and considers it
-unauthenticated otherwise.
+When either agent both knows the PSK and has received a auth-spake2-message
+message, the agent computes and sends a auth-spake2-confirmation message.
 
-Note: the values of 32 above (for salt length, keyLength) are based on the
-output size of sha-256.  If a different hash mechanism is used in the future,
-these values should be updated as well.
+When either agent has received both auth-spake2-message and
+auth-spake2-confirmation messages, the agent validates the confirmation message
+and sends the auth-status authenticated message.
 
 Control Protocols {#control-protocols}
 ============================