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