1 2 3 4 5 6 7Internet Engineering Task Force (IETF) S. Hartman 8Request for Comments: 6113 Painless Security 9Updates: 4120 L. Zhu 10Category: Standards Track Microsoft Corporation 11ISSN: 2070-1721 April 2011 12 13 14 A Generalized Framework for Kerberos Pre-Authentication 15 16Abstract 17 18 Kerberos is a protocol for verifying the identity of principals 19 (e.g., a workstation user or a network server) on an open network. 20 The Kerberos protocol provides a facility called pre-authentication. 21 Pre-authentication mechanisms can use this facility to extend the 22 Kerberos protocol and prove the identity of a principal. 23 24 This document describes a more formal model for this facility. The 25 model describes what state in the Kerberos request a pre- 26 authentication mechanism is likely to change. It also describes how 27 multiple pre-authentication mechanisms used in the same request will 28 interact. 29 30 This document also provides common tools needed by multiple pre- 31 authentication mechanisms. One of these tools is a secure channel 32 between the client and the key distribution center with a reply key 33 strengthening mechanism; this secure channel can be used to protect 34 the authentication exchange and thus eliminate offline dictionary 35 attacks. With these tools, it is relatively straightforward to chain 36 multiple authentication mechanisms, utilize a different key 37 management system, or support a new key agreement algorithm. 38 39Status of This Memo 40 41 This is an Internet Standards Track document. 42 43 This document is a product of the Internet Engineering Task Force 44 (IETF). It represents the consensus of the IETF community. It has 45 received public review and has been approved for publication by the 46 Internet Engineering Steering Group (IESG). Further information on 47 Internet Standards is available in Section 2 of RFC 5741. 48 49 Information about the current status of this document, any errata, 50 and how to provide feedback on it may be obtained at 51 http://www.rfc-editor.org/info/rfc6113. 52 53 54 55 56 57 58Hartman & Zhu Standards Track [Page 1] 59 60RFC 6113 Kerberos Preauth Framework April 2011 61 62 63Copyright Notice 64 65 Copyright (c) 2011 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 67 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114Hartman & Zhu Standards Track [Page 2] 115 116RFC 6113 Kerberos Preauth Framework April 2011 117 118 119Table of Contents 120 121 1. Introduction ....................................................4 122 1.1. Conventions and Terminology Used in This Document ..........5 123 1.2. Conformance Requirements ...................................5 124 2. Model for Pre-Authentication ....................................6 125 2.1. Information Managed by the Pre-Authentication Model ........7 126 2.2. Initial Pre-Authentication Required Error ..................9 127 2.3. Client to KDC .............................................10 128 2.4. KDC to Client .............................................11 129 3. Pre-Authentication Facilities ..................................12 130 3.1. Client Authentication Facility ............................13 131 3.2. Strengthening Reply Key Facility ..........................13 132 3.3. Replace Reply Key Facility ................................14 133 3.4. KDC Authentication Facility ...............................15 134 4. Requirements for Pre-Authentication Mechanisms .................15 135 4.1. Protecting Requests/Responses .............................16 136 5. Tools for Use in Pre-Authentication Mechanisms .................17 137 5.1. Combining Keys ............................................17 138 5.2. Managing States for the KDC ...............................19 139 5.3. Pre-Authentication Set ....................................20 140 5.4. Definition of Kerberos FAST Padata ........................23 141 5.4.1. FAST Armors ........................................24 142 5.4.2. FAST Request .......................................26 143 5.4.3. FAST Response ......................................30 144 5.4.4. Authenticated Kerberos Error Messages Using 145 Kerberos FAST ......................................33 146 5.4.5. Outer and Inner Requests ...........................34 147 5.4.6. The Encrypted Challenge FAST Factor ................34 148 5.5. Authentication Strength Indication ........................36 149 6. Assigned Constants .............................................37 150 6.1. New Errors ................................................37 151 6.2. Key Usage Numbers .........................................37 152 6.3. Authorization Data Elements ...............................37 153 6.4. New PA-DATA Types .........................................37 154 7. IANA Considerations ............................................38 155 7.1. Pre-Authentication and Typed Data .........................38 156 7.2. Fast Armor Types ..........................................40 157 7.3. FAST Options ..............................................40 158 8. Security Considerations ........................................41 159 9. Acknowledgements ...............................................42 160 10. References ....................................................43 161 10.1. Normative References .....................................43 162 10.2. Informative References ...................................43 163 Appendix A. Test Vectors for KRB-FX-CF2 ...........................45 164 Appendix B. ASN.1 Module ..........................................46 165 166 167 168 169 170Hartman & Zhu Standards Track [Page 3] 171 172RFC 6113 Kerberos Preauth Framework April 2011 173 174 1751. Introduction 176 177 The core Kerberos specification [RFC4120] treats pre-authentication 178 data (padata) as an opaque typed hole in the messages to the key 179 distribution center (KDC) that may influence the reply key used to 180 encrypt the KDC reply. This generality has been useful: pre- 181 authentication data is used for a variety of extensions to the 182 protocol, many outside the expectations of the initial designers. 183 However, this generality makes designing more common types of pre- 184 authentication mechanisms difficult. Each mechanism needs to specify 185 how it interacts with other mechanisms. Also, tasks such as 186 combining a key with the long-term secrets or proving the identity of 187 the user are common to multiple mechanisms. Where there are 188 generally well-accepted solutions to these problems, it is desirable 189 to standardize one of these solutions so mechanisms can avoid 190 duplication of work. In other cases, a modular approach to these 191 problems is appropriate. The modular approach will allow new and 192 better solutions to common pre-authentication problems to be used by 193 existing mechanisms as they are developed. 194 195 This document specifies a framework for Kerberos pre-authentication 196 mechanisms. It defines the common set of functions that pre- 197 authentication mechanisms perform as well as how these functions 198 affect the state of the request and reply. In addition, several 199 common tools needed by pre-authentication mechanisms are provided. 200 Unlike [RFC3961], this framework is not complete -- it does not 201 describe all the inputs and outputs for the pre-authentication 202 mechanisms. Pre-authentication mechanism designers should try to be 203 consistent with this framework because doing so will make their 204 mechanisms easier to implement. Kerberos implementations are likely 205 to have plug-in architectures for pre-authentication; such 206 architectures are likely to support mechanisms that follow this 207 framework plus commonly used extensions. This framework also 208 facilitates combining multiple pre-authentication mechanisms, each of 209 which may represent an authentication factor, into a single multi- 210 factor pre-authentication mechanism. 211 212 One of these common tools is the flexible authentication secure 213 tunneling (FAST) padata type. FAST provides a protected channel 214 between the client and the key distribution center (KDC), and it can 215 optionally deliver key material used to strengthen the reply key 216 within the protected channel. Based on FAST, pre-authentication 217 mechanisms can extend Kerberos with ease, to support, for example, 218 password-authenticated key exchange (PAKE) protocols with zero- 219 knowledge password proof (ZKPP) [EKE] [IEEE1363.2]. Any pre- 220 authentication mechanism can be encapsulated in the FAST messages as 221 defined in Section 5.4. A pre-authentication type carried within 222 FAST is called a "FAST factor". Creating a FAST factor is the 223 224 225 226Hartman & Zhu Standards Track [Page 4] 227 228RFC 6113 Kerberos Preauth Framework April 2011 229 230 231 easiest path to create a new pre-authentication mechanism. FAST 232 factors are significantly easier to analyze from a security 233 standpoint than other pre-authentication mechanisms. 234 235 Mechanism designers should design FAST factors, instead of new pre- 236 authentication mechanisms outside of FAST. 237 2381.1. Conventions and Terminology Used in This Document 239 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 242 document are to be interpreted as described in [RFC2119]. 243 244 This document should be read only after reading the documents 245 describing the Kerberos cryptography framework [RFC3961] and the core 246 Kerberos protocol [RFC4120]. This document may freely use 247 terminology and notation from these documents without reference or 248 further explanation. 249 250 The word padata is used as a shorthand for pre-authentication data. 251 252 A conversation is the set of all authentication messages exchanged 253 between the client and the client's Authentication Service (AS) in 254 order to authenticate the client principal. A conversation as 255 defined here consists of all messages that are necessary to complete 256 the authentication between the client and the client's AS. In the 257 Ticket Granting Service (TGS) exchange, a conversation consists of 258 the request message and the reply message. The term conversation is 259 defined here for both AS and TGS for convenience of discussion. See 260 Section 5.2 for specific rules on the extent of a conversation in the 261 AS-REQ case. Prior to this framework, implementations needed to use 262 implementation-specific heuristics to determine the extent of a 263 conversation. 264 265 If the KDC reply in an AS exchange is verified, the KDC is 266 authenticated by the client. In this document, verification of the 267 KDC reply is used as a synonym of authentication of the KDC. 268 2691.2. Conformance Requirements 270 271 This section summarizes the mandatory-to-implement subset of this 272 specification as a convenience to implementors. The actual 273 requirements and their context are stated in the body of the 274 document. 275 276 Clients conforming to this specification MUST support the padata 277 defined in Section 5.2. 278 279 280 281 282Hartman & Zhu Standards Track [Page 5] 283 284RFC 6113 Kerberos Preauth Framework April 2011 285 286 287 Conforming implementations MUST support Kerberos FAST padata 288 (Section 5.4). Conforming implementations MUST implement the 289 FX_FAST_ARMOR_AP_REQUEST armor type. 290 291 Conforming implementations MUST support the encrypted challenge FAST 292 factor (Section 5.4.6). 293 2942. Model for Pre-Authentication 295 296 When a Kerberos client wishes to obtain a ticket, it sends an initial 297 Authentication Service (AS) request to the KDC. If pre- 298 authentication is required but not being used, then the KDC will 299 respond with a KDC_ERR_PREAUTH_REQUIRED error [RFC4120]. 300 Alternatively, if the client knows what pre-authentication to use, it 301 MAY optimize away a round trip and send an initial request with 302 padata included in the initial request. If the client includes the 303 padata computed using the wrong pre-authentication mechanism or 304 incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no 305 indication of what padata should have been included. In that case, 306 the client MUST retry with no padata and examine the error data of 307 the KDC_ERR_PREAUTH_REQUIRED error. If the KDC includes pre- 308 authentication information in the accompanying error data of 309 KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data and 310 then retry. 311 312 The conventional KDC maintains no state between two requests; 313 subsequent requests may even be processed by a different KDC. On the 314 other hand, the client treats a series of exchanges with KDCs as a 315 single conversation. Each exchange accumulates state and hopefully 316 brings the client closer to a successful authentication. 317 318 These models for state management are in apparent conflict. For many 319 of the simpler pre-authentication scenarios, the client uses one 320 round trip to find out what mechanisms the KDC supports. Then, the 321 next request contains sufficient pre-authentication for the KDC to be 322 able to return a successful reply. For these simple scenarios, the 323 client only sends one request with pre-authentication data and so the 324 conversation is trivial. For more complex conversations, the KDC 325 needs to provide the client with a cookie to include in future 326 requests to capture the current state of the authentication session. 327 Handling of multiple round-trip mechanisms is discussed in 328 Section 5.2. 329 330 This framework specifies the behavior of Kerberos pre-authentication 331 mechanisms used to identify users or to modify the reply key used to 332 encrypt the KDC reply. The PA-DATA typed hole may be used to carry 333 extensions to Kerberos that have nothing to do with proving the 334 335 336 337 338Hartman & Zhu Standards Track [Page 6] 339 340RFC 6113 Kerberos Preauth Framework April 2011 341 342 343 identity of the user or establishing a reply key. Such extensions 344 are outside the scope of this framework. However, mechanisms that do 345 accomplish these goals should follow this framework. 346 347 This framework specifies the minimum state that a Kerberos 348 implementation needs to maintain while handling a request in order to 349 process pre-authentication. It also specifies how Kerberos 350 implementations process the padata at each step of the AS request 351 process. 352 3532.1. Information Managed by the Pre-Authentication Model 354 355 The following information is maintained by the client and KDC as each 356 request is being processed: 357 358 o The reply key used to encrypt the KDC reply 359 360 o How strongly the identity of the client has been authenticated 361 362 o Whether the reply key has been used in this conversation 363 364 o Whether the reply key has been replaced in this conversation 365 366 o Whether the origin of the KDC reply can be verified by the client 367 (i.e., whether the KDC is authenticated to the client) 368 369 Conceptually, the reply key is initially the long-term key of the 370 principal. However, principals can have multiple long-term keys 371 because of support for multiple encryption types, salts, and 372 string2key parameters. As described in Section 5.2.7.5 of the 373 Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify 374 the client what types of keys are available. Thus, in full 375 generality, the reply key in the pre-authentication model is actually 376 a set of keys. At the beginning of a request, it is initialized to 377 the set of long-term keys advertised in the PA-ETYPE-INFO2 element on 378 the KDC. If multiple reply keys are available, the client chooses 379 which one to use. Thus, the client does not need to treat the reply 380 key as a set. At the beginning of a request, the client picks a key 381 to use. 382 383 KDC implementations MAY choose to offer only one key in the PA-ETYPE- 384 INFO2 element. Since the KDC already knows the client's list of 385 supported enctypes from the request, no interoperability problems are 386 387 388 389 390 391 392 393 394Hartman & Zhu Standards Track [Page 7] 395 396RFC 6113 Kerberos Preauth Framework April 2011 397 398 399 created by choosing a single possible reply key. This way, the KDC 400 implementation avoids the complexity of treating the reply key as a 401 set. 402 403 When the padata in the request are verified by the KDC, then the 404 client is known to have that key; therefore, the KDC SHOULD pick the 405 same key as the reply key. 406 407 At the beginning of handling a message on both the client and the 408 KDC, the client's identity is not authenticated. A mechanism may 409 indicate that it has successfully authenticated the client's 410 identity. It is useful to keep track of this information on the 411 client in order to know what pre-authentication mechanisms should be 412 used. The KDC needs to keep track of whether the client is 413 authenticated because the primary purpose of pre-authentication is to 414 authenticate the client identity before issuing a ticket. The 415 handling of authentication strength using various authentication 416 mechanisms is discussed in Section 5.5. 417 418 Initially, the reply key is not used. A pre-authentication mechanism 419 that uses the reply key to encrypt or checksum some data in the 420 generation of new keys MUST indicate that the reply key is used. 421 This state is maintained by the client and the KDC to enforce the 422 security requirement stated in Section 3.3 that the reply key SHOULD 423 NOT be replaced after it is used. 424 425 Initially, the reply key is not replaced. If a mechanism implements 426 the Replace Reply Key facility discussed in Section 3.3, then the 427 state MUST be updated to indicate that the reply key has been 428 replaced. Once the reply key has been replaced, knowledge of the 429 reply key is insufficient to authenticate the client. The reply key 430 is marked as replaced in exactly the same situations as the KDC reply 431 is marked as not being verified to the client principal. However, 432 while mechanisms can verify the KDC reply to the client, once the 433 reply key is replaced, then the reply key remains replaced for the 434 remainder of the conversation. 435 436 Without pre-authentication, the client knows that the KDC reply is 437 authentic and has not been modified because it is encrypted in a 438 long-term key of the client. Only the KDC and the client know that 439 key. So, at the start of a conversation, the KDC reply is presumed 440 to be verified using the client's long-term key. It should be noted 441 that in this document, verifying the KDC reply means authenticating 442 the KDC, and these phrases are used interchangeably. Any pre- 443 authentication mechanism that sets a new reply key not based on the 444 principal's long-term secret MUST either verify the KDC reply some 445 other way or indicate that the reply is not verified. If a mechanism 446 indicates that the reply is not verified, then the client 447 448 449 450Hartman & Zhu Standards Track [Page 8] 451 452RFC 6113 Kerberos Preauth Framework April 2011 453 454 455 implementation MUST return an error unless a subsequent mechanism 456 verifies the reply. The KDC needs to track this state so it can 457 avoid generating a reply that is not verified. 458 459 In this specification, KDC verification/authentication refers to the 460 level of authentication of the KDC to the client provided by RFC 461 4120. There is a stronger form of KDC verification that, while 462 sometimes important in Kerberos deployments, is not addressed in this 463 specification: the typical Kerberos request does not provide a way 464 for the client machine to know that it is talking to the correct KDC. 465 Someone who can inject packets into the network between the client 466 machine and the KDC and who knows the password that the user will 467 give to the client machine can generate a KDC reply that will decrypt 468 properly. So, if the client machine needs to authenticate that the 469 user is in fact the named principal, then the client machine needs to 470 do a TGS request for itself as a service. Some pre-authentication 471 mechanisms may provide a way for the client machine to authenticate 472 the KDC. Examples of this include signing the reply that can be 473 verified using a well-known public key or providing a ticket for the 474 client machine as a service. 475 4762.2. Initial Pre-Authentication Required Error 477 478 Typically, a client starts a conversation by sending an initial 479 request with no pre-authentication. If the KDC requires pre- 480 authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message. 481 After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code, 482 the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED 483 (defined in Section 5.2) for pre-authentication configurations that 484 use multi-round-trip mechanisms; see Section 2.4 for details of that 485 case. 486 487 The KDC needs to choose which mechanisms to offer the client. The 488 client needs to be able to choose what mechanisms to use from the 489 first message. For example, consider the KDC that will accept 490 mechanism A followed by mechanism B or alternatively the single 491 mechanism C. A client that supports A and C needs to know that it 492 should not bother trying A. 493 494 Mechanisms can either be sufficient on their own or can be part of an 495 authentication set -- a group of mechanisms that all need to 496 successfully complete in order to authenticate a client. Some 497 mechanisms may only be useful in authentication sets; others may be 498 useful alone or in authentication sets. For the second group of 499 mechanisms, KDC policy dictates whether the mechanism will be part of 500 an authentication set, offered alone, or both. For each mechanism 501 that is offered alone (even if it is also offered in an 502 authentication set), the KDC includes the pre-authentication type ID 503 504 505 506Hartman & Zhu Standards Track [Page 9] 507 508RFC 6113 Kerberos Preauth Framework April 2011 509 510 511 of the mechanism in the padata sequence returned in the 512 KDC_ERR_PREAUTH_REQUIRED error. Mechanisms that are only offered as 513 part of an authentication set are not directly represented in the 514 padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error, 515 although they are represented in the PA-AUTHENTICATION-SET sequence. 516 517 The KDC SHOULD NOT send data that is encrypted in the long-term 518 password-based key of the principal. Doing so has the same security 519 exposures as the Kerberos protocol without pre-authentication. There 520 are few situations where the KDC needs to expose cipher text 521 encrypted in a weak key before the client has proven knowledge of 522 that key, and where pre-authentication is desirable. 523 5242.3. Client to KDC 525 526 This description assumes that a client has already received a 527 KDC_ERR_PREAUTH_REQUIRED from the KDC. If the client performs 528 optimistic pre-authentication, then the client needs to guess values 529 for the information it would normally receive from that error 530 response or use cached information obtained in prior interactions 531 with the KDC. 532 533 The client starts by initializing the pre-authentication state as 534 specified. It then processes the padata in the 535 KDC_ERR_PREAUTH_REQUIRED. 536 537 When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the 538 client MAY ignore any padata it chooses unless doing so violates a 539 specification to which the client conforms. Clients conforming to 540 this specification MUST NOT ignore the padata defined in Section 5.2. 541 Clients SHOULD choose one authentication set or mechanism that could 542 lead to authenticating the user and ignore other such mechanisms. 543 However, this rule does not affect the processing of padata unrelated 544 to this framework; clients SHOULD process such padata normally. 545 Since the list of mechanisms offered by the KDC is in the decreasing 546 preference order, clients typically choose the first mechanism or 547 authentication set that the client can usefully perform. If a client 548 chooses to ignore padata, it MUST NOT process the padata, allow the 549 padata to affect the pre-authentication state, or respond to the 550 padata. 551 552 For each instance of padata the client chooses to process, the client 553 processes the padata and modifies the pre-authentication state as 554 required by that mechanism. 555 556 557 558 559 560 561 562Hartman & Zhu Standards Track [Page 10] 563 564RFC 6113 Kerberos Preauth Framework April 2011 565 566 567 After processing the padata in the KDC error, the client generates a 568 new request. It processes the pre-authentication mechanisms in the 569 order in which they will appear in the next request, updating the 570 state as appropriate. The request is sent when it is complete. 571 5722.4. KDC to Client 573 574 When a KDC receives an AS request from a client, it needs to 575 determine whether it will respond with an error or an AS reply. 576 There are many causes for an error to be generated that have nothing 577 to do with pre-authentication; they are discussed in the core 578 Kerberos specification. 579 580 From the standpoint of evaluating the pre-authentication, the KDC 581 first starts by initializing the pre-authentication state. If a PA- 582 FX-COOKIE pre-authentication data item is present, it is processed 583 first; see Section 5.2 for a definition. It then processes the 584 padata in the request. As mentioned in Section 2.3, the KDC MAY 585 ignore padata that are inappropriate for the configuration and MUST 586 ignore padata of an unknown type. The KDC MUST NOT ignore padata of 587 types used in previous messages. For example, if a KDC issues a 588 KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the 589 KDC cannot ignore padata of type x received in an AS-REQ message from 590 the client. 591 592 At this point, the KDC decides whether it will issue an error or a 593 reply. Typically, a KDC will issue a reply if the client's identity 594 has been authenticated to a sufficient degree. 595 596 In the case of a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error, the KDC 597 first starts by initializing the pre-authentication state. Then, it 598 processes any padata in the client's request in the order provided by 599 the client. Mechanisms that are not understood by the KDC are 600 ignored. Next, it generates padata for the error response, modifying 601 the pre-authentication state appropriately as each mechanism is 602 processed. The KDC chooses the order in which it will generate 603 padata (and thus the order of padata in the response), but it needs 604 to modify the pre-authentication state consistently with the choice 605 of order. For example, if some mechanism establishes an 606 authenticated client identity, then the subsequent mechanisms in the 607 generated response receive this state as input. After the padata are 608 generated, the error response is sent. Typically, the errors with 609 the code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED in a conversation will 610 include KDC state, as discussed in Section 5.2. 611 612 To generate a final reply, the KDC generates the padata modifying the 613 pre-authentication state as necessary. Then, it generates the final 614 response, encrypting it in the current pre-authentication reply key. 615 616 617 618Hartman & Zhu Standards Track [Page 11] 619 620RFC 6113 Kerberos Preauth Framework April 2011 621 622 6233. Pre-Authentication Facilities 624 625 Pre-authentication mechanisms can be thought of as providing various 626 conceptual facilities. This serves two useful purposes. First, 627 mechanism authors can choose only to solve one specific small 628 problem. It is often useful for a mechanism designed to offer key 629 management not to directly provide client authentication but instead 630 to allow one or more other mechanisms to handle this need. Secondly, 631 thinking about the abstract services that a mechanism provides yields 632 a minimum set of security requirements that all mechanisms providing 633 that facility must meet. These security requirements are not 634 complete; mechanisms will have additional security requirements based 635 on the specific protocol they employ. 636 637 A mechanism is not constrained to only offering one of these 638 facilities. While such mechanisms can be designed and are sometimes 639 useful, many pre-authentication mechanisms implement several 640 facilities. It is often easier to construct a secure, simple 641 solution by combining multiple facilities in a single mechanism than 642 by solving the problem in full generality. Even when mechanisms 643 provide multiple facilities, they need to meet the security 644 requirements for all the facilities they provide. If the FAST factor 645 approach is used, it is likely that one or a small number of 646 facilities can be provided by a single mechanism without complicating 647 the security analysis. 648 649 According to Kerberos extensibility rules (Section 1.5 of the 650 Kerberos specification [RFC4120]), an extension MUST NOT change the 651 semantics of a message unless a recipient is known to understand that 652 extension. Because a client does not know that the KDC supports a 653 particular pre-authentication mechanism when it sends an initial 654 request, a pre-authentication mechanism MUST NOT change the semantics 655 of the request in a way that will break a KDC that does not 656 understand that mechanism. Similarly, KDCs MUST NOT send messages to 657 clients that affect the core semantics unless the client has 658 indicated support for the message. 659 660 The only state in this model that would break the interpretation of a 661 message is changing the expected reply key. If one mechanism changed 662 the reply key and a later mechanism used that reply key, then a KDC 663 that interpreted the second mechanism but not the first would fail to 664 interpret the request correctly. In order to avoid this problem, 665 extensions that change core semantics are typically divided into two 666 parts. The first part proposes a change to the core semantic -- for 667 example, proposes a new reply key. The second part acknowledges that 668 the extension is understood and that the change takes effect. 669 Section 3.2 discusses how to design mechanisms that modify the reply 670 key to be split into a proposal and acceptance without requiring 671 672 673 674Hartman & Zhu Standards Track [Page 12] 675 676RFC 6113 Kerberos Preauth Framework April 2011 677 678 679 additional round trips to use the new reply key in subsequent pre- 680 authentication. Other changes in the state described in Section 2.1 681 can safely be ignored by a KDC that does not understand a mechanism. 682 Mechanisms that modify the behavior of the request outside the scope 683 of this framework need to carefully consider the Kerberos 684 extensibility rules to avoid similar problems. 685 6863.1. Client Authentication Facility 687 688 The Client Authentication facility proves the identity of a user to 689 the KDC before a ticket is issued. Examples of mechanisms 690 implementing this facility include the encrypted timestamp facility, 691 defined in Section 5.2.7.2 of the Kerberos specification [RFC4120]. 692 Mechanisms that provide this facility are expected to mark the client 693 as authenticated. 694 695 Mechanisms implementing this facility SHOULD require the client to 696 prove knowledge of the reply key before transmitting a successful KDC 697 reply. Otherwise, an attacker can intercept the pre-authentication 698 exchange and get a reply to attack. One way of proving the client 699 knows the reply key is to implement the Replace Reply Key facility 700 along with this facility. The Public Key Cryptography for Initial 701 Authentication in Kerberos (PKINIT) mechanism [RFC4556] implements 702 Client Authentication alongside Replace Reply Key. 703 704 If the reply key has been replaced, then mechanisms such as 705 encrypted-timestamp that rely on knowledge of the reply key to 706 authenticate the client MUST NOT be used. 707 7083.2. Strengthening Reply Key Facility 709 710 Particularly when dealing with keys based on passwords, it is 711 desirable to increase the strength of the key by adding additional 712 secrets to it. Examples of sources of additional secrets include the 713 results of a Diffie-Hellman key exchange or key bits from the output 714 of a smart card [KRB-WG.SAM]. Typically, these additional secrets 715 can be first combined with the existing reply key and then converted 716 to a protocol key using tools defined in Section 5.1. 717 718 Typically, a mechanism implementing this facility will know that the 719 other side of the exchange supports the facility before the reply key 720 is changed. For example, a mechanism might need to learn the 721 certificate for a KDC before encrypting a new key in the public key 722 belonging to that certificate. However, if a mechanism implementing 723 this facility wishes to modify the reply key before knowing that the 724 other party in the exchange supports the mechanism, it proposes 725 modifying the reply key. The other party then includes a message 726 indicating that the proposal is accepted if it is understood and 727 728 729 730Hartman & Zhu Standards Track [Page 13] 731 732RFC 6113 Kerberos Preauth Framework April 2011 733 734 735 meets policy. In many cases, it is desirable to use the new reply 736 key for client authentication and for other facilities. Waiting for 737 the other party to accept the proposal and actually modify the reply 738 key state would add an additional round trip to the exchange. 739 Instead, mechanism designers are encouraged to include a typed hole 740 for additional padata in the message that proposes the reply key 741 change. The padata included in the typed hole are generated assuming 742 the new reply key. If the other party accepts the proposal, then 743 these padata are considered as an inner level. As with the outer 744 level, one authentication set or mechanism is typically chosen for 745 client authentication, along with auxiliary mechanisms such as KDC 746 cookies, and other mechanisms are ignored. When mechanisms include 747 such a container, the hint provided for use in authentication sets 748 (as defined in Section 5.3) MUST contain a sequence of inner 749 mechanisms along with hints for those mechanisms. The party 750 generating the proposal can determine whether the padata were 751 processed based on whether the proposal for the reply key is 752 accepted. 753 754 The specific formats of the proposal message, including where padata 755 are included, is a matter for the mechanism specification. 756 Similarly, the format of the message accepting the proposal is 757 mechanism specific. 758 759 Mechanisms implementing this facility and including a typed hole for 760 additional padata MUST checksum that padata using a keyed checksum or 761 encrypt the padata. This requirement protects against modification 762 of the contents of the typed hole. By modifying these contents, an 763 attacker might be able to choose which mechanism is used to 764 authenticate the client, or to convince a party to provide text 765 encrypted in a key that the attacker had manipulated. It is 766 important that mechanisms strengthen the reply key enough that using 767 it to checksum padata is appropriate. 768 7693.3. Replace Reply Key Facility 770 771 The Replace Reply Key facility replaces the key in which a successful 772 AS reply will be encrypted. This facility can only be used in cases 773 where knowledge of the reply key is not used to authenticate the 774 client. The new reply key MUST be communicated to the client and the 775 KDC in a secure manner. This facility MUST NOT be used if there can 776 be a man-in-the-middle between the client and the KDC. Mechanisms 777 implementing this facility MUST mark the reply key as replaced in the 778 pre-authentication state. Mechanisms implementing this facility MUST 779 either provide a mechanism to verify the KDC reply to the client or 780 mark the reply as unverified in the pre-authentication state. 781 Mechanisms implementing this facility SHOULD NOT be used if a 782 previous mechanism has used the reply key. 783 784 785 786Hartman & Zhu Standards Track [Page 14] 787 788RFC 6113 Kerberos Preauth Framework April 2011 789 790 791 As with the Strengthening Reply Key facility, Kerberos extensibility 792 rules require that the reply key not be changed unless both sides of 793 the exchange understand the extension. In the case of this facility, 794 it will likely be the case for both sides to know that the facility 795 is available by the time that the new key is available to be used. 796 However, mechanism designers can use a container for padata in a 797 proposal message, as discussed in Section 3.2, if appropriate. 798 7993.4. KDC Authentication Facility 800 801 This facility verifies that the reply comes from the expected KDC. 802 In traditional Kerberos, the KDC and the client share a key, so if 803 the KDC reply can be decrypted, then the client knows that a trusted 804 KDC responded. Note that the client machine cannot trust the client 805 unless the machine is presented with a service ticket for it 806 (typically, the machine can retrieve this ticket by itself). 807 However, if the reply key is replaced, some mechanism is required to 808 verify the KDC. Pre-authentication mechanisms providing this 809 facility allow a client to determine that the expected KDC has 810 responded even after the reply key is replaced. They mark the pre- 811 authentication state as having been verified. 812 8134. Requirements for Pre-Authentication Mechanisms 814 815 This section lists requirements for specifications of pre- 816 authentication mechanisms. 817 818 For each message in the pre-authentication mechanism, the 819 specification describes the pa-type value to be used and the contents 820 of the message. The processing of the message by the sender and 821 recipient is also specified. This specification needs to include all 822 modifications to the pre-authentication state. 823 824 Generally, mechanisms have a message that can be sent in the error 825 data of the KDC_ERR_PREAUTH_REQUIRED error message or in an 826 authentication set. If the client needs information, such as trusted 827 certificate authorities, in order to determine if it can use the 828 mechanism, then this information should be in that message. In 829 addition, such mechanisms should also define a pa-hint to be included 830 in authentication sets. Often, the same information included in the 831 padata-value is appropriate to include in the pa-hint (as defined in 832 Section 5.3). 833 834 In order to ease security analysis, the mechanism specification 835 should describe what facilities from this document are offered by the 836 mechanism. For each facility, the security considerations section of 837 the mechanism specification should show that the security 838 839 840 841 842Hartman & Zhu Standards Track [Page 15] 843 844RFC 6113 Kerberos Preauth Framework April 2011 845 846 847 requirements of that facility are met. This requirement is 848 applicable to any FAST factor that provides authentication 849 information. 850 851 Significant problems have resulted in the specification of Kerberos 852 protocols because much of the KDC exchange is not protected against 853 alteration. The security considerations section should discuss 854 unauthenticated plaintext attacks. It should either show that 855 plaintext is protected or discuss what harm an attacker could do by 856 modifying the plaintext. It is generally acceptable for an attacker 857 to be able to cause the protocol negotiation to fail by modifying 858 plaintext. More significant attacks should be evaluated carefully. 859 860 As discussed in Section 5.2, there is no guarantee that a client will 861 use the same KDCs for all messages in a conversation. The mechanism 862 specification needs to show why the mechanism is secure in this 863 situation. The hardest problem to deal with, especially for 864 challenge/response mechanisms is to make sure that the same response 865 cannot be replayed against two KDCs while allowing the client to talk 866 to any KDC. 867 8684.1. Protecting Requests/Responses 869 870 Mechanism designers SHOULD protect cleartext portions of pre- 871 authentication data. Various denial-of-service attacks and downgrade 872 attacks against Kerberos are possible unless plaintexts are somehow 873 protected against modification. An early design goal of Kerberos 874 Version 5 [RFC4120] was to avoid encrypting more of the 875 authentication exchange than was required. (Version 4 doubly- 876 encrypted the encrypted part of a ticket in a KDC reply, for 877 example). This minimization of encryption reduces the load on the 878 KDC and busy servers. Also, during the initial design of Version 5, 879 the existence of legal restrictions on the export of cryptography 880 made it desirable to minimize of the number of uses of encryption in 881 the protocol. Unfortunately, performing this minimization created 882 numerous instances of unauthenticated security-relevant plaintext 883 fields. 884 885 Mechanisms MUST guarantee that by the end of a successful 886 authentication exchange, both the client and the KDC have verified 887 all the plaintext sent by the other party. If there is more than one 888 round trip in the exchange, mechanisms MUST additionally guarantee 889 that no individual messages were reordered or replayed from a 890 previous exchange. Strategies for accomplishing this include using 891 message authentication codes (MACs) to protect the plaintext as it is 892 sent including some form of nonce or cookie to allow for the chaining 893 of state from one message to the next or exchanging a MAC of the 894 entire conversation after a key is established. 895 896 897 898Hartman & Zhu Standards Track [Page 16] 899 900RFC 6113 Kerberos Preauth Framework April 2011 901 902 903 Mechanism designers need to provide a strategy for updating 904 cryptographic algorithms, such as defining a new pre-authentication 905 type for each algorithm or taking advantage of the client's list of 906 supported RFC 3961 encryption types to indicate the client's support 907 for cryptographic algorithms. 908 909 Primitives defined in [RFC3961] are RECOMMENDED for integrity 910 protection and confidentiality. Mechanisms based on these primitives 911 are crypto-agile as the result of using [RFC3961] along with 912 [RFC4120]. The advantage afforded by crypto-agility is the ability 913 to incrementally deploy a fix specific to a particular algorithm thus 914 avoid a multi-year standardization and deployment cycle, when real 915 attacks do arise against that algorithm. 916 917 Note that data used by FAST factors (defined in Section 5.4) is 918 encrypted in a protected channel; thus, they do not share the un- 919 authenticated-text issues with mechanisms designed as full-blown pre- 920 authentication mechanisms. 921 9225. Tools for Use in Pre-Authentication Mechanisms 923 924 This section describes common tools needed by multiple pre- 925 authentication mechanisms. By using these tools, mechanism designers 926 can use a modular approach to specify mechanism details and ease 927 security analysis. 928 9295.1. Combining Keys 930 931 Frequently, a weak key needs to be combined with a stronger key 932 before use. For example, passwords are typically limited in size and 933 insufficiently random: therefore, it is desirable to increase the 934 strength of the keys based on passwords by adding additional secrets. 935 An additional source of secrecy may come from hardware tokens. 936 937 This section provides standard ways to combine two keys into one. 938 939 KRB-FX-CF1() is defined to combine two passphrases. 940 941 KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string) 942 KRB-FX-CF1(x, y) := x || y 943 944 Where || denotes concatenation. The strength of the final key is 945 roughly the total strength of the individual keys being combined, 946 assuming that the string_to_key() function [RFC3961] uses all its 947 input evenly. 948 949 950 951 952 953 954Hartman & Zhu Standards Track [Page 17] 955 956RFC 6113 Kerberos Preauth Framework April 2011 957 958 959 An example usage of KRB-FX-CF1() is when a device provides random but 960 short passwords, the password is often combined with a personal 961 identification number (PIN). The password and the PIN can be 962 combined using KRB-FX-CF1(). 963 964 KRB-FX-CF2() combines two protocol keys based on the pseudo-random() 965 function defined in [RFC3961]. 966 967 Given two input keys, K1 and K2, where K1 and K2 can be of two 968 different enctypes, the output key of KRB-FX-CF2(), K3, is derived as 969 follows: 970 971 KRB-FX-CF2(protocol key, protocol key, octet string, 972 octet string) -> (protocol key) 973 974 PRF+(K1, pepper1) -> octet-string-1 975 PRF+(K2, pepper2) -> octet-string-2 976 KRB-FX-CF2(K1, K2, pepper1, pepper2) := 977 random-to-key(octet-string-1 ^ octet-string-2) 978 979 Where ^ denotes the exclusive-OR operation. PRF+() is defined as 980 follows: 981 982 PRF+(protocol key, octet string) -> (octet string) 983 984 PRF+(key, shared-info) := pseudo-random( key, 1 || shared-info ) || 985 pseudo-random( key, 2 || shared-info ) || 986 pseudo-random( key, 3 || shared-info ) || ... 987 988 Here the counter value 1, 2, 3, and so on are encoded as a one-octet 989 integer. The pseudo-random() operation is specified by the enctype 990 of the protocol key. PRF+() uses the counter to generate enough bits 991 as needed by the random-to-key() [RFC3961] function for the 992 encryption type specified for the resulting key; unneeded bits are 993 removed from the tail. Unless otherwise specified, the resulting 994 enctype of KRB-FX-CF2 is the enctype of k1. The pseudo-random() 995 operation is the RFC 3961 pseudo-random() operation for the 996 corresponding input key; the random-to-key() operation is the RFC 997 3961 random-to-key operation for the resulting key. 998 999 Mechanism designers MUST specify the values for the input parameter 1000 pepper1 and pepper2 when combining two keys using KRB-FX-CF2(). The 1001 pepper1 and pepper2 MUST be distinct so that if the two keys being 1002 combined are the same, the resulting key is not a trivial key. 1003 1004 1005 1006 1007 1008 1009 1010Hartman & Zhu Standards Track [Page 18] 1011 1012RFC 6113 Kerberos Preauth Framework April 2011 1013 1014 10155.2. Managing States for the KDC 1016 1017 Kerberos KDCs are stateless in that there is no requirement that 1018 clients will choose the same KDC for the second request in a 1019 conversation. Proxies or other intermediate nodes may also influence 1020 KDC selection. So, each request from a client to a KDC must include 1021 sufficient information that the KDC can regenerate any needed state. 1022 This is accomplished by giving the client a potentially long opaque 1023 cookie in responses to include in future requests in the same 1024 conversation. The KDC MAY respond that a conversation is too old and 1025 needs to restart by responding with a KDC_ERR_PREAUTH_EXPIRED error. 1026 1027 KDC_ERR_PREAUTH_EXPIRED 90 1028 1029 When a client receives this error, the client SHOULD abort the 1030 existing conversation, and restart a new one. 1031 1032 An example, where more than one message from the client is needed, is 1033 when the client is authenticated based on a challenge/response 1034 scheme. In that case, the KDC needs to keep track of the challenge 1035 issued for a client authentication request. 1036 1037 The PA-FX-COOKIE padata type is defined in this section to facilitate 1038 state management in the AS exchange. These padata are sent by the 1039 KDC when the KDC requires state for a future transaction. The client 1040 includes this opaque token in the next message in the conversation. 1041 The token may be relatively large; clients MUST be prepared for 1042 tokens somewhat larger than the size of all messages in a 1043 conversation. 1044 1045 PA-FX-COOKIE 133 1046 -- Stateless cookie that is not tied to a specific KDC. 1047 1048 The corresponding padata-value field [RFC4120] contains an opaque 1049 token that will be echoed by the client in its response to an error 1050 from the KDC. 1051 1052 The cookie token is generated by the KDC and transmitted in a PA-FX- 1053 COOKIE pre-authentication data item of a KRB-ERROR message. The 1054 client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data 1055 element into the next message of the same conversation. The content 1056 of the cookie field is a local matter of the KDC. As a result, it is 1057 not generally possible to mix KDC implementations from different 1058 vendors in the same realm. However, the KDC MUST construct the 1059 cookie token in such a manner that a malicious client cannot subvert 1060 the authentication process by manipulating the token. The KDC 1061 implementation needs to consider expiration of tokens, key rollover, 1062 and other security issues in token design. The content of the cookie 1063 1064 1065 1066Hartman & Zhu Standards Track [Page 19] 1067 1068RFC 6113 Kerberos Preauth Framework April 2011 1069 1070 1071 field is likely specific to the pre-authentication mechanisms used to 1072 authenticate the client. If a client authentication response can be 1073 replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an 1074 expiration in the cookie is RECOMMENDED to prevent the response being 1075 presented indefinitely. Implementations need to consider replay both 1076 of an entire conversation and of messages within a conversation when 1077 designing what information is stored in a cookie and how pre- 1078 authentication mechanisms are implemented. 1079 1080 If at least one more message for a mechanism or a mechanism set is 1081 expected by the KDC, the KDC returns a 1082 KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error with a PA-FX-COOKIE to 1083 identify the conversation with the client, according to Section 2.2. 1084 The cookie is not expected to stay constant for a conversation: the 1085 KDC is expected to generate a new cookie for each message. 1086 1087 KDC_ERR_MORE_PREAUTH_DATA_REQUIRED 91 1088 1089 A client MAY throw away the state associated with a conversation and 1090 begin a new conversation by discarding its state and not including a 1091 cookie in the first message of a conversation. KDCs that comply with 1092 this specification MUST include a cookie in a response when the 1093 client can continue the conversation. In particular, a KDC MUST 1094 include a cookie in a KDC_ERR_PREAUTH_REQUIRED or 1095 KDC_ERR_MORE_PREAUTH_DATA_REQUIRED. KDCs SHOULD include a cookie in 1096 errors containing additional information allowing a client to retry. 1097 One reasonable strategy for meeting these requirements is to always 1098 include a cookie in KDC errors. 1099 1100 A KDC MAY indicate that it is terminating a conversation by not 1101 including a cookie in a response. When FAST is used, clients can 1102 assume that the absence of a cookie means that the KDC is ending the 1103 conversation. Similarly, if a cookie is seen at all during a 1104 conversation, clients MAY assume that the absence of a cookie in a 1105 future message means that the KDC is ending the conversation. 1106 Clients also need to deal with KDCs, prior to this specification, 1107 that do not include cookies; if neither cookies nor FAST are used in 1108 a conversation, the absence of a cookie is not a strong indication 1109 that the KDC is terminating the conversation. 1110 11115.3. Pre-Authentication Set 1112 1113 If all mechanisms in a group need to successfully complete in order 1114 to authenticate a client, the client and the KDC SHOULD use the PA- 1115 AUTHENTICATION-SET padata element. 1116 1117 PA-AUTHENTICATION-SET 134 1118 1119 1120 1121 1122Hartman & Zhu Standards Track [Page 20] 1123 1124RFC 6113 Kerberos Preauth Framework April 2011 1125 1126 1127 A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER 1128 encoding of the PA-AUTHENTICATION-SET structure: 1129 1130 PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM 1131 1132 PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE { 1133 pa-type [0] Int32, 1134 -- same as padata-type. 1135 pa-hint [1] OCTET STRING OPTIONAL, 1136 pa-value [2] OCTET STRING OPTIONAL, 1137 ... 1138 } 1139 1140 The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure 1141 contains the corresponding value of padata-type in PA-DATA [RFC4120]. 1142 Associated with the pa-type is a pa-hint, which is an octet string 1143 specified by the pre-authentication mechanism. This hint may provide 1144 information for the client that helps it determine whether the 1145 mechanism can be used. For example, a public-key mechanism might 1146 include the certificate authorities it trusts in the hint info. Most 1147 mechanisms today do not specify hint info; if a mechanism does not 1148 specify hint info, the KDC MUST NOT send a hint for that mechanism. 1149 To allow future revisions of mechanism specifications to add hint 1150 info, clients MUST ignore hint info received for mechanisms that the 1151 client believes do not support hint info. The pa-value element of 1152 the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the 1153 first padata-value from the KDC to the client. If the client chooses 1154 this authentication set, then the client MUST process this pa-value. 1155 The pa-value element MUST be absent for all but the first entry in 1156 the authentication set. Clients MUST ignore the pa-value for the 1157 second and following entries in the authentication set. 1158 1159 If the client chooses an authentication set, then its first AS-REQ 1160 message MUST contain a PA-AUTH-SET-SELECTED padata element. This 1161 element contains the encoding of the PA-AUTHENTICATION-SET sequence 1162 received from the KDC corresponding to the authentication set that is 1163 chosen. The client MUST use the same octet values received from the 1164 KDC; it cannot re-encode the sequence. This allows KDCs to use bit- 1165 wise comparison to identify the selected authentication set. 1166 Permitting bit-wise comparison may limit the ability to use certain 1167 pre-authentication mechanisms that generate a dynamic challenge in an 1168 authentication set with optimistic selection of an authentication 1169 set. As with other optimistic pre-authentication failures, the KDC 1170 MAY return KDC_ERR_PREAUTH_FAILED with a new list of pre- 1171 authentication mechanisms (including authentication sets) if 1172 optimistic pre-authentication fails. The PA-AUTH-SET-SELECTED padata 1173 element MUST come before any padata elements from the authentication 1174 set in the padata sequence in the AS-REQ message. The client MAY 1175 1176 1177 1178Hartman & Zhu Standards Track [Page 21] 1179 1180RFC 6113 Kerberos Preauth Framework April 2011 1181 1182 1183 cache authentication sets from prior messages and use them to 1184 construct an optimistic initial AS-REQ. If the KDC receives a PA- 1185 AUTH-SET-SELECTED padata element that does not correspond to an 1186 authentication set that it would offer, then the KDC returns the 1187 KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error. The e-data in this 1188 error contains a sequence of padata just as for the 1189 KDC_ERR_PREAUTH_REQUIRED error. 1190 1191 PA-AUTH-SET-SELECTED 135 1192 KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92 1193 1194 The PA-AUTHENTICATION-SET appears only in the first message from the 1195 KDC to the client. In particular, the client MAY fail if the 1196 authentication mechanism sets change as the conversation progresses. 1197 Clients MAY assume that the hints provided in the authentication set 1198 contain enough information that the client knows what user interface 1199 elements need to be displayed during the entire authentication 1200 conversation. Exceptional circumstances, such as expired passwords 1201 or expired accounts, may require that additional user interface be 1202 displayed. Mechanism designers need to carefully consider the design 1203 of their hints so that the client has this information. This way, 1204 clients can construct necessary dialogue boxes or wizards based on 1205 the authentication set and can present a coherent user interface. 1206 Current standards for user interfaces do not provide an acceptable 1207 experience when the client has to ask additional questions later in 1208 the conversation. 1209 1210 When indicating which sets of pre-authentication mechanisms are 1211 supported, the KDC includes a PA-AUTHENTICATION-SET padata element 1212 for each pre-authentication mechanism set. 1213 1214 The client sends the padata-value for the first mechanism it picks in 1215 the pre-authentication set, when the first mechanism completes, the 1216 client and the KDC will proceed with the second mechanism, and so on 1217 until all mechanisms complete successfully. The PA-FX-COOKIE, as 1218 defined in Section 5.2, MUST be sent by the KDC. One reason for this 1219 requirement is so that the conversation can continue if the 1220 conversation involves multiple KDCs. KDCs MUST support clients that 1221 do not include a cookie because they optimistically choose an 1222 authentication set, although they MAY always return a 1223 KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in that 1224 message. Clients that support PA-AUTHENTICATION-SET MUST support PA- 1225 FX-COOKIE. 1226 1227 Before the authentication succeeds and a ticket is returned, the 1228 message that the client sends is an AS-REQ and the message that the 1229 KDC sends is a KRB-ERROR message. The error code in the KRB-ERROR 1230 message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_REQUIRED as defined 1231 1232 1233 1234Hartman & Zhu Standards Track [Page 22] 1235 1236RFC 6113 Kerberos Preauth Framework April 2011 1237 1238 1239 in Section 5.2 and the accompanying e-data contains the DER encoding 1240 of ASN.1 type METHOD-DATA. The KDC includes the padata elements in 1241 the METHOD-DATA. If there are no padata, the e-data field is absent 1242 in the KRB-ERROR message. 1243 1244 If the client sends the last message for a given mechanism, then the 1245 KDC sends the first message for the next mechanism. If the next 1246 mechanism does not start with a KDC-side challenge, then the KDC 1247 includes a padata item with the appropriate pa-type and an empty pa- 1248 data. 1249 1250 If the KDC sends the last message for a particular mechanism, the KDC 1251 also includes the first padata for the next mechanism. 1252 12535.4. Definition of Kerberos FAST Padata 1254 1255 As described in [RFC4120], Kerberos is vulnerable to offline 1256 dictionary attacks. An attacker can request an AS-REP and try 1257 various passwords to see if they can decrypt the resulting ticket. 1258 RFC 4120 provides the encrypted timestamp pre-authentication method 1259 that ameliorates the situation somewhat by requiring that an attacker 1260 observe a successful authentication. However, stronger security is 1261 desired in many environments. The Kerberos FAST pre-authentication 1262 padata defined in this section provides a tool to significantly 1263 reduce vulnerability to offline dictionary attacks. When combined 1264 with encrypted challenge, FAST requires an attacker to mount a 1265 successful man-in-the-middle attack to observe ciphertext. When 1266 combined with host keys, FAST can even protect against active 1267 attacks. FAST also provides solutions to common problems for pre- 1268 authentication mechanisms such as binding of the request and the 1269 reply and freshness guarantee of the authentication. FAST itself, 1270 however, does not authenticate the client or the KDC; instead, it 1271 provides a typed hole to allow pre-authentication data be tunneled. 1272 A pre-authentication data element used within FAST is called a "FAST 1273 factor". A FAST factor captures the minimal work required for 1274 extending Kerberos to support a new pre-authentication scheme. 1275 1276 A FAST factor MUST NOT be used outside of FAST unless its 1277 specification explicitly allows so. The typed holes in FAST messages 1278 can also be used as generic holes for other padata that are not 1279 intended to prove the client's identity, or establish the reply key. 1280 1281 New pre-authentication mechanisms SHOULD be designed as FAST factors, 1282 instead of full-blown pre-authentication mechanisms. 1283 1284 FAST factors that are pre-authentication mechanisms MUST meet the 1285 requirements in Section 4. 1286 1287 1288 1289 1290Hartman & Zhu Standards Track [Page 23] 1291 1292RFC 6113 Kerberos Preauth Framework April 2011 1293 1294 1295 FAST employs an armoring scheme. The armor can be a Ticket Granting 1296 Ticket (TGT) obtained by the client's machine using the host keys to 1297 pre-authenticate with the KDC, or an anonymous TGT obtained based on 1298 anonymous PKINIT [RFC6112] [RFC4556]. 1299 1300 The rest of this section describes the types of armors and the syntax 1301 of the messages used by FAST. Conforming implementations MUST 1302 support Kerberos FAST padata. 1303 1304 Any FAST armor scheme MUST provide a fresh armor key for each 1305 conversation. Clients and KDCs can assume that if a message is 1306 encrypted and integrity protected with a given armor key, then it is 1307 part of the conversation using that armor key. 1308 1309 All KDCs in a realm MUST support FAST if FAST is offered by any KDC 1310 as a pre-authentication mechanism. 1311 13125.4.1. FAST Armors 1313 1314 An armor key is used to encrypt pre-authentication data in the FAST 1315 request and the response. The KrbFastArmor structure is defined to 1316 identify the armor key. This structure contains the following two 1317 fields: the armor-type identifies the type of armors and the armor- 1318 value is an OCTET STRING that contains the description of the armor 1319 scheme and the armor key. 1320 1321 KrbFastArmor ::= SEQUENCE { 1322 armor-type [0] Int32, 1323 -- Type of the armor. 1324 armor-value [1] OCTET STRING, 1325 -- Value of the armor. 1326 ... 1327 } 1328 1329 The value of the armor key is a matter of the armor type 1330 specification. Only one armor type is defined in this document. 1331 1332 FX_FAST_ARMOR_AP_REQUEST 1 1333 1334 The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets. 1335 1336 Conforming implementations MUST implement the 1337 FX_FAST_ARMOR_AP_REQUEST armor type. If a FAST KDC receives an 1338 unknown armor type it MUST respond with KDC_ERR_PREAUTH_FAILED. 1339 1340 An armor type may be appropriate for use in armoring AS requests, 1341 armoring TGS requests, or both. TGS armor types MUST authenticate 1342 the client to the KDC, typically by binding the TGT sub-session key 1343 1344 1345 1346Hartman & Zhu Standards Track [Page 24] 1347 1348RFC 6113 Kerberos Preauth Framework April 2011 1349 1350 1351 to the armor key. As discussed below, it is desirable for AS armor 1352 types to authenticate the KDC to the client, but this is not 1353 required. 1354 1355 FAST implementations MUST maintain state about whether the armor 1356 mechanism authenticates the KDC. If it does not, then a FAST factor 1357 that authenticates the KDC MUST be used if the reply key is replaced. 1358 13595.4.1.1. Ticket-Based Armors 1360 1361 This is a ticket-based armoring scheme. The armor-type is 1362 FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER 1363 encoded AP-REQ. The ticket in the AP-REQ is called an armor ticket 1364 or an armor TGT. The subkey field in the AP-REQ MUST be present. 1365 The armor key is defined by the following function: 1366 1367 armor_key = KRB-FX-CF2( subkey, ticket_session_key, 1368 "subkeyarmor", "ticketarmor" ) 1369 1370 The 'ticket_session_key' is the session key from the ticket in the 1371 ap-req. The 'subkey' is the ap-req subkey. This construction 1372 guarantees that both the KDC (through the session key) and the client 1373 (through the subkey) contribute to the armor key. 1374 1375 The server name field of the armor ticket MUST identify the TGS of 1376 the target realm. Here are three common ways in the decreasing 1377 preference order how an armor TGT SHOULD be obtained: 1378 1379 1. If the client is authenticating from a host machine whose 1380 Kerberos realm has an authentication path to the client's realm, 1381 the host machine obtains a TGT by using the host keys. If the 1382 client's realm is different than the realm of the local host, the 1383 machine then obtains a cross-realm TGT to the client's realm as 1384 the armor ticket. Otherwise, the host's primary TGT is the armor 1385 ticket. 1386 1387 2. If the client's host machine cannot obtain a host ticket strictly 1388 based on RFC 4120, but the KDC has an asymmetric signing key 1389 whose binding with the expected KDC can be verified by the 1390 client, the client can use anonymous PKINIT [RFC6112] [RFC4556] 1391 to authenticate the KDC and obtain an anonymous TGT as the armor 1392 ticket. The armor ticket can also be a cross-realm TGT obtained 1393 based on the initial primary TGT obtained using anonymous PKINIT 1394 with KDC authentication. 1395 1396 3. Otherwise, the client uses anonymous PKINIT to get an anonymous 1397 TGT without KDC authentication and that TGT is the armor ticket. 1398 Note that this mode of operation is vulnerable to man-in-the- 1399 1400 1401 1402Hartman & Zhu Standards Track [Page 25] 1403 1404RFC 6113 Kerberos Preauth Framework April 2011 1405 1406 1407 middle attacks at the time of obtaining the initial anonymous 1408 armor TGT. 1409 1410 If anonymous PKINIT is used to obtain the armor ticket, the KDC 1411 cannot know whether its signing key can be verified by the client; 1412 hence, the KDC MUST be marked as unverified from the KDC's point of 1413 view while the client could be able to authenticate the KDC by 1414 verifying the KDC's signing key is bound with the expected KDC. The 1415 client needs to carefully consider the risk and benefit tradeoffs 1416 associated with active attacks before exposing cipher text encrypted 1417 using the user's long-term secrets when the armor does not 1418 authenticate the KDC. 1419 1420 The TGS MUST reject a request if there is an AD-fx-fast-armor (71) 1421 element in the authenticator of the pa-tgs-req padata or if the 1422 ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast- 1423 armor authorization data element. These tickets and authenticators 1424 MAY be used as FAST armor tickets but not to obtain a ticket via the 1425 TGS. This authorization data is used in a system where the 1426 encryption of the user's pre-authentication data is performed in an 1427 unprivileged user process. A privileged process can provide to the 1428 user process a host ticket, an authenticator for use with that 1429 ticket, and the sub-session key contained in the authenticator. In 1430 order for the host process to ensure that the host ticket is not 1431 accidentally or intentionally misused, (i.e., the user process might 1432 use the host ticket to authenticate as the host), it MUST include a 1433 critical authorization data element of the type AD-fx-fast-armor when 1434 providing the authenticator or in the enc-authorization-data field of 1435 the TGS request used to obtain the TGT. The corresponding ad-data 1436 field of the AD-fx-fast-armor element is empty. 1437 1438 This armor type is only valid for AS requests; implicit armor, 1439 described below in TGS processing, is the only supported way to 1440 establish an armor key for the TGS at this time. 1441 14425.4.2. FAST Request 1443 1444 A padata type PA-FX-FAST is defined for the Kerberos FAST pre- 1445 authentication padata. The corresponding padata-value field 1446 [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST- 1447 REQUEST. As with all pre-authentication types, the KDC SHOULD 1448 advertise PA-FX-FAST in a PREAUTH_REQUIRED error. KDCs MUST send the 1449 advertisement of PA-FX-FAST with an empty pa-value. Clients MUST 1450 ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED 1451 error. FAST is not expected to be used in an authentication set: 1452 clients will typically use FAST padata if available and this decision 1453 should not depend on what other pre-authentication methods are 1454 available. As such, no pa-hint is defined for FAST at this time. 1455 1456 1457 1458Hartman & Zhu Standards Track [Page 26] 1459 1460RFC 6113 Kerberos Preauth Framework April 2011 1461 1462 1463 PA-FX-FAST 136 1464 -- Padata type for Kerberos FAST 1465 1466 PA-FX-FAST-REQUEST ::= CHOICE { 1467 armored-data [0] KrbFastArmoredReq, 1468 ... 1469 } 1470 1471 KrbFastArmoredReq ::= SEQUENCE { 1472 armor [0] KrbFastArmor OPTIONAL, 1473 -- Contains the armor that identifies the armor key. 1474 -- MUST be present in AS-REQ. 1475 req-checksum [1] Checksum, 1476 -- For AS, contains the checksum performed over the type 1477 -- KDC-REQ-BODY for the req-body field of the KDC-REQ 1478 -- structure; 1479 -- For TGS, contains the checksum performed over the type 1480 -- AP-REQ in the PA-TGS-REQ padata. 1481 -- The checksum key is the armor key, the checksum 1482 -- type is the required checksum type for the enctype of 1483 -- the armor key, and the key usage number is 1484 -- KEY_USAGE_FAST_REQ_CHKSUM. 1485 enc-fast-req [2] EncryptedData, -- KrbFastReq -- 1486 -- The encryption key is the armor key, and the key usage 1487 -- number is KEY_USAGE_FAST_ENC. 1488 ... 1489 } 1490 1491 KEY_USAGE_FAST_REQ_CHKSUM 50 1492 KEY_USAGE_FAST_ENC 51 1493 1494 The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type. 1495 The KrbFastArmoredReq encapsulates the encrypted padata. 1496 1497 The enc-fast-req field contains an encrypted KrbFastReq structure. 1498 The armor key is used to encrypt the KrbFastReq structure, and the 1499 key usage number for that encryption is KEY_USAGE_FAST_ENC. 1500 1501 The armor key is selected as follows: 1502 1503 o In an AS request, the armor field in the KrbFastArmoredReq 1504 structure MUST be present and the armor key is identified 1505 according to the specification of the armor type. 1506 1507 1508 1509 1510 1511 1512 1513 1514Hartman & Zhu Standards Track [Page 27] 1515 1516RFC 6113 Kerberos Preauth Framework April 2011 1517 1518 1519 o There are two possibilities for armor for a TGS request. If the 1520 ticket presented in the PA-TGS-REQ authenticator is a TGT, then 1521 the client SHOULD NOT include the armor field in the Krbfastreq 1522 and a subkey MUST be included in the PA-TGS-REQ authenticator. In 1523 this case, the armor key is the same armor key that would be 1524 computed if the TGS-REQ authenticator was used in an 1525 FX_FAST_ARMOR_AP_REQUEST armor. Clients MAY present a non-TGT in 1526 the PA-TGS-REQ authenticator and omit the armor field, in which 1527 case the armor key is the same that would be computed if the 1528 authenticator were used in an FX_FAST_ARMOR_AP_REQUEST armor. 1529 This is the only case where a ticket other than a TGT can be used 1530 to establish an armor key; even though the armor key is computed 1531 the same as an FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used 1532 as an armor ticket in FX_FAST_ARMOR_AP_REQUEST. Alternatively, a 1533 client MAY use an armor type defined in the future for use with 1534 the TGS request. 1535 1536 The req-checksum field contains a checksum computed differently for 1537 AS and TGS. For an AS-REQ, it is performed over the type KDC-REQ- 1538 BODY for the req-body field of the KDC-REQ structure of the 1539 containing message; for a TGS-REQ, it is performed over the type AP- 1540 REQ in the PA-TGS-REQ padata of the TGS request. The checksum key is 1541 the armor key, and the checksum type is the required checksum type 1542 for the enctype of the armor key per [RFC3961]. This checksum MUST 1543 be a keyed checksum and it is included in order to bind the FAST 1544 padata to the outer request. A KDC that implements FAST will ignore 1545 the outer request, but including a checksum is relatively cheap and 1546 may prevent confusing behavior. 1547 1548 The KrbFastReq structure contains the following information: 1549 1550 KrbFastReq ::= SEQUENCE { 1551 fast-options [0] FastOptions, 1552 -- Additional options. 1553 padata [1] SEQUENCE OF PA-DATA, 1554 -- padata typed holes. 1555 req-body [2] KDC-REQ-BODY, 1556 -- Contains the KDC request body as defined in Section 1557 -- 5.4.1 of [RFC4120]. 1558 -- This req-body field is preferred over the outer field 1559 -- in the KDC request. 1560 ... 1561 } 1562 1563 1564 1565 1566 1567 1568 1569 1570Hartman & Zhu Standards Track [Page 28] 1571 1572RFC 6113 Kerberos Preauth Framework April 2011 1573 1574 1575 The fast-options field indicates various options that are to modify 1576 the behavior of the KDC. The following options are defined: 1577 1578 FastOptions ::= KerberosFlags 1579 -- reserved(0), 1580 -- hide-client-names(1), 1581 1582 Bits Name Description 1583 ----------------------------------------------------------------- 1584 0 RESERVED Reserved for future expansion of this 1585 field. 1586 1 hide-client-names Requesting the KDC to hide client 1587 names in the KDC response, as 1588 described next in this section. 1589 16 kdc-follow-referrals reserved [REFERRALS]. 1590 1591 Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are 1592 critical options. If the KDC does not support a critical option, it 1593 MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and 1594 there is no accompanying e-data defined in this document for this 1595 error code. Bit 16 and onward (with bit 16 included) are non- 1596 critical options. KDCs conforming to this specification ignore 1597 unknown non-critical options. 1598 1599 KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS 93 1600 1601 The hide-client-names Option 1602 1603 The Kerberos response defined in [RFC4120] contains the client 1604 identity in cleartext. This makes traffic analysis 1605 straightforward. The hide-client-names option is designed to 1606 complicate traffic analysis. If the hide-client-names option is 1607 set, the KDC implementing PA-FX-FAST MUST identify the client as 1608 the anonymous principal [RFC6112] in the KDC reply and the error 1609 response. Hence, this option is set by the client if it wishes to 1610 conceal the client identity in the KDC response. A conforming KDC 1611 ignores the client principal name in the outer KDC-REQ-BODY field, 1612 and identifies the client using the cname and crealm fields in the 1613 req-body field of the KrbFastReq structure. 1614 1615 The kdc-follow-referrals Option 1616 1617 This option is reserved for [REFERRALS]. 1618 1619 1620 1621 1622 1623 1624 1625 1626Hartman & Zhu Standards Track [Page 29] 1627 1628RFC 6113 Kerberos Preauth Framework April 2011 1629 1630 1631 The padata field contains a list of PA-DATA structures as described 1632 in Section 5.2.7 of [RFC4120]. These PA-DATA structures can contain 1633 FAST factors. They can also be used as generic typed-holes to 1634 contain data not intended for proving the client's identity or 1635 establishing a reply key, but for protocol extensibility. If the KDC 1636 supports the PA-FX-FAST-REQUEST padata, unless otherwise specified, 1637 the client MUST place any padata that is otherwise in the outer KDC 1638 request body into this field. In a TGS request, PA-TGS-REQ padata is 1639 not included in this field and it is present in the outer KDC request 1640 body. 1641 1642 The KDC-REQ-BODY in the FAST structure is used in preference to the 1643 KDC-REQ-BODY outside of the FAST pre-authentication. The outer KDC- 1644 REQ-BODY structure SHOULD be filled in for backwards compatibility 1645 with KDCs that do not support FAST. A conforming KDC ignores the 1646 outer KDC-REQ-BODY field in the KDC request. Pre-authentication data 1647 methods such as [RFC4556] that include a checksum of the KDC-REQ-BODY 1648 should checksum the KDC-REQ-BODY in the FAST structure. 1649 1650 In a TGS request, a client MAY include the AD-fx-fast-used authdata 1651 either in the pa-tgs-req authenticator or in the authorization data 1652 in the pa-tgs-req ticket. If the KDC receives this authorization 1653 data but does not find a FAST padata, then it MUST return 1654 KRB_APP_ERR_MODIFIED. 1655 16565.4.3. FAST Response 1657 1658 The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST 1659 padata element in the KDC reply. In the case of an error, the PA-FX- 1660 FAST padata is included in the KDC responses according to 1661 Section 5.4.4. 1662 1663 The corresponding padata-value field [RFC4120] for the PA-FX-FAST in 1664 the KDC response contains the DER encoding of the ASN.1 type PA-FX- 1665 FAST-REPLY. 1666 1667 PA-FX-FAST-REPLY ::= CHOICE { 1668 armored-data [0] KrbFastArmoredRep, 1669 ... 1670 } 1671 1672 KrbFastArmoredRep ::= SEQUENCE { 1673 enc-fast-rep [0] EncryptedData, -- KrbFastResponse -- 1674 -- The encryption key is the armor key in the request, and 1675 -- the key usage number is KEY_USAGE_FAST_REP. 1676 ... 1677 } 1678 KEY_USAGE_FAST_REP 52 1679 1680 1681 1682Hartman & Zhu Standards Track [Page 30] 1683 1684RFC 6113 Kerberos Preauth Framework April 2011 1685 1686 1687 The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep 1688 structure. The KrbFastArmoredRep structure encapsulates the padata 1689 in the KDC reply in the encrypted form. The KrbFastResponse is 1690 encrypted with the armor key used in the corresponding request, and 1691 the key usage number is KEY_USAGE_FAST_REP. 1692 1693 The Kerberos client MUST support a local policy that rejects the 1694 response if PA-FX-FAST-REPLY is not included in the response. 1695 Clients MAY also support policies that fall back to other mechanisms 1696 or that do not use pre-authentication when FAST is unavailable. It 1697 is important to consider the potential downgrade attacks when 1698 deploying such a policy. 1699 1700 The KrbFastResponse structure contains the following information: 1701 1702 KrbFastResponse ::= SEQUENCE { 1703 padata [0] SEQUENCE OF PA-DATA, 1704 -- padata typed holes. 1705 strengthen-key [1] EncryptionKey OPTIONAL, 1706 -- This, if present, strengthens the reply key for AS and 1707 -- TGS. MUST be present for TGS. 1708 -- MUST be absent in KRB-ERROR. 1709 finished [2] KrbFastFinished OPTIONAL, 1710 -- Present in AS or TGS reply; absent otherwise. 1711 nonce [3] UInt32, 1712 -- Nonce from the client request. 1713 ... 1714 } 1715 1716 The padata field in the KrbFastResponse structure contains a list of 1717 PA-DATA structures as described in Section 5.2.7 of [RFC4120]. These 1718 PA-DATA structures are used to carry data advancing the exchange 1719 specific for the FAST factors. They can also be used as generic 1720 typed-holes for protocol extensibility. Unless otherwise specified, 1721 the KDC MUST include any padata that are otherwise in the outer KDC- 1722 REP or KDC-ERROR structure into this field. The padata field in the 1723 KDC reply structure outside of the PA-FX-FAST-REPLY structure 1724 typically includes only the PA-FX-FAST-REPLY padata. 1725 1726 The strengthen-key field provides a mechanism for the KDC to 1727 strengthen the reply key. If set, the strengthen-key value MUST be 1728 randomly generated to have the same etype as that of the reply key 1729 before being strengthened, and then the reply key is strengthened 1730 after all padata items are processed. Let padata-reply-key be the 1731 reply key after padata processing. 1732 1733 reply-key = KRB-FX-CF2(strengthen-key, padata-reply-key, 1734 "strengthenkey", "replykey") 1735 1736 1737 1738Hartman & Zhu Standards Track [Page 31] 1739 1740RFC 6113 Kerberos Preauth Framework April 2011 1741 1742 1743 The strengthen-key field MAY be set in an AS reply; it MUST be set in 1744 a TGS reply; it must be absent in an error reply. The strengthen key 1745 is required in a TGS reply so that an attacker cannot remove the FAST 1746 PADATA from a TGS reply, causing the KDC to appear not to support 1747 FAST. 1748 1749 The finished field contains a KrbFastFinished structure. It is 1750 filled by the KDC in the final message in the conversation. This 1751 field is present in an AS-REP or a TGS-REP when a ticket is returned, 1752 and it is not present in an error reply. 1753 1754 The KrbFastFinished structure contains the following information: 1755 1756 KrbFastFinished ::= SEQUENCE { 1757 timestamp [0] KerberosTime, 1758 usec [1] Microseconds, 1759 -- timestamp and usec represent the time on the KDC when 1760 -- the reply was generated. 1761 crealm [2] Realm, 1762 cname [3] PrincipalName, 1763 -- Contains the client realm and the client name. 1764 ticket-checksum [4] Checksum, 1765 -- checksum of the ticket in the KDC-REP using the armor 1766 -- and the key usage is KEY_USAGE_FAST_FINISH. 1767 -- The checksum type is the required checksum type 1768 -- of the armor key. 1769 ... 1770 } 1771 KEY_USAGE_FAST_FINISHED 53 1772 1773 The timestamp and usec fields represent the time on the KDC when the 1774 reply ticket was generated, these fields have the same semantics as 1775 the corresponding identically named fields in Section 5.6.1 of 1776 [RFC4120]. The client MUST use the KDC's time in these fields 1777 thereafter when using the returned ticket. The client need not 1778 confirm that the timestamp returned is within allowable clock skew: 1779 the armor key guarantees that the reply is fresh. The client MAY 1780 trust the timestamp returned. 1781 1782 The cname and crealm fields identify the authenticated client. If 1783 facilities described in [REFERRALS] are used, the authenticated 1784 client may differ from the client in the FAST request. 1785 1786 The ticket-checksum is a checksum of the issued ticket. The checksum 1787 key is the armor key, and the checksum type is the required checksum 1788 type of the enctype of that key, and the key usage number is 1789 KEY_USAGE_FAST_FINISHED. 1790 1791 1792 1793 1794Hartman & Zhu Standards Track [Page 32] 1795 1796RFC 6113 Kerberos Preauth Framework April 2011 1797 1798 1799 When FAST padata is included, the PA-FX-COOKIE padata as defined in 1800 Section 5.2 MUST be included in the padata sequence in the 1801 KrbFastResponse sequence if the KDC expects at least one more message 1802 from the client in order to complete the authentication. 1803 1804 The nonce field in the KrbFastResponse contains the value of the 1805 nonce field in the KDC-REQ of the corresponding client request and it 1806 binds the KDC response with the client request. The client MUST 1807 verify that this nonce value in the reply matches with that of the 1808 request and reject the KDC reply otherwise. To prevent the response 1809 from one message in a conversation from being replayed to a request 1810 in another message, clients SHOULD use a new nonce for each message 1811 in a conversation. 1812 18135.4.4. Authenticated Kerberos Error Messages Using Kerberos FAST 1814 1815 If the Kerberos FAST padata was included in the request, unless 1816 otherwise specified, the e-data field of the KRB-ERROR message 1817 [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA 1818 [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA. The KDC 1819 MUST include all the padata elements such as PA-ETYPE-INFO2 and 1820 padata elements that indicate acceptable pre-authentication 1821 mechanisms [RFC4120] in the KrbFastResponse structure. 1822 1823 The KDC MUST also include a PA-FX-ERROR padata item in the 1824 KRBFastResponse structure. The padata-value element of this sequence 1825 is the ASN.1 DER encoding of the type KRB-ERROR. The e-data field 1826 MUST be absent in the PA-FX-ERROR padata. All other fields should be 1827 the same as the outer KRB-ERROR. The client ignores the outer error 1828 and uses the combination of the padata in the KRBFastResponse and the 1829 error information in the PA-FX-ERROR. 1830 1831 PA-FX-ERROR 137 1832 1833 If the Kerberos FAST padata is included in the request but not 1834 included in the error reply, it is a matter of the local policy on 1835 the client to accept the information in the error message without 1836 integrity protection. However, the client SHOULD process the KDC 1837 errors as the result of the KDC's inability to accept the AP_REQ 1838 armor and potentially retry another request with a different armor 1839 when applicable. The Kerberos client MAY process an error message 1840 without a PA-FX-FAST-REPLY, if that is only intended to return better 1841 error information to the application, typically for trouble-shooting 1842 purposes. 1843 1844 In the cases where the e-data field of the KRB-ERROR message is 1845 expected to carry a TYPED-DATA [RFC4120] element, that information 1846 should be transmitted in a pa-data element within the KRBFastResponse 1847 1848 1849 1850Hartman & Zhu Standards Track [Page 33] 1851 1852RFC 6113 Kerberos Preauth Framework April 2011 1853 1854 1855 structure. The padata-type is the same as the data-type would be in 1856 the typed data element and the padata-value is the same as the data- 1857 value. As discussed in Section 7, data-types and padata-types are 1858 drawn from the same namespace. For example, the 1859 TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR 1860 message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE 1861 [RFC4556]. 1862 18635.4.5. Outer and Inner Requests 1864 1865 Typically, a client will know that FAST is being used before a 1866 request containing PA-FX-FAST is sent. So, the outer AS request 1867 typically only includes one pa-data item: PA-FX-FAST. The client MAY 1868 include additional pa-data, but the KDC MUST ignore the outer request 1869 body and any padata besides PA-FX-FAST if and only if PA-FX-FAST is 1870 processed. In the case of the TGS request, the outer request should 1871 include PA-FX-FAST and PA-TGS-REQ. 1872 1873 When an AS generates a response, all padata besides PA-FX-FAST should 1874 be included in PA-FX-FAST. The client MUST ignore other padata 1875 outside of PA-FX-FAST. 1876 18775.4.6. The Encrypted Challenge FAST Factor 1878 1879 The encrypted challenge FAST factor authenticates a client using the 1880 client's long-term key. This factor works similarly to the encrypted 1881 timestamp pre-authentication option described in [RFC4120]. The word 1882 "challenge" is used instead of "timestamp" because while the 1883 timestamp is used as an initial challenge, if the KDC and client do 1884 not have synchronized time, then the KDC can provide updated time to 1885 the client to use as a challenge. The client encrypts a structure 1886 containing a timestamp in the challenge key. The challenge key used 1887 by the client to send a message to the KDC is KRB-FX- 1888 CF2(armor_key,long_term_key, "clientchallengearmor", 1889 "challengelongterm"). The challenge key used by the KDC encrypting 1890 to the client is KRB-FX-CF2(armor_key, long_term_key, 1891 "kdcchallengearmor", "challengelongterm"). Because the armor key is 1892 fresh and random, the challenge key is fresh and random. The only 1893 purpose of the timestamp is to limit the validity of the 1894 authentication so that a request cannot be replayed. A client MAY 1895 base the timestamp on the KDC time in a KDC error and need not 1896 maintain accurate time synchronization itself. If a client bases its 1897 time on an untrusted source, an attacker may trick the client into 1898 producing an authentication request that is valid at some future 1899 time. The attacker may be able to use this authentication request to 1900 make it appear that a client has authenticated at that future time. 1901 If ticket-based armor is used, then the lifetime of the ticket will 1902 limit the window in which an attacker can make the client appear to 1903 1904 1905 1906Hartman & Zhu Standards Track [Page 34] 1907 1908RFC 6113 Kerberos Preauth Framework April 2011 1909 1910 1911 have authenticated. For many situations, the ability of an attacker 1912 to cause a client to appear to have authenticated is not a 1913 significant concern; the ability to avoid requiring time 1914 synchronization on clients is more valuable. 1915 1916 The client sends a padata of type PA-ENCRYPTED-CHALLENGE. The 1917 corresponding padata-value contains the DER encoding of ASN.1 type 1918 EncryptedChallenge. 1919 1920 EncryptedChallenge ::= EncryptedData 1921 -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key 1922 -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the 1923 -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC. 1924 1925 PA-ENCRYPTED-CHALLENGE 138 1926 KEY_USAGE_ENC_CHALLENGE_CLIENT 54 1927 KEY_USAGE_ENC_CHALLENGE_KDC 55 1928 1929 The client includes some timestamp reasonably close to the KDC's 1930 current time and encrypts it in the challenge key in a PA-ENC-TS-ENC 1931 structure (see Section 5.2.7.2 in RFC 4120). Clients MAY use the 1932 current time; doing so prevents the exposure where an attacker can 1933 cause a client to appear to authenticate in the future. The client 1934 sends the request including this factor. 1935 1936 On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE FAST 1937 factor, the KDC decrypts the timestamp. If the decryption fails the 1938 KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in 1939 the KRBFastResponse in the error. The KDC confirms that the 1940 timestamp falls within its current clock skew returning 1941 KRB_APP_ERR_SKEW if not. The KDC then SHOULD check to see if the 1942 encrypted challenge is a replay. The KDC MUST NOT consider two 1943 encrypted challenges replays simply because the timestamps are the 1944 same; to be a replay, the ciphertext MUST be identical. Allowing 1945 clients to reuse timestamps avoids requiring that clients maintain 1946 state about which timestamps have been used. 1947 1948 If the KDC accepts the encrypted challenge, it MUST include a padata 1949 element of type PA-ENCRYPTED-CHALLENGE. The KDC encrypts its current 1950 time in the challenge key. The KDC MUST strengthen the reply key 1951 before issuing a ticket. The client MUST check that the timestamp 1952 decrypts properly. The client MAY check that the timestamp is within 1953 the window of acceptable clock skew for the client. The client MUST 1954 NOT require that the timestamp be identical to the timestamp in the 1955 issued credentials or the returned message. 1956 1957 1958 1959 1960 1961 1962Hartman & Zhu Standards Track [Page 35] 1963 1964RFC 6113 Kerberos Preauth Framework April 2011 1965 1966 1967 The encrypted challenge FAST factor provides the following 1968 facilities: Client Authentication and KDC Authentication. This FAST 1969 factor also takes advantage of the FAST facility to strengthen the 1970 reply key. It does not provide the Replace Reply Key facility. The 1971 Security Considerations section of this document provides an 1972 explanation why the security requirements are met. 1973 1974 The encrypted challenge FAST factor can be useful in an 1975 authentication set. No pa-hint is defined because the only 1976 information needed by this mechanism is information contained in the 1977 PA-ETYPE-INFO2 pre-authentication data. KDCs are already required to 1978 send PA-ETYPE-INFO2. If KDCs were not required to send PA-ETYPE- 1979 INFO2 then that information would need to be part of a hint for 1980 encrypted challenge. 1981 1982 Conforming implementations MUST support the encrypted challenge FAST 1983 factor. 1984 19855.5. Authentication Strength Indication 1986 1987 Implementations that have pre-authentication mechanisms offering 1988 significantly different strengths of client authentication MAY choose 1989 to keep track of the strength of the authentication used as an input 1990 into policy decisions. For example, some principals might require 1991 strong pre-authentication, while less sensitive principals can use 1992 relatively weak forms of pre-authentication like encrypted timestamp. 1993 1994 An AuthorizationData data type AD-Authentication-Strength is defined 1995 for this purpose. 1996 1997 AD-authentication-strength 70 1998 1999 The corresponding ad-data field contains the DER encoding of the pre- 2000 authentication data set as defined in Section 5.3. This set contains 2001 all the pre-authentication mechanisms that were used to authenticate 2002 the client. If only one pre-authentication mechanism was used to 2003 authenticate the client, the pre-authentication set contains one 2004 element. Unless otherwise specified, the hint and value fields of 2005 the members of this sequence MUST be empty. In order to permit 2006 mechanisms to carry additional information about strength in these 2007 fields in the future, clients and application servers MUST ignore 2008 non-empty hint and value fields for mechanisms unless the 2009 implementation is updated with the interpretation of these fields for 2010 a given pre-authentication mechanism in this authorization element. 2011 2012 The AD-authentication-strength element MUST be included in the AD- 2013 KDC-ISSUED container so that the KDC integrity protects its contents. 2014 This element can be ignored if it is unknown to the receiver. 2015 2016 2017 2018Hartman & Zhu Standards Track [Page 36] 2019 2020RFC 6113 Kerberos Preauth Framework April 2011 2021 2022 20236. Assigned Constants 2024 2025 The pre-authentication framework and FAST involve using a number of 2026 Kerberos protocol constants. This section lists protocol constants 2027 first introduced in this specification drawn from registries not 2028 managed by IANA. Many of these registries would best be managed by 2029 IANA; that is a known issue that is out of scope for this document. 2030 The constants described in this section have been accounted for and 2031 will appear in the next revision of the Kerberos core specification 2032 or in a document creating IANA registries. 2033 2034 Section 7 creates IANA registries for a different set of constants 2035 used by the extensions described in this document. 2036 20376.1. New Errors 2038 2039 KDC_ERR_PREAUTH_EXPIRED 90 2040 KDC_ERR_MORE_PREAUTH_DATA_REQUIRED 91 2041 KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92 2042 KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS 93 2043 20446.2. Key Usage Numbers 2045 2046 KEY_USAGE_FAST_REQ_CHKSUM 50 2047 KEY_USAGE_FAST_ENC 51 2048 KEY_USAGE_FAST_REP 52 2049 KEY_USAGE_FAST_FINISHED 53 2050 KEY_USAGE_ENC_CHALLENGE_CLIENT 54 2051 KEY_USAGE_ENC_CHALLENGE_KDC 55 2052 20536.3. Authorization Data Elements 2054 2055 AD-authentication-strength 70 2056 AD-fx-fast-armor 71 2057 AD-fx-fast-used 72 2058 20596.4. New PA-DATA Types 2060 2061 PA-FX-COOKIE 133 2062 PA-AUTHENTICATION-SET 134 2063 PA-AUTH-SET-SELECTED 135 2064 PA-FX-FAST 136 2065 PA-FX-ERROR 137 2066 PA-ENCRYPTED-CHALLENGE 138 2067 2068 2069 2070 2071 2072 2073 2074Hartman & Zhu Standards Track [Page 37] 2075 2076RFC 6113 Kerberos Preauth Framework April 2011 2077 2078 20797. IANA Considerations 2080 2081 This document creates a number of IANA registries. These registries 2082 are all located under Kerberos Parameters on http://www.iana.org. 2083 See [RFC5226] for descriptions of the registration policies used in 2084 this section. 2085 20867.1. Pre-Authentication and Typed Data 2087 2088 RFC 4120 defines pre-authentication data, which can be included in a 2089 KDC request or response in order to authenticate the client or extend 2090 the protocol. In addition, it defines Typed-Data, which is an 2091 extension mechanism for errors. Both pre-authentication data and 2092 typed data are carried as a 32-bit signed integer along with an octet 2093 string. The encoding of typed data and pre-authentication data is 2094 slightly different. However, the types for pre-authentication data 2095 and typed-data are drawn from the same namespace. By convention, 2096 registrations starting with TD- are typed data and registrations 2097 starting with PA- are pre-authentication data. It is important that 2098 these data types be drawn from the same namespace, because some 2099 errors where it would be desirable to include typed data require the 2100 e-data field to be formatted as pre-authentication data. 2101 2102 When Kerberos FAST is used, pre-authentication data encoding is 2103 always used. 2104 2105 There is one apparently conflicting registration between typed data 2106 and pre-authentication data. PA-GET-FROM-TYPED-DATA and TD-PADATA 2107 are both assigned the value 22. However, this registration is simply 2108 a mechanism to include an element of the other encoding. The use of 2109 both should be deprecated. 2110 2111 This document creates a registry for pre-authentication and typed 2112 data. The registration procedures are as follows. Expert review for 2113 pre-authentication mechanisms designed to authenticate users, KDCs, 2114 or establish the reply key. The expert first determines that the 2115 purpose of the method is to authenticate clients, KDCs, or to 2116 establish the reply key. If so, expert review is appropriate. The 2117 expert evaluates the security and interoperability of the 2118 specification. 2119 2120 IETF review is required if the expert believes that the pre- 2121 authentication method is broader than these three areas. Pre- 2122 authentication methods that change the Kerberos state machine or 2123 otherwise make significant changes to the Kerberos protocol should be 2124 Standards Track RFCs. A concern that a particular method needs to be 2125 a Standards Track RFC may be raised as an objection during IETF 2126 review. 2127 2128 2129 2130Hartman & Zhu Standards Track [Page 38] 2131 2132RFC 6113 Kerberos Preauth Framework April 2011 2133 2134 2135 Several of the registrations indicated below were made at a time when 2136 the Kerberos protocol was less mature and do not meet the current 2137 requirements for this registry. These registrations are included in 2138 order to accurately document what is known about the use of these 2139 protocol code points and to avoid conflicts. 2140 2141 Type Value Reference 2142 ---------------------------------------------------------------------- 2143 PA-TGS-REQ 1 [RFC4120] 2144 PA-ENC-TIMESTAMP 2 [RFC4120] 2145 PA-PW-SALT 3 [RFC4120] 2146 [reserved] 4 [RFC6113] 2147 PA-ENC-UNIX-TIME 5 (deprecated) [RFC4120] 2148 PA-SANDIA-SECUREID 6 [RFC4120] 2149 PA-SESAME 7 [RFC4120] 2150 PA-OSF-DCE 8 [RFC4120] 2151 PA-CYBERSAFE-SECUREID 9 [RFC4120] 2152 PA-AFS3-SALT 10 [RFC4120] [RFC3961] 2153 PA-ETYPE-INFO 11 [RFC4120] 2154 PA-SAM-CHALLENGE 12 [KRB-WG.SAM] 2155 PA-SAM-RESPONSE 13 [KRB-WG.SAM] 2156 PA-PK-AS-REQ_OLD 14 [PK-INIT-1999] 2157 PA-PK-AS-REP_OLD 15 [PK-INIT-1999] 2158 PA-PK-AS-REQ 16 [RFC4556] 2159 PA-PK-AS-REP 17 [RFC4556] 2160 PA-PK-OCSP-RESPONSE 18 [RFC4557] 2161 PA-ETYPE-INFO2 19 [RFC4120] 2162 PA-USE-SPECIFIED-KVNO 20 [RFC4120] 2163 PA-SVR-REFERRAL-INFO 20 [REFERRALS] 2164 PA-SAM-REDIRECT 21 [KRB-WG.SAM] 2165 PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) [RFC4120] 2166 TD-PADATA 22 (embeds padata) [RFC4120] 2167 PA-SAM-ETYPE-INFO 23 (sam/otp) [KRB-WG.SAM] 2168 PA-ALT-PRINC 24 (crawdad@fnal.gov) [HW-AUTH] 2169 PA-SERVER-REFERRAL 25 [REFERRALS] 2170 PA-SAM-CHALLENGE2 30 (kenh@pobox.com) [KRB-WG.SAM] 2171 PA-SAM-RESPONSE2 31 (kenh@pobox.com) [KRB-WG.SAM] 2172 PA-EXTRA-TGT 41 Reserved extra TGT [RFC6113] 2173 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 2174 TD-KRB-PRINCIPAL 102 PrincipalName 2175 TD-KRB-REALM 103 Realm 2176 TD-TRUSTED-CERTIFIERS 104 [RFC4556] 2177 TD-CERTIFICATE-INDEX 105 [RFC4556] 2178 TD-APP-DEFINED-ERROR 106 Application specific [RFC6113] 2179 TD-REQ-NONCE 107 INTEGER [RFC6113] 2180 TD-REQ-SEQ 108 INTEGER [RFC6113] 2181 TD_DH_PARAMETERS 109 [RFC4556] 2182 TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY] 2183 2184 2185 2186Hartman & Zhu Standards Track [Page 39] 2187 2188RFC 6113 Kerberos Preauth Framework April 2011 2189 2190 2191 TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY] 2192 PA-PAC-REQUEST 128 [MS-KILE] 2193 PA-FOR_USER 129 [MS-KILE] 2194 PA-FOR-X509-USER 130 [MS-KILE] 2195 PA-FOR-CHECK_DUPS 131 [MS-KILE] 2196 PA-AS-CHECKSUM 132 [MS-KILE] 2197 PA-FX-COOKIE 133 [RFC6113] 2198 PA-AUTHENTICATION-SET 134 [RFC6113] 2199 PA-AUTH-SET-SELECTED 135 [RFC6113] 2200 PA-FX-FAST 136 [RFC6113] 2201 PA-FX-ERROR 137 [RFC6113] 2202 PA-ENCRYPTED-CHALLENGE 138 [RFC6113] 2203 PA-OTP-CHALLENGE 141 (gareth.richards@rsa.com) [OTP-PREAUTH] 2204 PA-OTP-REQUEST 142 (gareth.richards@rsa.com) [OTP-PREAUTH] 2205 PA-OTP-CONFIRM 143 (gareth.richards@rsa.com) [OTP-PREAUTH] 2206 PA-OTP-PIN-CHANGE 144 (gareth.richards@rsa.com) [OTP-PREAUTH] 2207 PA-EPAK-AS-REQ 145 (sshock@gmail.com) [RFC6113] 2208 PA-EPAK-AS-REP 146 (sshock@gmail.com) [RFC6113] 2209 PA_PKINIT_KX 147 [RFC6112] 2210 PA_PKU2U_NAME 148 [PKU2U] 2211 PA-SUPPORTED-ETYPES 165 [MS-KILE] 2212 PA-EXTENDED_ERROR 166 [MS-KILE] 2213 22147.2. Fast Armor Types 2215 2216 FAST armor types are defined in Section 5.4.1. A FAST armor type is 2217 a signed 32-bit integer. FAST armor types are assigned by standards 2218 action. 2219 2220 Type Name Description 2221 ------------------------------------------------------------ 2222 0 Reserved. 2223 1 FX_FAST_ARMOR_AP_REQUEST Ticket armor using an ap-req. 2224 22257.3. FAST Options 2226 2227 A FAST request includes a set of bit flags to indicate additional 2228 options. Bits 0-15 are critical; other bits are non-critical. 2229 Assigning bits greater than 31 may require special support in 2230 implementations. Assignment of FAST options requires standards 2231 action. 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242Hartman & Zhu Standards Track [Page 40] 2243 2244RFC 6113 Kerberos Preauth Framework April 2011 2245 2246 2247 Type Name Description 2248 ------------------------------------------------------------------- 2249 0 RESERVED Reserved for future expansion of this 2250 field. 2251 1 hide-client-names Requesting the KDC to hide client 2252 names in the KDC response 2253 16 kdc-follow-referrals Reserved. 2254 22558. Security Considerations 2256 2257 The kdc-referrals option in the Kerberos FAST padata requests the KDC 2258 to act as the client to follow referrals. This can overload the KDC. 2259 To limit the damages of denial of service using this option, KDCs MAY 2260 restrict the number of simultaneous active requests with this option 2261 for any given client principal. 2262 2263 Regarding the facilities provided by the Encrypted Challenge FAST 2264 factor, the challenge key is derived from the client secrets and 2265 because the client secrets are known only to the client and the KDC, 2266 the verification of the EncryptedChallenge structure proves the 2267 client's identity, the verification of the EncryptedChallenge 2268 structure in the KDC reply proves that the expected KDC responded. 2269 Therefore, the Encrypted Challenge FAST factor as a pre- 2270 authentication mechanism offers the following facilities: Client 2271 Authentication and KDC Authentication. There is no un-authenticated 2272 cleartext introduced by the Encrypted Challenge FAST factor. 2273 2274 FAST provides an encrypted tunnel over which pre-authentication 2275 conversations can take place. In addition, FAST optionally 2276 authenticates the KDC to the client. It is the responsibility of 2277 FAST factors to authenticate the client to the KDC. Care MUST be 2278 taken to design FAST factors such that they are bound to the 2279 conversation. If this is not done, a man-in-the-middle may be able 2280 to cut&paste a FAST factor from one conversation to another. The 2281 easiest way to do this is to bind each FAST factor to the armor key 2282 that is guaranteed to be unique for each conversation. 2283 2284 The anonymous PKINIT mode for obtaining an armor ticket does not 2285 always authenticate the KDC to the client before the conversation 2286 begins. Tracking the KDC verified state guarantees that by the end 2287 of the conversation, the client has authenticated the KDC. However, 2288 FAST factor designers need to consider the implications of using 2289 their factor when the KDC has not yet been authenticated. If this 2290 proves problematic in an environment, then the particular FAST factor 2291 should not be used with anonymous PKINIT. 2292 2293 Existing pre-authentication mechanisms are believed to be at least as 2294 secure when used with FAST as they are when used outside of FAST. 2295 2296 2297 2298Hartman & Zhu Standards Track [Page 41] 2299 2300RFC 6113 Kerberos Preauth Framework April 2011 2301 2302 2303 One part of this security is making sure that when pre-authentication 2304 methods checksum the request, they checksum the inner request rather 2305 than the outer request. If the mechanism checksummed the outer 2306 request, a man-in-the-middle could observe it outside a FAST tunnel 2307 and then cut&paste it into a FAST exchange where the inner rather 2308 than outer request would be used to select attributes of the issued 2309 ticket. Such attacks would typically invalidate auditing information 2310 or create a situation where the client and KDC disagree about what 2311 ticket is issued. However, such attacks are unlikely to allow an 2312 attacker who would not be able to authenticate as a principal to do 2313 so. Even so, FAST is believed to defend against these attacks in 2314 existing legacy mechanism. However, since there is no standard for 2315 how legacy mechanisms bind the request to the pre-authentication or 2316 provide integrity protection, security analysis can be difficult. In 2317 some cases, FAST may significantly improve the integrity protection 2318 of legacy mechanisms. 2319 2320 The security of the TGS exchange depends on authenticating the client 2321 to the KDC. In the AS exchange, this is done using pre- 2322 authentication data or FAST factors. In the TGS exchange, this is 2323 done by presenting a TGT and by using the session (or sub-session) 2324 key in constructing the request. Because FAST uses a request body in 2325 the inner request, encrypted in the armor key, rather than the 2326 request body in the outer request, it is critical that establishing 2327 the armor key be tied to the authentication of the client to the KDC. 2328 If this is not done, an attacker could manipulate the options 2329 requested in the TGS request, for example, requesting a ticket with 2330 different validity or addresses. The easiest way to bind the armor 2331 key to the authentication of the client to the KDC is for the armor 2332 key to depend on the sub-session key of the TGT. This is done with 2333 the implicit TGS armor supported by this specification. Future armor 2334 types designed for use with the TGS MUST either bind their armor keys 2335 to the TGT or provide another mechanism to authenticate the client to 2336 the KDC. 2337 23389. Acknowledgements 2339 2340 Sam Hartman would like to thank the MIT Kerberos Consortium for its 2341 funding of his time on this project. 2342 2343 Several suggestions from Jeffrey Hutzelman based on early revisions 2344 of this documents led to significant improvements of this document. 2345 2346 The proposal to ask one KDC to chase down the referrals and return 2347 the final ticket is based on requirements in [CROSS]. 2348 2349 Joel Weber had a proposal for a mechanism similar to FAST that 2350 created a protected tunnel for Kerberos pre-authentication. 2351 2352 2353 2354Hartman & Zhu Standards Track [Page 42] 2355 2356RFC 6113 Kerberos Preauth Framework April 2011 2357 2358 2359 Srinivas Cheruku and Greg Hudson provided valuable review comments. 2360 236110. References 2362 236310.1. Normative References 2364 2365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2366 Requirement Levels", BCP 14, RFC 2119, March 1997. 2367 2368 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications 2369 for Kerberos 5", RFC 3961, February 2005. 2370 2371 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 2372 Kerberos Network Authentication Service (V5)", 2373 RFC 4120, July 2005. 2374 2375 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for 2376 Initial Authentication in Kerberos (PKINIT)", 2377 RFC 4556, June 2006. 2378 2379 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 2380 an IANA Considerations Section in RFCs", BCP 26, 2381 RFC 5226, May 2008. 2382 2383 [RFC6112] Zhu, L., Leach, P., and S. Hartman "Anonymity Support 2384 for Kerberos", RFC 6112, April 2011. 2385 238610.2. Informative References 2387 2388 [ALG-AGILITY] Astrand, L. and L. Zhu, "PK-INIT algorithm agility", 2389 Work in Progress, August 2008. 2390 2391 [CROSS] Sakane, S., Zrelli, S., and M. Ishiyama , "Problem 2392 statement on the cross-realm operation of Kerberos in 2393 a specific system", Work in Progress, July 2007. 2394 2395 [EKE] Bellovin, S. and M. Merritt, "Augmented Encrypted Key 2396 Exchange: A Password-Based Protocol Secure Against 2397 Dictionary Attacks and Password File Compromise, 2398 Proceedings of the 1st ACM Conference on Computer and 2399 Communications Security, ACM Press.", November 1993. 2400 2401 [HW-AUTH] Crawford, M., "Passwordless Initial Authentication to 2402 Kerberos by Hardware Preauthentication", Work 2403 in Progress, October 2006. 2404 2405 [IEEE1363.2] IEEE, "IEEE P1363.2: Password-Based Public-Key 2406 Cryptography", 2004. 2407 2408 2409 2410Hartman & Zhu Standards Track [Page 43] 2411 2412RFC 6113 Kerberos Preauth Framework April 2011 2413 2414 2415 [KRB-WG.SAM] Hornstein, K., Renard, K., Neuman, C., and G. Zorn, 2416 "Integrating Single-use Authentication Mechanisms 2417 with Kerberos", Work in Progress, July 2004. 2418 2419 [MS-KILE] Microsoft, "Kerberos Protocol Extensions", <http:// 2420 msdn.microsoft.com/en-us/library/cc206927.aspx>. 2421 2422 [OTP-PREAUTH] Richards, G., "OTP Pre-authentication", Work 2423 in Progress, February 2011. 2424 2425 [PK-INIT-1999] Tung, B., Neuman, C., Hur, M., Medvinsky, A., 2426 Medvinsky, S., Wray, J., and J. Trostle, "Public Key 2427 Cryptography for Initial Authentication in Kerberos", 2428 Work in Progress, July 1999. 2429 2430 [PKU2U] Zhu, L., Altman, J., and N. Williams, "Public Key 2431 Cryptography Based User-to-User Authentication - 2432 (PKU2U)", Work in Progress, November 2008. 2433 2434 [REFERRALS] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos 2435 Principal Name Canonicalization and KDC-Generated 2436 Cross-Realm Referrals", Work in Progress, March 2011. 2437 2438 [RFC4557] Zhu, L., Jaganathan, K., and N. Williams, "Online 2439 Certificate Status Protocol (OCSP) Support for Public 2440 Key Cryptography for Initial Authentication in 2441 Kerberos (PKINIT)", RFC 4557, June 2006. 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466Hartman & Zhu Standards Track [Page 44] 2467 2468RFC 6113 Kerberos Preauth Framework April 2011 2469 2470 2471Appendix A. Test Vectors for KRB-FX-CF2 2472 2473 This informative appendix presents test vectors for the KRB-FX-CF2 2474 function. Test vectors are presented for several encryption types. 2475 In all cases, the first key (k1) is the result of string-to- 2476 key("key1", "key1", default_parameters) and the second key (k2) is 2477 the result of string-to-key("key2", "key2", default_parameters). 2478 Both keys are of the same enctype. The presented test vector is the 2479 hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a", 2480 "b"). The peppers are one-octet ASCII strings. 2481 2482 In performing interoperability testing, there was significant 2483 ambiguity surrounding [RFC3961] pseudo-random operations. These test 2484 vectors assume that the AES pseudo-random operation is 2485 aes-ecb(trunc128(sha-1(input))) where trunc128 truncates its input to 2486 128 bits. The 3DES pseudo-random operation is assumed to be 2487 des3-cbc(trunc128(sha-1(input))). The DES pseudo-random operation is 2488 assumed to be des-cbc(md5(input)). As specified in RFC 4757, the RC4 2489 pseudo-random operation is hmac-sha1(input). 2490 2491 Interoperability testing also demonstrated ambiguity surrounding the 2492 DES random-to-key operation. The random-to-key operation is assumed 2493 to be distribute 56 bits into high-7-bits of 8 octets and generate 2494 parity. 2495 2496 These test vectors were produced with revision 22359 of the MIT 2497 Kerberos sources. The AES 256 and AES 128 test vectors have been 2498 confirmed by multiple other implementors. The RC4 test vectors have 2499 been confirmed by one other implementor. The DES and triple DES test 2500 vectors have not been confirmed. 2501 2502 aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a 2503 AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566 2504 b9617ae3a96868c337cb93b5e72b1c7b 2505 DES (enctype 1): 43bae3738c9467e6 2506 3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01 2507 RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522Hartman & Zhu Standards Track [Page 45] 2523 2524RFC 6113 Kerberos Preauth Framework April 2011 2525 2526 2527Appendix B. ASN.1 Module 2528 2529 KerberosPreauthFramework { 2530 iso(1) identified-organization(3) dod(6) internet(1) 2531 security(5) kerberosV5(2) modules(4) preauth-framework(3) 2532 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 2533 2534 IMPORTS 2535 KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum, 2536 Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY, 2537 Microseconds, KerberosFlags, UInt32 2538 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 2539 dod(6) internet(1) security(5) kerberosV5(2) 2540 modules(4) krb5spec2(2) }; 2541 -- as defined in RFC 4120. 2542 2543 PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM 2544 2545 PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE { 2546 pa-type [0] Int32, 2547 -- same as padata-type. 2548 pa-hint [1] OCTET STRING OPTIONAL, 2549 pa-value [2] OCTET STRING OPTIONAL, 2550 ... 2551 } 2552 2553 KrbFastArmor ::= SEQUENCE { 2554 armor-type [0] Int32, 2555 -- Type of the armor. 2556 armor-value [1] OCTET STRING, 2557 -- Value of the armor. 2558 ... 2559 } 2560 2561 PA-FX-FAST-REQUEST ::= CHOICE { 2562 armored-data [0] KrbFastArmoredReq, 2563 ... 2564 } 2565 2566 KrbFastArmoredReq ::= SEQUENCE { 2567 armor [0] KrbFastArmor OPTIONAL, 2568 -- Contains the armor that identifies the armor key. 2569 -- MUST be present in AS-REQ. 2570 req-checksum [1] Checksum, 2571 -- For AS, contains the checksum performed over the type 2572 -- KDC-REQ-BODY for the req-body field of the KDC-REQ 2573 -- structure; 2574 -- For TGS, contains the checksum performed over the type 2575 2576 2577 2578Hartman & Zhu Standards Track [Page 46] 2579 2580RFC 6113 Kerberos Preauth Framework April 2011 2581 2582 2583 -- AP-REQ in the PA-TGS-REQ padata. 2584 -- The checksum key is the armor key, the checksum 2585 -- type is the required checksum type for the enctype of 2586 -- the armor key, and the key usage number is 2587 -- KEY_USAGE_FAST_REQ_CHKSUM. 2588 enc-fast-req [2] EncryptedData, -- KrbFastReq -- 2589 -- The encryption key is the armor key, and the key usage 2590 -- number is KEY_USAGE_FAST_ENC. 2591 ... 2592 } 2593 2594 KrbFastReq ::= SEQUENCE { 2595 fast-options [0] FastOptions, 2596 -- Additional options. 2597 padata [1] SEQUENCE OF PA-DATA, 2598 -- padata typed holes. 2599 req-body [2] KDC-REQ-BODY, 2600 -- Contains the KDC request body as defined in Section 2601 -- 5.4.1 of [RFC4120]. 2602 -- This req-body field is preferred over the outer field 2603 -- in the KDC request. 2604 ... 2605 } 2606 2607 FastOptions ::= KerberosFlags 2608 -- reserved(0), 2609 -- hide-client-names(1), 2610 -- kdc-follow-referrals(16) 2611 2612 PA-FX-FAST-REPLY ::= CHOICE { 2613 armored-data [0] KrbFastArmoredRep, 2614 ... 2615 } 2616 2617 KrbFastArmoredRep ::= SEQUENCE { 2618 enc-fast-rep [0] EncryptedData, -- KrbFastResponse -- 2619 -- The encryption key is the armor key in the request, and 2620 -- the key usage number is KEY_USAGE_FAST_REP. 2621 ... 2622 } 2623 2624 KrbFastResponse ::= SEQUENCE { 2625 padata [0] SEQUENCE OF PA-DATA, 2626 -- padata typed holes. 2627 strengthen-key [1] EncryptionKey OPTIONAL, 2628 -- This, if present, strengthens the reply key for AS and 2629 -- TGS. MUST be present for TGS 2630 -- MUST be absent in KRB-ERROR. 2631 2632 2633 2634Hartman & Zhu Standards Track [Page 47] 2635 2636RFC 6113 Kerberos Preauth Framework April 2011 2637 2638 2639 finished [2] KrbFastFinished OPTIONAL, 2640 -- Present in AS or TGS reply; absent otherwise. 2641 nonce [3] UInt32, 2642 -- Nonce from the client request. 2643 ... 2644 } 2645 2646 KrbFastFinished ::= SEQUENCE { 2647 timestamp [0] KerberosTime, 2648 usec [1] Microseconds, 2649 -- timestamp and usec represent the time on the KDC when 2650 -- the reply was generated. 2651 crealm [2] Realm, 2652 cname [3] PrincipalName, 2653 -- Contains the client realm and the client name. 2654 ticket-checksum [4] Checksum, 2655 -- checksum of the ticket in the KDC-REP using the armor 2656 -- and the key usage is KEY_USAGE_FAST_FINISH. 2657 -- The checksum type is the required checksum type 2658 -- of the armor key. 2659 ... 2660 } 2661 2662 EncryptedChallenge ::= EncryptedData 2663 -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key 2664 -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the 2665 -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC. 2666 END 2667 2668Authors' Addresses 2669 2670 Sam Hartman 2671 Painless Security 2672 2673 EMail: hartmans-ietf@mit.edu 2674 2675 2676 Larry Zhu 2677 Microsoft Corporation 2678 One Microsoft Way 2679 Redmond, WA 98052 2680 US 2681 2682 EMail: larry.zhu@microsoft.com 2683 2684 2685 2686 2687 2688 2689 2690Hartman & Zhu Standards Track [Page 48] 2691 2692