idnits 2.17.1 draft-madden-jose-ecdh-1pu-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 11, 2020) is 1535 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7748 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Madden 3 Internet-Draft ForgeRock 4 Intended status: Standards Track February 11, 2020 5 Expires: August 14, 2020 7 Public Key Authenticated Encryption for JOSE: ECDH-1PU 8 draft-madden-jose-ecdh-1pu-03 10 Abstract 12 This document describes the ECDH-1PU public key authenticated 13 encryption algorithm for JWE. The algorithm is similar to the 14 existing ECDH-ES encryption algorithm, but adds an additional ECDH 15 key agreement between static keys of the sender and recipient. This 16 additional step allows the recipient to be assured of sender 17 authenticity without requiring a nested signed-then-encrypted message 18 structure. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 14, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 56 2. Key Agreement with Elliptic Curve Diffie-Hellman One-Pass 57 Unified Model (ECDH-1PU) . . . . . . . . . . . . . . . . . . 3 58 2.1. Header Parameters used for ECDH Key Agreement . . . . . . 4 59 2.1.1. "skid" Header Parameter . . . . . . . . . . . . . . . 5 60 2.2. Key Derivation for ECDH-1PU Key Agreement . . . . . . . . 5 61 3. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. JSON Web Signature and Encryption Algorithms Registration 6 63 3.1.1. ECDH-1PU . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2. JSON Web Signature and Encryption Header Parameters 65 Registration . . . . . . . . . . . . . . . . . . . . . . 7 66 3.2.1. skid . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 5.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Appendix A. Example ECDH-1PU Key Agreement Computation with 72 A256GCM . . . . . . . . . . . . . . . . . . . . . . 9 73 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 JSON Object Signing and Encryption (JOSE) defines a number of 79 encryption (JWE) [RFC7516] and digital signature (JWS) [RFC7515] 80 algorithms. When symmetric cryptography is used, JWE provides 81 authenticated encryption that ensures both confidentiality and sender 82 authentication. However, for public key cryptography the existing 83 JWE encryption algorithms provide only confidentiality and some level 84 of ciphertext integrity. When sender authentication is required, 85 users must resort to nested signed-then-encrypted structures, which 86 increases the overhead and size of resulting messages. This document 87 describes an alternative encryption algorithm called ECDH-1PU that 88 provides public key authenticated encryption, allowing the benefits 89 of authenticated encryption to be enjoyed for public key JWE as it 90 currently is for symmetric cryptography. 92 ECDH-1PU is based on the One-Pass Unified Model for Elliptic Curve 93 Diffie-Hellman key agreement described in [NIST.800-56A]. 95 The advantages of public key authenticated encryption with ECDH-1PU 96 compared to using nested signed-then-encrypted documents include the 97 following: 99 o The resulting message size is more compact as an additional layer 100 of headers and base64url-encoding is avoided. A 500-byte payload 101 when encrypted and authenticated with ECDH-1PU (with P-256 keys 102 and "A256GCM" Content Encryption Method) results in a 1087-byte 103 JWE in Compact Encoding. An equivalent nested signed-then- 104 encrypted JOSE message using the same keys and encryption method 105 is 1489 bytes (37% larger). 107 o The same primitives are used for both confidentiality and 108 authenticity, providing savings in code size for constrained 109 environments. 111 o The generic composition of signatures and public key encryption 112 involves a number of subtle details that are essential to security 113 [PKAE]. Providing a dedicated algorithm for public key 114 authenticated encryption reduces complexity for users of JOSE 115 libraries. 117 o ECDH-1PU provides only authenticity and not the stronger security 118 properties of non-repudiation or third-party verifiability. This 119 can be an advantage in applications where privacy, anonymity, or 120 plausible deniability are goals. 122 1.1. Requirements Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC8174] when, and only when, they appear in all capitals, as 128 shown here. 130 2. Key Agreement with Elliptic Curve Diffie-Hellman One-Pass Unified 131 Model (ECDH-1PU) 133 This section defines the specifics of key agreement with Elliptic 134 Curve Diffie-Hellman One-Pass Unified Model, in combination with the 135 one-step KDF, as defined in Section 5.8.2.1 of [NIST.800-56A] using 136 the Concatenation Format of Section 5.8.2.1.1. This is identical to 137 the ConcatKDF function used by the existing JWE ECDH-ES algorithm 138 defined in Section 4.6 of [RFC7518]. As for ECDH-ES, the key 139 agreement result can be used in one of two ways: 141 1. directly as the Content Encryption Key (CEK) for the "enc" 142 algorithm, in the Direct Key Agreement mode, or 144 2. as a symmetric key used to wrap the CEK with the "A128KW", 145 "A192KW", or "A256KW" algorithms, in the Key Agreement with Key 146 Wrapping mode. 148 A new ephemeral public key value MUST be generated for each key 149 agreement operation. 151 In Direct Key Agreement mode, the output of the KDF MUST be a key of 152 the same length as that used by the "enc" algorithm. In this case, 153 the empty octet sequence is used as the JWE Encrypted Key value. The 154 "alg" (algorithm) Header Parameter value "ECDH-1PU" is used in Direct 155 Key Agreement mode. 157 In Key Agreement with Key Wrapping mode, the output of the KDF MUST 158 be a key of the length needed for the specified key wrapping 159 algorithm. In this case, the JWE Encrypted Key is the CEK wrapped 160 with the agreed-upon key. 162 The following "alg" (algorithm) Header Parameter values are used to 163 indicate the JWE Encrypted Key is the result of encrypting the CEK 164 using the result of the key agreement algorithm as the key encryption 165 key for the corresponding key wrapping algorithm: 167 +-----------------+-------------------------------------------------+ 168 | "alg" Param | Key Management Algorithm | 169 | Value | | 170 +-----------------+-------------------------------------------------+ 171 | ECDH-1PU+A128KW | ECDH-1PU using one-pass KDF and CEK wrapped | 172 | | with "A128KW" | 173 | ECDH-1PU+A192KW | ECDH-1PU using one-pass KDF and CEK wrapped | 174 | | with "A192KW" | 175 | ECDH-1PU+A256KW | ECDH-1PU using one-pass KDF and CEK wrapped | 176 | | with "A256KW" | 177 +-----------------+-------------------------------------------------+ 179 2.1. Header Parameters used for ECDH Key Agreement 181 The "epk" (ephemeral public key), "apu" (Agreement PartyUInfo), and 182 "apv" (Agreement PartyVInfo) header parameters are used in ECDH-1PU 183 exactly as defined in Section 4.6.1 of [RFC7518]. 185 When no other values are supplied, it is RECOMMENDED that the 186 producer software initializes the "apu" header to the base64url- 187 encoding of the SHA-256 hash of the concatenation of the sender's 188 static public key and the ephemeral public key, and the "apv" header 189 to the base64url-encoding of the SHA-256 hash of the recipient's 190 static public key. This ensures that all keys involved in the key 191 agreement are cryptographically bound to the derived keys. 193 2.1.1. "skid" Header Parameter 195 A new Header Parameter "skid" (Sender Key ID) is registered as a hint 196 as to which of the sender's keys was used to authenticate the JWE. 197 The structure of the "skid" value is unspecified. Its value MUST be 198 a case-sensitive string. Use of this Header Parameter is OPTIONAL. 199 When used with a JWK, the "skid" value is used to match a JWK "kid" 200 parameter value [RFC7517]. 202 2.2. Key Derivation for ECDH-1PU Key Agreement 204 The key derivation process derives the agreed-upon key from the 205 shared secret Z established through the ECDH algorithm, per 206 Section 6.2.1.2 of [NIST.800-56A]. For the NIST prime order curves 207 "P-256", "P-384", and "P-521", the ECC CDH primitive for cofactor 208 Diffie-Hellman defined in Section 5.7.1.2 of [NIST.800-56A] is used 209 (taking note that the cofactor for all these curves is 1). For 210 curves "X25519" and "X448" the appropriate ECDH primitive from 211 Section 5 of [RFC7748] is used. 213 Key derivation is performed using the one-step KDF, as defined in 214 Section 5.8.1 and Section 5.8.2.1 of [NIST.800-56A] using the 215 Concatenation Format of Section 5.8.2.1.1, where the Auxilary 216 Function H is SHA-256. The KDF parameters are set as follows: 218 Z This is set to the representation of the shared secret Z as an 219 octet sequence. As per Section 6.2.1.2 of [NIST.800-56A] Z is the 220 concatenation of Ze and Zs, where Ze is the shared secret derived 221 from applying the ECDH primitive to the sender's ephemeral private 222 key and the recipient's static public key. Zs is the shared 223 secret derived from applying the ECDH primitive to the sender's 224 static private key and the recipient's static public key. 226 keydatalen This is set to the number of bits in the desired output 227 key. For "ECDH-1PU", this is the length of the key used by the 228 "enc" algorithm. For "ECDH-1PU+A128KW", "ECDH-1PU+A192KW", and 229 "ECDH-1PU+A256KW", this is 128, 192, and 256, respectively. 231 AlgorithmID The AlgorithmID values is of the form Datalen || Data, 232 where Data is a variable-length string of zero or more octets, and 233 Datalen is a fixed-length, big-endian 32-bit counter that 234 indicates the length (in octets) of Data. In the Direct Key 235 Agreement case, Data is set to the octets of the ASCII 236 representation of the "enc" Header Parameter value. In the Key 237 Agreement with Key Wrapping case, Data is set to the octets of the 238 ASCII representation of the "alg" (algorithm) Header Parameter 239 value. 241 PartyUInfo The PartyUInfo value is of the form Datalen || Data, 242 where Data is a variable-length string of zero or more octets, and 243 Datalen is a fixed-length, big-endian 32-bit counter that 244 indicates the length (in octets) of Data. If an "apu" (agreement 245 PartyUInfo) Header Parameter is present, Data is set to the result 246 of base64url decoding the "apu" value and Datalen is set to the 247 number of octets in Data. Otherwise, Datalen is set to 0 and Data 248 is set to the empty octet sequence. 250 PartyVInfo The PartyVInfo value is of the form Datalen || Data, 251 where Data is a variable-length string of zero or more octets, and 252 Datalen is a fixed-length, big-endian 32-bit counter that 253 indicates the length (in octets) of Data. If an "apv" (agreement 254 PartyVInfo) Header Parameter is present, Data is set to the result 255 of base64url decoding the "apv" value and Datalen is set to the 256 number of octets in Data. Otherwise, Datalen is set to 0 and Data 257 is set to the empty octet sequence. 259 SuppPubInfo This is set to the keydatalen represented as a 32-bit 260 big-endian integer. 262 SuppPrivInfo This is set to the empty octet sequence. 264 Applications need to specify how the "apu" and "apv" Header 265 Parameters are used for that application. The "apu" and "apv" values 266 MUST be distinct, when used. Applications wishing to conform to 267 [NIST.800-56A] need to provide values that meet the requirements of 268 that document, e.g., by using values that identify the producer and 269 consumer. 271 See Appendix A for an example key agreement computation using this 272 method. 274 3. IANA considerations 276 This section registers identifiers under the IANA JSON Web Signature 277 and Encryption Algorithms Registry established by [RFC7518] and the 278 IANA JSON Web Signature and Encryption Header Parameters registry 279 established by [RFC7515]. 281 3.1. JSON Web Signature and Encryption Algorithms Registration 283 This section registers JWE algorithms as per the registry established 284 in [RFC7518]. 286 3.1.1. ECDH-1PU 288 Algorithm Name: "ECDH-1PU" 289 Algorithm Description: ECDH One-Pass Unified Model using one-pass 290 KDF 291 Algorithm Usage Location(s): "alg" 292 JOSE Implementation Requirements: Optional 293 Change Controller: IESG 294 Specification Document(s): Section 2 295 Algorithm Analysis Document(s): [NIST.800-56A] (Section 7.3), 296 [PKAE] 298 3.2. JSON Web Signature and Encryption Header Parameters Registration 300 This section registers new Header Parameters as per the registry 301 established in [RFC7515]. 303 3.2.1. skid 305 Header Parameter Name: "skid" 306 Header Parameter Description: Sender Key ID 307 Header Parameter Usage Location(s): JWE 308 Change Controller: IESG 309 Specification Document(s): Section 2.1.1 311 4. Security Considerations 313 The security considerations of [RFC7516] and [RFC7518] relevant to 314 ECDH-ES also apply to this specification. 316 The security considerations of [NIST.800-56A] apply here. 318 When performing an ECDH key agreement between a static private key 319 and any untrusted public key, care should be taken to ensure that the 320 public key is a valid point on the same curve as the private key. 321 Failure to do so may result in compromise of the static private key. 322 For the NIST curves P-256, P-384, and P-521, appropriate validation 323 routines are given in Section 5.6.2.3.3 of [NIST.800-56A]. For the 324 curves used by X25519 and X448, consult the security considerations 325 of [RFC7748]. 327 The ECDH-1PU algorithm is vulnerable to Key Compromise Impersonation 328 (KCI) attacks. If the long-term static private key of a party is 329 compromised, then the attacker can not only impersonate that party to 330 other parties, but also impersonate any other party when 331 communicating with the compromised party. If resistance to KCI is 332 desired in a single message, then the sender SHOULD use a nested JWS 333 signature over the content. 335 When Key Agreement with Key Wrapping is used, with the same Content 336 Encryption Key (CEK) reused for multiple recipients, any of those 337 recipients can produce a new message that appears to come from the 338 original sender. The new message will be indistinguishable from a 339 genuine message from the original sender to any of the other 340 participants. To avoid this attack, the content SHOULD be encrypted 341 separately to each recipient with a unique CEK or a nested signature 342 over the content SHOULD be used. 344 The security properties of the one-pass unified model are given in 345 Section 7.3 of [NIST.800-56A]. 347 5. References 349 5.1. Normative References 351 [NIST.800-56A] 352 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 353 Davis, "Recommendation for Pair-Wise Key Establishment 354 Using Discrete Logarithm Cryptography Revision 3.", NIST 355 Special Publication 800-56A, April 2018. 357 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 358 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 359 2015, . 361 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 362 RFC 7516, DOI 10.17487/RFC7516, May 2015, 363 . 365 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 366 DOI 10.17487/RFC7517, May 2015, 367 . 369 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 370 DOI 10.17487/RFC7518, May 2015, 371 . 373 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 374 for Security", RFC 7748, DOI 10.17487/RFC7748, January 375 2016, . 377 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 378 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 379 May 2017, . 381 5.2. Informative References 383 [PKAE] An, J., "Authenticated Encryption in the Public-Key 384 Setting: Security Notions and Analyses", IACR ePrint 385 2001/079, 2001. 387 Appendix A. Example ECDH-1PU Key Agreement Computation with A256GCM 389 This example uses ECDH-1PU in Direct Key Agreement mode ("alg" value 390 "ECDH-1PU") to produce an agreed-upon key for AES GCM with a 256-bit 391 key ("enc" value "A256GCM"). The example re-uses the keys and 392 parameters of the example computation in Appendix C of [RFC7518], 393 with the addition of an extra static key-pair for Alice. 395 In this example, a producer Alice is encrypting content to a consumer 396 Bob. Alice's static key-pair (in JWK format) used for the key 397 agreement in this example (including the private part) is: 399 {"kty":"EC", 400 "crv":"P-256", 401 "x":"WKn-ZIGevcwGIyyrzFoZNBdaq9_TsqzGl96oc0CWuis", 402 "y":"y77t-RvAHRKTsSGdIYUfweuOvwrvDD-Q3Hv5J0fSKbE", 403 "d":"Hndv7ZZjs_ke8o9zXYo3iq-Yr8SewI5vrqd0pAvEPqg"} 405 Bob's static key-pair (in JWK format) is: 407 {"kty":"EC", 408 "crv":"P-256", 409 "x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ", 410 "y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck", 411 "d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"} 413 The producer (Alice) generates an ephemeral key for the key agreement 414 computation. Alice's ephemeral key (in JWK format) is: 416 {"kty":"EC", 417 "crv":"P-256", 418 "x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0", 419 "y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps", 420 "d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo"} 422 Header Parameter values used in this example are as follows. The 423 "apu" (agreement PartyUInfo) Header Parameter value is the base64url 424 encoding of the UTF-8 string "Alice" and the "apv" (agreement 425 PartyVInfo) Header Parameter value is the base64url encoding of the 426 UTF-8 string "Bob". The "epk" (ephemeral public key) Header 427 Parameter is used to communicate the producer's (Alice's) ephemeral 428 public key value to the consumer (Bob). 430 {"alg":"ECDH-1PU", 431 "enc":"A256GCM", 432 "apu":"QWxpY2U", 433 "apv":"Qm9i", 434 "epk": 435 {"kty":"EC", 436 "crv":"P-256", 437 "x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0", 438 "y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps" 439 } 440 } 442 The resulting one-pass KDF [NIST.800-56A] parameter values are: 444 Ze This is set to the output of the ECDH key agreement between 445 Alice's ephemeral private key and Bob's static public key. In 446 this example, Ze is the following octet sequence (in hexadecimal 447 notation): 449 9e 56 d9 1d 81 71 35 d3 72 83 42 83 bf 84 26 9c 450 fb 31 6e a3 da 80 6a 48 f6 da a7 79 8c fe 90 c4 452 Zs This is set to the output of the ECDH key agreement between 453 Alice's static private key and Bob's static public key. In this 454 example, Zs is the following octet sequence (in hexadecimal 455 notation): 457 e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c 68 8b 3e 7d 458 41 10 a1 b4 ba dc 3c c5 4e f7 b8 12 41 ef d5 0d 460 Z This is set to the concatenation of Ze followed by Zs. In this 461 example, Z is the following octet sequence (in hexadecimal 462 notation): 464 9e 56 d9 1d 81 71 35 d3 72 83 42 83 bf 84 26 9c 465 fb 31 6e a3 da 80 6a 48 f6 da a7 79 8c fe 90 c4 466 e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c 68 8b 3e 7d 467 41 10 a1 b4 ba dc 3c c5 4e f7 b8 12 41 ef d5 0d 469 keydatalen This value is 256 - the number of bits in the desired 470 output key (because "A256GCM" uses a 256-bit key). 471 AlgorithmID This is set to the octets representing the 32-bit big- 472 endian value 7 - 00 00 00 07 in hexadecimal notation - the number 473 of octets in the AlgorithmID content "A256GCM", followed by the 474 octets representing the ASCII string "A256GCM" - 41 32 35 36 47 43 475 4d (in hex). The complete value is therefore: 00 00 00 07 41 32 476 35 36 47 43 4d 478 PartyUInfo This is set to the octets representing the 32-bit big- 479 endian value 5, followed by the octets representing the UTF-8 480 string "Alice". In hexadecimal notation: 00 00 00 05 41 6c 69 63 481 65 482 PartyVInfo This is set to the octets representing the 32-bit big- 483 endian value 3, followed by the octets representing the UTF-8 484 string "Bob". In hexadecimal notation: 00 00 00 03 42 6f 62 485 SuppPubInfo This is set to the octets representing the 32-bit big- 486 endian value 256 - the keydatalen value. In hexadecimal notation: 487 00 00 01 00 488 SuppPrivInfo This is set to the empty octet sequence. 490 Concatenating the parameters AlgorithmID through SuppPrivInfo results 491 in a FixedInfo value in Concatenation Format (as per 492 Section 5.8.2.1.1 of [NIST.800-56A]) of (in hexidecimal notation): 494 00 00 00 07 41 32 35 36 47 43 4d 00 00 00 05 41 495 6c 69 63 65 00 00 00 03 42 6f 62 00 00 01 00 497 Concatenating the round number 1 (00 00 00 01), Z, and the FixedInfo 498 value results in a one-pass KDF round 1 hash input of (hexadecimal): 500 00 00 00 01 9e 56 d9 1d 81 71 35 d3 72 83 42 83 501 bf 84 26 9c fb 31 6e a3 da 80 6a 48 f6 da a7 79 502 8c fe 90 c4 e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c 503 68 8b 3e 7d 41 10 a1 b4 ba dc 3c c5 4e f7 b8 12 504 41 ef d5 0d 00 00 00 07 41 32 35 36 47 43 4d 00 505 00 00 05 41 6c 69 63 65 00 00 00 03 42 6f 62 00 506 00 01 00 508 The resulting derived key, which is the full 256 bits of the round 1 509 hash output is: 511 6c af 13 72 3d 14 85 0a d4 b4 2c d6 dd e9 35 bf 512 fd 2f ff 00 a9 ba 70 de 05 c2 03 a5 e1 72 2c a7 514 The base64url-encoded representation of this derived key is: 516 bK8Tcj0UhQrUtCzW3ek1v_0v_wCpunDeBcIDpeFyLKc 518 Appendix B. Document History 520 -03 Corrected typos and clarified wording. Removed unnecessary 521 references. 522 -02 Removed two-way interactive handshake protocol section and 523 example after discussion with Hannes Tschofenig. 525 -01 Added examples in Appendix A and a two-way handshake example. 526 Added "skid" Header Parameter and registration. Fleshed out 527 Security Considerations. 529 Author's Address 531 Neil Madden 532 ForgeRock 533 Broad Quay House 534 Prince Street 535 Bristol BS1 4DJ 536 United Kingdom 538 Email: neil.madden@forgerock.com