idnits 2.17.00 (12 Aug 2021) /tmp/idnits25470/draft-gss-preauth-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 3, 2011) is 4036 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-krb-wg-preauth-framework has been published as RFC 6113 Summary: 0 errors (**), 0 flaws (~~), 3 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 R. Marin-Lopez 4 Intended status: Experimental F. Pereniguez-Garcia 5 Expires: November 4, 2011 G. Lopez-Millan 6 University of Murcia 7 May 3, 2011 9 GSS-API pre-authentication for Kerberos 10 draft-gss-preauth-00 12 Abstract 14 This document describes a pre-authentication mechanism for Kerberos 15 based on the Generic Security Service Application Program Interface 16 (GSS-API), which allows a Key Distribution Center (KDC) to 17 authenticate clients by using any GSS mechanism. 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 http://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 November 4, 2011. 36 Copyright Notice 38 Copyright (c) 2011 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 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 55 2. Definition of the Kerberos GSS padata . . . . . . . . . . . . . 4 56 3. GSS Pre-authentication Operation . . . . . . . . . . . . . . . 4 57 3.1. Generation of GSS preauth requests . . . . . . . . . . . . 4 58 3.2. Processing of GSS preauth requests . . . . . . . . . . . . 5 59 3.3. Generation of GSS preauth responses . . . . . . . . . . . . 5 60 3.4. Processing of GSS preauth responses . . . . . . . . . . . . 6 61 4. Data in the KDC_ERR_PREAUTH_REQUIRED . . . . . . . . . . . . . 6 62 5. Supported pre-authentication facilities . . . . . . . . . . . . 7 63 6. Managing states for the KDC . . . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 9. Normative References . . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 The GSS-API (Generic Security Service Application Programming 72 Interface) [RFC2743] provides a generic toolset of functions that 73 allow applications to establish security contexts in order to protect 74 their communications through security services such as 75 authentication, confidentiality and integrity protection. Thatks to 76 the GSS-API, applications remain independent from the specific 77 underlying mechanism used to establish the context and provide 78 security. 80 Kerberos [RFC4120] defines a process called pre-authentication. This 81 feature is intended to avoid the security risk of providing tickets 82 encrypted with the user's long-term key to attackers. The execution 83 of a pre-authentication mechanism may require the exchange of several 84 KRB_AS_REQ/KRB_ERROR messages before the KDC delivers the TGT 85 requested by the client within a KRB_AS_REP. These messages 86 transport authentication information by means of pre-authentication 87 elements. 89 There exists a variety of pre-authentication mechanisms, like PKINIT 90 [RFC4556] and encrypted time-stamp [RFC4120]. Furthermore, 91 [I-D.ietf-krb-wg-preauth-framework] provides a generic framework for 92 Kerberos pre-authentication, which aims to describe the features that 93 a pre-authentication mechanism may provide (e.g. mutual 94 authentication, replace reply key, etc.). Additionally, in order to 95 simplify the definition of new pre-authentication mechanisms, it 96 defines a mechanism called FAST (Flexible Authentication Secure 97 Tunneling), which provides a generic and secure transport for pre- 98 authentication elements. More specifically, FAST establishes a 99 secure tunnel providing confidentiality and integrity protection 100 between the client and the KDC prior to the exchange of any specific 101 pre-authentication data. Within this tunnel, different pre- 102 authentication methods can be executed. This inner mechanism is 103 called a FAST factor. It is important to note that FAST factors 104 cannot usually be used outside the FAST pre-authentication method 105 since they assume the underlying security layer provided by FAST. 107 The aim of this draft is to define a new pre-authentication 108 mechanism, following the recommendations of 109 [I-D.ietf-krb-wg-preauth-framework], that relies on the GSS-API 110 security services to pre-authenticate clients. This pre- 111 authentication mechanism will allow the KDC to authenticate clients 112 making use of any current or future GSS mechanism, as long as they 113 satisfy the minimum security requirements described in this 114 specification. The Kerberos client will play the role of the GSS 115 initiator, while the Authentication Server (AS) in the KDC will play 116 the role of the GSS acceptor. 118 1.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2. Definition of the Kerberos GSS padata 126 To establish the security context, the GSS-API defines the exchange 127 of GSS tokens between the initiator and the acceptor. These tokens, 128 which contain mechanism-specific information, are completely opaque 129 to the application. However, how these tokens are transported 130 between the initiator and the responder depends on the specific 131 application. Since GSS-API is defined as independent of the 132 underlying communications service, its use does not require to 133 implement any specific security feature for the transport. For 134 instance, tokens could just be sent by means of plain UDP datagrams. 135 For this reason, security and ordered delivery of information must be 136 implemented by each specific GSS mechanism (if required). 138 Therefore, GSS tokens are the atomic piece of information from the 139 application point of view when using GSS-API, which require a proper 140 transport between the initiator (Kerberos client) and the acceptor 141 (AS). In particular, the proposed GSS-based pre-authentication 142 mechanism defines a new pre-authentication element (hereafter padata) 143 called PA-GSS-TOKEN to transport a generic GSS token from the 144 Kerberos client to the AS and vice-versa. The ASN.1 specification 145 for this padata is: 147 PA-GSS-TOKEN To be defined (TBD) 149 PA-GSS-TOKEN ::= OCTECT STRING --value of the GSS token 151 3. GSS Pre-authentication Operation 153 3.1. Generation of GSS preauth requests 155 The Kerberos client (initiator) starts by calling to the 156 GSS_Init_sec_context function. In the first call to this function, 157 the client provides GSS_C_NO_CTX as the value of the context_handle 158 and NULL as the input_token, given that no context has been initiated 159 yet. When using multi round-trip GSS mechanisms, in subsequent calls 160 to this routine the client will use both, the context_handle value 161 obtained after the first call, and the input_token received from the 162 KDC. 164 The GSS_Init_sec_context returns a context_handle, an output_token 165 and a status value. If the obtained status is GSS_S_COMPLETE, the 166 generated token contains the neccesary information to establish the 167 context and, therefore, no further tokens are expected from the KDC 168 to complete the authentication process. On the contrary, if the 169 obtained status is GSS_S_CONTINUE_NEEDED, the KDC is expected to 170 provide a token in order to continue with the context establishment 171 process. In both cases, the Kerberos client includes the obtained 172 output_token into a new PA-GSS-TOKEN padata and sends it to the KDC 173 through a KRB_AS_REQ message. 175 3.2. Processing of GSS preauth requests 177 When the KDC (GSS acceptor) receives a KRB_AS_REQ message containing 178 a PA-GSS-TOKEN, but a PA-FX-COOKIE (see Section 6) is not included, 179 the KDC assumes that this is the first message of a context 180 establishment, and thus GSS_C_NO_CTX is used as context_handle to 181 invoke the GSS_Accept_sec_context routine. Conversely, if a PA-FX- 182 COOKIE is included, the KDC assumes that this message is part an 183 ongoing authentication and the value of the PA-FX-COOKIE is used as 184 the context_handle value. In both cases, after receiving the 185 message, the KDC calls to the GSS_Accept_sec_context function, using 186 the adequate context_handle value and using the received token in the 187 PA-GSS-TOKEN padata as input_token. 189 Once the execution of the GSS_Accept_sec_context function is 190 completed, the KDC obtains a context_handle, an output_token 191 (optional) that MUST be sent to the initiator in order to continue 192 with the authentication process, and a status value. If the obtained 193 status is GSS_S_COMPLETE, the client is considered authenticated and 194 the value of the output_token may be NULL. If the status is 195 GSS_S_CONTINUE_NEEDED, further information is required to complete 196 the process. 198 3.3. Generation of GSS preauth responses 200 Once the KDC has processed the input_token provided by the client (as 201 described in Section 3.2, two main different situations may occur 202 depending on the status value. If the client is successfully 203 authenticated (GSS_S_COMPLETE), the KDC will reply to the client with 204 a KRB_AS_REP message. This message will transport the final 205 output_token (if generated) in a PA-GSS-TOKEN padata type. 206 Additionally, there are three alternatives to encrypt the enc-part 207 field of the KRB_AS_REP message. The first one is to make use of the 208 client's password as described in the standard Kerberos. A second 209 option is to strengthen this key by using keying material from the 210 GSS context (more details are provide in Section 5). The final 211 option is to employ a key cryptographically independent from the 212 user's password which could be generated by using the keying material 213 from the GSS context. Section 5 provides further details regarding 214 these two last options. 216 On the contrary, if further data is required to complete the 217 establishment process (GSS_S_CONTINUE_NEEDED), the KDC will reply to 218 the client with a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error message 219 [I-D.ietf-krb-wg-preauth-framework]. In the e-data field of the 220 message, the KDC will include two padata types: a PA-FX-COOKIE 221 containing the context_handle of this context (Section 6), and a PA- 222 GSS-TOKEN containing the obtained output_token. 224 3.4. Processing of GSS preauth responses 226 When the client receives a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error, 227 it extracts the token from the PA-GSS-TOKEN element and invokes to 228 the GSS_Init_sec_context function, as described in section 229 Section 3.1. The received PA-FX-COOKIE is treated as an opaque 230 element, which is simply copied and included into the following 231 KRB_AS_REQ message without further processing. 233 On the other hand, when the client receives a KRB_AS_REP, the context 234 establishment has finalized successfully. If the KRB_AS_REP message 235 contains a PA-GSS-TOKEN padata type, the client invokes the 236 GSS_Init_sec_context function using the transported input_token. 237 Note that, to be consistent, this call MUST return GSS_S_COMPLETE and 238 not generate any output_token, since the KDC does not expect further 239 data from the client. Similarly, if the client does not expect any 240 data from the KDC (it obtained a GSS_S_COMPLETE status value on the 241 last call) and the KDC provides an input_token, an unexpected 242 situation occurrs and the context establishment must be aborted. 244 If the context establishment is completed correctly, the client must 245 use the same process followed by the KDC (Section 3.3). 247 4. Data in the KDC_ERR_PREAUTH_REQUIRED 249 When the KDC sends a KDC_ERR_PREAUTH_REQUIRED error to the client, it 250 includes a sequence of padata, each corresponding to an acceptable 251 pre-authentication method. Optionally, these padatas contain data 252 valuable for the client to configure the selected mechanism. The 253 data to be included in the padata for this message is described in 254 this section. 256 TBD. (For example, list of the OIDs of the GSS mechanisms supported 257 by the KDC) 259 5. Supported pre-authentication facilities 261 The pre-authentication framework [I-D.ietf-krb-wg-preauth-framework] 262 defines a set of facilities that the pre-authentication mechanisms 263 may provide. Specifically, the GSS pre-authentication mechanism 264 proposed in this draft may provide the following facilities: 266 o Client-authentication facility. The GSS pre-authentication 267 mechanism authenticates the client based on GSS-API calls. At the 268 end of the GSS context establishment process, the client is 269 authenticated against the KDC by means of the specific GSS 270 mechanism credentials. 272 o Strengthening-reply-key facility. After a successful 273 authentication, client and KDC may strengthen the reply key (the 274 key used to encrypt the enc-part field of the KRB_AS_REP message) 275 by adding additional keying material to it. This additional 276 keying material can be obtained by means of calls to the 277 GSS_Pseudo_random [RFC4401] function, although the standard 278 GSS_getMIC function could be used if the former is not available 279 for the specific GSS mechanism. 281 o Replacing-reply-key facility. Similarly to the strengthening 282 facility, client and KDC may decide to completely replace the 283 reply key used to encrypt the KRB_AS_REP by a new one that is 284 cryptographically independent from the client's password stored in 285 client password on the Kerberos users database. To generate this 286 keying material, the same GSS-API functions used for the previous 287 facility would be used. 289 o KDC-authentication facility. This facility is also provided, as 290 an optional feature, since the GSS-API allows the initiator of the 291 security context to request mutual authentication during the 292 establishment process. If the mutual_req_flag is indicated in the 293 GSS_Init_sec_context call, the acceptor (KDC) must be 294 authenticated by the initiator (client) before the context is 295 established. 297 The selection of the facilities that the GSS pre-authentication 298 mechanism will provide, and how will they be negotiated with the 299 client is still under discussion. 301 6. Managing states for the KDC 303 The Kerberos standard [RFC4120] defines the KDC as a stateless 304 entity. This means that, if the GSS mechanism requires more than one 305 round-trip, the client must provide enough data to the KDC in the 306 following interactions to allow recovering the complete state of the 307 ongoing authentication. This is specially relevant when the client 308 switches from one KDC to different one (within the same realm) during 309 a pre-authentication process. This second KDC must be able to 310 continue with the process in a seamless way. In 311 [I-D.ietf-krb-wg-preauth-framework], the PA-FX-COOKIE pre- 312 authentication element is defined to transport opaque state 313 information from the KDC to the client. This state information is 314 included by the client in the following KRB_AS_REQ message as-is, 315 without further processing. When the KDC receives the PA-FX-COOKIE 316 padata, it tries to recover the state and, if successful, continue 317 with the authentication process. 319 PA-FX-COOKIE 133 321 The GSS-API manages the so-called security contexts. They represent 322 the whole context of an authentication, including all the state and 323 relevant data of the ongoing security context. Every GSS-API 324 function requires an input parameter (called context_handle) which 325 identifies the specific context over which they are applied. The 326 application obtains a value for this context_handle after the first 327 call to the GSS_Init_sec_context function (when acting as GSS 328 initiator) or GSS_Accept_sec_context function (when acting as GSS 329 acceptor), which is used in subsequent calls regarding this security 330 context. Hence, it seems reasonable that this is the value that must 331 be transported in the PA-FX-COOKIE padata type as it allows the KDC 332 to recover the complete state of an ongoing context establishment 333 proccess. 335 7. Security Considerations 337 Protection of Request/Responses with FAST, restriction on GSS 338 mechanism, etc. TBD. 340 8. IANA Considerations 342 This document has no actions for IANA. 344 9. Normative References 346 [I-D.ietf-krb-wg-preauth-framework] 347 Hartman, S. and L. Zhu, "A Generalized Framework for 348 Kerberos Pre-Authentication", 349 draft-ietf-krb-wg-preauth-framework-17 (work in progress), 350 June 2010. 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC2743] Linn, J., "Generic Security Service Application Program 356 Interface Version 2, Update 1", RFC 2743, January 2000. 358 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 359 Kerberos Network Authentication Service (V5)", RFC 4120, 360 July 2005. 362 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 363 Extension for the Generic Security Service Application 364 Program Interface (GSS-API)", RFC 4401, February 2006. 366 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 367 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 369 Authors' Addresses 371 Alejandro Perez-Mendez (Ed.) 372 University of Murcia 373 Campus de Espinardo S/N, Faculty of Computer Science 374 Murcia, 30100 375 Spain 377 Phone: +34 868 88 46 44 378 Email: alex@um.es 380 Rafa Marin-Lopez 381 University of Murcia 382 Campus de Espinardo S/N, Faculty of Computer Science 383 Murcia, 30100 384 Spain 386 Phone: +34 868 88 85 01 387 Email: rafa@um.es 388 Fernando Pereniguez-Garcia 389 University of Murcia 390 Campus de Espinardo S/N, Faculty of Computer Science 391 Murcia, 30100 392 Spain 394 Phone: +34 868 88 78 82 395 Email: pereniguez@um.es 397 Gabriel Lopez-Millan 398 University of Murcia 399 Campus de Espinardo S/N, Faculty of Computer Science 400 Murcia, 30100 401 Spain 403 Phone: +34 868 88 85 04 404 Email: gabilm@um.es