From 69f6f60065c5146d23c49bdf9f4155fc4fa16492 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Thu, 26 Sep 2024 06:48:30 +0000 Subject: [PATCH] Script updating gh-pages from ee1cca8. [ci skip] --- draft-irtf-cfrg-cpace.html | 43 +++++++++++----------- draft-irtf-cfrg-cpace.txt | 74 ++++++++++++++++++++------------------ 2 files changed, 60 insertions(+), 57 deletions(-) diff --git a/draft-irtf-cfrg-cpace.html b/draft-irtf-cfrg-cpace.html index 4b57d6f..bdfb7ad 100644 --- a/draft-irtf-cfrg-cpace.html +++ b/draft-irtf-cfrg-cpace.html @@ -1156,7 +1156,7 @@

9.5. Integrating CPace in higher-level protocols such as TLS1.3

-

When integrating CPace into a higher-level protocol such as TLS1.3 [RFC8446] it is recommended to let the intermediate key ISK -take over the role of the shared secret that for other cipher suites -might be generated by Diffie-Hellman key exchange. Note that unlike a Diffie-Hellman shared secret ISK will also -mutually authenticate the protocol partners. +

When integrating CPace into a higher-level protocol such as TLS1.3 [RFC8446] it is recommended to use ISK +as shared secret (which might otherwise be generated as part of a Diffie-Hellman key exchange output for other cipher suites).

+

Note that unlike the shared secret of a Diffie-Hellman protocol run, ISK will also provide mutual implicit authentication of the protocol partners. For providing explicit authentication, it is recommended to add a key confirmation round along the lines in Section 9.4, -such as e.g. done in the "Finished" messages in TLS1.3.

-

