RFC 5896

RFC 5896: Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy 🎀

okay bestie, let me set the scene 💅 this one is from June 2010 and it's a Standards Track doc, so it's the real deal, not just an opinion piece 🫶 it was written by L. Hornquist Astrand (Apple, Inc.) and S. Hartman (Painless Security, LLC) 🦋 and it updates RFC 4120 (the Kerberos spec) ✨ it doesn't obsolete anything, it just adds to what's already there 🌸 the ISSN is 2070-1721 if you ever need to look it up 💜

---

1. Introduction ✨

okay so in a multi-tiered setup, the server borrows the user's delegated credentials so it can act on the user's behalf and reach out to other servers 🧚 basically the server becomes the user's agent 💖 examples include web apps that need to get to e-mail or file servers, like CIFS file servers 📁 BUT, and this is a big but 🙈, handing your credentials to someone who isn't trusted enough is a security nightmare 💀

Right now, [RFC2743] lets the client app decide whether delegation happens at all 🎀 the app asks for it by setting the deleg_req_flag when it calls init_sec_context 💅 which means the client has to already know which services are trusted for delegation 😭

but blindly delegating to services that don't even need it is risky 🥺 sometimes a central authority is in a much better spot to know which services should get delegation 👑 some GSS-API mechanisms have a way for an admin to flag a service as a good delegation target 🌈 for example, a Kerberos [RFC4121] KDC can set the OK-AS-DELEGATE flag in issued tickets to say exactly that ⭐ so the goal is to let the GSS-API client ask for delegation if and only if central policy recommends it to that service 🔥

this spec adds a new input flag to gss_init_sec_context() that asks for delegation when central policy approves 🦋 it also defines a constant for the GSS-API C bindings [RFC2744] 💜 and finally it spells out how the Kerberos mechanism [RFC4121] behaves 🫶

2. Requirements Notation ✨

okay this part is the boring-but-important bit 🙈 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] 🎀 no cap, these words carry real weight 💅

3. GSS-API flag, C binding ✨

the gss_init_sec_context API gets a new input flag, deleg_policy_req_flag, and a new output flag, deleg_policy_state BOOLEAN 🦋 if deleg_policy_req_flag is set, then delegation SHOULD be performed if central policy recommends it 🌸 when central policy recommended delegation AND delegation actually happened, the output flag deleg_policy_state gets set ✨

also the C bindings get a constant that stands for both deleg_policy_req_flag and deleg_policy_state, just like GSS_C_DELEG_FLAG maps to two flags 💜

#define GSS_C_DELEG_POLICY_FLAG 32768

4. GSS-API Behavior ✨

okay so the old deleg_req_flag still works the same way 💅 if it's set, the GSS-API mechanism WILL attempt delegation of user credentials 🔥 when it succeeds, deleg_state comes back TRUE in both the initiator and acceptor output state (that's gss_init_sec_context and gss_accept_sec_context) 👑

now, if deleg_policy_req_flag is set, the mechanism attempts delegation only if the mechanism-specific policy recommends it 🎀 when delegation is allowed and works, deleg_state is TRUE for both initiator and acceptor, and deleg_policy_state gets set in the initiator output state 🦋

if the initiator sets BOTH deleg_req_flag and deleg_policy_req_flag, delegation is attempted unconditionally 💀 when it succeeds, deleg_state is TRUE for the initiator and acceptor 🌸 and if the mechanism-specific policy recommended delegation, deleg_policy_state comes back TRUE for the initiator only 🫶

one more thing 💜 deleg_policy_req_flag and deleg_policy_state only apply to the initiator, and their state is never sent over the wire 🔒

5. Kerberos GSS-API Behavior ✨

if the initiator sets deleg_policy_req_flag (and NOT deleg_req_flag), the Kerberos GSS-API mechanism MUST only delegate if OK-AS-DELEGATE is set [RFC4120] in the service ticket 🎀 other policy checks MAY be applied too 🌈 if the initiator sets deleg_req_flag (and NOT deleg_policy_req_flag), the behavior is whatever [RFC2743] defines 🦋 and if the initiator sets both flags, delegation is attempted unconditionally, same as above 💅

[RFC4120] doesn't fully explain how OK-AS-DELEGATE works across realms, so this doc clarifies it 🙈 if the initiator sets deleg_policy_req_flag, the GSS-API Kerberos mechanism MUST check the OK-AS-DELEGATE flag in the service ticket AND MUST check every cross-realm ticket along the way from the user's initial ticket-granting-ticket (TGT) to the service ticket 🔥 if any of those intermediate cross-realm TGTs don't have OK-AS-DELEGATE set, the mechanism MUST NOT delegate credentials 💀

6. Rationale ✨

technically, the deleg_req_flag behavior in [RFC2743] could be read the same way deleg_policy_req_flag is described here 🤔 BUT in practice the new flag is needed, because existing apps and user expectations depend on GSS-API implementations that don't behave this way, i.e. they don't respect OK-AS-DELEGATE 😭

in hindsight, deleg_req_flag never should have meant unconditional delegation 💅 that kind of promiscuous delegation weakens security by needlessly exposing user credentials, including to hosts and services the user has no reason to trust 🥺

some Kerberos implementations don't support the OK-AS-DELEGATE flag in the Kerberos database yet 🌸 if deleg_req_flag were changed to honor OK-AS-DELEGATE, users with new client software would never get delegation, because the KDC would never issue a ticket with that flag set 💔 that's a rough user experience, and it's made worse because people often deploy new software without talking to their site admins 🙈

7. Security Considerations ✨

⚠️ bestie, this section is SERIOUS. read it carefully 💀

this doc adds a flag that lets the client get help from the KDC in deciding which servers it should delegate credentials to, and which servers the client can delegate to 🔥

the new flag deleg_policy_req_flag is never sent over the wire, so by itself it doesn't open a new chance for spoofing or downgrading policy 🔒

mechanisms SHOULD use a trusted, authenticated way of determining delegation policy, and it MUST NOT be spoofable on the network 🚨

delegating the user's TGT is still way too powerful and dangerous 💀 ideally you'd delegate specific service tickets, but that's out of scope for this document 🙈

if a client doesn't specify deleg_policy_req_flag, the worst case is that it does NOT delegate credentials 🫶 which means the client doesn't expand its trust, and that's generally safer than the alternative 🦋

8. Acknowledgements ✨

huge thanks to Disco Vince Giffin, Thomas Maslen, Ken Raeburn, Martin Rex, Alexey Melnikov, Jacques Vidrine, Tom Yu, Hilarie Orman, and Shawn Emery for reviewing the doc and suggesting improvements 👑🫶

9. Normative References ✨

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

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

[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.

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

[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.

Authors' Addresses ✨

L. Hornquist Astrand (Love Hornquist Astrand) Apple, Inc.

EMail: lha@apple.com

S. Hartman (Sam Hartman) Painless Security, LLC

EMail: hartmans-ietf@mit.edu