idnits 2.17.1 draft-ietf-krb-wg-kerberos-set-passwd-05.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 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1605. ** 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. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (July 27, 2006) is 6482 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 section? 'RFC2119' on line 1559 looks like a reference -- Missing reference section? 'RFC3244' on line 1565 looks like a reference -- Missing reference section? 'RFC4120' on line 1569 looks like a reference -- Missing reference section? 'RFC3066' on line 1562 looks like a reference -- Missing reference section? '1' on line 1513 looks like a reference -- Missing reference section? '0' on line 1512 looks like a reference -- Missing reference section? '2' on line 1458 looks like a reference -- Missing reference section? 'APPLICATION 0' on line 1150 looks like a reference -- Missing reference section? '3' on line 1461 looks like a reference -- Missing reference section? '4' on line 1407 looks like a reference -- Missing reference section? '5' on line 1215 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 1163 looks like a reference -- Missing reference section? 'APPLICATION 2' on line 1170 looks like a reference -- Missing reference section? '6' on line 1216 looks like a reference -- Missing reference section? '7' on line 1217 looks like a reference -- Missing reference section? '8' on line 1218 looks like a reference -- Missing reference section? '9' on line 1219 looks like a reference -- Missing reference section? '10' on line 1220 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Expires: January 28, 2007 July 27, 2006 6 Kerberos Set/Change Key/Password Protocol Version 2 7 draft-ietf-krb-wg-kerberos-set-passwd-05.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 19 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 28, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 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. Conventions used in this document . . . . . . . . . . . . 3 46 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. The Protocol . . . . . . . . . . . . . . . . . . . . . . . 5 48 3.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3.1.1. Protocol Framing . . . . . . . . . . . . . . . . . . . . . 5 50 3.2. Protocol Version Negotiation . . . . . . . . . . . . . . . 6 51 3.2.1. Protocol Major Version Negotiation . . . . . . . . . . . . 6 52 3.2.2. Protocol Minor Version Negotiation . . . . . . . . . . . . 7 53 3.3. Use of Kerberos V and Key Exchange . . . . . . . . . . . . 7 54 3.4. Use of ASN.1 . . . . . . . . . . . . . . . . . . . . . . . 8 55 3.5. Internationalization . . . . . . . . . . . . . . . . . . . 8 56 3.5.1. Normalization Forms for UTF-8 Strings . . . . . . . . . . 8 57 3.5.2. Language Negotiation . . . . . . . . . . . . . . . . . . . 8 58 3.6. Protocol Extensibility . . . . . . . . . . . . . . . . . . 9 59 3.7. Protocol Subsets . . . . . . . . . . . . . . . . . . . . . 9 60 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . 10 61 4.1. Password Quality Policies . . . . . . . . . . . . . . . . 10 62 4.1.1. Standard Password Quality Policies . . . . . . . . . . . . 11 63 4.2. PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 4.3. Operations . . . . . . . . . . . . . . . . . . . . . . . . 13 65 4.3.1. Null . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 4.3.2. Change Kerberos Password . . . . . . . . . . . . . . . . . 14 67 4.3.3. Set Kerberos Password . . . . . . . . . . . . . . . . . . 16 68 4.3.4. Set Kerberos Keys . . . . . . . . . . . . . . . . . . . . 19 69 4.3.5. Generate Kerberos Keys . . . . . . . . . . . . . . . . . . 21 70 4.3.6. Get New Keys . . . . . . . . . . . . . . . . . . . . . . . 22 71 4.3.7. Commit New Keys . . . . . . . . . . . . . . . . . . . . . 23 72 4.3.8. Get Password Quality Policy . . . . . . . . . . . . . . . 24 73 4.3.9. Get Principal Aliases . . . . . . . . . . . . . . . . . . 25 74 4.3.10. Get Realm's Supported Kerberos V Version and Features . . 25 75 4.3.11. Retrieve Principal's S2K Params and Preferred Params . . . 26 76 4.4. Principal Aliases . . . . . . . . . . . . . . . . . . . . 26 77 4.5. Kerberos V Feature Negotiation . . . . . . . . . . . . . . 27 78 5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . 28 79 6. Security Considerations . . . . . . . . . . . . . . . . . 38 80 7. Normative . . . . . . . . . . . . . . . . . . . . . . . . 38 81 Author's Address . . . . . . . . . . . . . . . . . . . . . 40 82 Intellectual Property and Copyright Statements . . . . . . 41 84 1. 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 2. 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 3. The Protocol 108 The structure of the protocol is quite similar to that of typical RPC 109 protocols. Each transaction consists of a data structure specific to 110 an operation which is then wrapped in a data structure which is 111 general to all operations of the protocol. These data structures are 112 defined with the Abstract Syntax Notation 1 (ASN.1) [CCITT.X680.2002] 113 and they are encoded using the Distinguished Encoding Rules (DER) 114 [CCITT.X690.2002]. 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 3.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 3.1.1. Protocol Framing 128 Requests and responses are exchanged using the same framing as in 129 [RFC3244], but with the following differences: 131 o the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1) 133 o 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 o the 'KRB-PRIV' field of the request and reply is mutually 137 exclusive with the 'AP-REQ' field of the request 139 o the 'AP-REP length' field of the reply can be set to 0x0, in which 140 case the 'AP-REP' field of the reply is excluded 142 o 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 o 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 3.2. Protocol Version Negotiation 161 There are several major versions of this protocol. Version 2 also 162 introduces a notion of protocol minor versions for use in negotiating 163 protocol extensions. As of this time only one minor version is 164 defined for major version 2: minor version 0, defined herein. 166 3.2.1. Protocol Major Version Negotiation 168 Version 2 clients that also support other versions, such as 0xff80, 169 as in [RFC3244], SHOULD attempt to use version 2 of the protocol 170 first. 172 Servers which do not support version 2 of this protocol typically 173 include their preferred version number in the reply and/or may 174 include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a 175 status code of KRB5_KPASSWD_MALFORMED. 177 Note that some [RFC3244] server implementations close the TCP 178 connection without returning any other response. Note also that 179 there is no integrity protection for the major version number in the 180 protocol framing or for any data in a KRB-ERROR. 182 As a result change password protocol major version negotiation is 183 subject to downgrade attacks. Therefore major version negotiation is 184 NOT RECOMMENDED. 186 Where the server indicates that it does not support version 2, the 187 client MAY, but SHOULD NOT, unless configured to do so, fall back on 188 another major version of this protocol. 190 Version 2 servers MAY respond to non-v2 requests using whatever 191 response is appropriate for the versions used by the clients, but if 192 a server does not do this or know how to do this then it MUST respond 193 with an error framed as in Section 3.1.1, using an AP-REP and KRB- 194 PRIV if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise 195 and using a ProtocolErrorCode value of unsupported-major-version. 197 It is expected that implementations of as yet unspecified future 198 major versions of this protocol will be required to support version 2 199 integrity protected error replies for properly indicating no support 200 for version 2 of the protocl. We also hope that no further major 201 versions of this protocol will be needed. 203 3.2.2. Protocol Minor Version Negotiation 205 Version 2 clients are free to use whatever protocol minor version and 206 message extensions are available to them in their initial messages to 207 version 2 servers, provided that the minor versions (other than 0) 208 have been defined through IETF documents. 210 Version 2 servers MUST answer with the highest protocol minor version 211 number supported by the server and the client. 213 Version 2 clients MUST use the protocol minor version used in a 214 server's reply for any subsequent messages in the same TCP session. 216 See Section 3.6 for further description of the protocol's 217 extensibility and its relation to protocol minor versions and the 218 negotiation thereof. 220 3.3. Use of Kerberos V and Key Exchange 222 This protocol makes use of messages defined in [RFC4120]. 223 Specifically, AP-REQ, AP-REP, KRB-ERROR and KRB-PRIV. 225 All operations are to be performed by the server on behalf of the 226 client principal. 228 Clients SHOULD use "kadmin/setpw" as the principal name of the server 229 for all requests except when changing the client principal's own 230 expired password, for which they should use "kadmin/changepw". The 231 "kadmin/changepw" service exists to allow KDCs to limit principals 232 with expired passwords to getting initial tickets to the password 233 changing service only and only for changing expired passwords. 235 Servers MUST limit clients that used the "kadmin/changepw" service 236 principal name to changing the password of the client principal. 238 The client MUST request mutual authentication and the client MUST 239 MUST request the use of sequence numbers. 241 Clients SHOULD use INITIAL tickets for requests whose target 242 principal is the client's principal. Servers SHOULD force the use of 243 INITIAL tickets for such requests and MAY force the use of INITIAL 244 for all others - see Section 4.3.2. 246 Servers MUST specify a sub-session key. 248 The encrypted part of KRB-PRIVs MUST be encrypted with the server's 249 sub-session key and key usage 20 (client->server) or 21 250 (server->client). 252 After each new AP exchange the client and server MUST destroy the 253 session keys, if any, resulting from the previous AP exchange. 255 3.4. Use of ASN.1 257 This protocol's messages are defined in ASN.1, using only features 258 from [CCITT.X680.2002]. All ASN.1 types defined herein are to be 259 encoded in DER [CCITT.X690.2002]. A complete ASN.1 module is given 260 in Section 5. 262 The DER encoding of the ASN.1 PDUs are exchanged wrapped in a KRB- 263 PRIV as described above and/or as e-data in KRB-ERROR messages. 265 3.5. Internationalization 267 This protocol's request PDU carries an optional field indicating the 268 languages spoken by the client user; the client SHOULD send its list 269 of spoken languages to the server (once per-TCP session). 271 The server SHOULD localize all strings intended for display to users 272 to a language in common with the languages spoken by the client user. 274 Strings for Kerberos principal and realm names used in this protocol 275 are be constrained as per [RFC4120]. 277 3.5.1. Normalization Forms for UTF-8 Strings 279 Because Kerberos V [RFC4120] restricts principal names, realm names 280 and passwords to IA5String, this protocol uses UTF8String with an 281 extensible constraint to IA5String. 283 Future versions of Kerberos may relax this constraint; if so then a 284 minor version of this protocol should relax this constraint 285 accordingly. 287 3.5.2. Language Negotiation 289 The server MUST pick a language from the client's input list or the 290 default language tag (see [RFC3066]) for text in its responses which 291 is meant for the user to read. 293 The server SHOULD use a language selection algorithm such that 294 consideration is first given to exact matches between the client's 295 spoken languages and the server's available locales, followed by 296 "fuzzy" matches where only the first sub-tags of the client's 297 language tag list are used for matching against the servers available 298 locales. 300 Servers MUST cache the optional language tag lists from prior 301 requests for use with subsequent requests that exclude the language 302 tag list. Clients MAY expect such server behaviour and send the 303 language tag lists only once per-TCP session. Clients SHOULD send 304 the server the language tag list at least once. 306 When the server has a message catalog for one of the client's spoken 307 languages the server SHOULD localize any text strings intended for 308 display to users. 310 3.6. Protocol Extensibility 312 The protocol is defined in ASN.1 and uses extensibility markers 313 throughout. As such, the module presented herein can be extended 314 within the framework of [CCITT.X680.2002]. 316 Typed holes are not used in this protocol as it is very simple and 317 does not require the ability to deal with abstract data types defined 318 in different layers. For this reason, the only way to extend this 319 protocol is by extending the ASN.1 module within the framework of the 320 IETF; all future extensions to this protocol have to be defined in 321 IETF documents unless otherwise specified in a future IETF revision 322 of this protocol. 324 A protocol minor version number is used to negotiate use of 325 extensions. See Section 3.2.2 for the minor version negotiation. 327 Servers SHOULD ignore unknown additions to the ASN.1 types, in 328 initial requests, where the syntax allows them, except for extensions 329 to the "Op-req" type, which MUST result in an error. 331 Servers MUST respond with an error (ProtocolErrorCode value of 332 unsupported-minor-version) to clients that use operations unknown to 333 the server. 335 3.7. Protocol Subsets 337 The structure of the protocol is such that the ASN.1 syntaxes for the 338 various operations supported by the protocol are independent of the 339 each other. Client and server implementations MAY implement subsets 340 of the overall protocol by removing some alternatives to the Op-req, 341 Op-rep and Op-err CHOICEs from the ASN.1 module given in Section 5. 343 For example, it should be possible to have a password-change only 344 client that cannot set principal's keys - and vice versa. 346 4. Protocol Elements 348 The protocol as defined herein supports the following operations 349 relating to the management of Kerberos principal's passwords or keys: 351 o change password (or enctypes and string-to-key parameters) 353 o set password (administrative) 355 o set new keys 357 o generate new keys 359 o get new, un-committed keys 361 o commit new keys 363 o get password policy name and/or description of principal 365 o list aliases of a principal 367 o list enctypes and version of Kerberos V supported by realm 369 The operation for retrieving a list of aliases of a principal is 370 needed where KDCs implement aliasing of principal names and allows 371 clients to properly setup their key databases when principal aliasing 372 is in use. 374 Operations such as creation or deletion of principals are outside the 375 scope of this document, and should be performed via other means, such 376 as through directories or other Kerberos administration protocols. 378 The individual operations are described in Section 4.3. 380 4.1. Password Quality Policies 382 Servers may reject new user passwords for failing to meet password 383 quality policies. When this happens the server must be able to 384 communicate the policy to the user so that the user may select a 385 better password. 387 The protocol allows for two ways to do this: 389 o through error codes that identify specific password quality 390 policies known; 392 o through localized error strings. 394 The use of localized error strings allows servers to convey non- 395 standard password quality policies to users, but it requires server- 396 side message catalogs for localization and support for language 397 negotiation. The use of error codes only allows for standard 398 password quality policies that clients must be aware of a priori, 399 therefore use of error codes requires the distribution of new message 400 catalogs to clients whenever new error codes are added; this 401 simplifies servers at the expense of password quality extensibility. 403 When a server would reject a password due to its failing to meet a 404 standard password quality policy the the server MUST use the 405 appropriate error codes (see below) and the server SHOULD send a 406 localized error message to the user. 408 When a server would reject a password due to its failing to meet a 409 non-standard password quality policy (one not described herein) the 410 the server MUST send a localized error message to the user. 412 4.1.1. Standard Password Quality Policies 414 o pwq-too-soon 416 It is too soon for the principal to change its password or long- 417 term keys. 419 o pwq-history 421 The new password is one that the principal has used before or is 422 too similar to a password that it has used before. 424 o pwq-too-short 426 The new password is too short. 428 o pwq-dictionary-words 430 The new password is or contains words that are in the dictionary. 432 o pwq-prohibited-codepoints 434 The new password contains prohibited codepoints. 436 o pwq-need-more-char-classes 438 The new password does not have characters from enough character 439 classes (lower-case letters, upper-case letters, digits, 440 punctuation, etc...). 442 4.2. PDUs 444 The types "Request," "Response" and "Error-Response" are the ASN.1 445 module's PDUs. 447 The "Request" and "Response" PDUs are always to be sent wrapped in 448 KRB-PRIV messages, except for the "Error-Response" PDU which MUST be 449 sent as KRB-ERROR e-data (see Section 3.3) when AP exchanges fail, 450 otherwise it MUST be sent wrapped in a KRB-PRIV. 452 The ASN.1 syntax for the PDUs is given in Section 5. 454 Note that the first field of each PDU is the major version of the 455 protocol, defaulted to 2, meaning that it is never included in 456 version 2 exchanges. Similarly, the second field of each PDU is the 457 minor version, defaulted to 0. 459 The request, responses and error PDUs consist of an outer structure 460 ("Request," "Response" and "Error-Response") containing fields common 461 to all requests, responses and errors, respectively, and an inner 462 structure for fields that are specific to each operation's requests/ 463 responses. The inner structure is optional in the case of the Error- 464 Response PDU and need not be included when generic errors occur for 465 which there is a suitable ProtocolErrorCode. 467 Specifically, the outer Request structure has a field for passing a 468 client user's spoken (read) languages to the server. It also has two 469 optional fields for identifying the requested operation's target 470 principal's name and realm (if not sent then the server MUST use the 471 client's principal name and realm as the target). A boolean field 472 for indicating whether or not the request should be dry-run is also 473 included; dry-runs can be used to test server policies, and servers 474 MUST NOT modify any principals when processing dry-run requests. 476 The Response and Error PDUs' outer structures include a field 477 indicating the language that the server has chosen for localization 478 of text intended to be displayed to users; this field is defaulted to 479 "i-default". This language tag applies to all UTF8 strings in the 480 inner structure (Op-rep and Op-err) that are meant to be displayed to 481 users. 483 The protocol error codes are: 485 o proto-generic-error 487 An operation-specific error ocurred, see the inner Op-error. 489 o proto-format-error 491 o proto-unsupported-major-version 493 o proto-unsupported-minor-version 495 o proto-unsupported-operation 497 o proto-wrong-service-principal 499 Use kadmin/setpw for the server's principal name. 501 o proto-re-authentication-required 503 The server demands that the client re-authenticate through a new 504 AP exchange. 506 o proto-initial-ticket-required 508 Use of an INITIAL ticket is required for the requested operation. 510 o proto-client-and-target-realm-mismatch 512 The server requires that the client's principal name and the 513 target principal of the operation share the same realm name. 515 o proto-target-principal-unknown 517 o proto-authorization-failed 519 4.3. Operations 521 This section describes the semantics of each operation request and 522 response defined in the ASN.1 module in Section 5. 524 4.3.1. Null 526 NAME 528 null - Null or "ping" operation 530 DESCRIPTION 532 The null request is intended for use with TCP; its purpose is 533 similar to RPC null procedures and is akin to a "ping" operation. 535 ERRORS 537 None. 539 4.3.2. Change Kerberos Password 541 NAME 543 change-pw - Change password operation 545 SYNOPSIS 547 Req-change-pw(old-pw, [languages], [new-pw], 548 [commit], [etypes]) -> 549 Rep-change-pw([info-text], [new-pw], [etypes]) | 550 Err-change-pw([help-text], error code, [error info]) 552 DESCRIPTION 554 Change a principal's password. 556 The change password request has one required, three optional and 557 one defaulted arguments: "old-pw" (required), "languages," 558 "new-pw", "commit" (defaults to "TRUE") and "etypes", 559 corresponding to the target principal's old password, its 560 preferred languages, its new password, a boolean indicating 561 whether or not to make the new long-term key available for 562 immediate use, and the desired enctypes for the new long-term 563 keys. 565 The server MUST validate the old password and MUST check the 566 quality of the new password, if sent, according the password 567 quality policy associated with the target principal. 569 If the old and new passwords in the request are the same strings, 570 and the principal is not currently required to change its 571 password, then the server MAY permit the password change as way to 572 change a principal's enctypes and string-to-key parameters. This 573 feature provides a way to, for example, add enctypes to a 574 principals' password-derived long-term keys without forcing a 575 password change following an upgrade to the KDC that adds support 576 for new enctypes. 578 A client MAY request that the server generate a new password by 579 excluding the new password from its request, in which case the 580 server MUST either generate a new password or respond with an 581 error indicating that it does not support this feature. 583 Server-generated passwords MUST meet the target principal's 584 password quality policy. It is RECOMMENDED that server-generated 585 passwords be user-friendly, that is, memorable and that the target 586 principal's preferred languages be taken into account by the 587 password generation alogrithm used by the server. 589 Uncommitted password changes are commited using the commit-keys 590 operation. 592 RETURN 594 Upon successful password changes the server responds with a 595 Rep-change-pw. The fields of Rep-change-pw are all optional and 596 include: 598 - 'info-text' which the server can use to send a message to the 599 user such as "Your new password will expire in 90 days," for 600 example. 602 - 'new-pw' which the server MUST include if the client 603 requested that the server generate a new password; generated 604 passwords MUST pass the target principal's password quality 605 policy. 607 - 'etypes' which the server MAY include to indicate which types 608 of long-term keys it created for the target principal and 609 which the server MUST include if the client specified a set 610 of enctypes in its request. 612 ERRORS 613 The server may respond to change password requests with protocol 614 or operation errors. 616 All operation errors include an optional 'help-text' field by 617 which the server can describe the error in a human-readable, 618 localizaed string. 620 Change password error codes include: 622 - generic-error 624 - old-pw-incorrect 626 - wont-generate-new-pw 628 The server will not generate a new password for this 629 principal or does not support password generation in general. 631 - new-pw-rejected-generic 633 The client's proposed new password failed the target 634 principal's password quality policy. 636 The server MUST include a description of the password quality 637 policy or aspect of it that the client's proposed new 638 password failed to meet. 640 The server MAY generate and send a new password that the 641 client can then use as a new password and which is guaranteed 642 to pass the target principal's current password quality 643 policy. 645 The server MAY include a set of policy error code hints. 647 - etype-not-supported 649 The client requested an enctype that the KDC does not 650 support. 652 4.3.3. Set Kerberos Password 654 NAME 656 set-pw - Set password operation 658 SYNOPSIS 660 Req-set-pw([languages], [new-pw], [commit], [etypes]) -> 661 Rep-set-pw([info-text], [new-pw], [etypes]) | 662 Err-set-pw([help-text], error code, [error info]) 664 DESCRIPTION 666 Administratively set a principal's password. 668 The set password request has three optional and one defaulted 669 arguments: "languages", "new-pw," "commit" (defaulted to "TRUE") 670 and "etypes", corresponding to the target principal's preferred 671 languages, new password, a boolean indicating whether or not to 672 make the new long-term key available for immediate use, and the 673 desired enctypes for the new long-term keys. 675 The server MUST check the quality of the new password, if sent, 676 according the password quality policy associated with the target 677 principal. 679 The server SHOULD require that the client use the change-pw 680 operation instead of set-pw when the client principal and the 681 target principal are the same. 683 A client MAY request that the server generate a new password by 684 excluding the new password from its request, in which case the 685 server MUST either generate a new password or respond with an 686 error indicating that it does not support this feature. 688 Server-generated passwords MUST meet the target principal's 689 password quality policy. It is RECOMMENDED that server-generated 690 passwords be user-friendly, that is, memorable and that the target 691 principal's preferred languages be taken into account by the 692 password generation alogrithm used by the server. 694 RETURN 696 Upon successfully setting a password the server responds with a 697 Rep-set-pw. The fields of Rep-set-pw are all optional and 698 include: 700 - 'info-text' which the server can use to send a message to the 701 user such as "Your new password will expire in 90 days," for 702 example. 704 - 'new-pw' which the server MUST include if the client 705 requested that the server generate a new password; generated 706 passwords MUST pass the target principal's password quality 707 policy. 709 - 'etypes' which the server MAY include to indicate which types 710 of long-term keys it created for the target principal and 711 which the server MUST include if the client specified a set 712 of enctypes in its request. 714 ERRORS 716 The server may respond to set password requests with protocol or 717 operation errors. 719 All operation errors include an optional 'help-text' field by 720 which the server can describe the error in a human-readable, 721 localizaed string. 723 Set password error codes include: 725 - generic-error 727 - use-change-pw 729 The server demands that the client use the change-pw 730 operation for the target principal of the set-pw request. 732 - wont-generate-new-pw 734 The server will not generate a new password for this 735 principal or does not support password generation in general. 737 - new-pw-rejected-generic 739 The client's proposed new password failed the target 740 principal's password quality policy. 742 The server MUST include a description of the password quality 743 policy or aspect of it that the client's proposed new 744 password failed to meet. 746 The server MAY generate and send a new password that the 747 client can then use as a new password and which is guaranteed 748 to pass the target principal's current password quality 749 policy. 751 The server MAY include a set of policy error code hints. 753 - etype-not-supported 754 The client requested an enctype that the KDC does not 755 support. 757 4.3.4. Set Kerberos Keys 758 NAME 760 set-keys - Set a principal's long-term keys 762 SYNOPSIS 764 Req-set-keys(new-keys, commit?, [isupport]) -> 765 Rep-set-keys([info-text], kvno, aliases, [isupport]) 767 DESCRIPTION 769 The set-keys request consists of two required fields and one 770 optional field: "new-keys", "commit" (a boolean field - see below) 771 and "isupport", an optional field for indicating to the KDC what 772 Kerberos V features are supported by the target principal. 774 When "commit" is true the KDC makes the new keys available for 775 issueing tickets encrypted in them immediately. Otherwise the 776 client MUST follow up with a commit-keys request to make the keys 777 available. This feature is useful for changing keys shared by 778 multiple hosts, in clustered services, for example, in an atomic 779 manner. 781 If a principal has keys are awaiting commitment when a new 782 set-keys request for that principal s made then the KDC MUST 783 overwrite the deferred keys. 785 RETURN 787 For successful set-keys operations the server returns: 789 - Informational text, optional. 791 - The new kvno for the target principal. 793 - A list of aliases of the target principal known to the KDC 794 (optional). 796 - The set of Kerberos V features supported by the KDC 797 (optional). 799 ERRORS 801 The server may respond with the following errors: 803 - generic 804 - deferred-commit-no-support 805 - etype-no-support 807 4.3.5. Generate Kerberos Keys 809 NAME 811 gen-keys - Generate long-term keys for a principal 813 SYNOPSIS 815 Req-gen-keys(etypes, [entropy], commit?, [isupport]) -> 816 Rep-set-keys([info-text], key, kvno, aliases, [isupport]) 818 DESCRIPTION 820 The gen-keys is similar to the set-keys request but differs in 821 that the server generates keys of client-requested enctypes, 822 rather than the client providing specific keys. 824 The gen-keys request consists of two required fields and two 825 optional fields: "etypes" (the enctypes of the new keys), 826 "entropy", "commit" and "isupport". 828 If a principal has keys are awaiting commitment when a new 829 set-keys request for that principal s made then the KDC MUST 830 overwrite the deferred keys. 832 RETURN 834 For successful set-keys operations the server returns: 836 - Informational text, optional. 838 - The new kvno for the target principal. 840 - The new key (only one is needed). 842 - A list of aliases of the target principal known to the KDC 843 (optional). 845 - The set of Kerberos V features supported by the KDC 846 (optional). 848 ERRORS 850 The server may respond with the following errors: 852 - generic 853 - deferred-commit-no-support 854 - etype-no-support 856 4.3.6. Get New Keys 858 NAME 860 get-keys - Retrieve a principal's uncommitted keys 862 SYNOPSIS 864 Req-get-keys(kvno) -> 865 Rep-get-keys([info-text], keys, aliases, [isupport]) | 866 Err-get-keys([help-text], error code, [error info]) 868 DESCRIPTION 870 This request allows a client to get the keys set or generated in a 871 previous set-keys or gen-keys request with deferred commitment.. 873 RETURN 875 If the target principal and kvno correspond to uncommitted keys 876 the server MUST respond with the actual keys that would be set by 877 a subsequent commit-keys request. Otherwise the server MUST 878 respond with an error (meaning that this operation cannot be used 879 to extract keys from the KDC that may be in use). 881 ERRORS 883 - generic 884 - kvno-committed 885 - no-such-kvno 887 4.3.7. Commit New Keys 889 NAME 891 commit-keys - Commit a principal's new long-term keys 893 SYNOPSIS 895 Req-commit-keys(kvno) -> 896 Rep-commit-keys() | 897 Err-commit-keys([help-text], error code, [error info]) 899 DESCRIPTION 901 The commit-keys operation allows a client to bring a principal's 902 new keys into use at the KDC. 904 Clients should make a commit-keys request corresponding to a 905 deferred commitment set-keys/gen-keys operation as soon as the 906 local key database for the target principal is updated. 908 The target principal name and the kvno MUST match those from a 909 prior set-keys or gen-keys operation. 911 Servers MAY expire delayed key commitments at will. Servers 912 SHOULD expire uncommitted new keys after a reasonable amount of 913 time (600 seconds is RECOMMENDED). 915 Servers MUST respond to new set-keys requests for principals with 916 pending, uncommitted new keys by expiring the uncommitted new keys 917 and proceeding as if there had been no expired new keys. 919 ERRORS 921 - generic 922 - op-kvno-expired 923 - op-kvno-unknown 924 - new-keys-conflict (A set-keys or gen-keys request succeeded 925 subsequent to the request that matches this 926 {principal, kvno} tuple.) 928 4.3.8. Get Password Quality Policy 930 NAME 932 get-pw-policy - Retrieve a principal's password policy 934 SYNOPSIS 936 Req-get-pw-policy() -> 937 Rep-get-pw-policy([policy name], [policy description]) 939 DESCRIPTION 941 Returns a description of the target principal's associated 942 password quality policy, if any, as a list of localized 943 UTF8String values. 945 Clients can use this operation in conjunction with the change-pw 946 operation to obtain text that can be displayed to the user before 947 the user actually enters a new password. 949 It is common for sites to set policies with respect to password 950 quality. It is beyond the scope of this document to describe such 951 policies. Management of password quality policies' actual content 952 is also beyond the scope of this protocol. 954 ERRORS 956 No operation errors are defined. 958 4.3.9. Get Principal Aliases 960 NAME 962 get-princ-aliases - Retrieve a principal's aliases 964 SYNOPSIS 966 Req-get-princ-aliases() -> 967 Rep-get-princ-aliases(aliases) 969 DESCRIPTION 971 Returns a list of aliases of the target principal. 973 ERRORS 975 No operation-specific errors. 977 4.3.10. Get Realm's Supported Kerberos V Version and Features 979 NAME 981 get-realm-krb5-support - List features supported by the realm 983 SYNOPSIS 985 Req-get-realm-krb5-support() -> 986 Rep-get-realm-krb5-support(isupport) 988 DESCRIPTION 990 Returns set of Kerberos V features support by the target 991 principal's realm's KDCs. 993 ERRORS 995 No operation-specific errors. 997 4.3.11. Retrieve Principal's S2K Params and Preferred Params 999 NAME 1001 get-s2kparams 1003 SYNOPSIS 1005 Req-get-s2kparams() -> 1006 Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams]) 1008 DESCRIPTION 1010 Returns the string2key parameters for the principal's current 1011 password-derived long-term keys, if any, and the parameters that 1012 the realm would prefer, if they differ from the former. 1014 This operation is intended for use with the change-pw() operation. 1015 When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if 1016 the principal's long-term secret keys' string2key parameters (and 1017 enctype list) should be changed and, if so, change them. 1019 If the 'princ-s2kparams' return value is missing then the 1021 principal does not have a password-derived long-term key. 1023 The 'preferred-s2kparams' MUST be excluded if the principal's 1024 string2key parameters satisfy the realm's policy. 1026 ERRORS 1028 No operation-specific errors. 1030 4.4. Principal Aliases 1032 Applications that use Kerberos often have to derive acceptor 1033 principal names from hostnames entered by users. Such hostnames may 1034 be aliases, they may be fully qualified, partially qualified or not 1035 qualified at all. Some implementations have resorted to deriving 1036 principal names from such hostnames by utilizing the names services 1037 to canonicalize the hostname first; such practices are not secure 1038 unless the name service are secure, which often aren't. 1040 One method for securely deriving principal names from hostnames is to 1041 alias principals at the KDC such that the KDC will issue tickets for 1042 principal names which are aliases of others. It is helpful for 1043 principals to know what are their aliases as known by the KDCs. 1045 Note that changing a principal's aliases is out of scope for this 1046 protocol. 1048 4.5. Kerberos V Feature Negotiation 1050 Principals and realms' KDCs may need to know about additional 1051 Kerberos V features and extensions that they each support. Several 1052 operations (see above) provide a way for clients and servers to 1053 exchange such infomration, in the form of lists of types supported 1054 for the various typed holes used in Kerberos V. 1056 5. ASN.1 Module 1058 DEFINITIONS EXPLICIT TAGS ::= BEGIN 1059 -- 1060 -- Note: EXPLICIT tagging is in use by default throughout this 1061 -- module. 1063 -- From [clarifications] with modifications 1064 PrincipalName ::= SEQUENCE { 1065 name-string [1] SEQUENCE OF UTF8String (IA5String, ...) 1066 } 1067 Realm ::= UTF8String (IA5String, ...) 1068 Salt ::= UTF8String (IA5String, ...) 1069 Password ::= UTF8String (IA5String, ...) 1071 -- NOTE WELL: Principal and realm names MUST be constrained by the 1072 -- specification of the version of Kerberos V used by the 1073 -- client. 1075 -- 1076 -- [Perhaps PrincipalName should be a SEQUENCE of an optional name 1077 -- type and a UTF8String, for simplicity.] 1079 -- From [clarifications] 1080 Int32 ::= INTEGER (-2147483648..2147483647) 1081 UInt32 ::= INTEGER (0..4294967295) 1083 -- Based on [clarifications] 1084 Etype ::= Int32 1085 Etype-Info-Entry ::= SEQUENCE { 1086 etype [0] Etype, 1087 salt [1] Salt OPTIONAL, 1088 s2kparams [2] OCTET STRING OPTIONAL, 1089 ... 1090 } 1091 Key ::= SEQUENCE { 1092 enc-type [0] Etype, -- from Kerberos 1093 key [1] OCTET STRING, 1094 ... 1095 } 1097 Language-Tag ::= UTF8String -- Constrained by [RFC3066] 1099 -- Empty, extensible SEQUENCEs are legal ASN.1 1100 Extensible-NULL ::= SEQUENCE { 1101 ... 1103 } 1105 -- Kerberos clients negotiate some parameters relating to their peers 1106 -- indirectly through the KDC. Today this is true of ticket session 1107 -- key enctypes, but in the future this indirect negotiation may also 1108 -- occur with respect to the minor version of Kerberos V to be used 1109 -- between clients and servers. Additionally, KDCs may need to know 1110 -- what authorization-data types are supported by service principals, 1111 -- both, for compatibility with legacy software and for optimization. 1112 -- 1113 -- Thesefore it is important for KDCs to know what features of 1114 -- Kerberos V each service principal supports. 1115 -- 1116 -- In version 2.0 of this protocol the clients and servers may notify 1117 -- each other of their support for: 1118 -- 1119 -- - enctypes 1120 -- - authorization data types 1121 -- - transited encoding data types 1122 -- 1123 -- All authorization-data types defined in [clarifications] are 1124 -- assumed to be supported if the minor version is 1 and do not need 1125 -- to be included in the ad-type list. 1126 -- 1127 -- Int32 is used for enctype and transited encoding data type 1128 -- identifiers. 1130 -- 1131 -- An extensible CHOICE of Int32 is used for authorization data 1132 -- types. 1134 KerberosV-TR-ID ::= Int32 1136 KerberosV-AD-ID ::= CHOICE { 1137 ad-int [0] Int32, 1138 ... 1139 } 1141 KerberosVSupportNego ::= SEQUENCE { 1142 enc-types [0] SEQUENCE OF Etype, 1143 ad-types [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL, 1144 -- authorization data types 1145 tr-enc-types [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL, 1146 -- transited encoding types 1147 ... 1148 } 1150 Request ::= [APPLICATION 0] SEQUENCE { 1151 pvno-minor [0] INTEGER DEFAULT 0, 1152 languages [1] SEQUENCE OF Language-Tag OPTIONAL, 1153 -- Should be defaulted to the SEQUENCE of "i-default" 1154 targ-name [2] PrincipalName OPTIONAL, 1155 targ-realm [3] Realm OPTIONAL, 1156 -- If targ-name/realm are missing then the request 1157 -- applies to the principal of the client 1158 dry-run [4] BOOLEAN DEFAULT FALSE, 1159 operation [5] Op-req, 1160 ... 1161 } 1163 Response ::= [APPLICATION 1] SEQUENCE { 1164 pvno-minor [0] INTEGER DEFAULT 0, 1165 language [1] Language-Tag DEFAULT "i-default", 1166 result [2] Op-rep, 1167 ... 1168 } 1170 Error-Response ::= [APPLICATION 2] SEQUENCE { 1171 pvno-minor [0] INTEGER DEFAULT 0, 1172 language [1] Language-Tag DEFAULT "i-default", 1173 error-code [2] ProtocolErrorCode, 1174 help-text [3] UTF8String OPTIONAL, 1175 op-error [4] Op-err OPTIONAL, 1176 ... 1177 } 1179 Op-req ::= CHOICE { 1180 null [0] Req-null, 1181 change-pw [1] Req-change-pw, 1182 set-pw [2] Req-set-pw, 1183 set-keys [3] Req-set-keys, 1184 gen-keys [4] Req-gen-keys, 1185 get-keys [5] Req-get-keys, 1186 commit-keys [6] Req-commit-keys, 1187 get-pw-policy [7] Req-get-pw-policy, 1188 get-princ-aliases [8] Req-get-princ-aliases, 1189 get-realm-krb5-support [9] Req-get-realm-krb5-support, 1190 get-s2kparams [10] Req-get-s2kparams, 1191 ... 1192 } 1194 Op-rep ::= CHOICE { 1195 null [0] Rep-null, 1196 change-pw [1] Rep-change-pw, 1197 set-pw [2] Rep-set-pw, 1198 set-keys [3] Rep-set-keys, 1199 gen-keys [4] Req-gen-keys, 1200 get-keys [5] Req-get-keys, 1201 commit-keys [6] Rep-commit-keys, 1202 get-pw-policy [7] Rep-get-pw-policy, 1203 get-princ-aliases [8] Rep-get-princ-aliases, 1204 get-realm-krb5-support [9] Rep-get-realm-krb5-support, 1205 get-s2kparams [10] Rep-get-s2kparams, 1206 ... 1207 } 1209 Op-err ::= CHOICE { 1210 null [0] Err-null, 1211 change-pw [1] Err-change-pw, 1212 set-pw [2] Err-set-pw, 1213 set-keys [3] Err-set-keys, 1214 gen-keys [4] Err-gen-keys, 1215 get-keys [5] Err-get-keys, 1216 commit-keys [6] Err-commit-keys, 1217 get-pw-policy [7] Err-get-pw-policy, 1218 get-princ-aliases [8] Err-get-princ-aliases, 1219 get-realm-krb5-support [9] Err-get-realm-krb5-support, 1220 get-s2kparams [10] Err-get-s2kparams, 1221 ... 1222 } 1224 ProtocolErrorCode ::= ENUM { 1225 proto-format-error, 1226 proto-unsupported-major-version, 1227 proto-unsupported-minor-version, 1228 proto-unsupported-operation, -- Request CHOICE tag unknown 1229 proto-generic-see-op-error, -- See Op-error 1230 proto-wrong-service-principal, -- Use kadmin/setpw 1231 proto-re-authentication-required, 1232 proto-initial-ticket-required, 1233 proto-client-and-target-realm-mismatch, 1234 proto-target-principal-unknown, 1235 proto-authorization-failed, 1236 proto-dry-run-not-permitted, 1237 ... 1238 } 1240 -- These codes are hints for clients, primarily for when they are 1241 -- used for changing the passwords of automated principals; error 1242 -- replies carry password quality policy help text that is more 1243 -- appropriate for clients to display to users. 1244 PW-Quality-Codes ::= ENUM { 1245 pwq-generic, 1246 pwq-too-soon, 1247 pwq-history, 1248 pwq-too-short, 1249 pwq-dictionary-words, 1250 pwq-prohibited-codepoints, 1251 pwq-need-more-char-classes, 1252 ... 1253 } 1255 -- 1256 -- Requests and responses 1257 -- 1259 -- NULL request, much like ONC RPC's NULL procedure - NOT extensible 1260 Req-null ::= NULL 1262 Rep-null ::= NULL 1264 Err-null ::= NULL 1266 -- Change password 1267 Req-change-pw ::= SEQUENCE { 1268 old-pw [0] Password, 1269 new-pw [1] Password OPTIONAL, 1270 commit [2] BOOLEAN DEFAULT TRUE, 1271 etypes [3] SEQUENCE (1..) OF Etype OPTIONAL, 1272 ... 1273 } 1275 Rep-change-pw ::= SEQUENCE { 1276 info-text [0] UTF8String OPTIONAL, 1277 new-pw [1] Password OPTIONAL, 1278 -- generated by the server if present 1279 -- (and requested by the client) 1280 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 1281 ... 1282 } 1284 Err-change-pw ::= SEQUENCE { 1285 help-text [0] UTF8String OPTIONAL, 1286 error [1] CHOICE { 1287 op-generic-error [0] Extensible-NULL, 1288 op-old-pw-incorrect [1] Extensible-NULL, 1289 op-wont-generate-new-pw [2] Extensible-NULL, 1290 op-new-pw-rejected-generic [3] SEQUENCE { 1291 policy [1] SEQUENCE OF UTF8String, 1292 suggested-pw [2] Password OPTIONAL, 1293 policy-codes [3] SET OF PW-Quality-Codes 1294 OPTIONAL, 1296 ... 1297 } 1298 op-etype-not-supported [4] SEQUENCE { 1299 supported-etypes [1] SEQUENCE OF Etype, 1300 ... 1301 }, 1302 ... 1303 }, 1304 ... 1305 } 1307 -- Set password 1308 Req-set-pw ::= SEQUENCE { 1309 languages [0] SEQUENCE OF Language-Tag OPTIONAL, 1310 new-pw [1] Password OPTIONAL, 1311 commit [2] BOOLEAN DEFAULT TRUE, 1312 etypes [3] SEQUENCE (1..) OF Etype OPTIONAL, 1313 ... 1314 } 1316 Rep-set-pw ::= SEQUENCE { 1317 info-text [0] UTF8String OPTIONAL, 1318 new-pw [1] Password OPTIONAL, 1319 -- generated by the server if present 1320 -- (and requested by the client) 1321 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 1322 ... 1323 } 1325 Err-set-pw ::= Err-change-pw 1327 -- Set keys 1328 Req-set-keys ::= SEQUENCE { 1329 keys [0] SEQUENCE OF Key, 1330 commit [1] BOOLEAN DEFAULT TRUE, 1331 -- TRUE -> install keys now 1332 -- 1333 -- FALSE -> require set-keys-commit 1334 -- before issuing tickets 1335 -- encrypted with these keys. 1336 -- 1337 -- See commit-keys op 1338 isupport [2] KerberosVSupportNego OPTIONAL, 1339 -- For future Kerberos V extensions KDCs 1340 -- may need to know what krb5 version is 1341 -- supported by individual service 1342 -- principals. This field provides a 1343 -- way to tell the KDC what version of 1344 -- Kerberos V the target principal 1345 -- supports. 1346 ... 1347 } 1349 Rep-set-keys ::= SEQUENCE { 1350 info-text [0] UTF8String OPTIONAL, 1351 kvno [1] UInt32, 1352 aliases [2] SEQUENCE OF SEQUENCE { 1353 name [0] PrincipalName, 1354 realm [1] Realm OPTIONAL, 1355 ... 1356 }, 1357 isupport [3] KerberosVSupportNego OPTIONAL, 1358 ... 1359 -- Should there be ETYPE-INFO2 stuff here? 1360 } 1362 Err-set-keys ::= SEQUENCE { 1363 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1364 error [1] CHOICE { 1365 op-generic [0] Extensible-NULL, 1366 op-deferred-commit-no-support [1] Extensible-NULL, 1367 op-etype-no-support [2] SEQUENCE OF { 1368 supported-etypes [1] SEQUENCE OF Etype, 1369 ... 1370 } 1371 ... 1372 } 1373 } 1375 -- Generate keys 1376 Req-gen-keys ::= SEQUENCE { 1377 etypes [0] SEQUENCE (1..) OF Etype, 1378 entropy [1] OCTET STRING OPTIONAL, 1379 commit [2] BOOLEAN DEFAULT TRUE, 1380 -- TRUE -> install keys now 1381 -- 1382 -- FALSE -> require set-keys-commit 1383 -- before issuing tickets 1384 -- encrypted with these keys. 1385 -- 1386 -- See commit-keys op 1387 isupport [3] KerberosVSupportNego OPTIONAL, 1388 -- For future Kerberos V extensions KDCs 1389 -- may need to know what krb5 version is 1390 -- supported by individual service 1391 -- principals. This field provides a 1392 -- way to tell the KDC what version of 1393 -- Kerberos V the target principal 1394 -- supports. 1395 ... 1396 } 1398 Rep-gen-keys ::= SEQUENCE { 1399 info-text [0] UTF8String OPTIONAL, 1400 kvno [1] UInt32, 1401 key [2] Key, 1402 aliases [3] SEQUENCE OF SEQUENCE { 1403 name [0] PrincipalName, 1404 realm [1] Realm OPTIONAL, 1405 ... 1406 }, 1407 isupport [4] KerberosVSupportNego OPTIONAL, 1408 ... 1409 -- Should there be ETYPE-INFO2 stuff here? 1410 } 1412 Err-gen-keys ::= Err-set-keys 1414 -- Get un-committed key request 1415 Req-get-keys ::= SEQUENCE { 1416 kvno [0] UInt32, 1417 ... 1418 } 1420 Rep-get-keys ::= SEQUENCE { 1421 info-text [0] UTF8String OPTIONAL, 1422 keys [1] SEQUENCE OF Key, 1423 aliases [2] SEQUENCE OF SEQUENCE { 1424 name [0] PrincipalName, 1425 realm [1] Realm OPTIONAL, 1426 ... 1427 }, 1428 isupport [3] KerberosVSupportNego OPTIONAL, 1429 ... 1430 -- Should there be ETYPE-INFO2 stuff here? 1431 } 1433 Err-get-keys ::= SEQUENCE { 1434 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1435 error [1] CHOICE { 1436 op-generic [0] Extensible-NULL, 1437 op-kvno-committed [1] Extensible-NULL, 1438 op-no-such-kvno [1] Extensible-NULL, 1439 ... 1441 } 1442 } 1444 -- Commit a set keys request 1445 Req-commit-keys ::= SEQUENCE { 1446 kvno [0] UInt32, 1447 ... 1448 } 1450 Rep-commit-keys ::= Extensible-NULL 1452 Err-commit-keys ::= SEQUENCE { 1453 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1454 error [1] CHOICE { 1455 op-generic [0] Extensible-NULL, 1456 op-kvno-expired [1] Extensible-NULL, 1457 -- The client took too long to respond. 1458 op-kvno-unknown [2] Extensible-NULL, 1459 -- The targ princ/kvno is invalid or unknown to the 1460 -- server (perhaps it lost track of state) 1461 op-new-keys-conflict [3] Extensible-NULL, 1462 -- A new-keys/commit-keys request subsequent to the 1463 -- new-keys that produced the kvno has completed 1464 -- and incremented the principal's kvno 1465 ... 1466 } 1467 ... 1468 } 1470 -- Get password policy 1471 Req-get-pw-policy ::= Extensible-NULL 1473 Rep-get-pw-policy ::= SEQUENCE { 1474 policy-name [0] UTF8String OPTIONAL, 1475 description [1] SEQUENCE OF UTF8String OPTIONAL, 1476 ... 1477 } 1479 Err-get-pw-policy ::= Extensible-NULL 1481 -- Get principal aliases 1482 Req-get-princ-aliases ::= Extensible-NULL 1484 Rep-get-princ-aliases ::= SEQUENCE { 1485 help-text [0] UTF8String OPTIONAL, 1486 aliases [1] SEQUENCE OF SEQUENCE { 1487 name [0] PrincipalName, 1488 realm [1] Realm OPTIONAL, 1489 ... 1490 }, 1491 ... 1492 } 1494 Err-get-princ-aliases ::= Extensible-NULL 1496 -- Get list of enctypes supported by KDC for new keys 1497 Req-get-realm-krb5-support ::= Extensible-NULL 1499 Rep-get-realm-krb5-support ::= SEQUENCE { 1500 isupport [0] KerberosVSupportNego, 1501 -- Version of Kerberos V supported by 1502 -- the target realm. 1503 ... 1504 } 1506 Err-get-realm-krb5-support ::= Extensible-NULL 1508 -- Get s2kparams 1509 Req-get-s2kparams ::= Extensible-NULL 1511 Rep-get-s2kparams ::= SEQUENCE { 1512 help-text [0] UTF8String OPTIONAL, 1513 s2kparams [1] SEQUENCE OF Etype-Info-Entry, 1514 ... 1515 } 1517 Err-get-s2kparams ::= Extensible-NULL 1519 END 1521 6. Security Considerations 1523 Implementors and site administrators should note that the redundancy 1524 of UTF-8 encodings of passwords varies by language. Password quality 1525 policies SHOULD, therefore, take this into account when estimating 1526 the amount of redundancy and entropy in a proposed new password. 1528 Kerberos set/change password/key protocol major version negotiation 1529 cannot be done securely; a downgrade attack is possible against 1530 clients that attempt to negotiate the protocol major version to use 1531 with a server. It is not clear at this time that the attacker would 1532 gain much from such a downgrade attack other than denial of service 1533 (DoS) by forcing the client to use a protocol version which does not 1534 support some feature needed by the client (Kerberos V in general is 1535 subject to a variety of DoS attacks anyways [RFC4120]). Clients 1536 SHOULD NOT negotiate support for legacy major versions of this 1537 protocol unless configured otherwise. 1539 This protocol does not have Perfect Forward Security (PFS). As a 1540 result, any passive network snooper watching password/key changing 1541 operations who has stolen a principal's password or long-term keys 1542 can find out what the new ones are. 1544 7. Normative 1546 [CCITT.X680.2002] 1547 International International Telephone and Telegraph 1548 Consultative Committee, "Abstract Syntax Notation One 1549 (ASN.1): Specification of basic notation", 1550 CCITT Recommendation X.680, July 2002. 1552 [CCITT.X690.2002] 1553 International International Telephone and Telegraph 1554 Consultative Committee, "ASN.1 encoding rules: 1555 Specification of basic encoding Rules (BER), Canonical 1556 encoding rules (CER) and Distinguished encoding rules 1557 (DER)", CCITT Recommendation X.690, July 2002. 1559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1560 Requirement Levels", BCP 14, RFC 2119, March 1997. 1562 [RFC3066] Alvestrand, H., "Tags for the Identification of 1563 Languages", BCP 47, RFC 3066, January 2001. 1565 [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows 1566 2000 Kerberos Change Password and Set Password Protocols", 1567 RFC 3244, February 2002. 1569 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1570 Kerberos Network Authentication Service (V5)", RFC 4120, 1571 July 2005. 1573 Author's Address 1575 Nicolas Williams 1576 Sun Microsystems 1577 5300 Riata Trace Ct 1578 Austin, TX 78727 1579 US 1581 Email: Nicolas.Williams@sun.com 1583 Intellectual Property Statement 1585 The IETF takes no position regarding the validity or scope of any 1586 Intellectual Property Rights or other rights that might be claimed to 1587 pertain to the implementation or use of the technology described in 1588 this document or the extent to which any license under such rights 1589 might or might not be available; nor does it represent that it has 1590 made any independent effort to identify any such rights. Information 1591 on the procedures with respect to rights in RFC documents can be 1592 found in BCP 78 and BCP 79. 1594 Copies of IPR disclosures made to the IETF Secretariat and any 1595 assurances of licenses to be made available, or the result of an 1596 attempt made to obtain a general license or permission for the use of 1597 such proprietary rights by implementers or users of this 1598 specification can be obtained from the IETF on-line IPR repository at 1599 http://www.ietf.org/ipr. 1601 The IETF invites any interested party to bring to its attention any 1602 copyrights, patents or patent applications, or other proprietary 1603 rights that may cover technology that may be required to implement 1604 this standard. Please address the information to the IETF at 1605 ietf-ipr@ietf.org. 1607 Disclaimer of Validity 1609 This document and the information contained herein are provided on an 1610 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1611 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1612 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1613 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1614 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1615 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1617 Copyright Statement 1619 Copyright (C) The Internet Society (2006). This document is subject 1620 to the rights, licenses and restrictions contained in BCP 78, and 1621 except as set forth therein, the authors retain all their rights. 1623 Acknowledgment 1625 Funding for the RFC Editor function is currently provided by the 1626 Internet Society.