idnits 2.17.1 draft-perez-krb-wg-gss-preauth-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 are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 2021) is 953 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos Working Group A. Perez-Mendez 3 Internet-Draft Jisc 4 Intended status: Experimental R. Marin-Lopez 5 Expires: 27 March 2022 University of Murcia 6 F. Pereniguez-Garcia 7 University Defense Center 8 G. Lopez-Millan 9 University of Murcia 10 L. Howard-Bentata 11 PADL Software Pty Ltd 12 September 2021 14 GSS-API pre-authentication for Kerberos 15 draft-perez-krb-wg-gss-preauth-03 17 Abstract 19 This document describes a pre-authentication mechanism for Kerberos 20 based on the Generic Security Service Application Program Interface 21 (GSS-API), which allows a Key Distribution Center (KDC) to 22 authenticate clients by using a GSS mechanism. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 5 March 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Cookie Support . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. More Pre-Authentication Data Required . . . . . . . . . . 3 62 2.3. Support for Exporting Partially Established Contexts . . 4 63 2.4. Processing of Channel Bindings in Single Round-Trip . . . 4 64 3. Definition of the GSS padata . . . . . . . . . . . . . . . . 4 65 4. GSS-API Pre-authentication Operation . . . . . . . . . . . . 4 66 4.1. Kerberos client (GSS-API initiator) . . . . . . . . . . . 4 67 4.2. KDC (GSS-API acceptor) . . . . . . . . . . . . . . . . . 5 68 5. Indication of Supported Mechanisms . . . . . . . . . . . . . 6 69 6. Reply Key Derivation . . . . . . . . . . . . . . . . . . . . 7 70 7. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8. Anonymous Authentication . . . . . . . . . . . . . . . . . . 8 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The Generic Security Service Application Programming Interface (GSS- 80 API) [RFC2743] provides a framework for authentication and message 81 protection services through a common programming interface, allowing 82 applications to remain agnostic from the selected mechanism. 84 Kerberos [RFC4120] is an authentication service based on the Needham- 85 Schroeder symmetric key protocol. It includes a facility called pre- 86 authentication designed to ensure clients prove knowledge of their 87 long-term key before the Key Distribution Center (KDC) issues a 88 ticket. Typical pre-authentication mechanisms include encrypted 89 timestamp [RFC4120] and public key certificates [RFC4556]. Pre- 90 authentication data in these messages provides a typed hole for 91 exchanging information used to authenticate the client. 93 [RFC6113] specifies a framework for pre-authentication in Kerberos, 94 describing the features such a pre-authentication mechanism may 95 provide such as authenticating the client and/or KDC and 96 strengthening or replacing the reply key in the AS-REP. FAST 97 (Flexible Authentication Secure Tunneling) provides a generic and 98 secure transport for pre-authentication elements prior to the 99 exchange of any pre-authentication data. The inner pre- 100 authentication mechanism is called a FAST factor. FAST factors can 101 generally not be used outside FAST as they assume the underlying 102 security layer provided by FAST. 104 This document defines a new pre-authentication method that relies on 105 GSS-API security services to pre-authenticate Kerberos clients. This 106 method allows the KDC to authenticate clients using any current or 107 future GSS-API mechanism, as long as they satisfy the minimum 108 security requirements described in this specification. The Kerberos 109 client assumes the role of the GSS-API initiator, and the 110 Authentication Service (AS) the role of the GSS-API acceptor. It may 111 be used as a FAST factor or without FAST. 113 This work was originally motivated by the desire to allow Kerberos to 114 use the protocols defined in [RFC7055] to authenticate federated 115 users with EAP. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Prerequisites 125 2.1. Cookie Support 127 KDCs which support GSS-API pre-authentication with mechanisms that 128 require more than one round-trip to establish a security context MUST 129 have a secure mechanism for retaining state between AS-REQs. For 130 stateless KDC implementations, this will typically be a digest of the 131 initial KDC-REQ-BODY concatenated with a GSS_Export_sec_context() 132 token, encrypted in a key known only to the KDC and protected from 133 replay attacks (see Section 5.2 of [RFC6113]). The format of the PA- 134 FX-COOKIE is implementation defined. 136 Clients that support GSS-API pre-authentication with mechanisms that 137 require more than one round-trip MUST echo the received PA-FX-COOKIE 138 in the next AS-REQ (within a given conversation). 140 2.2. More Pre-Authentication Data Required 142 Both KDCs and clients which implement GSS-API pre-authentication MUST 143 support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as decribed in 144 Section 5.2 of [RFC6113]. 146 2.3. Support for Exporting Partially Established Contexts 148 KDC implementations that use exported context tokens to maintain 149 state will call GSS_Export_sec_context() and GSS_Import_sec_context() 150 on partially established acceptor contexts. This may require 151 modifications to the mechanism implementation, as [RFC2743] only 152 requires these functions succeed on fully established contexts. 154 2.4. Processing of Channel Bindings in Single Round-Trip 156 The client's KDC request is bound to the GSS-API context 157 establishment through the use of channel bindings. GSS-API 158 mechanisms that require more than one round-trip do not expose at 159 which point in the exchange the channel bindings are validated, and 160 assume they are constant for all context establishment calls. In 161 this specification, the channel bindings contain the encoded client 162 request body, which may vary for each round-trip if a fresh nonce is 163 used on each request. 165 To accommodate this, and to avoid re-encoding the request body 166 without the nonce, this specification imposes the additional 167 requirement that the GSS-API mechanism processes channel bindings in 168 a single round-trip within the pre-authentication conversation. 170 3. Definition of the GSS padata 172 The GSS-API defines an exchange of opaque tokens between the 173 initiator (client) and acceptor (service) in order to authenticate 174 each party. GSS-API does not define the transport over which these 175 tokens are carried. This specification defines a Kerberos pre- 176 authentication type, PA-GSS, which carries a GSS-API context token 177 from the Kerberos client to the AS and vice versa. 179 PA-GSS 633 180 -- output_token from GSS_Init_sec_context() 181 -- or GSS_Accept_sec_context() 183 4. GSS-API Pre-authentication Operation 185 4.1. Kerberos client (GSS-API initiator) 187 The Kerberos client begins by calling GSS_Init_sec_context() with the 188 desired credential handle and the target name of the TGS, including 189 the instance and realm. If the underlying mechanism supports 190 Kerberos names, the TGS name MUST be imported as a 191 GSS_KRB5_NT_PRINCIPAL_NAME; otherwise, it SHALL be imported as a 192 GSS_C_NT_HOSTBASED_SERVICE with "krbtgt" as the "service" element and 193 the TGS realm as the "hostname" element (see [RFC2743] Section 4.1). 195 In the first call to GSS_Init_sec_context(), input_context_handle is 196 GSS_C_NO_CONTEXT and input_token is empty. In subsequent calls the 197 client uses the context_handle value obtained after the first call, 198 and the input_token received from the KDC. The mutual_req_flag MUST 199 be set. 201 In order to bind the GSS-API and Kerberos message exchanges, the DER- 202 encoded KDC-REQ-BODY from the AS-REQ is passed as channel binding 203 application data. As the nonce may differ between requests (see 204 [RFC6113] Section 5.4.3), this requires the GSS-API mechanism to 205 process the channel binding information in a single round-trip. To 206 avoid this potential interoperability issue, clients MAY use a single 207 nonce for all messages in a conversation once GSS-API pre- 208 authentication has commenced. 210 If GSS_Init_sec_context() returns GSS_S_CONTINUE_NEEDED, the 211 output_token is sent to the KDC in the PA-GSS pre-authentication data 212 and the client expects either a KRB-ERROR containing another context 213 token, or an AS-REP optionally containing a final context token. 215 Once GSS_Init_sec_context() returns GSS_S_COMPLETE, the context is 216 ready for use. The AS-REP is decrypted using the reply key (see 217 Section 6) and the Kerberos client name MAY be replaced by the AS-REP 218 cname (see Section 7). The client MUST fail if the mutual_state flag 219 is not set when fully established, unless the KDC was authenticated 220 by some other means such as a FAST armor. 222 The response received from the KDC must agree with the expected 223 status from GSS_Init_sec_context(). It is a state violation to 224 receive an AS-REP from the KDC when the initiator still has 225 additional tokens to send to the KDC (GSS_S_CONTINUE_NEEDED), or 226 conversely to receive KDC_ERR_MORE_PREAUTH_DATA_REQUIRED if the 227 context from the initiator's perspective was already open 228 (GSS_S_COMPLETE). 230 When receiving a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error from the 231 KDC, an PA-FX-COOKIE from the KDC MUST be present and copied into the 232 subsequent AS-REQ. 234 4.2. KDC (GSS-API acceptor) 236 When the KDC receives an AS-REQ message containing PA-GSS pre- 237 authentication data, it first looks for an PA-FX-COOKIE and if 238 present retrieves the context handle associated with the cookie, 239 typically by passing the context token from the decrypted cookie to 240 GSS_Import_sec_context(). The absence of an PA-FX-COOKIE indicates a 241 new conversation and the client sending an initial context token. 243 The KDC SHALL associate the KDC-REQ-BODY of the initial request with 244 the pre-authentication conversation. On subsequent requests, the KDC 245 MUST abort the conversation and return an error if the KDC-REQ-BODY 246 differs from the initial request. The nonce is excluded from this 247 comparison. This extends the protection afforded by the channel 248 binding to all requests in the conversation, not just the request 249 where the mechanism validated the channel bindings. (No specific 250 implementation is required, but one approach would be for the KDC to 251 include a digest of the KDC-REQ-BODY with the nonce set to zero in 252 the PA-FX-COOKIE contents.) 254 If no PA-GSS pre-authentication data is present, the KDC cannot 255 continue with GSS-API pre-authentication and will continue with other 256 pre-authentication methods or return an error as determined by local 257 policy. If PA-GSS pre-authentication data is present but empty, the 258 KDC SHALL return a KDC_ERR_PREAUTH_FAILED error. Otherwise, 259 GSS_Accept_sec_context() is called with the acceptor credential 260 handle, the token provided in the PA-GSS pre-authentication data, and 261 channel binding application data containing the DER-encoded KDC-REQ- 262 BODY. 264 If GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED, the KDC 265 returns a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error with the output 266 token included as PA-GSS pre-authentication data. The acceptor state 267 is encoded, typically by calling GSS_Export_sec_context(), and the 268 encrypted result is placed in an PA-FX-COOKIE. 270 If GSS_Accept_sec_context() returns GSS_S_COMPLETE, the context is 271 ready for use and an AS-REP is returned using the reply key specified 272 in Section 6. Otherwise, an appropriate error such as 273 KDC_ERR_PREAUTH_FAILED is returned to the client and the conversation 274 is aborted. If the mechanism emitted an error token on failure, it 275 SHOULD be returned to the client. 277 If the GSS-API mechanism requires an odd number of messages to 278 establish a security context, the KDC MUST include an empty GSS-PA 279 pre-authentication data in the last message of a successful 280 conversation. 282 5. Indication of Supported Mechanisms 284 When the KDC sends a KDC_ERR_PREAUTH_REQUIRED error to the client, it 285 MAY include a pre-authentication data element indicating the set of 286 supported mechanisms. The pre-authentication data comprises of a 287 SPNEGO server initiated initial context token as defined in [MS-SPNG] 288 3.2.5.2, containing the list of mechanisms supported by the acceptor. 289 Context state is discarded and as such the first PA-GSS from the 290 client is always an InitialContextToken ([RFC2743] Section 3.1). 292 6. Reply Key Derivation 294 The GSS-API pre-authentication mechanism proposed in this draft 295 provides the Replace Reply Key facility [RFC6113]. 297 After authentication is complete, the client and KDC replace the AS- 298 REP reply key with the output of calling GSS_Pseudo_random() 299 [RFC4401] with the following parameters: 301 context The initiator or acceptor context handle 303 prf_key GSS_C_PRF_KEY_FULL 305 prf_in KRB-GSS || 0x00 || AS-REQ nonce 307 desired_output_len The length in bytes of original reply key 309 The nonce is the nonce of the final AS-REQ in the conversation, and 310 is encoded as the little-endian binary representation of 4 bytes. 311 The new reply key has the same key type as the original key. If FAST 312 is used, the new reply key SHOULD be strengthened by including a 313 strengthen key in the KrbFastResponse. 315 7. Naming 317 This specification permits Kerberos clients to authenticate without 318 knowing how the KDC will map their GSS-API initiator name to a 319 Kerberos principal. In such cases the client SHALL set the value of 320 the cname field in the AS-REQ to the well-known [RFC6111] value 321 WELLKNOWN/FEDERATED, replacing it after a successful conversation 322 with the client name returned in the AS-REP. 324 When the initiator knows the Kerberos client name it wishes to 325 authenticate as, and the mechanism supports Kerberos names, the name 326 MUST be imported using the GSS_KRB5_NT_PRINCIPAL_NAME name type. 327 Otherwise, GSS_C_NT_USER_NAME SHOULD be used when importing NT- 328 PRINCIPAL names in the local realm, or NT-ENTERPRISE [RFC6806] names. 329 GSS_C_NT_HOSTBASED_SERVICE SHOULD be used when importing NT-SRV-HOST 330 or NT-SRV-INST names with a single instance. 332 This specification does not mandate a specific mapping of GSS-API 333 initiator names to Kerberos principal names. KDCs MAY use the NT- 334 ENTERPRISE principal name type to avoid conflating any domain- or 335 realm-like components of initiator names with Kerberos realms. 337 The KDC MAY include an AD-GSS-COMPOSITE-NAME authorization data 338 element, containing name attribute information. Its value is the 339 exp_composite_name octet string resulting from a successful call to 340 GSS_Export_name_composite() [RFC6680]. It SHOULD be enclosed in a 341 AD-IF-RELEVANT container. The format of composite name tokens is 342 implementation dependent; services that cannot parse the name token 343 MUST fail if the authorization data element was not enclosed in AD- 344 IF-RELEVANT. 346 8. Anonymous Authentication 348 If the client wishes to authenticate anonymously using GSS-API pre- 349 authentication, it MUST specify both the request-anonymous flag in 350 the AS-REQ and anon_req_flag in the call to GSS_Init_sec_context(). 351 If GSS_Accept_sec_context() set anon_state and returned an initiator 352 name of type GSS_C_NT_ANONYMOUS, the KDC MUST map the user to the 353 well-known anonymous PKINIT principal and realm defined in [RFC8062]. 355 If GSS_Accept_sec_context() set anon_state but did not return an 356 initiator name of type GSS_C_NT_ANONYMOUS, then the KDC MUST return 357 the well-known anonymous principal but it MAY include the realm of 358 the initiator. 360 9. Security Considerations 362 The client SHOULD use FAST armor to protect the pre-authentication 363 conversation. 365 The KDC MUST maintain confidentiality and integrity of the PA-FX- 366 COOKIE contents, typically by encrypting it using a key known only to 367 itself. Cookie values SHOULD be protected from replay attacks by 368 limiting their validity period and binding their contents to the 369 client name in the AS-REQ. 371 The establishment of a GSS-API security context is bound to the 372 client's AS-REQ through the inclusion of the encoded KDC-REQ-BODY as 373 channel bindings (see Section 4.1), and the nonce as input to the key 374 derivation function (see Section 6). By asserting the KDC-REQ-BODY 375 does not change during the conversation (nonce notwithstanding), the 376 channel bindings protect all request bodies in the conversation. 378 The KDC MAY wish to restrict the set of GSS-API mechanisms it will 379 accept requests from. When using SPNEGO [RFC4178] with GSS-API pre- 380 authentication, the client should take care not to select a mechanism 381 with weaker security properties than a different non-GSS-API pre- 382 authentication type that could have been used. 384 If mutual_state is false after GSS_Init_sec_context() completes, the 385 client MUST ensure that the KDC was authenticated by some other 386 means. 388 10. IANA Considerations 390 Assign PA-GSS value in Pre-authentication and Typed Data, Kerberos 391 Parameters registry (preference for 633). 393 The ad-type number 633 (TBD) is assigned for AD-GSS-COMPOSITE-NAME, 394 updating the table in Section 7.5.4 of [RFC4120]. 396 11. Normative References 398 [MS-SPNG] "Simple and Protected GSS-API Negotiation Mechanism 399 (SPNEGO) Extension", . 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, 405 DOI 10.17487/RFC2119, March 1997, 406 . 408 [RFC2743] Linn, J., "Generic Security Service Application Program 409 Interface Version 2, Update 1", RFC 2743, 410 DOI 10.17487/RFC2743, January 2000, 411 . 413 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 414 Kerberos Network Authentication Service (V5)", RFC 4120, 415 DOI 10.17487/RFC4120, July 2005, 416 . 418 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 419 Simple and Protected Generic Security Service Application 420 Program Interface (GSS-API) Negotiation Mechanism", 421 RFC 4178, DOI 10.17487/RFC4178, October 2005, 422 . 424 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 425 Extension for the Generic Security Service Application 426 Program Interface (GSS-API)", RFC 4401, 427 DOI 10.17487/RFC4401, February 2006, 428 . 430 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 431 Authentication in Kerberos (PKINIT)", RFC 4556, 432 DOI 10.17487/RFC4556, June 2006, 433 . 435 [RFC6111] Zhu, L., "Additional Kerberos Naming Constraints", 436 RFC 6111, DOI 10.17487/RFC6111, April 2011, 437 . 439 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 440 Kerberos Pre-Authentication", RFC 6113, 441 DOI 10.17487/RFC6113, April 2011, 442 . 444 [RFC6680] Williams, N., Johansson, L., Hartman, S., and S. 445 Josefsson, "Generic Security Service Application 446 Programming Interface (GSS-API) Naming Extensions", 447 RFC 6680, DOI 10.17487/RFC6680, August 2012, 448 . 450 [RFC6806] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos 451 Principal Name Canonicalization and Cross-Realm 452 Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012, 453 . 455 [RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for 456 the Extensible Authentication Protocol", RFC 7055, 457 DOI 10.17487/RFC7055, December 2013, 458 . 460 [RFC8062] Zhu, L., Leach, P., Hartman, S., and S. Emery, Ed., 461 "Anonymity Support for Kerberos", RFC 8062, 462 DOI 10.17487/RFC8062, February 2017, 463 . 465 Authors' Addresses 467 Alejandro Perez-Mendez 468 Jisc 469 4 Portwall Lane 470 Bristol 471 BS1 6NB 472 United Kingdom 474 Email: alex.perez-mendez@jisc.ac.uk 476 Rafa Marin-Lopez 477 University of Murcia 478 Campus de Espinardo S/N, Faculty of Computer Science 479 30100 Murcia Murcia 480 Spain 481 Phone: +34 868 88 85 01 482 Email: rafa@um.es 484 Fernando Pereniguez-Garcia 485 University Defense Center 486 Spanish Air Force Academy 487 30720 San Javier Murcia 488 Spain 490 Phone: +34 968 18 99 46 491 Email: fernando.pereniguez@cud.upct.es 493 Gabriel Lopez-Millan 494 University of Murcia 495 Campus de Espinardo S/N, Faculty of Computer Science 496 30100 Murcia Murcia 497 Spain 499 Phone: +34 868 88 85 04 500 Email: gabilm@um.es 502 Luke Howard-Bentata 503 PADL Software Pty Ltd 504 PO Box 59 505 Central Park Victoria 3145 506 Australia 508 Email: lukeh@padl.com