idnits 2.17.1 draft-ietf-krb-wg-kerberos-set-passwd-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1671. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1687), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 30 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2005) is 6998 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1510' is mentioned on line 1534, but not defined ** Obsolete undefined reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Looks like a reference, but probably isn't: '1' on line 1507 -- Looks like a reference, but probably isn't: '0' on line 1506 -- Looks like a reference, but probably isn't: '2' on line 1449 == Missing Reference: 'APPLICATION 0' is mentioned on line 1126, but not defined -- Looks like a reference, but probably isn't: '3' on line 1452 -- Looks like a reference, but probably isn't: '4' on line 1397 -- Looks like a reference, but probably isn't: '5' on line 1194 == Missing Reference: 'APPLICATION 1' is mentioned on line 1139, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 1146, but not defined -- Looks like a reference, but probably isn't: '6' on line 1195 -- Looks like a reference, but probably isn't: '7' on line 1196 -- Looks like a reference, but probably isn't: '8' on line 1197 -- Looks like a reference, but probably isn't: '9' on line 1198 -- Looks like a reference, but probably isn't: '10' on line 1199 == Unused Reference: 'RFC2026' is defined on line 1560, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1602 (ref. 'RFC2026') (Obsoleted by RFC 2026) -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' ** Obsolete normative reference: RFC 1766 (ref. 'RFC3066') (Obsoleted by RFC 3066, RFC 3282) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Kerberos Working Group Nicolas Williams 2 INTERNET-DRAFT Sun Microsystems 3 Expires: August 22, 2005 February 21, 2005 5 Kerberos Set/Change Password: Version 2 6 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 22, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This document specifies an extensible protocol for setting keys and 40 changing the passwords of Kerberos V principals. 42 Table of Contents 44 1 Introduction 45 2 The Protocol 46 2.1 Transports 47 2.2 Protocol Framing 48 2.3 Protocol version negotiation 49 2.3.1 Protocol Major Version Negotiation 50 2.3.2 Protocol Minor Version Negotiation 51 2.4 Use of Kerberos V 53 DRAFT Kerberos Set/Change Password v2 Expires January 2005 55 2.5 Use of ASN.1 56 2.6 Internationalization 57 2.6.1 Normalization Forms for UTF-8 Strings 58 2.6.2 Language Negotiation 59 2.7 Protocol Extensibility 60 2.8 Protocol Subsets 61 3 Protocol Elements 62 3.1 PDUs 63 3.2 Operations 64 3.2.1 Null 65 3.2.2 Change Kerberos Password 66 3.2.3 Set Kerberos Password 67 3.2.4 Set Kerberos Keys 68 3.2.5 Generate Kerberos Keys 69 3.2.6 Get New Keys 70 3.2.7 Commit New Keys 71 3.2.8 Get Password Quality Policy 72 3.2.9 Get Principal Aliases 73 3.2.10 Get Realm's Supported Kerberos V Version and Features 74 4 ASN.1 Module 75 6 IANA Considerations 76 7 Security Considerations 77 8 Acknowledgements 78 9 References 79 9.1 Normative References 80 9.2 Informative References 81 10 Authors' Addresses 82 11 Notes to the RFC Editor 84 Conventions used in this document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 1 Introduction 92 Up to this point Kerberos V has lacked a single, standard protocol 93 for changing passwords and keys. While several vendor-specific 94 protocols exist for changing Kerberos passwords/keys, none are 95 properly internationalized and all are incomplete in one respect or 96 another and none are sufficiently extensible to cope with new 97 features that may be added to Kerberos V at some future time. 99 This document defines a protocol that is somewhat backward-compatible 100 with the "kpasswd" protocol defined in [RFC3244] that uses more or 101 less the same protocol framing. 103 This new protocol is designed to be extensible and properly 104 internationalized. 106 2 The Protocol 107 DRAFT Kerberos Set/Change Password v2 Expires January 2005 109 The structure of the protocol is quite similar to that of typical RPC 110 protocols. Each transaction consists of a data structure specific to 111 an operation which is then wrapped in a data structure which is 112 general to all operations of the protocol. These data structures are 113 defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they 114 are encoded using the Distinguished Encoding Rules (DER) [X690]. 116 All protocol data is wrapped KRB-PRIV messages, or, in some cases, a 117 KRB-ERROR, and framed in a header that is backwards compatible with 118 [RFC3244]. 120 2.1 Transports 122 The service supports only connection-oriented transports, 123 specifically TCP, and MUST accept requests on TCP port 464, the same 124 as in [RFC3244]. 126 2.2 Protocol Framing 128 Requests and responses are exchanged using the same framing as in 129 [RFC3244], but with the following differences: 131 - the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1) 133 - the 'AP-REQ length' field of the request can be set to 0x0, in 134 which case the 'AP-REQ' field of the request is excluded 136 - the 'KRB-PRIV' field of the request and reply is mutually 137 exclusive with the 'AP-REQ' field of the request 139 - the 'AP-REP length' field of the reply can be set to 0x0, in 140 which case the 'AP-REP' field of the reply is excluded 142 - all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can 143 be or has been accepted by the server 145 - any KRB-ERROR messages are framed and sent in the 'AP-REP' field 146 of the reply 148 The initial message from the client MUST carry an AP-REQ and the 149 response to any request bearing an AP-REQ MUST carry an AP-REP or 150 MUST be a KRB-ERROR. 152 Subsequent messages exchanged on the same TCP connection MAY involve 153 Kerberos V AP exchanges, but generally the client SHOULD NOT initiate 154 a new AP exchange except when it desires to authenticate as a 155 different principal, when the ticket last used for authentication 156 expires or when the server responds with an error indicating that the 157 client must re-authenticate. 159 2.3 Protocol Version Negotiation 161 There are several major versions of this protocol. Version 2 also 163 DRAFT Kerberos Set/Change Password v2 Expires January 2005 165 introduces a notion of protocol minor versions for use in negotiating 166 protocol extensions. As of this time only one minor version is 167 defined for major version 2: minor version 0, defined herein. 169 2.3.1 Protocol Major Version Negotiation 171 Version 2 clients that also support other versions, such as 0xff80, 172 as in [RFC3244], SHOULD attempt to use version 2 of the protocol 173 first. 175 Servers which do not support version 2 of this protocol typically 176 include their preferred version number in the reply and/or may 177 include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a 178 status code of KRB5_KPASSWD_MALFORMED. 180 Note that some [RFC3244] server implementations close the TCP 181 connection without returning any other response. Note also that 182 there is no integrity protection for the major version number in the 183 protocol framing or for any data in a KRB-ERROR. 185 As a result change password protocol major version negotiation is 186 subject to downgrade attacks. Therefore major version negotiation is 187 NOT RECOMMENDED. 189 Where the server indicates that it does not support version 2, the 190 client MAY, but SHOULD NOT, unless configured to do so, fall back on 191 another major version of this protocol. 193 Version 2 servers MAY respond to non-v2 requests using whatever 194 response is appropriate for the versions used by the clients, but if 195 a server does not do this or know how to do this then it MUST respond 196 with an error framed as in section 2.2, using an AP-REP and KRB-PRIV 197 if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and 198 using a ProtocolErrorCode value of unsupported-major-version. 200 It is expected that implementations of as yet unspecified future 201 major versions of this protocol will be required to support version 2 202 integrity protected error replies for properly indicating no support 203 for version 2 of the protocl. We also hope that no further major 204 versions of this protocol will be needed. 206 2.3.2 Protocol Minor Version Negotiation 208 Version 2 clients are free to use whatever protocol minor version and 209 message extensions are available to them in their initial messages to 210 version 2 servers, provided that the minor versions (other than 0) 211 have been defined through IETF documents. 213 Version 2 servers MUST answer with the highest protocol minor version 214 number supported by the server and the client. 216 Version 2 clients MUST use the protocol minor version used in a 217 server's reply for any subsequent messages in the same TCP session. 219 DRAFT Kerberos Set/Change Password v2 Expires January 2005 221 See section 2.7 for further description of the protocol's 222 extensibility and its relation to protocol minor versions and the 223 negotiation thereof. 225 2.4 Use of Kerberos V and Key Exchange 227 This protocol makes use of messages defined in [RFC1510] and 228 [clarifications]. Specifically, AP-REQ, AP-REP, KRB-ERROR and 229 KRB-PRIV. 231 All operations are to be performed by the server on behalf of the 232 client principal. 234 Clients SHOULD use "kadmin/setpw" as the principal name of the server 235 for all requests except when changing the client principal's own 236 expired password, for which they should use "kadmin/changepw". The 237 "kadmin/changepw" service exists to allow KDCs to limit principals 238 with expired passwords to getting initial tickets to the password 239 changing service only and only for changing expired passwords. 241 Servers MUST limit clients that used the "kadmin/changepw" service 242 principal name to changing the password of the client principal. 244 The client MUST request mutual authentication and the client MUST 245 MUST request the use of sequence numbers. 247 Clients SHOULD use INITIAL tickets for requests whose target 248 principal is the client's principal. Servers SHOULD force the use of 249 INITIAL tickets for such requests and MAY force the use of INITIAL 250 for all others - see section 3.2. 252 Servers MUST specify a sub-session key. 254 The encrypted part of KRB-PRIVs MUST be encrypted with the server's 255 sub-session key and key usage 20 (client->server) or 21 256 (server->client). 258 After each new AP exchange the client and server MUST destroy the 259 session keys, if any, resulting from the previous AP exchange. 261 2.5 Use of ASN.1 263 This protocol's messages are defined in ASN.1, using only features 264 from [X680]. All ASN.1 types defined herein are to be encoded in 265 DER [X690]. A complete ASN.1 module is given in section 4. 267 The DER encoding of the ASN.1 PDUs are exchanged wrapped in a 268 KRB-PRIV as described above and/or as e-data in KRB-ERROR messages. 270 2.6 Internationalization 272 This protocol's request PDU carries an optional field indicating the 274 DRAFT Kerberos Set/Change Password v2 Expires January 2005 276 languages spoken by the client user; the client SHOULD send its list 277 of spoken languages to the server (once per-TCP session). 279 The server SHOULD localize all strings intended for display to users 280 to a language in common with the languages spoken by the client user. 282 Strings for Kerberos principal and realm names used in this protocol 283 are be constrained as per [clarifications]. 285 2.6.1 Normalization Forms for UTF-8 Strings 287 Because Kerberos V [clarifications] restricts principal names, realm 288 names and passwords to IA5String, this protocol uses UTF8String with 289 an extensible constraint to IA5String. 291 Future versions of Kerberos may relax this constraint; if so then a 292 minor version of this protocol should relax this constraint 293 accordingly. 295 2.6.2 Language Negotiation 297 The server MUST pick a language from the client's input list or 298 the default language tag (see [RFC3066]) for text in its responses 299 which is meant for the user to read. 301 The server SHOULD use a language selection algorithm such that 302 consideration is first given to exact matches between the client's 303 spoken languages and the server's available locales, followed by 304 "fuzzy" matches where only the first sub-tags of the client's 305 language tag list are used for matching against the servers available 306 locales. 308 Servers MUST cache the optional language tag lists from prior 309 requests for use with subsequent requests that exclude the language 310 tag list. Clients MAY expect such server behaviour and send the 311 language tag lists only once per-TCP session. Clients SHOULD send 312 the server the language tag list at least once. 314 When the server has a message catalog for one of the client's spoken 315 languages the server SHOULD localize any text strings intended for 316 display to users. 318 2.7 Protocol Extensibility 320 The protocol is defined in ASN.1 and uses extensibility markers 321 throughout. As such, the module presented herein can be extended 322 within the framework of [X680]. 324 Typed holes are not used in this protocol as it is very simple and 325 does not require the ability to deal with abstract data types defined 326 in different layers. For this reason, the only way to extend this 327 protocol is by extending the ASN.1 module within the framework of the 328 IETF; all future extensions to this protocol have to be defined in 330 DRAFT Kerberos Set/Change Password v2 Expires January 2005 332 IETF documents unless otherwise specified in a future IETF revision 333 of this protocol. 335 A protocol minor version number is used to negotiate use of 336 extensions. See section 2.3.2 for the minor version negotiation. 338 Servers SHOULD ignore unknown additions to the ASN.1 types, in 339 initial requests, where the syntax allows them, except for extensions 340 to the "Op-req" type, which MUST result in an error. 342 Servers MUST respond with an error (ProtocolErrorCode value of 343 unsupported-minor-version) to clients that use operations unknown to 344 the server. 346 2.8 Protocol Subsets 348 The structure of the protocol is such that the ASN.1 syntaxes for the 349 various operations supported by the protocol are independent of the 350 each other. Client and server implementations MAY implement subsets 351 of the overall protocol by removing some alternatives to the Op-req, 352 Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4. 354 For example, it should be possible to have a password-change only 355 client that cannot set principal's keys - and vice versa. 357 3 Protocol Elements 359 The protocol as defined herein supports the following operations 360 relating to the management of Kerberos principal's passwords or keys: 362 [NOTE: New since last version of this I-D.] 363 - get principal's current and preferred string-to-key parameters 365 - change password (or enctypes and string-to-key parameters) 366 - set password (administrative) 367 - set new keys 368 - generate new keys 369 - get new, un-committed keys 370 - commit new keys 371 - get password policy name and/or description of principal 372 - list aliases of a principal 373 - list enctypes and version of Kerberos V supported by realm 375 The operation for retrieving a list of aliases of a principal is 376 needed where KDCs implement aliasing of principal names and allows 377 clients to properly setup their key databases when principal aliasing 378 is in use. 380 Operations such as creation or deletion of principals are outside the 381 scope of this document, and should be performed via other means, such 382 as through directories or other Kerberos administration protocols. 384 The individual operations are described in section 3.2. 386 DRAFT Kerberos Set/Change Password v2 Expires January 2005 388 3.1 PDUs 390 The types "Request," "Response" and "Error-Response" are the ASN.1 391 module's PDUs. 393 The "Request" and "Response" PDUs are always to be sent wrapped in 394 KRB-PRIV messages, except for the "Error-Response" PDU which MUST be 395 sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail, 396 otherwise it MUST be sent wrapped in a KRB-PRIV. 398 The ASN.1 syntax for the PDUs is given in section 4. 400 Note that the first field of each PDU is the major version of the 401 protocol, defaulted to 2, meaning that it is never included in 402 version 2 exchanges. Similarly, the second field of each PDU is the 403 minor version, defaulted to 0. 405 The request, responses and error PDUs consist of an outer structure 406 ("Request," "Response" and "Error-Response") containing fields common 407 to all requests, responses and errors, respectively, and an inner 408 structure for fields that are specific to each operation's 409 requests/responses. The inner structure is optional in the case of 410 the Error-Response PDU and need not be included when generic errors 411 occur for which there is a suitable ProtocolErrorCode. 413 Specifically, the outer Request structure has a field for passing a 414 client user's spoken (read) languages to the server. It also has two 415 optional fields for identifying the requested operation's target 416 principal's name and realm (if not sent then the server MUST use the 417 client's principal name and realm as the target). A boolean field 418 for indicating whether or not the request should be dry-run is also 419 included; dry-runs can be used to test server policies, and servers 420 MUST NOT modify any principals when processing dry-run requests. 422 The Response and Error PDUs' outer structures include a field 423 indicating the language that the server has chosen for localization 424 of text intended to be displayed to users; this field is defaulted to 425 "i-default". This language tag applies to all UTF8 strings in the 426 inner structure (Op-rep and Op-err) that are meant to be displayed to 427 users. 429 The protocol error codes are: 431 - proto-generic-error 433 An operation-specific error ocurred, see the inner Op-error. 435 - proto-format-error 436 - proto-unsupported-major-version 437 - proto-unsupported-minor-version 438 - proto-unsupported-operation 440 DRAFT Kerberos Set/Change Password v2 Expires January 2005 442 - proto-wrong-service-principal 444 Use kadmin/setpw for the server's principal name. 446 - proto-re-authentication-required 448 The server demands that the client re-authenticate through a new 449 AP exchange. 451 - proto-initial-ticket-required 453 Use of an INITIAL ticket is required for the requested 454 operation. 456 - proto-client-and-target-realm-mismatch 458 The server requires that the client's principal name and the 459 target principal of the operation share the same realm name. 461 - proto-target-principal-unknown 462 - proto-authorization-failed 464 3.2 Operations 466 This section describes the semantics of each operation request and 467 response defined in the ASN.1 module in section 4. 469 3.2.1 Null 471 NAME 473 null - Null or "ping" operation 475 DESCRIPTION 477 The null request is intended for use with TCP; its purpose is 478 similar to RPC null procedures and is akin to a "ping" operation. 480 ERRORS 482 None. 484 3.2.2 Change Kerberos Password 486 NAME 488 change-pw - Change password operation 490 SYNOPSIS 492 Req-change-pw(old-pw, [languages], [new-pw], 493 [commit], [etypes]) -> 494 Rep-change-pw([info-text], [new-pw], [etypes]) | 496 DRAFT Kerberos Set/Change Password v2 Expires January 2005 498 Err-change-pw([help-text], error code, [error info]) 500 DESCRIPTION 502 Change a principal's password. 504 The change password request has one required, three optional and 505 one defaulted arguments: "old-pw" (required), "languages," 506 "new-pw", "commit" (defaults to "TRUE") and "etypes", 507 corresponding to the target principal's old password, its 508 preferred languages, its new password, a boolean indicating 509 whether or not to make the new long-term key available for 510 immediate use, and the desired enctypes for the new long-term 511 keys. 513 The server MUST validate the old password and MUST check the 514 quality of the new password, if sent, according the password 515 quality policy associated with the target principal. 517 If the old and new passwords in the request are the same strings, 518 and the principal is not currently required to change its 519 password, then the server MAY permit the password change as way to 520 change a principal's enctypes and string-to-key parameters. This 521 feature provides a way to, for example, add enctypes to a 522 principals' password-derived long-term keys without forcing a 523 password change following an upgrade to the KDC that adds support 524 for new enctypes. 526 A client MAY request that the server generate a new password by 527 excluding the new password from its request, in which case the 528 server MUST either generate a new password or respond with an 529 error indicating that it does not support this feature. 531 Server-generated passwords MUST meet the target principal's 532 password quality policy. It is RECOMMENDED that server-generated 533 passwords be user-friendly, that is, memorable and that the target 534 principal's preferred languages be taken into account by the 535 password generation alogrithm used by the server. 537 Uncommitted password changes are commited using the commit-keys 538 operation. 540 RETURN 542 Upon successful password changes the server responds with a 543 Rep-change-pw. The fields of Rep-change-pw are all optional and 544 include: 546 - 'info-text' which the server can use to send a message to the 547 user such as "Your new password will expire in 90 days," for 548 example. 550 - 'new-pw' which the server MUST include if the client 552 DRAFT Kerberos Set/Change Password v2 Expires January 2005 554 requested that the server generate a new password; generated 555 passwords MUST pass the target principal's password quality 556 policy. 558 - 'etypes' which the server MAY include to indicate which types 559 of long-term keys it created for the target principal and 560 which the server MUST include if the client specified a set 561 of enctypes in its request. 563 ERRORS 565 The server may respond to change password requests with protocol 566 or operation errors. See section 3.1 for a description of 567 protocol error codes. 569 All operation errors include an optional 'help-text' field by 570 which the server can describe the error in a human-readable, 571 localizaed string. 573 Change password error codes include: 575 - generic-error 577 - old-pw-incorrect 579 - wont-generate-new-pw 581 The server will not generate a new password for this 582 principal or does not support password generation in general. 584 - new-pw-rejected-generic 586 The client's proposed new password failed the target 587 principal's password quality policy. 589 The server MUST include a description of the password quality 590 policy or aspect of it that the client's proposed new 591 password failed to meet. 593 The server MAY generate and send a new password that the 594 client can then use as a new password and which is guaranteed 595 to pass the target principal's current password quality 596 policy. 598 The server MAY include a set of policy error code hints. 600 - etype-not-supported 602 The client requested an enctype that the KDC does not 603 support. 605 3.2.3 Set Kerberos Password 606 DRAFT Kerberos Set/Change Password v2 Expires January 2005 608 NAME 610 set-pw - Set password operation 612 SYNOPSIS 614 Req-set-pw([languages], [new-pw], [commit], [etypes]) -> 615 Rep-set-pw([info-text], [new-pw], [etypes]) | 616 Err-set-pw([help-text], error code, [error info]) 618 DESCRIPTION 620 Administratively set a principal's password. 622 The set password request has three optional and one defaulted 623 arguments: "languages", "new-pw," "commit" (defaulted to "TRUE") 624 and "etypes", corresponding to the target principal's preferred 625 languages, new password, a boolean indicating whether or not to 626 make the new long-term key available for immediate use, and the 627 desired enctypes for the new long-term keys. 629 The server MUST check the quality of the new password, if sent, 630 according the password quality policy associated with the target 631 principal. 633 The server SHOULD require that the client use the change-pw 634 operation instead of set-pw when the client principal and the 635 target principal are the same. 637 A client MAY request that the server generate a new password by 638 excluding the new password from its request, in which case the 639 server MUST either generate a new password or respond with an 640 error indicating that it does not support this feature. 642 Server-generated passwords MUST meet the target principal's 643 password quality policy. It is RECOMMENDED that server-generated 644 passwords be user-friendly, that is, memorable and that the target 645 principal's preferred languages be taken into account by the 646 password generation alogrithm used by the server. 648 RETURN 650 Upon successfully setting a password the server responds with a 651 Rep-set-pw. The fields of Rep-set-pw are all optional and 652 include: 654 - 'info-text' which the server can use to send a message to the 655 user such as "Your new password will expire in 90 days," for 656 example. 658 - 'new-pw' which the server MUST include if the client 659 requested that the server generate a new password; generated 660 passwords MUST pass the target principal's password quality 662 DRAFT Kerberos Set/Change Password v2 Expires January 2005 664 policy. 666 - 'etypes' which the server MAY include to indicate which types 667 of long-term keys it created for the target principal and 668 which the server MUST include if the client specified a set 669 of enctypes in its request. 671 ERRORS 673 The server may respond to set password requests with protocol or 674 operation errors. See section XYZ for a description of protocol 675 error codes. 677 All operation errors include an optional 'help-text' field by 678 which the server can describe the error in a human-readable, 679 localizaed string. 681 Set password error codes include: 683 - generic-error 685 - use-change-pw 687 The server demands that the client use the change-pw 688 operation for the target principal of the set-pw request. 690 - wont-generate-new-pw 692 The server will not generate a new password for this 693 principal or does not support password generation in general. 695 - new-pw-rejected-generic 697 The client's proposed new password failed the target 698 principal's password quality policy. 700 The server MUST include a description of the password quality 701 policy or aspect of it that the client's proposed new 702 password failed to meet. 704 The server MAY generate and send a new password that the 705 client can then use as a new password and which is guaranteed 706 to pass the target principal's current password quality 707 policy. 709 The server MAY include a set of policy error code hints. 711 - etype-not-supported 713 The client requested an enctype that the KDC does not 714 support. 716 3.2.4 Set Kerberos Keys 717 DRAFT Kerberos Set/Change Password v2 Expires January 2005 719 NAME 721 set-keys 723 SYNOPSIS 725 Req-set-keys(new-keys, commit?, [isupport]) -> 726 Rep-set-keys([info-text], kvno, aliases, [isupport]) 728 DESCRIPTION 730 The set-keys request consists of two required fields and one 731 optional field: "new-keys", "commit" (a boolean field - see below) 732 and "isupport", an optional field for indicating to the KDC what 733 Kerberos V features are supported by the target principal. 735 When "commit" is true the KDC makes the new keys available for 736 issueing tickets encrypted in them immediately. Otherwise the 737 client MUST follow up with a commit-keys request to make the keys 738 available. This feature is useful for changing keys shared by 739 multiple hosts, in clustered services, for example, in an atomic 740 manner; see section 3.2.6 and 3.2.7. 742 If a principal has keys are awaiting commitment when a new 743 set-keys request for that principal s made then the KDC MUST 744 overwrite the deferred keys. 746 RETURN 748 For successful set-keys operations the server returns: 750 - Informational text, optional. 752 - The new kvno for the target principal. 754 - A list of aliases of the target principal known to the KDC 755 (optional). 757 - The set of Kerberos V features supported by the KDC 758 (optional). 760 ERRORS 762 The server may respond with the following errors: 764 - generic 765 - deferred-commit-no-support 766 - etype-no-support 768 3.2.5 Generate Kerberos Keys 770 NAME 772 DRAFT Kerberos Set/Change Password v2 Expires January 2005 774 gen-keys 776 SYNOPSIS 778 Req-gen-keys(etypes, [entropy], commit?, [isupport]) -> 779 Rep-set-keys([info-text], key, kvno, aliases, [isupport]) 781 DESCRIPTION 783 The gen-keys is similar to the set-keys request (see section 784 3.2.4) but differs in that the server generates keys of 785 client-requested enctypes, rather than the client providing 786 specific keys. 788 The gen-keys request consists of two required fields and two 789 optional fields: "etypes" (the enctypes of the new keys), 790 "entropy", "commit" and "isupport" (see section 3.2.4). 792 If a principal has keys are awaiting commitment when a new 793 set-keys request for that principal s made then the KDC MUST 794 overwrite the deferred keys. 796 RETURN 798 For successful set-keys operations the server returns: 800 - Informational text, optional. 802 - The new kvno for the target principal. 804 - The new key (only one is needed). 806 - A list of aliases of the target principal known to the KDC 807 (optional). 809 - The set of Kerberos V features supported by the KDC 810 (optional). 812 ERRORS 814 The server may respond with the following errors: 816 - generic 817 - deferred-commit-no-support 818 - etype-no-support 820 3.2.6 Get New Keys 822 NAME 824 get-keys 826 DRAFT Kerberos Set/Change Password v2 Expires January 2005 828 SYNOPSIS 830 Req-get-keys(kvno) -> 831 Rep-get-keys([info-text], keys, aliases, [isupport]) | 832 Err-get-keys([help-text], error code, [error info]) 834 DESCRIPTION 836 This request allows a client to get the keys set or generated in a 837 previous set-keys or gen-keys request with deferred commitment.. 839 RETURN 841 If the target principal and kvno correspond to uncommitted keys 842 the server MUST respond with the actual keys that would be set by 843 a subsequent commit-keys request. Otherwise the server MUST 844 respond with an error (meaning that this operation cannot be used 845 to extract keys from the KDC that may be in use). 847 ERRORS 849 - generic 850 - kvno-committed 851 - no-such-kvno 853 3.2.7 Commit New Keys 855 NAME 857 commit-keys 859 SYNOPSIS 861 Req-commit-keys(kvno) -> 862 Rep-commit-keys() | 863 Err-commit-keys([help-text], error code, [error info]) 865 DESCRIPTION 867 The commit-keys operation allows a client to bring a principal's 868 new keys into use at the KDC. 870 Clients should make a commit-keys request corresponding to a 871 deferred commitment set-keys/gen-keys operation as soon as the 872 local key database for the target principal is updated. 874 The target principal name and the kvno MUST match those from a 875 prior set-keys or gen-keys operation. 877 Servers MAY expire delayed key commitments at will. Servers 878 SHOULD expire uncommitted new keys after a reasonable amount of 879 time (600 seconds is RECOMMENDED). 881 DRAFT Kerberos Set/Change Password v2 Expires January 2005 883 Servers MUST respond to new set-keys requests for principals with 884 pending, uncommitted new keys by expiring the uncommitted new keys 885 and proceeding as if there had been no expired new keys. 887 ERRORS 889 - generic 890 - op-kvno-expired 891 - op-kvno-unknown 892 - new-keys-conflict (A set-keys or gen-keys request succeeded 893 subsequent to the request that matches this 894 {principal, kvno} tuple.) 896 3.2.8 Get Password Quality Policy 898 NAME 900 get-pw-policy 902 SYNOPSIS 904 Req-get-pw-policy() -> 905 Rep-get-pw-policy([policy name], [policy description]) 907 DESCRIPTION 909 Returns a description of the target principal's associated 910 password quality policy, if any, as a list of localized 911 UTF8String values. 913 Clients can use this operation in conjunction with the change-pw 914 operation to obtain text that can be displayed to the user before 915 the user actually enters a new password. 917 It is common for sites to set policies with respect to password 918 quality. It is beyond the scope of this document to describe such 919 policies. Management of password quality policies' actual content 920 is also beyond the scope of this protocol. 922 ERRORS 924 No operation errors are defined. 926 3.2.9 Get Principal Aliases 928 NAME 930 get-print-aliases 932 SYNOPSIS 934 Req-get-princ-aliases() -> 936 DRAFT Kerberos Set/Change Password v2 Expires January 2005 938 Rep-get-princ-aliases(aliases) 940 DESCRIPTION 942 Returns a list of aliases of the target principal. 944 ERRORS 946 No operation-specific errors. 948 3.2.10 Get Realm's Supported Kerberos V Version and Features 950 NAME 952 get-realm-krb5-support 954 SYNOPSIS 956 Req-get-realm-krb5-support() -> 957 Rep-get-realm-krb5-support(isupport) 959 DESCRIPTION 961 Returns set of Kerberos V features support by the target 962 principal's realm's KDCs. 964 ERRORS 966 No operation-specific errors. 968 3.2.11 Retrieve Principal's S2K Params and Preferred Params 970 NAME 972 get-s2kparams 974 SYNOPSIS 976 Req-get-s2kparams() -> 977 Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams]) 979 DESCRIPTION 981 Returns the string2key parameters for the principal's current 982 password-derived long-term keys, if any, and the parameters that 983 the realm would prefer, if they differ from the former. 985 This operation is intended for use with the change-pw() operation. 986 When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if 987 the principal's long-term secret keys' string2key parameters (and 988 enctype list) should be changed and, if so, change them. 990 If the 'princ-s2kparams' return value is missing then the 992 DRAFT Kerberos Set/Change Password v2 Expires January 2005 994 principal does not have a password-derived long-term key. 996 The 'preferred-s2kparams' MUST be excluded if the principal's 997 string2key parameters satisfy the realm's policy. 999 ERRORS 1001 No operation-specific errors. 1003 3.3 Principal Aliases 1005 Applications that use Kerberos often have to derive acceptor 1006 principal names from hostnames entered by users. Such hostnames may 1007 be aliases, they may be fully qualified, partially qualified or not 1008 qualified at all. Some implementations have resorted to deriving 1009 principal names from such hostnames by utilizing the names services 1010 to canonicalize the hostname first; such practices are not secure 1011 unless the name service are secure, which often aren't. 1013 One method for securely deriving principal names from hostnames is to 1014 alias principals at the KDC such that the KDC will issue tickets for 1015 principal names which are aliases of others. It is helpful for 1016 principals to know what are their aliases as known by the KDCs. 1018 Note that changing a principal's aliases is out of scope for this 1019 protocol. 1021 3.4 Kerberos V Feature Negotiation 1023 Principals and realms' KDCs may need to know about additional 1024 Kerberos V features and extensions that they each support. Several 1025 operations (see above) provide a way for clients and servers to 1026 exchange such infomration, in the form of lists of types supported 1027 for the various typed holes used in Kerberos V. 1029 4 ASN.1 Module 1031 DEFINITIONS EXPLICIT TAGS ::= BEGIN 1032 -- 1033 -- Note: EXPLICIT tagging is in use by default throughout this 1034 -- module. 1036 -- From [clarifications] with modifications 1037 PrincipalName ::= SEQUENCE { 1038 name-string [1] SEQUENCE OF UTF8String (IA5String, ...) 1039 } 1040 Realm ::= UTF8String (IA5String, ...) 1041 Salt ::= UTF8String (IA5String, ...) 1042 Password ::= UTF8String (IA5String, ...) 1044 -- NOTE WELL: Principal and realm names MUST be constrained by the 1045 -- specification of the version of Kerberos V used by the 1046 -- client. 1048 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1050 -- 1051 -- [Perhaps PrincipalName should be a SEQUENCE of an optional name 1052 -- type and a UTF8String, for simplicity.] 1054 -- From [clarifications] 1055 Int32 ::= INTEGER (-2147483648..2147483647) 1056 UInt32 ::= INTEGER (0..4294967295) 1058 -- Based on [clarifications] 1059 Etype ::= Int32 1060 Etype-Info-Entry ::= SEQUENCE { 1061 etype [0] Etype, 1062 salt [1] Salt OPTIONAL, 1063 s2kparams [2] OCTET STRING OPTIONAL, 1064 ... 1065 } 1066 Key ::= SEQUENCE { 1067 enc-type [0] Etype, -- from Kerberos 1068 key [1] OCTET STRING, 1069 ... 1070 } 1072 Language-Tag ::= UTF8String -- Constrained by [RFC3066] 1074 -- Empty, extensible SEQUENCEs are legal ASN.1 1075 Extensible-NULL ::= SEQUENCE { 1076 ... 1077 } 1079 -- Kerberos clients negotiate some parameters relating to their peers 1080 -- indirectly through the KDC. Today this is true of ticket session 1081 -- key enctypes, but in the future this indirect negotiation may also 1082 -- occur with respect to the minor version of Kerberos V to be used 1083 -- between clients and servers. Additionally, KDCs may need to know 1084 -- what authorization-data types are supported by service principals, 1085 -- both, for compatibility with legacy software and for optimization. 1086 -- 1087 -- Thesefore it is important for KDCs to know what features of 1088 -- Kerberos V each service principal supports. 1089 -- 1090 -- In version 2.0 of this protocol the clients and servers may notify 1091 -- each other of their support for: 1092 -- 1093 -- - enctypes 1094 -- - authorization data types 1095 -- - transited encoding data types 1096 -- 1097 -- All authorization-data types defined in [clarifications] are 1098 -- assumed to be supported if the minor version is 1 and do not need 1099 -- to be included in the ad-type list. 1100 -- 1101 -- Int32 is used for enctype and transited encoding data type 1102 -- identifiers. 1104 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1106 -- 1107 -- An extensible CHOICE of Int32 is used for authorization data 1108 -- types. 1110 KerberosV-TR-ID ::= Int32 1112 KerberosV-AD-ID ::= CHOICE { 1113 ad-int [0] Int32, 1114 ... 1115 } 1117 KerberosVSupportNego ::= SEQUENCE { 1118 enc-types [0] SEQUENCE OF Etype, 1119 ad-types [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL, 1120 -- authorization data types 1121 tr-enc-types [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL, 1122 -- transited encoding types 1123 ... 1124 } 1126 Request ::= [APPLICATION 0] SEQUENCE { 1127 pvno-minor [0] INTEGER DEFAULT 0, 1128 languages [1] SEQUENCE OF Language-Tag OPTIONAL, 1129 -- Should be defaulted to the SEQUENCE of "i-default" 1130 targ-name [2] PrincipalName OPTIONAL, 1131 targ-realm [3] Realm OPTIONAL, 1132 -- If targ-name/realm are missing then the request 1133 -- applies to the principal of the client 1134 dry-run [4] BOOLEAN DEFAULT FALSE, 1135 operation [5] Op-req, 1136 ... 1137 } 1139 Response ::= [APPLICATION 1] SEQUENCE { 1140 pvno-minor [0] INTEGER DEFAULT 0, 1141 language [1] Language-Tag DEFAULT "i-default", 1142 result [2] Op-rep, 1143 ... 1144 } 1146 Error-Response ::= [APPLICATION 2] SEQUENCE { 1147 pvno-minor [0] INTEGER DEFAULT 0, 1148 language [1] Language-Tag DEFAULT "i-default", 1149 error-code [2] ProtocolErrorCode, 1150 help-text [3] UTF8String OPTIONAL, 1151 op-error [4] Op-err OPTIONAL, 1152 ... 1153 } 1155 Op-req ::= CHOICE { 1156 null [0] Req-null, 1157 change-pw [1] Req-change-pw, 1158 set-pw [2] Req-set-pw, 1160 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1162 set-keys [3] Req-set-keys, 1163 gen-keys [4] Req-gen-keys, 1164 get-keys [5] Req-get-keys, 1165 commit-keys [6] Req-commit-keys, 1166 get-pw-policy [7] Req-get-pw-policy, 1167 get-princ-aliases [8] Req-get-princ-aliases, 1168 get-realm-krb5-support [9] Req-get-realm-krb5-support, 1169 get-s2kparams [10] Req-get-s2kparams, 1170 ... 1171 } 1173 Op-rep ::= CHOICE { 1174 null [0] Rep-null, 1175 change-pw [1] Rep-change-pw, 1176 set-pw [2] Rep-set-pw, 1177 set-keys [3] Rep-set-keys, 1178 gen-keys [4] Req-gen-keys, 1179 get-keys [5] Req-get-keys, 1180 commit-keys [6] Rep-commit-keys, 1181 get-pw-policy [7] Rep-get-pw-policy, 1182 get-princ-aliases [8] Rep-get-princ-aliases, 1183 get-realm-krb5-support [9] Rep-get-realm-krb5-support, 1184 get-s2kparams [10] Rep-get-s2kparams, 1185 ... 1186 } 1188 Op-err ::= CHOICE { 1189 null [0] Err-null, 1190 change-pw [1] Err-change-pw, 1191 set-pw [2] Err-set-pw, 1192 set-keys [3] Err-set-keys, 1193 gen-keys [4] Err-gen-keys, 1194 get-keys [5] Err-get-keys, 1195 commit-keys [6] Err-commit-keys, 1196 get-pw-policy [7] Err-get-pw-policy, 1197 get-princ-aliases [8] Err-get-princ-aliases, 1198 get-realm-krb5-support [9] Err-get-realm-krb5-support, 1199 get-s2kparams [10] Err-get-s2kparams, 1200 ... 1201 } 1203 ProtocolErrorCode ::= ENUM { 1204 proto-format-error, 1205 proto-unsupported-major-version, 1206 proto-unsupported-minor-version, 1207 proto-unsupported-operation, -- Request CHOICE tag unknown 1208 proto-generic-see-op-error, -- See Op-error 1209 proto-wrong-service-principal, -- Use kadmin/setpw 1210 proto-re-authentication-required, 1211 proto-initial-ticket-required, 1212 proto-client-and-target-realm-mismatch, 1213 proto-target-principal-unknown, 1214 proto-authorization-failed, 1216 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1218 proto-dry-run-not-permitted, 1219 ... 1220 } 1222 -- These codes are hints for clients, primarily for when they are 1223 -- used for changing the passwords of automated principals; error 1224 -- replies carry password quality policy help text that is more 1225 -- appropriate for clients to display to users. 1226 PW-Quality-Codes ::= ENUM { 1227 pwq-generic, 1228 pwq-too-soon, 1229 pwq-repeated, 1230 pwq-too-short, 1231 pwq-dictionary-words, 1232 pwq-prohibited-codepoints, 1233 pwq-need-more-char-classes, 1234 ... 1235 } 1237 -- 1238 -- Requests and responses 1239 -- 1241 -- NULL request, much like ONC RPC's NULL procedure - NOT extensible 1242 Req-null ::= NULL 1244 Rep-null ::= NULL 1246 Err-null ::= NULL 1248 -- Change password 1249 Req-change-pw ::= SEQUENCE { 1250 old-pw [0] Password, 1251 new-pw [1] Password OPTIONAL, 1252 commit [2] BOOLEAN DEFAULT TRUE, 1253 etypes [3] SEQUENCE (1..) OF Etype OPTIONAL, 1254 ... 1255 } 1257 Rep-change-pw ::= SEQUENCE { 1258 info-text [0] UTF8String OPTIONAL, 1259 new-pw [1] Password OPTIONAL, 1260 -- generated by the server if present 1261 -- (and requested by the client) 1262 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 1263 ... 1264 } 1266 Err-change-pw ::= SEQUENCE { 1267 help-text [0] UTF8String OPTIONAL, 1268 error [1] CHOICE { 1269 op-generic-error [0] Extensible-NULL, 1270 op-old-pw-incorrect [1] Extensible-NULL, 1272 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1274 op-wont-generate-new-pw [2] Extensible-NULL, 1275 op-new-pw-rejected-generic [3] SEQUENCE { 1276 policy [1] SEQUENCE OF UTF8String, 1277 suggested-pw [2] Password OPTIONAL, 1278 policy-codes [3] SET OF PW-Quality-Codes 1279 OPTIONAL, 1280 ... 1281 } 1282 op-etype-not-supported [4] SEQUENCE { 1283 supported-etypes [1] SEQUENCE OF Etype, 1284 ... 1285 }, 1286 ... 1287 }, 1288 ... 1289 } 1291 -- Set password 1292 Req-set-pw ::= SEQUENCE { 1293 languages [0] SEQUENCE OF Language-Tag OPTIONAL, 1294 new-pw [1] Password OPTIONAL, 1295 commit [2] BOOLEAN DEFAULT TRUE, 1296 etypes [3] SEQUENCE (1..) OF Etype OPTIONAL, 1297 ... 1298 } 1300 Rep-set-pw ::= SEQUENCE { 1301 info-text [0] UTF8String OPTIONAL, 1302 new-pw [1] Password OPTIONAL, 1303 -- generated by the server if present 1304 -- (and requested by the client) 1305 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 1306 ... 1307 } 1309 Err-set-pw ::= Err-change-pw 1311 -- Set keys 1312 Req-set-keys ::= SEQUENCE { 1313 keys [0] SEQUENCE OF Key, 1314 commit [1] BOOLEAN DEFAULT TRUE, 1315 -- TRUE -> install keys now 1316 -- 1317 -- FALSE -> require set-keys-commit 1318 -- before issuing tickets 1319 -- encrypted with these keys. 1320 -- 1321 -- See commit-keys op 1322 isupport [2] KerberosVSupportNego OPTIONAL, 1323 -- For future Kerberos V extensions KDCs 1324 -- may need to know what krb5 version is 1325 -- supported by individual service 1326 -- principals. This field provides a 1328 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1330 -- way to tell the KDC what version of 1331 -- Kerberos V the target principal 1332 -- supports. 1333 ... 1334 } 1336 Rep-set-keys ::= SEQUENCE { 1337 info-text [0] UTF8String OPTIONAL, 1338 kvno [1] UInt32, 1339 aliases [2] SEQUENCE OF SEQUENCE { 1340 name [0] PrincipalName, 1341 realm [1] Realm OPTIONAL, 1342 ... 1343 }, 1344 isupport [3] KerberosVSupportNego OPTIONAL, 1345 ... 1346 -- Should there be ETYPE-INFO2 stuff here? 1347 } 1349 Err-set-keys ::= SEQUENCE { 1350 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1351 error [1] CHOICE { 1352 op-generic [0] Extensible-NULL, 1353 op-deferred-commit-no-support [1] Extensible-NULL, 1354 op-etype-no-support [2] SEQUENCE OF { 1355 supported-etypes [1] SEQUENCE OF Etype, 1356 ... 1357 } 1358 ... 1359 } 1360 } 1362 -- Generate keys 1363 Req-gen-keys ::= SEQUENCE { 1364 etypes [0] SEQUENCE (1..) OF Etype, 1365 entropy [1] OCTET STRING OPTIONAL, 1366 commit [2] BOOLEAN DEFAULT TRUE, 1367 -- TRUE -> install keys now 1368 -- 1369 -- FALSE -> require set-keys-commit 1370 -- before issuing tickets 1371 -- encrypted with these keys. 1372 -- 1373 -- See commit-keys op 1374 isupport [3] KerberosVSupportNego OPTIONAL, 1375 -- For future Kerberos V extensions KDCs 1376 -- may need to know what krb5 version is 1377 -- supported by individual service 1378 -- principals. This field provides a 1379 -- way to tell the KDC what version of 1380 -- Kerberos V the target principal 1381 -- supports. 1382 ... 1384 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1386 } 1388 Rep-gen-keys ::= SEQUENCE { 1389 info-text [0] UTF8String OPTIONAL, 1390 kvno [1] UInt32, 1391 key [2] Key, 1392 aliases [3] SEQUENCE OF SEQUENCE { 1393 name [0] PrincipalName, 1394 realm [1] Realm OPTIONAL, 1395 ... 1396 }, 1397 isupport [4] KerberosVSupportNego OPTIONAL, 1398 ... 1399 -- Should there be ETYPE-INFO2 stuff here? 1400 } 1402 Err-gen-keys ::= Err-set-keys 1404 -- Get un-committed key request 1405 Req-get-keys ::= SEQUENCE { 1406 kvno [0] UInt32, 1407 ... 1408 } 1410 Rep-get-keys ::= SEQUENCE { 1411 info-text [0] UTF8String OPTIONAL, 1412 keys [1] SEQUENCE OF Key, 1413 aliases [2] SEQUENCE OF SEQUENCE { 1414 name [0] PrincipalName, 1415 realm [1] Realm OPTIONAL, 1416 ... 1417 }, 1418 isupport [3] KerberosVSupportNego OPTIONAL, 1419 ... 1420 -- Should there be ETYPE-INFO2 stuff here? 1421 } 1423 Err-get-keys ::= SEQUENCE { 1424 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1425 error [1] CHOICE { 1426 op-generic [0] Extensible-NULL, 1427 op-kvno-committed [1] Extensible-NULL, 1428 op-no-such-kvno [1] Extensible-NULL, 1429 ... 1430 } 1431 } 1433 -- Commit a set keys request 1434 Req-commit-keys ::= SEQUENCE { 1435 kvno [0] UInt32, 1436 ... 1437 } 1439 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1441 Rep-commit-keys ::= Extensible-NULL 1443 Err-commit-keys ::= SEQUENCE { 1444 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1445 error [1] CHOICE { 1446 op-generic [0] Extensible-NULL, 1447 op-kvno-expired [1] Extensible-NULL, 1448 -- The client took too long to respond. 1449 op-kvno-unknown [2] Extensible-NULL, 1450 -- The targ princ/kvno is invalid or unknown to the 1451 -- server (perhaps it lost track of state) 1452 op-new-keys-conflict [3] Extensible-NULL, 1453 -- A new-keys/commit-keys request subsequent to the 1454 -- new-keys that produced the kvno has completed 1455 -- and incremented the principal's kvno 1456 ... 1457 } 1458 ... 1459 } 1461 -- Get password policy 1462 Req-get-pw-policy ::= Extensible-NULL 1464 Rep-get-pw-policy ::= SEQUENCE { 1465 policy-name [0] UTF8String OPTIONAL, 1466 description [1] SEQUENCE OF UTF8String OPTIONAL, 1467 ... 1468 } 1470 Err-get-pw-policy ::= Extensible-NULL 1472 -- Get principal aliases 1473 Req-get-princ-aliases ::= Extensible-NULL 1475 Rep-get-princ-aliases ::= SEQUENCE { 1476 help-text [0] UTF8String OPTIONAL, 1477 aliases [1] SEQUENCE OF SEQUENCE { 1478 name [0] PrincipalName, 1479 realm [1] Realm OPTIONAL, 1480 ... 1481 }, 1482 ... 1483 } 1485 Err-get-princ-aliases ::= Extensible-NULL 1487 -- Get list of enctypes supported by KDC for new keys 1488 Req-get-realm-krb5-support ::= Extensible-NULL 1490 Rep-get-realm-krb5-support ::= SEQUENCE { 1491 isupport [0] KerberosVSupportNego, 1492 -- Version of Kerberos V supported by 1493 -- the target realm. 1495 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1497 ... 1498 } 1500 Err-get-realm-krb5-support ::= Extensible-NULL 1502 -- Get s2kparams 1503 Req-get-s2kparams ::= Extensible-NULL 1505 Rep-get-s2kparams ::= SEQUENCE { 1506 help-text [0] UTF8String OPTIONAL, 1507 s2kparams [1] SEQUENCE OF Etype-Info-Entry, 1508 ... 1509 } 1511 Err-get-s2kparams ::= Extensible-NULL 1513 END 1515 6 IANA Considerations 1517 There are no IANA considerations for this document. 1519 7 Security Considerations 1521 Implementors and site administrators should note that the redundancy 1522 of UTF-8 encodings of passwords varies by language. Password quality 1523 policies SHOULD, therefore, take this into account when estimating 1524 the amount of redundancy and entropy in a proposed new password. [?? 1525 It's late at night - I think this is correct.] 1527 Kerberos set/change password/key protocol major version negotiation 1528 cannot be done securely; a downgrade attack is possible against 1529 clients that attempt to negotiate the protocol major version to use 1530 with a server. It is not clear at this time that the attacker would 1531 gain much from such a downgrade attack other than denial of service 1532 (DoS) by forcing the client to use a protocol version which does not 1533 support some feature needed by the client (Kerberos V in general is 1534 subject to a variety of DoS attacks anyways [RFC1510]). Clients 1535 SHOULD NOT negotiate support for legacy major versions of this 1536 protocol unless configured otherwise. 1538 This protocol does not have Perfect Forward Security (PFS). As a 1539 result, any passive network snooper watching password/key changing 1540 operations who has stolen a principal's password or long-term keys 1541 can find out what the new ones are. 1543 [More text needed?] 1545 8 Acknowledgements 1547 The authors would like to thank Bill GossmanMike Swift, John Brezak, 1548 Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W. 1550 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1552 Nelson, Marcus Watts, Love, Joel N. Weber II, Jeffrey Hutzelman and 1553 other participants from the IETF Kerberos Working Group for their 1554 assistance. 1556 9 References 1558 9.1 Normative References 1560 [RFC2026] 1561 S. Bradner, RFC2026: "The Internet Standard Process - Revision 1562 3," October 1996, Obsoletes - RFC 1602, Status: Best Current 1563 Practice. 1565 [RFC2119] 1566 S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to 1567 Indicate Requirement Levels," March 1997, Status: Best Current 1568 Practice. 1570 [X680] 1571 Abstract Syntax Notation One (ASN.1): Specification of Basic 1572 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC 1573 International Standard 8824-1:1998. 1574 http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf 1576 [X690] 1577 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), 1578 Canonical Encoding Rules (CER) and Distinguished Encoding Rules 1579 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International 1580 Standard 8825-1:1998. 1581 http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf 1583 [clarifications] 1584 RFC-Editor: To be replaced by RFC number for 1585 draft-ietf-krb-wg-kerberos-clarifications. 1587 [RFC3066] 1588 H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of 1589 Languages," January 2001, Obsoletes RFC1766, Status: Best Current 1590 Practice. 1592 9.2 Informative References 1594 [RFC3244] 1595 M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000 1596 Kerberos Change Password and Set Password Protocols," February 1597 2002, Status: Informational. 1599 10 Authors' Addresses 1601 Nicolas Williams 1602 Sun Microsystems 1603 5300 Riata Trace Ct 1604 Austin, TX 78727 1606 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1608 Email: nicolas.williams@sun.com 1610 11 Notes to the RFC Editor 1612 This document has two KRB WG drafts as normative references and 1613 cannot progress until those drafts progress, but no other draft 1614 depends on this one. 1616 12 Change History 1618 -01 -> -02 1620 - Removed Bill Gossman, Mike Swift and John Brezak as authors. 1622 - Removed UDP as a transport for this protocol. 1624 - Replaced redundant copies of framing ASCII art with reference to 1625 RFC3244. 1627 - Made all name/password strings UTF8String with an extensible 1628 constraint to IA5String. 1630 - Added a method for doing dry runs of operations. This is helpful 1631 in testing passwords against password quality policies. 1633 - Added an operation for retrieving a principal's current and 1634 preferred string-to-key parameters, and a way to change them 1635 without changing the principal's password. 1637 - Added password quality codes as hints for smart clients, but 1638 these are optional and not to be used instead of messages to be 1639 displayed to useds. 1641 - Added a 'commit' option to change-pw and set-pw (as requested by 1642 Larry). 1644 - Removed "version" field of the Kerberos V feature negotiation 1645 struture. 1647 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1649 Intellectual Property Statement 1651 The IETF takes no position regarding the validity or scope of any 1652 Intellectual Property Rights or other rights that might be claimed to 1653 pertain to the implementation or use of the technology described in 1654 this document or the extent to which any license under such rights 1655 might or might not be available; nor does it represent that it has 1656 made any independent effort to identify any such rights. Information 1657 on the procedures with respect to rights in RFC documents can be 1658 found in BCP 78 and BCP 79. 1660 Copies of IPR disclosures made to the IETF Secretariat and any 1661 assurances of licenses to be made available, or the result of an 1662 attempt made to obtain a general license or permission for the use of 1663 such proprietary rights by implementers or users of this 1664 specification can be obtained from the IETF on-line IPR repository at 1665 http://www.ietf.org/ipr. 1667 The IETF invites any interested party to bring to its attention any 1668 copyrights, patents or patent applications, or other proprietary 1669 rights that may cover technology that may be required to implement 1670 this standard. Please address the information to the IETF at 1671 ietf-ipr@ietf.org. 1673 Disclaimer of Validity 1675 This document and the information contained herein are provided on an 1676 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1677 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1678 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1679 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1680 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1681 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1683 Copyright Statement 1685 Copyright (C) The Internet Society (2005). This document is subject 1686 to the rights, licenses and restrictions contained in BCP 78, and 1687 except as set forth therein, the authors retain all their rights. 1689 Acknowledgment 1691 Funding for the RFC Editor function is currently provided by the 1692 Internet Society.