idnits 2.17.1 draft-ietf-kitten-gss-naming-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 507. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 31, 2006) is 6447 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-krb-wg-kerberos-clarifications-06 == Outdated reference: A later version (-15) exists of draft-ietf-krb-wg-kerberos-referrals-03 -- Obsolete informational reference (is this intentional?): RFC 3280 (ref. '5') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3281 (ref. '6') (Obsoleted by RFC 5755) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hartman 3 Internet-Draft MIT 4 Expires: March 4, 2007 August 31, 2006 6 Desired Enhancements to GSSAPI Version 3 Naming 7 draft-ietf-kitten-gss-naming-05.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 4, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The Generic Security Services API (GSS-API) provides a naming 41 architecture that supports name-based authorization. GSS-API 42 authenticates two named parties to each other. Names can be stored 43 on access control lists to make authorization decisions. Advances in 44 security mechanisms and the way implementers wish to use GSS-API 45 require this model to be extended for the next version of GSS-API. 46 As people move within an organization or change their names, the name 47 authenticated by GSS-API may change. Using some sort of constant 48 identifier would make ACLs more stable. Some mechanisms such as 49 public-key mechanisms do not have a single name to be used across all 50 environments. Other mechanisms such as Kerberos may include group 51 membership or role information as part of authentication. This 52 document motivates extensions to GSS-API naming and describes the 53 extensions under discussion. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Kerberos Naming . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. X.509 Names . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Composite Names . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. Usage of Name Attributes . . . . . . . . . . . . . . . . . 7 62 4.2. Open issues . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.3. Handling gss_export_name . . . . . . . . . . . . . . . . . 8 64 5. Credential Extensions . . . . . . . . . . . . . . . . . . . . 10 65 6. Mechanisms for Export Name . . . . . . . . . . . . . . . . . . 11 66 7. Selection of Source Identity . . . . . . . . . . . . . . . . . 12 67 8. Compatibility with GSS-API V2 . . . . . . . . . . . . . . . . 13 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 70 11. Informative References . . . . . . . . . . . . . . . . . . . . 15 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 Intellectual Property and Copyright Statements . . . . . . . . . . 17 74 1. Introduction 76 The Generic Security Services API [2] authenticates two named parties 77 to each other. GSS names can be imported in a variety of formats 78 through the gss_import_name call. Several mechanism-independent name 79 formats are provided including GSS_C_NT_HOSTBASED_SERVICE for 80 services running on an Internet host and GSS_C_NT_USER_NAME for the 81 names of users. Other mechanism-specific name types are also 82 provided. By the time a name is used in acquiring a mechanism- 83 specific credential or establishing a security context, it has been 84 transformed into one of these mechanism-specific name types. In 85 addition, the GSS-API provides a function called gss_export_name that 86 will transform a GSS-API name into a binary blob suitable for 87 comparisons. This binary blob can be stored on ACLs and then 88 authorization decisions can be made simply by comparing the name 89 exported from a newly accepted context to the name on the ACL. 91 Storing names on ACLs can be problematic because names tend to change 92 over time . If the name contains organizational information such as 93 a domain part or an indication of what department someone works for, 94 this changes as the person moves around the organization. Even if no 95 organizational information is included in the name, the name will 96 change as people change their names. Updating ACLs to reflect name 97 changes is difficult. Another significant problem is that names can 98 be reused to apply to an entity other than the entity to which they 99 originally applied. For example if a Unix user ID is placed on an 100 ACL, the account deleted and then a new user assigned the old ID, 101 then that new user may gain privileges intended for the old user. 103 Inherent in the GSS naming model is the idea that mechanism names 104 need to be able to be represented in a single canonical form. Anyone 105 importing that name needs to be able to retrieve the canonical form 106 of that name. 108 Several security mechanisms have been proposed for which this naming 109 architecture is too restrictive. In some cases it is not always 110 possible to canonicalize any name that is imported. In other cases 111 there is no single canonical name. 113 Also, as GSS-API is used in more complex environments, there is a 114 desire to use attribute certificates [6], Kerberos authorization data 115 [3], or other non-name-based authorization models. GSS-API needs to 116 be enhanced in order to support these uses in a mechanism-independent 117 manner. 119 This document discusses the particular naming problems with two 120 important classes of GSS-API mechanisms. It also discusses the set 121 of proposed solutions and open issues with these solutions. This 122 draft limits discussion to these solutions and provides a description 123 of the problem against which the solutions can be judged. These 124 solutions are targeted for incorporation into GSS-API Version 3. 126 2. Kerberos Naming 128 The Kerberos mechanism demonstrates both the naming stability problem 129 and the authorization extension problem. 131 The Kerberos Referrals draft [4] proposes a new type of Kerberos name 132 called an enterprise name. The intent is that the enterprise name is 133 an alias that the user knows for themselves and can use to login. 134 The Kerberos KDC translates this name into a normal Kerberos 135 principal and gives the user tickets for this principal. This normal 136 principal is used for authorization. The intent is that the 137 enterprise name tracks the user as they move throughout the 138 organization, even if they move to parts of the organization that 139 have different naming policies. The name they type at login remains 140 constant, but the Kerberos principal used to authenticate them to 141 services changes. 143 Unauthenticated services cannot generally perform a mapping from 144 enterprise name to principal name. Even authenticated services may 145 not be authorized to map names other than the name of the 146 authenticated service. Also, Kerberos does not (and does not plan 147 to) provide a mechanism for mapping enterprise names to principals 148 besides authentication as the enterprise name. Thus, any such 149 mapping would be vendor-specific. With this feature in Kerberos, it 150 is not possible to implement gss_canonicalize_name for enterprise 151 name types. Of course other names types such as traditional 152 principal names could be used for GSS-API applications. Naturally 153 this loses the benefits of enterprise names. 155 Another issue arises with enterprise names. In some cases, it would 156 be desirable to put the enterprise name on the ACL instead of a 157 principal name for greater ACL stability. At first glance this could 158 be accomplished by including the enterprise name in the name exported 159 by gss_export_name. Unfortunately, if this were done, the exported 160 name would change whenever the mapping changed, invalidating any ACL 161 entries based off the old exported name and defeating the purpose of 162 including the enterprise name in the exported name. In some cases it 163 would be desirable to have the exported name be based on the 164 enterprise name and in others based on the principal name, but this 165 is not permitted by the current GSS-API. 167 Another development also complicates GSS-API naming for Kerberos. 168 Several vendors have been looking at mechanisms to include group 169 membership information in Kerberos authorization data. It is 170 desirable to put these group names on ACLs. Again, GSS-API currently 171 has no mechanism to use this information. 173 3. X.509 Names 175 X.509 names are more complicated than Kerberos names. In the 176 Kerberos case there is a single principal carried in all Kerberos 177 messages. X.509 certificates have multiple options. It seems the 178 subject name might be the appropriate name to use as the name to be 179 exported in a GSS-API mechanism. However RFC 3280 [5] allows the 180 subject name to be an empty sequence in end-entity certificates. 181 Therefore the subjectAltName extension might be the only portion of 182 the certificate that identifies the subject. As in the case of 183 Kerberos group memberships, there may be many subjectAltName 184 extensions available in a certificate. Different applications will 185 care about different name forms. One possible candidate for an 186 exported name would be all the names from the subject field and the 187 subjectAltName extension from a certificate. However as new names 188 are added then existing ACL entries would be invalidated; this is 189 undesirable. Thus there is no single value that can be defined as 190 the exported GSS-API name that will be useful in all environments. 192 A profile of a particular X.509 GSS-API mechanism could require a 193 specific name be used. However this would limit that mechanism to 194 require a particular type of certificate. There is interest in being 195 able to use arbitrary X.509 certificates with GSS-API for some 196 applications. 198 Experience so far has not lead to sufficient interoperability with 199 GSS-API X.509 mechanisms. Even if the subject name is used, there is 200 ambiguity in how to handle sorting of name components. Martin Rex 201 said that he was aware of several SPKM [1] implementations but no two 202 were fully interoperable on names. 204 Also, as discussed in the introduction, it is desirable to support 205 X.509 attribute certificates. 207 4. Composite Names 209 One proposal to solve these problems is to extend the concept of a 210 GSS-API name to include a set of name attributes. Each attribute 211 would be an octet-string labeled by an OID. Examples of attributes 212 would include Kerberos enterprise names, group memberships in an 213 authorization infrastructure, Kerberos authorization data attributes 214 and subjectAltName attributes in a certificate. Several new 215 operations would be needed: 217 1. Add an attribute to name. 219 2. Query attributes of name. 221 3. Query values of an attribute. 223 4. Delete an attribute from a name. 225 5. Export a complete composite name and all its attributes for 226 transport between processes. 228 Note that an exported composite name would not generally be suitable 229 for binary comparison. Avoiding confusion between this operation and 230 the existing gss_export_name operation will require careful work. 231 However many attributes of composite names will be appropriate for 232 binary comparisons. Such attributes can be used on ACLs just as 233 exported names are used on ACLs today. For example if a particular 234 SubjectAltName extension contains the appropriate identity for an 235 application, then the name attribute for this SubjectAltName can be 236 placed on the ACL. This is only true if the name attribute is stored 237 in some canonical form. 239 Additional utility operations will probably be needed depending on 240 the implementation of name attributes. 242 4.1. Usage of Name Attributes 244 Since attributes are part of GSS-API names, the acceptor can retrieve 245 the attributes of the initiator's and acceptor's name from the 246 context. These attributes can then be used for authorization. 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. Components of these 251 mechanism-specific credentials may come from platform or environment- 252 specific names. mechanism-specific naming and group membership can be 253 mapped into name attributes by the mechanism implementation. The 254 specific form of this mapping will generally require protocol 255 specification for each mechanism. 257 4.2. Open issues 259 This section describes parts of the proposal to add attributes to 260 names that will need to be explored before the proposal can become a 261 protocol specification. 263 Are mechanisms expected to be able to carry arbitrary name attributes 264 as part of a context establishment? At first it seems like this 265 would be desirable. However the purpose of GSS-API is to establish 266 an authenticated context between two peers. In particular, a context 267 authenticates two named entities to each other. The names of these 268 entities and attributes associated with these names will be used for 269 authorization decisions. If an initiator or acceptor is allowed to 270 assert name attributes and the authenticity of these assertions is 271 not validated by the mechanisms, then security problems will result. 272 On the other hand, requiring that name attributes be mechanism- 273 specific and only be carried by mechanisms that understand the name 274 attributes and can validate them compromises GSS-API's place as a 275 generic API. Application authors would be forced to understand 276 mechanism-specific attributes to make authorization decisions. In 277 addition if mechanisms are not required to transport arbitrary 278 attributes, then application authors will need to deal with different 279 implementations of the same mechanism that support different sets of 280 name attributes. One possible solution is to carry a source along 281 with each name attribute; this source could indicate whether the 282 attribute comes from a mechanism data structure or from the other 283 party in the authentication. 285 Another related question is how will name attributes be mapped into 286 their mechanism-specific forms. For example it would be desirable to 287 map many Kerberos authorization data elements into name attributes. 288 In the case of the Microsoft PAC, it would be desirable for some 289 applications to get the entire PAC. However in many cases, the 290 specific lists of security IDs contained in the PAC would be more 291 directly useful to an application. So there may not be a good one- 292 to-one mapping between the mechanism-specific elements and the 293 representation desirable at the GSS-API layer. 295 Specific name matching rules need to be developed. How do names with 296 attributes compare? What is the effect of a name attribute on a 297 target name in gss_accept_sec_context? 299 4.3. Handling gss_export_name 301 For many mechanisms, there will be an obvious choice to use for the 302 name exported by gss_export_name. For example in the case of 303 Kerberos, the principal name can continue to be used as the exported 304 name. This will allow applications depending on existing GSS-API 305 name-based authorization to continue to work. However it is probably 306 desirable to allow GSS-API mechanisms for which gss_export_name 307 cannot meaningfully be defined. The behavior of gss_export_name in 308 such cases should probably be to return some error. Such mechanisms 309 may not work with existing applications and cannot conform to the 310 current version of the GSS-API. 312 5. Credential Extensions 314 An alternative to the name attributes proposal is to extend GSS-API 315 credentials with extensions labeled by OIDs. Interfaces would be 316 needed to manipulate these credential extensions and to retrieve the 317 credential extensions for credentials used to establish a context. 318 Even if name attributes are used, credential extensions may be useful 319 for other unrelated purposes. 321 It is possible to solve problems discussed in this document using 322 some credential extension mechanism. Doing so will have many of the 323 same open issues as discussed in the composite names proposal. The 324 main advantage of a credential extensions proposal is that it avoids 325 specifying how name attributes interact with name comparison or 326 target names. 328 The primary advantage of the name attributes proposal over credential 329 extensions is that name attributes seem to fit better into the GSS- 330 API authorization model. Names are already available at all points 331 when authorization decisions are made. In addition, for many 332 mechanisms the sort of information carried as name attributes will 333 also be carried as part of the name in the mechanism 335 6. Mechanisms for Export Name 337 Another proposal is to define some GSS-API mechanisms whose only 338 purpose is to have an exportable name form that is useful. For 339 example, you might be able to export a name as a local machine user 340 ID with such a mechanism. 342 This solution works well especially for name information that can be 343 looked up in a directory. It was unclear whether this solution would 344 allow mechanism-specific name information to be extracted from a 345 context. If so, then this solution would meet many of the goals of 346 this document. 348 One advantage of this solution is that it requires few if any changes 349 to GSS-API semantics. It is not as flexible as other solutions. 350 Also, it is not clear how to handle mechanisms that do not have a 351 well defined name to export with this solution. 353 7. Selection of Source Identity 355 Today, applications such as e-mail clients and web browsers require 356 connections to multiple targets. For each target there may be one or 357 more source identities that is appropriate for the connection. 358 Currently each application must choose the source name to use when 359 acquiring credentials or initiating a security context. However the 360 rules that applications use can be generalized to a large extent. 361 GSS-API could simplify application design and implementation by 362 taking a larger role in selection of source identity to use when 363 connecting to a particular target. 365 Currently GSS-API credentials represent a single mechanism name. that 366 is, by the time credentials are acquired, they must act as if a 367 particular single identity is chosen for each mechanism in the 368 credential. All these identities must correspond to a single 369 mechanism independent name. 371 Two possibilities have been proposed for involving GSS-API in the 372 selection of source identities. First, the restriction that a 373 mechanism name must be chosen when credentials are acquired could be 374 relaxed. Some name form would need to be used, but this name form 375 could represent a set of possibilities. The particular identity 376 would be chosen when context establishment happened. This could 377 involve information received from the target in identity selection. 379 Another possibility is to provide a mechanism to acquire credentials 380 and to provide information about the target when credentials are 381 acquired. This would be much less of a change to GSS-API but would 382 not allow information received from the target to choose identity 383 selection. 385 With both approaches, information to communicate the needs of the 386 application to the GSS-API mechanism will be required. For example, 387 hinting about whether information can be cached and about the scope 388 of cache entries is required. 390 Another possibility can be implemented in GSS-API V2 today. Do not 391 bind the credentials to a mechanism name until either the credentials 392 are queried or they are used to set up a context. This is 393 undesirable because if an application uses the credential inquiry 394 interface then it will get different behavior than cases where this 395 interface is not used. For this reason, the working group favors an 396 extension to GSS-API V3. 398 8. Compatibility with GSS-API V2 400 In order to avoid breaking existing applications or mechanisms the 401 following backward compatibility requirements need to be met: 403 1. Existing APIs must continue to behave as they do in GSS-API V2. 405 2. GSS-API V2 mechanisms must produce the same exported name forms; 406 composite names cannot change the existing exported name forms. 408 3. Extensions add new optional behavior. 410 If GSS-API V3 mechanisms are more permissive than GSS-API V2 411 mechanisms then care must be taken so that GSS-API V2 applications do 412 not select these mechanisms. 414 9. Security Considerations 416 GSS-API sets up a security context between two named parties. The 417 GSS-API names are security assertions that are authenticated by the 418 context establishment process. As such the GSS naming architecture 419 is critical to the security of GSS-API. 421 Currently GSS-API uses a simplistic naming model for authorization. 422 Names can be compared against a set of names on an access control 423 list. This architecture is relatively simple and its security 424 properties are well understood. However it does not provide the 425 flexibility and feature set for future deployments of GSS-API. 427 This proposal will significantly increase the complexity of the GSS 428 naming architecture. As this proposal is fleshed out, we need to 429 consider ways of managing security exposures created by this 430 increased complexity. 432 One area where the complexity may lead to security problems is 433 composite names with attributes from different sources. This may be 434 desirable so that name attributes that carry their own 435 authentication. However the design of any solutions needs to make 436 sure that applications can assign appropriate trust to name 437 components. 439 10. Acknowledgements 441 John Brezak, Paul Leach and Nicolas Williams all participated in 442 discussions that lead to a desire to enhance GSS naming. Martin Rex 443 provided descriptions of the current naming architecture and pointed 444 out many ways in which proposed enhancements would create 445 interoperability problems or increase complexity. Martin also 446 provided excellent information on what aspects of GSS naming have 447 tended to be implemented badly or have not met the needs of some 448 customers. 450 Nicolas Williams helped describe the possible approaches for 451 enhancing naming. 453 11. Informative References 455 [1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", 456 rfc 2025, October 1996. 458 [2] Linn, J., "Generic Security Service Application Program 459 Interface Version 2, Update 1", RFC 2743, January 2000. 461 [3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos 462 Network Authentication Service (V5)", 463 draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in 464 progress), June 2004. 466 [4] Jaganathan , K., Zhu, L., Swift, M., and J. Brezak, "Generating 467 KDC Referrals to locate Kerberos realms", 468 draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress), 469 2004. 471 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 472 Public Key Infrastructure Certificate and Certificate Revocation 473 List (CRL) Profile", rfc 3280, April 2002. 475 [6] Farrell, S. and R. Housley, "An Internet Attribute Certificate 476 Profile for Authorization.", rfc 3281, April 2002. 478 Author's Address 480 Sam Hartman 481 MIT 483 Email: hartmans@mit.edu 485 Intellectual Property Statement 487 The IETF takes no position regarding the validity or scope of any 488 Intellectual Property Rights or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; nor does it represent that it has 492 made any independent effort to identify any such rights. Information 493 on the procedures with respect to rights in RFC documents can be 494 found in BCP 78 and BCP 79. 496 Copies of IPR disclosures made to the IETF Secretariat and any 497 assurances of licenses to be made available, or the result of an 498 attempt made to obtain a general license or permission for the use of 499 such proprietary rights by implementers or users of this 500 specification can be obtained from the IETF on-line IPR repository at 501 http://www.ietf.org/ipr. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights that may cover technology that may be required to implement 506 this standard. Please address the information to the IETF at 507 ietf-ipr@ietf.org. 509 Disclaimer of Validity 511 This document and the information contained herein are provided on an 512 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 513 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 514 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 515 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 516 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 517 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 519 Copyright Statement 521 Copyright (C) The Internet Society (2006). This document is subject 522 to the rights, licenses and restrictions contained in BCP 78, and 523 except as set forth therein, the authors retain all their rights. 525 Acknowledgment 527 Funding for the RFC Editor function is currently provided by the 528 Internet Society.