diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-perez-krb-wg-gss-preauth-03.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/draft-perez-krb-wg-gss-preauth-03.txt | 616 |
1 files changed, 616 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-perez-krb-wg-gss-preauth-03.txt b/third_party/heimdal/doc/standardisation/draft-perez-krb-wg-gss-preauth-03.txt new file mode 100644 index 00000000000..e4c07b1db79 --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-perez-krb-wg-gss-preauth-03.txt @@ -0,0 +1,616 @@ + + + + +Kerberos Working Group A. Perez-Mendez +Internet-Draft Jisc +Intended status: Experimental R. Marin-Lopez +Expires: 27 March 2022 University of Murcia + F. Pereniguez-Garcia + University Defense Center + G. Lopez-Millan + University of Murcia + L. Howard-Bentata + PADL Software Pty Ltd + September 2021 + + + GSS-API pre-authentication for Kerberos + draft-perez-krb-wg-gss-preauth-03 + +Abstract + + This document describes a pre-authentication mechanism for Kerberos + based on the Generic Security Service Application Program Interface + (GSS-API), which allows a Key Distribution Center (KDC) to + authenticate clients by using a GSS mechanism. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on 5 March 2022. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + + + +Perez-Mendez, et al. Expires 27 March 2022 [Page 1] + +Internet-Draft GSS-API pre-auth September 2021 + + + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Simplified BSD License text + as described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Cookie Support . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. More Pre-Authentication Data Required . . . . . . . . . . 3 + 2.3. Support for Exporting Partially Established Contexts . . 4 + 2.4. Processing of Channel Bindings in Single Round-Trip . . . 4 + 3. Definition of the GSS padata . . . . . . . . . . . . . . . . 4 + 4. GSS-API Pre-authentication Operation . . . . . . . . . . . . 4 + 4.1. Kerberos client (GSS-API initiator) . . . . . . . . . . . 4 + 4.2. KDC (GSS-API acceptor) . . . . . . . . . . . . . . . . . 5 + 5. Indication of Supported Mechanisms . . . . . . . . . . . . . 6 + 6. Reply Key Derivation . . . . . . . . . . . . . . . . . . . . 7 + 7. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 8. Anonymous Authentication . . . . . . . . . . . . . . . . . . 8 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 + +1. Introduction + + The Generic Security Service Application Programming Interface (GSS- + API) [RFC2743] provides a framework for authentication and message + protection services through a common programming interface, allowing + applications to remain agnostic from the selected mechanism. + + Kerberos [RFC4120] is an authentication service based on the Needham- + Schroeder symmetric key protocol. It includes a facility called pre- + authentication designed to ensure clients prove knowledge of their + long-term key before the Key Distribution Center (KDC) issues a + ticket. Typical pre-authentication mechanisms include encrypted + timestamp [RFC4120] and public key certificates [RFC4556]. Pre- + authentication data in these messages provides a typed hole for + exchanging information used to authenticate the client. + + [RFC6113] specifies a framework for pre-authentication in Kerberos, + describing the features such a pre-authentication mechanism may + provide such as authenticating the client and/or KDC and + strengthening or replacing the reply key in the AS-REP. FAST + + + +Perez-Mendez, et al. Expires 27 March 2022 [Page 2] + +Internet-Draft GSS-API pre-auth September 2021 + + + (Flexible Authentication Secure Tunneling) provides a generic and + secure transport for pre-authentication elements prior to the + exchange of any pre-authentication data. The inner pre- + authentication mechanism is called a FAST factor. FAST factors can + generally not be used outside FAST as they assume the underlying + security layer provided by FAST. + + This document defines a new pre-authentication method that relies on + GSS-API security services to pre-authenticate Kerberos clients. This + method allows the KDC to authenticate clients using any current or + future GSS-API mechanism, as long as they satisfy the minimum + security requirements described in this specification. The Kerberos + client assumes the role of the GSS-API initiator, and the + Authentication Service (AS) the role of the GSS-API acceptor. It may + be used as a FAST factor or without FAST. + + This work was originally motivated by the desire to allow Kerberos to + use the protocols defined in [RFC7055] to authenticate federated + users with EAP. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Prerequisites + +2.1. Cookie Support + + KDCs which support GSS-API pre-authentication with mechanisms that + require more than one round-trip to establish a security context MUST + have a secure mechanism for retaining state between AS-REQs. For + stateless KDC implementations, this will typically be a digest of the + initial KDC-REQ-BODY concatenated with a GSS_Export_sec_context() + token, encrypted in a key known only to the KDC and protected from + replay attacks (see Section 5.2 of [RFC6113]). The format of the PA- + FX-COOKIE is implementation defined. + + Clients that support GSS-API pre-authentication with mechanisms that + require more than one round-trip MUST echo the received PA-FX-COOKIE + in the next AS-REQ (within a given conversation). + +2.2. More Pre-Authentication Data Required + + Both KDCs and clients which implement GSS-API pre-authentication MUST + support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as decribed in + Section 5.2 of [RFC6113]. + + + +Perez-Mendez, et al. Expires 27 March 2022 [Page 3] + +Internet-Draft GSS-API pre-auth September 2021 + + +2.3. Support for Exporting Partially Established Contexts + + KDC implementations that use exported context tokens to maintain + state will call GSS_Export_sec_context() and GSS_Import_sec_context() + on partially established acceptor contexts. This may require + modifications to the mechanism implementation, as [RFC2743] only + requires these functions succeed on fully established contexts. + +2.4. Processing of Channel Bindings in Single Round-Trip + + The client's KDC request is bound to the GSS-API context + establishment through the use of channel bindings. GSS-API + mechanisms that require more than one round-trip do not expose at + which point in the exchange the channel bindings are validated, and + assume they are constant for all context establishment calls. In + this specification, the channel bindings contain the encoded client + request body, which may vary for each round-trip if a fresh nonce is + used on each request. + + To accommodate this, and to avoid re-encoding the request body + without the nonce, this specification imposes the additional + requirement that the GSS-API mechanism processes channel bindings in + a single round-trip within the pre-authentication conversation. + +3. Definition of the GSS padata + + The GSS-API defines an exchange of opaque tokens between the + initiator (client) and acceptor (service) in order to authenticate + each party. GSS-API does not define the transport over which these + tokens are carried. This specification defines a Kerberos pre- + authentication type, PA-GSS, which carries a GSS-API context token + from the Kerberos client to the AS and vice versa. + + PA-GSS 633 + -- output_token from GSS_Init_sec_context() + -- or GSS_Accept_sec_context() + +4. GSS-API Pre-authentication Operation + +4.1. Kerberos client (GSS-API initiator) + + The Kerberos client begins by calling GSS_Init_sec_context() with the + desired credential handle and the target name of the TGS, including + the instance and realm. If the underlying mechanism supports + Kerberos names, the TGS name MUST be imported as a + GSS_KRB5_NT_PRINCIPAL_NAME; otherwise, it SHALL be imported as a + GSS_C_NT_HOSTBASED_SERVICE with "krbtgt" as the "service" element and + the TGS realm as the "hostname" element (see [RFC2743] Section 4.1). + + + +Perez-Mendez, et al. Expires 27 March 2022 [Page 4] + +Internet-Draft GSS-API pre-auth September 2021 + + + In the first call to GSS_Init_sec_context(), input_context_handle is + GSS_C_NO_CONTEXT and input_token is empty. In subsequent calls the + client uses the context_handle value obtained after the first call, + and the input_token received from the KDC. The mutual_req_flag MUST + be set. + + In order to bind the GSS-API and Kerberos message exchanges, the DER- + encoded KDC-REQ-BODY from the AS-REQ is passed as channel binding + application data. As the nonce may differ between requests (see + [RFC6113] Section 5.4.3), this requires the GSS-API mechanism to + process the channel binding information in a single round-trip. To + avoid this potential interoperability issue, clients MAY use a single + nonce for all messages in a conversation once GSS-API pre- + authentication has commenced. + + If GSS_Init_sec_context() returns GSS_S_CONTINUE_NEEDED, the + output_token is sent to the KDC in the PA-GSS pre-authentication data + and the client expects either a KRB-ERROR containing another context + token, or an AS-REP optionally containing a final context token. + + Once GSS_Init_sec_context() returns GSS_S_COMPLETE, the context is + ready for use. The AS-REP is decrypted using the reply key (see + Section 6) and the Kerberos client name MAY be replaced by the AS-REP + cname (see Section 7). The client MUST fail if the mutual_state flag + is not set when fully established, unless the KDC was authenticated + by some other means such as a FAST armor. + + The response received from the KDC must agree with the expected + status from GSS_Init_sec_context(). It is a state violation to + receive an AS-REP from the KDC when the initiator still has + additional tokens to send to the KDC (GSS_S_CONTINUE_NEEDED), or + conversely to receive KDC_ERR_MORE_PREAUTH_DATA_REQUIRED if the + context from the initiator's perspective was already open + (GSS_S_COMPLETE). + + When receiving a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error from the + KDC, an PA-FX-COOKIE from the KDC MUST be present and copied into the + subsequent AS-REQ. + +4.2. KDC (GSS-API acceptor) + + When the KDC receives an AS-REQ message containing PA-GSS pre- + authentication data, it first looks for an PA-FX-COOKIE and if + present retrieves the context handle associated with the cookie, + typically by passing the context token from the decrypted cookie to + GSS_Import_sec_context(). The absence of an PA-FX-COOKIE indicates a + new conversation and the client sending an initial context token. + + + + +Perez-Mendez, et al. Expires 27 March 2022 [Page 5] + +Internet-Draft GSS-API pre-auth September 2021 + + + The KDC SHALL associate the KDC-REQ-BODY of the initial request with + the pre-authentication conversation. On subsequent requests, the KDC + MUST abort the conversation and return an error if the KDC-REQ-BODY + differs from the initial request. The nonce is excluded from this + comparison. This extends the protection afforded by the channel + binding to all requests in the conversation, not just the request + where the mechanism validated the channel bindings. (No specific + implementation is required, but one approach would be for the KDC to + include a digest of the KDC-REQ-BODY with the nonce set to zero in + the PA-FX-COOKIE contents.) + + If no PA-GSS pre-authentication data is present, the KDC cannot + continue with GSS-API pre-authentication and will continue with other + pre-authentication methods or return an error as determined by local + policy. If PA-GSS pre-authentication data is present but empty, the + KDC SHALL return a KDC_ERR_PREAUTH_FAILED error. Otherwise, + GSS_Accept_sec_context() is called with the acceptor credential + handle, the token provided in the PA-GSS pre-authentication data, and + channel binding application data containing the DER-encoded KDC-REQ- + BODY. + + If GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED, the KDC + returns a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error with the output + token included as PA-GSS pre-authentication data. The acceptor state + is encoded, typically by calling GSS_Export_sec_context(), and the + encrypted result is placed in an PA-FX-COOKIE. + + If GSS_Accept_sec_context() returns GSS_S_COMPLETE, the context is + ready for use and an AS-REP is returned using the reply key specified + in Section 6. Otherwise, an appropriate error such as + KDC_ERR_PREAUTH_FAILED is returned to the client and the conversation + is aborted. If the mechanism emitted an error token on failure, it + SHOULD be returned to the client. + + If the GSS-API mechanism requires an odd number of messages to + establish a security context, the KDC MUST include an empty GSS-PA + pre-authentication data in the last message of a successful + conversation. + +5. Indication of Supported Mechanisms + + When the KDC sends a KDC_ERR_PREAUTH_REQUIRED error to the client, it + MAY include a pre-authentication data element indicating the set of + supported mechanisms. The pre-authentication data comprises of a + SPNEGO server initiated initial context token as defined in [MS-SPNG] + 3.2.5.2, containing the list of mechanisms supported by the acceptor. + Context state is discarded and as such the first PA-GSS from the + client is always an InitialContextToken ([RFC2743] Section 3.1). + + + +Perez-Mendez, et al. Expires 27 March 2022 [Page 6] + +Internet-Draft GSS-API pre-auth September 2021 + + +6. Reply Key Derivation + + The GSS-API pre-authentication mechanism proposed in this draft + provides the Replace Reply Key facility [RFC6113]. + + After authentication is complete, the client and KDC replace the AS- + REP reply key with the output of calling GSS_Pseudo_random() + [RFC4401] with the following parameters: + + context The initiator or acceptor context handle + + prf_key GSS_C_PRF_KEY_FULL + + prf_in KRB-GSS || 0x00 || AS-REQ nonce + + desired_output_len The length in bytes of original reply key + + The nonce is the nonce of the final AS-REQ in the conversation, and + is encoded as the little-endian binary representation of 4 bytes. + The new reply key has the same key type as the original key. If FAST + is used, the new reply key SHOULD be strengthened by including a + strengthen key in the KrbFastResponse. + +7. Naming + + This specification permits Kerberos clients to authenticate without + knowing how the KDC will map their GSS-API initiator name to a + Kerberos principal. In such cases the client SHALL set the value of + the cname field in the AS-REQ to the well-known [RFC6111] value + WELLKNOWN/FEDERATED, replacing it after a successful conversation + with the client name returned in the AS-REP. + + When the initiator knows the Kerberos client name it wishes to + authenticate as, and the mechanism supports Kerberos names, the name + MUST be imported using the GSS_KRB5_NT_PRINCIPAL_NAME name type. + Otherwise, GSS_C_NT_USER_NAME SHOULD be used when importing NT- + PRINCIPAL names in the local realm, or NT-ENTERPRISE [RFC6806] names. + GSS_C_NT_HOSTBASED_SERVICE SHOULD be used when importing NT-SRV-HOST + or NT-SRV-INST names with a single instance. + + This specification does not mandate a specific mapping of GSS-API + initiator names to Kerberos principal names. KDCs MAY use the NT- + ENTERPRISE principal name type to avoid conflating any domain- or + realm-like components of initiator names with Kerberos realms. + + The KDC MAY include an AD-GSS-COMPOSITE-NAME authorization data + element, containing name attribute information. Its value is the + exp_composite_name octet string resulting from a successful call to + + + +Perez-Mendez, et al. Expires 27 March 2022 [Page 7] + +Internet-Draft GSS-API pre-auth September 2021 + + + GSS_Export_name_composite() [RFC6680]. It SHOULD be enclosed in a + AD-IF-RELEVANT container. The format of composite name tokens is + implementation dependent; services that cannot parse the name token + MUST fail if the authorization data element was not enclosed in AD- + IF-RELEVANT. + +8. Anonymous Authentication + + If the client wishes to authenticate anonymously using GSS-API pre- + authentication, it MUST specify both the request-anonymous flag in + the AS-REQ and anon_req_flag in the call to GSS_Init_sec_context(). + If GSS_Accept_sec_context() set anon_state and returned an initiator + name of type GSS_C_NT_ANONYMOUS, the KDC MUST map the user to the + well-known anonymous PKINIT principal and realm defined in [RFC8062]. + + If GSS_Accept_sec_context() set anon_state but did not return an + initiator name of type GSS_C_NT_ANONYMOUS, then the KDC MUST return + the well-known anonymous principal but it MAY include the realm of + the initiator. + +9. Security Considerations + + The client SHOULD use FAST armor to protect the pre-authentication + conversation. + + The KDC MUST maintain confidentiality and integrity of the PA-FX- + COOKIE contents, typically by encrypting it using a key known only to + itself. Cookie values SHOULD be protected from replay attacks by + limiting their validity period and binding their contents to the + client name in the AS-REQ. + + The establishment of a GSS-API security context is bound to the + client's AS-REQ through the inclusion of the encoded KDC-REQ-BODY as + channel bindings (see Section 4.1), and the nonce as input to the key + derivation function (see Section 6). By asserting the KDC-REQ-BODY + does not change during the conversation (nonce notwithstanding), the + channel bindings protect all request bodies in the conversation. + + The KDC MAY wish to restrict the set of GSS-API mechanisms it will + accept requests from. When using SPNEGO [RFC4178] with GSS-API pre- + authentication, the client should take care not to select a mechanism + with weaker security properties than a different non-GSS-API pre- + authentication type that could have been used. + + If mutual_state is false after GSS_Init_sec_context() completes, the + client MUST ensure that the KDC was authenticated by some other + means. + + + + +Perez-Mendez, et al. Expires 27 March 2022 [Page 8] + +Internet-Draft GSS-API pre-auth September 2021 + + +10. IANA Considerations + + Assign PA-GSS value in Pre-authentication and Typed Data, Kerberos + Parameters registry (preference for 633). + + The ad-type number 633 (TBD) is assigned for AD-GSS-COMPOSITE-NAME, + updating the table in Section 7.5.4 of [RFC4120]. + +11. Normative References + + [MS-SPNG] "Simple and Protected GSS-API Negotiation Mechanism + (SPNEGO) Extension", <https://docs.microsoft.com/en- + us/openspecs/windows_protocols/ms-spng/f377a379-c24f-4a0f- + a3eb-0d835389e28a>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2743] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, + DOI 10.17487/RFC2743, January 2000, + <https://www.rfc-editor.org/info/rfc2743>. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + DOI 10.17487/RFC4120, July 2005, + <https://www.rfc-editor.org/info/rfc4120>. + + [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The + Simple and Protected Generic Security Service Application + Program Interface (GSS-API) Negotiation Mechanism", + RFC 4178, DOI 10.17487/RFC4178, October 2005, + <https://www.rfc-editor.org/info/rfc4178>. + + [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API + Extension for the Generic Security Service Application + Program Interface (GSS-API)", RFC 4401, + DOI 10.17487/RFC4401, February 2006, + <https://www.rfc-editor.org/info/rfc4401>. + + [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial + Authentication in Kerberos (PKINIT)", RFC 4556, + DOI 10.17487/RFC4556, June 2006, + <https://www.rfc-editor.org/info/rfc4556>. + + + + + +Perez-Mendez, et al. Expires 27 March 2022 [Page 9] + +Internet-Draft GSS-API pre-auth September 2021 + + + [RFC6111] Zhu, L., "Additional Kerberos Naming Constraints", + RFC 6111, DOI 10.17487/RFC6111, April 2011, + <https://www.rfc-editor.org/info/rfc6111>. + + [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for + Kerberos Pre-Authentication", RFC 6113, + DOI 10.17487/RFC6113, April 2011, + <https://www.rfc-editor.org/info/rfc6113>. + + [RFC6680] Williams, N., Johansson, L., Hartman, S., and S. + Josefsson, "Generic Security Service Application + Programming Interface (GSS-API) Naming Extensions", + RFC 6680, DOI 10.17487/RFC6680, August 2012, + <https://www.rfc-editor.org/info/rfc6680>. + + [RFC6806] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos + Principal Name Canonicalization and Cross-Realm + Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012, + <https://www.rfc-editor.org/info/rfc6806>. + + [RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for + the Extensible Authentication Protocol", RFC 7055, + DOI 10.17487/RFC7055, December 2013, + <https://www.rfc-editor.org/info/rfc7055>. + + [RFC8062] Zhu, L., Leach, P., Hartman, S., and S. Emery, Ed., + "Anonymity Support for Kerberos", RFC 8062, + DOI 10.17487/RFC8062, February 2017, + <https://www.rfc-editor.org/info/rfc8062>. + +Authors' Addresses + + Alejandro Perez-Mendez + Jisc + 4 Portwall Lane + Bristol + BS1 6NB + United Kingdom + + Email: alex.perez-mendez@jisc.ac.uk + + + Rafa Marin-Lopez + University of Murcia + Campus de Espinardo S/N, Faculty of Computer Science + 30100 Murcia Murcia + Spain + + + + +Perez-Mendez, et al. Expires 27 March 2022 [Page 10] + +Internet-Draft GSS-API pre-auth September 2021 + + + Phone: +34 868 88 85 01 + Email: rafa@um.es + + + Fernando Pereniguez-Garcia + University Defense Center + Spanish Air Force Academy + 30720 San Javier Murcia + Spain + + Phone: +34 968 18 99 46 + Email: fernando.pereniguez@cud.upct.es + + + Gabriel Lopez-Millan + University of Murcia + Campus de Espinardo S/N, Faculty of Computer Science + 30100 Murcia Murcia + Spain + + Phone: +34 868 88 85 04 + Email: gabilm@um.es + + + Luke Howard-Bentata + PADL Software Pty Ltd + PO Box 59 + Central Park Victoria 3145 + Australia + + Email: lukeh@padl.com + + + + + + + + + + + + + + + + + + + + +Perez-Mendez, et al. Expires 27 March 2022 [Page 11] |