idnits 2.17.1 draft-schmaus-kitten-sasl-ht-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 -- The document date (September 29, 2017) is 2391 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-19 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7613 (Obsoleted by RFC 8265) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: April 2, 2018 September 29, 2017 7 The Hashed Token SASL Mechanism 8 draft-schmaus-kitten-sasl-ht-01 10 Abstract 12 This document specifies a SASL mechanism designed to be used with 13 short-lived, exclusively ephemeral tokens. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 2, 2018. 32 Copyright Notice 34 Copyright (c) 2017 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 51 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 52 2. The HT-* Family of Mechanisms . . . . . . . . . . . . . . . . 3 53 3. The HT Mechanism . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Initiator First Message . . . . . . . . . . . . . . . . . 4 55 3.2. Final Responder Message . . . . . . . . . . . . . . . . . 5 56 4. Compliance with SASL Mechanism Requirements . . . . . . . . . 5 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 61 7.2. Informative References . . . . . . . . . . . . . . . . . 8 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 This section specifies the the family of Hashed Token (HT-*) SASL 68 mechanisms. It provides hash agility, mutual authentication and is 69 secured by channel binding. 71 This mechanism was designed to be used with short-lived tokens for 72 quick, one round-trip, re-authentication of a previous session. 73 Clients are supposed to request such tokens from the server after 74 being authenticated using a "strong" SASL mechanism (e.g. SCRAM). 75 Hence a typical sequence of actions using SASL-HT may look like the 76 following: 78 A) Client authenticates using a strong mechanism (e.g., SCRAM) 79 B) Client requests secret SASL-HT token 80 81 C) Connection between client and server gets interrupted 82 (e.g., WiFi <-> GSM switch) 83 D) Client resumes previous session using the token from B 84 E) Client requests secret SASL-HT token 85 [goto C] 87 An example application protocol specific extension based on SASL-HT 88 is [XEP-ISR-SASL2]. 90 Since the token is not salted, and only one hash iteration is used, 91 the HT-* mechanism is not suitable to protect long-lived shared 92 secrets (e.g. "passwords"). You may want to look at [RFC5802] for 93 that. 95 1.1. Conventions and Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*", 102 "*WOULD PROBABLY*", "*SHOULD CONSIDER*", and "*MUST (BUT WE KNOW YOU 103 WON'T)*" in this document are to interpreted as described in RFC 6919 104 [RFC6919]. 106 1.2. Applicability 108 Because this mechanism transports information that should not be 109 controlled by an attacker, the HT-* mechanism MUST only be used over 110 channels protected by TLS, or over similar integrity-protected and 111 authenticated channels. In addition, when TLS is used, the client 112 MUST successfully validate the server's certificate ([RFC5280], 113 [RFC6125]). 115 The family of HT-* mechanisms is not applicable for proxy 116 authentication, since they can not carry a authorization identity 117 string (authzid). 119 2. The HT-* Family of Mechanisms 121 Each mechanism in this family differs by the choice of the hash 122 algorithm and the choice of the channel binding [RFC5929] type. 124 A HT mechanism name is a string beginning with "HT-" followed by the 125 capitalized name of the used hash, followed by "-", and suffixed by 126 one of 'ENDP' and 'UNIQ'. 128 Hence each HT mechanism has a name of the following form: 130 HT-- 132 Where is the capitalized "Hash Name String" of the IANA 133 "Named Information Hash Algorithm Registry" [iana-hash-alg] as 134 specified in [RFC6920], and is one of 'ENDP' or 'UNIQ' 135 denoting the channel binding type. In case of 'ENDP', the tls- 136 server-end-point channel binding type is used. In case of 'UNIQ', 137 the tls-unique channel binding type is used. Valid channel binding 138 types are defined in the IANA "Channel-Binding Types" registry 139 [iana-cbt] as specified in [RFC5056]. 141 +------+----------------------+ 142 | CBT | Channel Binding Type | 143 +------+----------------------+ 144 | ENDP | tls-server-end-point | 145 | UNIQ | tls-unique | 146 +------+----------------------+ 148 Mapping of CBT to Channel Bindings 150 The following table lists the HT-* SASL mechanisms registered this 151 document. 153 +------------------+----------------+-------------------------------+ 154 | Mechanism Name | Hash Algorithm | Channel-binding unique prefix | 155 +------------------+----------------+-------------------------------+ 156 | HT-SHA-512-ENDP | SHA-512 | tls-server-end-point | 157 | HT-SHA-512-UNIQ | SHA-512 | tls-unique | 158 | HT-SHA3-512-ENDP | SHA3-512 | tls-server-end-point | 159 | HT-SHA-256-UNIQ | SHA-256 | tls-unique | 160 +------------------+----------------+-------------------------------+ 162 Defined HT-* SASL mechanisms 164 3. The HT Mechanism 166 The mechanism consists of a simple exchange of exactly two messages 167 between the initiator and responder. 169 The following syntax specifications use the Augmented Backus-Naur 170 form (ABNF) notation as specified in [RFC5234]. 172 3.1. Initiator First Message 174 The HT-* SASL mechanism starts with the initiator-msg, send by the 175 initiator to the responder. 177 initiator-msg = authcid-length authcid-data initiator-hashed-token 179 authcid-length = 4OCTET 181 authcid-data = 1*OCTET 183 initiator-hashed-token = 1*OCTET 185 The initiator message starts with an unsigned 32-bit integer in big 186 endian. It denotes length of the authcid-data, which contains the 187 authentication identity. Before sending the authentication identity 188 string the initiator SHOULD prepare the data with the 189 UsernameCaseMapped profile of [RFC7613]. 191 The initiator-hashed-token value is defined as: HMAC(token, 192 "Initiator" || cb-data) 194 HMAC() is the function defined in [RFC2104] with H being the selected 195 HT-* hash algorithm, 'cb-data' represents the data provided by the 196 channel binding type, and 'token' are the UTF-8 encoded octets of the 197 token string which acts as shared secret between initiator and 198 responder. 200 The initiator-msg MUST NOT be included in TLS 1.3 0-RTT early data 201 (see [I-D.ietf-tls-tls13]). 203 TODO: Add note why HMAC() is always involved, even if HMAC() is 204 usually not required when modern hash algorithms are used. 206 3.2. Final Responder Message 208 This message is followed by a message from the responder to the 209 initiator. This 'responder-msg' is defined as follows: 211 responder-msg = 1*OCTET 213 The responder-msg value is defined as: HMAC(token, "Responder" || cb- 214 data) 216 The initiating entity MUST verify the responder-msg to achieve mutual 217 authentication. 219 4. Compliance with SASL Mechanism Requirements 221 This section describes compliance with SASL mechanism requirements 222 specified in Section 5 of [RFC4422]. 224 1. "HT-SHA-256-ENDP", "HT-SHA-256-UNIQ", "HT-SHA-3-512-ENDP" and 225 "HT-SHA-3-512-UNIQ". 227 2. Definition of server-challenges and client-responses: 229 a HT is a client-first mechanism. 231 b HT does not send additional data with success. 233 3. HT is capable of transferring authorization identities from the 234 client to the server. 236 4. HT does not offer any security layers (HT offers channel binding 237 instead). 239 5. HT does not protect the authorization identity. 241 5. Security Considerations 243 To be secure, HT-* MUST be used over a TLS channel that has had the 244 session hash extension [RFC7627] negotiated, or session resumption 245 MUST NOT have been used. 247 6. IANA Considerations 249 IANA has added the following family of SASL mechanisms to the SASL 250 Mechanism registry established by [RFC4422]: 252 To: iana@iana.org 253 Subject: Registration of a new SASL family HT 255 SASL mechanism name (or prefix for the family): HT-* 256 Security considerations: 257 Section FIXME of draft-schmaus-kitten-sasl-ht-00 258 Published specification (optional, recommended): 259 draft-schmaus-kitten-sasl-ht-00 (TODO) 260 Person & email address to contact for further information: 261 IETF SASL WG 262 Intended usage: COMMON 263 Owner/Change controller: IESG 264 Note: Members of this family MUST be explicitly registered 265 using the "IETF Review" [@!RFC5226] registration procedure. 266 Reviews MUST be requested on the Kitten WG mailing list 267 (or a successor designated by the responsible 268 Security AD). 270 7. References 272 7.1. Normative References 274 [I-D.ietf-tls-tls13] 275 Rescorla, E., "The Transport Layer Security (TLS) Protocol 276 Version 1.3", draft-ietf-tls-tls13-19 (work in progress), 277 March 2017. 279 [iana-cbt] 280 Williams, N., "IANA Channel-Binding Types", 2010, 281 . 284 [iana-hash-alg] 285 Williams, N., "IANA Named Information Hash Algorithm 286 Registry", 2010, . 289 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 290 Hashing for Message Authentication", RFC 2104, 291 DOI 10.17487/RFC2104, February 1997, 292 . 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, 296 DOI 10.17487/RFC2119, March 1997, 297 . 299 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 300 Authentication and Security Layer (SASL)", RFC 4422, 301 DOI 10.17487/RFC4422, June 2006, 302 . 304 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 305 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 306 . 308 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 309 Specifications: ABNF", STD 68, RFC 5234, 310 DOI 10.17487/RFC5234, January 2008, 311 . 313 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 314 Housley, R., and W. Polk, "Internet X.509 Public Key 315 Infrastructure Certificate and Certificate Revocation List 316 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 317 . 319 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 320 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 321 . 323 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 324 Verification of Domain-Based Application Service Identity 325 within Internet Public Key Infrastructure Using X.509 326 (PKIX) Certificates in the Context of Transport Layer 327 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 328 2011, . 330 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 331 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 332 DOI 10.17487/RFC6919, April 2013, 333 . 335 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 336 Keranen, A., and P. Hallam-Baker, "Naming Things with 337 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 338 . 340 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 341 Enforcement, and Comparison of Internationalized Strings 342 Representing Usernames and Passwords", RFC 7613, 343 DOI 10.17487/RFC7613, August 2015, 344 . 346 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 347 Langley, A., and M. Ray, "Transport Layer Security (TLS) 348 Session Hash and Extended Master Secret Extension", 349 RFC 7627, DOI 10.17487/RFC7627, September 2015, 350 . 352 7.2. Informative References 354 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 355 "Salted Challenge Response Authentication Mechanism 356 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 357 DOI 10.17487/RFC5802, July 2010, 358 . 360 [XEP-ISR-SASL2] 361 Schmaus, F., "XEP-XXXX: Instant Stream Resumption", 2017, 362 . 365 Appendix A. Acknowledgments 367 Thanks to Thijs Alkemade. 369 Authors' Addresses 371 Florian Schmaus 372 University of Erlangen-Nuremberg 374 Email: schmaus@cs.fau.de 375 Christoph Egger 376 University of Erlangen-Nuremberg 378 Email: egger@cs.fau.de