idnits 2.17.1 draft-urien-tls-im-01.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 -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'PIN-Value' is mentioned on line 296, but not defined == Missing Reference: 'Salt-Value' is mentioned on line 303, but not defined == Missing Reference: 'PSK-Value' is mentioned on line 304, but not defined == Missing Reference: 'Messages' is mentioned on line 360, but not defined == Missing Reference: 'Data' is mentioned on line 388, but not defined Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group P. Urien 3 Internet Draft Telecom Paris 4 Intended status: Experimental 6 July 5 2020 7 Expires: January 2020 9 Identity Module for TLS Version 1.3 10 draft-urien-tls-im-01.txt 12 Abstract 14 TLS 1.3 will be deployed in the Internet of Things ecosystem. In 15 many IoT frameworks, TLS or DTLS protocols, based on pre-shared key 16 (PSK), are used for device authentication. So PSK tamper resistance, 17 is a critical market request, in order to prevent hijacking issues. 18 If DH exchange is used with certificate bound to DH ephemeral public 19 key, there is also a benefit to protect its signature procedure. The 20 TLS identity module (im) MAY be based on secure element; it realizes 21 some HKDF operations bound to PSK, and cryptographic signature if 22 certificates are used. Secure Element form factor could be 23 standalone chip, or embedded in SOC like eSIM. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six 42 months and may be updated, replaced, or obsoleted by other documents 43 at any time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 2020. 48 . 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Table of Contents 66 Abstract........................................................... 1 67 Requirements Language.............................................. 1 68 Status of this Memo................................................ 1 69 Copyright Notice................................................... 2 70 1 Overview......................................................... 4 71 2 Protecting the Key Schedule for PSK.............................. 4 72 2.1 Context..................................................... 4 73 2.2 Identity Module Procedures.................................. 5 74 2.3 KSGS: Keys Secure Generation and Storage.................... 5 75 2.4 Identity Module Key Procedures (IMKP)....................... 5 76 2.4.1 CETS: Client Early Traffic Secret .................... 5 77 2.4.2 EEMS: Early Exporter Master Secret ................... 6 78 2.4.3 HEDSK: HKDF-Extract from Derived Secret Key .......... 6 79 2.4.4 HBSK: HMAC from Binder Key Secret .................... 6 80 3. Asymmetric Signature............................................ 6 81 3.1 GENKEY...................................................... 6 82 3.2 GETPUB...................................................... 7 83 3.3 SIGN........................................................ 7 84 4. Secure Element as Identity Module............................... 8 85 4.1 Administrative mode......................................... 8 86 4.2 User Mode................................................... 8 87 4.3 KSGS: Keys Secure Generation and Storage.................... 8 88 4.3.1 Example .............................................. 9 89 4.4 CETS: Client Early Traffic Secret........................... 9 90 4.4.1 Example .............................................. 9 91 4.5 EEMS: Early Exporter Master Secret.......................... 9 92 4.5.1 Example ............................................. 10 93 4.6 HEDSK: HKDF-Extract from Derived Secret Key................ 10 94 4.6.1 Example ............................................. 10 95 4.7 HBSK: HMAC from Binder Key Secret.......................... 10 96 4.7.1 Example ............................................. 10 97 5 IANA Considerations............................................. 10 98 6 Security Considerations......................................... 10 99 7 References...................................................... 11 100 7.1 Normative References....................................... 11 101 7.2 Informative References..................................... 11 102 8 Authors' Addresses.............................................. 11 103 1 Overview 105 TLS 1.3 [RFC8446] will be deployed in the Internet of Things 106 ecosystem. In many IoT frameworks, TLS or DTLS protocols, based on 107 pre-shared key (PSK), are used for device authentication. So PSK 108 tamper resistance, is a critical market request, in order to prevent 109 hijacking issues. If DH exchange is used with certificate bound to 110 DH ephemeral public key, there is also a benefit to protect its 111 signature procedure. The TLS identity module (im) MAY be based on 112 secure element [ISO7816]; it realizes some HKDF [RFC5869] operations 113 bound to PSK, and cryptographic signature if certificates are used. 114 Secure Element form factor could be standalone chip or embedded in 115 SOC like eSIM. 117 +-----------+ +----------+ 118 | Processor | | Identity | 119 | TLS 1.3 +------+ Module | 120 | | | im | 121 +-----------+ +----------+ 123 Figure 1. TLS 1.3 Identity Module (im) 125 2 Protecting the Key Schedule for PSK 127 2.1 Context 129 According to [RFC8446] external PSKs MAY be provisioned outside of 130 TLS. 132 The Early Secret (ESK) is computed according to relation: 133 ESK =HKDF-Extract(salt=0s,PSK) = HMAC(salt=0s,PSK) 135 The Binder Key (BSK) for outside provisioning is computed according 136 to the relation: 137 BSK = Derive-Secret(ESK, "ext binder", "") 139 The Derived Secret (DSK) is computed according to the relation: 140 DSK= Derive-Secret(ESK, "derived", "") 142 The Finished External Key (FEK) is computed according to the 143 relation: 144 FEK = KDF-Expand-Label(BSK, "finished", "", Hash.length) 146 For Derive-Secret procedures, "" is equivalent to the value 147 hash(empty), whose size is hash-length 148 2.2 Identity Module Procedures 150 The identity module MUST provide a KSGS (Keys Secure Generation and 151 Storage) procedure, which computes and securely stores ESK, BSK and 152 FEK keys. 154 This procedure MUST require administrative rights. 156 A set IMKP (Identity Module Key Procedures) of four procedures is 157 required, in order to protect from public exposure ESK, BSK, and 158 FSK: 159 - CETS: Client Early Traffic Secret 160 - EEMS: Early Exporter Master Secret 161 - HEDSK: HKDF-Extract from Derived Secret Key 162 - HBSK: HMAC from Binder Key Secret 164 These procedures MAY require user rights. 166 2.3 KSGS: Keys Secure Generation and Storage 168 The Identity module MUST provide a KSGS procedure, requiring 169 administrative rights, which computes and securely stores ESK, BSK, 170 DSK, FSK 172 Input: salt and PSK 173 Output: Success or Failure 175 ESK, DSK, and BSK secret values are stored in the identity module 177 HL16 : hash Length, 16 bits 178 HL8: hash length, 8 bits 179 H0 : hash(empty) 181 ESK= HMAC(salt=0s,PSK) 182 DSK= HMAC(ESK,HL16||0d746c7331332064657269766564||HL8||H0||01) 183 BSK= HMAC(ESK,HL16||10746c733133206578742062696e646572||HL8||H0||01) 184 FSK= HMAC(BSK,HL16||0E746C7331332066696E69736865640001) 186 2.4 Identity Module Key Procedures (IMKP) 188 2.4.1 CETS: Client Early Traffic Secret 190 Input: Length, Message 191 Output: Client Early Traffic Secret or Failure 193 CETS(ClientHello) = Derive-Secret(ESK, "c e traffic", Message) 194 = HMAC(ESK, Length || 11746c733133206320652074726166666963 || 195 Message || 01) 197 Message is a hash value. 199 2.4.2 EEMS: Early Exporter Master Secret 201 Input: Length, Message 202 Output: Early Exporter Master Secret or Failure 204 EEMS(ClientHello) = Derive-Secret(ESK, "e exp master", Message) 205 = HMAC(ESK, Length || 12746c733133206520657870206d6173746572 || 206 Message || 01) 208 Message is a hash value 210 2.4.3 HEDSK: HKDF-Extract from Derived Secret Key 212 Input: DHE 213 Output: Handshake Secret or Failure 215 EDSK(DHE)= HKDF-Extract(salt=DSK,DHE) = HMAC(DSK, DHE) 217 2.4.4 HBSK: HMAC from Binder Key Secret 219 Input: data 220 Output: HMAC(BSK, data) or Failure 222 HBSK(data) = HMAC(FSK, data) 224 Data is a hash value 226 3. Asymmetric Signature 228 The identity module MUST provide a GENKEY (GENKEY: Generate Key) 229 procedure, in order to store or generate private asymmetric key and 230 associated public key. 232 This procedure MUST require administrative rights. 234 The procedure GETPUB (GETPUB: Get Public Key) is required in order 235 to read the public key value. 237 This procedure MAY require user rights. 239 The procedure SIGN (SIGN: Signature) is required in order to perform 240 a raw signature for a digest value, computed from certificate. 242 This procedure MAY require user rights. 244 3.1 GENKEY 246 Input: None 247 Output: Success or Failure 248 A private key is generated and store in the identity module. A 249 public key is computed from the private key. 251 3.2 GETPUB 253 Input: None 254 Output: Public Key Value or Failure 256 3.3 SIGN 258 Input: DigestValue 259 Output: Signature Value or Failure 260 4. Secure Element as Identity Module 262 Secure elements are defined according to [ISO7816] standards. They 263 support hash functions (sha256, sha384, sha512) and associated HMAC 264 procedures. They also provide DH procedures in Z/pZ* groups, and 265 elliptic curves. Open software can be released thanks to the 266 Javacard standards, such as JC3.04, JC3.05. 268 Below is an illustration of binary encoding rules for secure element 269 according to the T=1 ISO7816 protocol. 271 An ISO7816 command (TAPDU) is a set of bytes comprising a five byte 272 header and an optional payload (up to 255 bytes) 274 The header comprises the following five bytes 275 - CLA, Class 276 - INS, Instruction code 277 - P1, P1 byte 278 - P2, P2 byte 279 - P3, length of the payload, or number of expected bytes 281 The response comprises a payload (up to 256 bytes) and a two bytes 282 status word (SW1, SW2), 9000 meaning successful operation. 284 4.1 Administrative mode 286 The [ISO7816] command VERIFY (INS=0x20) SHOULD be used to enter the 287 administrative mode 289 Tx: CLA=00 INS=20 P1=00 P2=Adm P3=PIN-Length [PIN-Value] 290 Rx: 9000 292 4.2 User Mode 294 The [ISO7816] command VERIFY SHOULD be used to enter the user mode 296 Tx: CLA=00 INS=20 P1=00 P2=User P3=PIN-Length [PIN-Value] 297 Rx: 9000 299 4.3 KSGS: Keys Secure Generation and Storage 301 Length= 2 + Salt-Length + PSK-Length 303 Tx: CLA=00 INS=TLS13 P1=0 P2=KSGS P3=Length Salt-Length [Salt-Value] 304 PSK-Length [PSK-Value] 305 Rx: 9000 307 This procedure computes and stores ESK, BSK DSK and FSK. 309 4.3.1 Example 311 PSK=0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F20 313 Tx: CLA=00 INS=85 P1=00 P2=0A P3=23 01 00 20 314 0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F20 315 Rx:9000 317 sha56(empty) = 318 E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 320 ESK= HMAC-SHA256(0,PSK) 321 ESK= 322 23499E7EDF0FBE6BAA137DF0F23BECAEFA722AD19FC262855409DE8CD8B3C897 324 DSK= HMAC-SHA256(ESK,0020 0d746c7331332064657269766564 20 325 E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 01) 326 DSK= 327 E8E7AC087158FC8440E41A12989F9194783764CD5FC36564028037F2C8206E96 329 BSK = HMAC-SHA256(ESK,0020 10746c733133206578742062696e646572 20 330 E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 01) 331 BSK= 332 4351F8A53AA85AC394AB04C516464CAB96E9340C269632D09899537887EE651F 334 FSK= HMAC-256(BSK, 0020 0E746C7331332066696E6973686564 00 01) 336 4.4 CETS: Client Early Traffic Secret 338 Length = 2 + Messages-Length 339 Hash-Length: the hash length (2 bytes) 341 Tx: CLA INS=TLS13 P1=CETS P2=ESK P3=Length Hash-Length Messages- 342 Length [Messages] 343 Rx:[Client Early Traffic Secret] 9000 345 4.4.1 Example 347 Tx: CLA=00 INS=85 P1=00 P2=0B P3=03 0020 00 348 Rx: 0738A2B6F6FAA2AF5CDD9B6F0F2B232F19B3256A5926EAC600B911F91E98D2D4 349 9000 351 Message= NULL = 0s 352 [Client Early Traffic Secret] = 353 HMAC-SHA256(ESK, 0020 11746c733133206320652074726166666963 00 01) 355 4.5 EEMS: Early Exporter Master Secret 357 Length = 2 + Messages-Length 358 Hash-Length: the hash length (2 bytes) 359 Tx: CLA INS=TLS13 P1=EEMS P2=ESK P3=Length Hash-Length Messages- 360 Length [Messages] 361 Rx: [Early Exporter Master Secret] 9000 363 4.5.1 Example 365 Tx: CLA=00 INS=85 P1=01 P2=0B P3=03 0020 00 366 Rx: 9B7FC6A8F854C16A301DFC566859931DB5EE9A22793142A0C67159C445E7BEAB 367 9000 369 Message= NULL = 0s 370 [Early Exporter Master Secret] = 371 HMAC-SHA256(ESK, 0020 12746c733133206520657870206d6173746572 00 01) 373 4.6 HEDSK: HKDF-Extract from Derived Secret Key 375 Tx: CLA INS=TLS13 P1=0 P2=HEDSK P3=Data-Length [Data] 376 Rx: [HMAC(Data,DSK)] 9000 378 4.6.1 Example 380 Tx: CLA=00 INS=85 P1=00 P2=0E P3=01 00 381 Rx: 7092C2117D67E6AEB5C5FDF5E6D9C70FBDC69B374E914C26AB08A122483D0E73 383 DHE=NULL=0s 384 HMAC-256(DSK,DHE)= HMAC-256(DSK,0s) 386 4.7 HBSK: HMAC from Binder Key Secret 388 Tx: CLA INS=TLS13 P1=0 P2=HBSK P3=Data-Length [Data] 389 Rx: [HMAC(FSK,data)] 9000 391 4.7.1 Example 393 Tx: CLA=00 INS=85 P1=00 P2=0C P3=01 00 394 Rx: 3E015D850B89C2470D4C49D4BD8E7C76F2B74175DDD85F393569315DA15480A4 396 Data=NULL=0s 397 HMAC-256(FSK,Data)= HMAC-256(DSK,0s) 399 5 IANA Considerations 401 TODO 403 6 Security Considerations 405 TODO 406 7 References 408 7.1 Normative References 410 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 411 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 412 https://www.rfc-editor.org/info/rfc8446. 414 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 415 Expand Key Derivation Function (HKDF)", RFC 5869, DOI 416 10.17487/RFC5869, May 2010, 417 . 419 [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards 420 with Contacts", The International Organization for Standardization 421 (ISO). 423 7.2 Informative References 425 8 Authors' Addresses 427 Pascal Urien 428 Telecom Paris 429 19 place Marguerite Perey 430 91120 Palaiseau Phone: NA 431 France Email: Pascal.Urien@telecom-paris.fr