From 21d4c096a99d757dd78374d0cea2493d3b118872 Mon Sep 17 00:00:00 2001 From: Peter Thatcher Date: Sat, 15 Dec 2018 11:56:06 -0800 Subject: [PATCH 1/6] Add challenge/response mechanism for authentication --- index.bs | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 123 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index 00ef2dd..d4f97b8 100644 --- a/index.bs +++ b/index.bs @@ -375,7 +375,81 @@ request they are associated with. Authentication {#authentication} ================================ -Issue(102): Incorporate material from the \[J-PAKE](j-pake.md) document. +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 best 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-entry 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 authentication-request message with the following values: + +- mechanism: The authentication mechanism being used. This standard only + defines the mechanism hkdf-of-scrypt-of-psk but this field gives a place for + other mechanisms to be specified. + +- salt: 32 random bytes (which need not be kept secret). + +- 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 authentication-response 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 + [HKDF](https://tools.ietf.org/html/rfc5869) on the result of running + [scrypt](https://tools.ietf.org/html/rfc7914) on the shared secret. For + scrypt, the cost parameter (N) used is the 2 to the power of the cost from + the authentication-request message, the block size (r) is 8, the + parallelization parameter (p) is 1, and the key length derived is 32. For + HKDF, both the extract and expand steps are used, the hash function used is + sha-256, the salt used is the salt from the authentication-request message, + the application-specific info is a serialized certificate-fingerprint-pair + object (defined below), and the length of the output key matrial (L) is 32. + +Note: the values of 32 above (for salt length, scrypt output key length, and +HKDF output key material length) 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. + +The certificate-fingerprint-pair object used as application-specific info above +is serialized as CBOR (without the type or length prefix of messages in a QUIC +stream) and contains the following values: + +- challenger-fingerprint: The certificate fingerprint of the + challenger, used in the QUIC crypto handshake during connection + establishment, as defined by [RFC 8122 section + 5](https://tools.ietf.org/html/rfc8122#section-5). It is the output using + sha-256 as the hash wihtout any hexadecimal encoding or prefixing. + +- responder-fingerprint: The certificate fingerprint of the + responder, obtained from the QUIC crypto handshake during connection + establishment, as defined by [RFC 8122 section + 5](https://tools.ietf.org/html/rfc8122#section-5). It is the output using + sha-256 as the hash wihtout any hexadecimal encoding or prefixing. + +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. In either case, the challenger sends the responder an +authentication-result message with the following values: + +- result: If the challenger was able to authenticate the responder or not, + and if not, why not. + +The challenger must limit the time the responder has to send a response to 60 +seconds (to avoid the possibility of brute-force attacks.) + + Control Protocols {#control} ============================ @@ -513,7 +587,7 @@ message which contains the following values: - presentation-id: The ID of the presentation to connect to. -- url: The URL of the presentation to connect to. +- url: The URL of the presentation to connect to. The receiver should, upon receipt of a @@ -707,6 +781,53 @@ response = ( request-id = uint +; type key 1001 +authentication-request = { + request + 1: authentication-mechanism ; mechanism + 2: bytes ; salt + 3: uint ; cost +} + +; type key 1002 +authentication-response = { + response + 1: authentication-response-result ; result + 2: bytes ; proof +} + +certificate-fingerprint-pair = [ + challenger-fingerprint: bytes + responder-fingerprint: bytes +] + +; type key 1003 +authentication-result = { + 1: authentication-result-result ; result +} + + +authentication-mechanism = &( + hkdf-of-scrypt-of-psk: 1 +) + +authentication-response-result = &( + ok: 0 + unknown-error: 1 + mechanism-unknown: 2 + salt-too-small: 3 + cost-too-low: 4 + cost-too-high: 5 + secret-unknown: 6 + calculation-took-too-long: 7 +) + +authentication-result-result = &( + authenticated: 0 + unknown-error: 1 + proof-invalid: 2 +) + ; type key 14 presentation-url-availability-request = { request From f9c0bdf36aebcc950bae862f6654692d9b25f4ed Mon Sep 17 00:00:00 2001 From: Peter Thatcher Date: Thu, 27 Dec 2018 17:47:18 -0800 Subject: [PATCH 2/6] Fix typos --- index.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index d4f97b8..6af26ef 100644 --- a/index.bs +++ b/index.bs @@ -377,9 +377,9 @@ Authentication {#authentication} 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 best sent back from the responder. To +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-entry secret, +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. From a8a8dbd2f6b02c3125af5974aa6a856b63fda54f Mon Sep 17 00:00:00 2001 From: Peter Thatcher Date: Thu, 27 Dec 2018 18:00:16 -0800 Subject: [PATCH 3/6] Add reference to https://tools.ietf.org/html/rfc5869#section-3.1 --- index.bs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 184f87e..0208c3b 100644 --- a/index.bs +++ b/index.bs @@ -392,7 +392,9 @@ The challenger sends an authentication-request message with the following values defines the mechanism hkdf-of-scrypt-of-psk but this field gives a place for other mechanisms to be specified. -- salt: 32 random bytes (which need not be kept secret). +- 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 From c8c74cadfe5fc8f169f353c0289f6d5c18d57517 Mon Sep 17 00:00:00 2001 From: Peter Thatcher Date: Thu, 27 Dec 2018 20:53:11 -0800 Subject: [PATCH 4/6] Make steps for proof calculation more precise and algorithmic --- index.bs | 73 +++++++++++++++++++++++++++++++++++--------------------- 1 file changed, 46 insertions(+), 27 deletions(-) diff --git a/index.bs b/index.bs index 0208c3b..6b6c7a7 100644 --- a/index.bs +++ b/index.bs @@ -407,25 +407,43 @@ The responder replies with an authentication-response message with the following - 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 - [HKDF](https://tools.ietf.org/html/rfc5869) on the result of running - [scrypt](https://tools.ietf.org/html/rfc7914) on the shared secret. For - scrypt, the cost parameter (N) used is the 2 to the power of the cost from - the authentication-request message, the block size (r) is 8, the - parallelization parameter (p) is 1, and the key length derived is 32. For - HKDF, both the extract and expand steps are used, the hash function used is - sha-256, the salt used is the salt from the authentication-request message, - the application-specific info is a serialized certificate-fingerprint-pair - object (defined below), and the length of the output key matrial (L) is 32. - -Note: the values of 32 above (for salt length, scrypt output key length, and -HKDF output key material length) 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. - -The certificate-fingerprint-pair object used as application-specific info above -is serialized as CBOR (without the type or length prefix of messages in a QUIC -stream) and contains the following values: +- proof: The result of running the authentication mechanism. The steps for + hkdf-of-scrypt-of-psk are described below. + +The challenger verifies the proof and sends the responder an +authentication-result message with the following values: + +- result: If the challenger was able to authenticate the responder or not, + and if not, why not. + +The challenger must limit the time the responder has to send a response to 60 +seconds (to avoid the possibility of brute-force attacks.) + + +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. + +8. Let salt be the salt from the authentication-request message. + +9. Let info be a CBOR-serialized certificate-fingerprint-pair object (CDDL + defined in Appendix A) with the following values: - challenger-fingerprint: The certificate fingerprint of the challenger, used in the QUIC crypto handshake during connection @@ -439,18 +457,19 @@ stream) and contains the following values: 5](https://tools.ietf.org/html/rfc8122#section-5). It is the output using sha-256 as the hash wihtout any hexadecimal encoding or prefixing. +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. + 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. In either case, the challenger sends the responder an -authentication-result message with the following values: - -- result: If the challenger was able to authenticate the responder or not, - and if not, why not. - -The challenger must limit the time the responder has to send a response to 60 -seconds (to avoid the possibility of brute-force attacks.) +unauthenticated otherwise. +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. Control Protocols {#control} From b5f108dedb1f94536bec567758d3839bebb7987c Mon Sep 17 00:00:00 2001 From: Peter Thatcher Date: Thu, 27 Dec 2018 21:01:56 -0800 Subject: [PATCH 5/6] Make fingerprint text more clear --- index.bs | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/index.bs b/index.bs index 6b6c7a7..bc17b2c 100644 --- a/index.bs +++ b/index.bs @@ -445,17 +445,15 @@ For hkdf-of-scrypt-of-psk, the proof is calculated using the following steps: 9. Let info be a CBOR-serialized certificate-fingerprint-pair object (CDDL defined in Appendix A) with the following values: -- challenger-fingerprint: The certificate fingerprint of the - challenger, used in the QUIC crypto handshake during connection - establishment, as defined by [RFC 8122 section - 5](https://tools.ietf.org/html/rfc8122#section-5). It is the output using - sha-256 as the hash wihtout any hexadecimal encoding or prefixing. - -- responder-fingerprint: The certificate fingerprint of the - responder, obtained from the QUIC crypto handshake during connection - establishment, as defined by [RFC 8122 section - 5](https://tools.ietf.org/html/rfc8122#section-5). It is the output using - sha-256 as the hash wihtout any hexadecimal encoding or prefixing. +- challenger-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. + +- responder-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. 9. Let proof be the result of running [HKDF](https://tools.ietf.org/html/rfc5869) on scryptResult with From 17ada9e2d0083bc6982b36003c356ec86520559b Mon Sep 17 00:00:00 2001 From: "mark a. foltz" Date: Mon, 14 Jan 2019 15:23:57 -0800 Subject: [PATCH 6/6] Fix index.html --- index.bs | 16 +++--- index.html | 147 +++++++++++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 151 insertions(+), 12 deletions(-) diff --git a/index.bs b/index.bs index 76fe791..48194f7 100644 --- a/index.bs +++ b/index.bs @@ -426,7 +426,7 @@ 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. + message. 3. Let r be 8. @@ -435,16 +435,16 @@ For hkdf-of-scrypt-of-psk, the proof is calculated using the following steps: 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. + [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. 8. Let salt be the salt from the authentication-request message. 9. Let info be a CBOR-serialized certificate-fingerprint-pair object (CDDL - defined in Appendix A) with the following values: + defined in Appendix A) with the following values: - challenger-fingerprint: The result of running sha-256 on the Distinguished Encoding Rules (DER) form (see @@ -457,9 +457,9 @@ For hkdf-of-scrypt-of-psk, the proof is calculated using the following steps: the responder in the QUIC crypto handshake during connection establishment. 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. + [\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. 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, diff --git a/index.html b/index.html index d1fe462..df6d91d 100644 --- a/index.html +++ b/index.html @@ -1214,7 +1214,7 @@ - +