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