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