idnits 2.17.1 draft-schmaus-kitten-sasl-ht-07.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 date (November 1, 2019) is 1638 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Common Authentication Technology Next Generation F. Schmaus 3 Internet-Draft C. Egger 4 Intended status: Experimental University of Erlangen-Nuremberg 5 Expires: May 4, 2020 November 1, 2019 7 The Hashed Token SASL Mechanism 8 draft-schmaus-kitten-sasl-ht-07 10 Abstract 12 This document specifies the family of Hashed Token SASL mechanisms 13 which enable a proof-of-possession-based authentication scheme and 14 are meant to be used for quick re-authentication of a previous 15 session. The Hashed Token SASL mechanism's authentication sequence 16 consists of only one round-trip. The usage of short-lived, 17 exclusively ephemeral hashed tokens is achieving the single round- 18 trip property. The SASL mechanism specified herin further provides 19 hash agility, mutual authentication and is secured by channel 20 binding. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 4, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 58 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 59 2. The HT Family of Mechanisms . . . . . . . . . . . . . . . . . 4 60 3. The HT Authentication Exchange . . . . . . . . . . . . . . . 5 61 3.1. Initiator First Message . . . . . . . . . . . . . . . . . 5 62 3.2. Initiator Authentication . . . . . . . . . . . . . . . . 6 63 3.3. Final Responder Message . . . . . . . . . . . . . . . . . 6 64 4. Compliance with SASL Mechanism Requirements . . . . . . . . . 6 65 5. Requirements for the Application-Protocol Extension . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 This specification describes the family of Hashed Token (HT) Simple 77 Authentication and Security Layer (SASL) [RFC4422] mechanisms, which 78 enable a proof-of-possession-based authentication scheme. The HT 79 mechanism is designed to be used with short-lived, exclusively 80 ephemeral tokens, called SASL-HT tokens, and allow for quick, one 81 round-trip, re-authentication of a previous session. 83 Further properties of the HT mechanism are 1) hash agility, 2) mutual 84 authentication, and 3) being secured by channel binding. 86 Clients are supposed to request SASL-HT tokens from the server after 87 being authenticated using a "strong" SASL mechanism like SCRAM 88 [RFC5802]. Hence a typical sequence of actions using HT may look 89 like the following: 91 A) Client authenticates using a strong mechanism (e.g., SCRAM) 92 B) Client requests secret SASL-HT token 93 C) Service returns SASL-HT token 94 95 D) Connection between client and server gets interrupted, 96 for example because of a WiFi <-> GSM switch 97 E) Client resumes the previous session using HT and token from C) 98 F) Service revokes the successfully used SASL-HT token 99 [goto B] 101 The HT mechanism requires an accompanying, application protocol 102 specific, extension, which allows clients to requests a new SASL-HT 103 token (see Section 5). One example for such an application protocol 104 specific extension based on HT is [XEP-0397]. This XMPP [RFC6120] 105 extension protocol allows, amongst other things, B) and C), 107 Since the SASL-HT token is not salted, and only one hash iteration is 108 used, the HT mechanism is not suitable to protect long-lived shared 109 secrets (e.g. "passwords"). You may want to look at [RFC5802] for 110 that. 112 1.1. Conventions and Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 1.2. Applicability 122 Because this mechanism transports information that should not be 123 controlled by an attacker, the HT mechanism MUST only be used over 124 channels protected by Transport Layer Security (TLS, see [RFC5246]), 125 or over similar integrity-protected and authenticated channels. 126 Also, the application protcol specific extension which requests a new 127 SASL-HT token SHOULD only be used over similarly protected channels. 129 Also, when TLS is used, the client MUST successfully validate the 130 server's certificate ([RFC5280], [RFC6125]). 132 The family of HT mechanisms is not applicable for proxy 133 authentication since they can not carry an authorization identity 134 string (authzid). 136 2. The HT Family of Mechanisms 138 Each mechanism in this family differs by choice of the hash algorithm 139 and the choice of the channel binding [RFC5929] type. 141 An HT mechanism name is a string beginning with "HT-" followed by the 142 capitalised name of the used hash, followed by "-", and suffixed by 143 one of 'ENDP' and 'UNIQ'. 145 Hence each HT mechanism has a name of the following form: 147 HT-- 149 Where is the capitalised "Hash Name String" of the IANA 150 "Named Information Hash Algorithm Registry" [iana-hash-alg] as 151 specified in [RFC6920], and is one of 'ENDP' or 'UNIQ' 152 denoting the channel binding type. In the case of 'ENDP', the tls- 153 server-end-point channel binding type is used. In the case of 154 'UNIQ', the tls-unique channel binding type is used. Valid channel 155 binding types are defined in the IANA "Channel-Binding Types" 156 registry [iana-cbt] as specified in [RFC5056]. 158 +---------+----------------------+ 159 | cb-type | Channel Binding Type | 160 +---------+----------------------+ 161 | ENDP | tls-server-end-point | 162 | UNIQ | tls-unique | 163 +---------+----------------------+ 165 Mapping of cb-type to Channel Binding Types 167 The following table lists the HT SASL mechanisms registered by this 168 document. 170 +------------------+------------------+-----------------------------+ 171 | Mechanism Name | HT Hash | Channel-binding unique | 172 | | Algorithm | prefix | 173 +------------------+------------------+-----------------------------+ 174 | HT-SHA-512-ENDP | SHA-512 | tls-server-end-point | 175 | HT-SHA-512-UNIQ | SHA-512 | tls-unique | 176 | HT-SHA3-512-ENDP | SHA3-512 | tls-server-end-point | 177 | HT-SHA-256-UNIQ | SHA-256 | tls-unique | 178 +------------------+------------------+-----------------------------+ 180 Defined HT SASL mechanisms 182 3. The HT Authentication Exchange 184 The mechanism consists of a simple exchange of precisely two messages 185 between the initiator and responder. 187 The following syntax specifications use the Augmented Backus-Naur 188 form (ABNF) notation as specified in [RFC5234]. 190 3.1. Initiator First Message 192 The HT mechanism starts with the initiator-msg, send by the initiator 193 to the responder. The following lists the ABNF grammar for the 194 initiator-msg: 196 initiator-msg = authcid NUL initiator-hashed-token 197 authcid = 1*SAFE ; MUST accept up to 255 octets 198 initiator-hashed-token = 1*OCTET 200 NUL = %0x00 ; The null octet 201 SAFE = UTF1 / UTF2 / UTF3 / UTF4 202 ;; any UTF-8 encoded Unicode character except NUL 204 UTF1 = %x01-7F ;; except NUL 205 UTF2 = %xC2-DF UTF0 206 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / 207 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) 208 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / 209 %xF4 %x80-8F 2(UTF0) 210 UTF0 = %x80-BF 212 The initiator first message starts with the authentication identity 213 (authcid, see[RFC4422]) as UTF-8 [RFC3629] encoded string. It is 214 followed by initiator-hashed-token separated by as single null octet. 216 The value of the initiator-hashed-token is defined as follows: 218 initiator-hashed-token := HMAC(token, "Initiator" || cb-data) 220 HMAC() is the function defined in [RFC2104] with H being the selected 221 HT hash algorithm, 'cb-data' represents the data provided by the 222 selected channel binding type, and 'token' are the UTF-8 encoded 223 octets of the SASL-HT token string which acts as a shared secret 224 between initiator and responder. 226 The initiator-msg MAY be included in TLS 1.3 0-RTT early data, as 227 specified in [RFC8446]. If this is the case, then the initiating 228 entity MUST NOT include any further application protocol payload in 229 the early data besides the HT initiator-msg and potential required 230 framing of the SASL profile. The responder MUST abort the SASL 231 authentication if the early data contains additional application 232 protocol payload. 234 SASL-HT hence allows exploiting TLS 1.3 early data for "0.5 Round 235 Trip Time (RTT)" resumption of the application protocol's session. 236 Using TLS early data requires extra care when implementing: The 237 early data should only contain the SASL-HT payload, i.e., the 238 initiator-msg, and not an application protocol specific payload. 239 The reason for this is that the early data could be replayed, and 240 thus needs to carry an idempotent operation. On the other hand, 241 if the responding entity can verify the early data, then it can 242 send additional application protocol payload together with the 243 "resumption successful" response to the initiating entity. 245 3.2. Initiator Authentication 247 Upon receiving the initiator-msg, the responder calculates itself the 248 value of initiator-hashed-token and compares it with the received 249 value found in the initiator-msg. If both values are equal, then the 250 initiator has been successfully authenticated. Otherwise, if both 251 values are not equal, then authentication MUST fail. 253 If the responder was able to authenticate the initiator, then the 254 used token MUST be revoked immediately. 256 3.3. Final Responder Message 258 After the initiator was authenticated the responder continues the 259 SASL authentication by sending the responder-msg to the initiator. 261 The ABNF for responder-msg is: 263 responder-msg = 1*OCTET 265 The responder-msg value is defined as follows: 267 responder-msg := HMAC(token, "Responder" || cb-data) 269 The initiating entity MUST verify the responder-msg to achieve mutual 270 authentication. 272 4. Compliance with SASL Mechanism Requirements 274 This section describes compliance with SASL mechanism requirements 275 specified in Section 5 of [RFC4422]. 277 1. "HT-SHA-256-ENDP", "HT-SHA-256-UNIQ", "HT-SHA-3-512-ENDP" and 278 "HT-SHA-3-512-UNIQ". 280 2. Definition of server-challenges and client-responses: 282 a HT is a client-first mechanism. 284 b HT does send additional data with success (the responder-msg). 286 3. HT is not capable of transferring authorization identities from 287 the client to the server. 289 4. HT does not offer any security layers (HT offers channel binding 290 instead). 292 5. HT does not protect the authorization identity. 294 5. Requirements for the Application-Protocol Extension 296 It is REQUIRED that the application-protocol specific extension 297 provides a mechanism to request a SASL-HT token in form of a Unicode 298 string. The returned token MUST have been newly generated by a 299 cryptographically secure random number generator and MUST contain at 300 least 128 bit of entropy. 302 It is RECOMMENDED that the protocol allows the requestor to signal 303 the name of the SASL mechanism which he intends to use with the 304 token. If a token is used with a different mechanism than the one 305 which was signalled upon requesting the token, then the 306 authentication MUST fail. This allows pinning the token to a SASL 307 mechanism, which increases the security because it makes it 308 impossible for an attacker to downgrade the SASL mechanism. 310 6. Security Considerations 312 To be secure, the HT mechanism MUST be used over a TLS channel that 313 has had the session hash extension [RFC7627] negotiated, or session 314 resumption MUST NOT have been used. 316 It is RECOMMENDED that implementations periodically require a full 317 authentication using a strong SASL mechanism which does not use the 318 SASL-HT token. 320 It is of vital importance that the SASL-HT token is generated by a 321 cryptographically secure random generator. See [RFC4086] for more 322 information about Randomness Requirements for Security. 324 7. IANA Considerations 326 IANA has added the following family of SASL mechanisms to the SASL 327 Mechanism registry established by [RFC4422]: 329 To: iana@iana.org 330 Subject: Registration of a new SASL family HT 332 SASL mechanism name (or prefix for the family): HT-* 333 Security considerations: 334 Section FIXME of draft-schmaus-kitten-sasl-ht 335 Published specification (optional, recommended): 336 draft-schmaus-kitten-sasl-ht-XX (TODO) 337 Person & email address to contact for further information: 338 IETF SASL WG 339 Intended usage: COMMON 340 Owner/Change controller: IESG 341 Note: Members of this family MUST be explicitly registered 342 using the "IETF Review" [@!RFC5226] registration procedure. 343 Reviews MUST be requested on the Kitten WG mailing list 344 (or a successor designated by the responsible 345 Security AD). 347 8. References 349 8.1. Normative References 351 [iana-cbt] 352 Williams, N., "IANA Channel-Binding Types", 2010, 353 . 356 [iana-hash-alg] 357 Williams, N., "IANA Named Information Hash Algorithm 358 Registry", 2010, . 361 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 362 Hashing for Message Authentication", RFC 2104, 363 DOI 10.17487/RFC2104, February 1997, 364 . 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, 368 DOI 10.17487/RFC2119, March 1997, 369 . 371 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 372 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 373 2003, . 375 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 376 "Randomness Requirements for Security", BCP 106, RFC 4086, 377 DOI 10.17487/RFC4086, June 2005, 378 . 380 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 381 Authentication and Security Layer (SASL)", RFC 4422, 382 DOI 10.17487/RFC4422, June 2006, 383 . 385 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 386 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 387 . 389 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 390 Specifications: ABNF", STD 68, RFC 5234, 391 DOI 10.17487/RFC5234, January 2008, 392 . 394 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 395 (TLS) Protocol Version 1.2", RFC 5246, 396 DOI 10.17487/RFC5246, August 2008, 397 . 399 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 400 Housley, R., and W. Polk, "Internet X.509 Public Key 401 Infrastructure Certificate and Certificate Revocation List 402 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 403 . 405 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 406 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 407 . 409 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 410 Verification of Domain-Based Application Service Identity 411 within Internet Public Key Infrastructure Using X.509 412 (PKIX) Certificates in the Context of Transport Layer 413 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 414 2011, . 416 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 417 Keranen, A., and P. Hallam-Baker, "Naming Things with 418 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 419 . 421 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 422 Langley, A., and M. Ray, "Transport Layer Security (TLS) 423 Session Hash and Extended Master Secret Extension", 424 RFC 7627, DOI 10.17487/RFC7627, September 2015, 425 . 427 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 428 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 429 May 2017, . 431 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 432 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 433 . 435 8.2. Informative References 437 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 438 "Salted Challenge Response Authentication Mechanism 439 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 440 DOI 10.17487/RFC5802, July 2010, 441 . 443 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 444 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 445 March 2011, . 447 [XEP-0397] 448 Schmaus, F., "XEP-0397: Instant Stream Resumption", 2018, 449 . 451 Appendix A. Acknowledgments 453 This document benefited from discussions on the KITTEN WG mailing 454 list. The authors would like to especially thank Thijs Alkemade, Sam 455 Whited and Alexey Melnikov for their comments on this topic. 456 Furthermore, we would like to thank Alexander Wuerstlein, who came up 457 with the idea to pin the token to a SASL mechanism for increased 458 security. 460 Authors' Addresses 462 Florian Schmaus 463 University of Erlangen-Nuremberg 465 Email: schmaus@cs.fau.de 467 Christoph Egger 468 University of Erlangen-Nuremberg 470 Email: egger@cs.fau.de