RFC 4768

Desired Enhancements to GSS-API Version 3 Naming 🎀

Network Working Group 🧚: this one is by S. Hartman from MIT 🦋. It's an Informational doc (so it's giving "here's some info," not a rule book 💅), dated December 2006, and it doesn't list any documents it obsoletes or updates. The RFC number is 4768 ✨.

---

Status of This Memo 📋

okay so this memo is just here to share info with the Internet community 💖 it does NOT set any Internet standard, so don't treat it like one 🙈 and distribution is totally unlimited, so share away 🌸

Copyright Notice 🌈

Copyright (C) The IETF Trust (2006).

Abstract 📝

bestie, the Generic Security Services API (GSS-API) has a naming setup built for name-based authorization 🔐. GSS-API authenticates two named parties to each other 🫶, and those names can live on access control lists (ACLs) so the system can decide who gets in 🚪. but security mechanisms are glowing up and the way implementers want to use GSS-API is changing, so this model needs to be extended for the next version of GSS-API 🔥

the problem is names keep changing. when people move around an org or change their names, the name GSS-API authenticates can change too 😭 a constant identifier would keep ACLs way more stable 💎. also, some mechanisms (like public-key ones) don't have one single name that works everywhere, and others (like Kerberos) can bring group membership or role info along with authentication 👑. this doc explains why these extensions are needed and describes the extensions that are being talked about 🦋

Table of Contents 🗂️

   1. Introduction ....................................................2
   2. Kerberos Naming .................................................3
   3. X.509 Names .....................................................4
   4. Composite Names .................................................5
      4.1. Usage of Name Attributes ...................................6
      4.2. Open Issues ................................................6
      4.3. Handling gss_export_name ...................................7
   5. Credential Extensions ...........................................7
   6. Mechanisms for Export Name ......................................8
   7. Selection of Source Identity ....................................8
   8. Compatibility with GSS-API V2 ...................................9
   9. Security Considerations .........................................9
   10. Acknowledgements ..............................................10
   11. Informative References ........................................10

---

1. Introduction ✨

okay so the Generic Security Services API [2] authenticates two named parties to each other, and that's the whole vibe 🫶. GSS names can be imported in a bunch of formats using the gss_import_name call 📥. there are a few mechanism-independent name formats, including GSS_C_NT_HOSTBASED_SERVICE for services running on an Internet host 🖥️ and GSS_C_NT_USER_NAME for user names 🧑. other mechanism-specific name types exist too 💅. before a name gets used to acquire a mechanism-specific credential or set up a security context, it's been transformed into one of these mechanism-specific name types ✨

GSS-API also has a function called gss_export_name that turns a GSS-API name into a binary blob you can compare directly 🧩. that blob can go on an ACL, and then authorization is basically just comparing the name exported from a newly accepted context with the name on the ACL. simple and iconic 💖

but storing names on ACLs can get messy 😩 because names tend to change over time. if the name has org info in it, like a domain part or what department someone works in, it changes when the person moves around the org 🏢. even if there's no org info, the name still changes when people change their names 💍. and updating ACLs to match name changes is a pain 🙃. the other big problem is that names can get reused. for example, if a Unix user ID is on an ACL, and the account gets deleted and then a brand new user is given that same old ID, the new user could end up with privileges meant for the old user 💀

here's the key idea: the GSS naming model assumes mechanism names can be represented in one single canonical form 🎀. anyone who imports a name needs to be able to get that canonical form back 🔍

some security mechanisms have been proposed where this naming architecture is way too restrictive 🙅‍♀️. sometimes it's not possible to canonicalize every name that gets imported, and other times there just isn't one single canonical name at all 🌀

also, as GSS-API gets used in more complex environments, people want to use attribute certificates [6], Kerberos authorization data [3], or other non-name-based authorization models 🔑. GSS-API needs to be extended so it can support these uses in a mechanism-independent way 🌸

this document digs into the naming problems with two important classes of GSS-API mechanisms 🔬. it also covers the proposed solutions and their open issues. the doc keeps its discussion limited to these solutions and describes the problem they're meant to solve, so they can be judged against it 📏. these solutions are aimed at being included in GSS-API Version 3 ⭐

