1 2 3Kerberos Working Group L. Zhu 4Internet-Draft Microsoft Corporation 5Updates: 4120 (if approved) S. Hartman 6Intended status: Standards Track MIT 7Expires: April 28, 2007 October 25, 2006 8 9 10 A Generalized Framework for Kerberos Pre-Authentication 11 draft-ietf-krb-wg-preauth-framework-04 12 13Status of this Memo 14 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 24 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 29 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 36 This Internet-Draft will expire on April 28, 2007. 37 38Copyright Notice 39 40 Copyright (C) The Internet Society (2006). 41 42Abstract 43 44 Kerberos is a protocol for verifying the identity of principals 45 (e.g., a workstation user or a network server) on an open network. 46 The Kerberos protocol provides a mechanism called pre-authentication 47 for proving the identity of a principal and for better protecting the 48 long-term secret of the principal. 49 50 This document describes a model for Kerberos pre-authentication 51 52 53 54Zhu & Hartman Expires April 28, 2007 [Page 1] 55 56Internet-Draft Kerberos Preauth Framework October 2006 57 58 59 mechanisms. The model describes what state in the Kerberos request a 60 pre-authentication mechanism is likely to change. It also describes 61 how multiple pre-authentication mechanisms used in the same request 62 will interact. 63 64 This document also provides common tools needed by multiple pre- 65 authentication mechanisms. One of such tools is a secure channel 66 between the client and the KDC with a reply key delivery mechanism, 67 this secure channel can be used to protect the authentication 68 exchange thus eliminate offline dictionary attacks. With these 69 tools, it is straightforward to chain multiple authentication factors 70 or add a plugin to, for example, utilize a different key management 71 system, or support a new key agreement algorithm. 72 73 74Table of Contents 75 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 78 3. Model for Pre-Authentication . . . . . . . . . . . . . . . . . 5 79 3.1. Information Managed by the Pre-authentication Model . . . 6 80 3.2. Initial Pre-authentication Required Error . . . . . . . . 8 81 3.3. Client to KDC . . . . . . . . . . . . . . . . . . . . . . 9 82 3.4. KDC to Client . . . . . . . . . . . . . . . . . . . . . . 10 83 4. Pre-Authentication Facilities . . . . . . . . . . . . . . . . 11 84 4.1. Client-authentication Facility . . . . . . . . . . . . . . 12 85 4.2. Strengthening-reply-key Facility . . . . . . . . . . . . . 12 86 4.3. Replacing-reply-key Facility . . . . . . . . . . . . . . . 13 87 4.4. KDC-authentication Facility . . . . . . . . . . . . . . . 14 88 5. Requirements for Pre-Authentication Mechanisms . . . . . . . . 14 89 6. Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15 90 6.1. Combining Keys . . . . . . . . . . . . . . . . . . . . . . 15 91 6.2. Protecting Requests/Responses . . . . . . . . . . . . . . 17 92 6.3. Managing States for the KDC . . . . . . . . . . . . . . . 17 93 6.4. Pre-authentication Set . . . . . . . . . . . . . . . . . . 18 94 6.5. Definition of Kerberos FAST Padata . . . . . . . . . . . . 19 95 6.5.1. FAST Armors . . . . . . . . . . . . . . . . . . . . . 20 96 6.5.2. FAST Request . . . . . . . . . . . . . . . . . . . . . 21 97 6.5.3. FAST Response . . . . . . . . . . . . . . . . . . . . 24 98 6.6. Authentication Strength Indication . . . . . . . . . . . . 27 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 101 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 103 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 104 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 105 Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 28 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 107 108 109 110Zhu & Hartman Expires April 28, 2007 [Page 2] 111 112Internet-Draft Kerberos Preauth Framework October 2006 113 114 115 Intellectual Property and Copyright Statements . . . . . . . . . . 32 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166Zhu & Hartman Expires April 28, 2007 [Page 3] 167 168Internet-Draft Kerberos Preauth Framework October 2006 169 170 1711. Introduction 172 173 The core Kerberos specification [RFC4120] treats pre-authentication 174 data as an opaque typed hole in the messages to the KDC that may 175 influence the reply key used to encrypt the KDC reply. This 176 generality has been useful: pre-authentication data is used for a 177 variety of extensions to the protocol, many outside the expectations 178 of the initial designers. However, this generality makes designing 179 more common types of pre-authentication mechanisms difficult. Each 180 mechanism needs to specify how it interacts with other mechanisms. 181 Also, problems like combining a key with the long-term secret or 182 proving the identity of the user are common to multiple mechanisms. 183 Where there are generally well-accepted solutions to these problems, 184 it is desirable to standardize one of these solutions so mechanisms 185 can avoid duplication of work. In other cases, a modular approach to 186 these problems is appropriated. The modular approach will allow new 187 and better solutions to common pre-authentication problems to be used 188 by existing mechanisms as they are developed. 189 190 This document specifies a framework for Kerberos pre-authentication 191 mechanisms. It defines the common set of functions pre- 192 authentication mechanisms perform as well as how these functions 193 affect the state of the request and reply. In addition several 194 common tools needed by pre-authentication mechanisms are provided. 195 Unlike [RFC3961], this framework is not complete--it does not 196 describe all the inputs and outputs for the pre-authentication 197 mechanisms. Pre-Authentication mechanism designers should try to be 198 consistent with this framework because doing so will make their 199 mechanisms easier to implement. Kerberos implementations are likely 200 to have plugin architectures for pre-authentication; such 201 architectures are likely to support mechanisms that follow this 202 framework plus commonly used extensions. 203 204 One of these common tools is the flexible authentication secure 205 tunneling (FAST) padata. FAST provides a protected channel between 206 the client and the KDC, and it also delivers a reply key within the 207 protected channel. Based on FAST, pre-authentication mechanisms can 208 extend Kerberos with ease, to support, for example, password 209 authenticated key exchange (PAKE) protocols with zero knowledge 210 password proof (ZKPP) [EKE] [IEEE1363.2]. Any pre-authentication 211 mechanism can be encapsulated in the padata field Section 6.5 of 212 FAST. A pre-authentication type thus carried within FAST is called a 213 FAST factor. A FAST factor MUST NOT be used outside of FAST unless 214 its specification explicitly allows so. Note that FAST without a 215 FAST factor for authentication does NOT by itself authenticate the 216 client or the KDC. 217 218 New pre-authentication mechanisms SHOULD design FAST factors, instead 219 220 221 222Zhu & Hartman Expires April 28, 2007 [Page 4] 223 224Internet-Draft Kerberos Preauth Framework October 2006 225 226 227 of full-blown pre-authentication mechanisms. 228 229 A conversation consists of all messages that are necessary to 230 complete the mutual authentication between the client and the KDC. A 231 conversation is the smallest logic unit for messages exchanged 232 between the client and the KDC. The KDC need to manage mulitple 233 authentication sets frequently need to keep track of KDC states 234 during a convesation, standard solutions are provided for these 235 common problems. 236 237 This document should be read only after reading the documents 238 describing the Kerberos cryptography framework [RFC3961] and the core 239 Kerberos protocol [RFC4120]. This document freely uses terminology 240 and notation from these documents without reference or further 241 explanation. 242 243 2442. Conventions Used in This Document 245 246 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 247 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 248 document are to be interpreted as described in [RFC2119]. 249 250 The word padata is used as the shorthand of pre-authentication data. 251 A conversation is used to refer to all authentication messages 252 exchanged between the client and the KDC. 253 254 2553. Model for Pre-Authentication 256 257 When a Kerberos client wishes to obtain a ticket using the 258 authentication server, it sends an initial Authentication Service 259 (AS) request. If pre-authentication is required but not being used, 260 then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error. 261 Alternatively, if the client knows what pre-authentication to use, it 262 MAY optimize away a round-trip and send an initial request with 263 padata included in the initial request. If the client includes the 264 wrong padata, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no 265 indication of what padata should have been included. In that case, 266 the client MUST retry with no padata and examine the error data of 267 the KDC_ERR_PREAUTH_REQUIRED error. If the KDC includes pre- 268 authentication information in the accompanying error data of 269 KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data as 270 that of the KDC_ERR_PREAUTH_REQUIRED error, and then retry. 271 272 The conventional KDC maintains no state between two requests; 273 subsequent requests may even be processed by a different KDC. On the 274 other hand, the client treats a series of exchanges with KDCs as a 275 276 277 278Zhu & Hartman Expires April 28, 2007 [Page 5] 279 280Internet-Draft Kerberos Preauth Framework October 2006 281 282 283 single authentication session. Each exchange accumulates state and 284 hopefully brings the client closer to a successful authentication. 285 286 These models for state management are in apparent conflict. For many 287 of the simpler pre-authentication scenarios, the client uses one 288 round trip to find out what mechanisms the KDC supports. Then the 289 next request contains sufficient pre-authentication for the KDC to be 290 able to return a successful reply. For these simple scenarios, the 291 client only sends one request with pre-authentication data and so the 292 authentication session is trivial. For more complex authentication 293 sessions, the KDC needs to provide the client with a cookie to 294 include in future requests to capture the current state of the 295 authentication session. Handling of multiple round-trip mechanisms 296 is discussed in Section 6.3. 297 298 This framework specifies the behavior of Kerberos pre-authentication 299 mechanisms used to identify users or to modify the reply key used to 300 encrypt the KDC reply. The PA-DATA typed hole may be used to carry 301 extensions to Kerberos that have nothing to do with proving the 302 identity of the user or establishing a reply key. Such extensions 303 are outside the scope of this framework. However mechanisms that do 304 accomplish these goals should follow this framework. 305 306 This framework specifies the minimum state that a Kerberos 307 implementation needs to maintain while handling a request in order to 308 process pre-authentication. It also specifies how Kerberos 309 implementations process the padata at each step of the AS request 310 process. 311 3123.1. Information Managed by the Pre-authentication Model 313 314 The following information is maintained by the client and KDC as each 315 request is being processed: 316 317 o The reply key used to encrypt the KDC reply 318 319 o How strongly the identity of the client has been authenticated 320 321 o Whether the reply key has been used in this authentication session 322 323 o Whether the reply key has been replaced in this authentication 324 session 325 326 o Whether the contents of the KDC reply can be verified by the 327 client principal 328 329 330 331 332 333 334Zhu & Hartman Expires April 28, 2007 [Page 6] 335 336Internet-Draft Kerberos Preauth Framework October 2006 337 338 339 o Whether the contents of the KDC reply can be verified by the 340 client machine 341 342 Conceptually, the reply key is initially the long-term key of the 343 principal. However, principals can have multiple long-term keys 344 because of support for multiple encryption types, salts and 345 string2key parameters. As described in section 5.2.7.5 of the 346 Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify 347 the client what types of keys are available. Thus in full 348 generality, the reply key in the pre-authentication model is actually 349 a set of keys. At the beginning of a request, it is initialized to 350 the set of long-term keys advertised in the PA-ETYPE-INFO2 element on 351 the KDC. If multiple reply keys are available, the client chooses 352 which one to use. Thus the client does not need to treat the reply 353 key as a set. At the beginning of a handling a request, the client 354 picks a reply key to use. 355 356 KDC implementations MAY choose to offer only one key in the PA-ETYPE- 357 INFO2 element. Since the KDC already knows the client's list of 358 supported enctypes from the request, no interoperability problems are 359 created by choosing a single possible reply key. This way, the KDC 360 implementation avoids the complexity of treating the reply key as a 361 set. 362 363 When the padata in the request is verified by the KDC, then the 364 client is known to have that key, therefore the KDC SHOULD pick the 365 same key as the reply key. 366 367 At the beginning of handling a message on both the client and the 368 KDC, the client's identity is not authenticated. A mechanism may 369 indicate that it has successfully authenticated the client's 370 identity. This information is useful to keep track of on the client 371 in order to know what pre-authentication mechanisms should be used. 372 The KDC needs to keep track of whether the client is authenticated 373 because the primary purpose of pre-authentication is to authenticate 374 the client identity before issuing a ticket. The handling of 375 authentication strength using various authentication mechanisms is 376 discussed in Section 6.6. 377 378 Initially the reply key has not been used. A pre-authentication 379 mechanism that uses the reply key either directly to encrypt or 380 checksum some data or indirectly in the generation of new keys MUST 381 indicate that the reply key is used. This state is maintained by the 382 client and the KDC to enforce the security requirement stated in 383 Section 4.3 that the reply key cannot be used after it is replaced. 384 385 Initially the reply key has not been replaced. If a mechanism 386 implements the Replace Reply Key facility discussed in Section 4.3, 387 388 389 390Zhu & Hartman Expires April 28, 2007 [Page 7] 391 392Internet-Draft Kerberos Preauth Framework October 2006 393 394 395 then the state MUST be updated to indicate that the reply key has 396 been replaced. Once the reply key has been replaced, knowledge of 397 the reply key is insufficient to authenticate the client. The reply 398 key is marked replaced in exactly the same situations as the KDC 399 reply is marked as not being verified to the client principal. 400 However, while mechanisms can verify the KDC reply to the client, 401 once the reply key is replaced, then the reply key remains replaced 402 for the remainder of the authentication session. 403 404 Without pre-authentication, the client knows that the KDC reply is 405 authentic and has not been modified because it is encrypted in a 406 long-term key of the client. Only the KDC and the client know that 407 key. So at the start of handling any message the KDC reply is 408 presumed to be verified using the client principal's long-term key. 409 Any pre-authentication mechanism that sets a new reply key not based 410 on the principal's long-term secret MUST either verify the KDC reply 411 some other way or indicate that the reply is not verified. If a 412 mechanism indicates that the reply is not verified then the client 413 implementation MUST return an error unless a subsequent mechanism 414 verifies the reply. The KDC needs to track this state so it can 415 avoid generating a reply that is not verified. 416 417 The typical Kerberos request does not provide a way for the client 418 machine to know that it is talking to the correct KDC. Someone who 419 can inject packets into the network between the client machine and 420 the KDC and who knows the password that the user will give to the 421 client machine can generate a KDC reply that will decrypt properly. 422 So, if the client machine needs to authenticate that the user is in 423 fact the named principal, then the client machine needs to do a TGS 424 request for itself as a service. Some pre-authentication mechanisms 425 may provide a way for the client to authenticate the KDC. Examples 426 of this include signing the reply with a well-known public key or 427 providing a ticket for the client machine as a service in addition to 428 the requested ticket. 429 4303.2. Initial Pre-authentication Required Error 431 432 Typically a client starts an authentication session by sending an 433 initial request with no pre-authentication. If the KDC requires pre- 434 authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message. 435 After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code, 436 the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED for 437 pre-authentication configurations that use multi-round-trip 438 mechanisms; see Section 3.4 for details of that case. 439 440 The KDC needs to choose which mechanisms to offer the client. The 441 client needs to be able to choose what mechanisms to use from the 442 first message. For example consider the KDC that will accept 443 444 445 446Zhu & Hartman Expires April 28, 2007 [Page 8] 447 448Internet-Draft Kerberos Preauth Framework October 2006 449 450 451 mechanism A followed by mechanism B or alternatively the single 452 mechanism C. A client that supports A and C needs to know that it 453 should not bother trying A. 454 455 Mechanisms can either be sufficient on their own or can be part of an 456 authentication set--a group of mechanisms that all need to 457 successfully complete in order to authenticate a client. Some 458 mechanisms may only be useful in authentication sets; others may be 459 useful alone or in authentication sets. For the second group of 460 mechanisms, KDC policy dictates whether the mechanism will be part of 461 an authentication set or offered alone. For each mechanism that is 462 offered alone, the KDC includes the pre-authentication type ID of the 463 mechanism in the padata sequence returned in the 464 KDC_ERR_PREAUTH_REQUIRED error. 465 466 The KDC SHOULD NOT send data that is encrypted in the long-term 467 password-based key of the principal. Doing so has the same security 468 exposures as the Kerberos protocol without pre-authentication. There 469 are few situations where pre-authentication is desirable and where 470 the KDC needs to expose cipher text encrypted in a weak key before 471 the client has proven knowledge of that key. 472 4733.3. Client to KDC 474 475 This description assumes a client has already received a 476 KDC_ERR_PREAUTH_REQUIRED from the KDC. If the client performs 477 optimistic pre-authentication then the client needs to optimistically 478 choose the information it would normally receive from that error 479 response. 480 481 The client starts by initializing the pre-authentication state as 482 specified. It then processes the padata in the 483 KDC_ERR_PREAUTH_REQUIRED. 484 485 When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the 486 client MAY ignore any padata it chooses unless doing so violates a 487 specification to which the client conforms. Clients MUST NOT ignore 488 the padata defined in Section 6.3. Clients SHOULD process padata 489 unrelated to this framework or other means of authenticating the 490 user. Clients SHOULD choose one authentication set or mechanism that 491 could lead to authenticating the user and ignore the rest. Since the 492 list of mechanisms offered by the KDC is in the decreasing preference 493 order, clients typically choose the first mechanism that the client 494 can usefully perform. If a client chooses to ignore a padata it MUST 495 NOT process the padata, allow the padata to affect the pre- 496 authentication state, nor respond to the padata. 497 498 For each padata the client chooses to process, the client processes 499 500 501 502Zhu & Hartman Expires April 28, 2007 [Page 9] 503 504Internet-Draft Kerberos Preauth Framework October 2006 505 506 507 the padata and modifies the pre-authentication state as required by 508 that mechanism. Padata are processed in the order received from the 509 KDC. 510 511 After processing the padata in the KDC error, the client generates a 512 new request. It processes the pre-authentication mechanisms in the 513 order in which they will appear in the next request, updating the 514 state as appropriate. The request is sent when it is complete. 515 5163.4. KDC to Client 517 518 When a KDC receives an AS request from a client, it needs to 519 determine whether it will respond with an error or a AS reply. There 520 are many causes for an error to be generated that have nothing to do 521 with pre-authentication; they are discussed in the core Kerberos 522 specification. 523 524 From the standpoint of evaluating the pre-authentication, the KDC 525 first starts by initializing the pre-authentication state. It then 526 processes the padata in the request. As mentioned in Section 3.3, 527 the KDC MAY ignore padata that is inappropriate for the configuration 528 and MUST ignore padata of an unknown type. 529 530 At this point the KDC decides whether it will issue a pre- 531 authentication required error or a reply. Typically a KDC will issue 532 a reply if the client's identity has been authenticated to a 533 sufficient degree. 534 535 In the case of a KDC_ERR_PREAUTH_REQUIRED error, the KDC first starts 536 by initializing the pre-authentication state. Then it processes any 537 padata in the client's request in the order provided by the client. 538 Mechanisms that are not understood by the KDC are ignored. 539 Mechanisms that are inappropriate for the client principal or the 540 request SHOULD also be ignored. Next, it generates padata for the 541 error response, modifying the pre-authentication state appropriately 542 as each mechanism is processed. The KDC chooses the order in which 543 it will generate padata (and thus the order of padata in the 544 response), but it needs to modify the pre-authentication state 545 consistently with the choice of order. For example, if some 546 mechanism establishes an authenticated client identity, then the 547 subsequent mechanisms in the generated response receive this state as 548 input. After the padata is generated, the error response is sent. 549 Typically the errors with the code KDC_ERR_MORE_PREAUTH_DATA_NEEDED 550 in a converstation will include KDC state as discussed in 551 Section 6.3. 552 553 To generate a final reply, the KDC generates the padata modifying the 554 pre-authentication state as necessary. Then it generates the final 555 556 557 558Zhu & Hartman Expires April 28, 2007 [Page 10] 559 560Internet-Draft Kerberos Preauth Framework October 2006 561 562 563 response, encrypting it in the current pre-authentication reply key. 564 565 5664. Pre-Authentication Facilities 567 568 Pre-Authentication mechanisms can be thought of as providing various 569 conceptual facilities. This serves two useful purposes. First, 570 mechanism authors can choose only to solve one specific small 571 problem. It is often useful for a mechanism designed to offer key 572 management not to directly provide client authentication but instead 573 to allow one or more other mechanisms to handle this need. Secondly, 574 thinking about the abstract services that a mechanism provides yields 575 a minimum set of security requirements that all mechanisms providing 576 that facility must meet. These security requirements are not 577 complete; mechanisms will have additional security requirements based 578 on the specific protocol they employ. 579 580 A mechanism is not constrained to only offering one of these 581 facilities. While such mechanisms can be designed and are sometimes 582 useful, many pre-authentication mechanisms implement several 583 facilities. By combining multiple facilities in a single mechanism, 584 it is often easier to construct a secure, simple solution than by 585 solving the problem in full generality. Even when mechanisms provide 586 multiple facilities, they need to meet the security requirements for 587 all the facilities they provide. 588 589 According to Kerberos extensibility rules (Section 1.5 of the 590 Kerberos specification [RFC4120]), an extension MUST NOT change the 591 semantics of a message unless a recipient is known to understand that 592 extension. Because a client does not know that the KDC supports a 593 particular pre-authentication mechanism when it sends an initial 594 request, a pre-authentication mechanism MUST NOT change the semantics 595 of the request in a way that will break a KDC that does not 596 understand that mechanism. Similarly, KDCs MUST not send messages to 597 clients that affect the core semantics unless the client has 598 indicated support for the message. 599 600 The only state in this model that would break the interpretation of a 601 message is changing the expected reply key. If one mechanism changed 602 the reply key and a later mechanism used that reply key, then a KDC 603 that interpreted the second mechanism but not the first would fail to 604 interpret the request correctly. In order to avoid this problem, 605 extensions that change core semantics are typically divided into two 606 parts. The first part proposes a change to the core semantic--for 607 example proposes a new reply key. The second part acknowledges that 608 the extension is understood and that the change takes effect. 609 Section 4.2 discusses how to design mechanisms that modify the reply 610 key to be split into a proposal and acceptance without requiring 611 612 613 614Zhu & Hartman Expires April 28, 2007 [Page 11] 615 616Internet-Draft Kerberos Preauth Framework October 2006 617 618 619 additional round trips to use the new reply key in subsequent pre- 620 authentication. Other changes in the state described in Section 3.1 621 can safely be ignored by a KDC that does not understand a mechanism. 622 Mechanisms that modify the behavior of the request outside the scope 623 of this framework need to carefully consider the Kerberos 624 extensibility rules to avoid similar problems. 625 6264.1. Client-authentication Facility 627 628 The client authentication facility proves the identity of a user to 629 the KDC before a ticket is issued. Examples of mechanisms 630 implementing this facility include the encrypted timestamp facility 631 defined in Section 5.2.7.2 of the Kerberos specification [RFC4120]. 632 Mechanisms that provide this facility are expected to mark the client 633 as authenticated. 634 635 Mechanisms implementing this facility SHOULD require the client to 636 prove knowledge of the reply key before transmitting a successful KDC 637 reply. Otherwise, an attacker can intercept the pre-authentication 638 exchange and get a reply to attack. One way of proving the client 639 knows the reply key is to implement the Replace Reply Key facility 640 along with this facility. The PKINIT mechanism [RFC4556] implements 641 Client Authentication alongside Replace Reply Key. 642 643 If the reply key has been replaced, then mechanisms such as 644 encrypted-timestamp that rely on knowledge of the reply key to 645 authenticate the client MUST NOT be used. 646 6474.2. Strengthening-reply-key Facility 648 649 Particularly, when dealing with keys based on passwords, it is 650 desirable to increase the strength of the key by adding additional 651 secrets to it. Examples of sources of additional secrets include the 652 results of a Diffie-Hellman key exchange or key bits from the output 653 of a smart card [RFC4556]. Typically these additional secrets can be 654 first combined with the existing reply key and then converted to a 655 protocol key using tools defined in Section 6.1. 656 657 If a mechanism implementing this facility wishes to modify the reply 658 key before knowing that the other party in the exchange supports the 659 mechanism, it proposes modifying the reply key. The other party then 660 includes a message indicating that the proposal is accepted if it is 661 understood and meets policy. In many cases it is desirable to use 662 the new reply key for client authentication and for other facilities. 663 Waiting for the other party to accept the proposal and actually 664 modify the reply key state would add an additional round trip to the 665 exchange. Instead, mechanism designers are encouraged to include a 666 typed hole for additional padata in the message that proposes the 667 668 669 670Zhu & Hartman Expires April 28, 2007 [Page 12] 671 672Internet-Draft Kerberos Preauth Framework October 2006 673 674 675 reply key change. The padata included in the typed hole are 676 generated assuming the new reply key. If the other party accepts the 677 proposal, then these padata are interpreted as if they were included 678 immediately following the proposal. The party generating the 679 proposal can determine whether the padata were processed based on 680 whether the proposal for the reply key is accepted. 681 682 The specific formats of the proposal message, including where padata 683 are are included is a matter for the mechanism specification. 684 Similarly, the format of the message accepting the proposal is 685 mechanism-specific. 686 687 Mechanisms implementing this facility and including a typed hole for 688 additional padata MUST checksum that padata using a keyed checksum or 689 encrypt the padata. Typically the reply key is used to protect the 690 padata. If you are only minimally increasing the strength of the 691 reply key, this may give the attacker access to something too close 692 to the original reply key. However, binding the padata to the new 693 reply key seems potentially important from a security standpoint. 694 There may also be objections to this from a double encryption 695 standpoint because we also recommend client authentication facilities 696 be tied to the reply key. 697 6984.3. Replacing-reply-key Facility 699 700 The Replace Reply Key facility replaces the key in which a successful 701 AS reply will be encrypted. This facility can only be used in cases 702 where knowledge of the reply key is not used to authenticate the 703 client. The new reply key MUST be communicated to the client and the 704 KDC in a secure manner. Mechanisms implementing this facility MUST 705 mark the reply key as replaced in the pre-authentication state. 706 Mechanisms implementing this facility MUST either provide a mechanism 707 to verify the KDC reply to the client or mark the reply as unverified 708 in the pre-authentication state. Mechanisms implementing this 709 facility SHOULD NOT be used if a previous mechanism has used the 710 reply key. 711 712 As with the strengthening-reply-key facility, Kerberos extensibility 713 rules require that the reply key not be changed unless both sides of 714 the exchange understand the extension. In the case of this facility 715 it will likely be more common for both sides to know that the 716 facility is available by the time that the new key is available to be 717 used. However, mechanism designers can use a container for padata in 718 a proposal message as discussed in Section 4.2 if appropriate. 719 720 721 722 723 724 725 726Zhu & Hartman Expires April 28, 2007 [Page 13] 727 728Internet-Draft Kerberos Preauth Framework October 2006 729 730 7314.4. KDC-authentication Facility 732 733 This facility verifies that the reply comes from the expected KDC. 734 In traditional Kerberos, the KDC and the client share a key, so if 735 the KDC reply can be decrypted then the client knows that a trusted 736 KDC responded. Note that the client machine cannot trust the client 737 unless the machine is presented with a service ticket for it 738 (typically the machine can retrieve this ticket by itself). However, 739 if the reply key is replaced, some mechanism is required to verify 740 the KDC. Pre-authentication mechanisms providing this facility allow 741 a client to determine that the expected KDC has responded even after 742 the reply key is replaced. They mark the pre-authentication state as 743 having been verified. 744 745 7465. Requirements for Pre-Authentication Mechanisms 747 748 This section lists requirements for specifications of pre- 749 authentication mechanisms. 750 751 For each message in the pre-authentication mechanism, the 752 specification describes the pa-type value to be used and the contents 753 of the message. The processing of the message by the sender and 754 recipient is also specified. This specification needs to include all 755 modifications to the pre-authentication state. 756 757 Generally mechanisms have a message that can be sent in the error 758 data of the KDC_ERR_PREAUTH_REQUIRED error message or in an 759 authentication set. If the client need information such as, for 760 example, trusted certificate authorities in order to determine if it 761 can use the mechanism, then this information should be in that 762 message. In addition, such mechanisms should also define a pa-hint 763 to be included in authentication sets. Often, the same information 764 included in the padata-value is appropriate to include in the pa- 765 hint. 766 767 In order to ease security analysis the mechanism specification should 768 describe what facilities from this document are offered by the 769 mechanism. For each facility, the security consideration section of 770 the mechanism specification should show that the security 771 requirements of that facility are met. This requirement is 772 applicable to any FAST factor that is used in FAST to provide 773 authentication information. 774 775 Significant problems have resulted in the specification of Kerberos 776 protocols because much of the KDC exchange is not protected against 777 authentication. The security considerations section should discuss 778 unauthenticated plaintext attacks. It should either show that 779 780 781 782Zhu & Hartman Expires April 28, 2007 [Page 14] 783 784Internet-Draft Kerberos Preauth Framework October 2006 785 786 787 plaintext is protected or discuss what harm an attacker could do by 788 modifying the plaintext. It is generally acceptable for an attacker 789 to be able to cause the protocol negotiation to fail by modifying 790 plaintext. More significant attacks should be evaluated carefully. 791 792 7936. Tools for Use in Pre-Authentication Mechanisms 794 795 This section describes common tools needed by multiple pre- 796 authentication mechanisms. By using these tools mechanism designers 797 can use a modular approach to specify mechanism details and ease 798 security analysis. 799 8006.1. Combining Keys 801 802 Frequently a weak key need to be combined with a stronger key before 803 use. For example, passwords are typically limited in size and 804 insufficiently random, therefore it is desirable to increase the 805 strength of the keys based on passwords by adding additional secrets 806 to it. Additional source of secrecy may come from hardware tokens. 807 808 This section provides standard ways to combine two keys into one. 809 810 KRB-FX-CF1() is defined to combine two pass-phrases. 811 812 KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string) 813 KRB-FX-CF1(x, y) -> x || y 814 815 Where || denotes concatenation. The strength of the final key is 816 roughly the total strength of the individual keys being combined. 817 818 An example usage of KRB-FX-CF1() is when a device provides random but 819 short passwords, the password is often combined with a personal 820 identification number (PIN). The password and the PIN can be 821 combined using KRB-FX-CF1(). 822 823 The function KRB-FX-CF2() produces a new key based on two existing 824 keys of the same enctype and it is base on a secure hash function and 825 the primitives encrypt(), random-to-key() and K-truncate() described 826 in [RFC3961]. 827 828 KRB-FX-CF2(protocol key, protocol key, octet string) -> 829 (resulting key) 830 831 The KRB-FX-CF2() function takes two protocol keys and an octet string 832 as input, and output a new key of the same enctype. 833 834 835 836 837 838Zhu & Hartman Expires April 28, 2007 [Page 15] 839 840Internet-Draft Kerberos Preauth Framework October 2006 841 842 843 encrypt(B, initial-cipher-state, pepper) -> (state-1, cipher-text-1) 844 845 encrypt(A, initial-cipher-state, pepper) -> (state-2, cipher-text-2) 846 847 PRF+(H, cipher-text-1 | cipher-text-2) -> bitstring-1 848 849 K-truncate(cipher-text-1) -> bitstring-2 850 851 random-to-key(bitstring-2) -> final-key 852 853 KRB-FX-CF2(A, B, pepper) -> final-key 854 855 Where initial-cipher-state is defined in [RFC3961] and the key- 856 generation seed length K is specified by the enctype profile 857 [RFC3961]. The value of the parameter pepper is RECOMMENDED to be in 858 the form of contextID || SharedInfo per guidelines in [HKDF]. If the 859 value of pepper is too short for the encrypt() primitive, it MUST 860 first be padded with all zeroes to the next shortest length that 861 encryt() can operate on. PRF+() produces a bit-string of at least K 862 bits in length. 863 864 H is the secure hash function associated with the enctype. An 865 example of a secure hash function is SHA-256 [SHA2]. 866 867 This document updates [RFC3961] to associate a secure hash function 868 with every enctype. Unless otherwise specified by the enctype 869 specification, the associated hash function is SHA-256. The 870 associated hash function for hmac-sha1-96-aes256 is SHA-512 [SHA2]. 871 872 encryption type etype associated hash function 873 -------------------------------------------------------------- 874 hmac-sha1-96-aes256 16 SHA-512 [SHA2] 875 876 PRF+ is defined as follows: 877 878 PRF+(secure hash function, octet string) -> (octet string) 879 880 PRF+(H, shared-info) -> H( 1 || shared-info ) || 881 H( 2 || shared-info ) H ( 3 || shared-info ) || ... 882 883 Where the counter value 1, 2, 3 and so on are encoded as a one-octet 884 integer. 885 886 Mechanism designers MUST specify the pepper value when combining two 887 keys using KRB-FX-CF2(). 888 889 890 891 892 893 894Zhu & Hartman Expires April 28, 2007 [Page 16] 895 896Internet-Draft Kerberos Preauth Framework October 2006 897 898 8996.2. Protecting Requests/Responses 900 901 Mechanism designers SHOULD provide integrity protection of the 902 messages in a conversation whenever feasible 903 904 Sensitive data MUST be encrypted when sent over the wire. Non- 905 sensitive data that have privacy implications are encouraged to be 906 encrypted as well. 907 908 If there are more than one roundtrip for an authentication exchange, 909 mechanism designers SHOULD allow either the client or the KDC provide 910 a checksum of all the messages exchanged on the wire, that is then 911 verified by the receiver. 912 913 Primitives defined in [RFC3961] are RECOMMENDED for integrity 914 protection and confidentiality. Mechanisms based on these primitives 915 have the benefit of crypto-agility provided by [RFC3961]. The 916 advantage afforded by crypto-agility is the ability to avoid a multi- 917 year standardization and deployment cycle to fix a problem specific 918 to a particular algorithm, when real attacks do arise against that 919 algorithm. 920 921 New mechanisms MUST NOT be hard-wired to use a specific algorithm. 922 9236.3. Managing States for the KDC 924 925 For any conversation that consists of more than two messages, the KDC 926 likely need to keep track of KDC states for incomplete authentication 927 exchanges and destroy the states of a conversation when the 928 authentication completes successful or fails, or the KDC times out. 929 When the KDC times out, the KDC returns an error message with the 930 code KDC_ERR_PREAUTH_TIMED_OUT. 931 932 KDC_ERR_PREAUTH_TIMED_OUT TBA 933 934 Upnon receipt of this error, the client MUST abort the existing 935 conversation, and restart a new one. 936 937 An example, where more than one message from the client is needed, is 938 when the client is authenticated based on a challenge-response 939 scheme. In that case, the KDC need to keep track of the challenge 940 issued for a client authentication request. 941 942 The PA-FX-COOKIE pdata type is defined in this section to facilitate 943 state management. 944 945 PA_FX_COOKIE TBA 946 947 948 949 950Zhu & Hartman Expires April 28, 2007 [Page 17] 951 952Internet-Draft Kerberos Preauth Framework October 2006 953 954 955 The corresponding padata-value field [RFC4120] contains the 956 Distinguished Encoding Rules (DER) [X60] [X690] encoding of the 957 following Abstract Syntax Notation One (ASN.1) type PA-FX-COOKIE: 958 959 PA-FX-COOKIE ::= SEQUENCE { 960 Cookie [1] OCTET STRING, 961 -- Opaque data, for use to associate all the messages in a 962 -- single conversation between the client and the KDC. 963 -- This can be generated by either the client or the KDC. 964 -- The receiver MUST copy the exact Cookie encapsulated in 965 -- a PA_FX_COOKIE data element into the next message of the 966 -- same conversation. 967 ... 968 } 969 970 The PA-FX-COOKIE structure contains an opaque cookie that is a logic 971 identifier of all the messages in a conversation. 972 973 The PA_FX_COOKIE can be initially sent by the client or the KDC, the 974 receiver MUST copy the Cookie into a PA_FX_COOKIE padata and include 975 it in the next message, if any, in the same conversation. 976 977 The content of the PA_FX_COOKIE padata is a local matter of the 978 sender. Implementations MUST NOT include any sensitive or private 979 data in the PA-FX-COOKIE structure. 980 981 If at least one more message for a mechanism or a mechanism set is 982 expected by the KDC, the KDC returns a 983 KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA_FX_COOKIE to 984 identify the conversation with the client. 985 986 KDC_ERR_MORE_PREAUTH_DATA_NEEDED TBA 987 988 If a PA_FX_COOKIE is included in the client request, the KDC then 989 MUST copy the exact cookie into the response. 990 9916.4. Pre-authentication Set 992 993 If all mechanisms in a group need to successfully complete in order 994 to authenticate a client, the client and the KDC SHOULD use the 995 PA_AUTHENTICATION_SET padata element. A PA_AUTHENTICATION_SET padata 996 element contains the ASN.1 DER encoding of the PA-AUTHENTICATION-SET 997 structure: 998 999 1000 1001 1002 1003 1004 1005 1006Zhu & Hartman Expires April 28, 2007 [Page 18] 1007 1008Internet-Draft Kerberos Preauth Framework October 2006 1009 1010 1011 PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM 1012 1013 PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE { 1014 pa-type [1] Int32, 1015 -- same as padata-type. 1016 pa-hint [2] OCTET STRING, 1017 -- hint data. 1018 ... 1019 } 1020 1021 The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure 1022 contains the corresponding value of padata-type in PA-DATA [RFC4120]. 1023 Associated with the pa-type is a pa-hint, which is an octet-string 1024 specified by the pre-authentication mechanism. This hint may provide 1025 information for the client which helps it determine whether the 1026 mechanism can be used. For example a public-key mechanism might 1027 include the certificate authorities it trusts in the hint info. Most 1028 mechanisms today do not specify hint info; if a mechanism does not 1029 specify hint info the KDC MUST NOT send a hint for that mechanism. 1030 To allow future revisions of mechanism specifications to add hint 1031 info, clients MUST ignore hint info received for mechanisms that the 1032 client believes do not support hint info. 1033 1034 When indicating which sets of padata are supported, the KDC includes 1035 a PA-AUTHENTICATION-SET padata element for each authentication set. 1036 1037 The client sends the padata-value for the first mechanism it picks in 1038 the authentication set, when the first mechanism completes, the 1039 client and the KDC will proceed with the second mechanism, and so on 1040 until all mechanisms complete successfully. The PA_FX_COOKIE as 1041 defined in Section 6.3 MUST be sent by the KDC along with the first 1042 message that contains a PA-AUTHENTICATION-SET, in order to keep track 1043 of KDC states. 1044 10456.5. Definition of Kerberos FAST Padata 1046 1047 The cipher text exposure of encrypted timestamp pre-authentication 1048 data is a security concern for Kerberos. Attackers can lauch offline 1049 dictionary attack using the cipher text. The FAST pre-authentication 1050 padata is a tool to mitigate this threat. FAST also provides 1051 solutions to common problems for pre-authentication mechanisms such 1052 as binding of the request and the reply, freshness guarantee of the 1053 authentication. FAST itself, however, does not authenticate the 1054 client or the KDC, instead, it provides a typed hole to allow pre- 1055 authentication data be tunneled using FAST messages. A pre- 1056 authentication data element used within FAST is called a FAST factor. 1057 A FAST factor capatures the minimal work required for extending 1058 Kerberos to support a new authentication scheme. A FAST factor MUST 1059 1060 1061 1062Zhu & Hartman Expires April 28, 2007 [Page 19] 1063 1064Internet-Draft Kerberos Preauth Framework October 2006 1065 1066 1067 NOT be used outside of FAST unless its specification explicitly 1068 allows so. The typed holes in FAST messages can also be used as 1069 generic ones that are not intended to prove the client's identity, or 1070 establish the reply key. 1071 1072 New pre-authentication mechanisms SHOULD be designed as FAST factors, 1073 instead of full-blown pre-authentication mechanisms. 1074 1075 A FAST mechanism factor when used within FAST to authenticate the 1076 client or the KDC is a pre-authentication mechanism, as such the 1077 specification of such a FAST factor SHOULD specify which facilities 1078 it provides per Section 5. 1079 1080 Implementations of the pre-authentication framework SHOULD use 1081 encrypted timestamp pre-authentication, if that is the mechanism to 1082 authenticate the client, as a FAST factor to avoid security exposure. 1083 1084 The encrypted timestamp FAST factor MUST fill out the encrypted rep- 1085 key-package field as described in Section 6.5.3. It provides the 1086 following facilities: client-authentication, replacing-reply-key, 1087 KDC-authentication. It does not provide the strengthening-reply-key 1088 facility. The security considerations section of this document 1089 provides an explaination why the security requirements are met. 1090 1091 FAST employs an armoring scheme. The armor can be a host Ticket 1092 Granting Ticket (TGT), or an anonymous TGT obtained based on 1093 anonymous PKINIT [KRB-ANON], or a pre-shared long term key such as a 1094 host key. The rest of this section describes the types of armors and 1095 the messages used by FAST. 1096 10976.5.1. FAST Armors 1098 1099 An armor key is used to encrypt pre-authentication data in the FAST 1100 request and the response. The ArmorData structure is used to 1101 identify the armor key. It contains the following two fields: the 1102 armor-type identifies the type of armor data, and the armor-value as 1103 an OCTET STRING contains the data. 1104 1105 KrbFastArmor ::= SEQUENCE { 1106 armor-type [1] Int32, 1107 -- Type of the armor. 1108 armor-value [2] OCTET STRING, 1109 -- Value of the armor. 1110 ... 1111 } 1112 1113 The value of the armor key is a matter of the armor type 1114 specification. The following types of armors are currently defined: 1115 1116 1117 1118Zhu & Hartman Expires April 28, 2007 [Page 20] 1119 1120Internet-Draft Kerberos Preauth Framework October 2006 1121 1122 1123 FX_FAST_ARMOR_AP_REQUEST 1 1124 FX_FAST_ARMOR_KEY_ID 2 1125 1126 Conforming implementations MUST implement the 1127 FX_FAST_ARMOR_AP_REQUEST armor type. 1128 11296.5.1.1. Ticket-based Armors 1130 1131 The FX_FAST_ARMOR_AP_REQUEST armor type is based on a Kerberos TGT. 1132 The armor-value field of an FX_FAST_ARMOR_AP_REQUEST armor contains 1133 an AP-REQ encoded in DER. The subkey field in the AP-REQ MUST be 1134 present. And the armor key is the subkey in the AP-REQ 1135 authenticator. 1136 1137 If the client has a TGT for the expected KDC, it can use that ticket 1138 to construct the AP-REQ. If not, the client can use anonymous PKINIT 1139 as described in [KRB-ANON] to obtain a TGT anonymously and use that 1140 to construct an FX_FAST_ARMOR_AP_REQUEST armor. 1141 11426.5.1.2. Key-based Armors 1143 1144 The FX_FAST_ARMOR_KEY_ID armor type is used to carry an identifier of 1145 a key that is shared between the client host and the KDC. The 1146 content and the encoding of the armor-data field of this armor type 1147 is a local matter of the communicating client and the expected KDC. 1148 The FX_FAST_ARMOR_KEY_ID armor is useful when the client host and the 1149 KDC does have a shared key and it is beneficial to minimize the 1150 number of messages exchanged between the client and the KDC, namely 1151 by eliminating the messages for obtaining a host ticket based on the 1152 host key. 1153 11546.5.2. FAST Request 1155 1156 A padata type PA_FX_FAST is defined for the Kerberos FAST pre- 1157 authentication padata. The corresponding padata-value field 1158 [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST- 1159 REQUEST. 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174Zhu & Hartman Expires April 28, 2007 [Page 21] 1175 1176Internet-Draft Kerberos Preauth Framework October 2006 1177 1178 1179 PA-FX-FAST-REQUEST ::= CHOICE { 1180 armored-data [1] KrbFastAmoredReq, 1181 ... 1182 } 1183 1184 KrbFastAmoredReq ::= SEQUENCE { 1185 armor [1] KrbFastArmor OPTIONAL, 1186 -- Contains the armor that determines the armor key. 1187 -- MUST be present in the initial AS-REQ in a converstation, 1188 -- MUST be absent in any subsequent AS-REQ. 1189 -- MUST be absent in TGS-REQ. 1190 req-checksum [2] Checksum, 1191 -- Checksum performed over the type KDC-REQ-BODY. 1192 -- The checksum key is the armor key, and the checksum 1193 -- type is the required checksum type for the enctype of 1194 -- the armor key. 1195 enc-fast-req [3] EncryptedData, -- KrbFastReq -- 1196 -- The encryption key is the armor key, and the key usage 1197 -- number is TBA. 1198 ... 1199 } 1200 1201 The PA-FX-FAST-REQUEST contains a KrbFastAmoredReq structure. The 1202 KrbFastAmoredReq encapsulates the encrypted padata. 1203 1204 The armor key is used to encrypt the KrbFastReq structure, and the 1205 key usage number for that encryption is TBA. The armor field in the 1206 KrbFastAmoredReq structure is filled to identify the armor key. 1207 1208 When a KrbFastAmoredReq is included in an AS request, the armor field 1209 MUST be present in the initial AS-REQ in a converstation, specifying 1210 the armor key being used. The armor field MUST be absent in any 1211 subsequent AS-REQ of the same converstation. Thus the armor key is 1212 specified explicitly in the initial AS-REQ in a converstation, and 1213 implicitly thereafter. 1214 1215 When a KrbFastAmoredReq is included in a TGS request, the armor field 1216 MUST be absent. In which case, the subkey in the AP-REQ 1217 authenticator in the PA-TGS-REQ PA-DATA MUST be present, and the 1218 armor key is implicitly that subkey. 1219 1220 The req-checksum field contains a checksum that is performed over the 1221 type KDC-REQ-BODY of the containing message. The checksum key is the 1222 armor key, and the checksum type is the required checksum type for 1223 the enctype of the armor key. 1224 1225 The enc-fast-req field contains an encrypted KrbFastReq structure. 1226 The KrbFastReq structure contains the following information: 1227 1228 1229 1230Zhu & Hartman Expires April 28, 2007 [Page 22] 1231 1232Internet-Draft Kerberos Preauth Framework October 2006 1233 1234 1235 KrbFastReq ::= SEQUENCE { 1236 fast-options [0] FastOptions, 1237 -- Additional options. 1238 padata [1] SEQUENCE OF PA-DATA, 1239 -- padata typed holes. 1240 timestamp [2] KerberosTime, 1241 usec [3] Microseconds, 1242 -- timestamp and usec represent the time of the client 1243 -- host. 1244 req-nonce [4] OCTET STRING, 1245 -- At least 128 octets in length, randomly filled using 1246 -- a PRNG by the client for each message request. 1247 ... 1248 } 1249 1250 The fast-options field indicates various options that are to modify 1251 the behavior of the KDC. The meanings of the options are as follows: 1252 1253 FastOptions ::= KerberosFlags 1254 -- reserved(0), 1255 -- anonymous(1), 1256 -- kdc-referrals(16) 1257 1258 1259 Bits Name Description 1260 ----------------------------------------------------------------- 1261 0 RESERVED Reserved for future expansion of this field. 1262 1 anonymous Requesting the KDC to hide client names in 1263 the KDC response, as described next in this 1264 section. 1265 16 kdc-referrals Requesting the KDC to follow referrals, as 1266 described next in this section. 1267 1268 Bits 1 through 15 (with bit 2 and bit 15 included) are critical 1269 options. If the KDC does not understand a critical option, it MUST 1270 fail the request. Bit 16 and onward (with bit 16 included) are non- 1271 critical options. The KDC conforming to this specification ignores 1272 unknown non-critical options. 1273 1274 The anonymous Option 1275 1276 The Kerberos response defined in [RFC4120] contains the client 1277 identity in clear text, This makes traffic analysis 1278 straightforward. The anonymous option is designed to complicate 1279 traffic analysis performed over the client-KDC messages. If the 1280 anonymous option is set, the KDC implementing PA_FX_FAST MUST 1281 identify the client as the anonymous principal in the KDC reply 1282 and the error response. Thus this option is set by the client if 1283 1284 1285 1286Zhu & Hartman Expires April 28, 2007 [Page 23] 1287 1288Internet-Draft Kerberos Preauth Framework October 2006 1289 1290 1291 it wishes to hide the client identity in the KDC response. 1292 1293 The kdc-referrals Option 1294 1295 The Kerberos client described in [RFC4120] has to request referral 1296 TGTs along the authentication path in order to get a service 1297 ticket for the target service. The Kerberos client described in 1298 the [REFERRALS] need to contain the AS specified in the error 1299 response in order to complete client referrals. In many cases, it 1300 is desirable to keep the client's involvement minimal. For 1301 example, the client may contact the KDC via a satellite link that 1302 has high latency, or the client has limited computational 1303 capabilities. The kdc-referrals option is designed to minimize 1304 the number of KDC response messages that the client need to 1305 process. If the kdc-referrals option is set, the KDC that honors 1306 this option acts as the client to follow AS referrals and TGS 1307 referrals [REFERRALS], and return the ticket thus-obtained using 1308 the reply key expected by the client. The kdc-referrals option 1309 can be implemented when the KDC knows the reply key. KDC can 1310 igore kdc-referrals option when it does not understand it or it 1311 does not allow it based on local policy. The client MUST be able 1312 to process the KDC responses when this option is not honored by 1313 the KDC, unless otherwise specified. 1314 1315 The padata field contains a list of PA-DATA structures as described 1316 in Section 5.2.7 in [RFC4120]. These PA-DATA structures can contain 1317 FAST factors. They can also be used as generic typed-holes to 1318 contain data not intended for proving the client's identity or 1319 establishing a reply key, but for protocol extensibility. 1320 1321 The timestamp and usec fields represent the time of the client host, 1322 these fields have the same semantics as the corresponding- 1323 identically-named fields in Section 5.6.1 of [RFC4120]. 1324 1325 The req-nonce field is randomly filled using a PRNG by the client for 1326 each message request. It MUST have at least 128 octets in length. 1327 13286.5.3. FAST Response 1329 1330 The KDC that supports the PA_FX_FAST padata MUST include a PA_FX_FAST 1331 padata element in the KDC reply and/or the error response, when the 1332 client and the KDC agreed upon the armor key. The corresponding 1333 padata-value field [RFC4120] in the KDC response is the DER encoding 1334 of the ASN.1 type PA-FX-FAST-REPLY. 1335 1336 1337 1338 1339 1340 1341 1342Zhu & Hartman Expires April 28, 2007 [Page 24] 1343 1344Internet-Draft Kerberos Preauth Framework October 2006 1345 1346 1347 PA-FX-FAST-REPLY ::= CHOICE { 1348 armored-data [1] KrbFastArmoredRep, 1349 ... 1350 } 1351 1352 KrbFastArmoredRep ::= SEQUENCE { 1353 enc-fast-rep [1] EncryptedData, -- KrbFastResponse -- 1354 -- The encryption key is the armor key in the request, and 1355 -- the key usage number is TBA. 1356 ... 1357 } 1358 1359 The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep 1360 structure. The KrbFastArmoredRep structure encapsulates the padata 1361 in the KDC reply in the encrypted form. The KrbFastResponse is 1362 encrypted with the armor key used in the corresponding request, and 1363 the key usage number is TBA. 1364 1365 The Kerberos client who does not receive a PA-FX-FAST-REPLY in the 1366 KDC response MUST reject the reply based on local policy. The 1367 Kerberos client MAY process an error message without a PA-FX-FAST- 1368 REPLY, if that is only intended to return better error information to 1369 the application, typically for trouble-shooing purposes. 1370 1371 The KrbFastResponse structure contains the following information: 1372 1373 KrbFastResponse ::= SEQUENCE { 1374 padata [1] SEQUENCE OF PA-DATA, 1375 -- padata typed holes. 1376 finish [2] KrbFastFinish OPTIONAL, 1377 -- MUST be present if the client is authenticated, 1378 -- absent otherwise. 1379 -- Typically this is present if and only if the containing 1380 -- message is the last one in a conversation. 1381 rep-nonce [3] OCTET STRING, 1382 -- At least 128 octets in length, randomly filled using 1383 -- a PRNG by the KDC for each KDC response. 1384 ... 1385 } 1386 1387 The padata field in the KrbFastResponse structure contains a list of 1388 PA-DATA structures as described in Section 5.2.7 of [RFC4120]. These 1389 PA-DATA structures are used to carry data completing the exchange for 1390 the FAST factors. They can also be used as generic typed-holes for 1391 protocol extensibility. 1392 1393 The finish field contains a KrbFastFinish structure. It is filled by 1394 the KDC when the client has been authenticated (the client 1395 1396 1397 1398Zhu & Hartman Expires April 28, 2007 [Page 25] 1399 1400Internet-Draft Kerberos Preauth Framework October 2006 1401 1402 1403 authenticated state is marked), it MUST be absent otherwise. 1404 Consequently this field can only be present in an AS-REP or a TGS-REP 1405 when a ticket is returned. And typically the containing message with 1406 the finish field present is the last one in a conversation. 1407 1408 The KrbFastFinish structure contains the following information: 1409 1410 KrbFastFinish ::= SEQUENCE { 1411 authtime [1] KerberosTime, 1412 usec [2] Microseconds, 1413 -- timestamp and usec represent the time on the KDC when 1414 -- the reply was generated. 1415 rep-key-package [3] EncryptedData OPTIONAL, -- EncryptionKey -- 1416 -- This, if present, replaces the reply key for AS and TGS. 1417 -- The encryption key is the client key, unless otherwise 1418 -- specified. The key usage number is TBA. 1419 crealm [4] Realm, 1420 cname [5] PrincipalName, 1421 -- Contains the client realm and the client name. 1422 checksum [6] Checksum, 1423 -- Checksum performed over all the messages in the 1424 -- conversation, except the containing message. 1425 -- The checksum key is the ticket session key of the reply 1426 -- ticket, and the checksum type is the required checksum 1427 -- type of that key. 1428 ... 1429 } 1430 1431 The timestamp and usec fields represent the time on the KDC when the 1432 reply was generated, these fields have the same semantics as the 1433 corresponding-identically-named fields in Section 5.6.1 of [RFC4120]. 1434 The client MUST use the KDC's time in these fields thereafter when 1435 using the returned ticket. Note that the KDC's time in AS-REP may 1436 not match the authtime in the reply ticket if the kdc-referrals 1437 option is requested and honored by the KDC. 1438 1439 The rep-key-package field, if present, contains the reply key 1440 encrypted using the client key unless otherwise specified. The key 1441 usage number is TBA. 1442 1443 When the encrypted timestamp FAST factor is used in the request, the 1444 rep-key-package field MUST be present and the client key is used to 1445 encrypt the reply key enclosed in the KrbFastArmoredRep. 1446 1447 The cname and crealm fields identifies the authenticated client. 1448 1449 The checksum field contains a checksum of all the messages in the 1450 conversation excluding and prior to the containing message. The 1451 1452 1453 1454Zhu & Hartman Expires April 28, 2007 [Page 26] 1455 1456Internet-Draft Kerberos Preauth Framework October 2006 1457 1458 1459 checksum key is the ticket session key of the reply ticket, and the 1460 checksum type is the required checksum type of the enctype of that 1461 key. 1462 1463 The rep-nonce field is randomly filled using a PRNG by the KDC for 1464 each KDC response, and it MUST have at least 128 octets in length. 1465 1466 The client MUST include a PA_FX_COOKIE as defined in Section 6.3, if 1467 it includes a PA_FX_FAST in the request. 1468 14696.6. Authentication Strength Indication 1470 1471 Implementations that have pre-authentication mechanisms offering 1472 significantly different strengths of client authentication MAY choose 1473 to keep track of the strength of the authentication used as an input 1474 into policy decisions. For example, some principals might require 1475 strong pre-authentication, while less sensitive principals can use 1476 relatively weak forms of pre-authentication like encrypted timestamp. 1477 1478 An AuthorizationData data type AD-Authentication-Strength is defined 1479 for this purpose. 1480 1481 AD-authentication-strength TBA 1482 1483 The corresponding ad-data field contains the DER encoding of the pre- 1484 authentication data set as defined in Section 6.4. This set contains 1485 all the pre-authentication mechanisms that were used to authenticate 1486 the client. If only one pre-authentication mechanism was used to 1487 authenticate the client, the pre-authentication set contains one 1488 element. 1489 1490 The AD-authentication-strength element MUST be included in the AD-IF- 1491 RELEVANT, thus it can be ignored if it is unknown to the receiver. 1492 1493 14947. IANA Considerations 1495 1496 This document defines FAST factors, these are mini- and light- 1497 weighted- pre-authentication mechanisms. A new IANA registry should 1498 be setup for registering FAST factor IDs. 1499 1500 15018. Security Considerations 1502 1503 The kdc-referrals option in the Kerberos FAST padata requests the KDC 1504 to act as the client to follow referrals. This can overload the KDC. 1505 To limit the damages of denied of service using this option, KDCs MAY 1506 restrict the number of simultaneous active requests with this option 1507 1508 1509 1510Zhu & Hartman Expires April 28, 2007 [Page 27] 1511 1512Internet-Draft Kerberos Preauth Framework October 2006 1513 1514 1515 for any given client principal. 1516 1517 Because the client secrets are known only to the client and the KDC, 1518 the verification of the encrypted timestamp proves the client's 1519 identity, the verification of the encrypted rep-key-package in the 1520 KDC reply proves that the expected KDC responded. The encrypted 1521 reply key is contained in the rep-key-package in the PA-FX-FAST- 1522 REPLY. Therefore, the encrypted timestamp FAST factor as a pre- 1523 authentication mechanism offers the following facilities: client- 1524 authentication, replacing-reply-key, KDC-authentication. There is no 1525 un-authenticated cleartext introduced by the encrypted timestamp FAST 1526 factor. 1527 1528 15299. Acknowledgements 1530 1531 Serveral suggestions from Jeffery Hutzman based on early revisions of 1532 this documents led to significant improvements of this document. 1533 1534 153510. References 1536 153710.1. Normative References 1538 1539 [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 1540 Support", draft-ietf-krb-wg-anon, work in progress. 1541 1542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1543 Requirement Levels", BCP 14, RFC 2119, March 1997. 1544 1545 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1546 Kerberos 5", RFC 3961, February 2005. 1547 1548 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1549 Kerberos Network Authentication Service (V5)", RFC 4120, 1550 July 2005. 1551 1552 [REFERALS] Raeburn, K. et al, "Generating KDC Referrals to Locate 1553 Kerberos Realms", draft-ietf-krb-wg-kerberos-referrals, 1554 work in progress. 1555 1556Zhu & Hartman Expires April 27, 2007 [Page 27] 1557 1558Internet-Draft Kerberos Preauth Framework October 2006 1559 1560 1561 [SHA2] National Institute of Standards and Technology, "Secure 1562 Hash Standard (SHS)", Federal Information Processing 1563 Standards Publication 180-2, August 2002. 1564 1565 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 1566 Information technology - Abstract Syntax Notation One 1567 (ASN.1): Specification of basic notation. 1568 1569 1570 1571Zhu & Hartman Expires April 28, 2007 [Page 28] 1572 1573Internet-Draft Kerberos Preauth Framework October 2006 1574 1575 1576 1577 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 1578 Information technology - ASN.1 encoding Rules: 1579 Specification of Basic Encoding Rules (BER), Canonical 1580 Encoding Rules (CER) and Distinguished Encoding Rules 1581 (DER). 1582 158310.2. Informative References 1584 1585 [EKE] Bellovin, S. M. and M. Merritt. "Augmented 1586 Encrypted Key Exchange: A Password-Based Protocol Secure 1587 Against Dictionary Attacks and Password File Compromise". 1588 Proceedings of the 1st ACM Conference on Computer and 1589 Communications Security, ACM Press, November 1993. 1590 1591 [HKDF] Dang, Q. and P. Polk, draft-dang-nistkdf, work in 1592 progress. 1593 1594 [IEEE1363.2] 1595 IEEE P1363.2: Password-Based Public-Key Cryptography, 1596 2004. 1597 1598 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 1599 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 1600 1601 1602Appendix A. ASN.1 module 1603 1604 KerberosPreauthFramework { 1605 iso(1) identified-organization(3) dod(6) internet(1) 1606 security(5) kerberosV5(2) modules(4) preauth-framework(3) 1607 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1608 1609 IMPORTS 1610 1611 KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum, 1612 Int32, EncryptedData, PA-DATA 1613 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 1614 dod(6) internet(1) security(5) kerberosV5(2) 1615 modules(4) krb5spec2(2) }; 1616 -- as defined in RFC 4120. 1617 1618 PA-FX-COOKIE ::= SEQUENCE { 1619 Cookie [1] OCTET STRING, 1620 -- Opaque data, for use to associate all the messages in a 1621 -- single conversation between the client and the KDC. 1622 -- This can be generated by either the client or the KDC. 1623 -- The receiver MUST copy the exact Cookie encapsulated in 1624 -- a PA_FX_COOKIE data element into the next message of the 1625 -- same conversation. 1626 ... 1627 } 1628 1629 PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM 1630 1631 PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE { 1632 pa-type [1] Int32, 1633 -- same as padata-type. 1634 pa-hint [2] OCTET STRING, 1635 -- hint data. 1636 ... 1637 } 1638 1639 1640Zhu & Hartman Expires April 28, 2007 [Page 29] 1641 1642Internet-Draft Kerberos Preauth Framework October 2006 1643 1644 1645 1646 PA-FX-FAST-REQUEST ::= CHOICE { 1647 armored-data [1] KrbFastAmoredReq, 1648 ... 1649 } 1650 1651 KrbFastAmoredReq ::= SEQUENCE { 1652 armor [1] KrbFastArmor OPTIONAL, 1653 -- Contains the armor that determines the armor key. 1654 -- MUST be present in AS-REQ. 1655 -- MUST be absent in TGS-REQ. 1656 req-checksum [2] Checksum, 1657 -- Checksum performed over the type KDC-REQ-BODY. 1658 -- The checksum key is the armor key, and the checksum 1659 -- type is the required checksum type for the enctype of 1660 -- the armor key. 1661 enc-fast-req [3] EncryptedData, -- KrbFastReq -- 1662 -- The encryption key is the armor key, and the key usage 1663 -- number is TBA. 1664 ... 1665 } 1666 1667 KrbFastArmor ::= SEQUENCE { 1668 armor-type [1] Int32, 1669 -- Type of the armor. 1670 armor-value [2] OCTET STRING, 1671 -- Value of the armor. 1672 ... 1673 } 1674 1675 KrbFastReq ::= SEQUENCE { 1676 fast-options [0] FastOptions, 1677 -- Additional options. 1678 padata [1] SEQUENCE OF PA-DATA, 1679 -- padata typed holes. 1680 timestamp [2] KerberosTime, 1681 usec [3] Microseconds, 1682 -- timestamp and usec represent the time of the client 1683 -- host. 1684 req-nonce [4] OCTET STRING, 1685 -- At least 128 octets in length, randomly filled using 1686 -- a PRNG by the client for each message request. 1687 ... 1688 } 1689 1690 FastOptions ::= KerberosFlags 1691 -- reserved(0), 1692 -- anonymous(1), 1693 -- kdc-referrals(16) 1694 1695 1696 1697Zhu & Hartman Expires April 28, 2007 [Page 30] 1698 1699Internet-Draft Kerberos Preauth Framework October 2006 1700 1701 1702 1703 PA-FX-FAST-REPLY ::= CHOICE { 1704 armored-data [1] KrbFastArmoredRep, 1705 ... 1706 } 1707 1708 KrbFastArmoredRep ::= SEQUENCE { 1709 enc-fast-rep [1] EncryptedData, -- KrbFastResponse -- 1710 -- The encryption key is the armor key in the request, and 1711 -- the key usage number is TBA. 1712 ... 1713 } 1714 1715 KrbFastResponse ::= SEQUENCE { 1716 padata [1] SEQUENCE OF PA-DATA, 1717 -- padata typed holes. 1718 finish [2] KrbFastFinish OPTIONAL, 1719 -- MUST be present if the client is authenticated, 1720 -- absent otherwise. 1721 -- Typically this is present if and only if the containing 1722 -- message is the last one in a conversation. 1723 rep-nonce [3] OCTET STRING, 1724 -- At least 128 octets in length, randomly filled using 1725 -- a PRNG by the KDC for each KDC response. 1726 ... 1727 } 1728 1729 KrbFastFinish ::= SEQUENCE { 1730 timestamp [1] KerberosTime, 1731 usec [2] Microseconds, 1732 -- timestamp and usec represent the time on the KDC when 1733 -- the reply was generated. 1734 rep-key-package [3] EncryptedData OPTIONAL, -- EncryptionKey -- 1735 -- This, if present, replaces the reply key for AS and TGS. 1736 -- The encryption key is the client key, unless otherwise 1737 -- specified. The key usage number is TBA. 1738 crealm [4] Realm, 1739 cname [5] PrincipalName, 1740 -- Contains the client realm and the client name. 1741 checksum [6] Checksum, 1742 -- Checksum performed over all the messages in the 1743 -- conversation, except the containing message. 1744 -- The checksum key is the ticket session key of the reply 1745 -- ticket, and the checksum type is the required checksum 1746 -- type of that key. 1747 ... 1748 } 1749 1750 END 1751 1752 1753Authors' Addresses 1754 1755 Larry Zhu 1756 Microsoft Corporation 1757 One Microsoft Way 1758 Redmond, WA 98052 1759 US 1760 1761 Email: lzhu@microsoft.com 1762 1763 1764 Sam hartman 1765 MIT 1766 1767 Email: hartmans@mit.edu 1768 1769 1770 1771 1772Zhu & Hartman Expires April 28, 2007 [Page 31] 1773 1774Internet-Draft Kerberos Preauth Framework October 2006 1775 1776 1777Full Copyright Statement 1778 1779 Copyright (C) The Internet Society (2006). 1780 1781 This document is subject to the rights, licenses and restrictions 1782 contained in BCP 78, and except as set forth therein, the authors 1783 retain all their rights. 1784 1785 This document and the information contained herein are provided on an 1786 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1787 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1788 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1789 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1790 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1791 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1792 1793 1794Intellectual Property 1795 1796 The IETF takes no position regarding the validity or scope of any 1797 Intellectual Property Rights or other rights that might be claimed to 1798 pertain to the implementation or use of the technology described in 1799 this document or the extent to which any license under such rights 1800 might or might not be available; nor does it represent that it has 1801 made any independent effort to identify any such rights. Information 1802 on the procedures with respect to rights in RFC documents can be 1803 found in BCP 78 and BCP 79. 1804 1805 Copies of IPR disclosures made to the IETF Secretariat and any 1806 assurances of licenses to be made available, or the result of an 1807 attempt made to obtain a general license or permission for the use of 1808 such proprietary rights by implementers or users of this 1809 specification can be obtained from the IETF on-line IPR repository at 1810 http://www.ietf.org/ipr. 1811 1812 The IETF invites any interested party to bring to its attention any 1813 copyrights, patents or patent applications, or other proprietary 1814 rights that may cover technology that may be required to implement 1815 this standard. Please address the information to the IETF at 1816 ietf-ipr@ietf.org. 1817 1818 1819Acknowledgment 1820 1821 Funding for the RFC Editor function is provided by the IETF 1822 Administrative Support Activity (IASA). 1823 1824 1825 1826 1827 1828Zhu & Hartman Expires April 28, 2007 [Page 32] 1829 1830 1831