idnits 2.17.1 draft-vanrein-diameter-sasl-06.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 131: '... and MAY use this for access control...' RFC 2119 keyword, line 200: '... unique form [RFC5929] of channel binding is RECOMMENDED for protocols...' RFC 2119 keyword, line 203: '...onnections it is RECOMMENDED to suppor...' RFC 2119 keyword, line 281: '...hsel IA5String OPTIONAL, -- SASL m...' RFC 2119 keyword, line 292: '... MUST be in the first inner SASL mes...' (52 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 550 has weird spacing: '...n-Realm is th...' == Line 609 has weird spacing: '...lt-Code is se...' == Line 617 has weird spacing: '...lt-Code is se...' == Line 623 has weird spacing: '...lt-Code is se...' == Line 625 has weird spacing: '...L-Token is in...' == (1 more instance...) -- The document date (28 January 2022) is 812 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'APPLICATION 1' is mentioned on line 210, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 249, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 280, but not defined == Missing Reference: 'APPLICATION 4' is mentioned on line 309, but not defined == Missing Reference: 'APPLICATION 10' is mentioned on line 871, but not defined -- Looks like a reference, but probably isn't: '1' on line 916 -- Looks like a reference, but probably isn't: '8' on line 873 -- Looks like a reference, but probably isn't: '9' on line 874 == Missing Reference: 'APPLICATION 11' is mentioned on line 883, but not defined -- Looks like a reference, but probably isn't: '2' on line 943 == Missing Reference: 'APPLICATION 12' is mentioned on line 890, but not defined -- Looks like a reference, but probably isn't: '3' on line 918 -- Looks like a reference, but probably isn't: '4' on line 893 -- Looks like a reference, but probably isn't: '5' on line 944 == Missing Reference: 'APPLICATION 13' is mentioned on line 911, but not defined -- Looks like a reference, but probably isn't: '0' on line 939 == Missing Reference: 'APPLICATION 14' is mentioned on line 938, but not defined -- Looks like a reference, but probably isn't: '6' on line 945 -- Looks like a reference, but probably isn't: '7' on line 946 == Unused Reference: 'I-D.vanrein-internetwide-realm-crossover' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'RFC6113' is defined on line 802, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-vanrein-internetwide-realm-crossover-00 Summary: 1 error (**), 0 flaws (~~), 19 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Van Rein 3 Internet-Draft OpenFortress BV 4 Intended status: Informational H. Manson 5 Expires: 1 August 2022 Mansoft 6 28 January 2022 8 Realm Crossover for SASL and GSS-API via Diameter 9 draft-vanrein-diameter-sasl-06 11 Abstract 13 SASL and GSS-API are used for authentication in many application 14 protocols. This specification extends them to allow credentials of 15 an identity domain to be used against external services. To this 16 end, it introduces end-to-end encryption for SASL that is safe to 17 relay through a foreign server. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 1 August 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Messages of SXOVER-PLUS . . . . . . . . . . . . . . . . . . . 4 54 2.1. Preparation for Messaging . . . . . . . . . . . . . . . . 4 55 2.2. Initial Client-to-Server Message . . . . . . . . . . . . 5 56 2.3. Initial Server-to-Client Message . . . . . . . . . . . . 6 57 2.4. Continued Client-to-Server Messages . . . . . . . . . . . 6 58 2.5. Continued Server-to-Client Messages . . . . . . . . . . . 7 59 2.6. Using SXOVER-PLUS with GSS-API . . . . . . . . . . . . . 8 60 2.7. Application Key Derivation . . . . . . . . . . . . . . . 8 61 3. AVP Definitions for SASL in Diameter . . . . . . . . . . . . 9 62 3.1. SASL-Mechanism . . . . . . . . . . . . . . . . . . . . . 10 63 3.2. SASL-Token . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.3. SASL-Channel-Binding . . . . . . . . . . . . . . . . . . 11 65 4. Diameter Session Requirements for SASL . . . . . . . . . . . 11 66 5. Diameter Message Requirements for SXOVER-PLUS . . . . . . . . 12 67 5.1. C2S-Init Requests over Diameter . . . . . . . . . . . . . 12 68 5.2. S2C-Init Responses over Diameter . . . . . . . . . . . . 13 69 5.3. C2S-Cont Requests over Diameter . . . . . . . . . . . . . 13 70 5.4. S2C-Cont Responses over Diameter . . . . . . . . . . . . 13 71 6. Running Diameter as a SASL Backend . . . . . . . . . . . . . 14 72 6.1. Diameter is an SCTP service . . . . . . . . . . . . . . . 14 73 6.2. Reliance on DANE and DNSSEC . . . . . . . . . . . . . . . 15 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 9. Normative References . . . . . . . . . . . . . . . . . . . . 17 77 Appendix A. Centralised handing of SASL over Diameter . . . . . 18 78 Appendix B. Support Levels for Realm Crossover . . . . . . . . . 21 79 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 22 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 82 1. Introduction 84 It is common for Internet users to work with services from a 85 varierity of providers. An ad hoc practice has arisen of using local 86 identity schemes for each of these providers. There is no 87 integration of identity systems, and the practice reduces the control 88 of users over their online identity. A solution to this is support 89 for Realm Crossover TODO.xref.target=draft-vanrein-internetwide- 90 realm-crossover, where an externally acquired service can make a 91 callback to a home realm to authenticate a user's identity and use 92 that for service-specific authorisation. 94 SASL [RFC4422] and GSS-API [RFC2743] together is instrumental in 95 authentication across a wide range of application protocols; it 96 allows these protocols to abstract from the actual authentication 97 mechanisms, and at the same time it allows authentication mechanisms 98 to not be concerned with the application protocol. SASL can easily 99 be funneled from one protocol into another, modulo a number of 100 security concerns. 102 Diameter and its Network Access Server application are instrumental 103 in authenticating a user under a realm, while not handing over any 104 resources like an application protocol would. Furthermore, Diameter 105 integrates with realm-crossing security; service can be declared 106 under a domain name in a manner that is standardised, scalable and 107 secure. 109 This can be used by a foreign server to authenticate a client by call 110 the client's own domain as an authentication backend: 112 +--------+ SASL +--------+ SASL +---------+ 113 | Proto |-----------> | Foreign| ---------> | Identity| 114 | Client |-----------> | Server | ---------> | Domain | 115 +--------+ AppProto +--------+ Diameter +---------+ 116 || || || 117 john@example.com find SRV, TLSA example.com 118 & credential & relay SASL authentication 120 Realm Crossover authentication: 122 Client John authenticates to his own Domain 123 while using a foreign Server. 125 The Diameter server in the domain needs to respond success or failure 126 on the SASL exchange forwarded to it. It delivers a User-Name on 127 success, but not its domain. The client domain is validated by the 128 foreign server, using DANE [RFC6698]. The User-Name combines with 129 the validated domain to form the client identity for use in the 130 foreign server. The domain server also validates the foreign server, 131 and MAY use this for access control, and perhaps to decide on the 132 release of additional AVPs. 134 The client needs to assure that the authentication exchange cannot be 135 relayed anywhere but to the Diameter service in his realm. This can 136 be assured with channel binding [RFC5056] [RFC5801]; the foreign 137 server detects this information and relays it to the Diameter 138 service. Normally, protocol servers should not accept externally 139 dictated channel binding information; the reason why it is safe to 140 make an exception for Diameter is that it provides no resources, 141 making it an unattractive attack target. 143 SASL tokens are not generally safe to pass over plaintext channels. 144 This is usually addressed by wrapping the application protocol in 145 TLS, but since that would only protect one leg of the intended realm- 146 crossing authentication exchange, there is a need for end-to-end 147 encryption. 149 This specification describes a SASL mechanism named SXOVER-PLUS as an 150 end-to-end encrypted tunnel around another SASL exchange. It also 151 defines how SASL can be embedded in a Diameter authentication 152 exchange, which may be useful with SXOVER-PLUS or with any other SASL 153 mechanism. 155 Realm Crossover for SASL is part of a series of protocol 156 enhancements, as overviewed in TODO:xref target="draft-vanrein- 157 internetwide-realm-crossover". Among the potential use cases are a 158 global identity scheme for general communication and group 159 participation, establishment of encryption keys, all with identity 160 control under individually owned domains. 162 2. Messages of SXOVER-PLUS 164 SXOVER-PLUS consists of a few messages that derive an encryption 165 secret and then continue using it as an end-to-end encrypted tunnel 166 around a standard SASL authentication exchange. SXOVER continues to 167 be active as long as the tunneled exchange does. 169 2.1. Preparation for Messaging 171 Before SXOVER-PLUS starts, the user uses an out-of-band protocol to 172 submit a long-term key to his domain and receives back a suitable 173 keyno and encalg in the style of Kerberos [RFC4120] along with a 174 "keymap" blob that contains the originally submitted long-term key in 175 encrypted form. This process may be run at any time desired by the 176 client, like when a program first uses the SXOVER-PLUS mechanism; 177 keys may be kept for the remainder of the program run, even if this 178 lasts for weeks and crosses between security realms, as a pre- 179 validated key for protected contact with their realm; but at any time 180 desired, the client may drop the long-term key, for example when a 181 user desktop session is suspended or terminated. 183 By offering the SXOVER-PLUS mechanism for SASL, a foreign server 184 announces its willingness to validate the client's domain. relay SASL 185 messages to it, trust its authentication conclusion and User-Name and 186 treat that as a user identity of the client's domain. 188 Offering SXOVER-PLUS does not preclude the offering of other SASL 189 mechanisms; for instance, ANONYMOUS may be a useful option to also 190 offer guest access to clients. 192 2.2. Initial Client-to-Server Message 194 SXOVER-PLUS is a client-first mechanism. The first SASL Token starts 195 with "p=CHANBIND,,DOMAIN," where CHANBIND is the channel binding name 196 and DOMAIN is the domain name of the client. This notation is 197 compatible with the GS2 bridge [RFC5056]. 199 When the client connects to the foreign service over TLS, the tls- 200 unique form [RFC5929] of channel binding is RECOMMENDED for protocols 201 or their implementation that encapsulate an entire SASL exchange in 202 one TLS connection. For protocols that spread the SASL exchange over 203 multiple connections it is RECOMMENDED to support both tls-unique and 204 tls-server-end-point. Special considerations may apply as a result 205 of software configuration per home realm. 207 Following this is DER-encoded information for the following ASN.1 208 structure: 210 C2S-Init ::= [APPLICATION 1] IMPLICIT SEQUENCE { 211 clirnd OCTET STRING, -- Entropy to allow client variety 212 keyno KeyNumber, -- Given realm and encalg, identify... 213 encalg EncryptAlg, -- ...the key for keymap decryption... 214 keymap OCTET STRING -- ...yielding server-acceptable data 215 } 217 EncryptAlg ::= Int32 218 KeyNumber ::= UInt32 220 The clirnd is a salt that should hold enough entropy to satisfy the 221 client's cryptographic requirements. The other fields result from 222 the setup of the long-term key preceding SXOVER-PLUS. 224 Upon reception, the server locates a key for the keyno and encalg in 225 the key store for DOMAIN and uses it to decrypt keymap into entropy 226 that serves as input to the random-to-key function [RFC3961], where 227 the length of the decrypted keymap must match the key-generation 228 seed-length. 230 The same key is constructed with random-to-key on both ends; the 231 client uses the key that it originally submitted to the server. The 232 result is now on both ends, and known as key K0. 234 Both ends pass K0 into the PRF+() function [Section 5.1 of [RFC6113]] 235 with the entire message (the GS2 header followed by C2S-Init, which 236 includes the clirnd entropy field) to produce properly sized input to 237 the random-to-key function. The result is known as key K1. Note how 238 this is similar to the KRB-FX-C2 procedure [Section 5.1 of [RFC6113]] 239 except that it is applied to a single key. (Considering slight 240 generalisation of the procedure to a list of key/pepper pairs that 241 are composed with associative/commutative XOR operators.) 243 2.3. Initial Server-to-Client Message 245 After the client-first SASL Token, the server sends its first 246 challenge. It is encoded with DER and encrypted by K1, and contains 247 the following ASN.1 structure: 249 S2C-Init ::= [APPLICATION 2] IMPLICIT SEQUENCE { 250 srvrnd OCTET STRING, -- Entropy to allow server variety 251 mechlist IA5String -- Available SASL mechanisms 252 } 254 The srvrnd is a salt that should hold enough entropy to satisfy the 255 server's cryptographic requirements. Note that the mechlist and DER 256 tagging add no entropy. 258 The mechlist starts the SASL exchange inside the end-to-end encrypted 259 tunnel. If this inner list uses channel binding at all, it should 260 replicate the channel binding choices from the outer layer. 262 The key K1 is passed into the PRF+() function [Section 5.1 of 263 [RFC6113]] with the pepper set to the concatenation of the entire 264 S2C-Init message and the channel binding value. This is used to 265 produce a last input to the random-to-key function. The result is 266 known as key K2. 268 The direct concatenation of S2C-Init with channel binding information 269 is secure because of the self-descriptive size of the DER encoding of 270 the former. Also note that there is no risk of cross-polination 271 between types of channel binding because the name for the type has 272 been hashed into key K1 and is therefore already securely encompassed 273 in the key derivation. 275 2.4. Continued Client-to-Server Messages 277 Further messages from the client to the server hold DER content 278 encrypted with key K2, following this ASN.1 format: 280 C2S-Cont ::= [APPLICATION 3] IMPLICIT SEQUENCE { 281 mechsel IA5String OPTIONAL, -- SASL mechanism name selection 282 c2s SaslToken -- NULL or SASL token passed 283 -- from client to server 284 } 286 SaslToken ::= CHOICE { 287 token OCTET STRING, 288 no-token NULL 289 } 291 The mechsel indicates the client's choice of a SASL mechanism, and 292 MUST be in the first inner SASL message. It initiates a new 293 authentication exchange. The c2s holds the SASL Token and is sent as 294 NULL whenever the mechanism yields no token, which is distinct from 295 yielding an empty token. 297 The inner SASL exchange may be used to select an authorisation name 298 that differs from the authentication name. This would be subject to 299 normal approval by the SASL server, but upon success the 300 authorisation name would be revealed in the User-Name over Diameter, 301 and the foreign server would not be told about the authentication 302 name. This can facilitate pseudonymity. 304 2.5. Continued Server-to-Client Messages 306 Further messages from the server to the client hold DER content 307 encrypted with key K2, following this ASN.1 format: 309 S2C-Cont ::= [APPLICATION 4] IMPLICIT SEQUENCE { 310 success BOOLEAN DEFAULT FALSE, -- When TRUE, s2c is an 311 -- additional token 312 s2c SaslToken -- NULL or SASL token from 313 -- server to client 314 } 316 The s2c field carries the SASL token if it is provided, even when it 317 is empty. If the token is absent, it carries NULL. 319 General reporting of success or failure is done for SXOVER-PLUS. But 320 not all encapsulating protocols support additional data, but the 321 success field makes this possible in any case. Note that this is 322 trivially supported in Diameter, by sending a SASL token as part of a 323 success message. Inside the SXOVER-PLUS tunnel it is also possible 324 by setting the success flag and supplying the additional data in s2c. 326 2.6. Using SXOVER-PLUS with GSS-API 328 SXOVER-PLUS can be used with GSS-API [RFC2743] instead of SASL with 329 minor changes, because it is mostly similar to GS2. This results in 330 a GSS-API tunnel wrapped around SASL authentication. 332 GSS-API calls [RFC2744] to gss_init_sec_context() and 333 gss_accept_sec_context() MUST follow the GS2 data structure for 334 channel binding information [Section 5.1 of [RFC5801]]. This means 335 that only the application_data field is filled, namely with the 336 "p=CHANBIND,," part of the first SASL token from client to server, 337 concatenated with the application's channel binding data. Since such 338 data starts with "CHANBIND:" [RFC5056] there is some duplication of 339 data, which should be validated. This outer layer of SXOVER-PLUS 340 does not support an authorization identifier; any desire to select an 341 identity is to be encapsulated inside the end-to-end encrypted tunnel 342 of SXOVER-PLUS. 344 The first message transmitted as GSS-API token does not repeat the 345 "p=CHANBIND,," prefix, but the "DOMAIN," and subsequent DER-encoded 346 C2S-Init data is retained. Instead, the standard GSS-API header is 347 inserted, adhering to the Mechanism-Independent Token Format 348 [Section 3.1 of [RFC2743]] with object identifier 349 1.3.6.1.4.1.44469.5081.1 to identify SXOVER-PLUS. When this object 350 identifier is supplied to the call GSS_Inquire_SASLname_for_mech 351 [Section 10 of [RFC5801]], the output reads "SXOVER-PLUS" (without 352 the quotes). 354 When the GSS-API data must be relayed to a SASL backend, then the 355 "p=CHANBIND,," prefix must be reinserted after removal of the GSS-API 356 header. Realm Crossover for GSS-API works like this; it is rewritten 357 to SASL and passed over Diameter in that form. 359 2.7. Application Key Derivation 361 SXOVER-PLUS adheres to most of the GS2 bridge, but deviates in two 362 points. First, security layers are not considered useful in GS2 363 [Section 12 of [RFC5801]] because it assumes a pre-existing secure 364 layer to provide this benefit. With SXOVER-PLUS however, the end-to- 365 end connection between a client and their authentication server 366 differs from the single-hop connection to the foreign service, and it 367 can be beneficial to extract secret key information between the 368 former and latter. The second deviation from GS2 is that SXOVER-PLUS 369 is defined but SXOVER is not. For these reasons, GS2- was not 370 prefixed to the mechanism name. 372 In general, security layers may be derived from the key K2 by yet 373 another pass through the PRF+() function [Section 5.1 of [RFC6113]]. 374 The pepper for this is application-specific, and the requested length 375 of octet-string can also be requested by the application. Multiple 376 keys can be defined, each constructed from K2 and pepper. 378 Specifically, when SXOVER-PLUS is used under GSS-API, the following 379 32-byte ASCII strings may be used as pepper to derive keys for each 380 of the four secure streams supported by GSS-API: 382 Pepper as 32 ASCII bytes | Purpose | Direction 383 ---------------------------------+----------+------------------ 384 SXOVER-PLUS/GSS-API/SIGN-C2S-KEY | signing | client --> server 385 SXOVER-PLUS/GSS-API/SIGN-S2C-KEY | signing | client <-- server 386 SXOVER-PLUS/GSS-API/WRAP-C2S-KEY | wrapping | client --> server 387 SXOVER-PLUS/GSS-API/WRAP-S2C-KEY | wrapping | client <-- server 389 Definitions for one application do not preclude the generation of 390 keys for other applications. It is however vital to security that 391 they all use different pepper that share a SASL-authenticated session 392 but distribute keys to different trusted regions within an endpoint. 394 3. AVP Definitions for SASL in Diameter 396 SASL messages in Diameter use a number of AVPs [Section 4 of 397 [RFC6733]] that are combined to relay SASL to a Destination-Realm 398 that is set to the client's domain name. 400 These AVPs are added to the set that is used with the Network Access 401 Server application [RFC7155], and can therefore be used in AA-Request 402 and AA-Answer messages. They are always sent with the Mandatory Flag 403 set to 0. When they are not recognised upon reception, they will be 404 silently igored. 406 Normally, a successful AA-Answer would provide a User-Name AVP to 407 inform the server about a utf8-username NAI without a utf8-realm 408 [Section 2.2 of [RFC7542]] under which the client is identified; 409 without the User-Name an anonymous session is the only available 410 option, possibly leading to reduced service and/or limited data 411 retention. Sending a pseudonym in the User-Name may be an 412 intermediate option. In all cases, the domain under which an 413 authenticated user name is defined can be taken from the Destination- 414 Realm handling the Network Access Server session; with the domain 415 also written in UTF-8, the parts may be combined in the nai grammar 416 [Section 2.2 of [RFC7542]. 418 3.1. SASL-Mechanism 420 The SASL-Mechanism AVP has AVP Code TBD0 and is of type UTF8String, 421 further restricted to a list of zero or more SASL mechanism names in 422 their standardised notation [Section 3.1 of [RFC4422]] separated by a 423 space character U+0020. 425 To retrieve a server's list of supported SASL mechanisms, this AVP is 426 included in an AA-Request message, containing an empty list of SASL 427 mechanism names, so an empty string. When SASL is supported by the 428 server, it responds with the list of currently available SASL 429 mechanisms. 431 Clients MAY retrieve the server's supported mechanism list without 432 actually attempting authentication in the same session; this can be a 433 caching mechanism for a given combination of Destination-Realm, 434 Origin-Realm and Origin-Host. An abort of such a session by the 435 server indicates that the cache entry has expired, and should be 436 retrieved anew for a following attempt. 438 To relay a client's choice of SASL mechanism, this AVP is included in 439 an AA-Request message, containing a single SASL mechanism name. This 440 MAY be done in another session than the one that retrieved the 441 supported SASL mechanisms from the server, as long as origin and use 442 have a matching Destination-Realm, Origin-Realm and Origin-Host. 444 When the supported SASL mechanism list on a server is changed, any 445 open sessions that depend on one or more of the modified mechanisms 446 SHOULD be aborted by the server. 448 Diameter peers MUST NOT send the SASL-Mechanism AVP unless they also 449 process SASL-Token and SASL-Channel-Binding AVPs for any sessions 450 with the same Destination-Realm. 452 3.2. SASL-Token 454 The SASL-Token AVP has AVP Code TBD1 and is of type OctetString. It 455 may be passed in AA-Request and AA-Answer messages. 457 SASL requires distinction between empty and absent tokens; absent 458 SASL tokens are represented by absence of the SASL-Token AVP and 459 empty SASL tokens are represented as a present SASL-Token AVP with 460 zero content bytes. 462 The interpretation of a SASL-Token is subject to the SASL mechanism 463 selection by the client. This is relayed with a SASL-Mechanism AVP, 464 which MUST be part of each Network Access Server session, no later 465 than the first SASL-Token exchange in that session. 467 3.3. SASL-Channel-Binding 469 The SASL-Channel-Binding AVP has AVP Code TBD2 and is of type 470 OctetString. The AVP contains the literal channel binding 471 information for a SASL mechanism, and may be sent in an AA-Request 472 that also holds a SASL-Mechanism AVP that lists a single SASL 473 mechanism. 475 Without Realm Crossover, a SASL identity provider can source channel 476 binding information from the underlying communications channel. This 477 information is not available to a SASL backend running Diameter. To 478 enable channel binding between the end points, and thereby 479 authentication between the SASL end points, the foreign server 480 incorporates the channel binding information that the client can use 481 in its connection to the foreign server. This is useful to mitigate 482 replay attacks, which is why its use is RECOMMENDED. 484 Note that SASL requires channel binding information when the client- 485 selected SASL-Mechanism AVP ends in -PLUS. Different kinds of 486 channel binding exist, and their representations are distinguished 487 with an IANA-registered prefix. As a result, more than one SASL- 488 Channel-Binding AVP can be safely included in one AA-Request. 489 Servers MAY refrain from learning the client-chosen kind of channel 490 binding from the SASL exchange, but SHOULD then transmit all the 491 kinds that they support to avoid authentication failure. 493 4. Diameter Session Requirements for SASL 495 Any exchange under the Network Access Server application must include 496 a Session-ID. There MAY be two kinds of session, and whether they 497 are combined is an implementation requirement. 499 A session can probe a SASL mechanism list as supported by a 500 Destination-Realm for a given Origin-Realm and Origin-Host. This 501 mechanism MAY be assumed valid for any other sessions with these same 502 three AVPs, for as long as this session is open. 504 A session can make at most one SASL authentication attempt. This is 505 initiated with a SASL-Mechanism AVP that conveys precisely one SASL 506 mechanism name in the first token. The same Diameter message MAY 507 convey a SASL-Token AVP in support of client-first mechanisms. The 508 same Diameter message MUST convey one or more SASL-Channel-Binding 509 AVPs if the SASL-Mechanism ends in -PLUS. Further messages in the 510 session MUST NOT have the SASL-Mechanism AVP, MUST NOT have the SASL- 511 Channel-Binding AVP and MAY have zero or one SASL-Token AVP. 513 It is possible for a session that probed a SASL mechanism list to 514 continue as an authentication attempt. In this case, the SASL 515 mechanism list collapses to the one choice made by the client, and 516 other sessions cannot rely on the entire mechanism list. The server 517 MAY close the session if it drops support for the client-selected 518 SASL mechanism. 520 Alternatively, a session that probed a SASL mechanism list can be 521 kept open, and the obtained SASL mechanism list is then considered 522 stable for sessions that use the same combination of Destination- 523 Realm, Origin-Realm and Origin-Host. This may be used to cache 524 mechanism lists. The server SHOULD close this session if it changes 525 the mechanism list, thus invalidating the previously submitted 526 mechanism list. As long as the client has the mechanism list open, 527 it MAY use that list for sessions that directly enter into an 528 authentication attempt. 530 5. Diameter Message Requirements for SXOVER-PLUS 532 This section explains how the various SXOVER-PLUS messages are 533 forwarded over Diameter by the foreign server. The foreign server is 534 connected to the SASL client, possibly over a TLS connection or a 535 protocol under GSS-API protection, and relays requests over Diameter, 536 usually over SCTP with DTLS. 538 Diameter servers eventually provide success and failure responses, 539 based on the corresponding final results from a SASL implementation 540 that they in turn use. Before the final result is reached, the SASL 541 implementation may impose a challenge that will be reproduced over 542 Diameter, passing challenge and response tokens over Diameter on 543 behalf of SASL. 545 5.1. C2S-Init Requests over Diameter 547 To send C2S-Init the Diameter client MUST include at least the 548 following AVPs in an AA-Request [Section 3.1 of [RFC7155]]: 550 Destination-Realm is the client's identity domain, replicated here 551 for Diameter routing purposes; SXOVER-PLUS conveys this value 552 in plaintext; 554 SASL-Mechanism MUST be set to the fixed string SXOVER-PLUS for this 555 SASL mechanism's name; 557 SASL-Token MUST be set to the GS2 header and C2S-Init; 559 SASL-Channel-Binding MUST be set to the channel binding bytes for 560 the connection in which the SASL client attempts 561 authentication, adhering to the channel binding mechanism named 562 in the gs2-header in the SASL-Token. 564 It is possible to extend the message with more AVPs. Unless 565 described herein, the SASL implementation ignores them. 567 5.2. S2C-Init Responses over Diameter 569 When SASL fails to initialise in response to the C2S-Init passed in 570 an AA-Request, then the AA-Answer MUST represent that in the 571 following AVP: 573 Result-Code MUST be set to an error or failure code [Section 7.1 of 574 [RFC6733]]. 576 The initialisation of SASL forms a S2C-Init response, and an AA- 577 Answer MUST be sent with the following AVPs: 579 Result-Code MUST be set to the value DIAMETER_MULTI_ROUND_AUTH 580 [Section 7.1.1 of [RFC6733]]; 582 SASL-Token MUST be set to the S2C-Init value. 584 5.3. C2S-Cont Requests over Diameter 586 The C2S-Cont message is any further message that the SASL client 587 passes to the foreign server. It MUST be forwarded as a Diameter AA- 588 Request with the following AVPs: 590 SASL-Token MUST be set to the C2S-Cont value from the SASL client; 592 SASL-Mechanism MUST NOT be sent; 594 SASL-Channel-Binding MUST NOT be sent; 596 User-Name MAY be sent but MUST NOT be processed when received by 597 implementations of this specification; 599 User-Password MOST NOT be sent. 601 5.4. S2C-Cont Responses over Diameter 603 S2C-Cont tokens are produced as output from continued SASL processing 604 based on C2S-Cont tokens found in AA-Request messages. 606 If the SASL exchange is not final, then the AA-Answer MUST represent 607 that in the following AVPs: 609 Result-Code is set to the value DIAMETER_MULTI_ROUND_AUTH 610 [Section 7.1.1 of [RFC6733]]; 612 SASL-Token MUST be included, and set to the S2C-Cont value. 614 If the SASL exchange fails, then the AA-Answer MUST represent that in 615 the following AVP: 617 Result-Code is set to an error or failure code [Section 7.1 of 618 [RFC6733]]. 620 If the SASL exchange succeeds, then the AA-Answer MUST represent that 621 in the following AVPs: 623 Result-Code is set to a success code [Section 7.1.2 of [RFC6733]]; 625 SASL-Token is included when the SASL exchange produced an additional 626 token upon success [Section 4 of [RFC4422]]; 628 User-Name may be provided, and then contains the utf8-username part 629 of a NAI [RFC7542], but not a utf8-realm; normally, this is the 630 authentication identity for which the inner SASL mechanism 631 succeeded, but if an authorization identity string was supplied 632 and approved, then that is used instead; finally, there may be 633 circumstances that call for sending no User-Name, such as when 634 the inner SASL mechanism was ANONYMOUS (as that does not yield 635 an authenticated user identity). 637 Further AVPs may be included in a successful AA-Answer. Examples are 638 access control list information and backend tunnel creation. No 639 meaning is assigned herein to such additional AVPs. 641 6. Running Diameter as a SASL Backend 643 Following are a few practical considerations in relation to the 644 Diameter connectivity for SASL. 646 6.1. Diameter is an SCTP service 648 Diameter is primarily an SCTP-based protocol [RFC6733], for reasons 649 of scalabaility and efficiency. SASL Diameter benefits from these 650 properties and embraces the SCTP transport. Operating system support 651 for SCTP is wide-spread, but parts of network infrastructure may not 652 support it, and that may cause implementations to add a fallback to 653 more traditional protocols. Standards offer two options for doing 654 this. 656 Diameter can fallback to run over TCP, which is mostly of use to 657 poorly connected client machines, but this sacrifices several 658 benefits of the SCTP carrier. SASL Diameter embeddings typically 659 involve no client systems, so this option is NOT RECOMMENDED. 661 SCTP may be run over a UDP transport using port 9899 [RFC6951], which 662 does not sacrifice much; it only inserts a UDP header before each 663 message. This is a reasonable expectation of foreign servers as well 664 as identity domain, so this additional option is RECOMMENDED for 665 situations where an alternative for native SCTP is desired. It is 666 standardised as a socket option SCTP_REMOTE_UDP_ENCAPS_PORT, and only 667 involves a small repetition in code, with a minor change between the 668 attempts. 670 6.2. Reliance on DANE and DNSSEC 672 Diameter always involves the use of DTLS or TLS, but there is a 673 number of choices concerning the validation of connections through 674 DNSSEC and DANE. It is the identity domain's prerogative what level 675 of protection it upholds for its client identities, but any foreign 676 server MAY choose to raise the bar by setting a minimum accepable 677 level. 679 DNSSEC offers a protection mechanism for the _diameters._sctp SRV 680 records that lead to the Diameter host and its port for the identity 681 domain. DNSSEC can also protect any following AAAA and A records. 682 DNSSEC does not protect against forged IP routes or hijacked port 683 mappings or routing. To protect against this as well, a TLSA record 684 for the service host and port, along with the _sctp protocol label, 685 can be used as specified for DANE [RFC6698]. This use of DNSSEC and 686 DANE is RECOMMENDED. 688 When identity domains choose to be light on these measures they risk 689 that their user identities are hijacked, in spite of the use of DTLS 690 or TLS. Foreign servers MAY choose to reject such identity domains, 691 or alternatively be more restrictive about the certificates that are 692 accepted. 694 7. Security Considerations 696 The SASL mechanism SXOVER-PLUS separates the authentication of a 697 client identity into a domain and a user name underneath it. The 698 user name is validated by an identity server whose authority to 699 identify users for the domain is authenticated by the relying foreign 700 server. 702 From the perspective of the foreign server, assurance of an identity 703 is the vital aspect of the SXOVER-PLUS flow that it forwards over 704 Diameter. Through DTLS or TLS, with DNSSEC and DANE to validate the 705 certificate it uses, the link from an identity domain to the Diameter 706 connection can be verified, so the relying server can be certain 707 about the domain under which its backend connection resides. By 708 receiving a response over that connection to a known-authoritative 709 server for the domain, the user name can also be trusted. The 710 relying server continues to treat the user name and domain as a pair 711 the for identification of the user. 713 Channel binding is normally limited to two parties only, and 714 forwarding such information is not a trivial idea. The fact that the 715 forwarding connection is encrypted, and known to lead to an 716 authoritative server for an identity domain does help. The foreign 717 server relies on proper authentication, and has no interest in 718 bypassing authentication, and it would be doing that by adopting 719 channel binding information from anywhere else. 721 From the perspective of the client and the identity domain, the 722 safety of the SASL credentials is paramount. When addressing a 723 foreign server that is not part of the identity domain, clients 724 therefore MUST NOT rely on mechanisms that might leak credentials. 725 Two mechanisms that are safe to use are ANONYMOUS, which passes no 726 credentials and yields no privileges, and SXOVER-PLUS, which applies 727 end-to-end encryption to another SASL mechanism that may or may not 728 be secure. 730 The SXOVER-PLUS mechanism uses channel binding to ensure that the 731 authentication is specific to a stream. The level to which this is 732 secure depends on the channel binding mechanism. Therefore, in spite 733 of end-to-end encryption, most use cases will want a secure carrier 734 such as TLS between the client and foreign server. 736 8. IANA Considerations 738 This specification defines three AVP Codes for use with Diameter. 739 IANA is requested to register the following AVP Codes for them in the 740 "Authentication, Authorization, and Accounting (AAA) Parameters" 741 registry: 743 AVP Code | Attribute Name | Reference 744 ---------+----------------------+------------ 745 TBD0 | SASL-Mechanism | (this spec) 746 TBD1 | SASL-Token | (this spec) 747 TBD2 | SASL-Channel-Binding | (this spec) 748 This specification defines a SASL mechanism named SXOVER-PLUS. IANA 749 is requested to register the following in the Simple Authentication 750 and Security Layer (SASL) Mechanisms registry under SASL Mechanisms: 752 Mechanism | Usage | Reference | Owner 753 ------------+--------+------------+------------------------------------- 754 SXOVER-PLUS | COMMON | (this doc) | Rick van Rein 756 9. Normative References 758 [I-D.vanrein-internetwide-realm-crossover] 759 Rein, R. V., "InternetWide Identities with Realm 760 Crossover", Work in Progress, Internet-Draft, draft- 761 vanrein-internetwide-realm-crossover-00, 28 September 762 2020, . 765 [RFC2743] Linn, J., "Generic Security Service Application Program 766 Interface Version 2, Update 1", RFC 2743, 767 DOI 10.17487/RFC2743, January 2000, 768 . 770 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 771 C-bindings", RFC 2744, DOI 10.17487/RFC2744, January 2000, 772 . 774 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 775 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 776 2005, . 778 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 779 Kerberos Network Authentication Service (V5)", RFC 4120, 780 DOI 10.17487/RFC4120, July 2005, 781 . 783 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 784 Authentication and Security Layer (SASL)", RFC 4422, 785 DOI 10.17487/RFC4422, June 2006, 786 . 788 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 789 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 790 . 792 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 793 Service Application Program Interface (GSS-API) Mechanisms 794 in Simple Authentication and Security Layer (SASL): The 795 GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, 796 July 2010, . 798 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 799 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 800 . 802 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 803 Kerberos Pre-Authentication", RFC 6113, 804 DOI 10.17487/RFC6113, April 2011, 805 . 807 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 808 of Named Entities (DANE) Transport Layer Security (TLS) 809 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 810 2012, . 812 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 813 Ed., "Diameter Base Protocol", RFC 6733, 814 DOI 10.17487/RFC6733, October 2012, 815 . 817 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 818 Control Transmission Protocol (SCTP) Packets for End-Host 819 to End-Host Communication", RFC 6951, 820 DOI 10.17487/RFC6951, May 2013, 821 . 823 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 824 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 825 . 827 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 828 DOI 10.17487/RFC7542, May 2015, 829 . 831 Appendix A. Centralised handing of SASL over Diameter 833 This section is non-normative. 835 Within foreign server networks, it can be useful to centralise 836 Diameter handling in one host, where service-neutral pooling of 837 connections to remote peers can improve efficiency and security. 838 Diameter could facilitate this directly, but that would add quite a 839 bit of handling logic to various foreign servers. The following 840 ASN.1 module was therefore designed as the simplest possible request/ 841 answer protocol that could run over a TCP connection between a 842 foreign service host and a nearby/trusted centralised host running 843 its side of Diameter. 845 The protocol can also be used over SCTP. In this case, a user 846 message can be defined to contain precisely one DiaSASL-Request in 847 downstream direction, or one DiaSASL-Answer in upstream direction, 848 and sent with the SCTP_UNORDERED flag. 850 Quick-DiaSASL DEFINITIONS EXPLICIT TAGS ::= BEGIN 852 -- ## SASL ready for Diameter 853 -- 854 -- This is targeted at Diameter backends and avoids loading all of 855 -- Diameter into applications. 856 -- 858 -- Open a connection; return is DiaSASL-Open-Answer. 859 -- The service-realm defines the context of the 860 -- identity provider; this is where Diameter requests 861 -- should be send, and it helps to determine what 862 -- sasl-mechanisms may be used. 863 -- 864 -- The front-end is identified by a service-trunk code 865 -- (for the long-term relation between a front-end and 866 -- back-end) and/or a service-proto protocol that can 867 -- be used while driving SASL (it could be the "imap" 868 -- part before the "imap/imap.example.com"PrincipalName 869 -- for a service in a Kerberos Ticket). 870 -- 871 DiaSASL-Open-Request ::= [APPLICATION 10] IMPLICIT SEQUENCE { 872 service-realm [1] UTF8String, 873 service-trunk [8] INTEGER OPTIONAL, 874 service-proto [9] IA5String OPTIONAL 875 } 877 -- Close a connection; session-id identifies which 878 -- and there is no response. This is ignored when the 879 -- session-id is unknown; the call is not required 880 -- after a DiaSASL-Authn-Answer that sets a value for 881 -- final-comerr, but it is harmless when sent anyway. 882 -- 883 DiaSASL-Close-Request ::= [APPLICATION 11] IMPLICIT SEQUENCE { 884 session-id [2] OCTET STRING 885 } 887 -- Relay an authentication request message; response is 888 -- DiaSASL-Authn-Answer with a copied session-id. 889 -- 890 DiaSASL-Authn-Request ::= [APPLICATION 12] IMPLICIT SEQUENCE { 891 session-id [2] OCTET STRING, 892 sasl-mechanism [3] IA5String OPTIONAL, 893 sasl-channel-binding [4] OCTET STRING OPTIONAL, 894 sasl-token [5] OCTET STRING OPTIONAL 895 } 897 -- This is the response to a DiaSASL-Open-Request. 898 -- 899 -- The final-comerr is set when Diameter was conclusive. 900 -- It is an error code from com_err to allow for errors, 901 -- but it may be sufficient to know that 0 indicates success 902 -- and everything else is a failure. 903 -- 904 -- The service-realm is copied from the Diasasl-Open-Request 905 -- so it can be used to match; the session-id will continue 906 -- to identify this session in requests and responses. 907 -- 908 -- The sasl-mechanisms holds a space-separated string of 909 -- SASL mechanism names. 910 -- 911 DiaSASL-Open-Answer ::= [APPLICATION 13] IMPLICIT SEQUENCE { 912 final-comerr [0] INTEGER (-2147483648..2147483647) OPTIONAL, 913 -- Only set when Diameter was conclusive. 914 -- 0 for success, different for failure. 915 -- The code is a com_err code, so int32_t. 916 service-realm [1] UTF8String, 917 session-id [2] OCTET STRING, 918 sasl-mechanisms [3] IA5String 919 } 921 -- This is the response to a DiaSASL-Authn-Request. 922 -- 923 -- The final-result is only set if Diameter was conclusive. 924 -- It is an error code from com_err to allow for errors, 925 -- but it may be sufficient to know that 0 indicates success 926 -- and everything else is a failure. 927 -- 928 -- Only a successful authentication response can hold values 929 -- for client-userid and client-domain. The latter overrides 930 -- the initial realm, which was provided in the open call, 931 -- but may be substituted as a result of Realm Crossover. 932 -- The client-userid is the local part and may be absent on 933 -- anonymous sessions; the client-userid value is approved 934 -- by the local Diameter peer as having come from a Diameter 935 -- Diameter peer that tends to client-domain. 937 -- 938 DiaSASL-Authn-Answer ::= [APPLICATION 14] IMPLICIT SEQUENCE { 939 final-comerr [0] INTEGER (-2147483648..2147483647) OPTIONAL, 940 -- Only set when Diameter was conclusive. 941 -- 0 for success, different for failure. 942 -- The code is a com_err code, so int32_t. 943 session-id [2] OCTET STRING, 944 sasl-token [5] OCTET STRING OPTIONAL, 945 client-userid [6] UTF8String OPTIONAL, 946 client-domain [7] UTF8String OPTIONAL 947 } 949 -- Requests are Open, Close and Authn requests. This simple 950 -- CHOICE differentiates between the variants. 951 -- Note that no extra tags are needed; the [APPLICATION n] 952 -- tag can be used, or the presence of fields in variants. 953 -- 954 DiaSASL-Request ::= CHOICE { 955 open-request DiaSASL-Open-Request, 956 close-request DiaSASL-Close-Request, 957 authn-request DiaSASL-Authn-Request 958 } 960 -- Answers are sent in response to Open and Authn requests. 961 -- This simple CHOICE differentiates between the variants. 962 -- Note that no extra tags are needed; the [APPLICATION n] 963 -- tag can be used, or the presence of fields in variants. 964 -- 965 DiaSASL-Answer ::= CHOICE { 966 open-answer DiaSASL-Open-Answer, 967 authn-answer DiaSASL-Authn-Answer 968 } 970 -- ## A simple API for DiaSASL 972 -- A `diasasl` API only needs a small number of calls: 973 -- http://quick-sasl.arpa2.net/group__quickdiasasl.html 974 -- This presents only a modest extension to existing software, 975 -- and easily merges into a variety of concurrency models. 977 END 979 Appendix B. Support Levels for Realm Crossover 981 This section is non-normative. 983 There are a few levels of support at which Realm Crossover for SASL 984 can be used. An informal description of these levels can be useful 985 for communication purposes. 987 Level 0 constitutes the normal mode with local SASL authentication. 988 This works well when clients are treated as local users of the 989 foreign server. Authentication is therefore carried out on the 990 foreign server. 992 Level 1/2 relays SASL authentication tokens to a statically 993 configured backend, perhaps specific for a host name or resource 994 path. The client is treated as a user of the statically configured 995 backend, which may serve their own domain. This setup can be used 996 for virtual hosting of a service without the need to hold 997 authentication data. 999 Level 1 supports SASL mechanisms for Realm Crossover like SXOVER-PLUS 1000 and relays the SASL information to the DOMAIN embedded in the first 1001 SASL token. In this case, clients can present their own identity 1002 regardless of configuration on the foreign server; the foreign server 1003 welcomes a user to Bring Your Own IDentity. 1005 The Diameter formalisms are required for level 1/2 and level 1, but 1006 are an internal choice at level 0. In all cases, the Quick-DiaSASL 1007 definition in Appendix A may be used to locally concentrate SASL 1008 authentication; the receiving end may be a local SASL identity 1009 provider for level 0 and would be a local Diameter node in level 1/2 1010 and level 1. 1012 Appendix C. Acknowledgements 1014 Thanks to Nico Williams for input on the GS2 bridge and Channel 1015 Binding. 1017 Thanks to NLNet and the NGI Pointer project of the European Union for 1018 each funding parts of this work. 1020 Authors' Addresses 1022 Rick van Rein 1023 OpenFortress BV 1024 Haarlebrink 5 1025 Enschede 1027 Email: rick@openfortress.nl 1028 Henri Manson 1029 Mansoft 1030 Castorstraat 30 1031 Enschede 1033 Email: info@mansoft.nl