idnits 2.17.1 draft-ietf-krb-wg-kerberos-set-passwd-08.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, updated by RFC 4748 on line 1600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1624. 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 IETF Trust 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 (November 3, 2008) is 5647 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) -- Looks like a reference, but probably isn't: '1' on line 1515 -- Looks like a reference, but probably isn't: '0' on line 1514 -- Looks like a reference, but probably isn't: '2' on line 1466 == Missing Reference: 'APPLICATION 0' is mentioned on line 1177, but not defined -- Looks like a reference, but probably isn't: '3' on line 1469 -- Looks like a reference, but probably isn't: '4' on line 1422 -- Looks like a reference, but probably isn't: '5' on line 1243 == Missing Reference: 'APPLICATION 1' is mentioned on line 1191, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 1198, but not defined -- Looks like a reference, but probably isn't: '6' on line 1244 -- Looks like a reference, but probably isn't: '7' on line 1245 -- Looks like a reference, but probably isn't: '8' on line 1246 -- Looks like a reference, but probably isn't: '9' on line 1247 -- Looks like a reference, but probably isn't: '10' on line 1248 ** Downref: Normative reference to an Informational RFC: RFC 3244 ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 18 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: May 7, 2009 November 3, 2008 6 Kerberos Set/Change Key/Password Protocol Version 2 7 draft-ietf-krb-wg-kerberos-set-passwd-08.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 March 27, 2009. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 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 . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Conventions used in this document . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 11 61 4.1 Password Quality Policies . . . . . . . . . . . . . . . . 11 62 4.1.1 Standard Password Quality Policies . . . . . . . . . . . . 12 63 4.2 PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 4.3 Operations . . . . . . . . . . . . . . . . . . . . . . . . 15 65 4.3.1 Null . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 4.3.2 Change Kerberos Password . . . . . . . . . . . . . . . . . 15 67 4.3.3 Set Kerberos Password . . . . . . . . . . . . . . . . . . 18 68 4.3.4 Set Kerberos Keys . . . . . . . . . . . . . . . . . . . . 20 69 4.3.5 Generate Kerberos Keys . . . . . . . . . . . . . . . . . . 22 70 4.3.6 Get New Keys . . . . . . . . . . . . . . . . . . . . . . . 23 71 4.3.7 Commit New Keys . . . . . . . . . . . . . . . . . . . . . 24 72 4.3.8 Get Password Quality Policy . . . . . . . . . . . . . . . 25 73 4.3.9 Get Principal Aliases . . . . . . . . . . . . . . . . . . 26 74 4.3.10 Get Realm's Supported Kerberos V Version and Features . . 26 75 4.3.11 Retrieve Principal's S2K Params and Preferred Params . . . 27 76 4.4 Principal Aliases . . . . . . . . . . . . . . . . . . . . 27 77 4.5 Kerberos V Feature Negotiation . . . . . . . . . . . . . . 27 78 5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . 29 79 6. Security Considerations . . . . . . . . . . . . . . . . . 39 80 7. Normative References . . . . . . . . . . . . . . . . . . . 39 81 Author's Address . . . . . . . . . . . . . . . . . . . . . 40 82 Intellectual Property and Copyright Statements . . . . . . 41 84 1. Introduction 86 Up to this point Kerberos V has lacked a single, standard protocol 87 for changing passwords and keys. While several vendor-specific 88 protocols exist for changing Kerberos passwords/keys, none are 89 properly internationalized and all are incomplete in one respect or 90 another and none are sufficiently extensible to cope with new 91 features that may be added to Kerberos V at some future time. 93 This document defines a protocol that is somewhat backward-compatible 94 with the "kpasswd" protocol defined in [RFC3244] that uses more or 95 less the same protocol framing. 97 This new protocol is designed to be extensible and properly 98 internationalized. 100 2. Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. The Protocol 108 The structure of the protocol is quite similar to that of typical 109 Remote Procedure Call (RPC) protocols. Each transaction consists of 110 a data structure specific to an operation which is then wrapped in a 111 data structure which is general to all operations of the protocol. 112 These data structures are defined with the Abstract Syntax Notation 1 113 (ASN.1) [CCITT.X680.2002] and they are encoded using the 114 Distinguished Encoding Rules (DER) [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 SHOULD accept requests on TCP port 464, the 124 same 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 Servers MAY force the use of INITIAL or fresh tickets for any 242 requests -- see Section 4.3. Traditionally users with expired 243 passwords are allowed only INITIAL tickets for the password changing 244 server, therefore clients MUST support the use of INITIAL tickets. 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 [RFC4646] and [RFC4647]) for text in its 291 responses which 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 in 313 some places, particularly extensible CHOICEs. As such, the module 314 presented herein can be extended within the framework of 315 [CCITT.X680.2002]. 317 Typed holes are not used in this protocol as it is very simple and 318 does not require the ability to deal with abstract data types defined 319 in different layers. For this reason, the only way to extend this 320 protocol is by extending the ASN.1 module within the framework of the 321 IETF; all future extensions to this protocol have to be defined in 322 IETF documents unless otherwise specified in a future IETF revision 323 of this protocol. 325 A protocol minor version number is used to negotiate use of 326 extensions. See Section 3.2.2 for the minor version negotiation. 328 Servers SHOULD ignore unknown additions to the ASN.1 types, in 329 initial requests, where the syntax allows them, except for extensions 330 to the "Op-req" type, which MUST result in an error. 332 Servers MUST respond with an error (ProtocolErrorCode value of proto- 333 unsupported-operation) to clients that use operations unknown to the 334 server. 336 3.7 Protocol Subsets 338 The structure of the protocol is such that the ASN.1 syntaxes for the 339 various operations supported by the protocol are independent of the 340 each other. Client and server implementations MAY implement subsets 341 of the overall protocol by removing some alternatives to the Op-req, 342 Op-rep and Op-err CHOICEs from the ASN.1 module given in Section 5. 344 For example, it should be possible to have a password-change only 345 client that cannot set principal's keys - and vice versa. 347 The following operations are REQUIRED to implement: 349 o Null 351 o Change Kerberos Password (with commit == TRUE) 353 o Set Kerberos Password (with commit == TRUE) 355 o Generate Kerberos Keys 357 o Get Password Quality Policy 359 4. Protocol Elements 361 The protocol as defined herein supports the following operations 362 relating to the management of Kerberos principal's passwords or keys: 364 o change password (or enctypes and string-to-key parameters) 366 o set password (administrative) 368 o set new keys 370 o generate new keys 372 o get new, un-committed keys 374 o commit new keys 376 o get password policy name and/or description of principal 378 o list aliases of a principal 380 o list enctypes and version of Kerberos V supported by realm 382 The operation for retrieving a list of aliases of a principal is 383 needed where KDCs implement aliasing of principal names and allows 384 clients to properly setup their key databases when principal aliasing 385 is in use. 387 Operations such as creation or deletion of principals are outside the 388 scope of this document, and should be performed via other means, such 389 as through directories or other Kerberos administration protocols. 391 The individual operations are described in Section 4.3. 393 4.1 Password Quality Policies 395 Servers may reject new user passwords for failing to meet password 396 quality policies. When this happens the server must be able to 397 communicate the policy to the user so that the user may select a 398 better password. 400 The protocol allows for two ways to do this: 402 o through error codes that identify specific password quality 403 policies known; 405 o through localized error strings. 407 The use of localized error strings allows servers to convey non- 408 standard password quality policies to users, but it requires server- 409 side message catalogs for localization and support for language 410 negotiation. The use of error codes only allows for standard 411 password quality policies that clients must be aware of a priori, 412 therefore use of error codes requires the distribution of new message 413 catalogs to clients whenever new error codes are added; this 414 simplifies servers at the expense of password quality extensibility. 416 When a server would reject a password due to its failing to meet a 417 standard password quality policy the the server MUST use the 418 appropriate error codes (see below) and the server SHOULD send a 419 localized error message to the user. 421 When a server would reject a password due to its failing to meet a 422 non-standard password quality policy (one not described herein) the 423 the server MUST send a localized error message to the user. 425 4.1.1 Standard Password Quality Policies 427 o pwq-too-soon 429 It is too soon for the principal to change its password or long- 430 term keys. 432 o pwq-history 434 The new password is one that the principal has used before or is 435 too similar to a password that it has used before. 437 o pwq-too-short 439 The new password is too short. 441 o pwq-dictionary-words 443 The new password is or contains words that are in the dictionary. 445 o pwq-prohibited-codepoints 447 The new password contains prohibited codepoints. 449 o pwq-need-more-char-classes 451 The new password does not have characters from enough character 452 classes (lower-case letters, upper-case letters, digits, 453 punctuation, etc...). 455 4.2 PDUs 457 The types "Request," "Response" and "Error-Response" are the ASN.1 458 module's PDUs. 460 The "Request" and "Response" PDUs are always to be sent wrapped in 461 KRB-PRIV messages, except for the "Error-Response" PDU which MUST be 462 sent as KRB-ERROR e-data (see Section 3.3) when AP exchanges fail, 463 otherwise it MUST be sent wrapped in a KRB-PRIV. 465 The ASN.1 syntax for the PDUs is given in Section 5. 467 Note that the first field of each PDU is the major version of the 468 protocol, defaulted to 2, meaning that it is never included in 469 version 2 exchanges. Similarly, the second field of each PDU is the 470 minor version, defaulted to 0. 472 The request, responses and error PDUs consist of an outer structure 473 ("Request," "Response" and "Error-Response") containing fields common 474 to all requests, responses and errors, respectively, and an inner 475 structure for fields that are specific to each operation's requests/ 476 responses. The inner structure is optional in the case of the Error- 477 Response PDU and need not be included when generic errors occur for 478 which there is a suitable ProtocolErrorCode. 480 Specifically, the outer Request structure has a field for passing a 481 client user's spoken (read) languages to the server. It also has two 482 optional fields for identifying the requested operation's target 483 principal's name and realm (if not sent then the server MUST use the 484 client's principal name and realm as the target). A boolean field 485 for indicating whether or not the request should be dry-run is also 486 included; dry-runs can be used to test server policies, and servers 487 MUST NOT modify any principals when processing dry-run requests. 489 The Response and Error PDUs' outer structures include a field 490 indicating the language that the server has chosen for localization 491 of text intended to be displayed to users; this field is defaulted to 492 "i-default". This language tag applies to all UTF8 strings in the 493 inner structure (Op-rep and Op-err) that are meant to be displayed to 494 users. 496 The protocol error codes are: 498 o proto-generic-error 500 An operation-specific error ocurred, see the inner Op-error. 502 o proto-format-error 504 The server failed to parse a message sent by the client. 506 o proto-unsupported-major-version 508 The server does not support the major version of this protocol 509 requested by the client. 511 o proto-unsupported-minor-version 513 The server does not support the minor version of this protocol 514 requested by the client. 516 o proto-unsupported-operation 518 The server does not support the operation requested by the client. 520 o proto-wrong-service-principal 522 Use kadmin/setpw for the server's principal name. 524 o proto-re-authentication-required 526 The server demands that the client re-authenticate through a new 527 AP exchange. 529 o proto-initial-ticket-required 531 Use of an INITIAL ticket is required for the requested operation. 533 o proto-client-and-target-realm-mismatch 535 The server requires that the client's principal name and the 536 target principal of the operation share the same realm name. 538 o proto-target-principal-unknown 540 The target of the client's operation is not a valid principal. 542 o proto-authorization-failed 543 The client principal is not authorized to perform the requested 544 operation. 546 o proto-fresh-ticket-required 548 The server would like the client to re-authenticate using a fresh 549 ticket. 551 4.3 Operations 553 This section describes the semantics of each operation request and 554 response defined in the ASN.1 module in Section 5. 556 4.3.1 Null 558 NAME 560 null - Null or "ping" operation 562 DESCRIPTION 564 The null request is intended for use with TCP; its purpose is 565 similar to RPC null procedures and is akin to a "ping" operation. 567 ERRORS 569 None. 571 4.3.2 Change Kerberos Password 573 NAME 575 change-pw - Change password operation 577 SYNOPSIS 579 Req-change-pw(old-pw, [languages], [new-pw], 580 commit?, [etypes]) -> 581 Rep-change-pw([info-text], [new-pw], [etypes]) | 582 Err-change-pw([help-text], error code, [error info]) 584 DESCRIPTION 586 Change a principal's password. 588 The change password request has one required, three optional and 589 one defaulted arguments: "old-pw" (required), "languages," 590 "new-pw", "commit" (defaults to "TRUE") and "etypes", 591 corresponding to the target principal's old password, its 592 preferred languages, its new password, a boolean indicating 593 whether or not to make the new long-term key available for 594 immediate use, and the desired enctypes for the new long-term 595 keys. 597 The server MUST validate the old password and MUST check the 598 quality of the new password, if sent, according the password 599 quality policy associated with the target principal. 601 If the old and new passwords in the request are the same strings, 602 and the principal is not currently required to change its 603 password, then the server MAY permit the password change as way to 604 change a principal's enctypes and string-to-key parameters. This 605 feature provides a way to, for example, add enctypes to a 606 principals' password-derived long-term keys without forcing a 607 password change following an upgrade to the KDC that adds support 608 for new enctypes. 610 A client MAY request that the server generate a new password by 611 excluding the new password from its request, in which case the 612 server MUST either generate a new password or respond with an 613 error indicating that it does not support this feature. 615 Server-generated passwords MUST meet the target principal's 616 password quality policy. It is RECOMMENDED that server-generated 617 passwords be user-friendly, that is, memorable and that the target 618 principal's preferred languages be taken into account by the 619 password generation alogrithm used by the server. 621 When "commit" is true the KDC makes the keys derived from the new 622 password available for issueing tickets encrypted in them 623 immediately. Otherwise the client MUST follow up with a 624 commit-keys request to make the keys available. This feature is 625 useful for changing keys shared by multiple hosts, in clustered 626 services, for example, in an atomic manner. 628 RETURN 630 Upon successful password changes the server responds with a 631 Rep-change-pw. The fields of Rep-change-pw are all optional and 632 include: 634 - 'info-text' which the server can use to send a message to the 635 user such as "Your new password will expire in 90 days," for 636 example. 638 - 'new-pw' which the server MUST include if the client 639 requested that the server generate a new password; generated 640 passwords MUST pass the target principal's password quality 641 policy. 643 - 'etypes' which the server MAY include to indicate which types 644 of long-term keys it created for the target principal and 645 which the server MUST include if the client specified a set 646 of enctypes in its request. 648 ERRORS 650 The server may respond to change password requests with protocol 651 or operation errors. 653 All operation errors include an optional 'help-text' field by 654 which the server can describe the error in a human-readable, 655 localizaed string. 657 Change password error codes include: 659 - generic-error 661 - old-pw-incorrect 663 - wont-generate-new-pw 665 The server will not generate a new password for this 666 principal or does not support password generation in general. 668 - new-pw-rejected-generic 670 The client's proposed new password failed the target 671 principal's password quality policy. 673 The server MUST include a description of the password quality 674 policy or aspect of it that the client's proposed new 675 password failed to meet. 677 The server MAY generate and send a new password that the 678 client can then use as a new password and which is guaranteed 679 to pass the target principal's current password quality 680 policy. 682 The server MAY include a set of policy error code hints. 684 - etype-not-supported 686 The client requested an enctype that the KDC does not 687 support. 689 4.3.3 Set Kerberos Password 691 NAME 693 set-pw - Set password operation 695 SYNOPSIS 697 Req-set-pw([languages], [new-pw], commit?, [etypes]) -> 698 Rep-set-pw([info-text], [new-pw], [etypes]) | 699 Err-set-pw([help-text], error code, [error info]) 701 DESCRIPTION 703 Administratively set a principal's password. 705 The set password request has three optional and one defaulted 706 arguments: "languages", "new-pw," "commit" (defaulted to "TRUE") 707 and "etypes", corresponding to the target principal's preferred 708 languages, new password, a boolean indicating whether or not to 709 make the new long-term key available for immediate use, and the 710 desired enctypes for the new long-term keys. 712 The server MUST check the quality of the new password, if sent, 713 according the password quality policy associated with the target 714 principal. 716 The server SHOULD require that the client use the change-pw 717 operation instead of set-pw when the client principal and the 718 target principal are the same. 720 A client MAY request that the server generate a new password by 721 excluding the new password from its request, in which case the 722 server MUST either generate a new password or respond with an 723 error indicating that it does not support this feature. 725 Server-generated passwords MUST meet the target principal's 726 password quality policy. It is RECOMMENDED that server-generated 727 passwords be user-friendly, that is, memorable and that the target 728 principal's preferred languages be taken into account by the 729 password generation alogrithm used by the server. 731 When "commit" is true the KDC makes the keys derived from the new 732 password available for issueing tickets encrypted in them 733 immediately. Otherwise the client MUST follow up with a 734 commit-keys request to make the keys available. This feature is 735 useful for changing keys shared by multiple hosts, in clustered 736 services, for example, in an atomic manner. 738 RETURN 740 Upon successfully setting a password the server responds with a 741 Rep-set-pw. The fields of Rep-set-pw are all optional and 742 include: 744 - 'info-text' which the server can use to send a message to the 745 user such as "Your new password will expire in 90 days," for 746 example. 748 - 'new-pw' which the server MUST include if the client 749 requested that the server generate a new password; generated 750 passwords MUST pass the target principal's password quality 751 policy. 753 - 'etypes' which the server MAY include to indicate which types 754 of long-term keys it created for the target principal and 755 which the server MUST include if the client specified a set 756 of enctypes in its request. 758 ERRORS 760 The server may respond to set password requests with protocol or 761 operation errors. 763 All operation errors include an optional 'help-text' field by 764 which the server can describe the error in a human-readable, 765 localizaed string. 767 Set password error codes include: 769 - generic-error 770 - use-change-pw 772 The server demands that the client use the change-pw 773 operation for the target principal of the set-pw request. 775 - wont-generate-new-pw 777 The server will not generate a new password for this 778 principal or does not support password generation in general. 780 - new-pw-rejected-generic 782 The client's proposed new password failed the target 783 principal's password quality policy. 785 The server MUST include a description of the password quality 786 policy or aspect of it that the client's proposed new 787 password failed to meet. 789 The server MAY generate and send a new password that the 790 client can then use as a new password and which is guaranteed 791 to pass the target principal's current password quality 792 policy. 794 The server MAY include a set of policy error code hints. 796 - etype-not-supported 798 The client requested an enctype that the KDC does not 799 support. 801 4.3.4 Set Kerberos Keys 802 NAME 804 set-keys - Set a principal's long-term keys 806 SYNOPSIS 808 Req-set-keys(new-keys, commit?, [isupport]) -> 809 Rep-set-keys([info-text], kvno, aliases, [isupport]) 811 DESCRIPTION 813 The set-keys request consists of two required fields and one 814 optional field: "new-keys", "commit" (a boolean field - see below) 815 and "isupport", an optional field for indicating to the KDC what 816 Kerberos V features are supported by the target principal. 818 When "commit" is true the KDC makes the new keys available for 819 issueing tickets encrypted in them immediately. Otherwise the 820 client MUST follow up with a commit-keys request to make the keys 821 available. This feature is useful for changing keys shared by 822 multiple hosts, in clustered services, for example, in an atomic 823 manner. 825 If a principal has keys are awaiting commitment when a new 826 set-keys request for that principal s made then the KDC MUST 827 overwrite the deferred keys. 829 RETURN 831 For successful set-keys operations the server returns: 833 - Informational text, optional. 835 - The new kvno for the target principal. 837 - A list of aliases of the target principal known to the KDC 838 (optional). 840 - The set of Kerberos V features supported by the KDC 841 (optional). 843 ERRORS 845 The server may respond with the following errors: 847 - generic 848 - deferred-commit-no-support 849 - etype-no-support 851 4.3.5 Generate Kerberos Keys 853 NAME 855 gen-keys - Generate long-term keys for a principal 857 SYNOPSIS 859 Req-gen-keys(etypes, [entropy], commit?, [isupport]) -> 860 Rep-set-keys([info-text], key, kvno, aliases, [isupport]) 862 DESCRIPTION 864 The gen-keys is similar to the set-keys request but differs in 865 that the server generates keys of client-requested enctypes, 866 rather than the client providing specific keys. 868 The gen-keys request consists of two required fields and two 869 optional fields: "etypes" (the enctypes of the new keys), 870 "entropy", "commit" and "isupport". 872 If a principal has keys are awaiting commitment when a new 873 set-keys request for that principal s made then the KDC MUST 874 overwrite the deferred keys. 876 RETURN 878 For successful set-keys operations the server returns: 880 - Informational text, optional. 882 - The new kvno for the target principal. 884 - The new key (only one is needed). 886 - A list of aliases of the target principal known to the KDC 887 (optional). 889 - The set of Kerberos V features supported by the KDC 890 (optional). 892 ERRORS 894 The server may respond with the following errors: 896 - generic 897 - deferred-commit-no-support 898 - etype-no-support 900 4.3.6 Get New Keys 902 NAME 904 get-keys - Retrieve a principal's uncommitted keys 906 SYNOPSIS 908 Req-get-keys(kvno) -> 909 Rep-get-keys([info-text], keys, aliases, [isupport]) | 910 Err-get-keys([help-text], error code, [error info]) 912 DESCRIPTION 914 This request allows a client to get the keys set or generated in a 915 previous set-keys or gen-keys request with deferred commitment. 917 RETURN 919 If the target principal and kvno correspond to uncommitted keys 920 the server SHOULD respond with the actual keys that would be set 921 by a subsequent commit-keys request. Otherwise the server MUST 922 respond with an error (meaning that this operation cannot be used 923 to extract keys from the KDC that may be in use). 925 ERRORS 927 - generic 928 - kvno-committed 929 - no-such-kvno 931 4.3.7 Commit New Keys 933 NAME 935 commit-keys - Commit a principal's new long-term keys 937 SYNOPSIS 939 Req-commit-keys(kvno) -> 940 Rep-commit-keys() | 941 Err-commit-keys([help-text], error code, [error info]) 943 DESCRIPTION 945 The commit-keys operation allows a client to bring a principal's 946 new keys into use at the KDC. 948 Clients should make a commit-keys request corresponding to a 949 deferred commitment set-keys/gen-keys operation as soon as the 950 local key database for the target principal is updated. 952 The target principal name and the kvno MUST match those from a 953 prior set-keys or gen-keys operation. 955 Servers MAY expire delayed key commitments at will. Servers 956 SHOULD expire uncommitted new keys after a reasonable amount of 957 time (600 seconds is RECOMMENDED). 959 Servers MUST respond to new set-keys requests for principals with 960 pending, uncommitted new keys by expiring the uncommitted new keys 961 and proceeding as if there had been no expired new keys. 963 ERRORS 965 - generic 966 - op-kvno-expired 967 - op-kvno-unknown 968 - new-keys-conflict (A set-keys or gen-keys request succeeded 969 subsequent to the request that matches this 970 {principal, kvno} tuple.) 972 4.3.8 Get Password Quality Policy 974 NAME 976 get-pw-policy - Retrieve a principal's password policy 978 SYNOPSIS 980 Req-get-pw-policy() -> 981 Rep-get-pw-policy([policy name], [policy description]) 983 DESCRIPTION 985 Returns a description of the target principal's associated 986 password quality policy, if any, as a list of localized 987 UTF8String values. 989 Clients can use this operation in conjunction with the change-pw 990 operation to obtain text that can be displayed to the user before 991 the user actually enters a new password. 993 It is common for sites to set policies with respect to password 994 quality. It is beyond the scope of this document to describe such 995 policies. Management of password quality policies' actual content 996 is also beyond the scope of this protocol. 998 ERRORS 1000 No operation errors are defined. 1002 4.3.9 Get Principal Aliases 1004 NAME 1006 get-princ-aliases - Retrieve a principal's aliases 1008 SYNOPSIS 1010 Req-get-princ-aliases() -> 1011 Rep-get-princ-aliases(aliases) 1013 DESCRIPTION 1015 Returns a list of aliases of the target principal. 1017 ERRORS 1019 No operation-specific errors. 1021 4.3.10 Get Realm's Supported Kerberos V Version and Features 1023 NAME 1025 get-realm-krb5-support - List features supported by the realm 1027 SYNOPSIS 1029 Req-get-realm-krb5-support() -> 1030 Rep-get-realm-krb5-support(isupport) 1032 DESCRIPTION 1034 Returns set of Kerberos V features support by the target 1035 principal's realm's KDCs. 1037 ERRORS 1039 No operation-specific errors. 1041 4.3.11 Retrieve Principal's S2K Params and Preferred Params 1043 NAME 1045 get-s2kparams 1047 SYNOPSIS 1049 Req-get-s2kparams() -> 1050 Rep-get-s2kparams(princ-s2kparams) 1052 DESCRIPTION 1054 Returns the string2key parameters for the principal's current 1055 password-derived long-term keys, if any (if there are none then 1056 the principal does not have a password-derived long-term key). 1058 ERRORS 1060 No operation-specific errors. 1062 4.4 Principal Aliases 1064 Applications that use Kerberos often have to derive acceptor 1065 principal names from hostnames entered by users. Such hostnames may 1066 be aliases, they may be fully qualified, partially qualified or not 1067 qualified at all. Some implementations have resorted to deriving 1068 principal names from such hostnames by utilizing the names services 1069 to canonicalize the hostname first; such practices are not secure 1070 unless the name service are secure, which often aren't. 1072 One method for securely deriving principal names from hostnames is to 1073 alias principals at the KDC such that the KDC will issue tickets for 1074 principal names which are aliases of others. It is helpful for 1075 principals to know what are their aliases as known by the KDCs. 1077 Note that changing a principal's aliases is out of scope for this 1078 protocol. 1080 4.5 Kerberos V Feature Negotiation 1082 Principals and realms' KDCs may need to know about additional 1083 Kerberos V features and extensions that they each support. Several 1084 operations (see above) provide a way for clients and servers to 1085 exchange such infomration, in the form of lists of types supported 1086 for the various typed holes used in Kerberos V. 1088 5. ASN.1 Module 1090 DEFINITIONS EXPLICIT TAGS ::= BEGIN 1091 -- 1092 -- Note: EXPLICIT tagging is in use by default throughout this 1093 -- module. 1095 -- From [clarifications] with modifications 1096 PrincipalName ::= SEQUENCE { 1097 name-string [1] SEQUENCE OF UTF8String (IA5String, ...) 1098 } 1099 Realm ::= UTF8String (IA5String, ...) 1100 Salt ::= UTF8String (IA5String, ...) 1101 Password ::= UTF8String (IA5String, ...) 1103 -- NOTE WELL: Principal and realm names MUST be constrained by the 1104 -- specification of the version of Kerberos V used by the 1105 -- client. 1107 -- 1108 -- [Perhaps PrincipalName should be a SEQUENCE of an optional name 1109 -- type and a UTF8String, for simplicity.] 1111 -- From [clarifications] 1112 Int32 ::= INTEGER (-2147483648..2147483647) 1113 UInt32 ::= INTEGER (0..4294967295) 1115 -- Based on [clarifications] 1116 Etype ::= Int32 1117 Etype-Info-Entry ::= SEQUENCE { 1118 etype [0] Etype, 1119 salt [1] Salt OPTIONAL, 1120 s2kparams [2] OCTET STRING OPTIONAL 1121 } 1122 Key ::= SEQUENCE { 1123 enc-type [0] Etype, -- from Kerberos 1124 key [1] OCTET STRING 1125 } 1127 Language-Tag ::= UTF8String -- Constrained by [RFC4646] 1129 -- Empty, extensible SEQUENCEs are legal ASN.1 1130 Extensible-NULL ::= SEQUENCE { 1131 ... 1132 } 1133 -- Kerberos clients negotiate some parameters relating to their peers 1134 -- indirectly through the KDC. Today this is true of ticket session 1135 -- key enctypes, but in the future this indirect negotiation may also 1136 -- occur with respect to the minor version of Kerberos V to be used 1137 -- between clients and servers. Additionally, KDCs may need to know 1138 -- what authorization-data types are supported by service principals, 1139 -- both, for compatibility with legacy software and for optimization. 1140 -- 1141 -- Thesefore it is important for KDCs to know what features of 1142 -- Kerberos V each service principal supports. 1143 -- 1144 -- In version 2.0 of this protocol the clients and servers may notify 1145 -- each other of their support for: 1146 -- 1147 -- - enctypes 1148 -- - authorization data types 1149 -- - transited encoding data types 1150 -- 1151 -- All authorization-data types defined in [clarifications] are 1152 -- assumed to be supported if the minor version is 1 and do not need 1153 -- to be included in the ad-type list. 1154 -- 1155 -- Int32 is used for enctype and transited encoding data type 1156 -- identifiers. 1158 -- 1159 -- An extensible CHOICE of Int32 is used for authorization data 1160 -- types. 1162 KerberosV-TR-ID ::= Int32 1164 KerberosV-AD-ID ::= CHOICE { 1165 ad-int [0] Int32, 1166 ... 1167 } 1169 KerberosVSupportNego ::= SEQUENCE { 1170 enc-types [0] SEQUENCE OF Etype, 1171 ad-types [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL, 1172 -- authorization data types 1173 tr-enc-types [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL 1174 -- transited encoding types 1175 } 1177 Request ::= [APPLICATION 0] SEQUENCE { 1178 pvno-minor [0] INTEGER DEFAULT 0, 1179 languages [1] SEQUENCE OF Language-Tag OPTIONAL, 1180 -- Should be defaulted to the SEQUENCE of "i-default" 1182 targ-name [2] PrincipalName OPTIONAL, 1183 targ-realm [3] Realm OPTIONAL, 1184 -- If targ-name/realm are missing then the request 1185 -- applies to the principal of the client 1186 dry-run [4] BOOLEAN DEFAULT FALSE, 1187 operation [5] Op-req, 1188 ... 1189 } 1191 Response ::= [APPLICATION 1] SEQUENCE { 1192 pvno-minor [0] INTEGER DEFAULT 0, 1193 language [1] Language-Tag DEFAULT "i-default", 1194 result [2] Op-rep, 1195 ... 1196 } 1198 Error-Response ::= [APPLICATION 2] SEQUENCE { 1199 pvno-minor [0] INTEGER DEFAULT 0, 1200 language [1] Language-Tag DEFAULT "i-default", 1201 error-code [2] ProtocolErrorCode, 1202 help-text [3] UTF8String OPTIONAL, 1203 op-error [4] Op-err OPTIONAL, 1204 ... 1205 } 1207 Op-req ::= CHOICE { 1208 null [0] Req-null, 1209 change-pw [1] Req-change-pw, 1210 set-pw [2] Req-set-pw, 1211 set-keys [3] Req-set-keys, 1212 gen-keys [4] Req-gen-keys, 1213 get-keys [5] Req-get-keys, 1214 commit-keys [6] Req-commit-keys, 1215 get-pw-policy [7] Req-get-pw-policy, 1216 get-princ-aliases [8] Req-get-princ-aliases, 1217 get-realm-krb5-support [9] Req-get-realm-krb5-support, 1218 get-s2kparams [10] Req-get-s2kparams, 1219 ... 1220 } 1222 Op-rep ::= CHOICE { 1223 null [0] Rep-null, 1224 change-pw [1] Rep-change-pw, 1225 set-pw [2] Rep-set-pw, 1226 set-keys [3] Rep-set-keys, 1227 gen-keys [4] Req-gen-keys, 1228 get-keys [5] Req-get-keys, 1229 commit-keys [6] Rep-commit-keys, 1230 get-pw-policy [7] Rep-get-pw-policy, 1231 get-princ-aliases [8] Rep-get-princ-aliases, 1232 get-realm-krb5-support [9] Rep-get-realm-krb5-support, 1233 get-s2kparams [10] Rep-get-s2kparams, 1234 ... 1235 } 1237 Op-err ::= CHOICE { 1238 null [0] Err-null, 1239 change-pw [1] Err-change-pw, 1240 set-pw [2] Err-set-pw, 1241 set-keys [3] Err-set-keys, 1242 gen-keys [4] Err-gen-keys, 1243 get-keys [5] Err-get-keys, 1244 commit-keys [6] Err-commit-keys, 1245 get-pw-policy [7] Err-get-pw-policy, 1246 get-princ-aliases [8] Err-get-princ-aliases, 1247 get-realm-krb5-support [9] Err-get-realm-krb5-support, 1248 get-s2kparams [10] Err-get-s2kparams, 1249 ... 1250 } 1252 ProtocolErrorCode ::= ENUM { 1253 proto-format-error, 1254 proto-unsupported-major-version, 1255 proto-unsupported-minor-version, 1256 proto-unsupported-operation, -- Request CHOICE tag unknown 1257 proto-generic-see-op-error, -- See Op-error 1258 proto-wrong-service-principal, -- Use kadmin/setpw 1259 proto-re-authentication-required, 1260 proto-initial-ticket-required, 1261 proto-client-and-target-realm-mismatch, 1262 proto-target-principal-unknown, 1263 proto-authorization-failed, 1264 proto-dry-run-not-permitted, 1265 proto-fresh-ticket-required, 1266 ... 1267 } 1269 -- These codes are hints for clients, primarily for when they are 1270 -- used for changing the passwords of automated principals; error 1271 -- replies carry password quality policy help text that is more 1272 -- appropriate for clients to display to users. 1273 PW-Quality-Codes ::= ENUM { 1274 pwq-generic, 1275 pwq-too-soon, 1276 pwq-history, 1277 pwq-too-short, 1278 pwq-dictionary-words, 1279 pwq-prohibited-codepoints, 1280 pwq-need-more-char-classes, 1281 ... 1282 } 1284 -- 1285 -- Requests and responses 1286 -- 1288 -- NULL request, much like ONC RPC's NULL procedure - NOT extensible 1289 Req-null ::= NULL 1291 Rep-null ::= NULL 1293 Err-null ::= NULL 1295 -- Change password 1296 Req-change-pw ::= SEQUENCE { 1297 old-pw [0] Password, 1298 languages [1] SEQUENCE OF Language-Tag OPTIONAL, 1299 new-pw [2] Password OPTIONAL, 1300 commit [3] BOOLEAN DEFAULT TRUE, 1301 etypes [4] SEQUENCE (1..MAX) OF Etype OPTIONAL 1302 } 1304 Rep-change-pw ::= SEQUENCE { 1305 info-text [0] UTF8String OPTIONAL, 1306 new-pw [1] Password OPTIONAL, 1307 -- generated by the server if present 1308 -- (and requested by the client) 1309 etypes [2] SEQUENCE (1..MAX) OF Etype OPTIONAL 1310 } 1312 Err-change-pw ::= SEQUENCE { 1313 help-text [0] UTF8String OPTIONAL, 1314 error [1] CHOICE { 1315 op-generic-error [0] Extensible-NULL, 1316 op-old-pw-incorrect [1] Extensible-NULL, 1317 op-wont-generate-new-pw [2] Extensible-NULL, 1318 op-new-pw-rejected-generic [3] SEQUENCE { 1319 policy [1] SEQUENCE OF UTF8String, 1320 suggested-pw [2] Password OPTIONAL, 1321 policy-codes [3] SET OF PW-Quality-Codes 1322 OPTIONAL 1323 } 1324 op-etype-not-supported [4] SEQUENCE { 1325 supported-etypes [1] SEQUENCE OF Etype 1327 } 1328 } 1329 } 1331 -- Set password 1332 Req-set-pw ::= SEQUENCE { 1333 languages [0] SEQUENCE OF Language-Tag OPTIONAL, 1334 new-pw [1] Password OPTIONAL, 1335 commit [2] BOOLEAN DEFAULT TRUE, 1336 etypes [3] SEQUENCE (1..MAX) OF Etype OPTIONAL 1337 } 1339 Rep-set-pw ::= SEQUENCE { 1340 info-text [0] UTF8String OPTIONAL, 1341 new-pw [1] Password OPTIONAL, 1342 -- generated by the server if present 1343 -- (and requested by the client) 1344 etypes [2] SEQUENCE (1..MAX) OF Etype OPTIONAL 1345 } 1347 Err-set-pw ::= Err-change-pw 1349 -- Set keys 1350 Req-set-keys ::= SEQUENCE { 1351 keys [0] SEQUENCE OF Key, 1352 commit [1] BOOLEAN DEFAULT TRUE, 1353 -- TRUE -> install keys now 1354 -- 1355 -- FALSE -> require set-keys-commit 1356 -- before issuing tickets 1357 -- encrypted with these keys. 1358 -- 1359 -- See commit-keys op 1360 isupport [2] KerberosVSupportNego OPTIONAL 1361 -- For future Kerberos V extensions KDCs 1362 -- may need to know what krb5 version is 1363 -- supported by individual service 1364 -- principals. This field provides a 1365 -- way to tell the KDC what version of 1366 -- Kerberos V the target principal 1367 -- supports. 1368 } 1370 Rep-set-keys ::= SEQUENCE { 1371 info-text [0] UTF8String OPTIONAL, 1372 kvno [1] UInt32, 1373 aliases [2] SEQUENCE OF SEQUENCE { 1374 name [0] PrincipalName, 1375 realm [1] Realm OPTIONAL 1376 }, 1377 isupport [3] KerberosVSupportNego OPTIONAL 1378 -- Should there be ETYPE-INFO2 stuff here? 1379 } 1381 Err-set-keys ::= SEQUENCE { 1382 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1383 error [1] CHOICE { 1384 op-generic [0] Extensible-NULL, 1385 op-deferred-commit-no-support [1] Extensible-NULL, 1386 op-etype-no-support [2] SEQUENCE OF { 1387 supported-etypes [1] SEQUENCE OF Etype 1388 } 1389 } 1390 } 1392 -- Generate keys 1393 Req-gen-keys ::= SEQUENCE { 1394 etypes [0] SEQUENCE (1..MAX) OF Etype, 1395 entropy [1] OCTET STRING OPTIONAL, 1396 commit [2] BOOLEAN DEFAULT TRUE, 1397 -- TRUE -> install keys now 1398 -- 1399 -- FALSE -> require set-keys-commit 1400 -- before issuing tickets 1401 -- encrypted with these keys. 1402 -- 1403 -- See commit-keys op 1404 isupport [3] KerberosVSupportNego OPTIONAL 1405 -- For future Kerberos V extensions KDCs 1406 -- may need to know what krb5 version is 1407 -- supported by individual service 1408 -- principals. This field provides a 1409 -- way to tell the KDC what version of 1410 -- Kerberos V the target principal 1411 -- supports. 1412 } 1414 Rep-gen-keys ::= SEQUENCE { 1415 info-text [0] UTF8String OPTIONAL, 1416 kvno [1] UInt32, 1417 key [2] Key, 1418 aliases [3] SEQUENCE OF SEQUENCE { 1419 name [0] PrincipalName, 1420 realm [1] Realm OPTIONAL 1421 }, 1422 isupport [4] KerberosVSupportNego OPTIONAL 1423 -- Should there be ETYPE-INFO2 stuff here? 1424 } 1426 Err-gen-keys ::= Err-set-keys 1428 -- Get un-committed key request 1429 Req-get-keys ::= SEQUENCE { 1430 kvno [0] UInt32 1431 } 1433 Rep-get-keys ::= SEQUENCE { 1434 info-text [0] UTF8String OPTIONAL, 1435 keys [1] SEQUENCE OF Key, 1436 aliases [2] SEQUENCE OF SEQUENCE { 1437 name [0] PrincipalName, 1438 realm [1] Realm OPTIONAL 1439 }, 1440 isupport [3] KerberosVSupportNego OPTIONAL 1441 -- Should there be ETYPE-INFO2 stuff here? 1442 } 1444 Err-get-keys ::= SEQUENCE { 1445 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1446 error [1] CHOICE { 1447 op-generic [0] Extensible-NULL, 1448 op-kvno-committed [1] Extensible-NULL, 1449 op-no-such-kvno [1] Extensible-NULL 1450 } 1451 } 1453 -- Commit a set keys request 1454 Req-commit-keys ::= SEQUENCE { 1455 kvno [0] UInt32 1456 } 1458 Rep-commit-keys ::= Extensible-NULL 1460 Err-commit-keys ::= SEQUENCE { 1461 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1462 error [1] CHOICE { 1463 op-generic [0] Extensible-NULL, 1464 op-kvno-expired [1] Extensible-NULL, 1465 -- The client took too long to respond. 1466 op-kvno-unknown [2] Extensible-NULL, 1467 -- The targ princ/kvno is invalid or unknown to the 1468 -- server (perhaps it lost track of state) 1469 op-new-keys-conflict [3] Extensible-NULL 1470 -- A new-keys/commit-keys request subsequent to the 1471 -- new-keys that produced the kvno has completed 1472 -- and incremented the principal's kvno 1473 } 1474 } 1476 -- Get password policy 1477 Req-get-pw-policy ::= Extensible-NULL 1479 Rep-get-pw-policy ::= SEQUENCE { 1480 policy-name [0] UTF8String OPTIONAL, 1481 description [1] SEQUENCE OF UTF8String OPTIONAL 1482 } 1484 Err-get-pw-policy ::= Extensible-NULL 1486 -- Get principal aliases 1487 Req-get-princ-aliases ::= Extensible-NULL 1489 Rep-get-princ-aliases ::= SEQUENCE { 1490 help-text [0] UTF8String OPTIONAL, 1491 aliases [1] SEQUENCE OF SEQUENCE { 1492 name [0] PrincipalName, 1493 realm [1] Realm OPTIONAL 1494 } 1495 } 1497 Err-get-princ-aliases ::= Extensible-NULL 1499 -- Get list of enctypes supported by KDC for new keys 1500 Req-get-realm-krb5-support ::= Extensible-NULL 1502 Rep-get-realm-krb5-support ::= SEQUENCE { 1503 isupport [0] KerberosVSupportNego 1504 -- Version of Kerberos V supported by 1505 -- the target realm. 1506 } 1508 Err-get-realm-krb5-support ::= Extensible-NULL 1510 -- Get s2kparams 1511 Req-get-s2kparams ::= Extensible-NULL 1513 Rep-get-s2kparams ::= SEQUENCE { 1514 help-text [0] UTF8String OPTIONAL, 1515 s2kparams [1] SEQUENCE OF Etype-Info-Entry 1516 } 1518 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 to do so. 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 References 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 [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows 1563 2000 Kerberos Change Password and Set Password Protocols", 1564 RFC 3244, February 2002. 1566 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1567 Kerberos Network Authentication Service (V5)", RFC 4120, 1568 July 2005. 1570 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 1571 Languages", BCP 47, RFC 4646, September 2006. 1573 [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", 1574 BCP 47, RFC 4647, September 2006. 1576 Author's Address 1578 Nicolas Williams 1579 Sun Microsystems 1580 5300 Riata Trace Ct 1581 Austin, TX 78727 1582 US 1584 Email: Nicolas.Williams@sun.com 1586 Full Copyright Statement 1588 Copyright (C) The IETF Trust (2008). 1590 This document is subject to the rights, licenses and restrictions 1591 contained in BCP 78, and except as set forth therein, the authors 1592 retain all their rights. 1594 This document and the information contained herein are provided on an 1595 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1596 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1597 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1598 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1599 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1600 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1602 Intellectual Property 1604 The IETF takes no position regarding the validity or scope of any 1605 Intellectual Property Rights or other rights that might be claimed to 1606 pertain to the implementation or use of the technology described in 1607 this document or the extent to which any license under such rights 1608 might or might not be available; nor does it represent that it has 1609 made any independent effort to identify any such rights. Information 1610 on the procedures with respect to rights in RFC documents can be 1611 found in BCP 78 and BCP 79. 1613 Copies of IPR disclosures made to the IETF Secretariat and any 1614 assurances of licenses to be made available, or the result of an 1615 attempt made to obtain a general license or permission for the use of 1616 such proprietary rights by implementers or users of this 1617 specification can be obtained from the IETF on-line IPR repository at 1618 http://www.ietf.org/ipr. 1620 The IETF invites any interested party to bring to its attention any 1621 copyrights, patents or patent applications, or other proprietary 1622 rights that may cover technology that may be required to implement 1623 this standard. Please address the information to the IETF at 1624 ietf-ipr@ietf.org. 1626 Acknowledgment 1628 Funding for the RFC Editor function is provided by the IETF 1629 Administrative Support Activity (IASA).