1 2Kerberos Working Group Nicolas Williams 3INTERNET-DRAFT Sun Microsystems 4Expires: August 22, 2005 February 21, 2005 5 6 7 8 9 Kerberos Set/Change Password: Version 2 10 <draft-ietf-krb-wg-kerberos-set-passwd-03.txt> 11 12Status of this Memo 13 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 18 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 23 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 28 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 31 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 34 35 This Internet-Draft will expire on August 22, 2005. 36 37Copyright Notice 38 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 41Abstract 42 43 This document specifies an extensible protocol for setting keys and 44 changing the passwords of Kerberos V principals. 45 46Table of Contents 47 48 1 Introduction 49 2 The Protocol 50 2.1 Transports 51 2.2 Protocol Framing 52 2.3 Protocol version negotiation 53 2.3.1 Protocol Major Version Negotiation 54 2.3.2 Protocol Minor Version Negotiation 55 2.4 Use of Kerberos V 56 57N. Williams [Page 1] 58 59 60DRAFT Kerberos Set/Change Password v2 Expires January 2005 61 62 2.5 Use of ASN.1 63 2.6 Internationalization 64 2.6.1 Normalization Forms for UTF-8 Strings 65 2.6.2 Language Negotiation 66 2.7 Protocol Extensibility 67 2.8 Protocol Subsets 68 3 Protocol Elements 69 3.1 PDUs 70 3.2 Operations 71 3.2.1 Null 72 3.2.2 Change Kerberos Password 73 3.2.3 Set Kerberos Password 74 3.2.4 Set Kerberos Keys 75 3.2.5 Generate Kerberos Keys 76 3.2.6 Get New Keys 77 3.2.7 Commit New Keys 78 3.2.8 Get Password Quality Policy 79 3.2.9 Get Principal Aliases 80 3.2.10 Get Realm's Supported Kerberos V Version and Features 81 4 ASN.1 Module 82 6 IANA Considerations 83 7 Security Considerations 84 8 Acknowledgements 85 9 References 86 9.1 Normative References 87 9.2 Informative References 88 10 Authors' Addresses 89 11 Notes to the RFC Editor 90 91Conventions used in this document 92 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 96 971 Introduction 98 99 Up to this point Kerberos V has lacked a single, standard protocol 100 for changing passwords and keys. While several vendor-specific 101 protocols exist for changing Kerberos passwords/keys, none are 102 properly internationalized and all are incomplete in one respect or 103 another and none are sufficiently extensible to cope with new 104 features that may be added to Kerberos V at some future time. 105 106 This document defines a protocol that is somewhat backward-compatible 107 with the "kpasswd" protocol defined in [RFC3244] that uses more or 108 less the same protocol framing. 109 110 This new protocol is designed to be extensible and properly 111 internationalized. 112 1132 The Protocol 114 115 116N. Williams [Page 2] 117 118 119DRAFT Kerberos Set/Change Password v2 Expires January 2005 120 121 The structure of the protocol is quite similar to that of typical RPC 122 protocols. Each transaction consists of a data structure specific to 123 an operation which is then wrapped in a data structure which is 124 general to all operations of the protocol. These data structures are 125 defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they 126 are encoded using the Distinguished Encoding Rules (DER) [X690]. 127 128 All protocol data is wrapped KRB-PRIV messages, or, in some cases, a 129 KRB-ERROR, and framed in a header that is backwards compatible with 130 [RFC3244]. 131 1322.1 Transports 133 134 The service supports only connection-oriented transports, 135 specifically TCP, and MUST accept requests on TCP port 464, the same 136 as in [RFC3244]. 137 1382.2 Protocol Framing 139 140 Requests and responses are exchanged using the same framing as in 141 [RFC3244], but with the following differences: 142 143 - the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1) 144 145 - the 'AP-REQ length' field of the request can be set to 0x0, in 146 which case the 'AP-REQ' field of the request is excluded 147 148 - the 'KRB-PRIV' field of the request and reply is mutually 149 exclusive with the 'AP-REQ' field of the request 150 151 - the 'AP-REP length' field of the reply can be set to 0x0, in 152 which case the 'AP-REP' field of the reply is excluded 153 154 - all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can 155 be or has been accepted by the server 156 157 - any KRB-ERROR messages are framed and sent in the 'AP-REP' field 158 of the reply 159 160 The initial message from the client MUST carry an AP-REQ and the 161 response to any request bearing an AP-REQ MUST carry an AP-REP or 162 MUST be a KRB-ERROR. 163 164 Subsequent messages exchanged on the same TCP connection MAY involve 165 Kerberos V AP exchanges, but generally the client SHOULD NOT initiate 166 a new AP exchange except when it desires to authenticate as a 167 different principal, when the ticket last used for authentication 168 expires or when the server responds with an error indicating that the 169 client must re-authenticate. 170 1712.3 Protocol Version Negotiation 172 173 There are several major versions of this protocol. Version 2 also 174 175N. Williams [Page 3] 176 177 178DRAFT Kerberos Set/Change Password v2 Expires January 2005 179 180 introduces a notion of protocol minor versions for use in negotiating 181 protocol extensions. As of this time only one minor version is 182 defined for major version 2: minor version 0, defined herein. 183 1842.3.1 Protocol Major Version Negotiation 185 186 Version 2 clients that also support other versions, such as 0xff80, 187 as in [RFC3244], SHOULD attempt to use version 2 of the protocol 188 first. 189 190 Servers which do not support version 2 of this protocol typically 191 include their preferred version number in the reply and/or may 192 include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a 193 status code of KRB5_KPASSWD_MALFORMED. 194 195 Note that some [RFC3244] server implementations close the TCP 196 connection without returning any other response. Note also that 197 there is no integrity protection for the major version number in the 198 protocol framing or for any data in a KRB-ERROR. 199 200 As a result change password protocol major version negotiation is 201 subject to downgrade attacks. Therefore major version negotiation is 202 NOT RECOMMENDED. 203 204 Where the server indicates that it does not support version 2, the 205 client MAY, but SHOULD NOT, unless configured to do so, fall back on 206 another major version of this protocol. 207 208 Version 2 servers MAY respond to non-v2 requests using whatever 209 response is appropriate for the versions used by the clients, but if 210 a server does not do this or know how to do this then it MUST respond 211 with an error framed as in section 2.2, using an AP-REP and KRB-PRIV 212 if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and 213 using a ProtocolErrorCode value of unsupported-major-version. 214 215 It is expected that implementations of as yet unspecified future 216 major versions of this protocol will be required to support version 2 217 integrity protected error replies for properly indicating no support 218 for version 2 of the protocl. We also hope that no further major 219 versions of this protocol will be needed. 220 2212.3.2 Protocol Minor Version Negotiation 222 223 Version 2 clients are free to use whatever protocol minor version and 224 message extensions are available to them in their initial messages to 225 version 2 servers, provided that the minor versions (other than 0) 226 have been defined through IETF documents. 227 228 Version 2 servers MUST answer with the highest protocol minor version 229 number supported by the server and the client. 230 231 Version 2 clients MUST use the protocol minor version used in a 232 server's reply for any subsequent messages in the same TCP session. 233 234N. Williams [Page 4] 235 236 237DRAFT Kerberos Set/Change Password v2 Expires January 2005 238 239 240 See section 2.7 for further description of the protocol's 241 extensibility and its relation to protocol minor versions and the 242 negotiation thereof. 243 2442.4 Use of Kerberos V and Key Exchange 245 246 This protocol makes use of messages defined in [RFC1510] and 247 [clarifications]. Specifically, AP-REQ, AP-REP, KRB-ERROR and 248 KRB-PRIV. 249 250 All operations are to be performed by the server on behalf of the 251 client principal. 252 253 Clients SHOULD use "kadmin/setpw" as the principal name of the server 254 for all requests except when changing the client principal's own 255 expired password, for which they should use "kadmin/changepw". The 256 "kadmin/changepw" service exists to allow KDCs to limit principals 257 with expired passwords to getting initial tickets to the password 258 changing service only and only for changing expired passwords. 259 260 Servers MUST limit clients that used the "kadmin/changepw" service 261 principal name to changing the password of the client principal. 262 263 The client MUST request mutual authentication and the client MUST 264 MUST request the use of sequence numbers. 265 266 Clients SHOULD use INITIAL tickets for requests whose target 267 principal is the client's principal. Servers SHOULD force the use of 268 INITIAL tickets for such requests and MAY force the use of INITIAL 269 for all others - see section 3.2. 270 271 Servers MUST specify a sub-session key. 272 273 The encrypted part of KRB-PRIVs MUST be encrypted with the server's 274 sub-session key and key usage 20 (client->server) or 21 275 (server->client). 276 277 After each new AP exchange the client and server MUST destroy the 278 session keys, if any, resulting from the previous AP exchange. 279 2802.5 Use of ASN.1 281 282 This protocol's messages are defined in ASN.1, using only features 283 from [X680]. All ASN.1 types defined herein are to be encoded in 284 DER [X690]. A complete ASN.1 module is given in section 4. 285 286 The DER encoding of the ASN.1 PDUs are exchanged wrapped in a 287 KRB-PRIV as described above and/or as e-data in KRB-ERROR messages. 288 2892.6 Internationalization 290 291 This protocol's request PDU carries an optional field indicating the 292 293N. Williams [Page 5] 294 295 296DRAFT Kerberos Set/Change Password v2 Expires January 2005 297 298 languages spoken by the client user; the client SHOULD send its list 299 of spoken languages to the server (once per-TCP session). 300 301 The server SHOULD localize all strings intended for display to users 302 to a language in common with the languages spoken by the client user. 303 304 Strings for Kerberos principal and realm names used in this protocol 305 are be constrained as per [clarifications]. 306 3072.6.1 Normalization Forms for UTF-8 Strings 308 309 Because Kerberos V [clarifications] restricts principal names, realm 310 names and passwords to IA5String, this protocol uses UTF8String with 311 an extensible constraint to IA5String. 312 313 Future versions of Kerberos may relax this constraint; if so then a 314 minor version of this protocol should relax this constraint 315 accordingly. 316 3172.6.2 Language Negotiation 318 319 The server MUST pick a language from the client's input list or 320 the default language tag (see [RFC3066]) for text in its responses 321 which is meant for the user to read. 322 323 The server SHOULD use a language selection algorithm such that 324 consideration is first given to exact matches between the client's 325 spoken languages and the server's available locales, followed by 326 "fuzzy" matches where only the first sub-tags of the client's 327 language tag list are used for matching against the servers available 328 locales. 329 330 Servers MUST cache the optional language tag lists from prior 331 requests for use with subsequent requests that exclude the language 332 tag list. Clients MAY expect such server behaviour and send the 333 language tag lists only once per-TCP session. Clients SHOULD send 334 the server the language tag list at least once. 335 336 When the server has a message catalog for one of the client's spoken 337 languages the server SHOULD localize any text strings intended for 338 display to users. 339 3402.7 Protocol Extensibility 341 342 The protocol is defined in ASN.1 and uses extensibility markers 343 throughout. As such, the module presented herein can be extended 344 within the framework of [X680]. 345 346 Typed holes are not used in this protocol as it is very simple and 347 does not require the ability to deal with abstract data types defined 348 in different layers. For this reason, the only way to extend this 349 protocol is by extending the ASN.1 module within the framework of the 350 IETF; all future extensions to this protocol have to be defined in 351 352N. Williams [Page 6] 353 354 355DRAFT Kerberos Set/Change Password v2 Expires January 2005 356 357 IETF documents unless otherwise specified in a future IETF revision 358 of this protocol. 359 360 A protocol minor version number is used to negotiate use of 361 extensions. See section 2.3.2 for the minor version negotiation. 362 363 Servers SHOULD ignore unknown additions to the ASN.1 types, in 364 initial requests, where the syntax allows them, except for extensions 365 to the "Op-req" type, which MUST result in an error. 366 367 Servers MUST respond with an error (ProtocolErrorCode value of 368 unsupported-minor-version) to clients that use operations unknown to 369 the server. 370 3712.8 Protocol Subsets 372 373 The structure of the protocol is such that the ASN.1 syntaxes for the 374 various operations supported by the protocol are independent of the 375 each other. Client and server implementations MAY implement subsets 376 of the overall protocol by removing some alternatives to the Op-req, 377 Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4. 378 379 For example, it should be possible to have a password-change only 380 client that cannot set principal's keys - and vice versa. 381 3823 Protocol Elements 383 384 The protocol as defined herein supports the following operations 385 relating to the management of Kerberos principal's passwords or keys: 386 387 [NOTE: New since last version of this I-D.] 388 - get principal's current and preferred string-to-key parameters 389 390 - change password (or enctypes and string-to-key parameters) 391 - set password (administrative) 392 - set new keys 393 - generate new keys 394 - get new, un-committed keys 395 - commit new keys 396 - get password policy name and/or description of principal 397 - list aliases of a principal 398 - list enctypes and version of Kerberos V supported by realm 399 400 The operation for retrieving a list of aliases of a principal is 401 needed where KDCs implement aliasing of principal names and allows 402 clients to properly setup their key databases when principal aliasing 403 is in use. 404 405 Operations such as creation or deletion of principals are outside the 406 scope of this document, and should be performed via other means, such 407 as through directories or other Kerberos administration protocols. 408 409 The individual operations are described in section 3.2. 410 411N. Williams [Page 7] 412 413 414DRAFT Kerberos Set/Change Password v2 Expires January 2005 415 416 4173.1 PDUs 418 419 The types "Request," "Response" and "Error-Response" are the ASN.1 420 module's PDUs. 421 422 The "Request" and "Response" PDUs are always to be sent wrapped in 423 KRB-PRIV messages, except for the "Error-Response" PDU which MUST be 424 sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail, 425 otherwise it MUST be sent wrapped in a KRB-PRIV. 426 427 The ASN.1 syntax for the PDUs is given in section 4. 428 429 Note that the first field of each PDU is the major version of the 430 protocol, defaulted to 2, meaning that it is never included in 431 version 2 exchanges. Similarly, the second field of each PDU is the 432 minor version, defaulted to 0. 433 434 The request, responses and error PDUs consist of an outer structure 435 ("Request," "Response" and "Error-Response") containing fields common 436 to all requests, responses and errors, respectively, and an inner 437 structure for fields that are specific to each operation's 438 requests/responses. The inner structure is optional in the case of 439 the Error-Response PDU and need not be included when generic errors 440 occur for which there is a suitable ProtocolErrorCode. 441 442 Specifically, the outer Request structure has a field for passing a 443 client user's spoken (read) languages to the server. It also has two 444 optional fields for identifying the requested operation's target 445 principal's name and realm (if not sent then the server MUST use the 446 client's principal name and realm as the target). A boolean field 447 for indicating whether or not the request should be dry-run is also 448 included; dry-runs can be used to test server policies, and servers 449 MUST NOT modify any principals when processing dry-run requests. 450 451 The Response and Error PDUs' outer structures include a field 452 indicating the language that the server has chosen for localization 453 of text intended to be displayed to users; this field is defaulted to 454 "i-default". This language tag applies to all UTF8 strings in the 455 inner structure (Op-rep and Op-err) that are meant to be displayed to 456 users. 457 458 The protocol error codes are: 459 460 - proto-generic-error 461 462 An operation-specific error ocurred, see the inner Op-error. 463 464 - proto-format-error 465 - proto-unsupported-major-version 466 - proto-unsupported-minor-version 467 - proto-unsupported-operation 468 469 470N. Williams [Page 8] 471 472 473DRAFT Kerberos Set/Change Password v2 Expires January 2005 474 475 - proto-wrong-service-principal 476 477 Use kadmin/setpw for the server's principal name. 478 479 - proto-re-authentication-required 480 481 The server demands that the client re-authenticate through a new 482 AP exchange. 483 484 - proto-initial-ticket-required 485 486 Use of an INITIAL ticket is required for the requested 487 operation. 488 489 - proto-client-and-target-realm-mismatch 490 491 The server requires that the client's principal name and the 492 target principal of the operation share the same realm name. 493 494 - proto-target-principal-unknown 495 - proto-authorization-failed 496 4973.2 Operations 498 499 This section describes the semantics of each operation request and 500 response defined in the ASN.1 module in section 4. 501 5023.2.1 Null 503 504 NAME 505 506 null - Null or "ping" operation 507 508 DESCRIPTION 509 510 The null request is intended for use with TCP; its purpose is 511 similar to RPC null procedures and is akin to a "ping" operation. 512 513 ERRORS 514 515 None. 516 5173.2.2 Change Kerberos Password 518 519 NAME 520 521 change-pw - Change password operation 522 523 SYNOPSIS 524 525 Req-change-pw(old-pw, [languages], [new-pw], 526 [commit], [etypes]) -> 527 Rep-change-pw([info-text], [new-pw], [etypes]) | 528 529N. Williams [Page 9] 530 531 532DRAFT Kerberos Set/Change Password v2 Expires January 2005 533 534 Err-change-pw([help-text], error code, [error info]) 535 536 DESCRIPTION 537 538 Change a principal's password. 539 540 The change password request has one required, three optional and 541 one defaulted arguments: "old-pw" (required), "languages," 542 "new-pw", "commit" (defaults to "TRUE") and "etypes", 543 corresponding to the target principal's old password, its 544 preferred languages, its new password, a boolean indicating 545 whether or not to make the new long-term key available for 546 immediate use, and the desired enctypes for the new long-term 547 keys. 548 549 The server MUST validate the old password and MUST check the 550 quality of the new password, if sent, according the password 551 quality policy associated with the target principal. 552 553 If the old and new passwords in the request are the same strings, 554 and the principal is not currently required to change its 555 password, then the server MAY permit the password change as way to 556 change a principal's enctypes and string-to-key parameters. This 557 feature provides a way to, for example, add enctypes to a 558 principals' password-derived long-term keys without forcing a 559 password change following an upgrade to the KDC that adds support 560 for new enctypes. 561 562 A client MAY request that the server generate a new password by 563 excluding the new password from its request, in which case the 564 server MUST either generate a new password or respond with an 565 error indicating that it does not support this feature. 566 567 Server-generated passwords MUST meet the target principal's 568 password quality policy. It is RECOMMENDED that server-generated 569 passwords be user-friendly, that is, memorable and that the target 570 principal's preferred languages be taken into account by the 571 password generation alogrithm used by the server. 572 573 Uncommitted password changes are commited using the commit-keys 574 operation. 575 576 RETURN 577 578 Upon successful password changes the server responds with a 579 Rep-change-pw. The fields of Rep-change-pw are all optional and 580 include: 581 582 - 'info-text' which the server can use to send a message to the 583 user such as "Your new password will expire in 90 days," for 584 example. 585 586 - 'new-pw' which the server MUST include if the client 587 588N. Williams [Page 10] 589 590 591DRAFT Kerberos Set/Change Password v2 Expires January 2005 592 593 requested that the server generate a new password; generated 594 passwords MUST pass the target principal's password quality 595 policy. 596 597 - 'etypes' which the server MAY include to indicate which types 598 of long-term keys it created for the target principal and 599 which the server MUST include if the client specified a set 600 of enctypes in its request. 601 602 ERRORS 603 604 The server may respond to change password requests with protocol 605 or operation errors. See section 3.1 for a description of 606 protocol error codes. 607 608 All operation errors include an optional 'help-text' field by 609 which the server can describe the error in a human-readable, 610 localizaed string. 611 612 Change password error codes include: 613 614 - generic-error 615 616 - old-pw-incorrect 617 618 - wont-generate-new-pw 619 620 The server will not generate a new password for this 621 principal or does not support password generation in general. 622 623 - new-pw-rejected-generic 624 625 The client's proposed new password failed the target 626 principal's password quality policy. 627 628 The server MUST include a description of the password quality 629 policy or aspect of it that the client's proposed new 630 password failed to meet. 631 632 The server MAY generate and send a new password that the 633 client can then use as a new password and which is guaranteed 634 to pass the target principal's current password quality 635 policy. 636 637 The server MAY include a set of policy error code hints. 638 639 - etype-not-supported 640 641 The client requested an enctype that the KDC does not 642 support. 643 6443.2.3 Set Kerberos Password 645 646 647N. Williams [Page 11] 648 649 650DRAFT Kerberos Set/Change Password v2 Expires January 2005 651 652 NAME 653 654 set-pw - Set password operation 655 656 SYNOPSIS 657 658 Req-set-pw([languages], [new-pw], [commit], [etypes]) -> 659 Rep-set-pw([info-text], [new-pw], [etypes]) | 660 Err-set-pw([help-text], error code, [error info]) 661 662 DESCRIPTION 663 664 Administratively set a principal's password. 665 666 The set password request has three optional and one defaulted 667 arguments: "languages", "new-pw," "commit" (defaulted to "TRUE") 668 and "etypes", corresponding to the target principal's preferred 669 languages, new password, a boolean indicating whether or not to 670 make the new long-term key available for immediate use, and the 671 desired enctypes for the new long-term keys. 672 673 The server MUST check the quality of the new password, if sent, 674 according the password quality policy associated with the target 675 principal. 676 677 The server SHOULD require that the client use the change-pw 678 operation instead of set-pw when the client principal and the 679 target principal are the same. 680 681 A client MAY request that the server generate a new password by 682 excluding the new password from its request, in which case the 683 server MUST either generate a new password or respond with an 684 error indicating that it does not support this feature. 685 686 Server-generated passwords MUST meet the target principal's 687 password quality policy. It is RECOMMENDED that server-generated 688 passwords be user-friendly, that is, memorable and that the target 689 principal's preferred languages be taken into account by the 690 password generation alogrithm used by the server. 691 692 RETURN 693 694 Upon successfully setting a password the server responds with a 695 Rep-set-pw. The fields of Rep-set-pw are all optional and 696 include: 697 698 - 'info-text' which the server can use to send a message to the 699 user such as "Your new password will expire in 90 days," for 700 example. 701 702 - 'new-pw' which the server MUST include if the client 703 requested that the server generate a new password; generated 704 passwords MUST pass the target principal's password quality 705 706N. Williams [Page 12] 707 708 709DRAFT Kerberos Set/Change Password v2 Expires January 2005 710 711 policy. 712 713 - 'etypes' which the server MAY include to indicate which types 714 of long-term keys it created for the target principal and 715 which the server MUST include if the client specified a set 716 of enctypes in its request. 717 718 ERRORS 719 720 The server may respond to set password requests with protocol or 721 operation errors. See section XYZ for a description of protocol 722 error codes. 723 724 All operation errors include an optional 'help-text' field by 725 which the server can describe the error in a human-readable, 726 localizaed string. 727 728 Set password error codes include: 729 730 - generic-error 731 732 - use-change-pw 733 734 The server demands that the client use the change-pw 735 operation for the target principal of the set-pw request. 736 737 - wont-generate-new-pw 738 739 The server will not generate a new password for this 740 principal or does not support password generation in general. 741 742 - new-pw-rejected-generic 743 744 The client's proposed new password failed the target 745 principal's password quality policy. 746 747 The server MUST include a description of the password quality 748 policy or aspect of it that the client's proposed new 749 password failed to meet. 750 751 The server MAY generate and send a new password that the 752 client can then use as a new password and which is guaranteed 753 to pass the target principal's current password quality 754 policy. 755 756 The server MAY include a set of policy error code hints. 757 758 - etype-not-supported 759 760 The client requested an enctype that the KDC does not 761 support. 762 7633.2.4 Set Kerberos Keys 764 765N. Williams [Page 13] 766 767 768DRAFT Kerberos Set/Change Password v2 Expires January 2005 769 770 771 NAME 772 773 set-keys 774 775 SYNOPSIS 776 777 Req-set-keys(new-keys, commit?, [isupport]) -> 778 Rep-set-keys([info-text], kvno, aliases, [isupport]) 779 780 DESCRIPTION 781 782 The set-keys request consists of two required fields and one 783 optional field: "new-keys", "commit" (a boolean field - see below) 784 and "isupport", an optional field for indicating to the KDC what 785 Kerberos V features are supported by the target principal. 786 787 When "commit" is true the KDC makes the new keys available for 788 issueing tickets encrypted in them immediately. Otherwise the 789 client MUST follow up with a commit-keys request to make the keys 790 available. This feature is useful for changing keys shared by 791 multiple hosts, in clustered services, for example, in an atomic 792 manner; see section 3.2.6 and 3.2.7. 793 794 If a principal has keys are awaiting commitment when a new 795 set-keys request for that principal s made then the KDC MUST 796 overwrite the deferred keys. 797 798 RETURN 799 800 For successful set-keys operations the server returns: 801 802 - Informational text, optional. 803 804 - The new kvno for the target principal. 805 806 - A list of aliases of the target principal known to the KDC 807 (optional). 808 809 - The set of Kerberos V features supported by the KDC 810 (optional). 811 812 ERRORS 813 814 The server may respond with the following errors: 815 816 - generic 817 - deferred-commit-no-support 818 - etype-no-support 819 8203.2.5 Generate Kerberos Keys 821 822 NAME 823 824N. Williams [Page 14] 825 826 827DRAFT Kerberos Set/Change Password v2 Expires January 2005 828 829 830 gen-keys 831 832 SYNOPSIS 833 834 Req-gen-keys(etypes, [entropy], commit?, [isupport]) -> 835 Rep-set-keys([info-text], key, kvno, aliases, [isupport]) 836 837 DESCRIPTION 838 839 The gen-keys is similar to the set-keys request (see section 840 3.2.4) but differs in that the server generates keys of 841 client-requested enctypes, rather than the client providing 842 specific keys. 843 844 The gen-keys request consists of two required fields and two 845 optional fields: "etypes" (the enctypes of the new keys), 846 "entropy", "commit" and "isupport" (see section 3.2.4). 847 848 If a principal has keys are awaiting commitment when a new 849 set-keys request for that principal s made then the KDC MUST 850 overwrite the deferred keys. 851 852 RETURN 853 854 For successful set-keys operations the server returns: 855 856 - Informational text, optional. 857 858 - The new kvno for the target principal. 859 860 - The new key (only one is needed). 861 862 - A list of aliases of the target principal known to the KDC 863 (optional). 864 865 - The set of Kerberos V features supported by the KDC 866 (optional). 867 868 ERRORS 869 870 The server may respond with the following errors: 871 872 - generic 873 - deferred-commit-no-support 874 - etype-no-support 875 8763.2.6 Get New Keys 877 878 NAME 879 880 get-keys 881 882 883N. Williams [Page 15] 884 885 886DRAFT Kerberos Set/Change Password v2 Expires January 2005 887 888 SYNOPSIS 889 890 Req-get-keys(kvno) -> 891 Rep-get-keys([info-text], keys, aliases, [isupport]) | 892 Err-get-keys([help-text], error code, [error info]) 893 894 DESCRIPTION 895 896 This request allows a client to get the keys set or generated in a 897 previous set-keys or gen-keys request with deferred commitment.. 898 899 RETURN 900 901 If the target principal and kvno correspond to uncommitted keys 902 the server MUST respond with the actual keys that would be set by 903 a subsequent commit-keys request. Otherwise the server MUST 904 respond with an error (meaning that this operation cannot be used 905 to extract keys from the KDC that may be in use). 906 907 ERRORS 908 909 - generic 910 - kvno-committed 911 - no-such-kvno 912 9133.2.7 Commit New Keys 914 915 NAME 916 917 commit-keys 918 919 SYNOPSIS 920 921 Req-commit-keys(kvno) -> 922 Rep-commit-keys() | 923 Err-commit-keys([help-text], error code, [error info]) 924 925 DESCRIPTION 926 927 The commit-keys operation allows a client to bring a principal's 928 new keys into use at the KDC. 929 930 Clients should make a commit-keys request corresponding to a 931 deferred commitment set-keys/gen-keys operation as soon as the 932 local key database for the target principal is updated. 933 934 The target principal name and the kvno MUST match those from a 935 prior set-keys or gen-keys operation. 936 937 Servers MAY expire delayed key commitments at will. Servers 938 SHOULD expire uncommitted new keys after a reasonable amount of 939 time (600 seconds is RECOMMENDED). 940 941 942N. Williams [Page 16] 943 944 945DRAFT Kerberos Set/Change Password v2 Expires January 2005 946 947 Servers MUST respond to new set-keys requests for principals with 948 pending, uncommitted new keys by expiring the uncommitted new keys 949 and proceeding as if there had been no expired new keys. 950 951 ERRORS 952 953 - generic 954 - op-kvno-expired 955 - op-kvno-unknown 956 - new-keys-conflict (A set-keys or gen-keys request succeeded 957 subsequent to the request that matches this 958 {principal, kvno} tuple.) 959 9603.2.8 Get Password Quality Policy 961 962 NAME 963 964 get-pw-policy 965 966 SYNOPSIS 967 968 Req-get-pw-policy() -> 969 Rep-get-pw-policy([policy name], [policy description]) 970 971 DESCRIPTION 972 973 Returns a description of the target principal's associated 974 password quality policy, if any, as a list of localized 975 UTF8String values. 976 977 Clients can use this operation in conjunction with the change-pw 978 operation to obtain text that can be displayed to the user before 979 the user actually enters a new password. 980 981 It is common for sites to set policies with respect to password 982 quality. It is beyond the scope of this document to describe such 983 policies. Management of password quality policies' actual content 984 is also beyond the scope of this protocol. 985 986 ERRORS 987 988 No operation errors are defined. 989 990 9913.2.9 Get Principal Aliases 992 993 NAME 994 995 get-print-aliases 996 997 SYNOPSIS 998 999 Req-get-princ-aliases() -> 1000 1001N. Williams [Page 17] 1002 1003 1004DRAFT Kerberos Set/Change Password v2 Expires January 2005 1005 1006 Rep-get-princ-aliases(aliases) 1007 1008 DESCRIPTION 1009 1010 Returns a list of aliases of the target principal. 1011 1012 ERRORS 1013 1014 No operation-specific errors. 1015 10163.2.10 Get Realm's Supported Kerberos V Version and Features 1017 1018 NAME 1019 1020 get-realm-krb5-support 1021 1022 SYNOPSIS 1023 1024 Req-get-realm-krb5-support() -> 1025 Rep-get-realm-krb5-support(isupport) 1026 1027 DESCRIPTION 1028 1029 Returns set of Kerberos V features support by the target 1030 principal's realm's KDCs. 1031 1032 ERRORS 1033 1034 No operation-specific errors. 1035 10363.2.11 Retrieve Principal's S2K Params and Preferred Params 1037 1038 NAME 1039 1040 get-s2kparams 1041 1042 SYNOPSIS 1043 1044 Req-get-s2kparams() -> 1045 Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams]) 1046 1047 DESCRIPTION 1048 1049 Returns the string2key parameters for the principal's current 1050 password-derived long-term keys, if any, and the parameters that 1051 the realm would prefer, if they differ from the former. 1052 1053 This operation is intended for use with the change-pw() operation. 1054 When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if 1055 the principal's long-term secret keys' string2key parameters (and 1056 enctype list) should be changed and, if so, change them. 1057 1058 If the 'princ-s2kparams' return value is missing then the 1059 1060N. Williams [Page 18] 1061 1062 1063DRAFT Kerberos Set/Change Password v2 Expires January 2005 1064 1065 principal does not have a password-derived long-term key. 1066 1067 The 'preferred-s2kparams' MUST be excluded if the principal's 1068 string2key parameters satisfy the realm's policy. 1069 1070 ERRORS 1071 1072 No operation-specific errors. 1073 10743.3 Principal Aliases 1075 1076 Applications that use Kerberos often have to derive acceptor 1077 principal names from hostnames entered by users. Such hostnames may 1078 be aliases, they may be fully qualified, partially qualified or not 1079 qualified at all. Some implementations have resorted to deriving 1080 principal names from such hostnames by utilizing the names services 1081 to canonicalize the hostname first; such practices are not secure 1082 unless the name service are secure, which often aren't. 1083 1084 One method for securely deriving principal names from hostnames is to 1085 alias principals at the KDC such that the KDC will issue tickets for 1086 principal names which are aliases of others. It is helpful for 1087 principals to know what are their aliases as known by the KDCs. 1088 1089 Note that changing a principal's aliases is out of scope for this 1090 protocol. 1091 10923.4 Kerberos V Feature Negotiation 1093 1094 Principals and realms' KDCs may need to know about additional 1095 Kerberos V features and extensions that they each support. Several 1096 operations (see above) provide a way for clients and servers to 1097 exchange such infomration, in the form of lists of types supported 1098 for the various typed holes used in Kerberos V. 1099 11004 ASN.1 Module 1101 1102 DEFINITIONS EXPLICIT TAGS ::= BEGIN 1103 -- 1104 -- Note: EXPLICIT tagging is in use by default throughout this 1105 -- module. 1106 1107 -- From [clarifications] with modifications 1108 PrincipalName ::= SEQUENCE { 1109 name-string [1] SEQUENCE OF UTF8String (IA5String, ...) 1110 } 1111 Realm ::= UTF8String (IA5String, ...) 1112 Salt ::= UTF8String (IA5String, ...) 1113 Password ::= UTF8String (IA5String, ...) 1114 1115 -- NOTE WELL: Principal and realm names MUST be constrained by the 1116 -- specification of the version of Kerberos V used by the 1117 -- client. 1118 1119N. Williams [Page 19] 1120 1121 1122DRAFT Kerberos Set/Change Password v2 Expires January 2005 1123 1124 -- 1125 -- [Perhaps PrincipalName should be a SEQUENCE of an optional name 1126 -- type and a UTF8String, for simplicity.] 1127 1128 -- From [clarifications] 1129 Int32 ::= INTEGER (-2147483648..2147483647) 1130 UInt32 ::= INTEGER (0..4294967295) 1131 1132 -- Based on [clarifications] 1133 Etype ::= Int32 1134 Etype-Info-Entry ::= SEQUENCE { 1135 etype [0] Etype, 1136 salt [1] Salt OPTIONAL, 1137 s2kparams [2] OCTET STRING OPTIONAL, 1138 ... 1139 } 1140 Key ::= SEQUENCE { 1141 enc-type [0] Etype, -- from Kerberos 1142 key [1] OCTET STRING, 1143 ... 1144 } 1145 1146 Language-Tag ::= UTF8String -- Constrained by [RFC3066] 1147 1148 -- Empty, extensible SEQUENCEs are legal ASN.1 1149 Extensible-NULL ::= SEQUENCE { 1150 ... 1151 } 1152 1153 -- Kerberos clients negotiate some parameters relating to their peers 1154 -- indirectly through the KDC. Today this is true of ticket session 1155 -- key enctypes, but in the future this indirect negotiation may also 1156 -- occur with respect to the minor version of Kerberos V to be used 1157 -- between clients and servers. Additionally, KDCs may need to know 1158 -- what authorization-data types are supported by service principals, 1159 -- both, for compatibility with legacy software and for optimization. 1160 -- 1161 -- Thesefore it is important for KDCs to know what features of 1162 -- Kerberos V each service principal supports. 1163 -- 1164 -- In version 2.0 of this protocol the clients and servers may notify 1165 -- each other of their support for: 1166 -- 1167 -- - enctypes 1168 -- - authorization data types 1169 -- - transited encoding data types 1170 -- 1171 -- All authorization-data types defined in [clarifications] are 1172 -- assumed to be supported if the minor version is 1 and do not need 1173 -- to be included in the ad-type list. 1174 -- 1175 -- Int32 is used for enctype and transited encoding data type 1176 -- identifiers. 1177 1178N. Williams [Page 20] 1179 1180 1181DRAFT Kerberos Set/Change Password v2 Expires January 2005 1182 1183 -- 1184 -- An extensible CHOICE of Int32 is used for authorization data 1185 -- types. 1186 1187 KerberosV-TR-ID ::= Int32 1188 1189 KerberosV-AD-ID ::= CHOICE { 1190 ad-int [0] Int32, 1191 ... 1192 } 1193 1194 KerberosVSupportNego ::= SEQUENCE { 1195 enc-types [0] SEQUENCE OF Etype, 1196 ad-types [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL, 1197 -- authorization data types 1198 tr-enc-types [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL, 1199 -- transited encoding types 1200 ... 1201 } 1202 1203 Request ::= [APPLICATION 0] SEQUENCE { 1204 pvno-minor [0] INTEGER DEFAULT 0, 1205 languages [1] SEQUENCE OF Language-Tag OPTIONAL, 1206 -- Should be defaulted to the SEQUENCE of "i-default" 1207 targ-name [2] PrincipalName OPTIONAL, 1208 targ-realm [3] Realm OPTIONAL, 1209 -- If targ-name/realm are missing then the request 1210 -- applies to the principal of the client 1211 dry-run [4] BOOLEAN DEFAULT FALSE, 1212 operation [5] Op-req, 1213 ... 1214 } 1215 1216 Response ::= [APPLICATION 1] SEQUENCE { 1217 pvno-minor [0] INTEGER DEFAULT 0, 1218 language [1] Language-Tag DEFAULT "i-default", 1219 result [2] Op-rep, 1220 ... 1221 } 1222 1223 Error-Response ::= [APPLICATION 2] SEQUENCE { 1224 pvno-minor [0] INTEGER DEFAULT 0, 1225 language [1] Language-Tag DEFAULT "i-default", 1226 error-code [2] ProtocolErrorCode, 1227 help-text [3] UTF8String OPTIONAL, 1228 op-error [4] Op-err OPTIONAL, 1229 ... 1230 } 1231 1232 Op-req ::= CHOICE { 1233 null [0] Req-null, 1234 change-pw [1] Req-change-pw, 1235 set-pw [2] Req-set-pw, 1236 1237N. Williams [Page 21] 1238 1239 1240DRAFT Kerberos Set/Change Password v2 Expires January 2005 1241 1242 set-keys [3] Req-set-keys, 1243 gen-keys [4] Req-gen-keys, 1244 get-keys [5] Req-get-keys, 1245 commit-keys [6] Req-commit-keys, 1246 get-pw-policy [7] Req-get-pw-policy, 1247 get-princ-aliases [8] Req-get-princ-aliases, 1248 get-realm-krb5-support [9] Req-get-realm-krb5-support, 1249 get-s2kparams [10] Req-get-s2kparams, 1250 ... 1251 } 1252 1253 Op-rep ::= CHOICE { 1254 null [0] Rep-null, 1255 change-pw [1] Rep-change-pw, 1256 set-pw [2] Rep-set-pw, 1257 set-keys [3] Rep-set-keys, 1258 gen-keys [4] Req-gen-keys, 1259 get-keys [5] Req-get-keys, 1260 commit-keys [6] Rep-commit-keys, 1261 get-pw-policy [7] Rep-get-pw-policy, 1262 get-princ-aliases [8] Rep-get-princ-aliases, 1263 get-realm-krb5-support [9] Rep-get-realm-krb5-support, 1264 get-s2kparams [10] Rep-get-s2kparams, 1265 ... 1266 } 1267 1268 Op-err ::= CHOICE { 1269 null [0] Err-null, 1270 change-pw [1] Err-change-pw, 1271 set-pw [2] Err-set-pw, 1272 set-keys [3] Err-set-keys, 1273 gen-keys [4] Err-gen-keys, 1274 get-keys [5] Err-get-keys, 1275 commit-keys [6] Err-commit-keys, 1276 get-pw-policy [7] Err-get-pw-policy, 1277 get-princ-aliases [8] Err-get-princ-aliases, 1278 get-realm-krb5-support [9] Err-get-realm-krb5-support, 1279 get-s2kparams [10] Err-get-s2kparams, 1280 ... 1281 } 1282 1283 ProtocolErrorCode ::= ENUM { 1284 proto-format-error, 1285 proto-unsupported-major-version, 1286 proto-unsupported-minor-version, 1287 proto-unsupported-operation, -- Request CHOICE tag unknown 1288 proto-generic-see-op-error, -- See Op-error 1289 proto-wrong-service-principal, -- Use kadmin/setpw 1290 proto-re-authentication-required, 1291 proto-initial-ticket-required, 1292 proto-client-and-target-realm-mismatch, 1293 proto-target-principal-unknown, 1294 proto-authorization-failed, 1295 1296N. Williams [Page 22] 1297 1298 1299DRAFT Kerberos Set/Change Password v2 Expires January 2005 1300 1301 proto-dry-run-not-permitted, 1302 ... 1303 } 1304 1305 -- These codes are hints for clients, primarily for when they are 1306 -- used for changing the passwords of automated principals; error 1307 -- replies carry password quality policy help text that is more 1308 -- appropriate for clients to display to users. 1309 PW-Quality-Codes ::= ENUM { 1310 pwq-generic, 1311 pwq-too-soon, 1312 pwq-repeated, 1313 pwq-too-short, 1314 pwq-dictionary-words, 1315 pwq-prohibited-codepoints, 1316 pwq-need-more-char-classes, 1317 ... 1318 } 1319 1320 -- 1321 -- Requests and responses 1322 -- 1323 1324 -- NULL request, much like ONC RPC's NULL procedure - NOT extensible 1325 Req-null ::= NULL 1326 1327 Rep-null ::= NULL 1328 1329 Err-null ::= NULL 1330 1331 -- Change password 1332 Req-change-pw ::= SEQUENCE { 1333 old-pw [0] Password, 1334 new-pw [1] Password OPTIONAL, 1335 commit [2] BOOLEAN DEFAULT TRUE, 1336 etypes [3] SEQUENCE (1..) OF Etype OPTIONAL, 1337 ... 1338 } 1339 1340 Rep-change-pw ::= SEQUENCE { 1341 info-text [0] UTF8String OPTIONAL, 1342 new-pw [1] Password OPTIONAL, 1343 -- generated by the server if present 1344 -- (and requested by the client) 1345 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 1346 ... 1347 } 1348 1349 Err-change-pw ::= SEQUENCE { 1350 help-text [0] UTF8String OPTIONAL, 1351 error [1] CHOICE { 1352 op-generic-error [0] Extensible-NULL, 1353 op-old-pw-incorrect [1] Extensible-NULL, 1354 1355N. Williams [Page 23] 1356 1357 1358DRAFT Kerberos Set/Change Password v2 Expires January 2005 1359 1360 op-wont-generate-new-pw [2] Extensible-NULL, 1361 op-new-pw-rejected-generic [3] SEQUENCE { 1362 policy [1] SEQUENCE OF UTF8String, 1363 suggested-pw [2] Password OPTIONAL, 1364 policy-codes [3] SET OF PW-Quality-Codes 1365 OPTIONAL, 1366 ... 1367 } 1368 op-etype-not-supported [4] SEQUENCE { 1369 supported-etypes [1] SEQUENCE OF Etype, 1370 ... 1371 }, 1372 ... 1373 }, 1374 ... 1375 } 1376 1377 -- Set password 1378 Req-set-pw ::= SEQUENCE { 1379 languages [0] SEQUENCE OF Language-Tag OPTIONAL, 1380 new-pw [1] Password OPTIONAL, 1381 commit [2] BOOLEAN DEFAULT TRUE, 1382 etypes [3] SEQUENCE (1..) OF Etype OPTIONAL, 1383 ... 1384 } 1385 1386 Rep-set-pw ::= SEQUENCE { 1387 info-text [0] UTF8String OPTIONAL, 1388 new-pw [1] Password OPTIONAL, 1389 -- generated by the server if present 1390 -- (and requested by the client) 1391 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 1392 ... 1393 } 1394 1395 Err-set-pw ::= Err-change-pw 1396 1397 -- Set keys 1398 Req-set-keys ::= SEQUENCE { 1399 keys [0] SEQUENCE OF Key, 1400 commit [1] BOOLEAN DEFAULT TRUE, 1401 -- TRUE -> install keys now 1402 -- 1403 -- FALSE -> require set-keys-commit 1404 -- before issuing tickets 1405 -- encrypted with these keys. 1406 -- 1407 -- See commit-keys op 1408 isupport [2] KerberosVSupportNego OPTIONAL, 1409 -- For future Kerberos V extensions KDCs 1410 -- may need to know what krb5 version is 1411 -- supported by individual service 1412 -- principals. This field provides a 1413 1414N. Williams [Page 24] 1415 1416 1417DRAFT Kerberos Set/Change Password v2 Expires January 2005 1418 1419 -- way to tell the KDC what version of 1420 -- Kerberos V the target principal 1421 -- supports. 1422 ... 1423 } 1424 1425 Rep-set-keys ::= SEQUENCE { 1426 info-text [0] UTF8String OPTIONAL, 1427 kvno [1] UInt32, 1428 aliases [2] SEQUENCE OF SEQUENCE { 1429 name [0] PrincipalName, 1430 realm [1] Realm OPTIONAL, 1431 ... 1432 }, 1433 isupport [3] KerberosVSupportNego OPTIONAL, 1434 ... 1435 -- Should there be ETYPE-INFO2 stuff here? 1436 } 1437 1438 Err-set-keys ::= SEQUENCE { 1439 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1440 error [1] CHOICE { 1441 op-generic [0] Extensible-NULL, 1442 op-deferred-commit-no-support [1] Extensible-NULL, 1443 op-etype-no-support [2] SEQUENCE OF { 1444 supported-etypes [1] SEQUENCE OF Etype, 1445 ... 1446 } 1447 ... 1448 } 1449 } 1450 1451 -- Generate keys 1452 Req-gen-keys ::= SEQUENCE { 1453 etypes [0] SEQUENCE (1..) OF Etype, 1454 entropy [1] OCTET STRING OPTIONAL, 1455 commit [2] BOOLEAN DEFAULT TRUE, 1456 -- TRUE -> install keys now 1457 -- 1458 -- FALSE -> require set-keys-commit 1459 -- before issuing tickets 1460 -- encrypted with these keys. 1461 -- 1462 -- See commit-keys op 1463 isupport [3] KerberosVSupportNego OPTIONAL, 1464 -- For future Kerberos V extensions KDCs 1465 -- may need to know what krb5 version is 1466 -- supported by individual service 1467 -- principals. This field provides a 1468 -- way to tell the KDC what version of 1469 -- Kerberos V the target principal 1470 -- supports. 1471 ... 1472 1473N. Williams [Page 25] 1474 1475 1476DRAFT Kerberos Set/Change Password v2 Expires January 2005 1477 1478 } 1479 1480 Rep-gen-keys ::= SEQUENCE { 1481 info-text [0] UTF8String OPTIONAL, 1482 kvno [1] UInt32, 1483 key [2] Key, 1484 aliases [3] SEQUENCE OF SEQUENCE { 1485 name [0] PrincipalName, 1486 realm [1] Realm OPTIONAL, 1487 ... 1488 }, 1489 isupport [4] KerberosVSupportNego OPTIONAL, 1490 ... 1491 -- Should there be ETYPE-INFO2 stuff here? 1492 } 1493 1494 Err-gen-keys ::= Err-set-keys 1495 1496 -- Get un-committed key request 1497 Req-get-keys ::= SEQUENCE { 1498 kvno [0] UInt32, 1499 ... 1500 } 1501 1502 Rep-get-keys ::= SEQUENCE { 1503 info-text [0] UTF8String OPTIONAL, 1504 keys [1] SEQUENCE OF Key, 1505 aliases [2] SEQUENCE OF SEQUENCE { 1506 name [0] PrincipalName, 1507 realm [1] Realm OPTIONAL, 1508 ... 1509 }, 1510 isupport [3] KerberosVSupportNego OPTIONAL, 1511 ... 1512 -- Should there be ETYPE-INFO2 stuff here? 1513 } 1514 1515 Err-get-keys ::= SEQUENCE { 1516 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1517 error [1] CHOICE { 1518 op-generic [0] Extensible-NULL, 1519 op-kvno-committed [1] Extensible-NULL, 1520 op-no-such-kvno [1] Extensible-NULL, 1521 ... 1522 } 1523 } 1524 1525 -- Commit a set keys request 1526 Req-commit-keys ::= SEQUENCE { 1527 kvno [0] UInt32, 1528 ... 1529 } 1530 1531 1532N. Williams [Page 26] 1533 1534 1535DRAFT Kerberos Set/Change Password v2 Expires January 2005 1536 1537 Rep-commit-keys ::= Extensible-NULL 1538 1539 Err-commit-keys ::= SEQUENCE { 1540 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1541 error [1] CHOICE { 1542 op-generic [0] Extensible-NULL, 1543 op-kvno-expired [1] Extensible-NULL, 1544 -- The client took too long to respond. 1545 op-kvno-unknown [2] Extensible-NULL, 1546 -- The targ princ/kvno is invalid or unknown to the 1547 -- server (perhaps it lost track of state) 1548 op-new-keys-conflict [3] Extensible-NULL, 1549 -- A new-keys/commit-keys request subsequent to the 1550 -- new-keys that produced the kvno has completed 1551 -- and incremented the principal's kvno 1552 ... 1553 } 1554 ... 1555 } 1556 1557 -- Get password policy 1558 Req-get-pw-policy ::= Extensible-NULL 1559 1560 Rep-get-pw-policy ::= SEQUENCE { 1561 policy-name [0] UTF8String OPTIONAL, 1562 description [1] SEQUENCE OF UTF8String OPTIONAL, 1563 ... 1564 } 1565 1566 Err-get-pw-policy ::= Extensible-NULL 1567 1568 -- Get principal aliases 1569 Req-get-princ-aliases ::= Extensible-NULL 1570 1571 Rep-get-princ-aliases ::= SEQUENCE { 1572 help-text [0] UTF8String OPTIONAL, 1573 aliases [1] SEQUENCE OF SEQUENCE { 1574 name [0] PrincipalName, 1575 realm [1] Realm OPTIONAL, 1576 ... 1577 }, 1578 ... 1579 } 1580 1581 Err-get-princ-aliases ::= Extensible-NULL 1582 1583 -- Get list of enctypes supported by KDC for new keys 1584 Req-get-realm-krb5-support ::= Extensible-NULL 1585 1586 Rep-get-realm-krb5-support ::= SEQUENCE { 1587 isupport [0] KerberosVSupportNego, 1588 -- Version of Kerberos V supported by 1589 -- the target realm. 1590 1591N. Williams [Page 27] 1592 1593 1594DRAFT Kerberos Set/Change Password v2 Expires January 2005 1595 1596 ... 1597 } 1598 1599 Err-get-realm-krb5-support ::= Extensible-NULL 1600 1601 -- Get s2kparams 1602 Req-get-s2kparams ::= Extensible-NULL 1603 1604 Rep-get-s2kparams ::= SEQUENCE { 1605 help-text [0] UTF8String OPTIONAL, 1606 s2kparams [1] SEQUENCE OF Etype-Info-Entry, 1607 ... 1608 } 1609 1610 Err-get-s2kparams ::= Extensible-NULL 1611 1612 END 1613 1614 16156 IANA Considerations 1616 1617 There are no IANA considerations for this document. 1618 16197 Security Considerations 1620 1621 Implementors and site administrators should note that the redundancy 1622 of UTF-8 encodings of passwords varies by language. Password quality 1623 policies SHOULD, therefore, take this into account when estimating 1624 the amount of redundancy and entropy in a proposed new password. [?? 1625 It's late at night - I think this is correct.] 1626 1627 Kerberos set/change password/key protocol major version negotiation 1628 cannot be done securely; a downgrade attack is possible against 1629 clients that attempt to negotiate the protocol major version to use 1630 with a server. It is not clear at this time that the attacker would 1631 gain much from such a downgrade attack other than denial of service 1632 (DoS) by forcing the client to use a protocol version which does not 1633 support some feature needed by the client (Kerberos V in general is 1634 subject to a variety of DoS attacks anyways [RFC1510]). Clients 1635 SHOULD NOT negotiate support for legacy major versions of this 1636 protocol unless configured otherwise. 1637 1638 This protocol does not have Perfect Forward Security (PFS). As a 1639 result, any passive network snooper watching password/key changing 1640 operations who has stolen a principal's password or long-term keys 1641 can find out what the new ones are. 1642 1643 [More text needed?] 1644 16458 Acknowledgements 1646 1647 The authors would like to thank Bill GossmanMike Swift, John Brezak, 1648 Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W. 1649 1650N. Williams [Page 28] 1651 1652 1653DRAFT Kerberos Set/Change Password v2 Expires January 2005 1654 1655 Nelson, Marcus Watts, Love, Joel N. Weber II, Jeffrey Hutzelman and 1656 other participants from the IETF Kerberos Working Group for their 1657 assistance. 1658 16599 References 1660 16619.1 Normative References 1662 1663 [RFC2026] 1664 S. Bradner, RFC2026: "The Internet Standard Process - Revision 1665 3," October 1996, Obsoletes - RFC 1602, Status: Best Current 1666 Practice. 1667 1668 [RFC2119] 1669 S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to 1670 Indicate Requirement Levels," March 1997, Status: Best Current 1671 Practice. 1672 1673 [X680] 1674 Abstract Syntax Notation One (ASN.1): Specification of Basic 1675 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC 1676 International Standard 8824-1:1998. 1677 http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf 1678 1679 [X690] 1680 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), 1681 Canonical Encoding Rules (CER) and Distinguished Encoding Rules 1682 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International 1683 Standard 8825-1:1998. 1684 http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf 1685 1686 [clarifications] 1687 RFC-Editor: To be replaced by RFC number for 1688 draft-ietf-krb-wg-kerberos-clarifications. 1689 1690 [RFC3066] 1691 H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of 1692 Languages," January 2001, Obsoletes RFC1766, Status: Best Current 1693 Practice. 1694 16959.2 Informative References 1696 1697 [RFC3244] 1698 M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000 1699 Kerberos Change Password and Set Password Protocols," February 1700 2002, Status: Informational. 1701 170210 Authors' Addresses 1703 1704 Nicolas Williams 1705 Sun Microsystems 1706 5300 Riata Trace Ct 1707 Austin, TX 78727 1708 1709N. Williams [Page 29] 1710 1711 1712DRAFT Kerberos Set/Change Password v2 Expires January 2005 1713 1714 Email: nicolas.williams@sun.com 1715 1716 171711 Notes to the RFC Editor 1718 1719 This document has two KRB WG drafts as normative references and 1720 cannot progress until those drafts progress, but no other draft 1721 depends on this one. 1722 172312 Change History 1724 1725 -01 -> -02 1726 1727 - Removed Bill Gossman, Mike Swift and John Brezak as authors. 1728 1729 - Removed UDP as a transport for this protocol. 1730 1731 - Replaced redundant copies of framing ASCII art with reference to 1732 RFC3244. 1733 1734 - Made all name/password strings UTF8String with an extensible 1735 constraint to IA5String. 1736 1737 - Added a method for doing dry runs of operations. This is helpful 1738 in testing passwords against password quality policies. 1739 1740 - Added an operation for retrieving a principal's current and 1741 preferred string-to-key parameters, and a way to change them 1742 without changing the principal's password. 1743 1744 - Added password quality codes as hints for smart clients, but 1745 these are optional and not to be used instead of messages to be 1746 displayed to useds. 1747 1748 - Added a 'commit' option to change-pw and set-pw (as requested by 1749 Larry). 1750 1751 - Removed "version" field of the Kerberos V feature negotiation 1752 struture. 1753 1754 1755 1756N. Williams [Page 30] 1757 1758 1759DRAFT Kerberos Set/Change Password v2 Expires January 2005 1760 1761 1762 1763Intellectual Property Statement 1764 1765 The IETF takes no position regarding the validity or scope of any 1766 Intellectual Property Rights or other rights that might be claimed to 1767 pertain to the implementation or use of the technology described in 1768 this document or the extent to which any license under such rights 1769 might or might not be available; nor does it represent that it has 1770 made any independent effort to identify any such rights. Information 1771 on the procedures with respect to rights in RFC documents can be 1772 found in BCP 78 and BCP 79. 1773 1774 Copies of IPR disclosures made to the IETF Secretariat and any 1775 assurances of licenses to be made available, or the result of an 1776 attempt made to obtain a general license or permission for the use of 1777 such proprietary rights by implementers or users of this 1778 specification can be obtained from the IETF on-line IPR repository at 1779 http://www.ietf.org/ipr. 1780 1781 The IETF invites any interested party to bring to its attention any 1782 copyrights, patents or patent applications, or other proprietary 1783 rights that may cover technology that may be required to implement 1784 this standard. Please address the information to the IETF at 1785 ietf-ipr@ietf.org. 1786 1787 1788Disclaimer of Validity 1789 1790 This document and the information contained herein are provided on an 1791 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1792 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1793 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1794 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1795 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1796 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1797 1798 1799Copyright Statement 1800 1801 Copyright (C) The Internet Society (2005). This document is subject 1802 to the rights, licenses and restrictions contained in BCP 78, and 1803 except as set forth therein, the authors retain all their rights. 1804 1805 1806Acknowledgment 1807 1808 Funding for the RFC Editor function is currently provided by the 1809 Internet Society. 1810 1811 1812 1813 1814Williams Expires August 22, 2005 [Page 31] 1815 1816 1817