idnits 2.17.1 draft-jay-tls-psk-identity-extension-02.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 == Line 229 has weird spacing: '...ecision in...' == Line 354 has weird spacing: '...eviated hands...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Clients and Servers wishing to use this extension should include an extension of type "psk_identity" in their extended Client and Server Hellos. Please note that, Server MUST include this extension only if the received Client Hello had this extension, else the same MUST not be included. And server MUST include this extension only if it selects any PSK cipher. Similarly, a Server not wishing to negotiate the PSK Identity as a part of Hello Messages can ignore this extension. If server wishes to include this extension as a part of server hello message, then it MUST include only one psk_identity in the extension data. -- The document date (December 15, 2016) is 2689 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) == Missing Reference: 'UTF8' is mentioned on line 317, but not defined == Unused Reference: 'RFC4785' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'RFC5485' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC6066' is defined on line 419, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5485 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group J Kuppannan 3 INTERNET-DRAFT Juniper 4 Intended Status: Standard Track R Ashok 5 Expires: June 15, 2017 Huawei 6 December 15, 2016 8 TLS/DTLS PSK Identity Extension 9 draft-jay-tls-psk-identity-extension-02 11 Abstract 13 Pre-Shared Key (PSK) based Key Exchange Mechanism is primarily used 14 in constrained environments where resource intensive Asymmetric 15 Cryptography cannot be used. In the Internet of Things (IoT) 16 deployments, constrained devices are commonly used for collecting 17 data via sensors for use in home automation, smart energy etc. In 18 this context, DTLS is being considered as the primary protocol for 19 communication security at the application layer and in some cases, it 20 is also being considered for network access authentication. 22 This document provides a specification for a new extension for 23 Optimizing DTLS and TLS Handshake when the Pre-Shared Key (PSK) based 24 Key Exchange is used. This extension is aimed at reducing the number 25 of messages exchanged and the RTT of the TLS & DTLS Handshakes. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Applicability Statement . . . . . . . . . . . . . . . . . . 3 67 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2 PSK based (D)TLS Handshake . . . . . . . . . . . . . . . . . . 4 69 3 Existing Mechanism of [D]TLS Cipher Negotiation . . . . . . . . 4 70 4 Drawbacks in existing PSK handshake . . . . . . . . . . . . . . 5 71 4.1 Drawback in existing PSK Cipher Negotiation . . . . . . . . 5 72 4.2 Scope of reducing RTT in PSK handshake . . . . . . . . . . 6 73 5 Optimized PSK handshake . . . . . . . . . . . . . . . . . . . . 6 74 5.1 PSKIdentityExtention Type . . . . . . . . . . . . . . . . . 6 75 5.2 PSK Identity Extension Data Specification . . . . . . . . . 6 76 5.3 Abbreviated Handshake . . . . . . . . . . . . . . . . . . . 8 77 5.4 Benefits of Abbreviated Handshake . . . . . . . . . . . . . 8 78 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 79 6.1 Identity Privacy . . . . . . . . . . . . . . . . . . . . . . 9 80 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 81 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 82 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 84 9.2 Informative References . . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 87 1 Introduction 89 RFC 4279 describes the usage of Pre-Shared Key (PSK) based Cipher 90 Suites in TLS. PSK cipher suite can avoid the need for public key 91 operations. This is useful for all those cases where TLS or DTLS are 92 used in resource constrained environments with limited CPU power and 93 memory. The advancements in Internet of Things (IoT) domain where 94 many constrained devices are involved has brought more limelight on 95 DTLS and particularly on the usage of PSK based cipher suites in 96 DTLS. CoAP (RFC 7252), which is one among the preferred application 97 layer protocols for IoT, mandates the use of DTLS for communication 98 security and specifies Pre-Shared Key among others as the preferred 99 key exchange mechanism. 101 Generally both Client and Server may have multiple Pre-Shared Keys 102 configured for communicating with different parties. As part of PSK 103 handshake, PSK ID send in client key exchange helps both the entity 104 to negotiate the Pre-Share Key which needs to be used. This document 105 defines a new Hello message extension for proposing and finalizing 106 the Pre-Shared key to be used between Client and Server. This new 107 extension helps in reducing the number of independent messages 108 exchanged and also in reducing the RTT for the entire handshake 109 routine. 111 This document currently focuses only on [D]TLS 1.2 and prior protocol 112 versions(TLS 1.1, TLS 1.0 and DTLS 1.0). TLS 1.3 (work in-progress) 113 also considers including a similar extension as the one proposed 114 here. But that TLS 1.3 extension cannot be used in lower version. So 115 a similar extension is proposed in this document, which is totally a 116 new and different extension compared to the PreSharedKey extension in 117 TLS 1.3. In future also not all system in world will be running 118 [D]TLS 1.3. So proposing this new extension in older version of 119 [D]TLS is beneficial. 121 The reader is expected to be familiar with TLS PSK based Handshake 122 though an overview is given in the below sections. 124 1.1 Applicability Statement 126 The idea proposed in this document is applicable for all types of PSK 127 cipher suites (PSK, DHE_PSK, RSA_PSK and ECDHE_PSK) defined in RFC 128 4279, RFC 4785 and RFC 5489. 130 1.2 Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 136 2 PSK based (D)TLS Handshake 138 PSK Key Exchange Algorithm and handshake sequence is listed in 139 section 2 of RFC "Pre-Shared Key Cipher suites for Transport Layer 140 Security" [RFC4279]. A basic overview is listed below for reference. 142 Incase of a PSK based handshake, the client indicate its willingness 143 to use pre-shared Key authentication by including one or more PSK 144 cipher suites in the Client Hello message. If the Server also wants 145 to use pre-shared keys, it selects one of the PSK cipher suites and 146 places the selected cipher suite in the Server Hello Message. 148 Both Client and Server may have pre-shared keys with several 149 different parties. The client indicates which key to use by including 150 a "PSK Identity" in the ClientKeyExchange message. To help the client 151 in selecting which key to use, server can provide a "PSK Identity 152 Hint" in the ServerKeyExchange message. If no hint is provided, the 153 ServerKeyExchange message can be omitted. 155 The (D)TLS PSK Handshake is shown below. "*" indicates situation 156 dependent messages. 158 Client Server 159 ------ ------ 160 ClientHello --------> 162 ServerHello 163 (Certificate) 164 ServerKeyExchange* 165 [with PSK Identity Hint] 166 (CertificateRequest) 167 <-------- ServerHelloDone 169 (Certificate) 170 ClientKeyExchange 171 [with PSK Identity] 172 (CertificateVerify) 173 ChangeCipherSpec 174 Finished --------> 176 ChangeCipherSpec 177 <-------- Finished 179 3 Existing Mechanism of [D]TLS Cipher Negotiation 180 In [D]TLS a cipher suite represents authentication algorithm, key 181 exchange algorithm and data protection algorithm (Encryption and 182 MAC). Client Hello and Server Hello message of TLS handshake 183 negotiates the cipher suite for a connection. At first client sends 184 the list of supported ciphers in its "Client Hello" message. On 185 receiving this message, server selects one among them and sends back 186 in its "Server Hello" message. At this stage, server selects cipher 187 based on its priority and its supportability. Here server checks the 188 supportability of a cipher, based on the availability of that 189 algorithm and the credential required for that algorithm. 191 Server does the below task to find out the supportability of a cipher 192 before selecting it. 193 a) Authentication algorithm : If it is certificate (RSA, DSA, 194 ECDSA) based authentication, it checks whether it can support that 195 crypto algorithm and it has a X509 certificate and private key. If 196 it is PSK based authentication, it checks whether it supports PSK 197 based authentication for its client. 198 b) Key exchange algorithm : If it is a Diffie-Hellman (DHE, ECHDE) 199 based key exchange, it checks whether it can support that crypto 200 algorithm. If it is RSA certificate based key exchange, it checks 201 whether it supports RSA data encryption and decryption. 202 c) Data protection algorithm : It checks whether it can support 203 that crypto algorithm (Encryption with MAC or AEAD). 205 4 Drawbacks in existing PSK handshake 207 4.1 Drawback in existing PSK Cipher Negotiation 209 Consider a client and a server can support both PSK based cipher and 210 Certificate based cipher. In this case client sends PSK based and 211 Certificate based cipher in its client hello message. If a server 212 selects PSK cipher then during 2nd RTT client reveals its PSK 213 Identity in Client Key exchange message. At this time if that PSK ID 214 is not known to server, then it fails. So selecting PSK cipher 215 without knowing Client's PSK Identity is not beneficial if both 216 entity can support other types of cipher. 218 Similar problem is there in certificate based cipher, which has been 219 solved by "trusted_ca_keys" extension. Server might be holding 220 multiple certificates issued by different CA. Server can choose any 221 one of them and send it to client. But if client is not having that 222 corresponding CA certificate, then handshake fails. For preventing 223 this late failure, there is a "trusted_ca_keys" extension specified 224 in RFC6066. In this extension, client can send the details about all 225 the CA certificate which it possess. Based on that server selects 226 certificate based cipher only if it holds any end entity certificate 227 issued by any one of the CA known to client. So basically this 228 "trusted_ca_keys" extension provides additional information about the 229 client's capability, this helps server to take right decision in 230 cipher selection. 232 Similar feasibility is not there for PSK cipher, because of this we 233 are not able to prevent the late handshake failure. So if a client 234 can sends its PSK ID in a new extension in its client hello message, 235 then it would be more helpful for cipher selection in server. 237 4.2 Scope of reducing RTT in PSK handshake 239 If a client can send its PSK ID (or list of PSK ID) in its client 240 hello, then server can respond back the selected PSK ID in its server 241 hello. So no need of sending client key exchange message. This can 242 make the [D]TLS handshake as 1 RTT. This is applicable only for the 243 PSK cipher which performs both authentication and key exchange using 244 PSK (not for DHE_PSK, RSA_PSK and ECDHE_PSK). 246 5 Optimized PSK handshake 248 To avoid the drawbacks mentioned in the above section and also to 249 reduce the number of messages exchanged and the round trip time for 250 the handshake, it will be better if both the Client and Server have 251 the ability to negotiate in the hello message, about which pre-shared 252 Key to use among the set of pre-shared keys available with them. This 253 document proposes a new extension for providing this ability to 254 clients and servers. 256 5.1 PSKIdentityExtention Type 258 This document defines a new extension type (psk_identity(TBD)), which 259 is used in the ClientHello and ServerHello messages. The extension 260 type is specified as follows: 262 enum { 263 psk_identity(TBD), (65535) 264 }ExtensionType; 266 This psk_identity extension is similar to the PreSharedKeyExtension 267 proposed in TLS 1.3, but not same. 269 5.2 PSK Identity Extension Data Specification 271 PSK Identity extension allows the client and server to negotiate the 272 PSK Identity which needs to be used for the current session. Clients 273 supporting this extension should include it in their client hello 274 message and list all the PSK Identities they possess as a part of 275 this extension. Clients MAY alternately list only a subset of 276 identities they possess. 278 Server on receiving this extension should parse through the 279 identities in the list, select one among them depending upon it's own 280 list of identities and include it as a part of PSK Identity extension 281 in the Server Hello. If none of identities sent by client match with 282 the list available at the server, it SHOULD choose a Non-PSK cipher 283 or abort the connection with "No Shared Ciphers" alert. 285 Clients and Servers wishing to use this extension should include an 286 extension of type "psk_identity" in their extended Client and Server 287 Hellos. Please note that, Server MUST include this extension only if 288 the received Client Hello had this extension, else the same MUST not 289 be included. And server MUST include this extension only if it 290 selects any PSK cipher. Similarly, a Server not wishing to negotiate 291 the PSK Identity as a part of Hello Messages can ignore this 292 extension. If server wishes to include this extension as a part of 293 server hello message, then it MUST include only one psk_identity in 294 the extension data. 296 The extension data field for this extension SHALL contain the 297 following: 299 opaque psk_identity<1..2^16-1>; 301 struct{ 302 select (Role){ 303 case client: 304 psk_identity identity_list<1..2^16-1>; 305 case server: 306 psk_identity identity; 307 } 308 }PSKIdentityExtension; 310 If client receives a server hello with PSK cipher and without PSK ID 311 extension, then it MUST perform the legacy PSK handshake as specified 312 in RFC 4279. If client receives a server hello message with Non-PSK 313 cipher but with PSKIdentity Extension or if the server hello contains 314 a psk identity not from the list sent by client, then it MUST fail 315 the handshake with illegal parameter alert. 317 The PSK identity send in identity_list MUST be UTF-8 [UTF8] format, 318 as specified in Section 5.1 of RFC 4279. 320 5.3 Abbreviated Handshake 322 Once the client and server have negotiated the Pre-Shared Key Cipher 323 and Identity to be used through the Client Hello and Server Hello 324 message extensions as discussed in the previous section, server can 325 directly send the Change Cipher Spec and Finished Messages. 326 ServerKeyExchange and ClientKeyExchange messages can be avoided 327 completely as the information exchanged in those messages are now 328 already exchanged using hello extensions. 330 The handshake flow, similar to that of session resumption can be used 331 here. On receiving the client hello, the server responds with a 332 server hello, followed by change cipher spec and finished message. 333 Client on receiving server hello, change cipher spec and finished 334 message, responds with its own change cipher spec and finished 335 messages. 337 The abbreviated handshake is presented below: 339 Client Server 340 ------ ------ 341 ClientHello 342 (with list of PSK 343 Identities in extn) --------> 345 ServerHello 346 with selected PSK 347 Identity in extn) 348 ChangeCipherSpec 349 <-------- Finished 351 ChangeCipherSpec 352 Finished --------> 354 This abbreviated handshake is not applicable for cipher which uses 355 PSK only for authentication (DHE_PSK, RSA_PSK, ECDHE_PSK). Because 356 here server key exchange and client key exchange messages are 357 required to exchange the parameters of DHE, RSA or ECDHE. 359 5.4 Benefits of Abbreviated Handshake 361 The above flow effectively reduces the round trip time for PSK Cipher 362 handshake from 2 to 1. The number of messages exchanged is also 363 reduced from 9 to 6. For DHE_PSK, RSA_PSK and ECDHE_PSK cipher this 364 extension gives more information about the PSK key it possess during 365 cipher selection. 367 Incase of unmatched pre-shared key scenario, earlier the error gets 368 discovered by server only after receiving the Client Key Exchange 369 message. This procedure helps in early detection of pre-shared key 370 mismatch and helps the server in making an informed decision about 371 cipher selection. 373 6 Security Considerations 375 General security considerations for DTLS and TLS are covered in 376 [RFC5246] and [RFC6347]. 378 6.1 Identity Privacy 380 All (or subset of) the PSK Identities held by the client are sent in 381 the clear text. It should be noted that this doesn't introduce any 382 new security concern as an attacker who has the capacity to sniff the 383 traffic sent by client can get the list of all identities possessed 384 by it by capturing and analyzing the traffic flowing from client to 385 various servers. 387 7 IANA Considerations 389 IANA is requested to add an entry to the existing TLS ExtensionType 390 registry, defined in TLS [RFC5246], for the new psk_identity 391 extension defined in this document. 393 we recommend to IANA to consider the value of 10015 for the 394 psk_identity extension. 396 8 Acknowledgements 398 We would like to thank Nikos Mavrogiannopoulos and David Woodhouse 399 for their inputs towards this document. 401 9 References 403 9.1 Normative References 405 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, March 1997. 408 [RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key 409 Ciphersuites for Transport Layer Security (TLS)", 410 RFC 4279, December 2005. 412 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 413 Ciphersuites with NULL Encryption for Transport Layer 414 Security (TLS)", RFC 4785, January 2007. 416 [RFC5485] Housley, R., "Digital Signatures on Internet-Draft 417 Documents", RFC 5485, March 2009. 419 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 420 Extensions: Extension Definitions", RFC 6066, January 421 2011. 423 9.2 Informative References 425 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 426 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 428 [RFC6347] E. Rescorla and N. Modadugu, "Datagram Transport Layer 429 Security Version 1.2", RFC 6347, January 2012. 431 Authors' Addresses 433 Jayaraghavendran Kuppannan 434 Juniper Networks 435 Elnath-Exora Business Park, 436 Prestige Tech Park, Marathalli, 437 Bengaluru, India 439 EMail: jayaraghavendran.ietf@gmail.com 441 Raja Ashok V K 442 Huawei Technologies 443 Divyasree Tech Park, 444 Whitefield, 445 Bengaluru, India 447 EMail: raja.ashok@huawei.com