1 2 3Network Working Group S. Hartman 4Internet-Draft MIT 5Expires: January 10, 2005 July 12, 2004 6 7 8 GSSAPI Mechanisms without a Single Canonical Name 9 draft-hartman-gss-naming-00.txt 10 11Status of this Memo 12 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I 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 other 20 groups may also distribute working documents as Internet-Drafts. 21 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 26 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 29 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 32 33 This Internet-Draft will expire on January 10, 2005. 34 35Copyright Notice 36 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 39Abstract 40 41 The Generic Security Services API (GSSAPI) uses name-based 42 authorization. GSSAPI authenticates two named parties to each other. 43 Names can be stored on access control lists to make authorization 44 decisions. Advances in security mechanisms require this model to be 45 extended. Some mechanisms such as public-key mechanisms do not have 46 a single name to be used. Other mechanisms such as Kerberos allow 47 names to change as people move around organizations. This document 48 proposes expanding the definition of GSSAPI names to deal with these 49 situations. 50 51 52 53 54 55Hartman Expires January 10, 2005 [Page 1] 56 57Internet-Draft GSS Name Attributes July 2004 58 59 601. Introduction 61 62 The Generic Security Services API [1] provides a function called 63 gss_export_name that will flatten a GSSAPI name into a binary blob 64 suitable for comparisons. This binary blob can be stored on ACLs 65 and then authorization decisions can be made simply by comparing the 66 name exported from a newly accepted context to the name on the ACL. 67 68 As a side effect of this name-based authorization model, each 69 mechanism name needs to be able to be represented in a single 70 canonical form and anyone importing that name needs to be able to 71 retrieve the canonical form. 72 73 Several security mechanisms have been proposed for which this naming 74 architecture is too restrictive. In some cases it is not always 75 possible to canonicalize any name that is imported. In other cases 76 there is no single canonical name. In addition, there is a desire to 77 have more complex authorization models in GSSAPI than the current 78 name based authorization model. 79 80 This draft discusses two different cases where the current GSSAPI 81 naming seems inadequate. Then, an extension to GSSAPI naming to meet 82 these concerns is sketched. 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 111Hartman Expires January 10, 2005 [Page 2] 112 113Internet-Draft GSS Name Attributes July 2004 114 115 1162. Kerberos Naming 117 118 The Kerberos Referals draft [2] proposes a new type of Kerberos name 119 called an enterprise name. The intent is that the enterprise name is 120 an alias that the user knows for themselves and can use to login. 121 The Kerberos KDC translates this name into a normal Kerberos 122 principal and gives the user tickets for this principal. This normal 123 principal is used for authorization. The intent is that the 124 enterprise name tracks the user as they move throughout the 125 organization, even if they move to parts of the organization that 126 have different naming policies. The name they type at login 127 remains constant, but the Kerberos principal used to authenticate 128 them to services changes. 129 130 Performing a mapping from enterprise name to principal name is not 131 generally possible for unauthenticated services. So in order to 132 canonicalize an enterprise name to get a principal, a service must 133 have credentials. However it may not be desirable to allow 134 services to map enterprise names to principal names in the general 135 case. Also, Kerberos does not (and does not plan to) provide a 136 mechanism for mapping enterprise names to principals besides 137 authentication as the enterprise name. So any such mapping would be 138 vendor-specific. With this feature in Kerberos, it is not possible 139 to implement gss_canonicalize_name for enterprise name types. 140 141 Another issue arises with enterprise names. IN some cases it would 142 be desirable to put the enterprise name on the ACL instead of a 143 principal name. Thus, it would be desirable to include the 144 enterprise name in the name exported by gss_export_name. However 145 then the exported name would change whenever the mapping changed, 146 defeating the purpose of including the enterprise name. So in some 147 cases it would be desirable to have the exported name be based on the 148 enterprise name and in others based on the principal name, but this 149 is not currently possible. 150 151 Another development also complicates GSSAPI naming for Kerberos. 152 Several vendors have been looking at mechanisms to include group 153 membership information in Kerberos authorization data. Then it is 154 desirable to put these group names on ACLs. Again, GSSAPI currently 155 has no mechanism to use this information. 156 157 158 159 160 161 162 163 164 165 166 167Hartman Expires January 10, 2005 [Page 3] 168 169Internet-Draft GSS Name Attributes July 2004 170 171 1723. X.509 Names 173 174 X.509 names are at least as complex as Kerberos names. It seems like 175 you might want to use the subject name as the name to be exported in 176 a GSSAPI mechanism. However RFC 3280 [3] does not even require the 177 subject name to be a non-empty sequence. Instead there are cases 178 where the subjectAltName extension is the only thing to identify the 179 subject of the certificate. As in the case of Kerberos group 180 memberships, there may be many subjectAltName extensions available in 181 a certificate. Different applications will care about different 182 extensions. Thus there is no single value that can be defined as 183 the exported GSSAPI name that will be generally useful. 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 223Hartman Expires January 10, 2005 [Page 4] 224 225Internet-Draft GSS Name Attributes July 2004 226 227 2284. Composite Names 229 230 I propose extending the concept of a GSSAPI name to include a 231 collection of attributes. Each attribute would be an octet-string 232 labeled by an OID. Examples of attributes would include Kerberos 233 enterprise names, group memberships in an authorization 234 infrastructure, Kerberos authorization data attributes and 235 subjectAltName attributes in a certificate. Several new operations 236 would be needed: 237 1. Add attribute to name 238 2. Query attributes of name 239 3. Query values of an attribute 240 4. Delete an attribute from a name 241 2424.1 Usage of Name Attributes 243 244 Since attributes are part of GSSAPI names, the acceptor can retrieve 245 the attributes of the initiator's name from the context. These 246 attributes can then be used for authorization. 247 248 Most name attributes will probably not come from explicit operations 249 to add attributes to a name. Instead, name attributes will probably 250 come from mechanism specific credentials. Mechanism specific 251 naming and group membership can be mapped into name attributes by 252 the mechanism implementation. The specific form of this mapping 253 will general require protocol specification for each mechanism. 254 2554.2 Open issues 256 257 This section describes parts of the proposal to add attributes to 258 names that will need to be explored before the proposal can become a 259 protocol specification. 260 261 Are mechanisms expected to be able to carry arbitrary name attributes 262 as part of a context establishment? At first it seems like this 263 would be desirable. However the point of GSSAPI is to establish an 264 authenticated context between two peers. In particular, a context 265 authenticates two named entities to each other. The names of these 266 entities and attributes associated with these names will be used for 267 authorization decisions. If an initiator or acceptor is allowed to 268 assert name attributes and the authenticity of these assertions is 269 not validated by the mechanisms, then security problems may result. 270 On the other hand, requiring that name attributes be mechanism 271 specific and only be carried by mechanisms that understand the name 272 attributes and can validate them compromises GSSAPI's place as a 273 generic API. Application authors would be forced to understand 274 mechanism-specific attributes to make authorization decisions. In 275 addition if mechanisms are not required to transport arbitrary 276 277 278 279Hartman Expires January 10, 2005 [Page 5] 280 281Internet-Draft GSS Name Attributes July 2004 282 283 284 attributes, then application authors will need to deal with different 285 implementations of the same mechanism that support different sets of 286 name attributes. 287 288 Another related question is how will name attributes be mapped into 289 their mechanism-specific forms. For example it would be desirable to 290 map many Kerberos authorization data elements into name attributes. 291 For example in the case of the Microsoft PAC, it would be desirable 292 for some applications to get the entire PAC. However in many cases, 293 the specific lists of security IDs contained in the PAC would be more 294 directly useful to an application. So there may not be a good 295 one-to-one mapping between the mechanism-specific elements and the 296 representation desirable at the GSSAPI layer. 297 298 Specific name matching rules need to be developed. How do names with 299 attributes compare? What is the effect of a name attribute on a 300 target name in gss_accept_sec_context? 301 3024.3 Name Attributes Instead of Credential Extensions 303 304 An alternative to this proposal is to extend GSSAPI credentials with 305 extensions labeled by OIDs. Interfaces would be needed to manipulate 306 these credential extensions and to retrieve the credential extensions 307 for credentials used to establish a context. Even if name attributes 308 are used, credential extensions may be useful for other unrelated 309 purposes. 310 311 It is possible to solve problems discussed in this document using 312 some credential extension mechanism. Doing so will have many of the 313 same open issues as discussed in this name attributes proposal. The 314 main advantage of a credential extensions proposal is that it avoids 315 specifying how name attributes interact with name comparison or 316 target names. 317 318 The primary advantage of the name attributes proposal over credential 319 extensions is that name attributes seem to fit better into the GSSAPI 320 authorization model. Names are already available at all points 321 when authorization decisions are made. In addition, for many 322 mechanisms the sort of information carried as name attributes will 323 also be carried as part of the name in the mechanism 324 325 326 327 328 329 330 331 332 333 334 335Hartman Expires January 10, 2005 [Page 6] 336 337Internet-Draft GSS Name Attributes July 2004 338 339 3405. Handling gss_export_name 341 342 For many mechanisms, there will be an obvious choice to use for the 343 name exported by gss_export_name. For example in the case of 344 Kerberos, the principal name can continue to be used as the exported 345 name. This will allow applications depending on existing GSSAPI 346 name-based authorization to continue to work. However it is probably 347 desirable to allow GSSAPI mechanisms for which gss_export_name cannot 348 meaningfully be defined. The behavior of gss_export_name in such 349 cases should probably be to return some error. Such mechanisms may 350 not work with existing applications and cannot conform to the current 351 version of the GSSAPI. 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391Hartman Expires January 10, 2005 [Page 7] 392 393Internet-Draft GSS Name Attributes July 2004 394 395 3966. Security Considerations 397 398 GSSAPI sets up a security context between two named parties. The 399 GSSAPI names are security assertions that are authenticated by the 400 context establishment process. As such the GSS naming architecture 401 is critical to the security of GSSAPI. 402 403 Currently GSSAPI uses a simplistic naming model for authorization. 404 Names can be compared against a set of names on an access control 405 list. This architecture is relatively simple and its security 406 properties are well understood. However it does not provide the 407 flexibility and feature set for future deployments of GSSAPI. 408 409 This proposal will significantly increase the complexity of the GSS 410 naming architecture. As this proposal is fleshed out, we need to 411 consider ways of managing security exposures created by this 412 increased complexity. 413 414 415 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 445 446 447Hartman Expires January 10, 2005 [Page 8] 448 449Internet-Draft GSS Name Attributes July 2004 450 451 4527. Acknowledgements 453 454 John Brezak, Paul Leach and Nicolas Williams all participated in 455 discussions that defined the problem this proposal attempts to solve. 456 Nicolas Williams and I discussed details of proposals to solve this 457 problem. However the details and open issues presented here have 458 only been reviewed by me and so I am responsible for their errors. 459 4608 Informative References 461 462 [1] Linn, J., "Generic Security Service Application Program 463 Interface Version 2, Update 1", RFC 2743, January 2000. 464 465 [2] Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating 466 KDC Referrals to locate Kerberos realms", 467 draft-ietf-krb-wg-kerberos-referals-03.txt (work in progress), 468 2004. 469 470 [3] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 471 Public Key Infrastructure Certificate and Certificate Revocation 472 List (CRL) Profile", rfc 3280, April 2002. 473 474 475Author's Address 476 477 Sam Hartman 478 MIT 479 480 EMail: hartmans@mit.edu 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503Hartman Expires January 10, 2005 [Page 9] 504 505Internet-Draft GSS Name Attributes July 2004 506 507 508Intellectual Property Statement 509 510 The IETF takes no position regarding the validity or scope of any 511 Intellectual Property Rights or other rights that might be claimed to 512 pertain to the implementation or use of the technology described in 513 this document or the extent to which any license under such rights 514 might or might not be available; nor does it represent that it has 515 made any independent effort to identify any such rights. Information 516 on the IETF's procedures with respect to rights in IETF Documents can 517 be found in BCP 78 and BCP 79. 518 519 Copies of IPR disclosures made to the IETF Secretariat and any 520 assurances of licenses to be made available, or the result of an 521 attempt made to obtain a general license or permission for the use of 522 such proprietary rights by implementers or users of this 523 specification can be obtained from the IETF on-line IPR repository at 524 http://www.ietf.org/ipr. 525 526 The IETF invites any interested party to bring to its attention any 527 copyrights, patents or patent applications, or other proprietary 528 rights that may cover technology that may be required to implement 529 this standard. Please address the information to the IETF at 530 ietf-ipr@ietf.org. 531 532 533Disclaimer of Validity 534 535 This document and the information contained herein are provided on an 536 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 537 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 538 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 539 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 540 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 541 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 542 543 544Copyright Statement 545 546 Copyright (C) The Internet Society (2004). This document is subject 547 to the rights, licenses and restrictions contained in BCP 78, and 548 except as set forth therein, the authors retain all their rights. 549 550 551Acknowledgment 552 553 Funding for the RFC Editor function is currently provided by the 554 Internet Society. 555 556 557 558 559Hartman Expires January 10, 2005 [Page 10] 560 561 562