2. Kerberos Naming 👑

the Kerberos mechanism shows off both the naming stability problem and the authorization extension problem, so it's a perfect example 🦋

the Kerberos Referrals document [4] proposes a new kind of Kerberos name called an enterprise name 🏷️. the idea is that the enterprise name is an alias the user knows for themselves and can use to log in 🔑. the Kerberos Key Distribution Center (KDC) translates this name into a normal Kerberos principal and gives the user tickets for that principal 🎟️. that normal principal is what's used for authorization. so the enterprise name follows the user as they move through the org, even if they end up in parts of the org with different naming policies 🚶‍♀️. the name they type at login stays the same, but the Kerberos principal used to authenticate them to services changes 🔄

here's the catch 🙈: unauthenticated services generally can't map an enterprise name to a principal name. even authenticated services might not be allowed to map any name other than their own. Kerberos also doesn't provide (and doesn't plan to provide) a way to map enterprise names to principals other than authenticating as the enterprise name itself. so any such mapping would be vendor-specific 🏪. because of this, it isn't possible to implement gss_canonicalize_name for enterprise name types 😭. sure, other name types, like traditional principal names, could be used for GSS-API applications instead 🤷‍♀️. but naturally, that loses the benefits of enterprise names 💔

⚠️ bestie, this is the big gotcha: if you go with principal names to dodge the canonicalization problem, you give up the stability that made enterprise names worth it in the first place.

there's another issue with enterprise names too 👀. sometimes it would be really nice to put the enterprise name on the ACL instead of a principal name, since that's more stable 💅. at first glance, you could make this happen by including the enterprise name in the name that gss_export_name exports. but nope, that backfires 💀: the exported name would change whenever the mapping changed, which would invalidate any ACL entries based on the old exported name and totally defeat the purpose of putting the enterprise name in there. in some cases you'd want the exported name based on the enterprise name, and in others based on the principal name. but the current GSS-API doesn't allow that 🚫

and Kerberos naming gets even more complicated 🌀. several vendors have been looking at ways to put group membership information into Kerberos authorization data 👥. it would be really desirable to put these group names on ACLs too. again, GSS-API doesn't currently have any mechanism to use this info 😤

---

more coming in part 2 with X.509 names, composite names and everything after 🫶💖

4.1. Usage of Name Attributes 💖

okay so since attributes are part of GSS-API names, the acceptor can pull up the attributes of both the initiator's and the acceptor's name right from the context 🔍. And those attributes can then be used for authorization, which is literally the whole point 👑

most name attributes probably won't come from someone explicitly adding them to a name 🙈 they'll more likely show up through mechanism-specific credentials. Pieces of those credentials might come from platform or environment-specific names. Mechanism-specific naming and group membership can get turned into name attributes by the mechanism implementation 🧚 The exact way that mapping works will generally need a protocol specification for each mechanism, so it's not one-size-fits-all bestie 💅

4.2. Open Issues 🤔

this section is basically the "stuff we still need to figure out" list 📝 these are parts of the proposal to add attributes to names that have to be explored before the proposal can turn into an actual protocol specification.

first up: are mechanisms expected to be able to carry arbitrary name attributes as part of a context establishment? At first glance it seems like yes, that would be super desirable ✨ but GSS-API exists to set up an authenticated context between two peers. A context authenticates two named entities to each other, and the names of those entities plus the attributes tied to them are what get used for authorization decisions. So if an initiator or acceptor is allowed to assert name attributes and the mechanisms don't validate that those assertions are authentic, then security problems will happen 😭 On the flip side, requiring that name attributes be mechanism-specific, and only carried by mechanisms that understand them and can validate them, would wreck GSS-API's vibe as a generic API 💀 Application authors would be forced to understand mechanism-specific attributes just to make authorization decisions. And if mechanisms aren't required to transport arbitrary attributes, app authors would have to deal with different implementations of the same mechanism that support different sets of name attributes 🥴 One possible fix is to carry a source along with each name attribute. That source could say whether the attribute comes from a mechanism data structure or from the other party in the authentication 🫶

