idnits 2.17.1 draft-vanrein-diameter-sasl-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 12 characters in excess of 72. ** 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 191: '...ue of the seskey MAY be locally determ...' RFC 2119 keyword, line 192: '... SHOULD be a random seed that can se...' RFC 2119 keyword, line 224: '...2-bit range. It MUST be validated by ...' RFC 2119 keyword, line 230: '... key. Therefore, the SASL client MUST...' RFC 2119 keyword, line 239: '... SHOULD be supported, meaning that a...' (39 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 323 has weird spacing: '...2S-Init is no...' == Line 327 has weird spacing: '...2C-Cont are e...' == Line 421 has weird spacing: '...td-flag is ab...' == Line 429 has weird spacing: '...authzid is us...' == Line 506 has weird spacing: '... name is th...' == (8 more instances...) -- The document date (January 21, 2020) is 1555 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'APPLICATION 1' is mentioned on line 164, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 206, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 251, but not defined == Missing Reference: 'APPLICATION 4' is mentioned on line 283, but not defined == Missing Reference: 'APPLICATION 0' is mentioned on line 399, but not defined == Unused Reference: 'RFC2743' is defined on line 743, but no explicit reference was found in the text == Unused Reference: 'RFC3961' is defined on line 748, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 14 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: Informational January 21, 2020 5 Expires: July 24, 2020 7 Realm Crossover for SASL and GSS-API via Diameter 8 draft-vanrein-diameter-sasl-03 10 Abstract 12 SASL and GSS-API are used for authentication in many application 13 protocols. This specification extends them to allow credentials of a 14 home realm to be used against external services. To this end, it 15 introduces end-to-end encryption for SASL that is safe to relay to 16 the client's home realm. 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 July 24, 2020. 35 Copyright Notice 37 Copyright (c) 2020 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. Messages of GS2-SXOVER-PLUS . . . . . . . . . . . . . . . . . 3 54 2.1. Initial Client-to-Server Message . . . . . . . . . . . . 4 55 2.2. Initial Server-to-Client Message . . . . . . . . . . . . 5 56 2.3. Continued Client-to-Server Messages . . . . . . . . . . . 6 57 2.4. Continued Server-to-Client Messages . . . . . . . . . . . 6 58 3. GS2-SXOVER-PLUS as a GS2 Mechanism . . . . . . . . . . . . . 7 59 3.1. Encrypting GS2-SXOVER-PLUS Messages . . . . . . . . . . . 7 60 3.2. Initial Round-trip Optimisation . . . . . . . . . . . . . 8 61 3.3. Initial Header for GSS-API . . . . . . . . . . . . . . . 8 62 3.4. Initial Header for SASL . . . . . . . . . . . . . . . . . 9 63 4. AVP Definitions for SASL in Diameter . . . . . . . . . . . . 10 64 4.1. SASL-Mechanism . . . . . . . . . . . . . . . . . . . . . 10 65 4.2. SASL-Token . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3. SASL-Channel-Binding . . . . . . . . . . . . . . . . . . 11 67 5. Diameter Message Requirements for GS2-SXOVER-PLUS . . . . . . 11 68 5.1. C2S-Init Requests over Diameter . . . . . . . . . . . . . 12 69 5.2. S2C-Init Responses over Diameter . . . . . . . . . . . . 12 70 5.3. C2S-Cont Requests over Diameter . . . . . . . . . . . . . 13 71 5.4. S2C-Cont Responses over Diameter . . . . . . . . . . . . 14 72 6. Running Diameter as a SASL Backend . . . . . . . . . . . . . 14 73 6.1. Diameter is an SCTP service . . . . . . . . . . . . . . . 14 74 6.2. Reliance on DANE and DNSSEC . . . . . . . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 9. Normative References . . . . . . . . . . . . . . . . . . . . 16 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 It is common for Internet users to combine services from a varierity 84 of providers. Along with this, an ad hoc practice has arisen of 85 using the local identity schemes of these providers. These are not 86 integrated, and the practice tends to reduce the control of users 87 over their online identity. A solution to this is support for realm 88 crossover, where an externally acquired service can make a callback 89 to a home realm to authenticate a user's identity and use that for 90 service-specific authorisation. 92 SASL [RFC4422] is instrumental in authentication across a wide range 93 of application protocols; it allows those protocols to abstract from 94 the actual authentication mechanisms, and at the same time it allows 95 authentication mechanisms to not be concerned about the application 96 protocol. SASL can easily be funneled from one protocol into 97 another, modulo a number of security concerns. 99 Diameter and its Network Access application are instrumental in 100 authenticating a user under a realm, while not providing the 101 resources that an application protocol would imply. Moreover, 102 Diameter service can be declared under a domain name in a manner that 103 is standardised, scalable and secure. 105 This allows a foreign server to authenticate a client to authenticate 106 with its home realm: 108 +--------+ SASL +--------+ SASL +---------+ 109 | Client |-----------> | Server | ---------> | Realm | 110 +--------+ AppProto +--------+ Diameter +---------+ 111 || || || 112 john@example.com find SRV, TLSA example.com 113 & credential relay SASL authentication 115 Diameter can send a mere notification of authentication, and the 116 foreign server can use DANE [RFC6698] to validate the origin of these 117 notifications. Diameter in the foreign server will authenticate to 118 the home realm, which may then decide to add resources beyond the 119 basic notification of authentication. 121 SASL mechanisms are not generally protected against attacks by men in 122 the middle named Eve. This is usually compensated for by wrapping 123 the application protocol in TLS, but since that would only protect 124 one leg of the intended realm-crossing authentication exchange, there 125 is a need for end-to-end encryption. This can be established along 126 with other credentials for the home realm, but an end-to-end 127 mechanism needs to be defined. This specification introduces a 128 wrapper for that pupose, and nests a SASL exchange with the home 129 realm under its cloak. 131 Finally, to avoid the use of one authentication exchange to validate 132 another, it is advisable to incorporate channel binding [RFC5056] 133 [RFC5801] when making use of backends. When passing SASL tokens 134 between application protocol and Diameter backend, the channel 135 binding information from the application protocol would be supplied 136 as a side-note to the Diameter backcall. 138 2. Messages of GS2-SXOVER-PLUS 140 GS2-SXOVER-PLUS establishes a session key and continues with an 141 encrypted, but otherwise normal SASL exchange. This cloak provides 142 end-to-end encryption for the contained SASL exchange, which allows 143 it to be passed through a foreign server. This section defines the 144 messages involved in the GS2-SXOVER-PLUS exchange in isolation, later 145 sections specify how this fits into GSS-API and SASL contexts, and 146 how these travel to the home realm's network access server. 148 By announcing the GS2-SXOVER-PLUS mechanism for SASL, a foreign 149 server declares it is willing to relay SASL messages for that 150 mechanism to the authentication realm indicated by the client in its 151 first GS2-SXOVER-PLUS message in a plaintext form. Later sections 152 define a standard mechanism for relaying such messages over Diameter, 153 using DNSSEC and DANE so that the result can be trusted to have come 154 from the indicated realm and thus warrant any user name scoped under 155 that realm. Offering GS2-SXOVER-PLUS does not preclude the offering 156 of other SASL mechanisms; for instance, ANONYMOUS may be useful to 157 allow clients to choose guest access. 159 2.1. Initial Client-to-Server Message 161 The GS2-SXOVER-PLUS exchange is initiated by the client, by sending a 162 C2S-Init message: 164 C2S-Init ::= [APPLICATION 1] IMPLICIT SEQUENCE { 165 inictr Counter, -- Initial counter value 166 keyno KeyNumber, -- With realm and encalg, identifies... 167 encalg EncryptAlg, -- ...the key for svckeymud decryption 168 seskey OCTET STRING -- RFC 3961 encrypted, key usage 1864 169 } 171 Counter ::= INTEGER (0..4294967295) -- Unsigned 32-bit 172 KeyNumber ::= INTEGER (0..4294967295) -- Unsigned 32-bit 173 EncryptAlg ::= INTEGER (-2147483648..2147483647) -- Signed 32-bit 175 The inictr value is used as a bit of entropy, and will be incremented 176 by one for every next message in the same flow. This helps to bind 177 messages into one flow and to distinguish among flows. Though 178 helpful to protect against replay attacks, dynamic challenges and 179 channel binding offer better protection. 181 The keyno and encalg values present identification information for a 182 key at the Diameter/SASL server, and the seskey is a representation 183 of a session key suitable for decryption with that identified key. 184 The method by which the keyno and encalg and the key itself are 185 established is not defined here, because its choice is local to the 186 client's realm. The reason for not authenticating with this key is 187 that anonymous encryption keys are much easier to establish than 188 authentication keys. One possible mechanism is KIP, the Keyful 189 Identity Protocol, but it is not prescribed herein. 191 The value of the seskey MAY be locally determined, but by default it 192 SHOULD be a random seed that can serve as input to the random-to-key 193 function with the required key-generation seed-length [Section 3 of 194 [RFC3961]] for a session key with the same encryption algorithm 195 enctype as the identified key. The random seed is protected by 196 encryption to the identified key using the Encrypt function 197 [Section 3 of [RFC3961]], which always involves authenticity. The 198 key usage number is shared from the independent KIP protocol, and is 199 set to KIP_KEYUSAGE_MAPPING or 1864. 201 2.2. Initial Server-to-Client Message 203 In both SASL and GSS-API, this first message from server to client is 204 passed as an S2C-Init message: 206 S2C-Init ::= [APPLICATION 2] IMPLICIT SEQUENCE { 207 ctr Counter, -- Counter value is inictr+1 208 realm IA5String, -- Secure realm confirmation 209 mechlist SEQUENCE OF IA5String -- Available SASL mechanisms 210 } 212 The first message from the server to the client is named the Initial 213 Response in SASL. This message presents the client with a choice of 214 mechanism names to use under the cloak of GS2-SXOVER-PLUS. In 215 addition, it securely confirms the realm name that will be assumed in 216 the upcoming exchange. 218 GS2-SXOVER-PLUS makes no assumptions about the mechanisms supported 219 at the home realm. Instead, S2C-Init lists mechanisms specific to 220 the home realm of the client, which are concealed from the foreign 221 server, so it cannot influence the list. 223 The ctr value is simply inictr incremented by 1, with a wrap-around 224 to stay within an unsigned 32-bit range. It MUST be validated by the 225 SASL client. The counter mechanism is both a protection against 226 message resending and a means of having concurrent SASL exchanges if 227 the client wants to. 229 The realm is repeated from the GS2-SXOVER-PLUS request, but this time 230 it is protected by the session key. Therefore, the SASL client MUST 231 validate it before starting the wrapped SASL exchange. 233 The mechlist informs the SASL client of the mechanisms available for 234 authentication against the SASL server. These can be used for the 235 wrapped SASL exchange. The list is not related to any mechanism list 236 that the foreign server will have sent before. Specifically, GS2- 237 SXOVER-PLUS and ANONYMOUS mechanisms should not occur in the wrapped 238 mechlist. Furthermore, only mechanisms supporting channel binding 239 SHOULD be supported, meaning that all strings in mechlist should have 240 a -PLUS ending. 242 2.3. Continued Client-to-Server Messages 244 Further GS2-SXOVER-PLUS messages from client to server are named 245 (initial) responses by SASL, and they are formed by encrypting the 246 DER-form of C2S-Cont under the seskey. There is one special case, 247 namely the need for the first C2S-Cont to select a SASL mechanism to 248 run under the seskey cloak. For all C2S-Cont messages, there is a 249 separate representation for no data, distinguishable from empty data: 251 C2S-Cont ::= [APPLICATION 3] IMPLICIT SEQUENCE { 252 ctr Counter, -- 1 + Previous ctr value 253 c2s SaslToken, -- NULL or token, client to server 254 mechsel IA5String OPTIONAL -- SASL mechanism name selection 255 } 257 SaslToken ::= CHOICE { 258 token OCTET STRING, 259 no-token NULL 260 } 262 This is the first and later of the wrapped SASL messages sent from 263 the client to the server. When it is the first, the mechsel field 264 MUST specify the SASL mechanism that the client selected from the 265 mechsel issued before. The mechsel MUST support channel binding, so 266 it must have a -PLUS ending. In any message, the ctr value is one 267 more than the value in the previous SASL message, reduced to an 268 unsigned 32-bit range; see Section 3.2 for an important detail caused 269 by round-trip optimisation. 271 The SaslToken in c2s is either a literal OCTET STRING with the SASL 272 token to pass, or it is NULL if no token is passed. This implements 273 a distinction between an empty token and no token, as required by 274 SASL [RFC4422]. 276 2.4. Continued Server-to-Client Messages 278 After the first message from the server to the client, they adhere to 279 the structure of S2C-Cont, defined below. The SASL term for these 280 messages would be a Challenge that is not an Initial Challenge. The 281 exchange is encrypted under the seskey: 283 S2C-Cont ::= [APPLICATION 4] IMPLICIT SEQUENCE { 284 ctr Counter, -- 1 + Previous ctr value 285 s2c SaslToken, -- NULL or token, server to client 286 extra OCTET STRING OPTIONAL -- On success, optional extra token 287 } 288 This is the first and later of the wrapped SASL messages sent from 289 the server to the client. In any message, the ctr value is one more 290 than the value in the previous SASL message, reduced to an unsigned 291 32-bit range. 293 The SaslToken in s2c is either a literal OCTET STRING with the SASL 294 token to pass, or it is NULL if no token is passed. This implements 295 a distinction between an empty token and no token, as required for 296 SASL. 298 The extra value can be passed along as a hint to the user for a 299 successful authentication. Mechanisms do not commonly use the field, 300 but SASL offers it. The distinction between an empty OCTET STRING 301 and an absent value is assured through the OPTIONAL modifier. Note 302 that this value should not be passed as part of the GS2-SXOVER-PLUS 303 exchange, as it is part of the SASL mechanism that was selected with 304 mechsel in the wrapped exchange. GS2-SXOVER-PLUS does not specify an 305 extra value, so the field in the outer SASL exchange that runs GS2- 306 SXOVER-PLUS will not be used. 308 3. GS2-SXOVER-PLUS as a GS2 Mechanism 310 The messages of GS2-SXOVER-PLUS will now be mapped to SASL and GSS- 311 API. The GS2 bridge [RFC5056] defines the requirements to make the 312 two behave equavalently on the basis of a header preceding the first 313 "raw" message which is the C2S-Init message. 315 Further messages, so S2C-Init, C2S-Cont and S2C-Cont will be 316 encrypted but otherwise used as-is under both SASL and GSS-API. 318 3.1. Encrypting GS2-SXOVER-PLUS Messages 320 Before inclusion in the GSS-API and SASL frames, most GS2-SXOVER-PLUS 321 messages will be encrypted: 323 C2S-Init is not encrypted, but it contains a seskey field that is 324 encrypted under the long-term key with key usage value 325 KIP_KEYUSAGE_MAPPING or 1864; 327 S2C-Init, C2S-Cont, S2C-Cont are encrypted under the seskey, as 328 supplied in the C2S-Init that started the session, with key 329 usage value KIP_KEYUSAGE_USERDATA or 1863. 331 The encrypt operation [Section 3 of [RFC3961]] uses default initial 332 state and is known to also guarantee integrity. The name KIP 333 references the compatible Keyful Identity Protocol, which may or may 334 not develop independently of GS2-SXOVER-PLUS. 336 3.2. Initial Round-trip Optimisation 338 This section introduces an optimisation that MUST be accepted by 339 servers, and MAY be sent by clients. In addition, the server MAY use 340 it in response to optimised messages to clients which MUST then 341 accept it. 343 Normally, the C2S-Init, S2C-Init, C2S-Cont and S2C-Cont messages are 344 all placed in a single GSS-API or SASL message, with encryption and 345 headers applied as dictated for each occasion. The optimisation 346 described here concatenates an opportunistic C2S-Cont to C2S-Init, 347 and upon acceptance of the opportunistic attempt the server sends not 348 only a S2C-Init, but also the accepting S2C-Cont. 350 Encryption is applied to the GS2-SXOVER-PLUS messages before they are 351 concatenated. The header is applied after concatenation. 353 The Counter values used in case of success or failure of the 354 opportunistic attempt are: 356 Message | Counter on success | Counter on failure 357 ----------+----------------------+-------------------- 358 C2S-Init | inictr | inictr 359 C2S-Cont | inictr + 2 | inictr + 2 360 S2C-Init | inictr + 1 | inictr + 1 361 S2C-Cont | inictr + 3 | (message absent) 362 next... | inictr + 4,5,6... | inictr + 3,4,5... 364 or, in words, the counter is not incremented when failure causes the 365 S2C-Init to not be sent. This is reflected in the next messages, 366 which would start with another attempted C2S-Cont, and normal 367 counting commences from that point. 369 The use of this pattern is that a mechanism may be tried immediately, 370 without awaiting the mechanism list. Very often, clients will be 371 setup to validate using a particular mechanism, or they may have 372 learnt from a prior exchange. This is particularly useful because 373 traffic concentrates at the home realm, which usually leads to a 374 stable mechanism list. 376 3.3. Initial Header for GSS-API 378 The header to use for GSS-API is standardised as a Mechanism- 379 Independent Token Format [Section 3.1 of [RFC2743]] and prefixed to 380 the initial token of a GSS-API context establishment sequence, 381 incorporating the object identifier 1.3.6.1.4.1.44469.666.5081.1 382 (TBD:GSSOID) to identify GS2-SXOVER-PLUS. When this object 383 identifier is supplied to the call GSS_Inquire_SASLname_for_mech 385 [Section 10 of [RFC5801]], the output reads "GS2-SXOVER-PLUS" 386 (without the quotes). 388 Following the header is a GSS-API variant of C2S-Init, which prefixes 389 an authorization identity, interpreted as defined in the GS2 header 390 for SASL. The structure after the header in ASN.1 notation is: 392 GSS-SXOVER-Init ::= SEQUENCE { 393 gs2-authzid IA5String, 394 c2s-init C2S-Init 395 } 397 The annotated bytes are shown below: 399 60 02 ...length... -- [APPLICATION 0] IMPLICIT SEQUENCE { ... } 400 -- OBJECT IDENTIFIER 1.3.6.1.4.1.44469.666.5081.1 (TBD:GSSOID) 401 06 ...length... 2b 06 01 04 01 44469 TBD:666 TBD:5081 01 -- OBJECT IDENTIFIER 402 -- GSS-SXOVER-Init 403 30 ...length... -- SEQUENCE { ... } 404 ... 406 The mapping of GS2-SXOVER-PLUS into GSS-API is less natural than into 407 SASL, because it references SASL mechanisms. This is not a strict 408 problem however, and implementers MAY provide GS2-SXOVER-PLUS as a 409 GSS-API mechanism. The absense of a realm name in the generic parts 410 of the protocol may however lead to difficulties routing. 412 The function GSS_Inquire_SASLname_for_mech [Section 10 of [RFC5801]] 413 maps the aforementioned object identifier for the GSS-API mechanism 414 to the name "GS2-SXOVER-PLUS" (without quotes). 416 3.4. Initial Header for SASL 418 The header to use for SASL is the gs2-header [RFC5801] with a few 419 extra constraints: constrained than its general form, namely: 421 gs2-nonstd-flag is absent; 423 gs2-cb-flag MUST NOT be "y" or "n" because channel binding is 424 required; the only remaining general form is therefore ("p=" 425 cb-name); a foreign server MUST interpret this flag and relay 426 the appropriate channel binding information through its 427 Diameter backend; 429 gs2-authzid is used for routing of C2S-Init to the Diameter server 430 of the authoritative backend realm. This field MUST contain at 431 least one AT symbol U+0040. The domain name for the backend is 432 mentioned after the last AT symbol. Anything preceding the AT 433 symbol is interpreted by the local realm, and MAY be used for 434 realm-internal routing to a more specific Diameter backend 435 service node, but identification is done within the realm by 436 the inner SASL layer, and the foreign server MUST NOT rely on 437 text before the last AT symbol. 439 As an example, the gs2-header targeting a realm "example.com" and 440 channel binding through tls-unique could be 442 p=tls-unique,@example.com, 444 or, when example.com uses internal GS2-SXOVER-PLUS routing to a 445 service node named +idp+sxover it might be 447 p=tls-unique,+idp+sxover@example.com, 449 In both cases, the last comma would be immediately followed by the 450 DER-encoded S2C-Init structure. Since SASL tokens are always carried 451 over binary channels, there is no use in continuing the message in a 452 textual form. 454 4. AVP Definitions for SASL in Diameter 456 SASL messages in Diameter use a number of AVPs [Section 4 of 457 [RFC6733]] that are combined to relay SASL to an authentication 458 realm. 460 These AVPs are added to the set that is used with the Network Access 461 Server application [RFC7155], and can therefore be used in AA-Request 462 and AA-Answer messages. On top of that, the SASL-Mechanism AVP may 463 also occur in a Capabilities Exchange Answer. The User-Name AVP MUST 464 be supplied in a successful AA-Answer to inform the server about the 465 user name that the backend decided on; the server MAY send a hint 466 requesting a value in the User-Name AVP in the AA-Request. 468 4.1. SASL-Mechanism 470 The SASL-Mechanism AVP has AVP Code TBD0. This specification only 471 uses the mechanism name GS2-SXOVER-PLUS as a value for this AVP. It 472 MUST be included in the first message of an GS2-SXOVER-PLUS exchange 473 sent to the home realm, and it SHOULD be verified by the home realm 474 upon reception. Its purpose is mostly to distinguish this 475 specification from potential future specifications to encapsulate 476 SASL in Diameter. 478 Though not used in this specification, this AVP may also be supplied 479 from the home realm to the Diameter client to hold a space-separated 480 list of SASL mechanisms. 482 4.2. SASL-Token 484 The SASL-Token AVP has AVP Code TBD1. SASL requires distinction 485 between empty and absent tokens; absent SASL tokens are represented 486 by absence of the SASL-Token AVP and empty SASL tokens are 487 represented as a present SASL-Token AVP with zero content bytes. 489 4.3. SASL-Channel-Binding 491 The SASL-Channel-Binding AVP has AVP Code TBD2. It MUST appear along 492 the first SASL-Token AVP for a Network Access session if the SASL- 493 Mechanism ends in -PLUS. 495 This AVP may occur more than once, to indicate support of multiple 496 forms of channel binding. Note however that all mechanisms suitable 497 for Diameter relaying use the GS2 bridge [RFC5056] in which case the 498 channel binding name to pass along in this message can be derived. 500 When the client connects to the foreign service over TLS, the tls- 501 unique form [RFC5929] of channel binding is RECOMMENDED. Specific 502 foreign servers may however be exempted by the home realm. 504 The contents of this AVP concatenates two values: 506 name is the standard name of the channel binding information, 507 followed by a zero-valued byte. 509 value contains the bytes of the channel binding information. 511 Normally, channel binding information should be sourced from the 512 underlying communications channel, but this information is not 513 available to a SASL backend running Diameter. To enable channel 514 binding between the end points, the foreign server incorporates the 515 channel binding information that the client can use in its connection 516 to the foreign server. This is useful to mitigate replay attacks, 517 which is why its use is RECOMMENDED. 519 5. Diameter Message Requirements for GS2-SXOVER-PLUS 521 This section explains how the various GS2-SXOVER-PLUS messages are 522 forwarded over Diameter by the foreign server. The foreign server is 523 connected to the SASL client, usually over a TLS connection, and 524 relays requests over Diameter, usually over SCTP with DTLS. 526 Diameter servers provide success and failure responses, based on the 527 corresponding final results from a SASL service that they in turn 528 use. When no such final result comes from a Diameter request, a 529 challenge will instead be produced over Diameter, holding a SASL 530 challenge token from the server. 532 5.1. C2S-Init Requests over Diameter 534 To send C2S-Init, possibly including the C2S-Cont that the 535 optimisation adds, the Diameter client MUST include at least the 536 following AVPs in an AA-Request [Section 3.1 of [RFC7155]]: 538 Realm is the client's requested realm, replicated here for routing 539 purposes; GS2-SXOVER-PLUS provides this value in the 540 gs2-header's authorization identity field; 542 SASL-Mechanism is set to the fixed string GS2-SXOVER-PLUS; 544 SASL-Token is set to the C2S-Init and optional C2S-Cont as it 545 arrived from the SASL client; 547 SASL-Channel-Binding is set to the channel binding information for 548 the connection in which the SASL client attempts 549 authentication, adhering to the channel binding mechanism named 550 in the gs2-header in the SASL-Token. 552 It is possible to extend the message with more AVPs if the client and 553 server have agreed on this, perhaps as a result of capability 554 negotiation during Diameter connection setup. 556 The C2S-Init Request is likely to hold other Diameter AVPs for 557 general housekeeping of Diameter in general and the NAS application, 558 such as Session-Id. Though User-Name and User-Password would be sent 559 with password-based Diameter mechanisms, they are not required in 560 C2S-Init messages, but they MAY be sent with empty contents to 561 accommodate software and the RECOMMENDED status of the AVPs in the 562 AA-Request, in which case they MUST be ignored on reception. 564 5.2. S2C-Init Responses over Diameter 566 The Diameter server serves as a SASL server to which the foreign 567 server relays requests. To this end, the Diameter server responds 568 with acceptance, denial or a further challenge. Acceptance and 569 denial are used for the corresponding SASL outcomes, the further 570 challenge also matches logically. 572 When the SASL server responds with S2C-Init over Diameter, the 573 Diameter server MUST include at least the following AVPs in a 574 successful AA-Answer [Section 3.2. of [RFC7155]]: 576 User-Name is set to the identity of the SASL client, which resulted 577 from the encapsulated SASL exchange and possibly further 578 authorisation processing in the SASL server; the name MUST NOT 579 add the realm name in this attribute; it is up to the foreign 580 server to assign it under the authoritative realm, possibly by 581 appending the last U+0040 (AT) character and its realm name 582 observed from the GS2 header sent in C2S-Init over Diameter. 584 Permissions may be expected from a Diameter server, but are 585 considered optional for SASL over Diameter. The reason is that 586 SASL focusses on authentication, not authorisation. This 587 especially applies to realm crossover, where authentication is 588 a matter of the home realm and authorisation is, at least by 589 default, the prerogative of the foreign server implementing its 590 own resource with its own semantics. Extensions to this 591 specification could however be made to use the infrastructure 592 proposed herein to also centralise the storage and/or 593 processing of resource access rights. 595 If the SASL exchange requires continuation, then the AA-Answer 596 represents a challenge to follow up, represented in the an AA-Answer 597 that MUST include at least the following AVPs: 599 Result-Code is set to the value DIAMETER_MULTI_ROUND_AUTH; 601 SASL-Token is set to the S2C-Init value; 603 State is set to server state to be reproduced in the followup. 605 If the AA-Answer is a final failure report, this MUST be represented 606 in a failing Result-Code AVP. 608 5.3. C2S-Cont Requests over Diameter 610 The C2S-Cont message is any further message that the SASL client 611 passes to the foreign server. It is forwarded as a Diameter AA- 612 Request [Section 3.1 of [RFC7155]] which MUST contain at least the 613 following AVP: 615 SASL-Token is set to the token from the SASL client. 617 The C2S-Cont Request MUST NOT contain AVPs for SASL-Mechanism or 618 SASL-Channel-Binding. It is however likely to hold other Diameter 619 AVPs for general housekeeping of Diameter in general and the NAS 620 application, such as Session-Id and State AVPs. Though User-Password 621 would be sent with password-based mechanisms, it is not required in 622 C2S-Cont messages, but it MAY be sent with empty contents to 623 accommodate software and the RECOMMENDED status of the AVP, in which 624 case it MUST be ignored on reception. 626 5.4. S2C-Cont Responses over Diameter 628 The S2C-Cont Response message may inform the Diameter client of 629 success, failure or a further challenge. It is transmitted over 630 Diameter as a Diameter AA-Answer [Section 3.2 of [RFC7155]] message, 631 with the customary Result-Code interpretations. 633 Processing of these Diameter messages is the same as for S2C-Init, 634 with the exception that the SASL-Token, if it is present, is not 635 interpreted as S2C-Init but as S2C-Cont. 637 6. Running Diameter as a SASL Backend 639 Following are a few practical considerations in relation to the 640 Diameter connectivity for SASL. 642 6.1. Diameter is an SCTP service 644 Diameter is primarily an SCTP-based protocol [RFC6733], for reasons 645 of scalabaility and efficiency. SASL Diameter benefits from these 646 properties and embraces the SCTP carrier. Operating system support 647 for SCTP is wide-spread, but parts of network infrastructure may not 648 support it, and that may cause implementations to add a fallback to 649 more traditional protocols. Standards offer two options for doing 650 this. 652 Diameter can fallback to run over TCP, which is mostly of use to 653 client-only machines, but then sacrifices several benefits of the 654 SCTP carrier. SASL Diameter embeddings typically involve no client 655 systems, so this option is NOT RECOMMENDED. 657 SCTP may be run over a UDP transport using port 9899 [RFC6951], which 658 does not sacrifice much; it only inserts a UDP header before each 659 message. This is a reasonable expectation of foreign servers as well 660 as home realms, so this additional option is RECOMMENDED for 661 situations where a fallback for plain SCTP is desired. It is 662 standardised as a socket option SCTP_REMOTE_UDP_ENCAPS_PORT, and only 663 involves a small repetition in code, with a minor change between the 664 attempts. 666 6.2. Reliance on DANE and DNSSEC 668 Diameter always involves the use of TLS, but there is a number of 669 choices concerning the validation of connections through DNSSEC and 670 DANE. It is the home realm's prerogative what level of protection it 671 upholds for its client identities, but any foreign server can choose 672 to raise the bar by setting a minimum standard. 674 DNSSEC offers a protection mechanism for the _diameter._sctp SRV 675 records that lead to the Diameter host and its port for the home 676 realm. This does not protect against forged IP addresses, port 677 mappings or routing. To protect against this as well, a TLSA record 678 for the service host and port, along with the _sctp protocol label, 679 can be used as specified for DANE [RFC6698]. This use of DNSSEC and 680 DANE is RECOMMENDED. 682 Home realms that choose to be light on such measures risk that 683 identities are forged, in spite of their use of TLS. Foreign servers 684 MAY choose to reject such home realms, or alternatively be more 685 inquisitive about the certificates used. 687 7. Security Considerations 689 The SASL mechanism GS2-SXOVER-PLUS separates the authentication of a 690 foreign identity into its realm and the username underneath it. The 691 realm is authenticated by the relying server, such as the proposed 692 foreign server, whereas the username is obtained from a backend realm 693 server that is known to be responsible for that realm. 695 From the perspective of the foreign server, assurance of an identity 696 is the vital aspect of the GS2-SXOVER-PLUS flow that it relays over 697 Diameter. Through TLS or DTLS, with DNSSEC and DANE to validate the 698 certificate it uses, the link from a realm (which is read as a domain 699 name) to the Diameter connection can be verified, so the relying 700 server can be certain about the realm under which the backend 701 connection resides. By receiving a response over that connection to 702 a known-authoritative server for the realm, the username can also be 703 trusted. The relying server continues to treat the username and 704 realm as a pair the for identification of the user. 706 Channel binding is normally limited to two parties only, and 707 forwarding such information is not a trivial idea. The fact that the 708 forwarding connection is encrypted, and known to lead to an 709 authoritative server for a claimed realm does help. The intermediate 710 server relies on proper authentication, and has no interest in 711 bypassing authentication, and it would be doing that by adopting 712 channel binding information from anywhere else. 714 From the perspective of the client and the home realm, the safety of 715 the SASL credentials is paramount. When addressing a foreign server, 716 which is not part of the home realm, clients therefore MUST NOT rely 717 on mechanisms that might leak credentials. Two mechanisms that are 718 safe to use are ANONYMOUS, which passes no credentials and assigns no 719 rights, and GS2-SXOVER-PLUS, which applies end-to-end encryption to 720 another SASL mechanism that may or may not be secure. 722 The GS2-SXOVER-PLUS mechanism uses channel binding to ensure that the 723 authentication is specific to a stream. The level to which this is 724 secure depends on the channel binding mechanism. Therefore, in spite 725 of end-to-end encryption, most use cases will want a secure carrier 726 such as TLS between the client and foreign server. 728 8. IANA Considerations 730 This specification defines three AVP Codes for use with Diameter. 731 IANA registers the following AVP Codes for them in the 732 "Authentication, Authorization, and Accounting (AAA) Parameters" 733 registry: 735 AVP Code | Attribute Name | Reference 736 ---------+----------------------+------------ 737 TBD0 | SASL-Mechanism | (this spec) 738 TBD1 | SASL-Token | (this spec) 739 TBD2 | SASL-Channel-Binding | (this spec) 741 9. Normative References 743 [RFC2743] Linn, J., "Generic Security Service Application Program 744 Interface Version 2, Update 1", RFC 2743, 745 DOI 10.17487/RFC2743, January 2000, 746 . 748 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 749 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 750 2005, . 752 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 753 Authentication and Security Layer (SASL)", RFC 4422, 754 DOI 10.17487/RFC4422, June 2006, 755 . 757 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 758 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 759 . 761 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 762 Service Application Program Interface (GSS-API) Mechanisms 763 in Simple Authentication and Security Layer (SASL): The 764 GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, 765 July 2010, . 767 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 768 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 769 . 771 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 772 of Named Entities (DANE) Transport Layer Security (TLS) 773 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 774 2012, . 776 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 777 Ed., "Diameter Base Protocol", RFC 6733, 778 DOI 10.17487/RFC6733, October 2012, 779 . 781 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 782 Control Transmission Protocol (SCTP) Packets for End-Host 783 to End-Host Communication", RFC 6951, 784 DOI 10.17487/RFC6951, May 2013, 785 . 787 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 788 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 789 . 791 Appendix A. Acknowledgements 793 Thanks to Nico Williams for input on the GS2 bridge and Channel 794 Binding. 796 Author's Address 798 Rick van Rein 799 ARPA2.net 800 Haarlebrink 5 801 Enschede, Overijssel 7544 WP 802 The Netherlands 804 Email: rick@openfortress.nl