idnits 2.17.1 draft-ietf-kitten-gss-naming-03.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 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 462. ** 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 == Line 41 has weird spacing: '...upports name-...' == Line 84 has weird spacing: '... naming model...' == Line 123 has weird spacing: '...erprise name ...' == Line 134 has weird spacing: '... to put the ...' == Line 139 has weird spacing: '...purpose of...' == (18 more instances...) -- 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 (October 23, 2005) is 6758 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 (~~), 10 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: April 26, 2006 October 23, 2005 6 Desired Enhancements to GSSAPI Naming 7 draft-ietf-kitten-gss-naming-03.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 April 26, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 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. As people move within an 46 organization or change their names, the name authenticated by GSS-API 47 may change. Using some sort of constant identifier would make ACLs 48 more stable. Some mechanisms such as public-key mechanisms do not 49 have a single name to be used across all environments. Other 50 mechanisms such as Kerberos include may include group membership or 51 role information as part of authentication. This document motivates 52 extensions to GSS-API naming and describes the extensions under 53 discussion. 55 1. Introduction 57 The Generic Security Services API [2] authenticates two named parties 58 to each other. GSS names can be imported in a variety of formats 59 through the gss_import_name call. Several mechanism-independent name 60 formats are provided including GSS_C_NT_HOSTBASED_SERVICE for 61 services running on an Internet host and GSS_C_NT_USER_NAME for the 62 names of users. Other mechanism-specific name types are also 63 provided. By the time a name is used in acquiring a mechanism- 64 specific credential or establishing a security context, it has been 65 transformed into one of these mechanism-specific name types. In 66 addition, the GSS-API provides a function called gss_export_name that 67 will flatten a GSS-API name into a binary blob suitable for 68 comparisons. This binary blob can be stored on ACLs and then 69 authorization decisions can be made simply by comparing the name 70 exported from a newly accepted context to the name on the ACL. 72 Storing names on ACLs can be problematic because names tend to change 73 over time . If the name contains organizational information such as 74 a domain part or an indication of what department someone works for, 75 this changes as the person moves around the organization. Even if no 76 organizational information is included in the name, the name will 77 change as people change their names. Updating ACLs to reflect name 78 changes is difficult. Another significant problem is that names can 79 be reused to apply to another entity than the entity to which they 80 originally applied. For example if a Unix user ID is placed on an 81 ACL, the account deleted and then a new user assigned the old ID, 82 then that new user may gain privileges intended for the old user. 84 Inherent in the GSS naming model is the idea that mechanism names 85 need to be able to be represented in a single canonical form. Anyone 86 importing that name needs to be able to retrieve the canonical form 87 of that name. 89 Several security mechanisms have been proposed for which this naming 90 architecture is too restrictive. In some cases it is not always 91 possible to canonicalize any name that is imported. In other cases 92 there is no single canonical name. 94 Also, as GSS-API is used in more complex environments, there is a 95 desire to use attribute certificates [6], Kerberos authorization data 96 [3], or other non-name-based authorization models. GSS-API needs to 97 be enhanced in order to support these uses in a mechanism-independent 98 manner. 100 This document discusses the particular naming problems with two 101 important classes of GSS-API mechanisms. It also discusses the set 102 of proposed solutions and open issues with these solutions. This 103 draft limits discussion to these solutions and provides a description 104 of the problem against which the solutions can be judged. 106 2. Kerberos Naming 108 The Kerberos mechanism demonstrates both the naming stability problem 109 and the authorization extension problem. 111 The Kerberos Referrals draft [4] proposes a new type of Kerberos name 112 called an enterprise name. The intent is that the enterprise name is 113 an alias that the user knows for themselves and can use to login. 114 The Kerberos KDC translates this name into a normal Kerberos 115 principal and gives the user tickets for this principal. This normal 116 principal is used for authorization. The intent is that the 117 enterprise name tracks the user as they move throughout the 118 organization, even if they move to parts of the organization that 119 have different naming policies. The name they type at login remains 120 constant, but the Kerberos principal used to authenticate them to 121 services changes. 123 Performing a mapping from enterprise name to principal name is not 124 generally possible for unauthenticated services. Even authenticated 125 services may not be authorized to perform this mapping except for 126 their own name. Also, Kerberos does not (and does not plan to) 127 provide a mechanism for mapping enterprise names to principals 128 besides authentication as the enterprise name. Thus, any such 129 mapping would be vendor-specific. With this feature in Kerberos, it 130 is not possible to implement gss_canonicalize_name for enterprise 131 name types. 133 Another issue arises with enterprise names. In some cases, it would 134 be desirable to put the enterprise name on the ACL instead of a 135 principal name for greater ACL stability. At first glance this could 136 be accomplished by including the enterprise name in the name exported 137 by gss_export_name. Unfortunately, if this were done, the exported 138 name would change whenever the mapping changed, invalidating any ACL 139 entries based off the old exported name and defeating the purpose of 140 including the enterprise name in the exported name. In some cases it 141 would be desirable to have the exported name be based on the 142 enterprise name and in others based on the principal name, but this 143 is not permitted by the current GSS-API. 145 Another development also complicates GSS-API naming for Kerberos. 146 Several vendors have been looking at mechanisms to include group 147 membership information in Kerberos authorization data. It is 148 desirable to put these group names on ACLs. Again, GSS-API currently 149 has no mechanism to use this information. 151 3. X.509 Names 153 X.509 names are more complicated than Kerberos names. In the 154 Kerberos case there is a single principal carried in all Kerberos 155 messages. X.509 certificates have multiple options. It seems the 156 subject name might be the appropriate name to use as the name to be 157 exported in a GSS-API mechanism. However RFC 3280 [5] does not even 158 require the subject name to be a non-empty sequence. Instead there 159 are cases where the subjectAltName extension is the only thing to 160 identify the subject of the certificate. As in the case of Kerberos 161 group memberships, there may be many subjectAltName extensions 162 available in a certificate. Different applications will care about 163 different extensions. One possible candidate for an exported name 164 would be all the names and SubjectAltName extensions from a 165 certificate. However as new names are added then existing ACL 166 entries would be invalidated; this is undesirable. Thus there is no 167 single value that can be defined as the exported GSS-API name that 168 will be useful in all environments. 170 A profile of a particular X.509 GSS-API mechanism could require a 171 specific name be used. However this would limit that mechanism to 172 require a particular type of certificate. There is interest in being 173 able to use arbitrary X.509 certificates with GSS-API for some 174 applications. 176 Experience so far has not lead to sufficient interoperability with 177 GSS-API X.509 mechanisms. Even if the subject name is used, there is 178 ambiguity in how to handle sorting of name components. Martin Rex 179 said that he was aware of several SPKM [1] implementations but no two 180 were fully interoperable on names. 182 Also, as discussed in the introduction, it is desirable to support 183 X.509 attribute certificates. 185 4. Composite Names 187 One proposal to solve these problems is to extend the concept of a 188 GSS-API name to include a set of name attributes. Each attribute 189 would be an octet-string labeled by an OID. Examples of attributes 190 would include Kerberos enterprise names, group memberships in an 191 authorization infrastructure, Kerberos authorization data attributes 192 and subjectAltName attributes in a certificate. Several new 193 operations would be needed: 195 1. Add an attribute to name. 197 2. Query attributes of name. 199 3. Query values of an attribute. 201 4. Delete an attribute from a name. 203 5. Export a complete composite name and all its attributes for 204 transport between processes. 206 Note that an exported composite name would not generally be suitable 207 for binary comparison. Avoiding confusion between this operation and 208 the existing gss_export_name operation will require careful work. 210 Additional utility operations will probably be needed depending on 211 the implementation of name attributes. 213 4.1 Usage of Name Attributes 215 Since attributes are part of GSS-API names, the acceptor can retrieve 216 the attributes of the initiator's and acceptor's name from the 217 context. These attributes can then be used for authorization. 219 Most name attributes will probably not come from explicit operations 220 to add attributes to a name. Instead, name attributes will probably 221 come from mechanism specific credentials. Components of these 222 mechanism specific credentials may come from platform or environment- 223 specific names. Mechanism specific naming and group membership can 224 be mapped into name attributes by the mechanism implementation. The 225 specific form of this mapping will generally require protocol 226 specification for each mechanism. 228 The value of many name attributes may be suitable for use in binary 229 comparison. This should enable applications to use these name 230 attributes on ACLs the same way exported names are now used on ACLs. 231 For example if a particular SubjectAltname extension contains the 232 appropriate identity for an application, then the name attribute 233 for this SubjectAltname can be placed on the ACL. This is only true 234 if the name attribute is stored in some canonical form. 236 4.2 Open issues 238 This section describes parts of the proposal to add attributes to 239 names that will need to be explored before the proposal can become a 240 protocol specification. 242 Are mechanisms expected to be able to carry arbitrary name attributes 243 as part of a context establishment? At first it seems like this 244 would be desirable. However the purpose of GSS-API is to establish 245 an authenticated context between two peers. In particular, a context 246 authenticates two named entities to each other. The names of these 247 entities and attributes associated with these names will be used for 248 authorization decisions. If an initiator or acceptor is allowed to 249 assert name attributes and the authenticity of these assertions is 250 not validated by the mechanisms, then security problems will result. 251 On the other hand, requiring that name attributes be mechanism 252 specific and only be carried by mechanisms that understand the name 253 attributes and can validate them compromises GSS-API's place as a 254 generic API. Application authors would be forced to understand 255 mechanism-specific attributes to make authorization decisions. In 256 addition if mechanisms are not required to transport arbitrary 257 attributes, then application authors will need to deal with different 258 implementations of the same mechanism that support different sets of 259 name attributes. One possible solution is to carry a source along 260 with each name attribute; this source could indicate whether the 261 attribute comes from a mechanism data structure or from the other 262 party in the authentication. 264 Another related question is how will name attributes be mapped into 265 their mechanism-specific forms. For example it would be desirable to 266 map many Kerberos authorization data elements into name attributes. 267 In the case of the Microsoft PAC, it would be desirable for some 268 applications to get the entire PAC. However in many cases, the 269 specific lists of security IDs contained in the PAC would be more 270 directly useful to an application. So there may not be a good one- 271 to-one mapping between the mechanism-specific elements and the 272 representation desirable at the GSS-API layer. 274 Specific name matching rules need to be developed. How do names with 275 attributes compare? What is the effect of a name attribute on a 276 target name in gss_accept_sec_context? 278 4.3 Handling gss_export_name 280 For many mechanisms, there will be an obvious choice to use for the 281 name exported by gss_export_name. For example in the case of 282 Kerberos, the principal name can continue to be used as the exported 283 name. This will allow applications depending on existing GSS-API 284 name-based authorization to continue to work. However it is probably 285 desirable to allow GSS-API mechanisms for which gss_export_name 286 cannot meaningfully be defined. The behavior of gss_export_name in 287 such cases should probably be to return some error. Such mechanisms 288 may not work with existing applications and cannot conform to the 289 current version of the GSS-API. 291 5. Credential Extensions 293 An alternative to the name attributes proposal is to extend GSS-API 294 credentials with extensions labeled by OIDs. Interfaces would be 295 needed to manipulate these credential extensions and to retrieve the 296 credential extensions for credentials used to establish a context. 297 Even if name attributes are used, credential extensions may be useful 298 for other unrelated purposes. 300 It is possible to solve problems discussed in this document using 301 some credential extension mechanism. Doing so will have many of the 302 same open issues as discussed in the composite names proposal. The 303 main advantage of a credential extensions proposal is that it avoids 304 specifying how name attributes interact with name comparison or 305 target names. 307 The primary advantage of the name attributes proposal over credential 308 extensions is that name attributes seem to fit better into the GSS- 309 API authorization model. Names are already available at all points 310 when authorization decisions are made. In addition, for many 311 mechanisms the sort of information carried as name attributes will 312 also be carried as part of the name in the mechanism 314 6. Mechanisms for Export Name 316 Another proposal is to define some GSS-API mechanisms whose only 317 purpose is to have an exportable name form that is useful. For 318 example, you might be able to export a name as a local machine user 319 ID with such a mechanism. 321 This solution works well especially for name information that can be 322 looked up in a directory. It was unclear from the discussion whether 323 this solution would allow mechanism-specific name information to be 324 extracted from a context. If so, then this solution would meet many 325 of the goals of this document. 327 One advantage of this solution is that it requires few if any changes 328 to GSS-API semantics. It is not as flexible as other solutions. 329 Also, it is not clear how to handle mechanisms that do not have a 330 well defined name to export with this solution. 332 7. Selection of Source Identity 334 Today, applications such as e-mail clients and web browsers require 335 connections to multiple targets. For each target the there may be 336 one or more source identities that is appropriate for the connection. 337 Currently each application must choose the source name to use when 338 acquiring credentials or initiating a security context. However the 339 rules that applications use can be generalized to a large extent. 340 GSS-API could simplify application design and implementation by 341 taking a larger role in selection of source identity to use when 342 connecting to a particular target. 344 Currently GSS-API credentials represent a single mechanism name. that 345 is, by the time credentials are acquired, a particular single 346 identity must be chosen for each mechanism in the credential. All 347 these identities must correspond to a single mechanism independent 348 name. 350 Two possibilities have been proposed for involving GSS-API in the 351 selection of source identities. First, the restriction that a 352 mechanism name must be chosen when credentials are acquired could be 353 relaxed. Some name form would need to be used, but this name form 354 could represent a set of possibilities. The particular identity 355 would be chosen when context establishment happened. This could 356 involve information received from the target in identity selection. 358 Another possibility is to provide a mechanism to acquire credentials 359 and to provide information about the target when credentials are 360 acquired. This would be much less of a change to GSS-API but would 361 not allow information received from the target to choose identity 362 selection. 364 With both approaches, information to communicate the needs of the 365 application to the GSS-API mechanism will be required. For example, 366 hinting about whether information can be cached and about the scope 367 of cache entries is required. 369 8. Security Considerations 371 GSS-API sets up a security context between two named parties. The 372 GSS-API names are security assertions that are authenticated by the 373 context establishment process. As such the GSS naming architecture 374 is critical to the security of GSS-API. 376 Currently GSS-API uses a simplistic naming model for authorization. 377 Names can be compared against a set of names on an access control 378 list. This architecture is relatively simple and its security 379 properties are well understood. However it does not provide the 380 flexibility and feature set for future deployments of GSS-API. 382 This proposal will significantly increase the complexity of the GSS 383 naming architecture. As this proposal is fleshed out, we need to 384 consider ways of managing security exposures created by this 385 increased complexity. 387 One area where the complexity may lead to security problems is 388 composite names with attributes from different sources. This may be 389 desirable so that name attributes that carry their own 390 authentication. However the design of any solutions needs to make 391 sure that applications can assign appropriate trust to name 392 components. 394 9. Acknowledgements 396 John Brezak, Paul Leach and Nicolas Williams all participated in 397 discussions that lead to a desire to enhance GSS naming. Martin Rex 398 provided descriptions of the current naming architecture and pointed 399 out many ways in which proposed enhancements would create 400 interoperability problems or increase complexity. Martin also 401 provided excellent information on what aspects of GSS naming have 402 tended to be implemented badly or have not met the needs of some 403 customers. 405 Nicolas Williams helped describe the possible approaches for 406 enhancing naming. 408 10. Informative References 410 [1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", 411 rfc 2025, October 1996. 413 [2] Linn, J., "Generic Security Service Application Program 414 Interface Version 2, Update 1", RFC 2743, January 2000. 416 [3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos 417 Network Authentication Service (V5)", 418 draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in 419 progress), June 2004. 421 [4] Jaganathan , K., Zhu, L., Swift, M., and J. Brezak, "Generating 422 KDC Referrals to locate Kerberos realms", 423 draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress), 424 2004. 426 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 427 Public Key Infrastructure Certificate and Certificate Revocation 428 List (CRL) Profile", rfc 3280, April 2002. 430 [6] Farrell, S. and R. Housley, "An Internet Attribute Certificate 431 Profile for Authorization.", rfc 3281, April 2002. 433 Author's Address 435 Sam Hartman 436 MIT 438 Email: hartmans@mit.edu 440 Intellectual Property Statement 442 The IETF takes no position regarding the validity or scope of any 443 Intellectual Property Rights or other rights that might be claimed to 444 pertain to the implementation or use of the technology described in 445 this document or the extent to which any license under such rights 446 might or might not be available; nor does it represent that it has 447 made any independent effort to identify any such rights. Information 448 on the procedures with respect to rights in RFC documents can be 449 found in BCP 78 and BCP 79. 451 Copies of IPR disclosures made to the IETF Secretariat and any 452 assurances of licenses to be made available, or the result of an 453 attempt made to obtain a general license or permission for the use of 454 such proprietary rights by implementers or users of this 455 specification can be obtained from the IETF on-line IPR repository at 456 http://www.ietf.org/ipr. 458 The IETF invites any interested party to bring to its attention any 459 copyrights, patents or patent applications, or other proprietary 460 rights that may cover technology that may be required to implement 461 this standard. Please address the information to the IETF at 462 ietf-ipr@ietf.org. 464 Disclaimer of Validity 466 This document and the information contained herein are provided on an 467 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 468 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 469 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 470 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 471 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 472 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 474 Copyright Statement 476 Copyright (C) The Internet Society (2005). This document is subject 477 to the rights, licenses and restrictions contained in BCP 78, and 478 except as set forth therein, the authors retain all their rights. 480 Acknowledgment 482 Funding for the RFC Editor function is currently provided by the 483 Internet Society.