idnits 2.17.00 (12 Aug 2021) /tmp/idnits45833/draft-lha-gssapi-delegate-policy-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (March 22, 2010) is 4438 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Hornquist Astrand 3 Internet-Draft Apple, Inc. 4 Intended status: Standards Track S. Hartman 5 Expires: September 23, 2010 Painless Security, LLC 6 March 22, 2010 8 GSS-API: Delegate if approved by policy 9 draft-lha-gssapi-delegate-policy-05 11 Abstract 13 Several GSS-API applications work in a multi-tiered architecture, 14 where the server takes advantage of delegated user credentials to act 15 on behalf of the user and contact additional servers. In effect, the 16 server acts as an agent on behalf of the user. Examples include web 17 applications that need to access e-mail or file servers as well as 18 CIFS (Common Internet File System) file servers. However, delegating 19 the user credentials to a party who is not sufficiently trusted is 20 problematic from a security standpoint. Kerberos provides a flag 21 called OK-AS-DELEGATE that allows the administrator of a Kerberos 22 realm to communicate that a particular service is trusted for 23 delegation. This specification adds support for this flag and 24 similar facilities in other authentication mechanisms to GSS-API (RFC 25 2743). 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on September 23, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 Table of Contents 67 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. GSS-API flag, C binding . . . . . . . . . . . . . . . . . . . 5 70 4. GSS-API behavior . . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Kerberos GSS-API behavior . . . . . . . . . . . . . . . . . . 7 72 6. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 76 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 77 Appendix A. Change history . . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Requirements Notation 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. Introduction 88 Several GSS-API applications work in a multi-tiered architecture, 89 where the server takes advantage of delegated user credentials to act 90 on behalf of the user and contact additional servers. In effect, the 91 server acts as an agent on behalf of the user. Examples include web 92 applications that need to access e-mail or file servers as well as 93 CIFS file servers. However, delegating user credentials to a party 94 who is not sufficiently trusted is problematic from a security 95 standpoint. 97 Today, GSS-API [RFC2743] leaves the determination of whether 98 delegation is desired to the client application. An application 99 requests delegation by setting the deleg_req_flag when calling 100 init_sec_context. This requires client applications to know what 101 services should be trusted for delegation. 103 However blindly delegating to services for applications that do not 104 need delegation is problematic. In some cases a central authority is 105 in a better position than the client application to know what 106 services should receive delegation. Some GSS-API mechanisms have a 107 facility to allow an administrator to communicate that a particular 108 service an appropriate target for delegation. For example, a 109 Kerberos [RFC4121] KDC can set the OK-AS-DELEGATE flag in issued 110 tickets as such an indication. It is desirable to expose this 111 knowledge to the GSS-API client so the client can request delegation 112 if and only-if central policy recommends delegation to the given 113 service. 115 This specification adds a new input flag to gss_init_sec_context() to 116 request delegation when approved by central policy. In addition, a 117 constant value to be used in the GSS-API C bindings [RFC2744] is 118 defined. Finally, the behavior for the Kerberos mechanism [RFC4121] 119 is specified. 121 3. GSS-API flag, C binding 123 The gss_init_sec_context API is extended to gain a new input flag 124 deleg_policy_req_flag, and a new output flag, deleg_policy_state 125 BOOLEAN. If the deleg_policy_req_flag is set, then delegation SHOULD 126 be performed if recommended by central policy. When delegation was 127 recommended by the central policy and when delegation was done, the 128 output flag deleg_policy_state will be set. 130 In addition, the C bindings are extended to define the following 131 constant to represent both deleg_policy_req_flag and 132 deleg_policy_state (just like GSS_C_DELEG_FLAG maps to two flags). 134 #define GSS_C_DELEG_POLICY_FLAG 32768 136 4. GSS-API behavior 138 As before, if the deleg_req_flag is set, the GSS-API mechanism will 139 attempt delegation of user credentials. When delegation is 140 successful, deleg_state will return TRUE in both the initiator and 141 acceptor output state (gss_init_sec_context and 142 gss_accept_sec_context respectively). 144 Similarly, if the deleg_policy_req_flag is set, then the GSS-API 145 mechanism will attempt delegation if the mechanism-specific policy 146 recommends to do so. When delegation is allowed and successful, 147 deleg_state will return TRUE in both initiator and acceptor output 148 state. In addition, deleg_policy_state will be set in the initiator 149 output state. 151 If the initiator sets both the deleg_req_flag and 152 deleg_policy_req_flag, delegation will be attempted unconditionally. 153 When delegation was successful, deleg_state will be returned TRUE in 154 the initiator and acceptor. However, the deleg_policy_state will 155 additionally be returned TRUE for the initiator (only) if the 156 mechanism-specific policy recommended delegation. 158 Note that deleg_policy_req_flag and deleg_policy_state apply the 159 initiator only. Their state is never sent over the wire. 161 5. Kerberos GSS-API behavior 163 If the initiator sets the deleg_policy_req_flag (and not 164 deleg_req_flag), the Kerberos GSS-API mechanism MUST only delegate if 165 OK-AS-DELEGATE is set [RFC4120] in the service ticket. Other policy 166 checks MAY be applied. If the initiator sets deleg_req_flag (and not 167 deleg_policy_req_flag) the behavior will be as defined before. If 168 the initiator set both the deleg_req_flag and deleg_policy_req_flag, 169 delegation will be attempted unconditionally. 171 [RFC4120] does not adequately describe the behavior of OK-AS-DELEGATE 172 flag in a cross realm environment. This document clarifies that 173 behavior. If the initiator sets the deleg_policy_req_flag, the GSS- 174 API Kerberos mechanism MUST examine the OK-AS-DELEGATE flag in the 175 service ticket, and it MUST examine all cross realm tickets in the 176 traversal from the user's initial ticket-granting-ticket (TGT) to the 177 service ticket. If any of the intermediate cross realm TGTs do not 178 have the OK-AS-DELEGATE flag set, the mechanism MUST NOT delegate 179 credentials. 181 6. Rationale 183 Strictly speaking, the deleg_req_flag behavior in [RFC2743] could be 184 interpreted the same as deleg_policy_req_flag is described in this 185 document. However in practice the new flag is required because 186 existing applications and user expectations depend upon GSS-API 187 mechanism implementations without the described behavior, i.e. they 188 do not respect OK-AS-DELEGATE. 190 In hind sight, the deleg_req_flag should not have been implemented to 191 mean unconditional delegation. Such promiscuous delegation reduces 192 overall security by unnecessarily exposing user credentials, 193 including to hosts and services that the user have no reason to 194 trust. 196 Today there are Kerberos implementations that do not support the OK- 197 AS-DELEGATE flag in the Kerberos database. If the implementation of 198 the deleg_req_flag were changed to honor the OK-AS-DELEGATE flag, 199 users who deploy new client software, would never achieve credential 200 delegation because the KDC would never issue a ticket with the OK-AS- 201 DELEGATE flag set. Changing the client software behavior in this way 202 would cause a negative user experience for those users. This is 203 compounded by the fact that users often deploy new software without 204 coordinating with site administrators. 206 7. Security Considerations 208 This document introduces a flag that allows the client to get help 209 from the KDC in determining to which servers one should delegate 210 credentials, and the servers to which the client can delegate. 212 The new flag deleg_policy_req_flag is not communicated over the wire, 213 and thus does not present a new opportunity for spoofing or 214 downgrading policy in and of itself. 216 Mechanisms should use a trusted/authenticated means of determining 217 delegation policy, and it must not be spoof-able on the network. 219 Delegating the user's TGT is still too powerful and dangerous. 220 Ideally one would delegate specific service tickets, but this is out 221 of scope of this draft. 223 A client's failure to specify deleg_policy_req_flag can at worst 224 result in NOT delegating credentials. This means that the client 225 does not expand its trust, which is generally safer than the 226 alternative. 228 8. IANA Considerations 230 This document doesnt have any IANA considerations, all registrations 231 are part of draft-ietf-kitten-gssapi-extensions-iana. RFC-EDIOR: 232 please remove this section. 234 9. Acknowledgements 236 Thanks to Disco Vince Giffin, Thomas Maslen, Ken Raeburn, Martin Rex, 237 Alexey Melnikov, Jacques Vidrine, Tom Yu and Hilarie Orman, Shawn 238 Emery for reviewing the document and provided suggestions for 239 improvements. 241 10. Normative References 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, March 1997. 246 [RFC2743] Linn, J., "Generic Security Service Application Program 247 Interface Version 2, Update 1", RFC 2743, January 2000. 249 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 250 C-bindings", RFC 2744, January 2000. 252 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 253 Kerberos Network Authentication Service (V5)", RFC 4120, 254 July 2005. 256 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 257 Version 5 Generic Security Service Application Program 258 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 259 July 2005. 261 Appendix A. Change history 263 RFC-EDITOR: please remove this section. 265 o Version 05: GEN-ART review. SEC-DIR review. Shawn Emery review. 267 o Version 04: Feedback from Thomas Maslen. Clarify chapter 5. 269 o Version 03: Feedback from Thomas Maslen. Remove IANA 270 considerations, Sam will work in the text into IANA draft as part 271 of the initial registry submission. 273 o Version 02: Comments from Disco and Jacques. Use deleg_req_flag 274 instead of GSS_C_DELEG_FLAG for all places that discuesses the 275 flag. 277 o Version 01: Document that GSS_C_DELEG_POLICY_FLAG is a local flag 278 from Martin Rex. Provide rationale as requested by Tom Yu. Ran 279 spell checker over document. 281 o Version 00: Inital draft by Love and cleaned up by Sam. 283 Authors' Addresses 285 Love Hornquist Astrand 286 Apple, Inc. 288 Email: lha@apple.com 290 Sam Hartman 291 Painless Security, LLC 293 Email: hartmans-ietf@mit.edu