1 2 3 4 5Network Working Group S. Hartman 6Internet-Draft MIT 7Expires: December 4, 2005 June 2, 2005 8 9 10 Desired Enhancements to GSSAPI Naming 11 draft-ietf-kitten-gss-naming-02.txt 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 December 4, 2005. 37 38Copyright Notice 39 40 Copyright (C) The Internet Society (2005). 41 42Abstract 43 44 The Generic Security Services API (GSS-API) provides a naming 45 architecture that supports name-based authorization. GSS-API 46 authenticates two named parties to each other. Names can be stored 47 on access control lists to make authorization decisions. Advances in 48 security mechanisms and the way implementers wish to use GSS-API 49 require this model to be extended. As people move within an 50 organization or change their names, the name authenticated by GSS-API 51 may change. Using some sort of constant identifier would make ACLs 52 more stable. Some mechanisms such as public-key mechanisms do not 53 54 55 56Hartman Expires December 4, 2005 [Page 1] 57 58Internet-Draft GSS Names June 2005 59 60 61 have a single name to be used across all environments. Other 62 mechanisms such as Kerberos include may include group membership or 63 role information as part of authentication. This document motivates 64 extensions to GSS-API naming and describes the extensions under 65 discussion. 66 67 68 69 70 71 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 110 111 112Hartman Expires December 4, 2005 [Page 2] 113 114Internet-Draft GSS Names June 2005 115 116 1171. Introduction 118 119 The Generic Security Services API [2] authenticates two named parties 120 to each other. GSS names can be imported in a variety of formats 121 through the gss_import_name call. Several mechanism-independent name 122 formats are provided including GSS_C_NT_HOSTBASED_SERVICE for 123 services running on an Internet host and GSS_C_NT_USER_NAME for the 124 names of users. Other mechanism-specific name types are also 125 provided. By the time a name is used in acquiring a mechanism- 126 specific credential or establishing a security context, it has been 127 transformed into one of these mechanism-specific name types. In 128 addition, the GSS-API provides a function called gss_export_name that 129 will flatten a GSS-API name into a binary blob suitable for 130 comparisons. This binary blob can be stored on ACLs and then 131 authorization decisions can be made simply by comparing the name 132 exported from a newly accepted context to the name on the ACL. 133 134 Storing names on ACLs can be problematic because names tend to change 135 over time . If the name contains organizational information such as 136 a domain part or an indication of what department someone works for, 137 this changes as the person moves around the organization. Even if no 138 organizational information is included in the name, the name will 139 change as people change their names. Updating ACLs to reflect name 140 changes is difficult. Another significant problem is that names can 141 be reused to apply to another entity than the entity to which they 142 originally applied. For example if a Unix user ID is placed on an 143 ACL, the account deleted and then a new user assigned the old ID, 144 then that new user may gain privileges intended for the old user. 145 146 Inherent in the GSS naming model is the idea that mechanism names 147 need to be able to be represented in a single canonical form. Anyone 148 importing that name needs to be able to retrieve the canonical form 149 of that name. 150 151 Several security mechanisms have been proposed for which this naming 152 architecture is too restrictive. In some cases it is not always 153 possible to canonicalize any name that is imported. In other cases 154 there is no single canonical name. 155 156 Also, as GSS-API is used in more complex environments, there is a 157 desire to use attribute certificates [6], Kerberos authorization data 158 [3], or other non-name-based authorization models. GSS-API needs to 159 be enhanced in order to support these uses in a mechanism-independent 160 manner. 161 162 This document discusses the particular naming problems with two 163 important classes of GSS-API mechanisms. It also discusses the set 164 of proposed solutions and open issues with these solutions. This 165 166 167 168Hartman Expires December 4, 2005 [Page 3] 169 170Internet-Draft GSS Names June 2005 171 172 173 draft limits discussion to these solutions and provides a description 174 of the problem against which the solutions can be judged. 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224Hartman Expires December 4, 2005 [Page 4] 225 226Internet-Draft GSS Names June 2005 227 228 2292. Kerberos Naming 230 231 The Kerberos mechanism demonstrates both the naming stability problem 232 and the authorization extension problem. 233 234 The Kerberos Referrals draft [4] proposes a new type of Kerberos name 235 called an enterprise name. The intent is that the enterprise name is 236 an alias that the user knows for themselves and can use to login. 237 The Kerberos KDC translates this name into a normal Kerberos 238 principal and gives the user tickets for this principal. This normal 239 principal is used for authorization. The intent is that the 240 enterprise name tracks the user as they move throughout the 241 organization, even if they move to parts of the organization that 242 have different naming policies. The name they type at login remains 243 constant, but the Kerberos principal used to authenticate them to 244 services changes. 245 246 Performing a mapping from enterprise name to principal name is not 247 generally possible for unauthenticated services. Even authenticated 248 services may not be authorized to perform this mapping except for 249 their own name. Also, Kerberos does not (and does not plan to) 250 provide a mechanism for mapping enterprise names to principals 251 besides authentication as the enterprise name. Thus, any such 252 mapping would be vendor-specific. With this feature in Kerberos, it 253 is not possible to implement gss_canonicalize_name for enterprise 254 name types. 255 256 Another issue arises with enterprise names. IN some cases it would 257 be desirable to put the enterprise name on the ACL instead of a 258 principal name for greater ACL stability. At first glance this could 259 be accomplished by including the enterprise name in the name exported 260 by gss_export_name. Unfortunately, if this were done, the exported 261 name would change whenever the mapping changed, invalidating any ACL 262 entries based off the old exported name and defeating the purpose of 263 including the enterprise name in the exported name. In some cases it 264 would be desirable to have the exported name be based on the 265 enterprise name and in others based on the principal name, but this 266 is not permitted by the current GSS-API. 267 268 Another development also complicates GSS-API naming for Kerberos. 269 Several vendors have been looking at mechanisms to include group 270 membership information in Kerberos authorization data. It is 271 desirable to put these group names on ACLs. Again, GSS-API currently 272 has no mechanism to use this information. 273 274 275 276 277 278 279 280Hartman Expires December 4, 2005 [Page 5] 281 282Internet-Draft GSS Names June 2005 283 284 2853. X.509 Names 286 287 X.509 names are more complicated than Kerberos names. In the 288 Kerberos case there is a single principal carried in all Kerberos 289 messages. X.509 certificates have multiple options. It seems the 290 subject name might be the appropriate name to use as the name to be 291 exported in a GSS-API mechanism. However RFC 3280 [5] does not even 292 require the subject name to be a non-empty sequence. Instead there 293 are cases where the subjectAltName extension is the only thing to 294 identify the subject of the certificate. As in the case of Kerberos 295 group memberships, there may be many subjectAltName extensions 296 available in a certificate. Different applications will care about 297 different extensions. One possible candidate for an exported name 298 would be all the names and SubjectAltName extensions from a 299 certificate. However as new names are added then existing ACL 300 entries would be invalidated; this is undesirable. Thus there is no 301 single value that can be defined as the exported GSS-API name that 302 will be useful in all environments. 303 304 A profile of a particular X.509 GSS-API mechanism could require a 305 specific name be used. However this would limit that mechanism to 306 require a particular type of certificate. There is interest in being 307 able to use arbitrary X.509 certificates with GSS-API for some 308 applications. 309 310 Experience so far has not lead to sufficient interoperability with 311 GSS-API X.509 mechanisms. Even if the subject name is used, there is 312 ambiguity in how to handle sorting of name components. Martin Rex 313 said that he was aware of several SPKM [1] implementations but no two 314 were fully interoperable on names. 315 316 Also, as discussed in the introduction, it is desirable to support 317 X.509 attribute certificates. 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336Hartman Expires December 4, 2005 [Page 6] 337 338Internet-Draft GSS Names June 2005 339 340 3414. Composite Names 342 343 One proposal to solve these problems is to extend the concept of a 344 GSS-API name to include a set of name attributes. Each attribute 345 would be an octet-string labeled by an OID. Examples of attributes 346 would include Kerberos enterprise names, group memberships in an 347 authorization infrastructure, Kerberos authorization data attributes 348 and subjectAltName attributes in a certificate. Several new 349 operations would be needed: 350 351 1. Add an attribute to name. 352 353 2. Query attributes of name. 354 355 3. Query values of an attribute. 356 357 4. Delete an attribute from a name. 358 359 5. Export a complete composite name and all its attributes for 360 transport between processes. 361 362 Note that an exported composite name would not generally be suitable 363 for binary comparison. Avoiding confusion between this operation and 364 the existing gss_export_name operation will require careful work. 365 366 Additional utility operations will probably be needed depending on 367 the implementation of name attributes. 368 3694.1 Usage of Name Attributes 370 371 Since attributes are part of GSS-API names, the acceptor can retrieve 372 the attributes of the initiator's and acceptor's name from the 373 context. These attributes can then be used for authorization. 374 375 Most name attributes will probably not come from explicit operations 376 to add attributes to a name. Instead, name attributes will probably 377 come from mechanism specific credentials. Components of these 378 mechanism specific credentials may come from platform or environment- 379 specific names. Mechanism specific naming and group membership can 380 be mapped into name attributes by the mechanism implementation. The 381 specific form of this mapping will generally require protocol 382 specification for each mechanism. 383 384 The value of many name attributes may be suitable for use in binary 385 comparison. This should enable applications to use these name 386 attributes on ACLs the same way exported names are now used on ACLs. 387 For example if a particular Subjectaltname extension contains the 388 appropriate identity for an application, then the name attribute 389 390 391 392Hartman Expires December 4, 2005 [Page 7] 393 394Internet-Draft GSS Names June 2005 395 396 397 for this Subjectaltname can be placed on the ACL. This is only true 398 if the name attribute is stored in some canonical form. 399 4004.2 Open issues 401 402 This section describes parts of the proposal to add attributes to 403 names that will need to be explored before the proposal can become a 404 protocol specification. 405 406 Are mechanisms expected to be able to carry arbitrary name attributes 407 as part of a context establishment? At first it seems like this 408 would be desirable. However the purpose of GSS-API is to establish 409 an authenticated context between two peers. In particular, a context 410 authenticates two named entities to each other. The names of these 411 entities and attributes associated with these names will be used for 412 authorization decisions. If an initiator or acceptor is allowed to 413 assert name attributes and the authenticity of these assertions is 414 not validated by the mechanisms, then security problems will result. 415 On the other hand, requiring that name attributes be mechanism 416 specific and only be carried by mechanisms that understand the name 417 attributes and can validate them compromises GSS-API's place as a 418 generic API. Application authors would be forced to understand 419 mechanism-specific attributes to make authorization decisions. In 420 addition if mechanisms are not required to transport arbitrary 421 attributes, then application authors will need to deal with different 422 implementations of the same mechanism that support different sets of 423 name attributes. One possible solution is to carry a source along 424 with each name attribute; this source could indicate whether the 425 attribute comes from a mechanism data structure or from the other 426 party in the authentication. 427 428 Another related question is how will name attributes be mapped into 429 their mechanism-specific forms. For example it would be desirable to 430 map many Kerberos authorization data elements into name attributes. 431 In the case of the Microsoft PAC, it would be desirable for some 432 applications to get the entire PAC. However in many cases, the 433 specific lists of security IDs contained in the PAC would be more 434 directly useful to an application. So there may not be a good one- 435 to-one mapping between the mechanism-specific elements and the 436 representation desirable at the GSS-API layer. 437 438 Specific name matching rules need to be developed. How do names with 439 attributes compare? What is the effect of a name attribute on a 440 target name in gss_accept_sec_context? 441 4424.3 Handling gss_export_name 443 444 For many mechanisms, there will be an obvious choice to use for the 445 446 447 448Hartman Expires December 4, 2005 [Page 8] 449 450Internet-Draft GSS Names June 2005 451 452 453 name exported by gss_export_name. For example in the case of 454 Kerberos, the principal name can continue to be used as the exported 455 name. This will allow applications depending on existing GSS-API 456 name-based authorization to continue to work. However it is probably 457 desirable to allow GSS-API mechanisms for which gss_export_name 458 cannot meaningfully be defined. The behavior of gss_export_name in 459 such cases should probably be to return some error. Such mechanisms 460 may not work with existing applications and cannot conform to the 461 current version of the GSS-API. 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504Hartman Expires December 4, 2005 [Page 9] 505 506Internet-Draft GSS Names June 2005 507 508 5095. Credential Extensions 510 511 An alternative to the name attributes proposal is to extend GSS-API 512 credentials with extensions labeled by OIDs. Interfaces would be 513 needed to manipulate these credential extensions and to retrieve the 514 credential extensions for credentials used to establish a context. 515 Even if name attributes are used, credential extensions may be useful 516 for other unrelated purposes. 517 518 It is possible to solve problems discussed in this document using 519 some credential extension mechanism. Doing so will have many of the 520 same open issues as discussed in the composite names proposal. The 521 main advantage of a credential extensions proposal is that it avoids 522 specifying how name attributes interact with name comparison or 523 target names. 524 525 The primary advantage of the name attributes proposal over credential 526 extensions is that name attributes seem to fit better into the GSS- 527 API authorization model. Names are already available at all points 528 when authorization decisions are made. In addition, for many 529 mechanisms the sort of information carried as name attributes will 530 also be carried as part of the name in the mechanism 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560Hartman Expires December 4, 2005 [Page 10] 561 562Internet-Draft GSS Names June 2005 563 564 5656. Mechanisms for Export Name 566 567 Another proposal is to define some GSS-API mechanisms whose only 568 purpose is to have an exportable name form that is useful. For 569 example, you might be able to export a name as a local machine user 570 ID with such a mechanism. 571 572 This solution works well especially for name information that can be 573 looked up in a directory. It was unclear from the p discussion 574 whether this solution would allow mechanism-specific name information 575 to be extracted from a context. If so, then this solution would meet 576 many of the goals of this document. 577 578 One advantage of this solution is that it requires few if any changes 579 to GSS-API semantics. It is not as flexible as other solutions. 580 Also, it is not clear how to handle mechanisms that do not have a 581 well defined name to export with this solution. 582 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 615 616Hartman Expires December 4, 2005 [Page 11] 617 618Internet-Draft GSS Names June 2005 619 620 6217. Deferring Credential Binding 622 623 Currently GSS-API credentials represent a single mechanism name. 624 While working on other issues discussion came up focused around 625 choosing the correct credential for a particular target. There are 626 several situations where an implementation can do a better job of 627 choosing a default source name to use given the name of the target to 628 connect to. Currently, GSS-API does not provide a mechanism to do 629 this. Adding such a mechanism would be desirable. 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 671 672Hartman Expires December 4, 2005 [Page 12] 673 674Internet-Draft GSS Names June 2005 675 676 6778. Security Considerations 678 679 GSS-API sets up a security context between two named parties. The 680 GSS-API names are security assertions that are authenticated by the 681 context establishment process. As such the GSS naming architecture 682 is critical to the security of GSS-API. 683 684 Currently GSS-API uses a simplistic naming model for authorization. 685 Names can be compared against a set of names on an access control 686 list. This architecture is relatively simple and its security 687 properties are well understood. However it does not provide the 688 flexibility and feature set for future deployments of GSS-API. 689 690 This proposal will significantly increase the complexity of the GSS 691 naming architecture. As this proposal is fleshed out, we need to 692 consider ways of managing security exposures created by this 693 increased complexity. 694 695 One area where the complexity may lead to security problems is 696 composite names with attributes from different sources. This may be 697 desirable so that name attributes that carry their own 698 authentication. However the design of any solutions needs to make 699 sure that applications can assign appropriate trust to name 700 components. 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 728Hartman Expires December 4, 2005 [Page 13] 729 730Internet-Draft GSS Names June 2005 731 732 7339. Acknowledgements 734 735 John Brezak, Paul Leach and Nicolas Williams all participated in 736 discussions that lead to a desire to enhance GSS naming. Martin Rex 737 provided descriptions of the current naming architecture and pointed 738 out many ways in which proposed enhancements would create 739 interoperability problems or increase complexity. Martin also 740 provided excellent information on what aspects of GSS naming have 741 tended to be implemented badly or have not met the needs of some 742 customers. 743 744 Nicolas Williams helped describe the possible approaches for 745 enhancing naming. 746 74710. Informative References 748 749 [1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", 750 rfc 2025, October 1996. 751 752 [2] Linn, J., "Generic Security Service Application Program 753 Interface Version 2, Update 1", RFC 2743, January 2000. 754 755 [3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos 756 Network Authentication Service (V5)", 757 draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in 758 progress), June 2004. 759 760 [4] Jaganathan , K., Zhu, L., Swift, M., and J. Brezak, "Generating 761 KDC Referrals to locate Kerberos realms", 762 draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress), 763 2004. 764 765 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 766 Public Key Infrastructure Certificate and Certificate Revocation 767 List (CRL) Profile", rfc 3280, April 2002. 768 769 [6] Farrell, S. and R. Housley, "An Internet Attribute Certificate 770 Profile for Authorization.", rfc 3281, April 2002. 771 772 773Author's Address 774 775 Sam Hartman 776 MIT 777 778 Email: hartmans@mit.edu 779 780 781 782 783 784Hartman Expires December 4, 2005 [Page 14] 785 786Internet-Draft GSS Names June 2005 787 788 789Intellectual Property Statement 790 791 The IETF takes no position regarding the validity or scope of any 792 Intellectual Property Rights or other rights that might be claimed to 793 pertain to the implementation or use of the technology described in 794 this document or the extent to which any license under such rights 795 might or might not be available; nor does it represent that it has 796 made any independent effort to identify any such rights. Information 797 on the procedures with respect to rights in RFC documents can be 798 found in BCP 78 and BCP 79. 799 800 Copies of IPR disclosures made to the IETF Secretariat and any 801 assurances of licenses to be made available, or the result of an 802 attempt made to obtain a general license or permission for the use of 803 such proprietary rights by implementers or users of this 804 specification can be obtained from the IETF on-line IPR repository at 805 http://www.ietf.org/ipr. 806 807 The IETF invites any interested party to bring to its attention any 808 copyrights, patents or patent applications, or other proprietary 809 rights that may cover technology that may be required to implement 810 this standard. Please address the information to the IETF at 811 ietf-ipr@ietf.org. 812 813 814Disclaimer of Validity 815 816 This document and the information contained herein are provided on an 817 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 818 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 819 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 820 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 821 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 822 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 823 824 825Copyright Statement 826 827 Copyright (C) The Internet Society (2005). This document is subject 828 to the rights, licenses and restrictions contained in BCP 78, and 829 except as set forth therein, the authors retain all their rights. 830 831 832Acknowledgment 833 834 Funding for the RFC Editor function is currently provided by the 835 Internet Society. 836 837 838 839 840Hartman Expires December 4, 2005 [Page 15] 841 842 843