idnits 2.17.1 draft-vanrein-diameter-sasl-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 190: '...ue of the seskey MAY be locally determ...' RFC 2119 keyword, line 191: '... SHOULD be a random seed that can se...' RFC 2119 keyword, line 225: '...2-bit range. It MUST be validated by ...' RFC 2119 keyword, line 229: '... key. Therefore, the SASL client MUST...' RFC 2119 keyword, line 240: '...ntinue. These values MUST be verified...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 365 has weird spacing: '... name is th...' -- The document date (May 25, 2019) is 1796 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) == Unused Reference: 'RFC3961' is defined on line 494, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Van Rein 3 Internet-Draft ARPA2.net 4 Intended status: Standards Track May 25, 2019 5 Expires: November 26, 2019 7 Realm Crossover for SASL via Diameter 8 draft-vanrein-diameter-sasl-02 10 Abstract 12 SASL is used for authentication in many application protocols. This 13 specification extends it to allow credentials from a home realm to be 14 used against external services. To this end, it introduces a secure 15 end-to-end wrapper for SASL traffic and a link back from to the home 16 realm based on Diameter. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 26, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. The SASL crossover mechanism SXOVER . . . . . . . . . . . . . 3 54 2.1. SXOVER initial response . . . . . . . . . . . . . . . . . 4 55 2.2. SXOVER initial challenge . . . . . . . . . . . . . . . . 5 56 2.3. SXOVER responses . . . . . . . . . . . . . . . . . . . . 6 57 2.4. SXOVER challenges . . . . . . . . . . . . . . . . . . . . 6 58 3. Embedding SASL in Diameter . . . . . . . . . . . . . . . . . 7 59 3.1. AVP Definitions for SASL . . . . . . . . . . . . . . . . 7 60 3.1.1. SASL-Mechanism . . . . . . . . . . . . . . . . . . . 7 61 3.1.2. SASL-Token . . . . . . . . . . . . . . . . . . . . . 8 62 3.1.3. SASL-Channel-Binding . . . . . . . . . . . . . . . . 8 63 4. Running Diameter as a SASL Backend . . . . . . . . . . . . . 8 64 4.1. Diameter is an SCTP service . . . . . . . . . . . . . . . 9 65 4.2. Reliance on DANE and DNSSEC . . . . . . . . . . . . . . . 9 66 4.3. Foreign Service SASL Mechanisms . . . . . . . . . . . . . 10 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 7.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 It is common for Internet users to combine services from a varierity 78 of providers. Along with this, an ad hoc practice has arisen of 79 using the local identity schemes of these providers. These are not 80 integrated, and the practice tends to reduce the control of users 81 over their online identity. A solution to this is generic support 82 for realm crossover, where an externally acquired service can make a 83 callback to a home realm to authenticate a user's identity and use 84 that for service-specific authorisation. 86 SASL [RFC4422] is instrumental in authentication across a wide range 87 of application protocols; it allows those protocols to abstract from 88 the actual authentication mechanisms, and at the same time it allows 89 authentication mechanisms to not be concerned about the application 90 protocol. SASL can easily be funneled from one protocol into 91 another, modulo a number of security concerns. 93 Diameter and its Network Access application are instrumental in 94 authenticating a user under a realm, while not providing the 95 resources that an application protocol would imply. Moreover, 96 Diameter service can be declared under a domain name in a manner that 97 is standardised, scalable and secure. 99 This allows a foreign server to authenticate a client to authenticate 100 with its home realm: 102 +--------+ SASL +--------+ SASL +---------+ 103 | Client |-----------> | Server | ---------> | Realm | 104 +--------+ AppProto +--------+ Diameter +---------+ 105 || || || 106 john@example.com find SRV, TLSA example.com 107 & credential relay SASL authentication 109 Diameter can send a mere notification of authentication, and the 110 foreign server can use DANE [RFC6698] to validate the origin of these 111 notification. Diameter in the foreign server will authenticate to 112 the home realm, which may then decide to add resources beyond the 113 basic notification of authentication. 115 SASL mechanisms are not generally protected against attacks by men in 116 the middle named Eve. This is usually compensated for by wrapping 117 the application protocol in TLS, but since that would only protect 118 one leg of the intended realm crossover, this raises a need for end- 119 to-end encryption. This can be established along with other 120 credentials for the home realm, but an end-to-end mechanism needs to 121 be defined. This specification introduces a wrapper for that pupose, 122 and nests a SASL exchange with the home realm under its cloak. 124 Finally, to avoid the use of one authentication exchange to validate 125 another, it is advisable to incorporate channel binding [RFC5056] 126 [RFC5801] when making use of backends. When passing SASL tokens 127 between application protocol and Diameter backend, the channel 128 binding information from the application protocol would be supplied 129 as a side-note to the Diameter backcall. 131 2. The SASL crossover mechanism SXOVER 133 SXOVER is a SASL authentication mechanism that encrypts all 134 information between a SASL client and SASL server, except for the 135 realm name to which they direct the authentication. The realm can be 136 used by an foreign server to redirect SXOVER to a home realm, for 137 instance using Diameter. SXOVER does not reveal success or failure 138 to this foreign server, but Diameter would release this information 139 in a manner that requires no knowledge of the SASL exchange. 141 The first SXOVER message supplies a session key to the SASL server. 142 The server responds with a list of SASL mechanisms to be used under 143 the cloak of the session key. Then, the client selects a mechanism 144 and the customary exchange follows, but under protection of the 145 session key. 147 Certain information in SXOVER is encrypted with the encrypt operation 148 [Section 3 of [RFC3961]] with default initial state; this always 149 includes integrity protection. The value for key usage is 150 KIP_KEYUSAGE_MAPPING or 1864 for the long-term key and 151 KIP_KEYUSAGE_USERDATA of 1863 for the session key; these values and 152 the formats exchanged are compatible with the Keyful Identity 153 Protocol, which may or may not develop independently of SXOVER. 155 2.1. SXOVER initial response 157 The SXOVER exchange starts with an initial response message, 158 traveling along the selection of SXOVER as the SASL mechanism. This 159 initial response contains the following: 161 SXOVER-Initial-Response ::= SEQUENCE { 162 realm IA5String, -- Lowercase domain name, no trailing dot 163 inictr Counter, -- Initial counter value 164 keyno KeyNumber, -- With realm and encalg, identifies... 165 encalg EncryptAlg, -- ...the key for svckeymud decryption 166 seskey OCTET STRING -- RFC 3961 encrypted, key usage 1864 167 } 169 Counter ::= INTEGER (0..4294967295) -- Unsigned 32-bit 170 KeyNumber ::= INTEGER (0..4294967295) -- Unsigned 32-bit 171 EncryptAlg ::= INTEGER (-2147483648..2147483647) -- Signed 32-bit 173 The one value of interest to the foreign server is the realm, which 174 it needs to determine the home realm of the client. It finds the 175 Diameter service underneath, and starts passing this SASL message and 176 any that follow between the end points. Note that this behaviour is 177 specific to the SXOVER mechanism; it is just as well possible for a 178 foreign server to welcome ANONYMOUS clients, which it can handle 179 locally. 181 The inictr value is used as a bit of entropy, thus making it more 182 difficult to mount replay attacks, though not at the level of 183 security that a proper SASL mechanism can achieve through dynamic 184 challenges and/or channel binding. 186 The keyno and encalg values present identification information for a 187 key at the Diameter/SASL server, and the seskey is a representation 188 of a session key suitable for decryption with that identified key. 190 The value of the seskey MAY be locally determined, but by default it 191 SHOULD be a random seed that can serve as input to the random-to-key 192 function with the required key-generation seed-length [Section 3 of 193 [RFC3961]] for a session key with the same encryption algorithm 194 enctype as the identified key. The random seed is protected by 195 encryption to the identified key using the Encrypt function 196 [Section 3 of [RFC3961]], which always involves authenticity. The 197 key usage number is shared from the independent KIP protocol, and is 198 set to KIP_KEYUSAGE_MAPPING or 1864. 200 2.2. SXOVER initial challenge 202 The initial SXOVER challenge is a server's response in which it 203 presents the choice of mechanism names to use under the cloak of 204 SXOVER. It does not present any other information. The following 205 information is sent as one block under protection of the seskey: 207 SXOVER-Initial-Challenge ::= SEQUENCE { 208 ctr Counter, -- Counter value is inictr+1 209 realm IA5String, -- Confirms the realm securely 210 mechlist SEQUENCE OF IA5String, -- Available SASL mechanisms 211 chanbindmth IA5String, -- TODO:REALLY? 212 -- Method of channel binding 213 chanbindval OCTET STRING -- TODO:REALLY? 214 -- Value for channel binding 215 } 217 This message precedes the SXOVER wrapping of a SASL exchange by first 218 passing the inner SASL mechanisms, which cannot be taken from the 219 list provided by the foreign server. The mechanisms listed here are 220 specific for the home realm of the client, information that could not 221 be known to the foreign server before learning about the targeted 222 realm. 224 The ctr value is simply inictr incremented by 1, with a wrap-around 225 to stay within an unsigned 32-bit range. It MUST be validated by the 226 SASL client. 228 The realm is repeated from the SXOVER request, but this time it is 229 protected by the session key. Therefore, the SASL client MUST 230 validate it before starting the wrapped SASL exchange. 232 The mechlist informs the SASL client of the mechanisms available for 233 authentication against the SASL server. These can be used for the 234 wrapped SASL exchange. The list is not related to any mechanism list 235 that the foreign server will have sent before. Specifically, SXOVER 236 and ANONYMOUS mechanisms should not occur in the wrapped mechlist. 238 TODO: The chanbindmth and chanbindval relay what channel binding 239 information the SASL server obtained, and which can be used by the 240 SASL client if it wants to continue. These values MUST be verified 241 against the actual context first, to ensure that they do represent 242 security requirements. If a mechanism is used that does not include 243 channel binding, then these fields can add some channel binding, but 244 it is invariably better to employ channel binding that is 245 cryptographically bound to the authentication operation. 247 2.3. SXOVER responses 249 Further SXOVER responses are essentially SASL responses and initial 250 responses, encrypted under the seskey, but there is one exception; 251 the first response must select a SASL mechanism. There is a separate 252 provision for sending no data, distinguishable from empty data, if 253 this is desired by the SASL mechanism: 255 SXOVER-Response ::= SEQUENCE { 256 ctr Counter, -- 1 + Previous ctr value 257 c2s SaslToken, -- NULL or token, client to server 258 mechsel IA5String OPTIONAL -- SASL mechanism name selection 259 } 261 SaslToken ::= CHOICE { 262 token OCTET STRING, 263 no-token NULL 264 } 266 This is the first and later of the wrapped SASL messages sent from 267 the client to the server. When it is the first, the mechsel field 268 MUST specify the SASL mechanism that the client selected from the 269 mechsel issued before. In any message, the ctr value is one more 270 than the value in the previous SASL message, reduced to an unsigned 271 32-bit range. 273 The SaslToken in c2s is either a literal OCTET STRING with the SASL 274 token to pass, or it is NULL if no token is passed. This implements 275 a distinction between an empty token and no token, as required for 276 SASL. 278 2.4. SXOVER challenges 280 Further SXOVER challenges are essentially SASL challenges and initial 281 challenges, encrypted under the seskey. There is a separate 282 provision for sending no data, distinguishable from empty data, if 283 this is desired by the SASL mechanism: 285 SXOVER-Challenge ::= SEQUENCE { 286 ctr Counter, -- 1 + Previous ctr value 287 s2c SaslToken, -- NULL or token, server to client 288 extra OCTET STRING OPTIONAL -- On success, optional extra token 289 } 290 This is the first and later of the wrapped SASL messages sent from 291 the server to the client. In any message, the ctr value is one more 292 than the value in the previous SASL message, reduced to an unsigned 293 32-bit range. 295 The SaslToken in s2c is either a literal OCTET STRING with the SASL 296 token to pass, or it is NULL if no token is passed. This implements 297 a distinction between an empty token and no token, as required for 298 SASL. 300 The extra value can be passed along as a hint to the user for a 301 successful authentication. Mechanisms do not commonly use the field, 302 but SASL offers it. The distinction between an empty OCTET STRING 303 and an absent value is assured through the OPTIONAL modifier. Note 304 that this value should not be passed as part of the SXOVER exchange, 305 as it is part of the SASL mechanism that was selected with mechsel in 306 the wrapped exchange. SXOVER does not specify an extra value, so the 307 field in the outer SASL exchange that runs SXOVER will not be used. 309 3. Embedding SASL in Diameter 311 SASL messages in Diameter use a number of AVPs [RFC6733] that are 312 defined for this purposes. They occur in those combinations that are 313 defined for SASL. 315 SASL over Diameter can only be used to relay the SXOVER mechanism to 316 a home realm. This means that no negotiation of mechanisms is needed 317 at the Diameter level; this is handled under the SXOVER cloak. The 318 same holds for any negotation of channel binding; it is part of the 319 cloacked SASL exchange. 321 3.1. AVP Definitions for SASL 323 These AVPs are added to the set that is used with the Network Access 324 application, and can therefore be used in AA-Request and AA-Answer 325 messages. On top of that, the SASL-Mechanisms AVP may also occur in 326 a Capabilities Exchange Answer. The User-Name AVP MUST be supplied 327 in the AA-Answer to inform the server about the user name that the 328 backend decided on; the server MAY send a hint requesting a value in 329 the User-Name AVP in the AA-Request. 331 3.1.1. SASL-Mechanism 333 The SASL-Mechanism AVP has AVP Code TBD0. This specification only 334 uses the mechanism name SXOVER as a value for this AVP. It MUST be 335 included in the first message of an SXOVER exchange sent to the home 336 realm, and it SHOULD be verified by the home realm upon reception. 338 Its purpose is mostly to distinguish this specification from 339 potential future specifications to encapsulate SASL in Diameter. 341 Though not used in this specification, this AVP may also be supplied 342 from the home realm to the Diameter client to hold a space-separated 343 list of SASL mechanisms. 345 3.1.2. SASL-Token 347 The SASL-Token AVP has AVP Code TBD1. Note that SASL requires 348 distinction between empty and absent tokens; absent SASL tokens are 349 represented by absence of the SASL-Token AVP and empty SASL tokens 350 are represented as a present SASL-Token AVP with zero content bytes. 352 3.1.3. SASL-Channel-Binding 354 The SASL-Channel-Binding AVP has AVP Code TBD2. It SHOULD appear 355 along the first SASL-Token AVP for a Network Access session. The AVP 356 may occur more than once, to indicate support of multiple forms of 357 channel binding. 359 When the client connects to the foreign service over TLS, the tls- 360 unique form [RFC5929] of channel binding is RECOMMENDED. Specific 361 foreign servers may however be exempted by the home realm. 363 The contents of this AVP are: 365 name is the standard name of the channel binding information, 366 followed by a zero-valued byte. 368 value contains the bytes of the channel binding information. 370 Normally, channel binding information should be sourced from the 371 underlying communications channel, but this information is not 372 available to backend running Diameter. To enable channel binding 373 between the end points, the foreign server incorporates the channel 374 binding information that the client can use in its connection to the 375 foreign server. This is useful to mitigate replay attacks, which is 376 why its use is RECOMMENDED. Channel binding provides better 377 guarantees than the simple inictr/ctr mechanism used in SXOVER. 379 4. Running Diameter as a SASL Backend 381 Following are a few practical considerations in relation to the 382 Diameter connectivity for SASL. 384 4.1. Diameter is an SCTP service 386 Diameter is primarily an SCTP-based protocol [RFC6733], for reasons 387 of scalabaility and efficiency. SASL Diameter benefits from these 388 properties and embraces the SCTP carrier. Operating system support 389 for SCTP is wide-spread, but parts of network infrastructure may not 390 support it, and that may cause implementations to add a fallback to 391 more traditional protocols. Standards offer two options for doing 392 this. 394 Diameter can fallback to run over TCP, which is mostly of use to 395 client-only machines, but it sacrifices several benefits of the SCTP 396 carrier. Since the SASL Diameter embedding typically involves no 397 client systems, this option is NOT RECOMMENDED. 399 SCTP may be run over a UDP transport using port 9899 [RFC6951], which 400 does not sacrifice much; it only inserts a UDP header before each 401 message. This is a reasonable expectation of foreign servers as well 402 as home realms, so this additional option is RECOMMENDED for 403 situations where a fallback for plain SCTP is desired. It is 404 standardised as a socket option SCTP_REMOTE_UDP_ENCAPS_PORT, and only 405 involves a small repetition in code, with a minor change between the 406 attempts. 408 4.2. Reliance on DANE and DNSSEC 410 Diameter always involves the use of TLS, but there is a number of 411 choices concerning the validation of connections through DNSSEC and 412 DANE. It is the home realm's prerogative what level of protection it 413 upholds for its client identities, but any foreign server can choose 414 to raise the bar by setting a minimum standard. 416 DNSSEC is a useful protection mechanism for the _diameter._sctp SRV 417 records that lead to the Diameter host and its port for the home 418 realm. This does not protect against forged IP addresses, port 419 mappings or routing. To protect against this as well, a TLSA record 420 for the service host and port, along with the _sctp protocol label, 421 should be used as specified for DANE [RFC6698]. 423 Home realms that choose to be light on such measures risk that 424 identities are forged, in spite of their use of TLS. Foreign servers 425 MAY choose to reject such home realms, or alternatively be more 426 inquisitive about the certificates used. 428 4.3. Foreign Service SASL Mechanisms 430 A foreign server MUST offer SXOVER if it wants to support realm 431 crossover via Diameter as specified herein. In addition, it MAY 432 offer SASL mechanisms that it resolves locally. 434 The ANONYMOUS method for SASL [RFC4505] may be offered for guest 435 access. The PLAIN method [RFC4616] continues to be ill-advised, 436 especially with modern methods such as SCRAM [RFC5802] to address the 437 needs of local accounts with password validation. 439 The HTTP protocol does not yet support SASL, and it is not optimal 440 from a security viewpoint to integrate credentials in the dynamic 441 environment of HTML, where dynamic content from potentially 442 undesirable origins come together in a manner not controllable to the 443 end user. One remedy is to use HTTP and its authentication methods 444 that match with SASL, such as SCRAM for HTTP [RFC7804]. Another 445 remedy is to switch to generic SASL embedding in HTTP 446 [TODO:REF:draft-vanrein-httpauth-sasl] and gain replay protection 447 through channel binding. 449 Many application protocols offer richer semantics than HTTP, making 450 them better targets for automation. Their reliance on SASL has made 451 them less tractable as a service to third parties. One reason for 452 introducing SXOVER is in the hope to make it possible to have those 453 semantically rich applications as a third-party offering. 455 5. Security Considerations 457 From the perspective of the client and the home realm, the safety of 458 the SASL credentials is paramount. Since not all SASL mechanisms are 459 safe from inspection by the foreign server, and since TLS cannot help 460 there either, there is a need for some caution. 462 The limitation of the Diameter carrier for SASL to SXOVER reduces 463 this risk, by only authenticating SASL mechanisms under end-to-end 464 encryption between the client and home realm. It is generally 465 understood that clients must not send unprotected SASL authentication 466 attempts to arbitrary parties, but SXOVER adds a facility that is 467 safe for clients to use in this manner. The SXOVER mechanism could 468 even be used without TLS protection. 470 From the perspective of the foreign server, the security concern is 471 to be certain of an identity. The home realm sends this information 472 back when SXOVER authentication succeeds, and the communication doing 473 so is protected with TLS. The certificate of the Diameter server can 474 be validated, and for cautious home realms there could be an 475 additional check based on DANE. 477 6. IANA Considerations 479 This specification defines three AVP Codes for use with Diameter. 480 IANA registers the following AVP Codes for them in the 481 "Authentication, Authorization, and Accounting (AAA) Parameters" 482 registry: 484 AVP Code | Attribute Name | Reference 485 ---------+----------------------+------------ 486 TBD0 | SASL-Mechanism | (this spec) 487 TBD1 | SASL-Token | (this spec) 488 TBD2 | SASL-Channel-Binding | (this spec) 490 7. References 492 7.1. Normative References 494 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 495 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 496 2005, . 498 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 499 Authentication and Security Layer (SASL)", RFC 4422, 500 DOI 10.17487/RFC4422, June 2006, 501 . 503 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 504 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 505 . 507 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 508 Service Application Program Interface (GSS-API) Mechanisms 509 in Simple Authentication and Security Layer (SASL): The 510 GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, 511 July 2010, . 513 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 514 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 515 . 517 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 518 of Named Entities (DANE) Transport Layer Security (TLS) 519 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 520 2012, . 522 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 523 Ed., "Diameter Base Protocol", RFC 6733, 524 DOI 10.17487/RFC6733, October 2012, 525 . 527 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 528 Control Transmission Protocol (SCTP) Packets for End-Host 529 to End-Host Communication", RFC 6951, 530 DOI 10.17487/RFC6951, May 2013, 531 . 533 7.2. Informative References 535 [RFC4505] Zeilenga, K., "Anonymous Simple Authentication and 536 Security Layer (SASL) Mechanism", RFC 4505, 537 DOI 10.17487/RFC4505, June 2006, 538 . 540 [RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and 541 Security Layer (SASL) Mechanism", RFC 4616, 542 DOI 10.17487/RFC4616, August 2006, 543 . 545 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 546 "Salted Challenge Response Authentication Mechanism 547 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 548 DOI 10.17487/RFC5802, July 2010, 549 . 551 [RFC7804] Melnikov, A., "Salted Challenge Response HTTP 552 Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804, 553 March 2016, . 555 Appendix A. Acknowledgements 557 Thanks go to TODO for useful discussions during the creation of this 558 document. 560 Author's Address 562 Rick van Rein 563 ARPA2.net 564 Haarlebrink 5 565 Enschede, Overijssel 7544 WP 566 The Netherlands 568 Email: rick@openfortress.nl