1NETWORK WORKING GROUP N. Williams 2Internet-Draft Sun 3Expires: December 30, 2004 July 2004 4 5 6 7 Guide to the GSS-APIv3 8 draft-williams-gssapi-v3-guide-to-00.txt 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 22 other groups may also distribute working documents as 23 Internet-Drafts. 24 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 34 35 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 38 39 40 This Internet-Draft will expire on December 30, 2004. 41 42 43Copyright Notice 44 45 46 Copyright (C) The Internet Society (2004). All Rights Reserved. 47 48 49Abstract 50 51 52 Extensions to the GSS-APIv2 are needed for a number of reasons. This 53 documents describes the extensions being proposed, the resons, 54 possible future directions, and portability, IANA and security 55 considerations. This document does not define any protocol or 56 interface and is purely informational. 57 58 59 60 61 62 63 64 65 66Williams Expires December 30, 2004 [Page 1] 67Internet-Draft Guide to the GSS-APIv3 July 2004 68 69 70 71Table of Contents 72 73 74 1. Conventions used in this document . . . . . . . . . . . . . . 3 75 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. A Pseudo-Mechanism OID for the GSS-API Itself . . . . . . . . 5 77 4. Mechanism Attribute Inquiry Facilities . . . . . . . . . . . . 6 78 5. Security Context Extensibility Extensions . . . . . . . . . . 7 79 6. Credential Extensibility Extensions . . . . . . . . . . . . . 8 80 7. Credential Export/Import . . . . . . . . . . . . . . . . . . . 9 81 8. GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 10 82 9. Pseudo-Mechanism Stacking . . . . . . . . . . . . . . . . . . 11 83 10. Naming Extensions . . . . . . . . . . . . . . . . . . . . . . 12 84 11. Additional Name Types . . . . . . . . . . . . . . . . . . . . 13 85 12. GSS_Pseudo_random() . . . . . . . . . . . . . . . . . . . . . 14 86 13. Channel Bindings Specifications . . . . . . . . . . . . . . . 15 87 14. Semantic and Miscallaneous Extensions . . . . . . . . . . . . 16 88 15. Portability Considerations . . . . . . . . . . . . . . . . . . 17 89 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 17. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 18. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 93 Intellectual Property and Copyright Statements . . . . . . . . 20 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124Williams Expires December 30, 2004 [Page 2] 125Internet-Draft Guide to the GSS-APIv3 July 2004 126 127 128 1291. Conventions used in this document 130 131 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182Williams Expires December 30, 2004 [Page 3] 183Internet-Draft Guide to the GSS-APIv3 July 2004 184 185 186 1872. Introduction 188 189 190 [NOTE: the references section is current fairly empty; the various 191 KITTEN WG work items will be added to this I-D in a subsequent 192 revision.] 193 194 195 Since the advent of the GSS-APIv2 it has come to be used in a number 196 of Internet (and other) protocols and a number of implementations 197 exist. In that time implementors and protocol designers have come to 198 understand both, the GSS-API's strengths, and its shortcommings; we 199 believe now that a number of extensions to the GSS-API are needed. 200 Here these proposed extensions, forming what we may call the GSS-API 201 version 3, are described at a high-level.; 202 203 204 Some of these extensions are intended to facilitate further 205 extensions, so that further major revisions to the GSS-API may not be 206 necessary. Others are intended to fill voids in the the GSS-APIv2. 207 208 209 The extensions being proposed are: 210 A pseudo-mechanism OID for the GSS-API itself 211 Mechanism attribute inquiry facilities 212 Security context extensibility extensions 213 Credential extensibility extensions 214 Credential export/import 215 GSS_Store_cred(), for making delegated credentials available for 216 acquisition 217 Pseudo-mechanism stacking 218 Naming extensions, to facilitate authorization by identifiers 219 other than names 220 Additional name types, specifically domain-based naming 221 A pseudo-random function interface 222 Channel bindings specifications 223 Semantic extensions relating to thread- and/or fork-safety 224 [Have I missed anything? I have a feeling I have. Re-keying?] 225 ... 226 227 228 Additionally, because we foresee future minor extensions, including, 229 specifically, extensions which may impact the various namespaces 230 associated with APIs (symbol names, constant values, class names, 231 etc...) we also propose the establishment of IANA registries for 232 these namespaces. 233 234 235 236 237 238 239 240 241 242 243 244Williams Expires December 30, 2004 [Page 4] 245Internet-Draft Guide to the GSS-APIv3 July 2004 246 247 248 2493. A Pseudo-Mechanism OID for the GSS-API Itself 250 251 252 A mechanism OID is assigned to identify and refer to the GSS-API 253 iself. This is necessary to enable the use of extended inquiry 254 interfaces to inquire about features of a GSS-API implementation 255 specifically, apart from actual mechanisms. 256 257 258 But also, this OID is needed for better error handling, so that minor 259 status codes produced in generic contexts that lack a mechanism OID 260 can be distinguished from minor status codes for a "default" 261 mechanism and properly displayed. 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303Williams Expires December 30, 2004 [Page 5] 304Internet-Draft Guide to the GSS-APIv3 July 2004 305 306 307 3084. Mechanism Attribute Inquiry Facilities 309 310 311 In the course of designing a pseudo-mechanism stacking facility, as 312 well as while considering the impact of all of these extensions on 313 portability, a need for interfaces through which to discover or 314 inquire by features provided by GSS-API mechanisms was discovered. 315 316 317 The proposed mechanism attribute inquiry interfaces consist of: 318 GSS_Inquire_mech_attrs_for_mech() 319 GSS_Indicate_mechs_by_mech_attrs() 320 GSS_Display_mech_attr() 321 322 323 These extensions facilitate portability by allowing GSS-APIv3 324 applications to discover the features provided by a given 325 implementation of the GSS-API or any mechanisms. These extensions 326 are also useful in facilitating stackable pseudo-mechanisms. 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363Williams Expires December 30, 2004 [Page 6] 364Internet-Draft Guide to the GSS-APIv3 July 2004 365 366 367 3685. Security Context Extensibility Extensions 369 370 371 In order to facilitate future security context options we introduce a 372 GSS_Create_sec_context() interface that creates a security context 373 object, for use with extensions and with GSS_Init_sec_context(), 374 GSS_Accept_sec_context(), and GSS_Inquire_sec_context(). Such 375 security contexts are in a non-established state until they are 376 established through the use of GSS_Init_sec_context() or 377 GSS_Accept_sec_context(). 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421Williams Expires December 30, 2004 [Page 7] 422Internet-Draft Guide to the GSS-APIv3 July 2004 423 424 425 4266. Credential Extensibility Extensions 427 428 429 In order to facilitate future extensions to GSS credentials we 430 introduce a GSS_Create_credential(), similar to 431 GSS_Create_sec_context(), interface that creates an "empty" 432 credential. 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479Williams Expires December 30, 2004 [Page 8] 480Internet-Draft Guide to the GSS-APIv3 July 2004 481 482 483 4847. Credential Export/Import 485 486 487 To allow for passing of credentials between different "session 488 contexts," between different hosts, or for storage of post-dated 489 credentials, we introduce a credential export/import facility, much 490 like the security context export/import facility of the GSS-APIv2. 491 492 493 Together with credential extensibility and other extensions this 494 facility may allow for: 495 Credential delegation at any time 496 Post-dated credentials, and storage of the such for subsequent 497 use. 498 ...? 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538Williams Expires December 30, 2004 [Page 9] 539Internet-Draft Guide to the GSS-APIv3 July 2004 540 541 542 5438. GSS_Store_cred() 544 545 546 This extension fills a void in the GSS-APIv2 where delegated 547 credentials could not be used except in the context of the same 548 process that received them. With this extension acceptor 549 applications can now make delegated credentials available for use, 550 with GSS_Acquire_cred() et. al., in other process contexts. 551 552 553 [Manipulation of "credential stores" is (may be?) out of scope for 554 this document.] 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597Williams Expires December 30, 2004 [Page 10] 598Internet-Draft Guide to the GSS-APIv3 July 2004 599 600 601 6029. Pseudo-Mechanism Stacking 603 604 605 A number of pseudo-mechanisms are being proposed which are designed 606 to "stack" atop other mechanisms. The possiblities are many, 607 including: a compression mechanism, a perfect forward security 608 mechanism, an many others. 609 610 611 The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism 612 (SPNEGO) available. With this proposal the mechanism taxonomy is 613 quite expanded: 614 Concrete mechanisms (e.g., the Kerberos V mechanism) 615 Composite mechanisms (a concrete mechanism composed with one or 616 more stackable pseudo-mechanisms) 617 Stackable pseudo-mechanisms 618 Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself) 619 620 621 Although composed mechanisms may be made available for use by 622 GSS-APIv2 applications without any further extensions, use of 623 stackable pseudo-mechanisms can complicate mechanism negotiation; 624 additionally, discovery of mechanisms appropriate for use in one or 625 another context would require hard-coding information about them in 626 GSS-APIv2 applications. Extensions to the GSS-APIv2 could facilitate 627 use of composite. 628 629 630 The mechanism attribute inquiry facilities, together with the 631 forllowing additional interfaces, provide for a complete interface to 632 mechanism composition and for managing the complexity of mechanism 633 negotiation: 634 GSS_Compose_oid() 635 GSS_Decompose_oid() 636 GSS_Release_oid() 637 GSS_Indicate_negotiable_mechs() 638 GSS_Negotiate_mechs() 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658Williams Expires December 30, 2004 [Page 11] 659Internet-Draft Guide to the GSS-APIv3 July 2004 660 661 662 66310. Naming Extensions 664 665 666 Some applications make use of exported names, as produced by 667 GSS_Export_name(), to create/manage/evaluate access control lists; we 668 call this name-based authorization. 669 670 671 Exported names typically encode names that are meant for display to 672 humans, not internal identifiers. 673 674 675 In practice this creates a number of problems. E.g., the referential 676 integrity of such access control lists is hard to maintain as 677 principals are added, removed, renamed or old principal names reused. 678 679 680 Additionally, some mechanisms may lack a notion of a "canonical" name 681 for some or all of their principals. Such mechanisms cannot be used 682 by applications that rely on name-based authorization. 683 684 685 <Describe the proposed extensions in this area.> 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 720Williams Expires December 30, 2004 [Page 12] 721Internet-Draft Guide to the GSS-APIv3 July 2004 722 723 724 72511. Additional Name Types 726 727 728 <Decribe domain-based names and the need for them.> 729 730 731 732 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 778Williams Expires December 30, 2004 [Page 13] 779Internet-Draft Guide to the GSS-APIv3 July 2004 780 781 782 78312. GSS_Pseudo_random() 784 785 786 <Decribe GSS_Pseudo_random() and the need for it.> 787 788 789 790 791 792 793 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 836Williams Expires December 30, 2004 [Page 14] 837Internet-Draft Guide to the GSS-APIv3 July 2004 838 839 840 84113. Channel Bindings Specifications 842 843 844 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 893Williams Expires December 30, 2004 [Page 15] 894Internet-Draft Guide to the GSS-APIv3 July 2004 895 896 897 89814. Semantic and Miscallaneous Extensions 899 900 901 The GSS-APIv2 specifications say nothing about the thread-safety, 902 much less the fork-safety, of the GSS-API. Thread-safety and 903 fork-safety are, after all, platform- and/or language-specific 904 matters. But as support for multi-threading spreads the matter of 905 thread-safety cannot be avoided. The matter of fork-safety is 906 specific to platforms that provide a "fork()" function, or similar. 907 908 909 <describe the GSS-APIv3's thread-safety requirements> 910 911 912 <reference the portability considerations section> 913 914 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 951 952 953Williams Expires December 30, 2004 [Page 16] 954Internet-Draft Guide to the GSS-APIv3 July 2004 955 956 957 95815. Portability Considerations 959 960 961 The potential for additional generic, mechanism-specific, language 962 binding-specific and, most importantly, semantic extensions to the 963 GSS-APIv3 may create application portability problems. The mechanism 964 attribute inquiry facilities of the GSS-APIv3 and the 965 pseudo-mechanism OID for the GSS-API itself double as a run-time 966 facility for discovery of feature availability. Run-time feature 967 discovery facilities, in turn, can be used at application build-time 968 as well by building small applications to display the available 969 features. 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 1007 1008 1009 1010 1011 1012Williams Expires December 30, 2004 [Page 17] 1013Internet-Draft Guide to the GSS-APIv3 July 2004 1014 1015 1016 101716. IANA Considerations 1018 1019 1020 <Describe the namespace issues associated with future minor 1021 extensions to the GSS-APIv3 and the IANA registries to be created to 1022 cope with them.> 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 1063 1064 1065 1066 1067 1068 1069 1070Williams Expires December 30, 2004 [Page 18] 1071Internet-Draft Guide to the GSS-APIv3 July 2004 1072 1073 1074 107517. Security Considerations 1076 1077 1078 <...> 1079 1080 108118 Normative 1082 1083 1084 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1085 Requirement Levels", BCP 14, RFC 2119, March 1997. 1086 1087 1088 [RFC2743] Linn, J., "Generic Security Service Application Program 1089 Interface Version 2, Update 1", RFC 2743, January 2000. 1090 1091 1092 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 1093 C-bindings", RFC 2744, January 2000. 1094 1095 1096 1097Author's Address 1098 1099 1100 Nicolas Williams 1101 Sun Microsystems 1102 5300 Riata Trace Ct 1103 Austin, TX 78727 1104 US 1105 1106 1107 EMail: Nicolas.Williams@sun.com 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135Williams Expires December 30, 2004 [Page 19] 1136Internet-Draft Guide to the GSS-APIv3 July 2004 1137 1138 1139 1140Intellectual Property Statement 1141 1142 1143 The IETF takes no position regarding the validity or scope of any 1144 Intellectual Property Rights or other rights that might be claimed to 1145 pertain to the implementation or use of the technology described in 1146 this document or the extent to which any license under such rights 1147 might or might not be available; nor does it represent that it has 1148 made any independent effort to identify any such rights. Information 1149 on the procedures with respect to rights in RFC documents can be 1150 found in BCP 78 and BCP 79. 1151 1152 1153 Copies of IPR disclosures made to the IETF Secretariat and any 1154 assurances of licenses to be made available, or the result of an 1155 attempt made to obtain a general license or permission for the use of 1156 such proprietary rights by implementers or users of this 1157 specification can be obtained from the IETF on-line IPR repository at 1158 http://www.ietf.org/ipr. 1159 1160 1161 The IETF invites any interested party to bring to its attention any 1162 copyrights, patents or patent applications, or other proprietary 1163 rights that may cover technology that may be required to implement 1164 this standard. Please address the information to the IETF at 1165 ietf-ipr@ietf.org. 1166 1167 1168 1169Disclaimer of Validity 1170 1171 1172 This document and the information contained herein are provided on an 1173 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1174 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1175 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1176 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1177 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1178 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1179 1180 1181 1182Copyright Statement 1183 1184 1185 Copyright (C) The Internet Society (2004). This document is subject 1186 to the rights, licenses and restrictions contained in BCP 78, and 1187 except as set forth therein, the authors retain all their rights. 1188 1189 1190 1191Acknowledgment 1192 1193 1194 Funding for the RFC Editor function is currently provided by the 1195 Internet Society. 1196 1197 1198 1199 1200Williams Expires December 30, 2004 [Page 20]