idnits 2.17.1 draft-madden-jose-ecdh-1pu-00.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 (May 8, 2019) is 1814 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 May 8, 2019 5 Expires: November 9, 2019 7 Public Key Authenticated Encryption for JOSE: ECDH-1PU 8 draft-madden-jose-ecdh-1pu-00 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. The mode is also a useful building block for constructing 19 interactive handshake protocols on top of JOSE. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 9, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 57 2. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral- 58 Static Static-Static (ECDH-1PU) . . . . . . . . . . . . . . . 3 59 2.1. Header Parameters used for ECDH Key Agreement . . . . . . 4 60 2.2. Key Derivation for ECDH-1PU Key Agreement . . . . . . . . 4 61 3. Two-way interactive handshake . . . . . . . . . . . . . . . . 6 62 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. ECDH-1PU . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 6.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 JSON Object Signing and Encryption (JOSE) defines a number of 73 encryption (JWE) [RFC7516] and digital signature (JWS) [RFC7515] 74 algorithms. When symmetric cryptography is used, JWE provides 75 authenticated encryption that ensures both confidentiality and sender 76 authentication. However, for public key cryptography the existing 77 JWE encryption algorithms provide only confidentiality and some level 78 of ciphertext integrity. When sender authentication is required, 79 users must resort to nested signed-then-encrypted structures, which 80 increases the overhead and size of resulting messages. This document 81 describes an alternative encryption algorithm called ECDH-1PU that 82 provides public key authenticated encryption, allowing the benefits 83 of authenticated encryption to be enjoyed for public key JWE as it 84 currently is for symmetric cryptography. 86 ECDH-1PU is based on the One-Pass Unified Model for Elliptic Curve 87 Diffie-Hellman key agreement described in [NIST.800-56A]. 89 The advantages of public key authenticated encryption with ECDH-1PU 90 compared to using nested signed-then-encrypted documents include the 91 following: 93 o The resulting message size is more compact as an additional layer 94 of headers and base64url-encoding is avoided. 96 o The same primitives are used for both confidentiality and 97 authenticity, providing savings in code size for constrained 98 environments. 100 o The generic composition of signatures and public key encryption 101 involves a number of subtle details that are essential to security 102 [PKAE]. Providing a dedicated algorithm for public key 103 authenticated encryption reduces complexity for users of JOSE 104 libraries. 106 o ECDH-1PU provides only authenticity and not the stronger security 107 properties of non-repudiation or third-party verifiability. This 108 can be an advantage in applications where privacy, anonymity, or 109 plausible deniability are goals. 111 1.1. Requirements Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC8174] when, and only when, they appear in all capitals, as 117 shown here. 119 2. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral-Static 120 Static-Static (ECDH-1PU) 122 This section defines the specifics of key agreement with Elliptic 123 Curve Diffie-Hellman Ephemeral-Static Static-Static, in combination 124 with the one-step KDF, as defined in Section 5.8.2.1 of 125 [NIST.800-56A] using the Concatenation Format of Section 5.8.2.1.1. 126 This is identical to the ConcatKDF function used by the existing JWE 127 ECDH-ES algorithm defined in Section 4.6 of [RFC7518]. As for ECDH- 128 ES, the key agreement result can be used in one of two ways: 130 1. directly as the Content Encryption Key (CEK) for the "enc" 131 algorithm, in the Direct Key Agreement mode, or 133 2. as a symmetric key used to wrap the CEK with the "A128KW", 134 "A192KW", or "A256KW" algorithms, in the Key Agreement with Key 135 Wrapping mode. 137 A new ephemeral public key value MUST be generated for each key 138 agreement operation. 140 In Direct Key Agreement mode, the output of the KDF MUST be a key of 141 the same length as that used by the "enc" algorithm. In this case, 142 the empty octet sequence is used as the JWE Encrypted Key value. The 143 "alg" (algorithm) Header Parameter value "ECDH-1PU" is used in Direct 144 Key Agreement mode. 146 In Key Agreement with Key Wrapping mode, the output of the KDF MUST 147 be a key of the length needed for the specified key wrapping 148 algorithm. In this case, the JWE Encrypted Key is the CEK wrapped 149 with the agreed-upon key. 151 The following "alg" (algorithm) Header Parameter values are used to 152 indicate the JWE Encrypted Key is the result of encrypting the CEK 153 using the result of the key agreement algorithm as the key encryption 154 key for the corresponding key wrapping algorithm: 156 +-----------------+-------------------------------------------------+ 157 | "alg" Param | Key Management Algorithm | 158 | Value | | 159 +-----------------+-------------------------------------------------+ 160 | ECDH-1PU+A128KW | ECDH-1PU using Concat KDF and CEK wrapped with | 161 | | "A128KW" | 162 | ECDH-1PU+A192KW | ECDH-1PU using Concat KDF and CEK wrapped with | 163 | | "A192KW" | 164 | ECDH-1PU+A256KW | ECDH-1PU using Concat KDF and CEK wrapped with | 165 | | "A256KW" | 166 +-----------------+-------------------------------------------------+ 168 2.1. Header Parameters used for ECDH Key Agreement 170 The "epk" (ephemeral public key), "apu" (Agreement PartyUInfo), and 171 "apv" (Agreement PartyVInfo) header parameters are used in ECDH-1PU 172 exactly as defined in Section 4.6.1 of [RFC7518]. 174 When no other values are supplied, it is RECOMMENDED that the 175 producer software initializes the "apu" header to the base64url- 176 encoding of the SHA-256 hash of the concatenation of the sender's 177 static public key and the ephemeral public key, and the "apv" header 178 to the base64url-encoding of the SHA-256 hash of the recipient's 179 static public key. This ensures that all keys involved in the key 180 agreement are cryptographically bound to the derived keys. 182 2.2. Key Derivation for ECDH-1PU Key Agreement 184 The key derivation process derives the agreed-upon key from the 185 shared secret Z established through the ECDH algorithm, per 186 Section 6.2.1.2 of [NIST.800-56A]. For the NIST prime order curves 187 "P-256", "P-384", and "P-521", the ECC CDH primitive for cofactor 188 Diffie-Hellman defined in Section 5.7.1.2 of [NIST.800-56A] is used 189 (taking note that the cofactor for all these curves is 1). For 190 curves "X25519" and "X448" the appropriate ECDH primitive from 191 Section 5 of [RFC7748] is used. 193 Key derivation is performed using the one-step KDF, as defined in 194 Section 5.8.1 and Section 5.8.2.1 of [NIST.800-56A] using the 195 Concatenation Format of Section 5.8.2.1.1, where the Auxilary 196 Function H is SHA-256. The KDF parameters are set as follows: 198 Z This is set to the representation of the shared secret Z as an 199 octet sequence. As per Section 6.2.1.2 of [NIST.800-56A] Z is the 200 concatenation of Ze and Zs, where Ze is the shared secret derived 201 from applying the ECDH primitive to the sender's ephemeral private 202 key and the recipient's static public key. Zs is the shared 203 secret derived from applying the ECDH primitive to the sender's 204 static private key and the recipient's static public key. 206 keydatalen This is set to the number of bits in the desired output 207 key. For "ECDH-1PU", this is the length of the key used by the 208 "enc" algorithm. For "ECDH-1PU+A128KW", "ECDH-1PU+A192KW", and 209 "ECDH-1PU+A256KW", this is 128, 192, and 256, respectively. 211 AlgorithmID The AlgorithmID values is of the form Datalen || Data, 212 where Data is a variable-length string of zero or more octets, and 213 Datalen is a fixed-length, big-endian 32-bit counter that 214 indicates the length (in octets) of Data. In the Direct Key 215 Agreement case, Data is set to the octets of the ASCII 216 representation of the "enc" Header Parameter value. In the Key 217 Agreement with Key Wrapping case, Data is set to the octets of the 218 ASCII representation of the "alg" (algorithm) Header Parameter 219 value. 221 PartyUInfo The PartyUInfo value is of the form Datalen || Data, 222 where Data is a variable-length string of zero or more octets, and 223 Datalen is a fixed-length, big-endian 32-bit counter that 224 indicates the length (in octets) of Data. If an "apu" (agreement 225 PartyUInfo) Header Parameter is present, Data is set to the result 226 of base64url decoding the "apu" value and Datalen is set to the 227 number of octets in Data. Otherwise, Datalen is set to 0 and Data 228 is set to the empty octet sequence. 230 PartyVInfo The PartyVInfo value is of the form Datalen || Data, 231 where Data is a variable-length string of zero or more octets, and 232 Datalen is a fixed-length, big-endian 32-bit counter that 233 indicates the length (in octets) of Data. If an "apv" (agreement 234 PartyVInfo) Header Parameter is present, Data is set to the result 235 of base64url decoding the "apv" value and Datalen is set to the 236 number of octets in Data. Otherwise, Datalen is set to 0 and Data 237 is set to the empty octet sequence. 239 SuppPubInfo This is set to the keydatalen represented as a 32-bit 240 big-endian integer. 242 SuppPrivInfo This is set to the empty octet sequence. 244 Applications need to specifiy how the "apu" and "apv" Header 245 Parameters are used for that application. The "apu" and "apv" values 246 MUST be distinct, when used. Applications wishing to conform to 247 [NIST.800-56A] need to provide values that meet the requirements of 248 that doucument, e.g., by using values that identify the producer and 249 consumer. 251 3. Two-way interactive handshake 253 A party that has received a JWE encrypted with ECDH-1PU MAY reply to 254 that message by creating a new JWE using ECDH-1PU, but using the 255 ephemeral public key ("epk") from the first message as if it was the 256 originating party's static public key. In this case, key agreement 257 proceeds exactly as for Section 2, but with the originator's 258 ephemeral public key used as the recipient (Party V) static public 259 key. The "alg" (algorithm) Header Parameter in the response MUST be 260 identical to the "alg" Header Parameter of the original message. 262 The value of the "apu" (Agreement PartyUInfo) Header Parameter value 263 from the original message SHOULD be reflected as the "apv" (Agreement 264 PartyVInfo) Header Parameter value in the new message. Applications 265 need to specify how the new "apu" Header Parameter should be 266 constructed. 268 If a "kid" claim was included in the ephemeral public key of the 269 original message, then a "kid" Header Parameter with the same value 270 MUST be included in the reply JWE. 272 After the initial message and a reply have been exchanged, the two 273 parties may communicate using the derived key from the second message 274 as the encryption key for any number of additional messages. When 275 ECDH-1PU is used in Direct Key Agreement mode, then subsequent 276 messages using the derived key MUST be encrypted using the "dir" 277 (Direct) JWE algorithm. When used in Key Agreement with Key Wrapping 278 mode, subsequent messages using the derived key MUST be encrypted 279 using the associated Key Wrapping algorithm, as shown in the 280 following table: 282 +----------------------------+------------------------------+ 283 | ECDH-1PU "alg" Param Value | Subsequent "alg" Param Value | 284 +----------------------------+------------------------------+ 285 | ECDH-1PU+A128KW | A128KW | 286 | ECDH-1PU+A192KW | A192KW | 287 | ECDH-1PU+A256KW | A256KW | 288 +----------------------------+------------------------------+ 290 4. IANA considerations 292 This section registers JWE algorithms as per the registry established 293 in [RFC7518]. 295 4.1. ECDH-1PU 297 Algorithm Name: "ECDH-1PU" 298 Algorithm Description: ECDH One-Pass Unified Model using Concat 299 KDF 300 Algorithm Usage Location(s): "alg" 301 JOSE Implementation Requirements: Optional 302 Change Controller: IESG 303 Specification Document(s): Section 2 304 Algorithm Analysis Document(s): [NIST.800-56A] (Section 7.3), 305 [PKAE] 307 5. Security Considerations 309 The security considerations of [RFC7518] relevant to ECDH-ES also 310 apply to this specification. 312 The security considerations of [NIST.800-56A] apply here. 314 When performing an ECDH key agreement between a static private key 315 and any untrusted public key, care should be taken to ensure that the 316 public key is a valid point on the same curve as the private key. 317 Failure to do so may result in compromise of the static private key. 318 For the NIST curves P-256, P-384, and P-521, appropriate validation 319 routines are given in Section 5.6.2.3.3 of [NIST.800-56A]. For the 320 curves used by X25519 and X448, consult the security considerations 321 of [RFC7748]. 323 The ECDH-1PU algorithm is vulnerable to Key Compromise Impersonation 324 (KCI) attacks. If the long-term static private key of a party is 325 compromised, then the attacker can not only impersonate that party to 326 other parties, but also impersonate any other party when 327 communicating with the compromised party. The second and any 328 subsequent messages in the two-way interactive handshake described in 329 Section 3 are not vulnerable to KCI. If resistance to KCI is desired 330 in a single message, then it is RECOMMENDED to use a nested JWS 331 signature over the content. 333 When Key Agreement with Key Wrapping is used, with the same Content 334 Encryption Key (CEK) reused for multiple recipients, any of those 335 recipients can produce a new message that appears to come from the 336 original sender and will be trusted by any of the other recipients. 337 It is RECOMMENDED that a unique CEK is used for each recipient. 339 6. References 341 6.1. Normative References 343 [NIST.800-56A] 344 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 345 Davis, "Recommendation for Pair-Wise Key Establishment 346 Using Discrete Logarithm Cryptography Revision 3.", NIST 347 Special Publication 800-56A, April 2018. 349 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 350 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 351 2015, . 353 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 354 RFC 7516, DOI 10.17487/RFC7516, May 2015, 355 . 357 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 358 DOI 10.17487/RFC7518, May 2015, 359 . 361 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 362 for Security", RFC 7748, DOI 10.17487/RFC7748, January 363 2016, . 365 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 366 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 367 May 2017, . 369 6.2. Informative References 371 [PKAE] An, J., "Authenticated Encryption in the Public-Key 372 Setting: Security Notions and Analyses", IACR ePrint 373 2001/079, 2001. 375 Author's Address 377 Neil Madden 378 ForgeRock 379 Broad Quay House 380 Prince Street 381 Bristol BS1 4DJ 382 United Kingdom 384 Email: neil.madden@forgerock.com