1 2 3 4Network Working Group L. Hornquist Astrand 5Internet-Draft Apple, Inc 6Intended status: Standards Track August 13, 2008 7Expires: February 14, 2009 8 9 10 Kerberos ticket extensions 11 draft-lha-krb-wg-ticket-extensions-00 12 13Status of this Memo 14 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 24 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 29 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 36 This Internet-Draft will expire on February 14, 2009. 37 38Copyright Notice 39 40 Copyright (C) The IETF Trust (2008). 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55Hornquist Astrand Expires February 14, 2009 [Page 1] 56 57Internet-Draft Kerberos ticket extensions August 2008 58 59 60Abstract 61 62 The Kerberos protocol does not allow ticket extensions. This make it 63 harder to deploy features like referrals and PKCROSS. 64 65 Since the Kerberos protocol did not specified extensibility for the 66 Ticket structure and the current implementations are aware of the 67 contents of tickets, the extension protocol cannot simply extend the 68 Ticket ASN.1 structure. Instead, the extension data needs to be 69 hidden inside the ticket. 70 71 72Table of Contents 73 74 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 75 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. How to request a new assignment for a ticket extension . . . . 6 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 81 Appendix A. Ticket-extensions ASN.1 Module . . . . . . . . . . . 11 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 Intellectual Property and Copyright Statements . . . . . . . . . . 13 84 85 86 87 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 Expires February 14, 2009 [Page 2] 112 113Internet-Draft Kerberos ticket extensions 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 Expires February 14, 2009 [Page 3] 168 169Internet-Draft Kerberos ticket extensions August 2008 170 171 1722. Protocol 173 174 The ticket and enc-part as defined by [RFC4120] is defined as follow: 175 176 177 Ticket ::= [APPLICATION 1] SEQUENCE { 178 tkt-vno [0] INTEGER (5), 179 realm [1] Realm, 180 sname [2] PrincipalName, 181 enc-part [3] EncryptedData -- EncTicketPart 182 } 183 184 EncryptedData ::= SEQUENCE { 185 etype [0] Int32 -- EncryptionType --, 186 kvno [1] UInt32 OPTIONAL, 187 cipher [2] OCTET STRING -- ciphertext 188 } 189 190 191 192 This document uses the special encryption type etype-TBETicket to 193 signal that enc-part.cipher contains the DER-encoded TBETicket 194 structure, instead of an encrypted EncTicketPart. 195 196 197 198 etype-TBETicket INTEGER ::= 4711 -- TBA XXX -- 199 200 krb5int32 ::= INTEGER (-2147483648..2147483647) 201 202 TBETicket ::= SEQUENCE { 203 etype [0] krb5int32 -- EncryptionType --, 204 cipher [1] OCTET STRING 205 extensions [2] SEQUENCE OF TicketExtension OPTIONAL 206 207 } 208 209 TicketExtension ::= SEQUENCE { 210 te-type [0] krb5int32, 211 te-data [1] OCTET STRING 212 te-csum [2] Checksum OPTIONAL 213 } 214 215 216 The content of cipher data and encryption type fields is moved inside 217 TBETicket. 218 219 Negative ticket extensions types (te-type) is private extensions and 220 221 222 223Hornquist Astrand Expires February 14, 2009 [Page 4] 224 225Internet-Draft Kerberos ticket extensions August 2008 226 227 228 MUST only be used for experimentation. 229 230 The te-type field is specificing the type of the content in te-data. 231 Unknown te-types MUST be ignored both by the client and the server. 232 233 The te-csum field is optional for the type, when in use by type type 234 specifed in te-type, the key have to be specifed (usually the session 235 key of the ticket) and the key usage number. 236 237 The KDC MUST only return this extension in the AS-REQ if all other 238 KDCs for the same realm also supports this extension. 239 240 The KDC MUST only return this extension in the TGS-REQ to server the 241 KDC knows supports these extension. This includes both cross realm 242 tickets and service tickets. 243 244 The KDC MAY return extended tickets to servers supporting ticket 245 extensions even if the extended ticket does not contain any 246 extensions. 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 Expires February 14, 2009 [Page 5] 280 281Internet-Draft Kerberos ticket extensions August 2008 282 283 2843. How to request a new assignment for a ticket extension 285 286 When anyone is writing a internet-draft for which a new assignment 287 for te-type is needed/wanted under the ticket extension, then the 288 proper way to do so is as follows: 289 290 291 EXAMPLE-MODULE DEFINITIONS ::= BEGIN 292 293 krb5-ticket-extension-Name ::= INTEGER nnn 294 -- IANA: please assign nnn 295 -- RFC-Editor: replace nnn with IANA-assigned 296 -- number and remove this note 297 END 298 299 300 IANA: Don't do note above, its an example, remove this note RFC- 301 Editor: Don't do note above, its an example, remove this note IANA 302 will assign the number as part of the RFC publication process. 303 304 When reviewing the document, the reviewer should take sure to check 305 that if te-csum is used, the siging key and key usage is specifed. 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 Expires February 14, 2009 [Page 6] 336 337Internet-Draft Kerberos ticket extensions August 2008 338 339 3404. Security Considerations 341 342 This document describes how to extend Kerberos tickets to include 343 additional data in the ticket. This does have a security 344 implications since the extension data in the TBETicket is only 345 optionally signed, not encrypted and is not replay protected. It is 346 up to the consumers of this interface to make sure its used safely. 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 Expires February 14, 2009 [Page 7] 392 393Internet-Draft Kerberos ticket extensions August 2008 394 395 3965. Acknowledgements 397 398 Thanks to Leif Johansson, and Kamada Ken'ichi for reviewing the 399 document and provided suggestions for improvements. 400 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 Expires February 14, 2009 [Page 8] 448 449Internet-Draft Kerberos ticket extensions August 2008 450 451 4526. IANA Considerations 453 454 There are currently no ticket extensions. Future ticket extensions 455 will be published at: 456 457 458 http://www.iana.org/assignments/NNNNNNNN 459 -- IANA: please name registry, proposal: krb5-ticket-extensions 460 461 462 IANA is requested to maintain this registry for future assignments. 463 New assignments can only be made via Specification Required as 464 described in [RFC2434]. 465 466 IANA will assign the number as part of the RFC publication process. 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 Expires February 14, 2009 [Page 9] 504 505Internet-Draft Kerberos ticket extensions August 2008 506 507 5087. 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 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 514 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 515 October 1998. 516 517 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 518 Kerberos Network Authentication Service (V5)", RFC 4120, 519 July 2005. 520 521 522 523 524 525 526 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 Expires February 14, 2009 [Page 10] 560 561Internet-Draft Kerberos ticket extensions August 2008 562 563 564Appendix A. Ticket-extensions ASN.1 Module 565 566 567 568KerberosV5-TicketExtensions { 569 iso(1) identified-organization(3) dod(6) internet(1) 570 security(5) kerberosV5(2) modules(4) ticket-extensions(TBA) 571--- XXX who is the registerar for this number ? 572} DEFINITIONS EXPLICIT TAGS ::= BEGIN 573 574IMPORTS 575 -- as defined in RFC 4120 576 Int32, Checksum 577 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 578 dod(6) internet(1) security(5) kerberosV5(2) 579 modules(4) krb5spec2(2) } 580 581 582etype-TBETicket INTEGER ::= 4711 -- XXX TBA -- 583 584TBETicket ::= SEQUENCE { 585 etype [0] Int32 -- EncryptionType --, 586 cipher [1] OCTET STRING 587 extensions [2] SEQUENCE OF TicketExtension OPTIONAL 588} 589 590TicketExtension ::= SEQUENCE { 591 te-type [0] krb5int32, 592 te-data [1] OCTET STRING 593 te-csum [2] Checksum 594} 595 596END 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615Hornquist Astrand Expires February 14, 2009 [Page 11] 616 617Internet-Draft Kerberos ticket extensions August 2008 618 619 620Author's Address 621 622 Love Hornquist Astrand 623 Apple, Inc 624 Cupertino 625 USA 626 627 Email: lha@apple.com 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671Hornquist Astrand Expires February 14, 2009 [Page 12] 672 673Internet-Draft Kerberos ticket extensions August 2008 674 675 676Full Copyright Statement 677 678 Copyright (C) The IETF Trust (2008). 679 680 This document is subject to the rights, licenses and restrictions 681 contained in BCP 78, and except as set forth therein, the authors 682 retain all their rights. 683 684 This document and the information contained herein are provided on an 685 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 686 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 687 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 688 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 689 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 690 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 691 692 693Intellectual Property 694 695 The IETF takes no position regarding the validity or scope of any 696 Intellectual Property Rights or other rights that might be claimed to 697 pertain to the implementation or use of the technology described in 698 this document or the extent to which any license under such rights 699 might or might not be available; nor does it represent that it has 700 made any independent effort to identify any such rights. Information 701 on the procedures with respect to rights in RFC documents can be 702 found in BCP 78 and BCP 79. 703 704 Copies of IPR disclosures made to the IETF Secretariat and any 705 assurances of licenses to be made available, or the result of an 706 attempt made to obtain a general license or permission for the use of 707 such proprietary rights by implementers or users of this 708 specification can be obtained from the IETF on-line IPR repository at 709 http://www.ietf.org/ipr. 710 711 The IETF invites any interested party to bring to its attention any 712 copyrights, patents or patent applications, or other proprietary 713 rights that may cover technology that may be required to implement 714 this standard. Please address the information to the IETF at 715 ietf-ipr@ietf.org. 716 717 718Acknowledgment 719 720 Funding for the RFC Editor function is provided by the IETF 721 Administrative Support Activity (IASA). 722 723 724 725 726 727Hornquist Astrand Expires February 14, 2009 [Page 13] 728 729