If an embedding protocol uses more than two messages (e.g. four message TLS1.3 [RFC8446] flows involving +such as e.g. done in the "Finished" messages in TLS1.3 [RFC8446].

+

If an embedding protocol uses more than two messages (e.g. four message TLS1.3 [RFC8446] flows involving a hello-retry message and a repeated client-hello message) it is suggested that the CPace layer only considers the two messages used for the CPace run. I.e. it is suggested that authenticating the full message sequence involving also the additional messages that might preceed the two CPace messages -is done under the responsibiity of the embedding protocol. -This could be done by integrating the full protocol transcript as part of a final explicit key confirmation round (as commonly done by TLS 1.3). -Alternatively information on communication rounds preceeding the CPace flows can also be integrated as part of the CI field, as this will authenticate -the information and will not require both communication partners to keep state information regarding preceeding messages until after the CPace run.

-

In case of TLS 1.3 it is suggested to integrate Ya into the client-hello message and Yb into the server-hello message. Also party identifiers -may be added to the client-hello and server-hello messages as part of extension fields. +is done under the responsibiity of the embedding application protocol. +This could be done by integrating the full protocol transcript as part of a final explicit key confirmation round (as commonly done by TLS 1.3 as part of the "Finished" messages). +Alternatively, information on communication rounds preceeding the CPace flows can also be integrated as part of the CI field, as this will authenticate +the information and will not require both communication partners to keep state information regarding preceeding messages in memory until after the CPace run.

+

In case of TLS 1.3 [RFC8446] it is suggested to integrate Ya into the client-hello message and Yb into the server-hello message. Also party identifiers +might best be added to the client-hello and server-hello messages as part of extension fields. It is recommended to use the full octet stream encoding of the -client-hello message as parameter ADa. Likewise the encoding of the server-hello would be used for the parameter ADb. -This approach has the drawback that the public points Ya and Yb might show up duplicated in the hashing operation for +client-hello message as parameter ADa. Likewise it is recommended to use the encoding of the server-hello message for the parameter ADb. +This approach has the drawback that the public points Ya and Yb might show up redundantly duplicated in the hashing operation for CPace's transcript strings but has the advantage of simplicity and the advantage that all meta-information in the extension fields within the -client- and server hello fields will become authenticated as part of the ISK.

+client- and server hello fields will always become authenticated as part of the ISK.

diff --git a/draft-irtf-cfrg-cpace.txt b/draft-irtf-cfrg-cpace.txt index c2e90e0..b02316e 100644 --- a/draft-irtf-cfrg-cpace.txt +++ b/draft-irtf-cfrg-cpace.txt @@ -71,7 +71,7 @@ Table of Contents 2. Requirements Notation 3. High-level application perspective 3.1. Optional CPace inputs - 3.2. Optional CPace output + 3.2. Optional CPace outputs 3.3. Responsibilities of the application layer 4. CPace cipher suites 5. Definitions and notation @@ -380,12 +380,12 @@ Table of Contents security advantages and will bind the CPace run to this communication session (see Section 9). -3.2. Optional CPace output +3.2. Optional CPace outputs If a session identifier is not available as input at protocol start CPace can optionally produce a session identifier sid_output as output that might be helpful for the application for actions - subsequent to the CPace protocol step (see Section 9.6). + subsequent to the CPace protocol step (see Section 9.6, [BGHJ24]). 3.3. Responsibilities of the application layer @@ -404,10 +404,11 @@ Table of Contents * The application needs to settle whether CPace is used in the initiator-responder or the symmetric setting, as in the symmetric - setting transcripts and concatenation of party identity strings as - part of the channel identifier CI must be generated using ordered - string concatenation. In this document we will provide test - vectors for both, initiator-responder and symmetric settings. + setting transcripts ordered string concatenation must be used for + generating protocol transcripts and when integrating the identity + strings A and B into the channel identifier CI. In this document + we will provide test vectors for both, initiator-responder and + symmetric settings. 4. CPace cipher suites @@ -1121,13 +1122,15 @@ Table of Contents 9.5. Integrating CPace in higher-level protocols such as TLS1.3 When integrating CPace into a higher-level protocol such as TLS1.3 - [RFC8446] it is recommended to let the intermediate key ISK take over - the role of the shared secret that for other cipher suites might be - generated by Diffie-Hellman key exchange. Note that unlike a Diffie- - Hellman shared secret ISK will also mutually authenticate the - protocol partners. For providing explicit authentication, it is - recommended to add a key confirmation round along the lines in - Section 9.4, such as e.g. done in the "Finished" messages in TLS1.3. + [RFC8446] it is recommended to use ISK as shared secret (which might + otherwise be generated as part of a Diffie-Hellman key exchange + output for other cipher suites). + + Note that unlike the shared secret of a Diffie-Hellman protocol run, + ISK will also provide mutual implicit authentication of the protocol + partners. For providing explicit authentication, it is recommended + to add a key confirmation round along the lines in Section 9.4, such + as e.g. done in the "Finished" messages in TLS1.3 [RFC8446]. If an embedding protocol uses more than two messages (e.g. four message TLS1.3 [RFC8446] flows involving a hello-retry message and a @@ -1135,27 +1138,28 @@ Table of Contents only considers the two messages used for the CPace run. I.e. it is suggested that authenticating the full message sequence involving also the additional messages that might preceed the two CPace - messages is done under the responsibiity of the embedding protocol. - This could be done by integrating the full protocol transcript as - part of a final explicit key confirmation round (as commonly done by - TLS 1.3). Alternatively information on communication rounds - preceeding the CPace flows can also be integrated as part of the CI - field, as this will authenticate the information and will not require - both communication partners to keep state information regarding - preceeding messages until after the CPace run. - - In case of TLS 1.3 it is suggested to integrate Ya into the client- - hello message and Yb into the server-hello message. Also party - identifiers may be added to the client-hello and server-hello - messages as part of extension fields. It is recommended to use the - full octet stream encoding of the client-hello message as parameter - ADa. Likewise the encoding of the server-hello would be used for the - parameter ADb. This approach has the drawback that the public points - Ya and Yb might show up duplicated in the hashing operation for - CPace's transcript strings but has the advantage of simplicity and - the advantage that all meta-information in the extension fields - within the client- and server hello fields will become authenticated - as part of the ISK. + messages is done under the responsibiity of the embedding application + protocol. This could be done by integrating the full protocol + transcript as part of a final explicit key confirmation round (as + commonly done by TLS 1.3 as part of the "Finished" messages). + Alternatively, information on communication rounds preceeding the + CPace flows can also be integrated as part of the CI field, as this + will authenticate the information and will not require both + communication partners to keep state information regarding preceeding + messages in memory until after the CPace run. + + In case of TLS 1.3 [RFC8446] it is suggested to integrate Ya into the + client-hello message and Yb into the server-hello message. Also + party identifiers might best be added to the client-hello and server- + hello messages as part of extension fields. It is recommended to use + the full octet stream encoding of the client-hello message as + parameter ADa. Likewise it is recommended to use the encoding of the + server-hello message for the parameter ADb. This approach has the + drawback that the public points Ya and Yb might show up redundantly + duplicated in the hashing operation for CPace's transcript strings + but has the advantage of simplicity and the advantage that all meta- + information in the extension fields within the client- and server + hello fields will always become authenticated as part of the ISK. 9.6. Calculating a session identifier alongside with the CPace run