another related question is how name attributes get mapped into their mechanism-specific forms. For example, it would be desirable to map a lot of Kerberos authorization data elements into name attributes 🎀 With the Microsoft PAC (privilege attribute certificate), some applications would want the entire PAC. But in many cases the specific lists of security IDs inside the PAC would be way more directly useful to an application 🙃 So there may not be a good one-to-one mapping between the mechanism-specific elements and the representation that's desirable at the GSS-API layer.

specific name matching rules still need to be developed 🦋 How do names with attributes compare? And what is the effect of a name attribute on a target name in gss_accept_sec_context?

4.3. Handling gss_export_name 🌈

for a lot of mechanisms there'll be an obvious choice for the name exported by gss_export_name 🍓 For Kerberos, for instance, the principal name can keep being used as the exported name. That lets applications that depend on existing GSS-API name-based authorization keep working, which is so important ✨ Still, it's probably desirable to allow GSS-API mechanisms where gss_export_name can't meaningfully be defined. In those cases, the behavior of gss_export_name should probably be to return some error 🙈 Those mechanisms may not work with existing applications and can't conform to the current version of the GSS-API. Rough, but that's the tea ☕

5. Credential Extensions 🧁

an alternative to the name attributes proposal is to extend GSS-API credentials with extensions labeled by OIDs 🏷️ Interfaces would be needed to manipulate these credential extensions, and to retrieve the credential extensions for credentials used to establish a context. Even if name attributes get used, credential extensions might still be useful for other unrelated purposes 💜

it's possible to solve the problems discussed in this document using some credential extension mechanism 🔧 Doing that will have a lot of the same open issues as the composite names proposal. The main advantage of a credential extensions proposal is that it avoids specifying how name attributes interact with name comparison or target names 🙌

the primary advantage of the name attributes proposal over credential extensions is that name attributes seem to fit better into the GSS-API authorization model 👑 Names are already available at all the points where authorization decisions get made. Plus, for many mechanisms, the sort of information carried as name attributes will also be carried as part of the name in the mechanism 🫧

6. Mechanisms for Export Name 🧚

another proposal is to define some GSS-API mechanisms whose only purpose is to have an exportable name form that's actually useful 💫 For example, you might be able to export a name as a local machine user ID with such a mechanism.

this solution works well for name information that can be looked up in a directory 📂 It was unclear whether it would let mechanism-specific name information be extracted from a context. If it could, then this solution would meet a lot of the goals of this document 🎯

one advantage is that it requires few, if any, changes to GSS-API semantics 🌸 But it's not as flexible as the other solutions. Also, it's not clear how to handle mechanisms that don't have a well-defined name to export with this solution 😵‍💫

7. Selection of Source Identity 🦋

today, applications like e-mail clients and Web browsers need connections to multiple targets 📧 For each target, there may be one or more source identities that are appropriate for the connection. Right now each application has to choose the source name to use when acquiring credentials or initiating a security context. The thing is, the rules apps use can be generalized to a large extent 🧠 GSS-API could simplify application design and implementation by taking a bigger role in selecting the source identity to use when connecting to a particular target 🔥

right now, GSS-API credentials represent a single mechanism name. That means that by the time credentials are acquired, they have to act as if one particular identity has been chosen for each mechanism in the credential 😤 All of those identities must correspond to a single mechanism-independent name.

two possibilities have been proposed for getting GSS-API involved in selecting source identities 💅 First, the restriction that a mechanism name must be chosen when credentials are acquired could be relaxed. Some name form would need to be used, but this name form could represent a set of possibilities. The particular identity would then be chosen when context establishment happens. This could involve information received from the target in identity selection 👀

the other possibility is to provide a mechanism to acquire credentials and to provide information about the target when the credentials are acquired 🎁 This would be way less of a change to GSS-API, but it wouldn't let information received from the target choose the identity selection.

with both approaches, information is required to communicate the needs of the application to the GSS-API mechanism 📮 For example, hinting about whether information can be cached, and about the scope of cache entries, is required.

