1Network Working Group S. Hartman 2Internet-Draft MIT 3Expires: May 31, 2005 November 30, 2004 4 5 6 Desired Enhancements to GSSAPI Naming 7 draft-ietf-kitten-gss-naming-00.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 May 31, 2005. 35 36Copyright Notice 37 38 Copyright (C) The Internet Society (2004). 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. Some mechanisms such as 48 public-key mechanisms do not have a single name to be used across all 49 environments. Other mechanisms such as Kerberos allow names to 50 51 52 53Hartman Expires May 31, 2005 [Page 1] 54 55Internet-Draft GSS Names November 2004 56 57 58 change as people move around organizations. This document proposes 59 expanding the definition of GSS-API names to deal with these 60 situations. 61 62 63 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 May 31, 2005 [Page 2] 110 111Internet-Draft GSS Names November 2004 112 113 1141. Introduction 115 116 The Generic Security Services API [1] 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 such as GSS_C_NT_HOSTBASED_SERVICE for services running on an 120 Internet host and GSS_C_NT_USER_NAME for the names of users. Other 121 mechanism-specific name types are also provided. By the time a name 122 is used in acquiring a mechanism-specific credential or establishing 123 a security context, it has been transformed into one of these 124 mechanism-specific name types. In addition, the GSS-API provides a 125 function called gss_export_name that will flatten a GSS-API name into 126 a binary blob suitable for comparisons. This binary blob can be 127 stored on ACLs and then authorization decisions can be made simply by 128 comparing the name exported from a newly accepted context to the name 129 on the ACL. 130 131 Inherent in this model is the idea that mechanism names need to be 132 able to be represented in a single canonical form. Anyone importing 133 that name needs to be able to retrieve the canonical form of that 134 name. 135 136 Several security mechanisms have been proposed for which this naming 137 architecture is too restrictive. In some cases it is not always 138 possible to canonicalize any name that is imported. In other cases 139 there is no single canonical name. 140 141 Storing names on ACLs can be problematic because names tend to change 142 over time . If the name contains organizational information such as 143 a domain part or an indication of what department someone works for, 144 this changes as the person moves around the organization. Even if no 145 organizational information is included in the name, the name will 146 change as people change their names. Updating ACLs to reflect name 147 changes is difficult. 148 149 Also, as GSS-API is used in more complex environments, there is a 150 desire to use attribute certificates [5], Kerberos authorization data 151 [2], 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 draft discusses two different cases where the current GSS-API 156 naming seems inadequate. Two proposals that have been discussed 157 within the IETF Kitten community are discussed. Finally, the 158 problems that need to be resolved to adopt either of these proposals 159 are discussed. 160 161 162 163 164 165Hartman Expires May 31, 2005 [Page 3] 166 167Internet-Draft GSS Names November 2004 168 169 1702. Kerberos Naming 171 172 The Kerberos Referrals draft [3] proposes a new type of Kerberos name 173 called an enterprise name. The intent is that the enterprise name is 174 an alias that the user knows for themselves and can use to login. 175 The Kerberos KDC translates this name into a normal Kerberos 176 principal and gives the user tickets for this principal. This normal 177 principal is used for authorization. The intent is that the 178 enterprise name tracks the user as they move throughout the 179 organization, even if they move to parts of the organization that 180 have different naming policies. The name they type at login remains 181 constant, but the Kerberos principal used to authenticate them to 182 services changes. 183 184 Performing a mapping from enterprise name to principal name is not 185 generally possible for unauthenticated services. So in order to 186 canonicalize an enterprise name to get a principal, a service must 187 have credentials. However it may not be desirable to allow services 188 to map enterprise names to principal names in the general case. 189 Also, Kerberos does not (and does not plan to) provide a mechanism 190 for mapping enterprise names to principals besides authentication as 191 the enterprise name. Thus, any such mapping would be 192 vendor-specific. With this feature in Kerberos, it is not possible 193 to implement gss_canonicalize_name for enterprise name types. 194 195 Another issue arises with enterprise names. IN some cases it would 196 be desirable to put the enterprise name on the ACL instead of a 197 principal name. Thus, it would be desirable to include the 198 enterprise name in the name exported by gss_export_name. 199 Unfortunately, if this were done, the exported name would change 200 whenever the mapping changed, invalidating any ACL entries based off 201 the old exported name and defeating the purpose of including the 202 enterprise name. In some cases it would be desirable to have the 203 exported name be based on the enterprise name and in others based on 204 the principal name, but this is not permitted by the current GSS-API. 205 206 Another development also complicates GSS-API naming for Kerberos. 207 Several vendors have been looking at mechanisms to include group 208 membership information in Kerberos authorization data. It is 209 desirable to put these group names on ACLs. Again, GSS-API currently 210 has no mechanism to use this information. 211 212 213 214 215 216 217 218 219 220 221Hartman Expires May 31, 2005 [Page 4] 222 223Internet-Draft GSS Names November 2004 224 225 2263. X.509 Names 227 228 X.509 names are at least as complex as Kerberos names. It seems the 229 subject name might be the appropriate name to use as the name to be 230 exported in a GSS-API mechanism. However RFC 3280 [4] does not even 231 require the subject name to be a non-empty sequence. Instead there 232 are cases where the subjectAltName extension is the only thing to 233 identify the subject of the certificate. As in the case of Kerberos 234 group memberships, there may be many subjectAltName extensions 235 available in a certificate. Different applications will care about 236 different extensions. Thus there is no single value that can be 237 defined as the exported GSS-API name that will be useful in all 238 environments. 239 240 A profile of a particular X.509 GSS-API mechanism could require a 241 specific name be used. However this would limit that mechanism to 242 require a particular type of certificate. There is interest in being 243 able to use arbitrary X.509 certificates with GSS-API for some 244 applications. 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277Hartman Expires May 31, 2005 [Page 5] 278 279Internet-Draft GSS Names November 2004 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 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 2964.1 Usage of Name Attributes 297 298 Since attributes are part of GSS-API names, the acceptor can retrieve 299 the attributes of the initiator's name from the context. These 300 attributes can then be used for authorization. 301 302 Most name attributes will probably not come from explicit operations 303 to add attributes to a name. Instead, name attributes will probably 304 come from mechanism specific credentials. Mechanism specific naming 305 and group membership can be mapped into name attributes by the 306 mechanism implementation. The specific form of this mapping will 307 generally require protocol specification for each mechanism. 308 309 The value of many name attributes may be suitable for use in binary 310 comparison. This should enable applications to use these name 311 attributes on ACLs the same way exported names are now used on ACLs. 312 For example if a particular Subjectaltname extension contains the 313 appropriate identity for an application, then the name attribute 314 for this Subjectaltname can be placed on the ACL. This is only true 315 if the name attribute is stored in some canonical form. 316 3174.2 Open issues 318 319 This section describes parts of the proposal to add attributes to 320 names that will need to be explored before the proposal can become a 321 protocol specification. 322 323 Are mechanisms expected to be able to carry arbitrary name attributes 324 as part of a context establishment? At first it seems like this 325 would be desirable. However the purpose of GSS-API is to establish 326 an authenticated context between two peers. In particular, a context 327 authenticates two named entities to each other. The names of these 328 entities and attributes associated with these names will be used for 329 authorization decisions. If an initiator or acceptor is allowed to 330 331 332 333Hartman Expires May 31, 2005 [Page 6] 334 335Internet-Draft GSS Names November 2004 336 337 338 assert name attributes and the authenticity of these assertions is 339 not validated by the mechanisms, then security problems will result. 340 On the other hand, requiring that name attributes be mechanism 341 specific and only be carried by mechanisms that understand the name 342 attributes and can validate them compromises GSS-API's place as a 343 generic API. Application authors would be forced to understand 344 mechanism-specific attributes to make authorization decisions. In 345 addition if mechanisms are not required to transport arbitrary 346 attributes, then application authors will need to deal with different 347 implementations of the same mechanism that support different sets of 348 name attributes. One possible solution is to carry a source along 349 with each name attribute; this source could indicate whether the 350 attribute comes from a mechanism data structure or from the other 351 party in the authentication. 352 353 Another related question is how will name attributes be mapped into 354 their mechanism-specific forms. For example it would be desirable to 355 map many Kerberos authorization data elements into name attributes. 356 In the case of the Microsoft PAC, it would be desirable for some 357 applications to get the entire PAC. However in many cases, the 358 specific lists of security IDs contained in the PAC would be more 359 directly useful to an application. So there may not be a good 360 one-to-one mapping between the mechanism-specific elements and the 361 representation desirable at the GSS-API layer. 362 363 Specific name matching rules need to be developed. How do names with 364 attributes compare? What is the effect of a name attribute on a 365 target name in gss_accept_sec_context? 366 3674.3 Handling gss_export_name 368 369 For many mechanisms, there will be an obvious choice to use for the 370 name exported by gss_export_name. For example in the case of 371 Kerberos, the principal name can continue to be used as the exported 372 name. This will allow applications depending on existing GSS-API 373 name-based authorization to continue to work. However it is probably 374 desirable to allow GSS-API mechanisms for which gss_export_name 375 cannot meaningfully be defined. The behavior of gss_export_name in 376 such cases should probably be to return some error. Such mechanisms 377 may not work with existing applications and cannot conform to the 378 current version of the GSS-API. 379 380 381 382 383 384 385 386 387 388 389Hartman Expires May 31, 2005 [Page 7] 390 391Internet-Draft GSS Names November 2004 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 May 31, 2005 [Page 8] 446 447Internet-Draft GSS Names November 2004 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 May 31, 2005 [Page 9] 502 503Internet-Draft GSS Names November 2004 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 May 31, 2005 [Page 10] 558 559Internet-Draft GSS Names November 2004 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 581 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 613Hartman Expires May 31, 2005 [Page 11] 614 615Internet-Draft GSS Names November 2004 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] Linn, J., "Generic Security Service Application Program 635 Interface Version 2, Update 1", RFC 2743, January 2000. 636 637 [2] Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos 638 Network Authentication Service (V5)", 639 draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in 640 progress), June 2004. 641 642 [3] Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating 643 KDC Referrals to locate Kerberos realms", 644 draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress), 645 2004. 646 647 [4] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 648 Public Key Infrastructure Certificate and Certificate Revocation 649 List (CRL) Profile", rfc 3280, April 2002. 650 651 [5] Farrell, S. and R. Housley, "An Internet Attribute Certificate 652 Profile for Authorization.", rfc 3281, April 2002. 653 654 655Author's Address 656 657 Sam Hartman 658 MIT 659 660 EMail: hartmans@mit.edu 661 662 663 664 665 666 667 668 669Hartman Expires May 31, 2005 [Page 12] 670 671Internet-Draft GSS Names November 2004 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 (2004). 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 May 31, 2005 [Page 13] 726 727