1Kerberos Working Group S. Hartman 2Internet-Draft MIT 3Expires: January 17, 2005 July 19, 2004 4 5 6 7 A Generalized Framework for Kerberos Pre-Authentication 8 draft-ietf-krb-wg-preauth-framework-01 9 10 11Status of this Memo 12 13 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 18 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 23 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 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 33 34 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 37 38 39 This Internet-Draft will expire on January 17, 2005. 40 41 42Copyright Notice 43 44 45 Copyright (C) The Internet Society (2004). All Rights Reserved. 46 47 48Abstract 49 50 51 Kerberos is a protocol for verifying the identity of principals 52 (e.g., a workstation user or a network server) on an open network. 53 The Kerberos protocol provides a mechanism called pre-authentication 54 for proving the identity of a principal and for better protecting 55 the long-term secret of the principal. 56 57 58 This document describes a model for Kerberos pre-authentication 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 65 66 67Hartman Expires January 17, 2005 [Page 1] 68Internet-Draft Kerberos Preauth Framework July 2004 69 70 71 72 This document also provides common tools needed by multiple 73 pre-authentication mechanisms. 74 75 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [1]. 79 80 81Table of Contents 82 83 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 85 2. Model for Pre-Authentication . . . . . . . . . . . . . . . . . 4 86 2.1 Information Managed by Model . . . . . . . . . . . . . . . 5 87 2.2 The Preauth_Required Error . . . . . . . . . . . . . . . . 7 88 2.3 Client to KDC . . . . . . . . . . . . . . . . . . . . . . 7 89 2.4 KDC to Client . . . . . . . . . . . . . . . . . . . . . . 8 90 3. Pre-Authentication Facilities . . . . . . . . . . . . . . . . 9 91 3.1 Client Authentication . . . . . . . . . . . . . . . . . . 10 92 3.2 Strengthen Reply Key . . . . . . . . . . . . . . . . . . . 10 93 3.3 Replace Reply Key . . . . . . . . . . . . . . . . . . . . 11 94 3.4 Verify Response . . . . . . . . . . . . . . . . . . . . . 11 95 4. Requirements for Pre-Authentication Mechanisms . . . . . . . . 12 96 5. Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 13 97 5.1 Combine Keys . . . . . . . . . . . . . . . . . . . . . . . 13 98 5.2 Signing Requests/Responses . . . . . . . . . . . . . . . . 13 99 5.3 Managing State for the KDC . . . . . . . . . . . . . . . . 13 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 102 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 105 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 106 9.2 Informative References . . . . . . . . . . . . . . . . . . . 17 107 A. Todo List . . . . . . . . . . . . . . . . . . . . . . . . . . 18 108 Intellectual Property and Copyright Statements . . . . . . . . 19 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127Hartman Expires January 17, 2005 [Page 2] 128Internet-Draft Kerberos Preauth Framework July 2004 129 130 131 1321. Introduction 133 134 135 The core Kerberos specification treats pre-authentication data as an 136 opaque typed hole in the messages to the KDC that may influence the 137 reply key used to encrypt the KDC response. This generality has been 138 useful: pre-authentication data is used for a variety of extensions 139 to the protocol, many outside the expectations of the initial 140 designers. However, this generality makes designing the more common 141 types of pre-authentication mechanisms difficult. Each mechanism 142 needs to specify how it interacts with other mechanisms. Also, 143 problems like combining a key with the long-term secret or proving 144 the identity of the user are common to multiple mechanisms. Where 145 there are generally well-accepted solutions to these problems, it is 146 desirable to standardize one of these solutions so mechanisms can 147 avoid duplication of work. In other cases, a modular approach to 148 these problems is appropriate. The modular approach will allow new 149 and better solutions to common pre-authentication problems to be used 150 by existing mechanisms as they are developed. 151 152 153 This document specifies a framework for Kerberos pre-authentication 154 mechanisms. IT defines the common set of functions 155 pre-authentication mechanisms perform as well as how these functions 156 affect the state of the request and response. In addition several 157 common tools needed by pre-authentication mechanisms are provided. 158 Unlike [3], this framework is not complete--it does not describe all 159 the inputs and outputs for the pre-authentication mechanisms. 160 Mechanism designers should try to be consistent with this framework 161 because doing so will make their mechanisms easier to implement. 162 Kerberos implementations are likely to have plugin architectures for 163 pre-authentication; such architectures are likely to support 164 mechanisms that follow this framework plus commonly used extensions. 165 166 167 This document should be read only after reading the documents 168 describing the Kerberos cryptography framework [3] and the core 169 Kerberos protocol [2]. This document freely uses terminology and 170 notation from these documents without reference or further 171 explanation. 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187Hartman Expires January 17, 2005 [Page 3] 188Internet-Draft Kerberos Preauth Framework July 2004 189 190 191 1922. Model for Pre-Authentication 193 194 195 when a Kerberos client wishes to obtain a ticket using the 196 authentication server, it sends an initial AS request. If 197 pre-authentication is being used, then the KDC will respond with a 198 KDC_ERR_PREAUTH_REQUIRED error. Alternatively, if the client knows 199 what pre-authentication to use, it MAY optimize a round-trip and send 200 an initial request with padata included. If the client includes the 201 wrong padata, the server MAY return KDC_ERR_PREAUTH_FAILED with no 202 indication of what padata should have been included. For 203 interoperability reasons, clients that include optimistic 204 pre-authentication MUST retry with no padata and examine the 205 KDC_ERR_PREAUTH_REQUIRED if they receive a KDC_ERR_PREAUTH_FAILED in 206 response to their initial optimistic request. 207 208 209 The KDC maintains no state between two requests; subsequent requests 210 may even be processed by a different KDC. On the other hand, the 211 client treats a series of exchanges with KDCs as a single 212 authentication session. Each exchange accumulates state and 213 hopefully brings the client closer to a successful authentication. 214 215 216 These models for state management are in apparent conflict. For many 217 of the simpler pre-authentication scenarios, the client uses one 218 round trip to find out what mechanisms the KDC supports. Then the 219 next request contains sufficient pre-authentication for the KDC to be 220 able to return a successful response. For these simple scenarios, 221 the client only sends one request with pre-authentication data and so 222 the authentication session is trivial. For more complex 223 authentication sessions, the KDC needs to provide the client with a 224 cookie to include in future requests to capture the current state of 225 the authentication session. Handling of multiple round-trip 226 mechanisms is discussed in Section 5.3. 227 228 229 This framework specifies the behavior of Kerberos pre-authentication 230 mechanisms used to identify users or to modify the reply key used to 231 encrypt the KDC response. The padata typed hole may be used to carry 232 extensions to Kerberos that have nothing to do with proving the 233 identity of the user or establishing a reply key. These extensions 234 are outside the scope of this framework. However mechanisms that do 235 accomplish these goals should follow this framework. 236 237 238 This framework specifies the minimum state that a Kerberos 239 implementation needs to maintain while handling a request in order to 240 process pre-authentication. It also specifies how Kerberos 241 implementations process the pre-authentication data at each step of 242 the AS request process. 243 244 245 246 247 248 249Hartman Expires January 17, 2005 [Page 4] 250Internet-Draft Kerberos Preauth Framework July 2004 251 252 253 2542.1 Information Managed by Model 255 256 257 The following information is maintained by the client and KDC as each 258 request is being processed: 259 o The reply key used to encrypt the KDC response 260 o How strongly the identity of the client has been authenticated 261 o Whether the reply key has been used in this authentication session 262 o Whether the reply key has been replaced in this authentication 263 session 264 o Whether the contents of the KDC response can be verified by the 265 client principal 266 o Whether the contents of the KDC response can be verified by the 267 client machine 268 269 270 Conceptually, the reply key is initially the long-term key of the 271 principal. However, principals can have multiple long-term keys 272 because of support for multiple encryption types, salts and 273 string2key parameters. As described in section 5.2.7.5 of the 274 Kerberos protocol [2], the KDC sends PA-ETYPe-INFO2 to notify the 275 client what types of keys are available. Thus in full generality, 276 the reply key in the pre-authentication model is actually a set of 277 keys. At the beginning of a request, it is initialized to the set of 278 long-term keys advertised in the PA-ETYPE-INFO2 element on the KDC. 279 If multiple reply keys are available, the client chooses which one to 280 use. Thus the client does not need to treat the reply key as a set. 281 At the beginning of a handling a request, the client picks a reply 282 key to use. 283 284 285 KDC implementations MAY choose to offer only one key in the 286 PA-ETYPE-INFO2 element. Since the KDC already knows the client's 287 list of supported enctypes from the request, no interoperability 288 problems are created by choosing a single possible reply key. This 289 way, the KDC implementation avoids the complexity of treating the 290 reply key as a set. 291 292 293 At the beginning of handling a message on both the client and KDC, 294 the client's identity is not authenticated. A mechanism may indicate 295 that it has successfully authenticated the client's identity. This 296 information is useful to keep track of on the client in order to 297 know what pre-authentication mechanisms should be used. The KDC 298 needs to keep track of whether the client is authenticated because 299 the primary purpose of pre-authentication is to authenticate the 300 client identity before issuing a ticket. Implementations that have 301 pre-authentication mechanisms offering significantly different 302 strengths of client authentication MAY choose to keep track of the 303 strength of the authentication used as an input into policy 304 decisions. For example, some principals might require strong 305 pre-authentication, while less sensitive principals can use 306 307 308 309 310Hartman Expires January 17, 2005 [Page 5] 311Internet-Draft Kerberos Preauth Framework July 2004 312 313 314 315 relatively weak forms of pre-authentication like encrypted timestamp. 316 317 318 Initially the reply key has not been used. A pre-authentication 319 mechanism that uses the reply key either directly to encrypt or 320 checksum some data or indirectly in the generation of new keys MUST 321 indicate that the reply key is used. This state is maintained by the 322 client and KDC to enforce the security requirement stated in Section 323 3.3 that the reply key cannot be replaced after it is used. 324 325 326 Initially the reply key has not been replaced. If a mechanism 327 implements the Replace Reply Key facility discussed in Section 3.3, 328 then the state MUST be updated to indicate that the reply key has 329 been replaced. Once the reply key has been replaced, knowledge of the 330 reply key is insufficient to authenticate the client. The reply key 331 is marked replaced in exactly the same situations as the KDC reply 332 is marked as not being verified to the client principal. However, 333 while mechanisms can verify the KDC request to the client, once the 334 reply key is replaced, then the reply key remains replaced for the 335 remainder of the authentication session. 336 337 338 Without pre-authentication, the client knows that the KDC request is 339 authentic and has not been modified because it is encrypted in the 340 long-term key of the client. Only the KDC and client know that key. 341 So at the start of handling any message the KDC request is presumed 342 to be verified to the client principal. Any pre-authentication 343 mechanism that sets a new reply key not based on the principal's 344 long-term secret MUST either verify the KDC response some other way 345 or indicate that the response is not verified. If a mechanism 346 indicates that the response is not verified then the client 347 implementation MUST return an error unless a subsequent mechanism 348 verifies the response. The KDC needs to track this state so it can 349 avoid generating a response that is not verified. 350 351 352 The typical Kerberos request does not provide a way for the client 353 machine to know that it is talking to the correct KDC. Someone who 354 can inject packets into the network between the client machine and 355 the KDC and who knows the password that the user will give to the 356 client machine can generate a KDC response that will decrypt 357 properly. So, if the client machine needs to authenticate that the 358 user is in fact the named principal, then the client machine needs to 359 do a TGS request for itself as a service. Some pre-authentication 360 mechanisms may provide a way for the client to authenticate the KDC. 361 Examples of this include signing the response with a well-known 362 public key or providing a ticket for the client machine as a service 363 in addition to the requested ticket. 364 365 366 367 368 369 370 371Hartman Expires January 17, 2005 [Page 6] 372Internet-Draft Kerberos Preauth Framework July 2004 373 374 375 3762.2 The Preauth_Required Error 377 378 379 Typically a client starts an authentication session by sending an 380 initial request with no pre-authentication. If the KDC requires 381 pre-authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED 382 message. This message MAY also be returned for pre-authentication 383 configurations that use multi-round-trip mechanisms. This error 384 contains a sequence of padata. Typically the padata contains the 385 pre-authentication type IDs of all the available pre-authentication 386 mechanisms. IN the initial error response, most mechanisms do not 387 contain data. If a mechanism requires multiple round trips or starts 388 with a challenge from the KDC to the client, then it will likely 389 contain data in the initial error response. 390 391 392 The KDC SHOULD NOT send data that is encrypted in the long-term 393 password-based key of the principal. Doing so has the same security 394 exposures as the Kerberos protocol without pre-authentication. There 395 are few situations where pre-authentication is desirable and where 396 the KDC needs to expose ciphertext encrypted in a weak key before the 397 client has proven knowledge of that key. 398 399 400 In order to generate the error response, the KDC first starts by 401 initializing the pre-authentication state. Then it processes any 402 padata in the client's request in the order provided by the client. 403 Mechanisms that are not understood by the KDC are ignored. 404 Mechanisms that are inappropriate for the client principal or request 405 SHOULD also be ignored. Next, it generates padata for the error 406 response, modifying the pre-authentication state appropriately as 407 each mechanism is processed. The KDC chooses the order in which it 408 will generated padata (and thus the order of padata in the response), 409 but it needs to modify the pre-authentication state consistently with 410 the choice of order. For example, if some mechanism establishes an 411 authenticated client identity, then the mechanisms subsequent in the 412 generated response receive this state as input. After the padata is 413 generated, the error response is sent. 414 415 4162.3 Client to KDC 417 418 419 This description assumes a client has already received a 420 KDC_ERR_PREAUTH_REQUIRED from the KDC. If the client performs 421 optimistic pre-authentication then the client needs to optimisticly 422 choose the information it would normally receive from that error 423 response. 424 425 426 The client starts by initializing the pre-authentication state as 427 specified. It then processes the pdata in the 428 KDC_ERR_PREAUTH_REQUIRED. 429 430 431 432 433 434Hartman Expires January 17, 2005 [Page 7] 435Internet-Draft Kerberos Preauth Framework July 2004 436 437 438 439 After processing the pdata in the KDC error, the client generates a 440 new request. It processes the pre-authentication mechanisms in the 441 order in which they will appear in the next request, updating the 442 state as appropriate. When the request is complete it is sent. 443 444 4452.4 KDC to Client 446 447 448 When a KDC receives an AS request from a client, it needs to 449 determine whether it will respond with an error or a AS reply. 450 There are many causes for an error to be generated that have nothing 451 to do with pre-authentication; they are discussed in the Kerberos 452 specification. 453 454 455 From the standpoint of evaluating the pre-authentication, the KDC 456 first starts by initializing the pre-authentication state. IT then 457 processes the padata in the request. AS mentioned in Section 2.2, 458 the KDC MAY ignore padata that is inappropriate for the configuration 459 and MUST ignore padata of an unknown type. 460 461 462 At this point the KDC decides whether it will issue a 463 pre-authentication required error or a reply. Typically a KDC will 464 issue a reply if the client's identity has been authenticated to a 465 sufficient degree. The processing of the pre-authentication required 466 error is described in Section 2.2. 467 468 469 The KDC generates the pdata modifying the pre-authentication state as 470 necessary. Then it generates the final response, encrypting it in 471 the current pre-authentication reply key. 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496Hartman Expires January 17, 2005 [Page 8] 497Internet-Draft Kerberos Preauth Framework July 2004 498 499 500 5013. Pre-Authentication Facilities 502 503 504 Pre-Authentication mechanisms can be thought of as providing various 505 conceptual facilities. This serves two useful purposes. First, 506 mechanism authors can choose only to solve one specific small 507 problem. It is often useful for a mechanism designed to offer key 508 management not to directly provide client authentication but instead 509 to allow one or more other mechanisms to handle this need. Secondly, 510 thinking about the abstract services that a 2mechanism provides 511 yields a minimum set of security requirements that all mechanisms 512 providing that facility must meet. These security requirements are 513 not complete; mechanisms will have additional security requirements 514 based on the specific protocol they employ. 515 516 517 A mechanism is not constrained to only offering one of these 518 facilities. While such mechanisms can be designed and are sometimes 519 useful, many pre-authentication mechanisms implement several 520 facilities. By combining multiple facilities in a single mechanism, 521 it is often easier to construct a secure, simple solution than by 522 solving the problem in full generality. Even when mechanisms provide 523 multiple facilities, they need to meet the security requirements for 524 all the facilities they provide. 525 526 527 According to Kerberos extensibility rules (section 1.4.2 of the 528 Kerberos specification [2]), an extension MUST NOT change the 529 semantics of a message unless a recipient is known to understand that 530 extension. Because a client does not know that the KDC supports a 531 particular pre-authentication mechanism when it sends an initial 532 request, a preauth mechanism MUST NOT change the semantics of the 533 request in a way that will break a KDC that does not understand that 534 mechanism. Similarly, KDCs MUST not send messages to clients that 535 affect the core semantics unless the clients have indicated support 536 for the message. 537 538 539 The only state in this model that would break the interpretation of a 540 message is changing the expected reply key. If one mechanism changed 541 the reply key and a later mechanism used that reply key, then a KDC 542 that interpreted the second mechanism but not the first would fail to 543 interpret the request correctly. In order to avoid this problem, 544 extensions that change core semantics are typically divided into two 545 parts. The first part proposes a change to the core semantic--for 546 example proposes a new reply key. The second part acknowledges that 547 the extension is understood and that the change takes effect. Section 548 3.2 discusses how to design mechanisms that modify the reply key to 549 be split into a proposal and acceptance without requiring additional 550 round trips to use the new reply key in subsequent 551 pre-authentication. Other changes in the state described in Section 552 2.1 can safely be ignored by a KDC that does not understand a 553 554 555 556 557Hartman Expires January 17, 2005 [Page 9] 558Internet-Draft Kerberos Preauth Framework July 2004 559 560 561 562 mechanism. Mechanisms that modify the behavior of the request 563 outside the scope of this framework need to carefully consider the 564 Kerberos extensibility rules to avoid similar problems. 565 566 5673.1 Client Authentication 568 569 570 The client authentication facility proves the identity of a user to 571 the KDC before a ticket is issued. Examples of mechanisms 572 implementing this facility include the encrypted timestamp facility 573 defined in Section 5.2.7.2 of the Kerberos specification [2] and the 574 single-use mechanism defined in [5]. Mechanisms that provide this 575 facility are expected to mark the client as authenticated. 576 577 578 Mechanisms implementing this facility SHOULD require the client to 579 prove knowledge of the reply key before transmitting a successful 580 KDC reply. Otherwise, an attacker can intercept the 581 pre-authentication exchange and get a reply to attack. One way of 582 proving the client knows the reply key is to implement the Replace 583 Reply Key facility along with this facility. The Pkinit mechanism 584 [6] implements Client Authentication along side Replace Reply Key. 585 586 587 If the reply key has been replaced, then mechanisms such as encrypted 588 timestamp that rely on knowledge of the reply key to authenticate the 589 client MUST NOT be used. 590 591 5923.2 Strengthen Reply Key 593 594 595 Particularly, when dealing with keys based on passwords, it is 596 desirable to increase the strength of the key by adding additional 597 secrets to it. Examples of sources of additional secrets include the 598 results of a Diffie-Hellman key exchange or key bits from the output 599 of a smart card [5]. Typically these additional secrets are 600 converted into a Kerberos protocol key. Then they are combined with 601 the existing reply key as discussed in Section 5.1. 602 603 604 If a mechanism implementing this facility wishes to modify the reply 605 key before knowing that the other party in the exchange supports the 606 mechanism, it proposes modifying the reply key. The other party then 607 includes a message indicating that the proposal is accepted if it is 608 understood and meets policy. In many cases it is desirable to use 609 the new reply key for client authentication and for other facilities. 610 Waiting for the other party to accept the proposal and actually 611 modify the reply key state would add an additional round trip to the 612 exchange. Instead, mechanism designers are encouraged to include a 613 typed hole for additional padata in the message that proposes the 614 reply key change. The padata included in the typed hole are 615 generated assuming the new reply key. If the other party accepts the 616 proposal, then these padata are interpreted as if they were included 617 618 619 620 621Hartman Expires January 17, 2005 [Page 10] 622Internet-Draft Kerberos Preauth Framework July 2004 623 624 625 626 immediately following the proposal. The party generating the 627 proposal can determine whether the padata were processed based on 628 whether the proposal for the reply key is accepted. 629 630 631 The specific formats of the proposal message, including where padata 632 are are included is a matter for the mechanism specification. 633 Similarly, the format of the message accepting the proposal is 634 mechanism-specific. 635 636 637 Mechanisms implementing this facility and including a typed hole for 638 additional padata MUST checksum that padata using a keyed checksum or 639 encrypt the padata. Typically the reply key is used to protect the 640 padata. XXX If you are only minimally increasing the strength of the 641 reply key, this may give the attacker access to something too close 642 to the original reply key. However, binding the padata to the new 643 reply key seems potentially important from a security standpoint. 644 There may also be objections to this from a double encryption 645 standpoint because we also recommend client authentication facilities 646 be tied to the reply key. 647 648 6493.3 Replace Reply Key 650 651 652 The Replace Reply Key facility replaces the key in which a successful 653 AS reply will be encrypted. This facility can only be used in 654 cases where knowledge of the reply key is not used to authenticate 655 the client. The new reply key MUST be communicated to the client and 656 KDC in a secure manner. Mechanisms implementing this facility MUST 657 mark the reply key as replaced in the pre-authentication state. 658 Mechanisms implementing this facility MUST either provide a mechanism 659 to verify the KDC reply to the client or mark the reply as unverified 660 in the pre-authentication state. Mechanisms implementing this 661 facility SHOULD NOT be used if a previous mechanism has used the 662 reply key. 663 664 665 As with the Strengthen Reply Key facility, Kerberos extensibility 666 rules require that the reply key not be changed unless both sides of 667 the exchange understand the extension. In the case of this facility 668 it will likely be more common for both sides to know that the 669 facility is available by the time that the new key is available to be 670 used. However, mechanism designers can use a container for padata in 671 a proposal message as discussed in Section 3.2 if appropriate. 672 673 6743.4 Verify Response 675 676 677 678 679 680 681 682 683 684Hartman Expires January 17, 2005 [Page 11] 685Internet-Draft Kerberos Preauth Framework July 2004 686 687 688 6894. Requirements for Pre-Authentication Mechanisms 690 691 692 State management for multi-round-trip mechs 693 Security interactions with other mechs 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742Hartman Expires January 17, 2005 [Page 12] 743Internet-Draft Kerberos Preauth Framework July 2004 744 745 746 7475. Tools for Use in Pre-Authentication Mechanisms 748 749 7505.1 Combine Keys 751 752 7535.2 Signing Requests/Responses 754 755 7565.3 Managing State for the KDC 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802Hartman Expires January 17, 2005 [Page 13] 803Internet-Draft Kerberos Preauth Framework July 2004 804 805 806 8076. IANA Considerations 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859Hartman Expires January 17, 2005 [Page 14] 860Internet-Draft Kerberos Preauth Framework July 2004 861 862 863 8647. Security Considerations 865 866 867 Very little of the AS request is authenticated. Same for padata 868 in the reply or error. Discuss implications 869 Table of security requirements stated elsewhere in the document 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917Hartman Expires January 17, 2005 [Page 15] 918Internet-Draft Kerberos Preauth Framework July 2004 919 920 921 9228. Acknowledgements 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974Hartman Expires January 17, 2005 [Page 16] 975Internet-Draft Kerberos Preauth Framework July 2004 976 977 978 9799. References 980 981 9829.1 Normative References 983 984 985 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 986 Levels", RFC 2119, BCP 14, March 1997. 987 988 989 [2] Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos 990 Network Authentication Service (V5)", 991 draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in 992 progress), June 2004. 993 994 995 [3] Raeburn, K., "Encryption and Checksum Specifications for 996 Kerberos 5", draft-ietf-krb-wg-crypto-03.txt (work in progress). 997 998 999 [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1000 2279, January 1998. 1001 1002 10039.2 Informative References 1004 1005 1006 [5] Hornstein, K., Renard, K., Neuman, C. and G. Zorn, "Integrating 1007 Single-use Authentication Mechanisms with Kerberos", 1008 draft-ietf-krb-wg-kerberos-sam-02.txt (work in progress), 1009 October 2003. 1010 1011 1012 [6] Tung, B., Neuman, C., Hur, M., Medvinsky, A. and S. Medvinsky, 1013 "Public Key Cryptography for Initial Authentication in 1014 Kerberos", draft-ietf-cat-kerberos-pk-init-19.txt (work in 1015 progress), April 2004. 1016 1017 1018 1019Author's Address 1020 1021 1022 Sam hartman 1023 MIT 1024 1025 1026 EMail: hartmans@mit.edu 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042Hartman Expires January 17, 2005 [Page 17] 1043Internet-Draft Kerberos Preauth Framework July 2004 1044 1045 1046 1047Appendix A. Todo List 1048 1049 1050 Flesh out sections that are still outlines 1051 Discuss cookies and multiple-round-trip mechanisms. 1052 Talk about checksum contributions from each mechanism 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100Hartman Expires January 17, 2005 [Page 18] 1101Internet-Draft Kerberos Preauth Framework July 2004 1102 1103 1104 1105Intellectual Property Statement 1106 1107 1108 The IETF takes no position regarding the validity or scope of any 1109 Intellectual Property Rights or other rights that might be claimed to 1110 pertain to the implementation or use of the technology described in 1111 this document or the extent to which any license under such rights 1112 might or might not be available; nor does it represent that it has 1113 made any independent effort to identify any such rights. Information 1114 on the IETF's procedures with respect to rights in IETF Documents can 1115 be found in BCP 78 and BCP 79. 1116 1117 1118 Copies of IPR disclosures made to the IETF Secretariat and any 1119 assurances of licenses to be made available, or the result of an 1120 attempt made to obtain a general license or permission for the use of 1121 such proprietary rights by implementers or users of this 1122 specification can be obtained from the IETF on-line IPR repository at 1123 http://www.ietf.org/ipr. 1124 1125 1126 The IETF invites any interested party to bring to its attention any 1127 copyrights, patents or patent applications, or other proprietary 1128 rights that may cover technology that may be required to implement 1129 this standard. Please address the information to the IETF at 1130 ietf-ipr@ietf.org. 1131 1132 1133 1134Disclaimer of Validity 1135 1136 1137 This document and the information contained herein are provided on an 1138 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1139 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1140 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1141 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1142 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1143 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1144 1145 1146 1147Copyright Statement 1148 1149 1150 Copyright (C) The Internet Society (2004). This document is subject 1151 to the rights, licenses and restrictions contained in BCP 78, and 1152 except as set forth therein, the authors retain all their rights. 1153 1154 1155 1156Acknowledgment 1157 1158 1159 Funding for the RFC Editor function is currently provided by the 1160 Internet Society. 1161 1162 1163 1164 1165Hartman Expires January 17, 2005 [Page 19]