idnits 2.17.1 draft-ietf-kitten-gss-naming-00.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 386. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 42 has weird spacing: '...upports name-...' == Line 70 has weird spacing: '...ea that mecha...' == Line 114 has weird spacing: '...erprise name ...' == Line 126 has weird spacing: '... to put the ...' == Line 131 has weird spacing: '...purpose of in...' == (12 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 (November 30, 2004) is 7080 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. '4') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3281 (ref. '5') (Obsoleted by RFC 5755) Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Hartman 2 Internet-Draft MIT 3 Expires: May 31, 2005 November 30, 2004 5 Desired Enhancements to GSSAPI Naming 6 draft-ietf-kitten-gss-naming-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 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." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 31, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 The Generic Security Services API (GSS-API) provides a naming 42 architecture that supports name-based authorization. GSS-API 43 authenticates two named parties to each other. Names can be stored 44 on access control lists to make authorization decisions. Advances in 45 security mechanisms and the way implementers wish to use GSS-API 46 require this model to be extended. Some mechanisms such as 47 public-key mechanisms do not have a single name to be used across all 48 environments. Other mechanisms such as Kerberos allow names to 49 change as people move around organizations. This document proposes 50 expanding the definition of GSS-API names to deal with these 51 situations. 53 1. Introduction 55 The Generic Security Services API [1] authenticates two named parties 56 to each other. GSS names can be imported in a variety of formats 57 through the gss_import_name call. Several mechanism-independent name 58 formats such as GSS_C_NT_HOSTBASED_SERVICE for services running on an 59 Internet host and GSS_C_NT_USER_NAME for the names of users. Other 60 mechanism-specific name types are also provided. By the time a name 61 is used in acquiring a mechanism-specific credential or establishing 62 a security context, it has been transformed into one of these 63 mechanism-specific name types. In addition, the GSS-API provides a 64 function called gss_export_name that will flatten a GSS-API name into 65 a binary blob suitable for comparisons. This binary blob can be 66 stored on ACLs and then authorization decisions can be made simply by 67 comparing the name exported from a newly accepted context to the name 68 on the ACL. 70 Inherent in this model is the idea that mechanism names need to be 71 able to be represented in a single canonical form. Anyone importing 72 that name needs to be able to retrieve the canonical form of that 73 name. 75 Several security mechanisms have been proposed for which this naming 76 architecture is too restrictive. In some cases it is not always 77 possible to canonicalize any name that is imported. In other cases 78 there is no single canonical name. 80 Storing names on ACLs can be problematic because names tend to change 81 over time . If the name contains organizational information such as 82 a domain part or an indication of what department someone works for, 83 this changes as the person moves around the organization. Even if no 84 organizational information is included in the name, the name will 85 change as people change their names. Updating ACLs to reflect name 86 changes is difficult. 88 Also, as GSS-API is used in more complex environments, there is a 89 desire to use attribute certificates [5], Kerberos authorization data 90 [2], or other non-name-based authorization models. GSS-API needs to 91 be enhanced in order to support these uses in a mechanism-independent 92 manner. 94 This draft discusses two different cases where the current GSS-API 95 naming seems inadequate. Two proposals that have been discussed 96 within the IETF Kitten community are discussed. Finally, the 97 problems that need to be resolved to adopt either of these proposals 98 are discussed. 100 2. Kerberos Naming 102 The Kerberos Referrals draft [3] proposes a new type of Kerberos name 103 called an enterprise name. The intent is that the enterprise name is 104 an alias that the user knows for themselves and can use to login. 105 The Kerberos KDC translates this name into a normal Kerberos 106 principal and gives the user tickets for this principal. This normal 107 principal is used for authorization. The intent is that the 108 enterprise name tracks the user as they move throughout the 109 organization, even if they move to parts of the organization that 110 have different naming policies. The name they type at login remains 111 constant, but the Kerberos principal used to authenticate them to 112 services changes. 114 Performing a mapping from enterprise name to principal name is not 115 generally possible for unauthenticated services. So in order to 116 canonicalize an enterprise name to get a principal, a service must 117 have credentials. However it may not be desirable to allow services 118 to map enterprise names to principal names in the general case. 119 Also, Kerberos does not (and does not plan to) provide a mechanism 120 for mapping enterprise names to principals besides authentication as 121 the enterprise name. Thus, any such mapping would be 122 vendor-specific. With this feature in Kerberos, it is not possible 123 to implement gss_canonicalize_name for enterprise name types. 125 Another issue arises with enterprise names. IN some cases it would 126 be desirable to put the enterprise name on the ACL instead of a 127 principal name. Thus, it would be desirable to include the 128 enterprise name in the name exported by gss_export_name. 129 Unfortunately, if this were done, the exported name would change 130 whenever the mapping changed, invalidating any ACL entries based off 131 the old exported name and defeating the purpose of including the 132 enterprise name. In some cases it would be desirable to have the 133 exported name be based on the enterprise name and in others based on 134 the principal name, but this is not permitted by the current GSS-API. 136 Another development also complicates GSS-API naming for Kerberos. 137 Several vendors have been looking at mechanisms to include group 138 membership information in Kerberos authorization data. It is 139 desirable to put these group names on ACLs. Again, GSS-API currently 140 has no mechanism to use this information. 142 3. X.509 Names 144 X.509 names are at least as complex as Kerberos names. It seems the 145 subject name might be the appropriate name to use as the name to be 146 exported in a GSS-API mechanism. However RFC 3280 [4] does not even 147 require the subject name to be a non-empty sequence. Instead there 148 are cases where the subjectAltName extension is the only thing to 149 identify the subject of the certificate. As in the case of Kerberos 150 group memberships, there may be many subjectAltName extensions 151 available in a certificate. Different applications will care about 152 different extensions. Thus there is no single value that can be 153 defined as the exported GSS-API name that will be useful in all 154 environments. 156 A profile of a particular X.509 GSS-API mechanism could require a 157 specific name be used. However this would limit that mechanism to 158 require a particular type of certificate. There is interest in being 159 able to use arbitrary X.509 certificates with GSS-API for some 160 applications. 162 4. Composite Names 164 One proposal to solve these problems is to extend the concept of a 165 GSS-API name to include a set of name attributes. Each attribute 166 would be an octet-string labeled by an OID. Examples of attributes 167 would include Kerberos enterprise names, group memberships in an 168 authorization infrastructure, Kerberos authorization data attributes 169 and subjectAltName attributes in a certificate. Several new 170 operations would be needed: 171 1. Add attribute to name 172 2. Query attributes of name 173 3. Query values of an attribute 174 4. Delete an attribute from a name 176 4.1 Usage of Name Attributes 178 Since attributes are part of GSS-API names, the acceptor can retrieve 179 the attributes of the initiator's name from the context. These 180 attributes can then be used for authorization. 182 Most name attributes will probably not come from explicit operations 183 to add attributes to a name. Instead, name attributes will probably 184 come from mechanism specific credentials. Mechanism specific naming 185 and group membership can be mapped into name attributes by the 186 mechanism implementation. The specific form of this mapping will 187 generally require protocol specification for each mechanism. 189 The value of many name attributes may be suitable for use in binary 190 comparison. This should enable applications to use these name 191 attributes on ACLs the same way exported names are now used on ACLs. 192 For example if a particular Subjectaltname extension contains the 193 appropriate identity for an application, then the name attribute 194 for this Subjectaltname can be placed on the ACL. This is only true 195 if the name attribute is stored in some canonical form. 197 4.2 Open issues 199 This section describes parts of the proposal to add attributes to 200 names that will need to be explored before the proposal can become a 201 protocol specification. 203 Are mechanisms expected to be able to carry arbitrary name attributes 204 as part of a context establishment? At first it seems like this 205 would be desirable. However the purpose of GSS-API is to establish 206 an authenticated context between two peers. In particular, a context 207 authenticates two named entities to each other. The names of these 208 entities and attributes associated with these names will be used for 209 authorization decisions. If an initiator or acceptor is allowed to 210 assert name attributes and the authenticity of these assertions is 211 not validated by the mechanisms, then security problems will result. 212 On the other hand, requiring that name attributes be mechanism 213 specific and only be carried by mechanisms that understand the name 214 attributes and can validate them compromises GSS-API's place as a 215 generic API. Application authors would be forced to understand 216 mechanism-specific attributes to make authorization decisions. In 217 addition if mechanisms are not required to transport arbitrary 218 attributes, then application authors will need to deal with different 219 implementations of the same mechanism that support different sets of 220 name attributes. One possible solution is to carry a source along 221 with each name attribute; this source could indicate whether the 222 attribute comes from a mechanism data structure or from the other 223 party in the authentication. 225 Another related question is how will name attributes be mapped into 226 their mechanism-specific forms. For example it would be desirable to 227 map many Kerberos authorization data elements into name attributes. 228 In the case of the Microsoft PAC, it would be desirable for some 229 applications to get the entire PAC. However in many cases, the 230 specific lists of security IDs contained in the PAC would be more 231 directly useful to an application. So there may not be a good 232 one-to-one mapping between the mechanism-specific elements and the 233 representation desirable at the GSS-API layer. 235 Specific name matching rules need to be developed. How do names with 236 attributes compare? What is the effect of a name attribute on a 237 target name in gss_accept_sec_context? 239 4.3 Handling gss_export_name 241 For many mechanisms, there will be an obvious choice to use for the 242 name exported by gss_export_name. For example in the case of 243 Kerberos, the principal name can continue to be used as the exported 244 name. This will allow applications depending on existing GSS-API 245 name-based authorization to continue to work. However it is probably 246 desirable to allow GSS-API mechanisms for which gss_export_name 247 cannot meaningfully be defined. The behavior of gss_export_name in 248 such cases should probably be to return some error. Such mechanisms 249 may not work with existing applications and cannot conform to the 250 current version of the GSS-API. 252 5. Credential Extensions 254 An alternative to the name attributes proposal is to extend GSS-API 255 credentials with extensions labeled by OIDs. Interfaces would be 256 needed to manipulate these credential extensions and to retrieve the 257 credential extensions for credentials used to establish a context. 258 Even if name attributes are used, credential extensions may be useful 259 for other unrelated purposes. 261 It is possible to solve problems discussed in this document using 262 some credential extension mechanism. Doing so will have many of the 263 same open issues as discussed in the composite names proposal. The 264 main advantage of a credential extensions proposal is that it avoids 265 specifying how name attributes interact with name comparison or 266 target names. 268 The primary advantage of the name attributes proposal over credential 269 extensions is that name attributes seem to fit better into the 270 GSS-API authorization model. Names are already available at all 271 points when authorization decisions are made. In addition, for many 272 mechanisms the sort of information carried as name attributes will 273 also be carried as part of the name in the mechanism 275 6. Mechanisms for Export Name 277 Another proposal is to define some GSS-API mechanisms whose only 278 purpose is to have an exportable name form that is useful. For 279 example, you might be able to export a name as a local machine user 280 ID with such a mechanism. 282 This solution works well especially for name information that can be 283 looked up in a directory. It was unclear from the p discussion 284 whether this solution would allow mechanism-specific name information 285 to be extracted from a context. If so, then this solution would meet 286 many of the goals of this document. 288 One advantage of this solution is that it requires few if any changes 289 to GSS-API semantics. It is not as flexible as other solutions. 290 Also, it is not clear how to handle mechanisms that do not have a 291 well defined name to export with this solution. 293 7. Deferring Credential Binding 295 Currently GSS-API credentials represent a single mechanism name. 296 While working on other issues discussion focused around choosing the 297 correct credential for a particular target. There are several 298 situations where an implementation can do a better job of choosing a 299 default source name to use given the name of the target to connect 300 to. Currently, GSS-API does not provide a mechanism to do this. 301 Adding such a mechanism would be desirable. 303 8. Security Considerations 305 GSS-API sets up a security context between two named parties. The 306 GSS-API names are security assertions that are authenticated by the 307 context establishment process. As such the GSS naming architecture 308 is critical to the security of GSS-API. 310 Currently GSS-API uses a simplistic naming model for authorization. 311 Names can be compared against a set of names on an access control 312 list. This architecture is relatively simple and its security 313 properties are well understood. However it does not provide the 314 flexibility and feature set for future deployments of GSS-API. 316 This proposal will significantly increase the complexity of the GSS 317 naming architecture. As this proposal is fleshed out, we need to 318 consider ways of managing security exposures created by this 319 increased complexity. 321 9. Acknowledgements 323 John Brezak, Paul Leach and Nicolas Williams all participated in 324 discussions that lead to a desire to enhance GSS naming. Martin Rex 325 provided descriptions of the current naming architecture and pointed 326 out many ways in which proposed enhancements would create 327 interoperability problems or increase complexity. Martin also 328 provided excellent information on what aspects of GSS naming have 329 tended to be implemented badly or have not met the needs of some 330 customers. 332 Nicolas Williams helped describe the possible approaches for 333 enhancing naming. 335 10 Informative References 337 [1] Linn, J., "Generic Security Service Application Program 338 Interface Version 2, Update 1", RFC 2743, January 2000. 340 [2] Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos 341 Network Authentication Service (V5)", 342 draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in 343 progress), June 2004. 345 [3] Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating 346 KDC Referrals to locate Kerberos realms", 347 draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress), 348 2004. 350 [4] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 351 Public Key Infrastructure Certificate and Certificate Revocation 352 List (CRL) Profile", rfc 3280, April 2002. 354 [5] Farrell, S. and R. Housley, "An Internet Attribute Certificate 355 Profile for Authorization.", rfc 3281, April 2002. 357 Author's Address 359 Sam Hartman 360 MIT 362 EMail: hartmans@mit.edu 364 Intellectual Property Statement 366 The IETF takes no position regarding the validity or scope of any 367 Intellectual Property Rights or other rights that might be claimed to 368 pertain to the implementation or use of the technology described in 369 this document or the extent to which any license under such rights 370 might or might not be available; nor does it represent that it has 371 made any independent effort to identify any such rights. Information 372 on the procedures with respect to rights in RFC documents can be 373 found in BCP 78 and BCP 79. 375 Copies of IPR disclosures made to the IETF Secretariat and any 376 assurances of licenses to be made available, or the result of an 377 attempt made to obtain a general license or permission for the use of 378 such proprietary rights by implementers or users of this 379 specification can be obtained from the IETF on-line IPR repository at 380 http://www.ietf.org/ipr. 382 The IETF invites any interested party to bring to its attention any 383 copyrights, patents or patent applications, or other proprietary 384 rights that may cover technology that may be required to implement 385 this standard. Please address the information to the IETF at 386 ietf-ipr@ietf.org. 388 Disclaimer of Validity 390 This document and the information contained herein are provided on an 391 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 392 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 393 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 394 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 395 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 396 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 398 Copyright Statement 400 Copyright (C) The Internet Society (2004). This document is subject 401 to the rights, licenses and restrictions contained in BCP 78, and 402 except as set forth therein, the authors retain all their rights. 404 Acknowledgment 406 Funding for the RFC Editor function is currently provided by the 407 Internet Society.