1 2 3 4Network Working Group L. Hornquist Astrand 5Internet-Draft Apple, Inc. 6Intended status: Standards Track S. Hartman 7Expires: February 14, 2009 Painless Security, LLC 8 August 13, 2008 9 10 11 GSS-API: Delegate if approved by policy 12 draft-lha-gssapi-delegate-policy-00 13 14Status of this Memo 15 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. 20 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- 24 Drafts. 25 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." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on February 14, 2009. 38 39Copyright Notice 40 41 Copyright (C) The IETF Trust (2008). 42 43 44 45 46 47 48 49 50 51 52 53 54 55Hornquist Astrand & Hartman Expires February 14, 2009 [Page 1] 56 57Internet-Draft GSS-API: Delegate if approved by policy August 2008 58 59 60Abstract 61 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). 74 75 76Table of Contents 77 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 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Hornquist Astrand & Hartman Expires February 14, 2009 [Page 2] 112 113Internet-Draft GSS-API: Delegate if approved by policy August 2008 114 115 1161. Requirements Notation 117 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]. 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Hornquist Astrand & Hartman Expires February 14, 2009 [Page 3] 168 169Internet-Draft GSS-API: Delegate if approved by policy August 2008 170 171 1722. Introduction 173 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 181 security standpoint. 182 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. 198 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] 203 is specified. 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223Hornquist Astrand & Hartman Expires February 14, 2009 [Page 4] 224 225Internet-Draft GSS-API: Delegate if approved by policy August 2008 226 227 2283. GSS-API flag, c binding 229 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. 234 235 236 237 #define GSS_C_DELEG_POLICY_FLAG 32768 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279Hornquist Astrand & Hartman Expires February 14, 2009 [Page 5] 280 281Internet-Draft GSS-API: Delegate if approved by policy August 2008 282 283 2844. GSS-API behavior 285 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. 289 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 294 acceptor. 295 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. 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335Hornquist Astrand & Hartman Expires February 14, 2009 [Page 6] 336 337Internet-Draft GSS-API: Delegate if approved by policy August 2008 338 339 3405. GSS-API behavior 341 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. 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391Hornquist Astrand & Hartman Expires February 14, 2009 [Page 7] 392 393Internet-Draft GSS-API: Delegate if approved by policy August 2008 394 395 3966. Security Considerations 397 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 400 too. 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447Hornquist Astrand & Hartman Expires February 14, 2009 [Page 8] 448 449Internet-Draft GSS-API: Delegate if approved by policy August 2008 450 451 4527. IANA Considerations 453 454 This section needs to be revised to be consistent with the kitten 455 IANA draft. 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503Hornquist Astrand & Hartman Expires February 14, 2009 [Page 9] 504 505Internet-Draft GSS-API: Delegate if approved by policy August 2008 506 507 5088. Normative References 509 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, March 1997. 512 513 [RFC2743] Linn, J., "Generic Security Service Application Program 514 Interface Version 2, Update 1", RFC 2743, January 2000. 515 516 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 517 C-bindings", RFC 2744, January 2000. 518 519 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 520 Kerberos Network Authentication Service (V5)", RFC 4120, 521 July 2005. 522 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, 526 July 2005. 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559Hornquist Astrand & Hartman Expires February 14, 2009 [Page 10] 560 561Internet-Draft GSS-API: Delegate if approved by policy August 2008 562 563 564Authors' Addresses 565 566 Love Hornquist Astrand 567 Apple, Inc. 568 569 Email: lha@apple.com 570 571 572 Sam Hartman 573 Painless Security, LLC 574 575 Email: hartmans-ietf@mit.edu 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615Hornquist Astrand & Hartman Expires February 14, 2009 [Page 11] 616 617Internet-Draft GSS-API: Delegate if approved by policy August 2008 618 619 620Full Copyright Statement 621 622 Copyright (C) The IETF Trust (2008). 623 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. 627 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. 635 636 637Intellectual Property 638 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. 647 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. 654 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 659 ietf-ipr@ietf.org. 660 661 662Acknowledgment 663 664 Funding for the RFC Editor function is provided by the IETF 665 Administrative Support Activity (IASA). 666 667 668 669 670 671Hornquist Astrand & Hartman Expires February 14, 2009 [Page 12] 672 673