idnits 2.17.1 draft-ietf-krb-wg-kerberos-set-passwd-02.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1660. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1676), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** 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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 31) being 60 lines 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1518, 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 1491 -- Looks like a reference, but probably isn't: '0' on line 1490 -- Looks like a reference, but probably isn't: '2' on line 1433 == Missing Reference: 'APPLICATION 0' is mentioned on line 1115, but not defined -- Looks like a reference, but probably isn't: '3' on line 1436 -- Looks like a reference, but probably isn't: '4' on line 1382 -- Looks like a reference, but probably isn't: '5' on line 1182 == Missing Reference: 'APPLICATION 1' is mentioned on line 1128, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 1135, but not defined -- Looks like a reference, but probably isn't: '6' on line 1183 -- Looks like a reference, but probably isn't: '7' on line 1184 -- Looks like a reference, but probably isn't: '8' on line 1185 -- Looks like a reference, but probably isn't: '9' on line 1186 -- Looks like a reference, but probably isn't: '10' on line 1187 == Unused Reference: 'RFC2026' is defined on line 1544, 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 Category: Standards Track Jonathan Trostle 4 Cisco Systems 6 Kerberos Set/Change Password: Version 2 7 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 12, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document specifies an extensible protocol for setting keys and 41 changing the passwords of Kerberos V principals. 43 Table of Contents 45 1 Introduction 46 2 The Protocol 47 2.1 Transports 48 2.2 Protocol Framing 49 2.3 Protocol version negotiation 50 2.3.1 Protocol Major Version Negotiation 51 2.3.2 Protocol Minor Version Negotiation 52 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 162 DRAFT Kerberos Set/Change Password v2 Expires January 2005 164 introduces a notion of protocol minor versions for use in negotiating 165 protocol extensions. As of this time only one minor version is 166 defined for major version 2: minor version 0, defined herein. 168 2.3.1 Protocol Major Version Negotiation 170 Version 2 clients that also support other versions, such as 0xff80, 171 as in [RFC3244], SHOULD attempt to use version 2 of the protocol 172 first. 174 Servers which do not support version 2 of this protocol typically 175 include their preferred version number in the reply and/or may 176 include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a 177 status code of KRB5_KPASSWD_MALFORMED. 179 Note that some [RFC3244] server implementations close the TCP 180 connection without returning any other response. Note also that 181 there is no integrity protection for the major version number in the 182 protocol framing or for any data in a KRB-ERROR. 184 As a result change password protocol major version negotiation is 185 subject to downgrade attacks. Therefore major version negotiation is 186 NOT RECOMMENDED. 188 Where the server indicates that it does not support version 2, the 189 client MAY, but SHOULD NOT, unless configured to do so, fall back on 190 another major version of this protocol. 192 Version 2 servers MAY respond to non-v2 requests using whatever 193 response is appropriate for the versions used by the clients, but if 194 a server does not do this or know how to do this then it MUST respond 195 with an error framed as in section 2.2, using an AP-REP and KRB-PRIV 196 if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and 197 using a ProtocolErrorCode value of unsupported-major-version. 199 It is expected that implementations of as yet unspecified future 200 major versions of this protocol will be required to support version 2 201 integrity protected error replies for properly indicating no support 202 for version 2 of the protocl. We also hope that no further major 203 versions of this protocol will be needed. 205 2.3.2 Protocol Minor Version Negotiation 207 Version 2 clients are free to use whatever protocol minor version and 208 message extensions are available to them in their initial messages to 209 version 2 servers, provided that the minor versions (other than 0) 210 have been defined through IETF documents. 212 Version 2 servers MUST answer with the highest protocol minor version 213 number supported by the server and the client. 215 Version 2 clients MUST use the protocol minor version used in a 216 server's reply for any subsequent messages in the same TCP session. 218 DRAFT Kerberos Set/Change Password v2 Expires January 2005 220 See section 2.7 for further description of the protocol's 221 extensibility and its relation to protocol minor versions and the 222 negotiation thereof. 224 2.4 Use of Kerberos V and Key Exchange 226 This protocol makes use of messages defined in [RFC1510] and 227 [clarifications]. Specifically, AP-REQ, AP-REP, KRB-ERROR and 228 KRB-PRIV. 230 All operations are to be performed by the server on behalf of the 231 client principal. 233 Clients SHOULD use "kadmin/setpw" as the principal name of the server 234 for all requests except when changing the client principal's own 235 expired password, for which they should use "kadmin/changepw". The 236 "kadmin/changepw" service exists to allow KDCs to limit principals 237 with expired passwords to getting initial tickets to the password 238 changing service only and only for changing expired passwords. 240 Servers MUST limit clients that used the "kadmin/changepw" service 241 principal name to changing the password of the client principal. 243 The client MUST request mutual authentication and the client MUST 244 MUST request the use of sequence numbers. 246 Clients SHOULD use INITIAL tickets for requests whose target 247 principal is the client's principal. Servers SHOULD force the use of 248 INITIAL tickets for such requests and MAY force the use of INITIAL 249 for all others - see section 3.2. 251 Servers MUST specify a sub-session key. 253 The encrypted part of KRB-PRIVs MUST be encrypted with the server's 254 sub-session key and key usage 20 (client->server) or 21 255 (server->client). 257 After each new AP exchange the client and server MUST destroy the 258 session keys, if any, resulting from the previous AP exchange. 260 2.5 Use of ASN.1 262 This protocol's messages are defined in ASN.1, using only features 263 from [X680]. All ASN.1 types defined herein are to be encoded in 264 DER [X690]. A complete ASN.1 module is given in section 4. 266 The DER encoding of the ASN.1 PDUs are exchanged wrapped in a 267 KRB-PRIV as described above and/or as e-data in KRB-ERROR messages. 269 2.6 Internationalization 271 This protocol's request PDU carries an optional field indicating the 272 DRAFT Kerberos Set/Change Password v2 Expires January 2005 274 languages spoken by the client user; the client SHOULD send its list 275 of spoken languages to the server (once per-TCP session). 277 The server SHOULD localize all strings intended for display to users 278 to a language in common with the languages spoken by the client user. 280 Strings for Kerberos principal and realm names used in this protocol 281 are be constrained as per [clarifications]. 283 2.6.1 Normalization Forms for UTF-8 Strings 285 Because Kerberos V [clarifications] restricts principal names, realm 286 names and passwords to IA5String, this protocol uses UTF8String with 287 an extensible constraint to IA5String. 289 Future versions of Kerberos may relax this constraint; if so then a 290 minor version of this protocol should relax this constraint 291 accordingly. 293 2.6.2 Language Negotiation 295 The server MUST pick a language from the client's input list or 296 the default language tag (see [RFC3066]) for text in its responses 297 which is meant for the user to read. 299 The server SHOULD use a language selection algorithm such that 300 consideration is first given to exact matches between the client's 301 spoken languages and the server's available locales, followed by 302 "fuzzy" matches where only the first sub-tags of the client's 303 language tag list are used for matching against the servers available 304 locales. 306 Servers MUST cache the optional language tag lists from prior 307 requests for use with subsequent requests that exclude the language 308 tag list. Clients MAY expect such server behaviour and send the 309 language tag lists only once per-TCP session. Clients SHOULD send 310 the server the language tag list at least once. 312 When the server has a message catalog for one of the client's spoken 313 languages the server SHOULD localize any text strings intended for 314 display to users. 316 2.7 Protocol Extensibility 318 The protocol is defined in ASN.1 and uses extensibility markers 319 throughout. As such, the module presented herein can be extended 320 within the framework of [X680]. 322 Typed holes are not used in this protocol as it is very simple and 323 does not require the ability to deal with abstract data types defined 324 in different layers. For this reason, the only way to extend this 325 protocol is by extending the ASN.1 module within the framework of the 326 IETF; all future extensions to this protocol have to be defined in 327 DRAFT Kerberos Set/Change Password v2 Expires January 2005 329 IETF documents unless otherwise specified in a future IETF revision 330 of this protocol. 332 A protocol minor version number is used to negotiate use of 333 extensions. See section 2.3.2 for the minor version negotiation. 335 Servers SHOULD ignore unknown additions to the ASN.1 types, in 336 initial requests, where the syntax allows them, except for extensions 337 to the "Op-req" type, which MUST result in an error. 339 Servers MUST respond with an error (ProtocolErrorCode value of 340 unsupported-minor-version) to clients that use operations unknown to 341 the server. 343 2.8 Protocol Subsets 345 The structure of the protocol is such that the ASN.1 syntaxes for the 346 various operations supported by the protocol are independent of the 347 each other. Client and server implementations MAY implement subsets 348 of the overall protocol by removing some alternatives to the Op-req, 349 Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4. 351 For example, it should be possible to have a password-change only 352 client that cannot set principal's keys - and vice versa. 354 3 Protocol Elements 356 The protocol as defined herein supports the following operations 357 relating to the management of Kerberos principal's passwords or keys: 359 [NOTE: New since last version of this I-D.] 360 - get principal's current and preferred string-to-key parameters 362 - change password (or enctypes and string-to-key parameters) 363 - set password (administrative) 364 - set new keys 365 - generate new keys 366 - get new, un-committed keys 367 - commit new keys 368 - get password policy name and/or description of principal 369 - list aliases of a principal 370 - list enctypes and version of Kerberos V supported by realm 372 The operation for retrieving a list of aliases of a principal is 373 needed where KDCs implement aliasing of principal names and allows 374 clients to properly setup their key databases when principal aliasing 375 is in use. 377 Operations such as creation or deletion of principals are outside the 378 scope of this document, and should be performed via other means, such 379 as through directories or other Kerberos administration protocols. 381 The individual operations are described in section 3.2. 383 DRAFT Kerberos Set/Change Password v2 Expires January 2005 385 3.1 PDUs 387 The types "Request," "Response" and "Error-Response" are the ASN.1 388 module's PDUs. 390 The "Request" and "Response" PDUs are always to be sent wrapped in 391 KRB-PRIV messages, except for the "Error-Response" PDU which MUST be 392 sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail, 393 otherwise it MUST be sent wrapped in a KRB-PRIV. 395 The ASN.1 syntax for the PDUs is given in section 4. 397 Note that the first field of each PDU is the major version of the 398 protocol, defaulted to 2, meaning that it is never included in 399 version 2 exchanges. Similarly, the second field of each PDU is the 400 minor version, defaulted to 0. 402 The request, responses and error PDUs consist of an outer structure 403 ("Request," "Response" and "Error-Response") containing fields common 404 to all requests, responses and errors, respectively, and an inner 405 structure for fields that are specific to each operation's 406 requests/responses. The inner structure is optional in the case of 407 the Error-Response PDU and need not be included when generic errors 408 occur for which there is a suitable ProtocolErrorCode. 410 Specifically, the outer Request structure has a field for passing a 411 client user's spoken (read) languages to the server. It also has two 412 optional fields for identifying the requested operation's target 413 principal's name and realm (if not sent then the server MUST use the 414 client's principal name and realm as the target). A boolean field 415 for indicating whether or not the request should be dry-run is also 416 included; dry-runs can be used to test server policies, and servers 417 MUST NOT modify any principals when processing dry-run requests. 419 The Response and Error PDUs' outer structures include a field 420 indicating the language that the server has chosen for localization 421 of text intended to be displayed to users; this field is defaulted to 422 "i-default". This language tag applies to all UTF8 strings in the 423 inner structure (Op-rep and Op-err) that are meant to be displayed to 424 users. 426 The protocol error codes are: 428 - proto-generic-error 430 An operation-specific error ocurred, see the inner Op-error. 432 - proto-format-error 433 - proto-unsupported-major-version 434 - proto-unsupported-minor-version 435 - proto-unsupported-operation 436 DRAFT Kerberos Set/Change Password v2 Expires January 2005 438 - proto-wrong-service-principal 440 Use kadmin/setpw for the server's principal name. 442 - proto-re-authentication-required 444 The server demands that the client re-authenticate through a new 445 AP exchange. 447 - proto-initial-ticket-required 449 Use of an INITIAL ticket is required for the requested 450 operation. 452 - proto-client-and-target-realm-mismatch 454 The server requires that the client's principal name and the 455 target principal of the operation share the same realm name. 457 - proto-target-principal-unknown 458 - proto-authorization-failed 460 3.2 Operations 462 This section describes the semantics of each operation request and 463 response defined in the ASN.1 module in section 4. 465 3.2.1 Null 467 NAME 469 null - Null or "ping" operation 471 DESCRIPTION 473 The null request is intended for use with TCP; its purpose is 474 similar to RPC null procedures and is akin to a "ping" operation. 476 ERRORS 478 None. 480 3.2.2 Change Kerberos Password 482 NAME 484 change-pw - Change password operation 486 SYNOPSIS 488 Req-change-pw(old-pw, [languages], [new-pw], 489 [commit], [etypes]) -> 490 Rep-change-pw([info-text], [new-pw], [etypes]) | 491 DRAFT Kerberos Set/Change Password v2 Expires January 2005 493 Err-change-pw([help-text], error code, [error info]) 495 DESCRIPTION 497 Change a principal's password. 499 The change password request has one required, three optional and 500 one defaulted arguments: "old-pw" (required), "languages," 501 "new-pw", "commit" (defaults to "TRUE") and "etypes", 502 corresponding to the target principal's old password, its 503 preferred languages, its new password, a boolean indicating 504 whether or not to make the new long-term key available for 505 immediate use, and the desired enctypes for the new long-term 506 keys. 508 The server MUST validate the old password and MUST check the 509 quality of the new password, if sent, according the password 510 quality policy associated with the target principal. 512 If the old and new passwords in the request are the same strings, 513 and the principal is not currently required to change its 514 password, then the server MAY permit the password change as way to 515 change a principal's enctypes and string-to-key parameters. This 516 feature provides a way to, for example, add enctypes to a 517 principals' password-derived long-term keys without forcing a 518 password change following an upgrade to the KDC that adds support 519 for new enctypes. 521 A client MAY request that the server generate a new password by 522 excluding the new password from its request, in which case the 523 server MUST either generate a new password or respond with an 524 error indicating that it does not support this feature. 526 Server-generated passwords MUST meet the target principal's 527 password quality policy. It is RECOMMENDED that server-generated 528 passwords be user-friendly, that is, memorable and that the target 529 principal's preferred languages be taken into account by the 530 password generation alogrithm used by the server. 532 Uncommitted password changes are commited using the commit-keys 533 operation. 535 RETURN 537 Upon successful password changes the server responds with a 538 Rep-change-pw. The fields of Rep-change-pw are all optional and 539 include: 541 - 'info-text' which the server can use to send a message to the 542 user such as "Your new password will expire in 90 days," for 543 example. 545 - 'new-pw' which the server MUST include if the client 546 DRAFT Kerberos Set/Change Password v2 Expires January 2005 548 requested that the server generate a new password; generated 549 passwords MUST pass the target principal's password quality 550 policy. 552 - 'etypes' which the server MAY include to indicate which types 553 of long-term keys it created for the target principal and 554 which the server MUST include if the client specified a set 555 of enctypes in its request. 557 ERRORS 559 The server may respond to change password requests with protocol 560 or operation errors. See section 3.1 for a description of 561 protocol error codes. 563 All operation errors include an optional 'help-text' field by 564 which the server can describe the error in a human-readable, 565 localizaed string. 567 Change password error codes include: 569 - generic-error 571 - old-pw-incorrect 573 - wont-generate-new-pw 575 The server will not generate a new password for this 576 principal or does not support password generation in general. 578 - new-pw-rejected-generic 580 The client's proposed new password failed the target 581 principal's password quality policy. 583 The server MUST include a description of the password quality 584 policy or aspect of it that the client's proposed new 585 password failed to meet. 587 The server MAY generate and send a new password that the 588 client can then use as a new password and which is guaranteed 589 to pass the target principal's current password quality 590 policy. 592 The server MAY include a set of policy error code hints. 594 - etype-not-supported 596 The client requested an enctype that the KDC does not 597 support. 599 3.2.3 Set Kerberos Password 600 DRAFT Kerberos Set/Change Password v2 Expires January 2005 602 NAME 604 set-pw - Set password operation 606 SYNOPSIS 608 Req-set-pw([languages], [new-pw], [commit], [etypes]) -> 609 Rep-set-pw([info-text], [new-pw], [etypes]) | 610 Err-set-pw([help-text], error code, [error info]) 612 DESCRIPTION 614 Administratively set a principal's password. 616 The set password request has three optional and one defaulted 617 arguments: "languages", "new-pw," "commit" (defaulted to "TRUE") 618 and "etypes", corresponding to the target principal's preferred 619 languages, new password, a boolean indicating whether or not to 620 make the new long-term key available for immediate use, and the 621 desired enctypes for the new long-term keys. 623 The server MUST check the quality of the new password, if sent, 624 according the password quality policy associated with the target 625 principal. 627 The server SHOULD require that the client use the change-pw 628 operation instead of set-pw when the client principal and the 629 target principal are the same. 631 A client MAY request that the server generate a new password by 632 excluding the new password from its request, in which case the 633 server MUST either generate a new password or respond with an 634 error indicating that it does not support this feature. 636 Server-generated passwords MUST meet the target principal's 637 password quality policy. It is RECOMMENDED that server-generated 638 passwords be user-friendly, that is, memorable and that the target 639 principal's preferred languages be taken into account by the 640 password generation alogrithm used by the server. 642 RETURN 644 Upon successfully setting a password the server responds with a 645 Rep-set-pw. The fields of Rep-set-pw are all optional and 646 include: 648 - 'info-text' which the server can use to send a message to the 649 user such as "Your new password will expire in 90 days," for 650 example. 652 - 'new-pw' which the server MUST include if the client 653 requested that the server generate a new password; generated 654 passwords MUST pass the target principal's password quality 655 DRAFT Kerberos Set/Change Password v2 Expires January 2005 657 policy. 659 - 'etypes' which the server MAY include to indicate which types 660 of long-term keys it created for the target principal and 661 which the server MUST include if the client specified a set 662 of enctypes in its request. 664 ERRORS 666 The server may respond to set password requests with protocol or 667 operation errors. See section XYZ for a description of protocol 668 error codes. 670 All operation errors include an optional 'help-text' field by 671 which the server can describe the error in a human-readable, 672 localizaed string. 674 Set password error codes include: 676 - generic-error 678 - use-change-pw 680 The server demands that the client use the change-pw 681 operation for the target principal of the set-pw request. 683 - wont-generate-new-pw 685 The server will not generate a new password for this 686 principal or does not support password generation in general. 688 - new-pw-rejected-generic 690 The client's proposed new password failed the target 691 principal's password quality policy. 693 The server MUST include a description of the password quality 694 policy or aspect of it that the client's proposed new 695 password failed to meet. 697 The server MAY generate and send a new password that the 698 client can then use as a new password and which is guaranteed 699 to pass the target principal's current password quality 700 policy. 702 The server MAY include a set of policy error code hints. 704 - etype-not-supported 706 The client requested an enctype that the KDC does not 707 support. 709 3.2.4 Set Kerberos Keys 710 DRAFT Kerberos Set/Change Password v2 Expires January 2005 712 NAME 714 set-keys 716 SYNOPSIS 718 Req-set-keys(new-keys, commit?, [isupport]) -> 719 Rep-set-keys([info-text], kvno, aliases, [isupport]) 721 DESCRIPTION 723 The set-keys request consists of two required fields and one 724 optional field: "new-keys", "commit" (a boolean field - see below) 725 and "isupport", an optional field for indicating to the KDC what 726 Kerberos V features are supported by the target principal. 728 When "commit" is true the KDC makes the new keys available for 729 issueing tickets encrypted in them immediately. Otherwise the 730 client MUST follow up with a commit-keys request to make the keys 731 available. This feature is useful for changing keys shared by 732 multiple hosts, in clustered services, for example, in an atomic 733 manner; see section 3.2.6 and 3.2.7. 735 If a principal has keys are awaiting commitment when a new 736 set-keys request for that principal s made then the KDC MUST 737 overwrite the deferred keys. 739 RETURN 741 For successful set-keys operations the server returns: 743 - Informational text, optional. 745 - The new kvno for the target principal. 747 - A list of aliases of the target principal known to the KDC 748 (optional). 750 - The set of Kerberos V features supported by the KDC 751 (optional). 753 ERRORS 755 The server may respond with the following errors: 757 - generic 758 - deferred-commit-no-support 759 - etype-no-support 761 3.2.5 Generate Kerberos Keys 763 NAME 764 DRAFT Kerberos Set/Change Password v2 Expires January 2005 766 gen-keys 768 SYNOPSIS 770 Req-gen-keys(etypes, [entropy], commit?, [isupport]) -> 771 Rep-set-keys([info-text], key, kvno, aliases, [isupport]) 773 DESCRIPTION 775 The gen-keys is similar to the set-keys request (see section 776 3.2.4) but differs in that the server generates keys of 777 client-requested enctypes, rather than the client providing 778 specific keys. 780 The gen-keys request consists of two required fields and two 781 optional fields: "etypes" (the enctypes of the new keys), 782 "entropy", "commit" and "isupport" (see section 3.2.4). 784 If a principal has keys are awaiting commitment when a new 785 set-keys request for that principal s made then the KDC MUST 786 overwrite the deferred keys. 788 RETURN 790 For successful set-keys operations the server returns: 792 - Informational text, optional. 794 - The new kvno for the target principal. 796 - The new key (only one is needed). 798 - A list of aliases of the target principal known to the KDC 799 (optional). 801 - The set of Kerberos V features supported by the KDC 802 (optional). 804 ERRORS 806 The server may respond with the following errors: 808 - generic 809 - deferred-commit-no-support 810 - etype-no-support 812 3.2.6 Get New Keys 814 NAME 816 get-keys 817 DRAFT Kerberos Set/Change Password v2 Expires January 2005 819 SYNOPSIS 821 Req-get-keys(kvno) -> 822 Rep-get-keys([info-text], keys, aliases, [isupport]) | 823 Err-get-keys([help-text], error code, [error info]) 825 DESCRIPTION 827 This request allows a client to get the keys set or generated in a 828 previous set-keys or gen-keys request with deferred commitment.. 830 RETURN 832 If the target principal and kvno correspond to uncommitted keys 833 the server MUST respond with the actual keys that would be set by 834 a subsequent commit-keys request. Otherwise the server MUST 835 respond with an error (meaning that this operation cannot be used 836 to extract keys from the KDC that may be in use). 838 ERRORS 840 - generic 841 - kvno-committed 842 - no-such-kvno 844 3.2.7 Commit New Keys 846 NAME 848 commit-keys 850 SYNOPSIS 852 Req-commit-keys(kvno) -> 853 Rep-commit-keys() | 854 Err-commit-keys([help-text], error code, [error info]) 856 DESCRIPTION 858 The commit-keys operation allows a client to bring a principal's 859 new keys into use at the KDC. 861 Clients should make a commit-keys request corresponding to a 862 deferred commitment set-keys/gen-keys operation as soon as the 863 local key database for the target principal is updated. 865 The target principal name and the kvno MUST match those from a 866 prior set-keys or gen-keys operation. 868 Servers MAY expire delayed key commitments at will. Servers 869 SHOULD expire uncommitted new keys after a reasonable amount of 870 time (600 seconds is RECOMMENDED). 872 DRAFT Kerberos Set/Change Password v2 Expires January 2005 874 Servers MUST respond to new set-keys requests for principals with 875 pending, uncommitted new keys by expiring the uncommitted new keys 876 and proceeding as if there had been no expired new keys. 878 ERRORS 880 - generic 881 - op-kvno-expired 882 - op-kvno-unknown 883 - new-keys-conflict (A set-keys or gen-keys request succeeded 884 subsequent to the request that matches this 885 {principal, kvno} tuple.) 887 3.2.8 Get Password Quality Policy 889 NAME 891 get-pw-policy 893 SYNOPSIS 895 Req-get-pw-policy() -> 896 Rep-get-pw-policy([policy name], [policy description]) 898 DESCRIPTION 900 Returns a description of the target principal's associated 901 password quality policy, if any, as a list of localized 902 UTF8String values. 904 Clients can use this operation in conjunction with the change-pw 905 operation to obtain text that can be displayed to the user before 906 the user actually enters a new password. 908 It is common for sites to set policies with respect to password 909 quality. It is beyond the scope of this document to describe such 910 policies. Management of password quality policies' actual content 911 is also beyond the scope of this protocol. 913 ERRORS 915 No operation errors are defined. 917 3.2.9 Get Principal Aliases 919 NAME 921 get-print-aliases 923 SYNOPSIS 925 Req-get-princ-aliases() -> 926 DRAFT Kerberos Set/Change Password v2 Expires January 2005 928 Rep-get-princ-aliases(aliases) 930 DESCRIPTION 932 Returns a list of aliases of the target principal. 934 ERRORS 936 No operation-specific errors. 938 3.2.10 Get Realm's Supported Kerberos V Version and Features 940 NAME 942 get-realm-krb5-support 944 SYNOPSIS 946 Req-get-realm-krb5-support() -> 947 Rep-get-realm-krb5-support(isupport) 949 DESCRIPTION 951 Returns set of Kerberos V features support by the target 952 principal's realm's KDCs. 954 ERRORS 956 No operation-specific errors. 958 3.2.11 Retrieve Principal's S2K Params and Preferred Params 960 NAME 962 get-s2kparams 964 SYNOPSIS 966 Req-get-s2kparams() -> 967 Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams]) 969 DESCRIPTION 971 Returns the string2key parameters for the principal's current 972 password-derived long-term keys, if any, and the parameters that 973 the realm would prefer, if they differ from the former. 975 This operation is intended for use with the change-pw() operation. 976 When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if 977 the principal's long-term secret keys' string2key parameters (and 978 enctype list) should be changed and, if so, change them. 980 If the 'princ-s2kparams' return value is missing then the 981 DRAFT Kerberos Set/Change Password v2 Expires January 2005 983 principal does not have a password-derived long-term key. 985 The 'preferred-s2kparams' MUST be excluded if the principal's 986 string2key parameters satisfy the realm's policy. 988 ERRORS 990 No operation-specific errors. 992 3.3 Principal Aliases 994 Applications that use Kerberos often have to derive acceptor 995 principal names from hostnames entered by users. Such hostnames may 996 be aliases, they may be fully qualified, partially qualified or not 997 qualified at all. Some implementations have resorted to deriving 998 principal names from such hostnames by utilizing the names services 999 to canonicalize the hostname first; such practices are not secure 1000 unless the name service are secure, which often aren't. 1002 One method for securely deriving principal names from hostnames is to 1003 alias principals at the KDC such that the KDC will issue tickets for 1004 principal names which are aliases of others. It is helpful for 1005 principals to know what are their aliases as known by the KDCs. 1007 Note that changing a principal's aliases is out of scope for this 1008 protocol. 1010 3.4 Kerberos V Feature Negotiation 1012 Principals and realms' KDCs may need to know about additional 1013 Kerberos V features and extensions that they each support. Several 1014 operations (see above) provide a way for clients and servers to 1015 exchange such infomration, in the form of lists of types supported 1016 for the various typed holes used in Kerberos V. 1018 4 ASN.1 Module 1020 DEFINITIONS EXPLICIT TAGS ::= BEGIN 1021 -- 1022 -- Note: EXPLICIT tagging is in use by default throughout this 1023 -- module. 1025 -- From [clarifications] with modifications 1026 PrincipalName ::= SEQUENCE { 1027 name-string [1] SEQUENCE OF UTF8String (IA5String, ...) 1028 } 1029 Realm ::= UTF8String (IA5String, ...) 1030 Salt ::= UTF8String (IA5String, ...) 1031 Password ::= UTF8String (IA5String, ...) 1033 -- NOTE WELL: Principal and realm names MUST be constrained by the 1034 -- specification of the version of Kerberos V used by the 1035 -- client. 1037 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1039 -- 1040 -- [Perhaps PrincipalName should be a SEQUENCE of an optional name 1041 -- type and a UTF8String, for simplicity.] 1043 -- From [clarifications] 1044 Int32 ::= INTEGER (-2147483648..2147483647) 1045 UInt32 ::= INTEGER (0..4294967295) 1047 -- Based on [clarifications] 1048 Etype ::= Int32 1049 Etype-Info-Entry ::= SEQUENCE { 1050 etype [0] Etype, 1051 salt [1] Salt OPTIONAL, 1052 s2kparams [2] OCTET STRING OPTIONAL, 1053 ... 1054 } 1055 Key ::= SEQUENCE { 1056 enc-type [0] Etype, -- from Kerberos 1057 key [1] OCTET STRING, 1058 ... 1059 } 1061 Language-Tag ::= UTF8String -- Constrained by [RFC3066] 1063 -- Empty, extensible SEQUENCEs are legal ASN.1 1064 Extensible-NULL ::= SEQUENCE { 1065 ... 1066 } 1068 -- Kerberos clients negotiate some parameters relating to their peers 1069 -- indirectly through the KDC. Today this is true of ticket session 1070 -- key enctypes, but in the future this indirect negotiation may also 1071 -- occur with respect to the minor version of Kerberos V to be used 1072 -- between clients and servers. Additionally, KDCs may need to know 1073 -- what authorization-data types are supported by service principals, 1074 -- both, for compatibility with legacy software and for optimization. 1075 -- 1076 -- Thesefore it is important for KDCs to know what features of 1077 -- Kerberos V each service principal supports. 1078 -- 1079 -- In version 2.0 of this protocol the clients and servers may notify 1080 -- each other of their support for: 1081 -- 1082 -- - enctypes 1083 -- - authorization data types 1084 -- - transited encoding data types 1085 -- 1086 -- All authorization-data types defined in [clarifications] are 1087 -- assumed to be supported if the minor version is 1 and do not need 1088 -- to be included in the ad-type list. 1089 -- 1090 -- Int32 is used for enctype and transited encoding data type 1091 -- identifiers. 1093 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1095 -- 1096 -- An extensible CHOICE of Int32 is used for authorization data 1097 -- types. 1099 KerberosV-TR-ID ::= Int32 1101 KerberosV-AD-ID ::= CHOICE { 1102 ad-int [0] Int32, 1103 ... 1104 } 1106 KerberosVSupportNego ::= SEQUENCE { 1107 enc-types [0] SEQUENCE OF Etype, 1108 ad-types [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL, 1109 -- authorization data types 1110 tr-enc-types [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL, 1111 -- transited encoding types 1112 ... 1113 } 1115 Request ::= [APPLICATION 0] SEQUENCE { 1116 pvno-minor [0] INTEGER DEFAULT 0, 1117 languages [1] SEQUENCE OF Language-Tag OPTIONAL, 1118 -- Should be defaulted to the SEQUENCE of "i-default" 1119 targ-name [2] PrincipalName OPTIONAL, 1120 targ-realm [3] Realm OPTIONAL, 1121 -- If targ-name/realm are missing then the request 1122 -- applies to the principal of the client 1123 dry-run [4] BOOLEAN DEFAULT FALSE, 1124 operation [5] Op-req, 1125 ... 1126 } 1128 Response ::= [APPLICATION 1] SEQUENCE { 1129 pvno-minor [0] INTEGER DEFAULT 0, 1130 language [1] Language-Tag DEFAULT "i-default", 1131 result [2] Op-rep, 1132 ... 1133 } 1135 Error-Response ::= [APPLICATION 2] SEQUENCE { 1136 pvno-minor [0] INTEGER DEFAULT 0, 1137 language [1] Language-Tag DEFAULT "i-default", 1138 error-code [2] ProtocolErrorCode, 1139 help-text [3] UTF8String OPTIONAL, 1140 op-error [4] Op-err OPTIONAL, 1141 ... 1142 } 1144 Op-req ::= CHOICE { 1145 null [0] Req-null, 1146 change-pw [1] Req-change-pw, 1147 set-pw [2] Req-set-pw, 1148 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1150 set-keys [3] Req-set-keys, 1151 gen-keys [4] Req-gen-keys, 1152 get-keys [5] Req-get-keys, 1153 commit-keys [6] Req-commit-keys, 1154 get-pw-policy [7] Req-get-pw-policy, 1155 get-princ-aliases [8] Req-get-princ-aliases, 1156 get-realm-krb5-support [9] Req-get-realm-krb5-support, 1157 get-s2kparams [10] Req-get-s2kparams, 1158 ... 1159 } 1161 Op-rep ::= CHOICE { 1162 null [0] Rep-null, 1163 change-pw [1] Rep-change-pw, 1164 set-pw [2] Rep-set-pw, 1165 set-keys [3] Rep-set-keys, 1166 gen-keys [4] Req-gen-keys, 1167 get-keys [5] Req-get-keys, 1168 commit-keys [6] Rep-commit-keys, 1169 get-pw-policy [7] Rep-get-pw-policy, 1170 get-princ-aliases [8] Rep-get-princ-aliases, 1171 get-realm-krb5-support [9] Rep-get-realm-krb5-support, 1172 get-s2kparams [10] Rep-get-s2kparams, 1173 ... 1174 } 1176 Op-err ::= CHOICE { 1177 null [0] Err-null, 1178 change-pw [1] Err-change-pw, 1179 set-pw [2] Err-set-pw, 1180 set-keys [3] Err-set-keys, 1181 gen-keys [4] Err-gen-keys, 1182 get-keys [5] Err-get-keys, 1183 commit-keys [6] Err-commit-keys, 1184 get-pw-policy [7] Err-get-pw-policy, 1185 get-princ-aliases [8] Err-get-princ-aliases, 1186 get-realm-krb5-support [9] Err-get-realm-krb5-support, 1187 get-s2kparams [10] Err-get-s2kparams, 1188 ... 1189 } 1191 ProtocolErrorCode ::= ENUM { 1192 proto-format-error, 1193 proto-unsupported-major-version, 1194 proto-unsupported-minor-version, 1195 proto-unsupported-operation, -- Request CHOICE tag unknown 1196 proto-generic-see-op-error, -- See Op-error 1197 proto-wrong-service-principal, -- Use kadmin/setpw 1198 proto-re-authentication-required, 1199 proto-initial-ticket-required, 1200 proto-client-and-target-realm-mismatch, 1201 proto-target-principal-unknown, 1202 proto-authorization-failed, 1203 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1205 proto-dry-run-not-permitted, 1206 ... 1207 } 1209 -- These codes are hints for clients, primarily for when they are 1210 -- used for changing the passwords of automated principals; error 1211 -- replies carry password quality policy help text that is more 1212 -- appropriate for clients to display to users. 1213 PW-Quality-Codes ::= ENUM { 1214 pwq-generic, 1215 pwq-too-soon, 1216 pwq-repeated, 1217 pwq-too-short, 1218 pwq-dictionary-words, 1219 pwq-prohibited-codepoints, 1220 pwq-need-more-char-classes, 1221 ... 1222 } 1224 -- 1225 -- Requests and responses 1226 -- 1228 -- NULL request, much like ONC RPC's NULL procedure - NOT extensible 1229 Req-null ::= NULL 1231 Rep-null ::= NULL 1233 Err-null ::= NULL 1235 -- Change password 1236 Req-change-pw ::= SEQUENCE { 1237 old-pw [0] Password, 1238 new-pw [1] Password OPTIONAL, 1239 commit [2] BOOLEAN DEFAULT TRUE, 1240 etypes [3] SEQUENCE (1..) OF Etype OPTIONAL, 1241 ... 1242 } 1244 Rep-change-pw ::= SEQUENCE { 1245 info-text [0] UTF8String OPTIONAL, 1246 new-pw [1] Password OPTIONAL, 1247 -- generated by the server if present 1248 -- (and requested by the client) 1249 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 1250 ... 1251 } 1253 Err-change-pw ::= SEQUENCE { 1254 help-text [0] UTF8String OPTIONAL, 1255 error [1] CHOICE { 1256 op-generic-error [0] Extensible-NULL, 1257 op-old-pw-incorrect [1] Extensible-NULL, 1258 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1260 op-wont-generate-new-pw [2] Extensible-NULL, 1261 op-new-pw-rejected-generic [3] SEQUENCE { 1262 policy [1] SEQUENCE OF UTF8String, 1263 suggested-pw [2] Password OPTIONAL, 1264 policy-codes [3] SET OF PW-Quality-Codes 1265 OPTIONAL, 1266 ... 1267 } 1268 op-etype-not-supported [4] SEQUENCE { 1269 supported-etypes [1] SEQUENCE OF Etype, 1270 ... 1271 }, 1272 ... 1273 }, 1274 ... 1275 } 1277 -- Set password 1278 Req-set-pw ::= SEQUENCE { 1279 languages [0] SEQUENCE OF Language-Tag OPTIONAL, 1280 new-pw [1] Password OPTIONAL, 1281 commit [2] BOOLEAN DEFAULT TRUE, 1282 etypes [3] SEQUENCE (1..) OF Etype OPTIONAL, 1283 ... 1284 } 1286 Rep-set-pw ::= SEQUENCE { 1287 info-text [0] UTF8String OPTIONAL, 1288 new-pw [1] Password OPTIONAL, 1289 -- generated by the server if present 1290 -- (and requested by the client) 1291 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 1292 ... 1293 } 1295 Err-set-pw ::= Err-change-pw 1297 -- Set keys 1298 Req-set-keys ::= SEQUENCE { 1299 keys [0] SEQUENCE OF Key, 1300 commit [1] BOOLEAN DEFAULT TRUE, 1301 -- TRUE -> install keys now 1302 -- 1303 -- FALSE -> require set-keys-commit 1304 -- before issuing tickets 1305 -- encrypted with these keys. 1306 -- 1307 -- See commit-keys op 1308 isupport [2] KerberosVSupportNego OPTIONAL, 1309 -- For future Kerberos V extensions KDCs 1310 -- may need to know what krb5 version is 1311 -- supported by individual service 1312 -- principals. This field provides a 1313 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1315 -- way to tell the KDC what version of 1316 -- Kerberos V the target principal 1317 -- supports. 1318 ... 1319 } 1321 Rep-set-keys ::= SEQUENCE { 1322 info-text [0] UTF8String OPTIONAL, 1323 kvno [1] UInt32, 1324 aliases [2] SEQUENCE OF SEQUENCE { 1325 name [0] PrincipalName, 1326 realm [1] Realm OPTIONAL, 1327 ... 1328 }, 1329 isupport [3] KerberosVSupportNego OPTIONAL, 1330 ... 1331 -- Should there be ETYPE-INFO2 stuff here? 1332 } 1334 Err-set-keys ::= SEQUENCE { 1335 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1336 error [1] CHOICE { 1337 op-generic [0] Extensible-NULL, 1338 op-deferred-commit-no-support [1] Extensible-NULL, 1339 op-etype-no-support [2] SEQUENCE OF { 1340 supported-etypes [1] SEQUENCE OF Etype, 1341 ... 1342 } 1343 ... 1344 } 1345 } 1347 -- Generate keys 1348 Req-gen-keys ::= SEQUENCE { 1349 etypes [0] SEQUENCE (1..) OF Etype, 1350 entropy [1] OCTET STRING OPTIONAL, 1351 commit [2] BOOLEAN DEFAULT TRUE, 1352 -- TRUE -> install keys now 1353 -- 1354 -- FALSE -> require set-keys-commit 1355 -- before issuing tickets 1356 -- encrypted with these keys. 1357 -- 1358 -- See commit-keys op 1359 isupport [3] KerberosVSupportNego OPTIONAL, 1360 -- For future Kerberos V extensions KDCs 1361 -- may need to know what krb5 version is 1362 -- supported by individual service 1363 -- principals. This field provides a 1364 -- way to tell the KDC what version of 1365 -- Kerberos V the target principal 1366 -- supports. 1367 ... 1369 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1371 } 1373 Rep-gen-keys ::= SEQUENCE { 1374 info-text [0] UTF8String OPTIONAL, 1375 kvno [1] UInt32, 1376 key [2] Key, 1377 aliases [3] SEQUENCE OF SEQUENCE { 1378 name [0] PrincipalName, 1379 realm [1] Realm OPTIONAL, 1380 ... 1381 }, 1382 isupport [4] KerberosVSupportNego OPTIONAL, 1383 ... 1384 -- Should there be ETYPE-INFO2 stuff here? 1385 } 1387 Err-gen-keys ::= Err-set-keys 1389 -- Get un-committed key request 1390 Req-get-keys ::= SEQUENCE { 1391 kvno [0] UInt32, 1392 ... 1393 } 1395 Rep-get-keys ::= SEQUENCE { 1396 info-text [0] UTF8String OPTIONAL, 1397 keys [1] SEQUENCE OF Key, 1398 aliases [2] SEQUENCE OF SEQUENCE { 1399 name [0] PrincipalName, 1400 realm [1] Realm OPTIONAL, 1401 ... 1402 }, 1403 isupport [3] KerberosVSupportNego OPTIONAL, 1404 ... 1405 -- Should there be ETYPE-INFO2 stuff here? 1406 } 1408 Err-get-keys ::= SEQUENCE { 1409 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1410 error [1] CHOICE { 1411 op-generic [0] Extensible-NULL, 1412 op-kvno-committed [1] Extensible-NULL, 1413 op-no-such-kvno [1] Extensible-NULL, 1414 ... 1415 } 1416 } 1418 -- Commit a set keys request 1419 Req-commit-keys ::= SEQUENCE { 1420 kvno [0] UInt32, 1421 ... 1422 } 1423 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1425 Rep-commit-keys ::= Extensible-NULL 1427 Err-commit-keys ::= SEQUENCE { 1428 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1429 error [1] CHOICE { 1430 op-generic [0] Extensible-NULL, 1431 op-kvno-expired [1] Extensible-NULL, 1432 -- The client took too long to respond. 1433 op-kvno-unknown [2] Extensible-NULL, 1434 -- The targ princ/kvno is invalid or unknown to the 1435 -- server (perhaps it lost track of state) 1436 op-new-keys-conflict [3] Extensible-NULL, 1437 -- A new-keys/commit-keys request subsequent to the 1438 -- new-keys that produced the kvno has completed 1439 -- and incremented the principal's kvno 1440 ... 1441 } 1442 ... 1443 } 1445 -- Get password policy 1446 Req-get-pw-policy ::= Extensible-NULL 1448 Rep-get-pw-policy ::= SEQUENCE { 1449 policy-name [0] UTF8String OPTIONAL, 1450 description [1] SEQUENCE OF UTF8String OPTIONAL, 1451 ... 1452 } 1454 Err-get-pw-policy ::= Extensible-NULL 1456 -- Get principal aliases 1457 Req-get-princ-aliases ::= Extensible-NULL 1459 Rep-get-princ-aliases ::= SEQUENCE { 1460 help-text [0] UTF8String OPTIONAL, 1461 aliases [1] SEQUENCE OF SEQUENCE { 1462 name [0] PrincipalName, 1463 realm [1] Realm OPTIONAL, 1464 ... 1465 }, 1466 ... 1467 } 1469 Err-get-princ-aliases ::= Extensible-NULL 1471 -- Get list of enctypes supported by KDC for new keys 1472 Req-get-realm-krb5-support ::= Extensible-NULL 1474 Rep-get-realm-krb5-support ::= SEQUENCE { 1475 isupport [0] KerberosVSupportNego, 1476 -- Version of Kerberos V supported by 1477 -- the target realm. 1479 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1481 ... 1482 } 1484 Err-get-realm-krb5-support ::= Extensible-NULL 1486 -- Get s2kparams 1487 Req-get-s2kparams ::= Extensible-NULL 1489 Rep-get-s2kparams ::= SEQUENCE { 1490 help-text [0] UTF8String OPTIONAL, 1491 s2kparams [1] SEQUENCE OF Etype-Info-Entry, 1492 ... 1493 } 1495 Err-get-s2kparams ::= Extensible-NULL 1497 END 1499 6 IANA Considerations 1501 There are no IANA considerations for this document. 1503 7 Security Considerations 1505 Implementors and site administrators should note that the redundancy 1506 of UTF-8 encodings of passwords varies by language. Password quality 1507 policies SHOULD, therefore, take this into account when estimating 1508 the amount of redundancy and entropy in a proposed new password. [?? 1509 It's late at night - I think this is correct.] 1511 Kerberos set/change password/key protocol major version negotiation 1512 cannot be done securely; a downgrade attack is possible against 1513 clients that attempt to negotiate the protocol major version to use 1514 with a server. It is not clear at this time that the attacker would 1515 gain much from such a downgrade attack other than denial of service 1516 (DoS) by forcing the client to use a protocol version which does not 1517 support some feature needed by the client (Kerberos V in general is 1518 subject to a variety of DoS attacks anyways [RFC1510]). Clients 1519 SHOULD NOT negotiate support for legacy major versions of this 1520 protocol unless configured otherwise. 1522 This protocol does not have Perfect Forward Security (PFS). As a 1523 result, any passive network snooper watching password/key changing 1524 operations who has stolen a principal's password or long-term keys 1525 can find out what the new ones are. 1527 [More text needed?] 1529 8 Acknowledgements 1531 The authors would like to thank Bill GossmanMike Swift, John Brezak, 1532 Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W. 1534 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1536 Nelson, Marcus Watts, Love, Joel N. Weber II, Jeffrey Hutzelman and 1537 other participants from the IETF Kerberos Working Group for their 1538 assistance. 1540 9 References 1542 9.1 Normative References 1544 [RFC2026] 1545 S. Bradner, RFC2026: "The Internet Standard Process - Revision 1546 3," October 1996, Obsoletes - RFC 1602, Status: Best Current 1547 Practice. 1549 [RFC2119] 1550 S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to 1551 Indicate Requirement Levels," March 1997, Status: Best Current 1552 Practice. 1554 [X680] 1555 Abstract Syntax Notation One (ASN.1): Specification of Basic 1556 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC 1557 International Standard 8824-1:1998. 1558 http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf 1560 [X690] 1561 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), 1562 Canonical Encoding Rules (CER) and Distinguished Encoding Rules 1563 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International 1564 Standard 8825-1:1998. 1565 http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf 1567 [clarifications] 1568 RFC-Editor: To be replaced by RFC number for 1569 draft-ietf-krb-wg-kerberos-clarifications. 1571 [RFC3066] 1572 H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of 1573 Languages," January 2001, Obsoletes RFC1766, Status: Best Current 1574 Practice. 1576 9.2 Informative References 1578 [RFC3244] 1579 M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000 1580 Kerberos Change Password and Set Password Protocols," February 1581 2002, Status: Informational. 1583 10 Authors' Addresses 1585 Nicolas Williams 1586 Sun Microsystems 1587 5300 Riata Trace Ct 1588 Austin, TX 78727 1589 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1591 Email: nicolas.williams@sun.com 1593 Jonathan Trostle 1594 Cisco Systems 1595 170 W. Tasman Dr. 1596 San Jose, CA 95134 1597 Email: jtrostle@cisco.com 1599 11 Notes to the RFC Editor 1601 This document has two KRB WG drafts as normative references and 1602 cannot progress until those drafts progress, but no other draft 1603 depends on this one. 1605 12 Change History 1607 -01 -> -02 1609 - Removed Bill Gossman, Mike Swift and John Brezak as authors. 1611 - Removed UDP as a transport for this protocol. 1613 - Replaced redundant copies of framing ASCII art with reference to 1614 RFC3244. 1616 - Made all name/password strings UTF8String with an extensible 1617 constraint to IA5String. 1619 - Added a method for doing dry runs of operations. This is helpful 1620 in testing passwords against password quality policies. 1622 - Added an operation for retrieving a principal's current and 1623 preferred string-to-key parameters, and a way to change them 1624 without changing the principal's password. 1626 - Added password quality codes as hints for smart clients, but 1627 these are optional and not to be used instead of messages to be 1628 displayed to useds. 1630 - Added a 'commit' option to change-pw and set-pw (as requested by 1631 Larry). 1633 - Removed "version" field of the Kerberos V feature negotiation 1634 struture. 1636 DRAFT Kerberos Set/Change Password v2 Expires January 2005 1638 Intellectual Property Statement 1640 The IETF takes no position regarding the validity or scope of any 1641 Intellectual Property Rights or other rights that might be claimed to 1642 pertain to the implementation or use of the technology described in 1643 this document or the extent to which any license under such rights 1644 might or might not be available; nor does it represent that it has 1645 made any independent effort to identify any such rights. Information 1646 on the procedures with respect to rights in RFC documents can be 1647 found in BCP 78 and BCP 79. 1649 Copies of IPR disclosures made to the IETF Secretariat and any 1650 assurances of licenses to be made available, or the result of an 1651 attempt made to obtain a general license or permission for the use of 1652 such proprietary rights by implementers or users of this 1653 specification can be obtained from the IETF on-line IPR repository at 1654 http://www.ietf.org/ipr. 1656 The IETF invites any interested party to bring to its attention any 1657 copyrights, patents or patent applications, or other proprietary 1658 rights that may cover technology that may be required to implement 1659 this standard. Please address the information to the IETF at 1660 ietf-ipr@ietf.org. 1662 Disclaimer of Validity 1664 This document and the information contained herein are provided on an 1665 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1666 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1667 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1668 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1669 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1670 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1672 Copyright Statement 1674 Copyright (C) The Internet Society (2004). This document is subject 1675 to the rights, licenses and restrictions contained in BCP 78, and 1676 except as set forth therein, the authors retain all their rights. 1678 Acknowledgment 1680 Funding for the RFC Editor function is currently provided by the 1681 Internet Society.