4 Network Working Group L. Hornquist Astrand
5 Internet-Draft Apple, Inc.
6 Intended status: Standards Track S. Hartman
7 Expires: February 14, 2009 Painless Security, LLC
11 GSS-API: Delegate if approved by policy
12 draft-lha-gssapi-delegate-policy-00
16 By submitting this Internet-Draft, each author represents that any
17 applicable patent or other IPR claims of which he or she is aware
18 have been or will be disclosed, and any of which he or she becomes
19 aware will be disclosed, in accordance with Section 6 of BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on February 14, 2009.
41 Copyright (C) The IETF Trust (2008).
55 Hornquist Astrand & Hartman Expires February 14, 2009 [Page 1]
57 Internet-Draft GSS-API: Delegate if approved by policy August 2008
62 Several GSS-API applications work in a multi-tiered architecture,
63 where the server takes advantage of delegated user credentials to act
64 on behalf of the user and contact additional servers. In effect, the
65 server acts as an agent on behalf of the user. Examples include web
66 applications that need to access e-mail or file servers as well as
67 CIFs file servers. However, delegating the ability to act as a user
68 to a party who is not sufficiently trusted is problematic from a
69 security standpoint. Kerberos provides a flag called OK-AS-DELEGATE
70 that allows the administrator of a Kerberos realm to communicate that
71 a particular service is trusted for delegation. This specification
72 adds support for this flag and similar facilities in other
73 authentication mechanisms to GSS-API (RFC 2743).
78 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
79 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
80 3. GSS-API flag, c binding . . . . . . . . . . . . . . . . . . . 5
81 4. GSS-API behavior . . . . . . . . . . . . . . . . . . . . . . . 6
82 5. GSS-API behavior . . . . . . . . . . . . . . . . . . . . . . . 7
83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
85 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
87 Intellectual Property and Copyright Statements . . . . . . . . . . 12
111 Hornquist Astrand & Hartman Expires February 14, 2009 [Page 2]
113 Internet-Draft GSS-API: Delegate if approved by policy August 2008
116 1. Requirements Notation
118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
120 document are to be interpreted as described in [RFC2119].
167 Hornquist Astrand & Hartman Expires February 14, 2009 [Page 3]
169 Internet-Draft GSS-API: Delegate if approved by policy August 2008
174 Several GSS-API applications work in a multi-tiered architecture,
175 where the server takes advantage of delegated user credentials to act
176 on behalf of the user and contact additional servers. In effect, the
177 server acts as an agent on behalf of the user. Examples include web
178 applications that need to access e-mail or file servers as well as
179 CIFs file servers. However, delegating the ability to act as a user
180 to a party who is not sufficiently trusted is problematic from a
183 Today, GSS-API [RFC2743] leaves the determination of whether
184 delegation is desired to the client application. If the client sets
185 the deleg_req_flag to gss_init_sec_context then the application
186 requests delegation. This requires client applications to know what
187 services should be trusted for delegation. In some cases, however, a
188 central authority is in a better position to know what services
189 should receive delegation than the client application. Some
190 mechanisms such as Kerberos [RFC4121] have a facility to allow a
191 realm administrator to communicate that a particular service is a
192 valid target for delegation. In Kerberos, the KDC can set the OK-AS-
193 DELEGATE flag in issued tickets. However even in such a case,
194 delegating to services for applications that do not need delegation
195 is problematic. So, it is desirable for a GSS-API client to be able
196 to request delegation if and only-if central policy reccomends
197 delegation to the given target.
199 This specification adds a new input flag to GSS_Init_sec_context to
200 request delegation when approved by central policy. In addition, a
201 constant value to be used in the GSS-API C bindings [RFC2744] is
202 defined. Finally, the behavior for the Kerberos mechanism [RFC4121]
223 Hornquist Astrand & Hartman Expires February 14, 2009 [Page 4]
225 Internet-Draft GSS-API: Delegate if approved by policy August 2008
228 3. GSS-API flag, c binding
230 The GSS_Init_sec_context API is extended to gain a new input flag: if
231 the deleg_policy_req flag is set, then delegation should be performed
232 if recommended by central policy. In addition, the C bindings are
233 extended to define the following constant to represent this new flag.
237 #define GSS_C_DELEG_POLICY_FLAG 32768
279 Hornquist Astrand & Hartman Expires February 14, 2009 [Page 5]
281 Internet-Draft GSS-API: Delegate if approved by policy August 2008
286 As before, if the GSS_C_DELEG_FLAG is set, the GSS-API mechanism
287 tries to delegate. Output ret_flags contains the flag
288 GSS_C_DELEG_FLAG if delegation is successful.
290 If the GSS_C_DELEG_POLICY_FLAG is set, the code delegates only if the
291 mechanism policy allows delegation. If delegation is done, the
292 output flag ret_flags contain both GSS_C_DELEG_FLAG and
293 GSS_C_DELEG_POLICY_FLAG on the initator and GSS_C_DELEG_FLAG on the
296 If both GSS_C_DELEG_FLAG and GSS_C_DELEG_POLICY_FLAG are set, then
297 delegation is attempted. However GSS_C_DELEG_POLICY_FLAG is only set
298 in ret_flags on the initiator if GSS_C_DELEG_POLICY_FLAG would have
299 been sufficient to request delegation.
335 Hornquist Astrand & Hartman Expires February 14, 2009 [Page 6]
337 Internet-Draft GSS-API: Delegate if approved by policy August 2008
342 If the GSS_C_DELEG_POLICY_FLAG is set, the Kerberos GSS-API mechanism
343 will only delegate if ok-as-delegate is set [RFC4120] in the service
344 ticket. Other policy checks MAY be applied.
391 Hornquist Astrand & Hartman Expires February 14, 2009 [Page 7]
393 Internet-Draft GSS-API: Delegate if approved by policy August 2008
396 6. Security Considerations
398 Introduce a flag what allows client to get help from the KDC when to
399 delegate to servers, will limit what servers that client delegate
447 Hornquist Astrand & Hartman Expires February 14, 2009 [Page 8]
449 Internet-Draft GSS-API: Delegate if approved by policy August 2008
452 7. IANA Considerations
454 This section needs to be revised to be consistent with the kitten
503 Hornquist Astrand & Hartman Expires February 14, 2009 [Page 9]
505 Internet-Draft GSS-API: Delegate if approved by policy August 2008
508 8. Normative References
510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
511 Requirement Levels", BCP 14, RFC 2119, March 1997.
513 [RFC2743] Linn, J., "Generic Security Service Application Program
514 Interface Version 2, Update 1", RFC 2743, January 2000.
516 [RFC2744] Wray, J., "Generic Security Service API Version 2 :
517 C-bindings", RFC 2744, January 2000.
519 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
520 Kerberos Network Authentication Service (V5)", RFC 4120,
523 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
524 Version 5 Generic Security Service Application Program
525 Interface (GSS-API) Mechanism: Version 2", RFC 4121,
559 Hornquist Astrand & Hartman Expires February 14, 2009 [Page 10]
561 Internet-Draft GSS-API: Delegate if approved by policy August 2008
566 Love Hornquist Astrand
573 Painless Security, LLC
575 Email: hartmans-ietf@mit.edu
615 Hornquist Astrand & Hartman Expires February 14, 2009 [Page 11]
617 Internet-Draft GSS-API: Delegate if approved by policy August 2008
620 Full Copyright Statement
622 Copyright (C) The IETF Trust (2008).
624 This document is subject to the rights, licenses and restrictions
625 contained in BCP 78, and except as set forth therein, the authors
626 retain all their rights.
628 This document and the information contained herein are provided on an
629 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
630 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
631 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
632 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
633 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
634 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
637 Intellectual Property
639 The IETF takes no position regarding the validity or scope of any
640 Intellectual Property Rights or other rights that might be claimed to
641 pertain to the implementation or use of the technology described in
642 this document or the extent to which any license under such rights
643 might or might not be available; nor does it represent that it has
644 made any independent effort to identify any such rights. Information
645 on the procedures with respect to rights in RFC documents can be
646 found in BCP 78 and BCP 79.
648 Copies of IPR disclosures made to the IETF Secretariat and any
649 assurances of licenses to be made available, or the result of an
650 attempt made to obtain a general license or permission for the use of
651 such proprietary rights by implementers or users of this
652 specification can be obtained from the IETF on-line IPR repository at
653 http://www.ietf.org/ipr.
655 The IETF invites any interested party to bring to its attention any
656 copyrights, patents or patent applications, or other proprietary
657 rights that may cover technology that may be required to implement
658 this standard. Please address the information to the IETF at
664 Funding for the RFC Editor function is provided by the IETF
665 Administrative Support Activity (IASA).
671 Hornquist Astrand & Hartman Expires February 14, 2009 [Page 12]