1Network Working Group S. Hartman 2Internet-Draft MIT 3Expires: August 21, 2005 February 20, 2005 4 5 6 Desired Enhancements to GSSAPI Naming 7 draft-ietf-kitten-gss-naming-01.txt 8 9Status of this Memo 10 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 17 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 22 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 27 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 30 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 33 34 This Internet-Draft will expire on August 21, 2005. 35 36Copyright Notice 37 38 Copyright (C) The Internet Society (2005). 39 40Abstract 41 42 The Generic Security Services API (GSS-API) provides a naming 43 architecture that supports name-based authorization. GSS-API 44 authenticates two named parties to each other. Names can be stored 45 on access control lists to make authorization decisions. Advances in 46 security mechanisms and the way implementers wish to use GSS-API 47 require this model to be extended. As people move within an 48 organization or change their names, the name authenticated by GSS-API 49 may change. Using some sort of constant identifier would make ACLs 50 51 52 53Hartman Expires August 21, 2005 [Page 1] 54 55Internet-Draft GSS Names February 2005 56 57 58 more stable. Some mechanisms such as public-key mechanisms do not 59 have a single name to be used across all environments. Other 60 mechanisms such as Kerberos include may include group membership or 61 role information as part of authentication. This document motivates 62 extensions to GSS-API naming and describes the extensions under 63 discussion. 64 65 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 109Hartman Expires August 21, 2005 [Page 2] 110 111Internet-Draft GSS Names February 2005 112 113 1141. Introduction 115 116 The Generic Security Services API [2] authenticates two named parties 117 to each other. GSS names can be imported in a variety of formats 118 through the gss_import_name call. Several mechanism-independent name 119 formats are provided including GSS_C_NT_HOSTBASED_SERVICE for 120 services running on an Internet host and GSS_C_NT_USER_NAME for the 121 names of users. Other mechanism-specific name types are also 122 provided. By the time a name is used in acquiring a 123 mechanism-specific credential or establishing a security context, it 124 has been transformed into one of these mechanism-specific name types. 125 In addition, the GSS-API provides a function called gss_export_name 126 that will flatten a GSS-API name into a binary blob suitable for 127 comparisons. This binary blob can be stored on ACLs and then 128 authorization decisions can be made simply by comparing the name 129 exported from a newly accepted context to the name on the ACL. 130 131 Storing names on ACLs can be problematic because names tend to change 132 over time . If the name contains organizational information such as 133 a domain part or an indication of what department someone works for, 134 this changes as the person moves around the organization. Even if no 135 organizational information is included in the name, the name will 136 change as people change their names. Updating ACLs to reflect name 137 changes is difficult. 138 139 Inherent in the GSS naming model is the idea that mechanism names 140 need to be able to be represented in a single canonical form. Anyone 141 importing that name needs to be able to retrieve the canonical form 142 of that name. 143 144 Several security mechanisms have been proposed for which this naming 145 architecture is too restrictive. In some cases it is not always 146 possible to canonicalize any name that is imported. In other cases 147 there is no single canonical name. 148 149 Also, as GSS-API is used in more complex environments, there is a 150 desire to use attribute certificates [6], Kerberos authorization data 151 [3], or other non-name-based authorization models. GSS-API needs to 152 be enhanced in order to support these uses in a mechanism-independent 153 manner. 154 155 This document discusses the particular naming problems with two 156 important classes of GSS-API mechanisms. It also discusses the set 157 of proposed solutions and open issues with these solutions. This 158 draft limits discussion to these solutions and provides a description 159 of the problem against which the solutions can be judged. 160 161 162 163 164 165Hartman Expires August 21, 2005 [Page 3] 166 167Internet-Draft GSS Names February 2005 168 169 1702. Kerberos Naming 171 172 The Kerberos mechanism demonstrates both the naming stability problem 173 and the authorization extension problem. 174 175 The Kerberos Referrals draft [4] proposes a new type of Kerberos name 176 called an enterprise name. The intent is that the enterprise name is 177 an alias that the user knows for themselves and can use to login. 178 The Kerberos KDC translates this name into a normal Kerberos 179 principal and gives the user tickets for this principal. This normal 180 principal is used for authorization. The intent is that the 181 enterprise name tracks the user as they move throughout the 182 organization, even if they move to parts of the organization that 183 have different naming policies. The name they type at login remains 184 constant, but the Kerberos principal used to authenticate them to 185 services changes. 186 187 Performing a mapping from enterprise name to principal name is not 188 generally possible for unauthenticated services. Even authenticated 189 services may not be authorized to perform this mapping except for 190 their own name. Also, Kerberos does not (and does not plan to) 191 provide a mechanism for mapping enterprise names to principals 192 besides authentication as the enterprise name. Thus, any such 193 mapping would be vendor-specific. With this feature in Kerberos, it 194 is not possible to implement gss_canonicalize_name for enterprise 195 name types. 196 197 Another issue arises with enterprise names. IN some cases it would 198 be desirable to put the enterprise name on the ACL instead of a 199 principal name for greater ACL stability. At first glance this could 200 be accomplished by including the enterprise name in the name exported 201 by gss_export_name. Unfortunately, if this were done, the exported 202 name would change whenever the mapping changed, invalidating any ACL 203 entries based off the old exported name and defeating the purpose of 204 including the enterprise name in the exported name. In some cases it 205 would be desirable to have the exported name be based on the 206 enterprise name and in others based on the principal name, but this 207 is not permitted by the current GSS-API. 208 209 Another development also complicates GSS-API naming for Kerberos. 210 Several vendors have been looking at mechanisms to include group 211 membership information in Kerberos authorization data. It is 212 desirable to put these group names on ACLs. Again, GSS-API currently 213 has no mechanism to use this information. 214 215 216 217 218 219 220 221Hartman Expires August 21, 2005 [Page 4] 222 223Internet-Draft GSS Names February 2005 224 225 2263. X.509 Names 227 228 X.509 names are more complicated than Kerberos names. In the 229 Kerberos case there is a single principal carried in all Kerberos 230 messages. X.509 certificates have multiple options. It seems the 231 subject name might be the appropriate name to use as the name to be 232 exported in a GSS-API mechanism. However RFC 3280 [5] does not even 233 require the subject name to be a non-empty sequence. Instead there 234 are cases where the subjectAltName extension is the only thing to 235 identify the subject of the certificate. As in the case of Kerberos 236 group memberships, there may be many subjectAltName extensions 237 available in a certificate. Different applications will care about 238 different extensions. Thus there is no single value that can be 239 defined as the exported GSS-API name that will be useful in all 240 environments. 241 242 A profile of a particular X.509 GSS-API mechanism could require a 243 specific name be used. However this would limit that mechanism to 244 require a particular type of certificate. There is interest in being 245 able to use arbitrary X.509 certificates with GSS-API for some 246 applications. 247 248 Experience so far has not lead to sufficient interoperability with 249 GSS-API X.509 mechanisms. Even if the subject name is used, there is 250 ambiguity in how to handle sorting of name components. Martin Rex 251 said that he was aware of several SPKM [1] implementations but no two 252 were fully interoperable on names. 253 254 Also, as discussed in the introduction, it is desirable to support 255 X.509 attribute certificates. 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277Hartman Expires August 21, 2005 [Page 5] 278 279Internet-Draft GSS Names February 2005 280 281 2824. Composite Names 283 284 One proposal to solve these problems is to extend the concept of a 285 GSS-API name to include a set of name attributes. Each attribute 286 would be an octet-string labeled by an OID. Examples of attributes 287 would include Kerberos enterprise names, group memberships in an 288 authorization infrastructure, Kerberos authorization data attributes 289 and subjectAltName attributes in a certificate. Several new 290 operations would be needed: 291 1. Add an attribute to name. 292 2. Query attributes of name. 293 3. Query values of an attribute. 294 4. Delete an attribute from a name. 295 5. Export a complete composite name and all its attributes for 296 transport between processes. 297 298 Note that an exported composite name would not be suitable for binary 299 comparison. Avoiding confusion between this operation and the 300 existing gss_export_name operation will require careful work. 301 3024.1 Usage of Name Attributes 303 304 Since attributes are part of GSS-API names, the acceptor can retrieve 305 the attributes of the initiator's and acceptor's name from the 306 context. These attributes can then be used for authorization. 307 308 Most name attributes will probably not come from explicit operations 309 to add attributes to a name. Instead, name attributes will probably 310 come from mechanism specific credentials. Components of these 311 mechanism specific credentials may come from platform or 312 environment-specific names. Mechanism specific naming and group 313 membership can be mapped into name attributes by the mechanism 314 implementation. The specific form of this mapping will generally 315 require protocol specification for each mechanism. 316 317 The value of many name attributes may be suitable for use in binary 318 comparison. This should enable applications to use these name 319 attributes on ACLs the same way exported names are now used on ACLs. 320 For example if a particular Subjectaltname extension contains the 321 appropriate identity for an application, then the name attribute 322 for this Subjectaltname can be placed on the ACL. This is only true 323 if the name attribute is stored in some canonical form. 324 3254.2 Open issues 326 327 This section describes parts of the proposal to add attributes to 328 names that will need to be explored before the proposal can become a 329 protocol specification. 330 331 332 333Hartman Expires August 21, 2005 [Page 6] 334 335Internet-Draft GSS Names February 2005 336 337 338 Are mechanisms expected to be able to carry arbitrary name attributes 339 as part of a context establishment? At first it seems like this 340 would be desirable. However the purpose of GSS-API is to establish 341 an authenticated context between two peers. In particular, a context 342 authenticates two named entities to each other. The names of these 343 entities and attributes associated with these names will be used for 344 authorization decisions. If an initiator or acceptor is allowed to 345 assert name attributes and the authenticity of these assertions is 346 not validated by the mechanisms, then security problems will result. 347 On the other hand, requiring that name attributes be mechanism 348 specific and only be carried by mechanisms that understand the name 349 attributes and can validate them compromises GSS-API's place as a 350 generic API. Application authors would be forced to understand 351 mechanism-specific attributes to make authorization decisions. In 352 addition if mechanisms are not required to transport arbitrary 353 attributes, then application authors will need to deal with different 354 implementations of the same mechanism that support different sets of 355 name attributes. One possible solution is to carry a source along 356 with each name attribute; this source could indicate whether the 357 attribute comes from a mechanism data structure or from the other 358 party in the authentication. 359 360 Another related question is how will name attributes be mapped into 361 their mechanism-specific forms. For example it would be desirable to 362 map many Kerberos authorization data elements into name attributes. 363 In the case of the Microsoft PAC, it would be desirable for some 364 applications to get the entire PAC. However in many cases, the 365 specific lists of security IDs contained in the PAC would be more 366 directly useful to an application. So there may not be a good 367 one-to-one mapping between the mechanism-specific elements and the 368 representation desirable at the GSS-API layer. 369 370 Specific name matching rules need to be developed. How do names with 371 attributes compare? What is the effect of a name attribute on a 372 target name in gss_accept_sec_context? 373 3744.3 Handling gss_export_name 375 376 For many mechanisms, there will be an obvious choice to use for the 377 name exported by gss_export_name. For example in the case of 378 Kerberos, the principal name can continue to be used as the exported 379 name. This will allow applications depending on existing GSS-API 380 name-based authorization to continue to work. However it is probably 381 desirable to allow GSS-API mechanisms for which gss_export_name 382 cannot meaningfully be defined. The behavior of gss_export_name in 383 such cases should probably be to return some error. Such mechanisms 384 may not work with existing applications and cannot conform to the 385 current version of the GSS-API. 386 387 388 389Hartman Expires August 21, 2005 [Page 7] 390 391Internet-Draft GSS Names February 2005 392 393 3945. Credential Extensions 395 396 An alternative to the name attributes proposal is to extend GSS-API 397 credentials with extensions labeled by OIDs. Interfaces would be 398 needed to manipulate these credential extensions and to retrieve the 399 credential extensions for credentials used to establish a context. 400 Even if name attributes are used, credential extensions may be useful 401 for other unrelated purposes. 402 403 It is possible to solve problems discussed in this document using 404 some credential extension mechanism. Doing so will have many of the 405 same open issues as discussed in the composite names proposal. The 406 main advantage of a credential extensions proposal is that it avoids 407 specifying how name attributes interact with name comparison or 408 target names. 409 410 The primary advantage of the name attributes proposal over credential 411 extensions is that name attributes seem to fit better into the 412 GSS-API authorization model. Names are already available at all 413 points when authorization decisions are made. In addition, for many 414 mechanisms the sort of information carried as name attributes will 415 also be carried as part of the name in the mechanism 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 445Hartman Expires August 21, 2005 [Page 8] 446 447Internet-Draft GSS Names February 2005 448 449 4506. Mechanisms for Export Name 451 452 Another proposal is to define some GSS-API mechanisms whose only 453 purpose is to have an exportable name form that is useful. For 454 example, you might be able to export a name as a local machine user 455 ID with such a mechanism. 456 457 This solution works well especially for name information that can be 458 looked up in a directory. It was unclear from the p discussion 459 whether this solution would allow mechanism-specific name information 460 to be extracted from a context. If so, then this solution would meet 461 many of the goals of this document. 462 463 One advantage of this solution is that it requires few if any changes 464 to GSS-API semantics. It is not as flexible as other solutions. 465 Also, it is not clear how to handle mechanisms that do not have a 466 well defined name to export with this solution. 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 501Hartman Expires August 21, 2005 [Page 9] 502 503Internet-Draft GSS Names February 2005 504 505 5067. Deferring Credential Binding 507 508 Currently GSS-API credentials represent a single mechanism name. 509 While working on other issues discussion focused around choosing the 510 correct credential for a particular target. There are several 511 situations where an implementation can do a better job of choosing a 512 default source name to use given the name of the target to connect 513 to. Currently, GSS-API does not provide a mechanism to do this. 514 Adding such a mechanism would be desirable. 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 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 557Hartman Expires August 21, 2005 [Page 10] 558 559Internet-Draft GSS Names February 2005 560 561 5628. Security Considerations 563 564 GSS-API sets up a security context between two named parties. The 565 GSS-API names are security assertions that are authenticated by the 566 context establishment process. As such the GSS naming architecture 567 is critical to the security of GSS-API. 568 569 Currently GSS-API uses a simplistic naming model for authorization. 570 Names can be compared against a set of names on an access control 571 list. This architecture is relatively simple and its security 572 properties are well understood. However it does not provide the 573 flexibility and feature set for future deployments of GSS-API. 574 575 This proposal will significantly increase the complexity of the GSS 576 naming architecture. As this proposal is fleshed out, we need to 577 consider ways of managing security exposures created by this 578 increased complexity. 579 580 One area where the complexity may lead to security problems is 581 composite names with attributes from different sources. This may be 582 desirable so that name attributes that carry their own 583 authentication. However the design of any solutions needs to make 584 sure that applications can assign appropriate trust to name 585 components. 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 613Hartman Expires August 21, 2005 [Page 11] 614 615Internet-Draft GSS Names February 2005 616 617 6189. Acknowledgements 619 620 John Brezak, Paul Leach and Nicolas Williams all participated in 621 discussions that lead to a desire to enhance GSS naming. Martin Rex 622 provided descriptions of the current naming architecture and pointed 623 out many ways in which proposed enhancements would create 624 interoperability problems or increase complexity. Martin also 625 provided excellent information on what aspects of GSS naming have 626 tended to be implemented badly or have not met the needs of some 627 customers. 628 629 Nicolas Williams helped describe the possible approaches for 630 enhancing naming. 631 63210 Informative References 633 634 [1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", rfc 635 2025, October 1996. 636 637 [2] Linn, J., "Generic Security Service Application Program 638 Interface Version 2, Update 1", RFC 2743, January 2000. 639 640 [3] Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos 641 Network Authentication Service (V5)", 642 draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in 643 progress), June 2004. 644 645 [4] Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating 646 KDC Referrals to locate Kerberos realms", 647 draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress), 648 2004. 649 650 [5] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 651 Public Key Infrastructure Certificate and Certificate Revocation 652 List (CRL) Profile", rfc 3280, April 2002. 653 654 [6] Farrell, S. and R. Housley, "An Internet Attribute Certificate 655 Profile for Authorization.", rfc 3281, April 2002. 656 657 658Author's Address 659 660 Sam Hartman 661 MIT 662 663 EMail: hartmans@mit.edu 664 665 666 667 668 669Hartman Expires August 21, 2005 [Page 12] 670 671Internet-Draft GSS Names February 2005 672 673 674Intellectual Property Statement 675 676 The IETF takes no position regarding the validity or scope of any 677 Intellectual Property Rights or other rights that might be claimed to 678 pertain to the implementation or use of the technology described in 679 this document or the extent to which any license under such rights 680 might or might not be available; nor does it represent that it has 681 made any independent effort to identify any such rights. Information 682 on the procedures with respect to rights in RFC documents can be 683 found in BCP 78 and BCP 79. 684 685 Copies of IPR disclosures made to the IETF Secretariat and any 686 assurances of licenses to be made available, or the result of an 687 attempt made to obtain a general license or permission for the use of 688 such proprietary rights by implementers or users of this 689 specification can be obtained from the IETF on-line IPR repository at 690 http://www.ietf.org/ipr. 691 692 The IETF invites any interested party to bring to its attention any 693 copyrights, patents or patent applications, or other proprietary 694 rights that may cover technology that may be required to implement 695 this standard. Please address the information to the IETF at 696 ietf-ipr@ietf.org. 697 698 699Disclaimer of Validity 700 701 This document and the information contained herein are provided on an 702 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 703 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 704 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 705 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 706 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 707 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 708 709 710Copyright Statement 711 712 Copyright (C) The Internet Society (2005). This document is subject 713 to the rights, licenses and restrictions contained in BCP 78, and 714 except as set forth therein, the authors retain all their rights. 715 716 717Acknowledgment 718 719 Funding for the RFC Editor function is currently provided by the 720 Internet Society. 721 722 723 724 725Hartman Expires August 21, 2005 [Page 13] 726 727 728