idnits 2.17.1 draft-vanrein-diameter-sasl-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 : ---------------------------------------------------------------------------- ** 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 238: '... initial response, it MUST be present....' RFC 2119 keyword, line 279: '...r. The User-Name AVP MUST be supplied...' RFC 2119 keyword, line 281: '...d on; the server MAY send a hint reque...' RFC 2119 keyword, line 287: '...R as a value for this AVP. It MUST be...' RFC 2119 keyword, line 289: '... realm, and it SHOULD be verified by...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 175 has weird spacing: '... inictr is an...' == Line 179 has weird spacing: '... kvno is a ...' == Line 184 has weird spacing: '...enctype is a ...' == Line 189 has weird spacing: '... seskey provi...' == Line 211 has weird spacing: '... ctr is a ...' == (10 more instances...) -- The document date (April 10, 2019) is 1836 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 447, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 8 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 April 10, 2019 5 Expires: October 12, 2019 7 Realm Crossover for SASL via Diameter 8 draft-vanrein-diameter-sasl-01 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 October 12, 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 . . . . . . . . . . . . . . . . . . . . 5 57 2.4. SXOVER challenges . . . . . . . . . . . . . . . . . . . . 6 58 3. Embedding SASL in Diameter . . . . . . . . . . . . . . . . . 6 59 3.1. AVP Definitions for SASL . . . . . . . . . . . . . . . . 6 60 3.1.1. SASL-Mechanism . . . . . . . . . . . . . . . . . . . 6 61 3.1.2. SASL-Token . . . . . . . . . . . . . . . . . . . . . 7 62 3.1.3. SASL-Channel-Binding . . . . . . . . . . . . . . . . 7 63 4. Running Diameter as a SASL Backend . . . . . . . . . . . . . 7 64 4.1. Diameter is an SCTP service . . . . . . . . . . . . . . . 8 65 4.2. Reliance on DANE and DNSSEC . . . . . . . . . . . . . . . 8 66 4.3. Foreign Service SASL Mechanisms . . . . . . . . . . . . . 9 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 7.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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 All multi-byte integer values in SXOVER are represented in network 148 byte order. When these values represent a counter, then it is a 149 32-bit unsigned integer whose increment may wrap around from the 150 highest value to zero. A NUL byte is a single byte whose bits are 151 all zero; a NUL-terminated string is a string with no inner NUL and 152 an additional NUL following it. Length-prefixed byte strings consist 153 of a 16 bit unsigned integer up to 65534 with the length followed by 154 that number of bytes with the value. Optional length-prefixed byte 155 strings can take all values of length-prefix byte strings or, if they 156 are opted out from, then their value consists of a 16-but unsigned 157 integere valued 65535. Certain information in SXOVER is encrypted 158 with the encrypt operation [Section 3 of [RFC3961]] with default 159 initial state and key usage TODO; this always includes integrity 160 protection. 162 TODO: The number for key usage is KIP_KEYUSAGE_MAPPING and comes from 163 the Keyful Identity Protocol. 165 2.1. SXOVER initial response 167 The SXOVER exchange starts with an initial response message, 168 traveling along the selection of SXOVER as the SASL mechanism. This 169 initial response contains the following: 171 realm the domain name, in lowercase ASCII and no trailing dot, under 172 which the client wants to authenticate. This is a NUL- 173 terminated string. 175 inictr is an initial counter value for this SXOVER session. It can 176 be used by the client to keep sessions separated for replay 177 prevention. 179 kvno is a 32-bit unsigned integer, holding a key version number 180 [RFC4120] for a long-term key established between the client 181 and its home realm. To complete the identity of the key, the 182 following field is also needed. 184 enctype is a 32-bit signed integer, holding an encryption type 185 following the IANA registry for Kerberos encryption types. 186 This field and kvno together identify a long-term key shared 187 between the client and its realm. 189 seskey provides a random seed from which a session key can be 190 formed, encrypted with the long-term key for the client and its 191 realm. The session key will use the same enctype, which 192 defines a random-to-key function with a required key-generation 193 seed-length [Section 3 of [RFC3961]]. Once derived, the 194 session key is used for encryption in the remaining SXOVER 195 session. 197 When this arrives at the foreign server, the domain name can be 198 tested to see if a session to the realm already exiss; if not, a 199 lookup of _diameter._sctp SRV records under the realm (which is a 200 domain name) is used to locate a home realm server to connect to. 201 Once a session to the domain's Diameter server is established, the 202 SXOVER token can be forwarded in whole, including the domain name. 204 2.2. SXOVER initial challenge 206 The initial SXOVER challenge is a server's response in which it 207 presents the choice of mechanism names to use under the cloak of 208 SXOVER. It does not present any other information. The following 209 information is sent as one block under protection of the seskey: 211 ctr is a counter that is incremented from the inictr in the initial 212 response. 214 realm repeats the NUL-terminated string with the domain name from the 215 initial response. 217 mechlist is a NUL-terminated string with a space-separated SASL 218 mechanism names. 220 chanbindmth is a NUL-terminated string with the name of a channel 221 binding method. TODO:REALLY? 223 chanbindval is a length-prefixed string with the value of the 224 channel binding. TODO:REALLY? 226 2.3. SXOVER responses 228 Further SXOVER responses are essentially SASL responses and initial 229 responses, encrypted under the seskey, but there is one exception; 230 the first response must select a SASL mechanism. There is a separate 231 provision for sending no data, distinguishable from empty data, if 232 this is desired by the SASL mechanism: 234 ctr is a counter, incremented from the prior message in this SXOVER 235 session. 237 opt_mechsel is an optional NUL-terminated string. In the first 238 SXOVER response after the initial response, it MUST be present. 239 When present, it mentions a SASL mechanism name to start under 240 the cloak of SXOVER. 242 opt_token is an optional length-prefixed token for the SASL 243 mechanism selected with the most recently provided opt_mechsel. 245 2.4. SXOVER challenges 247 Further SXOVER challenges are essentially SASL challenges and initial 248 challenges, encrypted under the seskey. There is a separate 249 provision for sending no data, distinguishable from empty data, if 250 this is desired by the SASL mechanism: 252 ctr is a new 32-bit counter value, 1 more than the prior message in 253 the SXOVER session. 255 opt_token is an optional length-prefixed token for the selected SASL 256 mechanism that is protected by SXOVER. 258 opt_extra is an optional length-prefixed byte string with extra 259 information, as provided by SASL alongside a successful 260 response. 262 3. Embedding SASL in Diameter 264 SASL messages in Diameter use a number of AVPs [RFC6733] that are 265 defined for this purposes. They occur in those combinations that are 266 defined for SASL. 268 SASL over Diameter can only be used to relay the SXOVER mechanism to 269 a home realm. This means that no negotiation of mechanisms is needed 270 at the Diameter level; this is handled under the SXOVER cloak. The 271 same holds for any negotation of channel binding; it is part of the 272 cloacked SASL exchange. 274 3.1. AVP Definitions for SASL 276 These AVPs are added to the set that is used with the Network Access 277 application, and can therefore be used in AA-Request and AA-Answer 278 messages. On top of that, the SASL-Mechanisms AVP may also occur in 279 a Capabilities Exchange Answer. The User-Name AVP MUST be supplied 280 in the AA-Answer to inform the server about the user name that the 281 backend decided on; the server MAY send a hint requesting a value in 282 the User-Name AVP in the AA-Request. 284 3.1.1. SASL-Mechanism 286 The SASL-Mechanism AVP has AVP Code TBD0. This specification only 287 uses the mechanism name SXOVER as a value for this AVP. It MUST be 288 included in the first message of an SXOVER exchange sent to the home 289 realm, and it SHOULD be verified by the home realm upon reception. 291 Its purpose is mostly to distinguish this specification from 292 potential future specifications to encapsulate SASL in Diameter. 294 Though not used in this specification, this AVP may also be supplied 295 from the home realm to the Diameter client to hold a space-separated 296 list of SASL mechanisms. 298 3.1.2. SASL-Token 300 The SASL-Token AVP has AVP Code TBD1. Note that SASL requires 301 distinction between empty and absent tokens; absent SASL tokens are 302 represented by absence of the SASL-Token AVP and empty SASL tokens 303 are represented as a present SASL-Token AVP with zero content bytes. 305 3.1.3. SASL-Channel-Binding 307 The SASL-Channel-Binding AVP has AVP Code TBD2. It SHOULD appear 308 along the first SASL-Token AVP for a Network Access session. The AVP 309 may occur more than once, to indicate support of multiple forms of 310 channel binding. 312 When the client connects to the foreign service over TLS, the tls- 313 unique form [RFC5929] of channel binding is RECOMMENDED. Specific 314 foreign servers may however be exempted by the home realm. 316 The contents of this AVP are: 318 name is the standard name of the channel binding information, 319 followed by a zero-valued byte. 321 value contains the bytes of the channel binding information. 323 Normally, channel binding information should be sourced from the 324 underlying communications channel, but this information is not 325 available to backend running Diameter. To enable channel binding 326 between the end points, the foreign server incorporates the channel 327 binding information that the client can use in its connection to the 328 foreign server. This is useful to mitigate replay attacks, which is 329 why its use is RECOMMENDED. Channel binding provides better 330 guarantees than the simple inictr/ctr mechanism used in SXOVER. 332 4. Running Diameter as a SASL Backend 334 Following are a few practical considerations in relation to the 335 Diameter connectivity for SASL. 337 4.1. Diameter is an SCTP service 339 Diameter is primarily an SCTP-based protocol [RFC6733], for reasons 340 of scalabaility and efficiency. SASL Diameter benefits from these 341 properties and embraces the SCTP carrier. Operating system support 342 for SCTP is wide-spread, but parts of network infrastructure may not 343 support it, and that may cause implementations to add a fallback to 344 more traditional protocols. Standards offer two options for doing 345 this. 347 Diameter can fallback to run over TCP, which is mostly of use to 348 client-only machines, but it sacrifices several benefits of the SCTP 349 carrier. Since the SASL Diameter embedding typically involves no 350 client systems, this option is NOT RECOMMENDED. 352 SCTP may be run over a UDP transport using port 9899 [RFC6951], which 353 does not sacrifice much; it only inserts a UDP header before each 354 message. This is a reasonable expectation of foreign servers as well 355 as home realms, so this additional option is RECOMMENDED for 356 situations where a fallback for plain SCTP is desired. It is 357 standardised as a socket option SCTP_REMOTE_UDP_ENCAPS_PORT, and only 358 involves a small repetition in code, with a minor change between the 359 attempts. 361 4.2. Reliance on DANE and DNSSEC 363 Diameter always involves the use of TLS, but there is a number of 364 choices concerning the validation of connections through DNSSEC and 365 DANE. It is the home realm's prerogative what level of protection it 366 upholds for its client identities, but any foreign server can choose 367 to raise the bar by setting a minimum standard. 369 DNSSEC is a useful protection mechanism for the _diameter._sctp SRV 370 records that lead to the Diameter host and its port for the home 371 realm. This does not protect against forged IP addresses, port 372 mappings or routing. To protect against this as well, a TLSA record 373 for the service host and port, along with the _sctp protocol label, 374 should be used as specified for DANE [RFC6698]. 376 Home realms that choose to be light on such measures risk that 377 identities are forged, in spite of their use of TLS. Foreign servers 378 MAY choose to reject such home realms, or alternatively be more 379 inquisitive about the certificates used. 381 4.3. Foreign Service SASL Mechanisms 383 A foreign server MUST offer SXOVER if it wants to support realm 384 crossover via Diameter as specified herein. In addition, it MAY 385 offer SASL mechanisms that it resolves locally. 387 The ANONYMOUS method for SASL [RFC4505] may be offered for guest 388 access. The PLAIN method [RFC4616] continues to be ill-advised, 389 especially with modern methods such as SCRAM [RFC5802] to address the 390 needs of local accounts with password validation. 392 The HTTP protocol does not yet support SASL, and it is not optimal 393 from a security viewpoint to integrate credentials in the dynamic 394 environment of HTML, where dynamic content from potentially 395 undesirable origins come together in a manner not controllable to the 396 end user. One remedy is to use HTTP and its authentication methods 397 that match with SASL, such as SCRAM for HTTP [RFC7804]. Another 398 remedy is to switch to generic SASL embedding in HTTP 399 [TODO:REF:draft-vanrein-httpauth-sasl] and gain replay protection 400 through channel binding. 402 Many application protocols offer richer semantics than HTTP, making 403 them better targets for automation. Their reliance on SASL has made 404 them less tractable as a service to third parties. One reason for 405 introducing SXOVER is in the hope to make it possible to have those 406 semantically rich applications as a third-party offering. 408 5. Security Considerations 410 From the perspective of the client and the home realm, the safety of 411 the SASL credentials is paramount. Since not all SASL mechanisms are 412 safe from inspection by the foreign server, and since TLS cannot help 413 there either, there is a need for some caution. 415 The limitation of the Diameter carrier for SASL to SXOVER reduces 416 this risk, by only authenticating SASL mechanisms under end-to-end 417 encryption between the client and home realm. It is generally 418 understood that clients must not send unprotected SASL authentication 419 attempts to arbitrary parties, but SXOVER adds a facility that is 420 safe for clients to use in this manner. The SXOVER mechanism could 421 even be used without TLS protection. 423 From the perspective of the foreign server, the security concern is 424 to be certain of an identity. The home realm sends this information 425 back when SXOVER authentication succeeds, and the communication doing 426 so is protected with TLS. The certificate of the Diameter server can 427 be validated, and for cautious home realms there could be an 428 additional check based on DANE. 430 6. IANA Considerations 432 This specification defines three AVP Codes for use with Diameter. 433 IANA registers the following AVP Codes for them in the 434 "Authentication, Authorization, and Accounting (AAA) Parameters" 435 registry: 437 AVP Code | Attribute Name | Reference 438 ---------+----------------------+------------ 439 TBD0 | SASL-Mechanism | (this spec) 440 TBD1 | SASL-Token | (this spec) 441 TBD2 | SASL-Channel-Binding | (this spec) 443 7. References 445 7.1. Normative References 447 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 448 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 449 2005, . 451 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 452 Kerberos Network Authentication Service (V5)", RFC 4120, 453 DOI 10.17487/RFC4120, July 2005, 454 . 456 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 457 Authentication and Security Layer (SASL)", RFC 4422, 458 DOI 10.17487/RFC4422, June 2006, 459 . 461 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 462 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 463 . 465 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 466 Service Application Program Interface (GSS-API) Mechanisms 467 in Simple Authentication and Security Layer (SASL): The 468 GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, 469 July 2010, . 471 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 472 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 473 . 475 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 476 of Named Entities (DANE) Transport Layer Security (TLS) 477 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 478 2012, . 480 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 481 Ed., "Diameter Base Protocol", RFC 6733, 482 DOI 10.17487/RFC6733, October 2012, 483 . 485 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 486 Control Transmission Protocol (SCTP) Packets for End-Host 487 to End-Host Communication", RFC 6951, 488 DOI 10.17487/RFC6951, May 2013, 489 . 491 7.2. Informative References 493 [RFC4505] Zeilenga, K., "Anonymous Simple Authentication and 494 Security Layer (SASL) Mechanism", RFC 4505, 495 DOI 10.17487/RFC4505, June 2006, 496 . 498 [RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and 499 Security Layer (SASL) Mechanism", RFC 4616, 500 DOI 10.17487/RFC4616, August 2006, 501 . 503 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 504 "Salted Challenge Response Authentication Mechanism 505 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 506 DOI 10.17487/RFC5802, July 2010, 507 . 509 [RFC7804] Melnikov, A., "Salted Challenge Response HTTP 510 Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804, 511 March 2016, . 513 Appendix A. Acknowledgements 515 Thanks go to TODO for useful discussions during the creation of this 516 document. 518 Author's Address 519 Rick van Rein 520 ARPA2.net 521 Haarlebrink 5 522 Enschede, Overijssel 7544 WP 523 The Netherlands 525 Email: rick@openfortress.nl