idnits 2.17.1 draft-ietf-krb-wg-kerberos-set-passwd-07.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1604. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 (September 25, 2007) is 6052 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 1494 -- Looks like a reference, but probably isn't: '0' on line 1493 -- Looks like a reference, but probably isn't: '2' on line 1445 == Missing Reference: 'APPLICATION 0' is mentioned on line 1155, but not defined -- Looks like a reference, but probably isn't: '3' on line 1448 -- Looks like a reference, but probably isn't: '4' on line 1400 -- Looks like a reference, but probably isn't: '5' on line 1221 == Missing Reference: 'APPLICATION 1' is mentioned on line 1169, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 1176, but not defined -- Looks like a reference, but probably isn't: '6' on line 1222 -- Looks like a reference, but probably isn't: '7' on line 1223 -- Looks like a reference, but probably isn't: '8' on line 1224 -- Looks like a reference, but probably isn't: '9' on line 1225 -- Looks like a reference, but probably isn't: '10' on line 1226 ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) Summary: 3 errors (**), 0 flaws (~~), 5 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 Intended status: Standards Track September 25, 2007 5 Expires: March 28, 2008 7 Kerberos Set/Change Key/Password Protocol Version 2 8 draft-ietf-krb-wg-kerberos-set-passwd-07.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 2, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies an extensible protocol for setting keys and 42 changing the passwords of Kerberos V principals. 44 Table of Contents 46 1. Conventions used in this document . . . . . . . . . . . . 3 47 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 48 3. The Protocol . . . . . . . . . . . . . . . . . . . . . . . 5 49 3.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3.1.1. Protocol Framing . . . . . . . . . . . . . . . . . . . . . 5 51 3.2. Protocol Version Negotiation . . . . . . . . . . . . . . . 6 52 3.2.1. Protocol Major Version Negotiation . . . . . . . . . . . . 6 53 3.2.2. Protocol Minor Version Negotiation . . . . . . . . . . . . 7 54 3.3. Use of Kerberos V and Key Exchange . . . . . . . . . . . . 7 55 3.4. Use of ASN.1 . . . . . . . . . . . . . . . . . . . . . . . 8 56 3.5. Internationalization . . . . . . . . . . . . . . . . . . . 8 57 3.5.1. Normalization Forms for UTF-8 Strings . . . . . . . . . . 8 58 3.5.2. Language Negotiation . . . . . . . . . . . . . . . . . . . 8 59 3.6. Protocol Extensibility . . . . . . . . . . . . . . . . . . 9 60 3.7. Protocol Subsets . . . . . . . . . . . . . . . . . . . . . 9 61 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . 10 62 4.1. Password Quality Policies . . . . . . . . . . . . . . . . 10 63 4.1.1. Standard Password Quality Policies . . . . . . . . . . . . 11 64 4.2. PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 4.3. Operations . . . . . . . . . . . . . . . . . . . . . . . . 14 66 4.3.1. Null . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 4.3.2. Change Kerberos Password . . . . . . . . . . . . . . . . . 14 68 4.3.3. Set Kerberos Password . . . . . . . . . . . . . . . . . . 17 69 4.3.4. Set Kerberos Keys . . . . . . . . . . . . . . . . . . . . 19 70 4.3.5. Generate Kerberos Keys . . . . . . . . . . . . . . . . . . 21 71 4.3.6. Get New Keys . . . . . . . . . . . . . . . . . . . . . . . 22 72 4.3.7. Commit New Keys . . . . . . . . . . . . . . . . . . . . . 23 73 4.3.8. Get Password Quality Policy . . . . . . . . . . . . . . . 24 74 4.3.9. Get Principal Aliases . . . . . . . . . . . . . . . . . . 25 75 4.3.10. Get Realm's Supported Kerberos V Version and Features . . 25 76 4.3.11. Retrieve Principal's S2K Params and Preferred Params . . . 26 77 4.4. Principal Aliases . . . . . . . . . . . . . . . . . . . . 26 78 4.5. Kerberos V Feature Negotiation . . . . . . . . . . . . . . 26 79 5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . 28 80 6. Security Considerations . . . . . . . . . . . . . . . . . 38 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . 39 82 7.1. Normative References . . . . . . . . . . . . . . . . . . . 39 83 7.2. Informative References . . . . . . . . . . . . . . . . . . 39 84 Author's Address . . . . . . . . . . . . . . . . . . . . . 40 85 Intellectual Property and Copyright Statements . . . . . . 41 87 1. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Introduction 95 Up to this point Kerberos V has lacked a single, standard protocol 96 for changing passwords and keys. While several vendor-specific 97 protocols exist for changing Kerberos passwords/keys, none are 98 properly internationalized and all are incomplete in one respect or 99 another and none are sufficiently extensible to cope with new 100 features that may be added to Kerberos V at some future time. 102 This document defines a protocol that is somewhat backward-compatible 103 with the "kpasswd" protocol defined in [RFC3244] that uses more or 104 less the same protocol framing. 106 This new protocol is designed to be extensible and properly 107 internationalized. 109 3. The Protocol 111 The structure of the protocol is quite similar to that of typical RPC 112 protocols. Each transaction consists of a data structure specific to 113 an operation which is then wrapped in a data structure which is 114 general to all operations of the protocol. These data structures are 115 defined with the Abstract Syntax Notation 1 (ASN.1) [CCITT.X680.2002] 116 and they are encoded using the Distinguished Encoding Rules (DER) 117 [CCITT.X690.2002]. 119 All protocol data is wrapped KRB-PRIV messages, or, in some cases, a 120 KRB-ERROR, and framed in a header that is backwards compatible with 121 [RFC3244]. 123 3.1. Transports 125 The service supports only connection-oriented transports, 126 specifically TCP, and SHOULD accept requests on TCP port 464, the 127 same as in [RFC3244]. 129 3.1.1. Protocol Framing 131 Requests and responses are exchanged using the same framing as in 132 [RFC3244], but with the following differences: 134 o the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1) 136 o the 'AP-REQ length' field of the request can be set to 0x0, in 137 which case the 'AP-REQ' field of the request is excluded 139 o the 'KRB-PRIV' field of the request and reply is mutually 140 exclusive with the 'AP-REQ' field of the request 142 o the 'AP-REP length' field of the reply can be set to 0x0, in which 143 case the 'AP-REP' field of the reply is excluded 145 o all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can 146 be or has been accepted by the server 148 o any KRB-ERROR messages are framed and sent in the 'AP-REP' field 149 of the reply 151 The initial message from the client MUST carry an AP-REQ and the 152 response to any request bearing an AP-REQ MUST carry an AP-REP or 153 MUST be a KRB-ERROR. 155 Subsequent messages exchanged on the same TCP connection MAY involve 156 Kerberos V AP exchanges, but generally the client SHOULD NOT initiate 157 a new AP exchange except when it desires to authenticate as a 158 different principal, when the ticket last used for authentication 159 expires or when the server responds with an error indicating that the 160 client must re-authenticate. 162 3.2. Protocol Version Negotiation 164 There are several major versions of this protocol. Version 2 also 165 introduces a notion of protocol minor versions for use in negotiating 166 protocol extensions. As of this time only one minor version is 167 defined for major version 2: minor version 0, defined herein. 169 3.2.1. Protocol Major Version Negotiation 171 Version 2 clients that also support other versions, such as 0xff80, 172 as in [RFC3244], SHOULD attempt to use version 2 of the protocol 173 first. 175 Servers which do not support version 2 of this protocol typically 176 include their preferred version number in the reply and/or may 177 include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a 178 status code of KRB5_KPASSWD_MALFORMED. 180 Note that some [RFC3244] server implementations close the TCP 181 connection without returning any other response. Note also that 182 there is no integrity protection for the major version number in the 183 protocol framing or for any data in a KRB-ERROR. 185 As a result change password protocol major version negotiation is 186 subject to downgrade attacks. Therefore major version negotiation is 187 NOT RECOMMENDED. 189 Where the server indicates that it does not support version 2, the 190 client MAY, but SHOULD NOT, unless configured to do so, fall back on 191 another major version of this protocol. 193 Version 2 servers MAY respond to non-v2 requests using whatever 194 response is appropriate for the versions used by the clients, but if 195 a server does not do this or know how to do this then it MUST respond 196 with an error framed as in Section 3.1.1, using an AP-REP and KRB- 197 PRIV if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise 198 and using a ProtocolErrorCode value of unsupported-major-version. 200 It is expected that implementations of as yet unspecified future 201 major versions of this protocol will be required to support version 2 202 integrity protected error replies for properly indicating no support 203 for version 2 of the protocl. We also hope that no further major 204 versions of this protocol will be needed. 206 3.2.2. Protocol Minor Version Negotiation 208 Version 2 clients are free to use whatever protocol minor version and 209 message extensions are available to them in their initial messages to 210 version 2 servers, provided that the minor versions (other than 0) 211 have been defined through IETF documents. 213 Version 2 servers MUST answer with the highest protocol minor version 214 number supported by the server and the client. 216 Version 2 clients MUST use the protocol minor version used in a 217 server's reply for any subsequent messages in the same TCP session. 219 See Section 3.6 for further description of the protocol's 220 extensibility and its relation to protocol minor versions and the 221 negotiation thereof. 223 3.3. Use of Kerberos V and Key Exchange 225 This protocol makes use of messages defined in [RFC4120]. 226 Specifically, AP-REQ, AP-REP, KRB-ERROR and KRB-PRIV. 228 All operations are to be performed by the server on behalf of the 229 client principal. 231 Clients SHOULD use "kadmin/setpw" as the principal name of the server 232 for all requests except when changing the client principal's own 233 expired password, for which they should use "kadmin/changepw". The 234 "kadmin/changepw" service exists to allow KDCs to limit principals 235 with expired passwords to getting initial tickets to the password 236 changing service only and only for changing expired passwords. 238 Servers MUST limit clients that used the "kadmin/changepw" service 239 principal name to changing the password of the client principal. 241 The client MUST request mutual authentication and the client MUST 242 MUST request the use of sequence numbers. 244 Servers MAY force the use of INITIAL or fresh tickets for any 245 requests -- see Section 4.3. Traditionally users with expired 246 passwords are allowed only INITIAL tickets for the password changing 247 server, therefore clients MUST support the use of INITIAL tickets. 249 Servers MUST specify a sub-session key. 251 The encrypted part of KRB-PRIVs MUST be encrypted with the server's 252 sub-session key and key usage 20 (client->server) or 21 253 (server->client). 255 After each new AP exchange the client and server MUST destroy the 256 session keys, if any, resulting from the previous AP exchange. 258 3.4. Use of ASN.1 260 This protocol's messages are defined in ASN.1, using only features 261 from [CCITT.X680.2002]. All ASN.1 types defined herein are to be 262 encoded in DER [CCITT.X690.2002]. A complete ASN.1 module is given 263 in Section 5. 265 The DER encoding of the ASN.1 PDUs are exchanged wrapped in a KRB- 266 PRIV as described above and/or as e-data in KRB-ERROR messages. 268 3.5. Internationalization 270 This protocol's request PDU carries an optional field indicating the 271 languages spoken by the client user; the client SHOULD send its list 272 of spoken languages to the server (once per-TCP session). 274 The server SHOULD localize all strings intended for display to users 275 to a language in common with the languages spoken by the client user. 277 Strings for Kerberos principal and realm names used in this protocol 278 are be constrained as per [RFC4120]. 280 3.5.1. Normalization Forms for UTF-8 Strings 282 Because Kerberos V [RFC4120] restricts principal names, realm names 283 and passwords to IA5String, this protocol uses UTF8String with an 284 extensible constraint to IA5String. 286 Future versions of Kerberos may relax this constraint; if so then a 287 minor version of this protocol should relax this constraint 288 accordingly. 290 3.5.2. Language Negotiation 292 The server MUST pick a language from the client's input list or the 293 default language tag (see [RFC3066]) for text in its responses which 294 is meant for the user to read. 296 The server SHOULD use a language selection algorithm such that 297 consideration is first given to exact matches between the client's 298 spoken languages and the server's available locales, followed by 299 "fuzzy" matches where only the first sub-tags of the client's 300 language tag list are used for matching against the servers available 301 locales. 303 Servers MUST cache the optional language tag lists from prior 304 requests for use with subsequent requests that exclude the language 305 tag list. Clients MAY expect such server behaviour and send the 306 language tag lists only once per-TCP session. Clients SHOULD send 307 the server the language tag list at least once. 309 When the server has a message catalog for one of the client's spoken 310 languages the server SHOULD localize any text strings intended for 311 display to users. 313 3.6. Protocol Extensibility 315 The protocol is defined in ASN.1 and uses extensibility markers 316 throughout. As such, the module presented herein can be extended 317 within the framework of [CCITT.X680.2002]. 319 Typed holes are not used in this protocol as it is very simple and 320 does not require the ability to deal with abstract data types defined 321 in different layers. For this reason, the only way to extend this 322 protocol is by extending the ASN.1 module within the framework of the 323 IETF; all future extensions to this protocol have to be defined in 324 IETF documents unless otherwise specified in a future IETF revision 325 of this protocol. 327 A protocol minor version number is used to negotiate use of 328 extensions. See Section 3.2.2 for the minor version negotiation. 330 Servers SHOULD ignore unknown additions to the ASN.1 types, in 331 initial requests, where the syntax allows them, except for extensions 332 to the "Op-req" type, which MUST result in an error. 334 Servers MUST respond with an error (ProtocolErrorCode value of proto- 335 unsupported-operation) to clients that use operations unknown to the 336 server. 338 3.7. Protocol Subsets 340 The structure of the protocol is such that the ASN.1 syntaxes for the 341 various operations supported by the protocol are independent of the 342 each other. Client and server implementations MAY implement subsets 343 of the overall protocol by removing some alternatives to the Op-req, 344 Op-rep and Op-err CHOICEs from the ASN.1 module given in Section 5. 346 For example, it should be possible to have a password-change only 347 client that cannot set principal's keys - and vice versa. 349 4. Protocol Elements 351 The protocol as defined herein supports the following operations 352 relating to the management of Kerberos principal's passwords or keys: 354 o change password (or enctypes and string-to-key parameters) 356 o set password (administrative) 358 o set new keys 360 o generate new keys 362 o get new, un-committed keys 364 o commit new keys 366 o get password policy name and/or description of principal 368 o list aliases of a principal 370 o list enctypes and version of Kerberos V supported by realm 372 The operation for retrieving a list of aliases of a principal is 373 needed where KDCs implement aliasing of principal names and allows 374 clients to properly setup their key databases when principal aliasing 375 is in use. 377 Operations such as creation or deletion of principals are outside the 378 scope of this document, and should be performed via other means, such 379 as through directories or other Kerberos administration protocols. 381 The individual operations are described in Section 4.3. 383 4.1. Password Quality Policies 385 Servers may reject new user passwords for failing to meet password 386 quality policies. When this happens the server must be able to 387 communicate the policy to the user so that the user may select a 388 better password. 390 The protocol allows for two ways to do this: 392 o through error codes that identify specific password quality 393 policies known; 395 o through localized error strings. 397 The use of localized error strings allows servers to convey non- 398 standard password quality policies to users, but it requires server- 399 side message catalogs for localization and support for language 400 negotiation. The use of error codes only allows for standard 401 password quality policies that clients must be aware of a priori, 402 therefore use of error codes requires the distribution of new message 403 catalogs to clients whenever new error codes are added; this 404 simplifies servers at the expense of password quality extensibility. 406 When a server would reject a password due to its failing to meet a 407 standard password quality policy the the server MUST use the 408 appropriate error codes (see below) and the server SHOULD send a 409 localized error message to the user. 411 When a server would reject a password due to its failing to meet a 412 non-standard password quality policy (one not described herein) the 413 the server MUST send a localized error message to the user. 415 4.1.1. Standard Password Quality Policies 417 o pwq-too-soon 419 It is too soon for the principal to change its password or long- 420 term keys. 422 o pwq-history 424 The new password is one that the principal has used before or is 425 too similar to a password that it has used before. 427 o pwq-too-short 429 The new password is too short. 431 o pwq-dictionary-words 433 The new password is or contains words that are in the dictionary. 435 o pwq-prohibited-codepoints 437 The new password contains prohibited codepoints. 439 o pwq-need-more-char-classes 441 The new password does not have characters from enough character 442 classes (lower-case letters, upper-case letters, digits, 443 punctuation, etc...). 445 4.2. PDUs 447 The types "Request," "Response" and "Error-Response" are the ASN.1 448 module's PDUs. 450 The "Request" and "Response" PDUs are always to be sent wrapped in 451 KRB-PRIV messages, except for the "Error-Response" PDU which MUST be 452 sent as KRB-ERROR e-data (see Section 3.3) when AP exchanges fail, 453 otherwise it MUST be sent wrapped in a KRB-PRIV. 455 The ASN.1 syntax for the PDUs is given in Section 5. 457 Note that the first field of each PDU is the major version of the 458 protocol, defaulted to 2, meaning that it is never included in 459 version 2 exchanges. Similarly, the second field of each PDU is the 460 minor version, defaulted to 0. 462 The request, responses and error PDUs consist of an outer structure 463 ("Request," "Response" and "Error-Response") containing fields common 464 to all requests, responses and errors, respectively, and an inner 465 structure for fields that are specific to each operation's requests/ 466 responses. The inner structure is optional in the case of the Error- 467 Response PDU and need not be included when generic errors occur for 468 which there is a suitable ProtocolErrorCode. 470 Specifically, the outer Request structure has a field for passing a 471 client user's spoken (read) languages to the server. It also has two 472 optional fields for identifying the requested operation's target 473 principal's name and realm (if not sent then the server MUST use the 474 client's principal name and realm as the target). A boolean field 475 for indicating whether or not the request should be dry-run is also 476 included; dry-runs can be used to test server policies, and servers 477 MUST NOT modify any principals when processing dry-run requests. 479 The Response and Error PDUs' outer structures include a field 480 indicating the language that the server has chosen for localization 481 of text intended to be displayed to users; this field is defaulted to 482 "i-default". This language tag applies to all UTF8 strings in the 483 inner structure (Op-rep and Op-err) that are meant to be displayed to 484 users. 486 The protocol error codes are: 488 o proto-generic-error 490 An operation-specific error ocurred, see the inner Op-error. 492 o proto-format-error 494 The server failed to parse a message sent by the client. 496 o proto-unsupported-major-version 498 The server does not support the major version of this protocol 499 requested by the client. 501 o proto-unsupported-minor-version 503 The server does not support the minor version of this protocol 504 requested by the client. 506 o proto-unsupported-operation 508 The server does not support the operation requested by the client. 510 o proto-wrong-service-principal 512 Use kadmin/setpw for the server's principal name. 514 o proto-re-authentication-required 516 The server demands that the client re-authenticate through a new 517 AP exchange. 519 o proto-initial-ticket-required 521 Use of an INITIAL ticket is required for the requested operation. 523 o proto-client-and-target-realm-mismatch 525 The server requires that the client's principal name and the 526 target principal of the operation share the same realm name. 528 o proto-target-principal-unknown 530 The target of the client's operation is not a valid principal. 532 o proto-authorization-failed 533 The client principal is not authorized to perform the requested 534 operation. 536 o proto-fresh-ticket-required 538 The server would like the client to re-authenticate using a fresh 539 ticket. 541 4.3. Operations 543 This section describes the semantics of each operation request and 544 response defined in the ASN.1 module in Section 5. 546 4.3.1. Null 548 NAME 550 null - Null or "ping" operation 552 DESCRIPTION 554 The null request is intended for use with TCP; its purpose is 555 similar to RPC null procedures and is akin to a "ping" operation. 557 ERRORS 559 None. 561 4.3.2. Change Kerberos Password 563 NAME 565 change-pw - Change password operation 567 SYNOPSIS 569 Req-change-pw(old-pw, [languages], [new-pw], 570 [commit], [etypes]) -> 571 Rep-change-pw([info-text], [new-pw], [etypes]) | 572 Err-change-pw([help-text], error code, [error info]) 574 DESCRIPTION 575 Change a principal's password. 577 The change password request has one required, three optional and 578 one defaulted arguments: "old-pw" (required), "languages," 579 "new-pw", "commit" (defaults to "TRUE") and "etypes", 580 corresponding to the target principal's old password, its 581 preferred languages, its new password, a boolean indicating 582 whether or not to make the new long-term key available for 583 immediate use, and the desired enctypes for the new long-term 584 keys. 586 The server MUST validate the old password and MUST check the 587 quality of the new password, if sent, according the password 588 quality policy associated with the target principal. 590 If the old and new passwords in the request are the same strings, 591 and the principal is not currently required to change its 592 password, then the server MAY permit the password change as way to 593 change a principal's enctypes and string-to-key parameters. This 594 feature provides a way to, for example, add enctypes to a 595 principals' password-derived long-term keys without forcing a 596 password change following an upgrade to the KDC that adds support 597 for new enctypes. 599 A client MAY request that the server generate a new password by 600 excluding the new password from its request, in which case the 601 server MUST either generate a new password or respond with an 602 error indicating that it does not support this feature. 604 Server-generated passwords MUST meet the target principal's 605 password quality policy. It is RECOMMENDED that server-generated 606 passwords be user-friendly, that is, memorable and that the target 607 principal's preferred languages be taken into account by the 608 password generation alogrithm used by the server. 610 Uncommitted password changes are commited using the commit-keys 611 operation. 613 RETURN 615 Upon successful password changes the server responds with a 616 Rep-change-pw. The fields of Rep-change-pw are all optional and 617 include: 619 - 'info-text' which the server can use to send a message to the 620 user such as "Your new password will expire in 90 days," for 621 example. 623 - 'new-pw' which the server MUST include if the client 624 requested that the server generate a new password; generated 625 passwords MUST pass the target principal's password quality 626 policy. 628 - 'etypes' which the server MAY include to indicate which types 629 of long-term keys it created for the target principal and 630 which the server MUST include if the client specified a set 631 of enctypes in its request. 633 ERRORS 635 The server may respond to change password requests with protocol 636 or operation errors. 638 All operation errors include an optional 'help-text' field by 639 which the server can describe the error in a human-readable, 640 localizaed string. 642 Change password error codes include: 644 - generic-error 646 - old-pw-incorrect 648 - wont-generate-new-pw 650 The server will not generate a new password for this 651 principal or does not support password generation in general. 653 - new-pw-rejected-generic 655 The client's proposed new password failed the target 656 principal's password quality policy. 658 The server MUST include a description of the password quality 659 policy or aspect of it that the client's proposed new 660 password failed to meet. 662 The server MAY generate and send a new password that the 663 client can then use as a new password and which is guaranteed 664 to pass the target principal's current password quality 665 policy. 667 The server MAY include a set of policy error code hints. 669 - etype-not-supported 670 The client requested an enctype that the KDC does not 671 support. 673 4.3.3. Set Kerberos Password 675 NAME 677 set-pw - Set password operation 679 SYNOPSIS 681 Req-set-pw([languages], [new-pw], [commit], [etypes]) -> 682 Rep-set-pw([info-text], [new-pw], [etypes]) | 683 Err-set-pw([help-text], error code, [error info]) 685 DESCRIPTION 687 Administratively set a principal's password. 689 The set password request has three optional and one defaulted 690 arguments: "languages", "new-pw," "commit" (defaulted to "TRUE") 691 and "etypes", corresponding to the target principal's preferred 692 languages, new password, a boolean indicating whether or not to 693 make the new long-term key available for immediate use, and the 694 desired enctypes for the new long-term keys. 696 The server MUST check the quality of the new password, if sent, 697 according the password quality policy associated with the target 698 principal. 700 The server SHOULD require that the client use the change-pw 701 operation instead of set-pw when the client principal and the 702 target principal are the same. 704 A client MAY request that the server generate a new password by 705 excluding the new password from its request, in which case the 706 server MUST either generate a new password or respond with an 707 error indicating that it does not support this feature. 709 Server-generated passwords MUST meet the target principal's 710 password quality policy. It is RECOMMENDED that server-generated 711 passwords be user-friendly, that is, memorable and that the target 712 principal's preferred languages be taken into account by the 713 password generation alogrithm used by the server. 715 RETURN 717 Upon successfully setting a password the server responds with a 718 Rep-set-pw. The fields of Rep-set-pw are all optional and 719 include: 721 - 'info-text' which the server can use to send a message to the 722 user such as "Your new password will expire in 90 days," for 723 example. 725 - 'new-pw' which the server MUST include if the client 726 requested that the server generate a new password; generated 727 passwords MUST pass the target principal's password quality 728 policy. 730 - 'etypes' which the server MAY include to indicate which types 731 of long-term keys it created for the target principal and 732 which the server MUST include if the client specified a set 733 of enctypes in its request. 735 ERRORS 737 The server may respond to set password requests with protocol or 738 operation errors. 740 All operation errors include an optional 'help-text' field by 741 which the server can describe the error in a human-readable, 742 localizaed string. 744 Set password error codes include: 746 - generic-error 748 - use-change-pw 750 The server demands that the client use the change-pw 751 operation for the target principal of the set-pw request. 753 - wont-generate-new-pw 755 The server will not generate a new password for this 756 principal or does not support password generation in general. 758 - new-pw-rejected-generic 760 The client's proposed new password failed the target 761 principal's password quality policy. 763 The server MUST include a description of the password quality 764 policy or aspect of it that the client's proposed new 765 password failed to meet. 767 The server MAY generate and send a new password that the 768 client can then use as a new password and which is guaranteed 769 to pass the target principal's current password quality 770 policy. 772 The server MAY include a set of policy error code hints. 774 - etype-not-supported 776 The client requested an enctype that the KDC does not 777 support. 779 4.3.4. Set Kerberos Keys 780 NAME 782 set-keys - Set a principal's long-term keys 784 SYNOPSIS 786 Req-set-keys(new-keys, commit?, [isupport]) -> 787 Rep-set-keys([info-text], kvno, aliases, [isupport]) 789 DESCRIPTION 791 The set-keys request consists of two required fields and one 792 optional field: "new-keys", "commit" (a boolean field - see below) 793 and "isupport", an optional field for indicating to the KDC what 794 Kerberos V features are supported by the target principal. 796 When "commit" is true the KDC makes the new keys available for 797 issueing tickets encrypted in them immediately. Otherwise the 798 client MUST follow up with a commit-keys request to make the keys 799 available. This feature is useful for changing keys shared by 800 multiple hosts, in clustered services, for example, in an atomic 801 manner. 803 If a principal has keys are awaiting commitment when a new 804 set-keys request for that principal s made then the KDC MUST 805 overwrite the deferred keys. 807 RETURN 809 For successful set-keys operations the server returns: 811 - Informational text, optional. 813 - The new kvno for the target principal. 815 - A list of aliases of the target principal known to the KDC 816 (optional). 818 - The set of Kerberos V features supported by the KDC 819 (optional). 821 ERRORS 823 The server may respond with the following errors: 825 - generic 826 - deferred-commit-no-support 827 - etype-no-support 829 4.3.5. Generate Kerberos Keys 831 NAME 833 gen-keys - Generate long-term keys for a principal 835 SYNOPSIS 837 Req-gen-keys(etypes, [entropy], commit?, [isupport]) -> 838 Rep-set-keys([info-text], key, kvno, aliases, [isupport]) 840 DESCRIPTION 842 The gen-keys is similar to the set-keys request but differs in 843 that the server generates keys of client-requested enctypes, 844 rather than the client providing specific keys. 846 The gen-keys request consists of two required fields and two 847 optional fields: "etypes" (the enctypes of the new keys), 848 "entropy", "commit" and "isupport". 850 If a principal has keys are awaiting commitment when a new 851 set-keys request for that principal s made then the KDC MUST 852 overwrite the deferred keys. 854 RETURN 856 For successful set-keys operations the server returns: 858 - Informational text, optional. 860 - The new kvno for the target principal. 862 - The new key (only one is needed). 864 - A list of aliases of the target principal known to the KDC 865 (optional). 867 - The set of Kerberos V features supported by the KDC 868 (optional). 870 ERRORS 872 The server may respond with the following errors: 874 - generic 875 - deferred-commit-no-support 876 - etype-no-support 878 4.3.6. Get New Keys 880 NAME 882 get-keys - Retrieve a principal's uncommitted keys 884 SYNOPSIS 886 Req-get-keys(kvno) -> 887 Rep-get-keys([info-text], keys, aliases, [isupport]) | 888 Err-get-keys([help-text], error code, [error info]) 890 DESCRIPTION 892 This request allows a client to get the keys set or generated in a 893 previous set-keys or gen-keys request with deferred commitment. 895 RETURN 897 If the target principal and kvno correspond to uncommitted keys 898 the server MUST respond with the actual keys that would be set by 899 a subsequent commit-keys request. Otherwise the server MUST 900 respond with an error (meaning that this operation cannot be used 901 to extract keys from the KDC that may be in use). 903 ERRORS 905 - generic 906 - kvno-committed 907 - no-such-kvno 909 4.3.7. Commit New Keys 911 NAME 913 commit-keys - Commit a principal's new long-term keys 915 SYNOPSIS 917 Req-commit-keys(kvno) -> 918 Rep-commit-keys() | 919 Err-commit-keys([help-text], error code, [error info]) 921 DESCRIPTION 923 The commit-keys operation allows a client to bring a principal's 924 new keys into use at the KDC. 926 Clients should make a commit-keys request corresponding to a 927 deferred commitment set-keys/gen-keys operation as soon as the 928 local key database for the target principal is updated. 930 The target principal name and the kvno MUST match those from a 931 prior set-keys or gen-keys operation. 933 Servers MAY expire delayed key commitments at will. Servers 934 SHOULD expire uncommitted new keys after a reasonable amount of 935 time (600 seconds is RECOMMENDED). 937 Servers MUST respond to new set-keys requests for principals with 938 pending, uncommitted new keys by expiring the uncommitted new keys 939 and proceeding as if there had been no expired new keys. 941 ERRORS 943 - generic 944 - op-kvno-expired 945 - op-kvno-unknown 946 - new-keys-conflict (A set-keys or gen-keys request succeeded 947 subsequent to the request that matches this 948 {principal, kvno} tuple.) 950 4.3.8. Get Password Quality Policy 952 NAME 954 get-pw-policy - Retrieve a principal's password policy 956 SYNOPSIS 958 Req-get-pw-policy() -> 959 Rep-get-pw-policy([policy name], [policy description]) 961 DESCRIPTION 963 Returns a description of the target principal's associated 964 password quality policy, if any, as a list of localized 965 UTF8String values. 967 Clients can use this operation in conjunction with the change-pw 968 operation to obtain text that can be displayed to the user before 969 the user actually enters a new password. 971 It is common for sites to set policies with respect to password 972 quality. It is beyond the scope of this document to describe such 973 policies. Management of password quality policies' actual content 974 is also beyond the scope of this protocol. 976 ERRORS 978 No operation errors are defined. 980 4.3.9. Get Principal Aliases 982 NAME 984 get-princ-aliases - Retrieve a principal's aliases 986 SYNOPSIS 988 Req-get-princ-aliases() -> 989 Rep-get-princ-aliases(aliases) 991 DESCRIPTION 993 Returns a list of aliases of the target principal. 995 ERRORS 997 No operation-specific errors. 999 4.3.10. Get Realm's Supported Kerberos V Version and Features 1001 NAME 1003 get-realm-krb5-support - List features supported by the realm 1005 SYNOPSIS 1007 Req-get-realm-krb5-support() -> 1008 Rep-get-realm-krb5-support(isupport) 1010 DESCRIPTION 1012 Returns set of Kerberos V features support by the target 1013 principal's realm's KDCs. 1015 ERRORS 1017 No operation-specific errors. 1019 4.3.11. Retrieve Principal's S2K Params and Preferred Params 1021 NAME 1023 get-s2kparams 1025 SYNOPSIS 1027 Req-get-s2kparams() -> 1028 Rep-get-s2kparams(princ-s2kparams) 1030 DESCRIPTION 1032 Returns the string2key parameters for the principal's current 1033 password-derived long-term keys, if any (if there are none then 1034 the principal does not have a password-derived long-term key). 1036 ERRORS 1038 No operation-specific errors. 1040 4.4. Principal Aliases 1042 Applications that use Kerberos often have to derive acceptor 1043 principal names from hostnames entered by users. Such hostnames may 1044 be aliases, they may be fully qualified, partially qualified or not 1045 qualified at all. Some implementations have resorted to deriving 1046 principal names from such hostnames by utilizing the names services 1047 to canonicalize the hostname first; such practices are not secure 1048 unless the name service are secure, which often aren't. 1050 One method for securely deriving principal names from hostnames is to 1051 alias principals at the KDC such that the KDC will issue tickets for 1052 principal names which are aliases of others. It is helpful for 1053 principals to know what are their aliases as known by the KDCs. 1055 Note that changing a principal's aliases is out of scope for this 1056 protocol. 1058 4.5. Kerberos V Feature Negotiation 1060 Principals and realms' KDCs may need to know about additional 1061 Kerberos V features and extensions that they each support. Several 1062 operations (see above) provide a way for clients and servers to 1063 exchange such infomration, in the form of lists of types supported 1064 for the various typed holes used in Kerberos V. 1066 5. ASN.1 Module 1068 DEFINITIONS EXPLICIT TAGS ::= BEGIN 1069 -- 1070 -- Note: EXPLICIT tagging is in use by default throughout this 1071 -- module. 1073 -- From [clarifications] with modifications 1074 PrincipalName ::= SEQUENCE { 1075 name-string [1] SEQUENCE OF UTF8String (IA5String, ...) 1076 } 1077 Realm ::= UTF8String (IA5String, ...) 1078 Salt ::= UTF8String (IA5String, ...) 1079 Password ::= UTF8String (IA5String, ...) 1081 -- NOTE WELL: Principal and realm names MUST be constrained by the 1082 -- specification of the version of Kerberos V used by the 1083 -- client. 1085 -- 1086 -- [Perhaps PrincipalName should be a SEQUENCE of an optional name 1087 -- type and a UTF8String, for simplicity.] 1089 -- From [clarifications] 1090 Int32 ::= INTEGER (-2147483648..2147483647) 1091 UInt32 ::= INTEGER (0..4294967295) 1093 -- Based on [clarifications] 1094 Etype ::= Int32 1095 Etype-Info-Entry ::= SEQUENCE { 1096 etype [0] Etype, 1097 salt [1] Salt OPTIONAL, 1098 s2kparams [2] OCTET STRING OPTIONAL 1099 } 1100 Key ::= SEQUENCE { 1101 enc-type [0] Etype, -- from Kerberos 1102 key [1] OCTET STRING 1103 } 1105 Language-Tag ::= UTF8String -- Constrained by [RFC3066] 1107 -- Empty, extensible SEQUENCEs are legal ASN.1 1108 Extensible-NULL ::= SEQUENCE { 1109 ... 1110 } 1111 -- Kerberos clients negotiate some parameters relating to their peers 1112 -- indirectly through the KDC. Today this is true of ticket session 1113 -- key enctypes, but in the future this indirect negotiation may also 1114 -- occur with respect to the minor version of Kerberos V to be used 1115 -- between clients and servers. Additionally, KDCs may need to know 1116 -- what authorization-data types are supported by service principals, 1117 -- both, for compatibility with legacy software and for optimization. 1118 -- 1119 -- Thesefore it is important for KDCs to know what features of 1120 -- Kerberos V each service principal supports. 1121 -- 1122 -- In version 2.0 of this protocol the clients and servers may notify 1123 -- each other of their support for: 1124 -- 1125 -- - enctypes 1126 -- - authorization data types 1127 -- - transited encoding data types 1128 -- 1129 -- All authorization-data types defined in [clarifications] are 1130 -- assumed to be supported if the minor version is 1 and do not need 1131 -- to be included in the ad-type list. 1132 -- 1133 -- Int32 is used for enctype and transited encoding data type 1134 -- identifiers. 1136 -- 1137 -- An extensible CHOICE of Int32 is used for authorization data 1138 -- types. 1140 KerberosV-TR-ID ::= Int32 1142 KerberosV-AD-ID ::= CHOICE { 1143 ad-int [0] Int32, 1144 ... 1145 } 1147 KerberosVSupportNego ::= SEQUENCE { 1148 enc-types [0] SEQUENCE OF Etype, 1149 ad-types [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL, 1150 -- authorization data types 1151 tr-enc-types [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL 1152 -- transited encoding types 1153 } 1155 Request ::= [APPLICATION 0] SEQUENCE { 1156 pvno-minor [0] INTEGER DEFAULT 0, 1157 languages [1] SEQUENCE OF Language-Tag OPTIONAL, 1158 -- Should be defaulted to the SEQUENCE of "i-default" 1160 targ-name [2] PrincipalName OPTIONAL, 1161 targ-realm [3] Realm OPTIONAL, 1162 -- If targ-name/realm are missing then the request 1163 -- applies to the principal of the client 1164 dry-run [4] BOOLEAN DEFAULT FALSE, 1165 operation [5] Op-req, 1166 ... 1167 } 1169 Response ::= [APPLICATION 1] SEQUENCE { 1170 pvno-minor [0] INTEGER DEFAULT 0, 1171 language [1] Language-Tag DEFAULT "i-default", 1172 result [2] Op-rep, 1173 ... 1174 } 1176 Error-Response ::= [APPLICATION 2] SEQUENCE { 1177 pvno-minor [0] INTEGER DEFAULT 0, 1178 language [1] Language-Tag DEFAULT "i-default", 1179 error-code [2] ProtocolErrorCode, 1180 help-text [3] UTF8String OPTIONAL, 1181 op-error [4] Op-err OPTIONAL, 1182 ... 1183 } 1185 Op-req ::= CHOICE { 1186 null [0] Req-null, 1187 change-pw [1] Req-change-pw, 1188 set-pw [2] Req-set-pw, 1189 set-keys [3] Req-set-keys, 1190 gen-keys [4] Req-gen-keys, 1191 get-keys [5] Req-get-keys, 1192 commit-keys [6] Req-commit-keys, 1193 get-pw-policy [7] Req-get-pw-policy, 1194 get-princ-aliases [8] Req-get-princ-aliases, 1195 get-realm-krb5-support [9] Req-get-realm-krb5-support, 1196 get-s2kparams [10] Req-get-s2kparams, 1197 ... 1198 } 1200 Op-rep ::= CHOICE { 1201 null [0] Rep-null, 1202 change-pw [1] Rep-change-pw, 1203 set-pw [2] Rep-set-pw, 1204 set-keys [3] Rep-set-keys, 1205 gen-keys [4] Req-gen-keys, 1206 get-keys [5] Req-get-keys, 1207 commit-keys [6] Rep-commit-keys, 1208 get-pw-policy [7] Rep-get-pw-policy, 1209 get-princ-aliases [8] Rep-get-princ-aliases, 1210 get-realm-krb5-support [9] Rep-get-realm-krb5-support, 1211 get-s2kparams [10] Rep-get-s2kparams, 1212 ... 1213 } 1215 Op-err ::= CHOICE { 1216 null [0] Err-null, 1217 change-pw [1] Err-change-pw, 1218 set-pw [2] Err-set-pw, 1219 set-keys [3] Err-set-keys, 1220 gen-keys [4] Err-gen-keys, 1221 get-keys [5] Err-get-keys, 1222 commit-keys [6] Err-commit-keys, 1223 get-pw-policy [7] Err-get-pw-policy, 1224 get-princ-aliases [8] Err-get-princ-aliases, 1225 get-realm-krb5-support [9] Err-get-realm-krb5-support, 1226 get-s2kparams [10] Err-get-s2kparams, 1227 ... 1228 } 1230 ProtocolErrorCode ::= ENUM { 1231 proto-format-error, 1232 proto-unsupported-major-version, 1233 proto-unsupported-minor-version, 1234 proto-unsupported-operation, -- Request CHOICE tag unknown 1235 proto-generic-see-op-error, -- See Op-error 1236 proto-wrong-service-principal, -- Use kadmin/setpw 1237 proto-re-authentication-required, 1238 proto-initial-ticket-required, 1239 proto-client-and-target-realm-mismatch, 1240 proto-target-principal-unknown, 1241 proto-authorization-failed, 1242 proto-dry-run-not-permitted, 1243 proto-fresh-ticket-required, 1244 ... 1245 } 1247 -- These codes are hints for clients, primarily for when they are 1248 -- used for changing the passwords of automated principals; error 1249 -- replies carry password quality policy help text that is more 1250 -- appropriate for clients to display to users. 1251 PW-Quality-Codes ::= ENUM { 1252 pwq-generic, 1253 pwq-too-soon, 1254 pwq-history, 1255 pwq-too-short, 1256 pwq-dictionary-words, 1257 pwq-prohibited-codepoints, 1258 pwq-need-more-char-classes, 1259 ... 1260 } 1262 -- 1263 -- Requests and responses 1264 -- 1266 -- NULL request, much like ONC RPC's NULL procedure - NOT extensible 1267 Req-null ::= NULL 1269 Rep-null ::= NULL 1271 Err-null ::= NULL 1273 -- Change password 1274 Req-change-pw ::= SEQUENCE { 1275 old-pw [0] Password, 1276 new-pw [1] Password OPTIONAL, 1277 commit [2] BOOLEAN DEFAULT TRUE, 1278 etypes [3] SEQUENCE (1..MAX) OF Etype OPTIONAL 1279 } 1281 Rep-change-pw ::= SEQUENCE { 1282 info-text [0] UTF8String OPTIONAL, 1283 new-pw [1] Password OPTIONAL, 1284 -- generated by the server if present 1285 -- (and requested by the client) 1286 etypes [2] SEQUENCE (1..MAX) OF Etype OPTIONAL 1287 } 1289 Err-change-pw ::= SEQUENCE { 1290 help-text [0] UTF8String OPTIONAL, 1291 error [1] CHOICE { 1292 op-generic-error [0] Extensible-NULL, 1293 op-old-pw-incorrect [1] Extensible-NULL, 1294 op-wont-generate-new-pw [2] Extensible-NULL, 1295 op-new-pw-rejected-generic [3] SEQUENCE { 1296 policy [1] SEQUENCE OF UTF8String, 1297 suggested-pw [2] Password OPTIONAL, 1298 policy-codes [3] SET OF PW-Quality-Codes 1299 OPTIONAL 1300 } 1301 op-etype-not-supported [4] SEQUENCE { 1302 supported-etypes [1] SEQUENCE OF Etype 1303 } 1305 } 1306 } 1308 -- Set password 1309 Req-set-pw ::= SEQUENCE { 1310 languages [0] SEQUENCE OF Language-Tag OPTIONAL, 1311 new-pw [1] Password OPTIONAL, 1312 commit [2] BOOLEAN DEFAULT TRUE, 1313 etypes [3] SEQUENCE (1..MAX) OF Etype OPTIONAL 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..MAX) OF Etype OPTIONAL 1322 } 1324 Err-set-pw ::= Err-change-pw 1326 -- Set keys 1327 Req-set-keys ::= SEQUENCE { 1328 keys [0] SEQUENCE OF Key, 1329 commit [1] BOOLEAN DEFAULT TRUE, 1330 -- TRUE -> install keys now 1331 -- 1332 -- FALSE -> require set-keys-commit 1333 -- before issuing tickets 1334 -- encrypted with these keys. 1335 -- 1336 -- See commit-keys op 1337 isupport [2] KerberosVSupportNego OPTIONAL 1338 -- For future Kerberos V extensions KDCs 1339 -- may need to know what krb5 version is 1340 -- supported by individual service 1341 -- principals. This field provides a 1342 -- way to tell the KDC what version of 1343 -- Kerberos V the target principal 1344 -- supports. 1345 } 1347 Rep-set-keys ::= SEQUENCE { 1348 info-text [0] UTF8String OPTIONAL, 1349 kvno [1] UInt32, 1350 aliases [2] SEQUENCE OF SEQUENCE { 1351 name [0] PrincipalName, 1352 realm [1] Realm OPTIONAL 1354 }, 1355 isupport [3] KerberosVSupportNego OPTIONAL 1356 -- Should there be ETYPE-INFO2 stuff here? 1357 } 1359 Err-set-keys ::= SEQUENCE { 1360 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1361 error [1] CHOICE { 1362 op-generic [0] Extensible-NULL, 1363 op-deferred-commit-no-support [1] Extensible-NULL, 1364 op-etype-no-support [2] SEQUENCE OF { 1365 supported-etypes [1] SEQUENCE OF Etype 1366 } 1367 } 1368 } 1370 -- Generate keys 1371 Req-gen-keys ::= SEQUENCE { 1372 etypes [0] SEQUENCE (1..MAX) OF Etype, 1373 entropy [1] OCTET STRING OPTIONAL, 1374 commit [2] BOOLEAN DEFAULT TRUE, 1375 -- TRUE -> install keys now 1376 -- 1377 -- FALSE -> require set-keys-commit 1378 -- before issuing tickets 1379 -- encrypted with these keys. 1380 -- 1381 -- See commit-keys op 1382 isupport [3] KerberosVSupportNego OPTIONAL 1383 -- For future Kerberos V extensions KDCs 1384 -- may need to know what krb5 version is 1385 -- supported by individual service 1386 -- principals. This field provides a 1387 -- way to tell the KDC what version of 1388 -- Kerberos V the target principal 1389 -- supports. 1390 } 1392 Rep-gen-keys ::= SEQUENCE { 1393 info-text [0] UTF8String OPTIONAL, 1394 kvno [1] UInt32, 1395 key [2] Key, 1396 aliases [3] SEQUENCE OF SEQUENCE { 1397 name [0] PrincipalName, 1398 realm [1] Realm OPTIONAL 1399 }, 1400 isupport [4] KerberosVSupportNego OPTIONAL 1401 -- Should there be ETYPE-INFO2 stuff here? 1403 } 1405 Err-gen-keys ::= Err-set-keys 1407 -- Get un-committed key request 1408 Req-get-keys ::= SEQUENCE { 1409 kvno [0] UInt32 1410 } 1412 Rep-get-keys ::= SEQUENCE { 1413 info-text [0] UTF8String OPTIONAL, 1414 keys [1] SEQUENCE OF Key, 1415 aliases [2] SEQUENCE OF SEQUENCE { 1416 name [0] PrincipalName, 1417 realm [1] Realm OPTIONAL 1418 }, 1419 isupport [3] KerberosVSupportNego OPTIONAL 1420 -- Should there be ETYPE-INFO2 stuff here? 1421 } 1423 Err-get-keys ::= SEQUENCE { 1424 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1425 error [1] CHOICE { 1426 op-generic [0] Extensible-NULL, 1427 op-kvno-committed [1] Extensible-NULL, 1428 op-no-such-kvno [1] Extensible-NULL 1429 } 1430 } 1432 -- Commit a set keys request 1433 Req-commit-keys ::= SEQUENCE { 1434 kvno [0] UInt32 1435 } 1437 Rep-commit-keys ::= Extensible-NULL 1439 Err-commit-keys ::= SEQUENCE { 1440 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1441 error [1] CHOICE { 1442 op-generic [0] Extensible-NULL, 1443 op-kvno-expired [1] Extensible-NULL, 1444 -- The client took too long to respond. 1445 op-kvno-unknown [2] Extensible-NULL, 1446 -- The targ princ/kvno is invalid or unknown to the 1447 -- server (perhaps it lost track of state) 1448 op-new-keys-conflict [3] Extensible-NULL 1449 -- A new-keys/commit-keys request subsequent to the 1450 -- new-keys that produced the kvno has completed 1451 -- and incremented the principal's kvno 1452 } 1453 } 1455 -- Get password policy 1456 Req-get-pw-policy ::= Extensible-NULL 1458 Rep-get-pw-policy ::= SEQUENCE { 1459 policy-name [0] UTF8String OPTIONAL, 1460 description [1] SEQUENCE OF UTF8String OPTIONAL 1461 } 1463 Err-get-pw-policy ::= Extensible-NULL 1465 -- Get principal aliases 1466 Req-get-princ-aliases ::= Extensible-NULL 1468 Rep-get-princ-aliases ::= SEQUENCE { 1469 help-text [0] UTF8String OPTIONAL, 1470 aliases [1] SEQUENCE OF SEQUENCE { 1471 name [0] PrincipalName, 1472 realm [1] Realm OPTIONAL 1473 } 1474 } 1476 Err-get-princ-aliases ::= Extensible-NULL 1478 -- Get list of enctypes supported by KDC for new keys 1479 Req-get-realm-krb5-support ::= Extensible-NULL 1481 Rep-get-realm-krb5-support ::= SEQUENCE { 1482 isupport [0] KerberosVSupportNego 1483 -- Version of Kerberos V supported by 1484 -- the target realm. 1485 } 1487 Err-get-realm-krb5-support ::= Extensible-NULL 1489 -- Get s2kparams 1490 Req-get-s2kparams ::= Extensible-NULL 1492 Rep-get-s2kparams ::= SEQUENCE { 1493 help-text [0] UTF8String OPTIONAL, 1494 s2kparams [1] SEQUENCE OF Etype-Info-Entry 1495 } 1497 Err-get-s2kparams ::= Extensible-NULL 1498 END 1500 6. Security Considerations 1502 Implementors and site administrators should note that the redundancy 1503 of UTF-8 encodings of passwords varies by language. Password quality 1504 policies SHOULD, therefore, take this into account when estimating 1505 the amount of redundancy and entropy in a proposed new password. 1507 Kerberos set/change password/key protocol major version negotiation 1508 cannot be done securely; a downgrade attack is possible against 1509 clients that attempt to negotiate the protocol major version to use 1510 with a server. It is not clear at this time that the attacker would 1511 gain much from such a downgrade attack other than denial of service 1512 (DoS) by forcing the client to use a protocol version which does not 1513 support some feature needed by the client (Kerberos V in general is 1514 subject to a variety of DoS attacks anyways [RFC4120]). Clients 1515 SHOULD NOT negotiate support for legacy major versions of this 1516 protocol unless configured otherwise. 1518 This protocol does not have Perfect Forward Security (PFS). As a 1519 result, any passive network snooper watching password/key changing 1520 operations who has stolen a principal's password or long-term keys 1521 can find out what the new ones are. 1523 7. References 1525 7.1. Normative References 1527 [CCITT.X680.2002] 1528 International International Telephone and Telegraph 1529 Consultative Committee, "Abstract Syntax Notation One 1530 (ASN.1): Specification of basic notation", 1531 CCITT Recommendation X.680, July 2002. 1533 [CCITT.X690.2002] 1534 International International Telephone and Telegraph 1535 Consultative Committee, "ASN.1 encoding rules: 1536 Specification of basic encoding Rules (BER), Canonical 1537 encoding rules (CER) and Distinguished encoding rules 1538 (DER)", CCITT Recommendation X.690, July 2002. 1540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1541 Requirement Levels", BCP 14, RFC 2119, March 1997. 1543 [RFC3066] Alvestrand, H., "Tags for the Identification of 1544 Languages", RFC 3066, January 2001. 1546 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1547 Kerberos Network Authentication Service (V5)", RFC 4120, 1548 July 2005. 1550 7.2. Informative References 1552 [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows 1553 2000 Kerberos Change Password and Set Password Protocols", 1554 RFC 3244, February 2002. 1556 Author's Address 1558 Nicolas Williams 1559 Sun Microsystems 1560 5300 Riata Trace Ct 1561 Austin, TX 78727 1562 US 1564 Email: Nicolas.Williams@sun.com 1566 Full Copyright Statement 1568 Copyright (C) The IETF Trust (2007). 1570 This document is subject to the rights, licenses and restrictions 1571 contained in BCP 78, and except as set forth therein, the authors 1572 retain all their rights. 1574 This document and the information contained herein are provided on an 1575 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1576 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1577 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1578 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1579 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1580 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1582 Intellectual Property 1584 The IETF takes no position regarding the validity or scope of any 1585 Intellectual Property Rights or other rights that might be claimed to 1586 pertain to the implementation or use of the technology described in 1587 this document or the extent to which any license under such rights 1588 might or might not be available; nor does it represent that it has 1589 made any independent effort to identify any such rights. Information 1590 on the procedures with respect to rights in RFC documents can be 1591 found in BCP 78 and BCP 79. 1593 Copies of IPR disclosures made to the IETF Secretariat and any 1594 assurances of licenses to be made available, or the result of an 1595 attempt made to obtain a general license or permission for the use of 1596 such proprietary rights by implementers or users of this 1597 specification can be obtained from the IETF on-line IPR repository at 1598 http://www.ietf.org/ipr. 1600 The IETF invites any interested party to bring to its attention any 1601 copyrights, patents or patent applications, or other proprietary 1602 rights that may cover technology that may be required to implement 1603 this standard. Please address the information to the IETF at 1604 ietf-ipr@ietf.org. 1606 Acknowledgment 1608 Funding for the RFC Editor function is provided by the IETF 1609 Administrative Support Activity (IASA).