there's one more possibility that can be implemented in GSS-API V2 today: don't bind the credentials to a mechanism name until either the credentials are queried or they're used to set up a context 🕰️ This is undesirable, though, because if an application uses the credential inquiry interface, it'll get different behavior than in cases where that interface isn't used 😬 For this reason, the working group favors an extension to GSS-API V3 💖

8. Compatibility with GSS-API V2 🫶

in order to avoid breaking existing applications or mechanisms, the following backward compatibility requirements need to be met 🛡️

1. Existing APIs must continue to behave as they do in GSS-API V2.
2. GSS-API V2 mechanisms must produce the same exported name forms; composite names cannot change the existing exported name forms.
3. Extensions add new optional behavior.

if GSS-API V3 mechanisms are more permissive than GSS-API V2 mechanisms, then care must be taken so that GSS-API V2 applications don't select these mechanisms 🚨

9. Security Considerations 🔐

okay this part is SERIOUS, bestie 😭 GSS-API sets up a security context between two named parties. The GSS-API names are security assertions that get authenticated by the context establishment process. As such, the GSS naming architecture is critical to the security of GSS-API 💀

right now, GSS-API uses a simplistic naming model for authorization. Names can be compared against a set of names on an access control list. This architecture is relatively simple, and its security properties are well understood ✅ However, it doesn't provide the flexibility and feature set needed for future deployments of GSS-API.

this proposal will significantly increase the complexity of the GSS naming architecture 📈 As the proposal gets fleshed out, we need to consider ways of managing the security exposures created by this increased complexity. Yikes 🙈

one area where the complexity may lead to security problems is composite names with attributes from different sources ⚠️ This may be desirable so that name attributes can carry their own authentication. But the design of any solution needs to make sure that applications can assign appropriate trust to name components. Trust is everything, periodt 💅

10. Acknowledgements 🌷

John Brezak, Paul Leach, and Nicolas Williams all participated in discussions that led to a desire to enhance GSS naming 🙌 Martin Rex provided descriptions of the current naming architecture and pointed out many ways the proposed enhancements would create interoperability problems or increase complexity. Martin also provided excellent information on which aspects of GSS naming have tended to be implemented badly, or haven't met the needs of some customers 🫡

Nicolas Williams helped describe the possible approaches for enhancing naming 💜

11. Informative References 📚

[1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.

[2] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.

[3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.

[4] Zhu, L., "Generating KDC Referrals to Locate Kerberos Realms", Work in Progress, June 2006.

[5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.

[6] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.

Author's Address 🎀

Sam Hartman
MIT

EMail: hartmans-ietf@mit.edu

Full Copyright Statement ✨

Okay, legal bit time, but make it cute 🎀. The IETF Trust owns the copyright on this doc (2006 vibes 🌸). It's bound by the rights, licenses, and restrictions in BCP 78, and apart from what BCP 78 says, the authors keep all their own rights 💜.

The doc and everything in it is handed over "AS IS", no guarantees 🙈. THE CONTRIBUTOR, the organization they represent or are sponsored by (if any), THE INTERNET SOCIETY, THE IETF TRUST, and THE INTERNET ENGINEERING TASK FORCE all say NO to ALL WARRANTIES, express or implied. That includes no promise that using the info won't infringe anyone's rights, and no implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE 💀.

Intellectual Property

Real talk: the IETF takes no position on whether any Intellectual Property Rights (or other rights) someone might claim over the tech in this doc are valid or how wide they are 🦋. It also doesn't say whether licenses for those rights exist or are available, and it hasn't done any independent digging to find out what rights are out there 🔍. If you want the procedures for rights in RFC docs, check BCP 78 and BCP 79 📚.

Copies of IPR disclosures sent to the IETF Secretariat, plus any promises of licenses, or the results of trying to get a general license or permission to use proprietary rights by implementers or users of this spec, can all be found in the IETF online IPR repository at http://www.ietf.org/ipr 💖.

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard 👑. Send that info to the IETF at ietf-ipr@ietf.org ✨.

Acknowledgement

Shoutout to the people keeping the RFC Editor function running: funding for it is currently provided by the Internet Society 🫶🌈.