1 2 3 4Network Working Group S. Hartman 5Internet-Draft MIT 6Expires: April 24, 2005 October 24, 2004 7 8 9 GSSAPI Mechanisms without a Single Canonical Name 10 draft-hartman-gss-naming-01.txt 11 12Status of this Memo 13 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on April 24, 2005. 38 39Copyright Notice 40 41 Copyright (C) The Internet Society (2004). 42 43Abstract 44 45 The Generic Security Services API (GSSAPI) provides a naming 46 architecture that supports name-based authorization. GSSAPI 47 authenticates two named parties to each other. Names can be stored 48 on access control lists to make authorization decisions. Advances in 49 security mechanisms and the way implementers wish to use GSSAPI 50 require this model to be extended. Some mechanisms such as 51 public-key mechanisms do not have a single name to be used. Other 52 mechanisms such as Kerberos allow names to change as people move 53 54 55 56Hartman Expires April 24, 2005 [Page 1] 57 58Internet-Draft GSS Name Attributes October 2004 59 60 61 around organizations. This document proposes expanding the 62 definition of GSSAPI names to deal with these situations. 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 109 110 111 112Hartman Expires April 24, 2005 [Page 2] 113 114Internet-Draft GSS Name Attributes October 2004 115 116 1171. Introduction 118 119 The Generic Security Services API [1] provides a function called 120 gss_export_name that will flatten a GSSAPI name into a binary blob 121 suitable for comparisons. This binary blob can be stored on ACLs and 122 then authorization decisions can be made simply by comparing the name 123 exported from a newly accepted context to the name on the ACL. 124 125 As a side effect of this model, each mechanism name needs to be able 126 to be represented in a single canonical form and anyone importing 127 that name needs to be able to retrieve the canonical form. 128 129 Several security mechanisms have been proposed for which this naming 130 architecture is too restrictive. In some cases it is not always 131 possible to canonicalize any name that is imported. In other cases 132 there is no single canonical name. In addition, there is a desire to 133 have more complex authorization models in GSSAPI than the current 134 name based authorization model. 135 136 This draft discusses two different cases where the current GSSAPI 137 naming seems inadequate. Two proposals that have been discussed 138 within the IETF Kitten community are discussed. Finally, the 139 problems that need to be resolved to adopt either of these proposals 140 are discussed. 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 168Hartman Expires April 24, 2005 [Page 3] 169 170Internet-Draft GSS Name Attributes October 2004 171 172 1732. Kerberos Naming 174 175 The Kerberos Referrals draft [2] 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. So in order to 189 canonicalize an enterprise name to get a principal, a service must 190 have credentials. However it may not be desirable to allow services 191 to map enterprise names to principal names in the general case. 192 Also, Kerberos does not (and does not plan to) provide a mechanism 193 for mapping enterprise names to principals besides authentication as 194 the enterprise name. So any such mapping would be vendor-specific. 195 With this feature in Kerberos, it is not possible to implement 196 gss_canonicalize_name for enterprise name types. 197 198 Another issue arises with enterprise names. IN some cases it would 199 be desirable to put the enterprise name on the ACL instead of a 200 principal name. Thus, it would be desirable to include the 201 enterprise name in the name exported by gss_export_name. However 202 then the exported name would change whenever the mapping changed, 203 defeating the purpose of including the enterprise name. So in some 204 cases it would be desirable to have the exported name be based on the 205 enterprise name and in others based on the principal name, but this 206 is not currently possible. 207 208 Another development also complicates GSSAPI naming for Kerberos. 209 Several vendors have been looking at mechanisms to include group 210 membership information in Kerberos authorization data. It is 211 desirable to put these group names on ACLs. Again, GSSAPI currently 212 has no mechanism to use this information. 213 214 215 216 217 218 219 220 221 222 223 224Hartman Expires April 24, 2005 [Page 4] 225 226Internet-Draft GSS Name Attributes October 2004 227 228 2293. X.509 Names 230 231 X.509 names are at least as complex as Kerberos names. It seems like 232 you might want to use the subject name as the name to be exported in 233 a GSSAPI mechanism. However RFC 3280 [3] does not even require the 234 subject name to be a non-empty sequence. Instead there are cases 235 where the subjectAltName extension is the only thing to identify the 236 subject of the certificate. As in the case of Kerberos group 237 memberships, there may be many subjectAltName extensions available in 238 a certificate. Different applications will care about different 239 extensions. Thus there is no single value that can be defined as 240 the exported GSSAPI name that will be generally useful. 241 242 A profile of a particular X.509 GSSAPI 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 GSSAPI for some 246 applications. 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 277 278 279 280Hartman Expires April 24, 2005 [Page 5] 281 282Internet-Draft GSS Name Attributes October 2004 283 284 2854. Composite Names 286 287 One proposal to solve these problems is to extend the concept of a 288 GSSAPI name to include a set of name attributes. Each attribute 289 would be an octet-string labeled by an OID. Examples of attributes 290 would include Kerberos enterprise names, group memberships in an 291 authorization infrastructure, Kerberos authorization data attributes 292 and subjectAltName attributes in a certificate. Several new 293 operations would be needed: 294 1. Add attribute to name 295 2. Query attributes of name 296 3. Query values of an attribute 297 4. Delete an attribute from a name 298 2994.1 Usage of Name Attributes 300 301 Since attributes are part of GSSAPI names, the acceptor can retrieve 302 the attributes of the initiator's name from the context. These 303 attributes can then be used for authorization. 304 305 Most name attributes will probably not come from explicit operations 306 to add attributes to a name. Instead, name attributes will probably 307 come from mechanism specific credentials. Mechanism specific naming 308 and group membership can be mapped into name attributes by the 309 mechanism implementation. The specific form of this mapping will 310 general require protocol specification for each mechanism. 311 3124.2 Open issues 313 314 This section describes parts of the proposal to add attributes to 315 names that will need to be explored before the proposal can become a 316 protocol specification. 317 318 Are mechanisms expected to be able to carry arbitrary name attributes 319 as part of a context establishment? At first it seems like this 320 would be desirable. However the point of GSSAPI is to establish an 321 authenticated context between two peers. In particular, a context 322 authenticates two named entities to each other. The names of these 323 entities and attributes associated with these names will be used for 324 authorization decisions. If an initiator or acceptor is allowed to 325 assert name attributes and the authenticity of these assertions is 326 not validated by the mechanisms, then security problems may result. 327 On the other hand, requiring that name attributes be mechanism 328 specific and only be carried by mechanisms that understand the name 329 attributes and can validate them compromises GSSAPI's place as a 330 generic API. Application authors would be forced to understand 331 mechanism-specific attributes to make authorization decisions. In 332 addition if mechanisms are not required to transport arbitrary 333 334 335 336Hartman Expires April 24, 2005 [Page 6] 337 338Internet-Draft GSS Name Attributes October 2004 339 340 341 attributes, then application authors will need to deal with different 342 implementations of the same mechanism that support different sets of 343 name attributes. One possible solution is to carry a source along 344 with each name attribute; this source could indicate whether the 345 attribute comes from a mechanism data structure or from the other 346 party in the authentication. 347 348 Another related question is how will name attributes be mapped into 349 their mechanism-specific forms. For example it would be desirable to 350 map many Kerberos authorization data elements into name attributes. 351 In the case of the Microsoft PAC, it would be desirable for some 352 applications to get the entire PAC. However in many cases, the 353 specific lists of security IDs contained in the PAC would be more 354 directly useful to an application. So there may not be a good 355 one-to-one mapping between the mechanism-specific elements and the 356 representation desirable at the GSSAPI layer. 357 358 Specific name matching rules need to be developed. How do names with 359 attributes compare? What is the effect of a name attribute on a 360 target name in gss_accept_sec_context? 361 3624.3 Handling gss_export_name 363 364 For many mechanisms, there will be an obvious choice to use for the 365 name exported by gss_export_name. For example in the case of 366 Kerberos, the principal name can continue to be used as the exported 367 name. This will allow applications depending on existing GSSAPI 368 name-based authorization to continue to work. However it is probably 369 desirable to allow GSSAPI mechanisms for which gss_export_name cannot 370 meaningfully be defined. The behavior of gss_export_name in such 371 cases should probably be to return some error. Such mechanisms may 372 not work with existing applications and cannot conform to the current 373 version of the GSSAPI. 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392Hartman Expires April 24, 2005 [Page 7] 393 394Internet-Draft GSS Name Attributes October 2004 395 396 3975. Credential Extensions 398 399 An alternative to the name attributes proposal is to extend GSSAPI 400 credentials with extensions labeled by OIDs. Interfaces would be 401 needed to manipulate these credential extensions and to retrieve the 402 credential extensions for credentials used to establish a context. 403 Even if name attributes are used, credential extensions may be useful 404 for other unrelated purposes. 405 406 It is possible to solve problems discussed in this document using 407 some credential extension mechanism. Doing so will have many of the 408 same open issues as discussed in the name attributes proposal. The 409 main advantage of a credential extensions proposal is that it avoids 410 specifying how name attributes interact with name comparison or 411 target names. 412 413 The primary advantage of the name attributes proposal over credential 414 extensions is that name attributes seem to fit better into the GSSAPI 415 authorization model. Names are already available at all points when 416 authorization decisions are made. In addition, for many mechanisms 417 the sort of information carried as name attributes will also be 418 carried as part of the name in the mechanism 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448Hartman Expires April 24, 2005 [Page 8] 449 450Internet-Draft GSS Name Attributes October 2004 451 452 4536. Mechanisms for Export Name 454 455 Another proposal is to define some GSSAPI mechanisms whose only 456 purpose is to have an exportable name form that is useful. For 457 example, you might be able to export a name as a local machine user 458 ID with such a mechanism. 459 460 This solution works well especially for name information that can be 461 looked up in a directory. It was unclear from the discussion whether 462 this solution would allow mechanism-specific name information to be 463 extracted from a context. If so, then this solution would meet many 464 of the goals of this document. 465 466 One advantage of this solution is that it requires few if any changes 467 to GSSAPI semantics. It is not as flexible as other solutions. 468 Also, it is not clear how to handle mechanisms that do not have a 469 well defined name to export with this solution. 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 April 24, 2005 [Page 9] 505 506Internet-Draft GSS Name Attributes October 2004 507 508 5097. Security Considerations 510 511 GSSAPI sets up a security context between two named parties. The 512 GSSAPI names are security assertions that are authenticated by the 513 context establishment process. As such the GSS naming architecture 514 is critical to the security of GSSAPI. 515 516 Currently GSSAPI uses a simplistic naming model for authorization. 517 Names can be compared against a set of names on an access control 518 list. This architecture is relatively simple and its security 519 properties are well understood. However it does not provide the 520 flexibility and feature set for future deployments of GSSAPI. 521 522 This proposal will significantly increase the complexity of the GSS 523 naming architecture. As this proposal is fleshed out, we need to 524 consider ways of managing security exposures created by this 525 increased complexity. 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 557 558 559 560Hartman Expires April 24, 2005 [Page 10] 561 562Internet-Draft GSS Name Attributes October 2004 563 564 5658. Acknowledgements 566 567 John Brezak, Paul Leach and Nicolas Williams all participated in 568 discussions that defined the problem this proposal attempts to solve. 569 Nicolas Williams and I discussed details of proposals to solve this 570 problem. However the details and open issues presented here have 571 only been reviewed by me and so I am responsible for their errors. 572 5739 Informative References 574 575 [1] Linn, J., "Generic Security Service Application Program 576 Interface Version 2, Update 1", RFC 2743, January 2000. 577 578 [2] Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating 579 KDC Referrals to locate Kerberos realms", 580 draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress), 581 2004. 582 583 [3] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 584 Public Key Infrastructure Certificate and Certificate Revocation 585 List (CRL) Profile", rfc 3280, April 2002. 586 587 588Author's Address 589 590 Sam Hartman 591 MIT 592 593 EMail: hartmans@mit.edu 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616Hartman Expires April 24, 2005 [Page 11] 617 618Internet-Draft GSS Name Attributes October 2004 619 620 621Intellectual Property Statement 622 623 The IETF takes no position regarding the validity or scope of any 624 Intellectual Property Rights or other rights that might be claimed to 625 pertain to the implementation or use of the technology described in 626 this document or the extent to which any license under such rights 627 might or might not be available; nor does it represent that it has 628 made any independent effort to identify any such rights. Information 629 on the procedures with respect to rights in RFC documents can be 630 found in BCP 78 and BCP 79. 631 632 Copies of IPR disclosures made to the IETF Secretariat and any 633 assurances of licenses to be made available, or the result of an 634 attempt made to obtain a general license or permission for the use of 635 such proprietary rights by implementers or users of this 636 specification can be obtained from the IETF on-line IPR repository at 637 http://www.ietf.org/ipr. 638 639 The IETF invites any interested party to bring to its attention any 640 copyrights, patents or patent applications, or other proprietary 641 rights that may cover technology that may be required to implement 642 this standard. Please address the information to the IETF at 643 ietf-ipr@ietf.org. 644 645 646Disclaimer of Validity 647 648 This document and the information contained herein are provided on an 649 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 650 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 651 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 652 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 653 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 654 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 655 656 657Copyright Statement 658 659 Copyright (C) The Internet Society (2004). This document is subject 660 to the rights, licenses and restrictions contained in BCP 78, and 661 except as set forth therein, the authors retain all their rights. 662 663 664Acknowledgment 665 666 Funding for the RFC Editor function is currently provided by the 667 Internet Society. 668 669 670 671 672Hartman Expires April 24, 2005 [Page 12] 673 674 675