idnits 2.17.1 draft-ietf-krb-wg-kerberos-set-passwd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 31) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 372 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: UDP clients MUST not request the use of sequence numbers, otherwise they cannot generate the KRB-PRIV prior to receiving the AP-REP. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Nico' is mentioned on line 135, but not defined == Missing Reference: 'RFC1510' is mentioned on line 1446, but not defined ** Obsolete undefined reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Looks like a reference, but probably isn't: '1' on line 1405 -- Looks like a reference, but probably isn't: '0' on line 1417 -- Looks like a reference, but probably isn't: '2' on line 1375 -- Looks like a reference, but probably isn't: '3' on line 1378 == Missing Reference: 'APPLICATION 0' is mentioned on line 1075, but not defined -- Looks like a reference, but probably isn't: '4' on line 1325 == Missing Reference: 'APPLICATION 1' is mentioned on line 1087, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 1094, but not defined -- Looks like a reference, but probably isn't: '5' on line 1137 -- Looks like a reference, but probably isn't: '6' on line 1138 -- Looks like a reference, but probably isn't: '7' on line 1139 -- Looks like a reference, but probably isn't: '8' on line 1140 -- Looks like a reference, but probably isn't: '9' on line 1141 ** Obsolete normative reference: RFC 1602 (ref. 'RFC2026') (Obsoleted by RFC 2026) -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' ** Obsolete normative reference: RFC 1766 (ref. 'RFC3066') (Obsoleted by RFC 3066, RFC 3282) -- Possible downref: Non-RFC (?) normative reference: ref. 'KPASSWDv1' Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Kerberos Working Group Nicolas Williams 2 INTERNET-DRAFT Sun Microsystems 3 Category: Standards Track Jonathan Trostle 4 Cisco Systems 5 Mike Swift 6 University of WA 7 John Brezak 8 Microsoft 9 Bill Gossman 10 Cisco Systems 12 Kerberos Set/Change Password: Version 2 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [RFC2026]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This draft expires on December 31st, 2001. Please send comments to 37 the authors. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 This document specifies an extensible protocol for setting keys and 46 changing the passwords of Kerberos V principals. 48 Table of Contents 50 1 Introduction 51 2 The Protocol 52 2.1 Transports 53 2.2 Protocol Framing 54 2.2.1 The protocol over UDP 55 2.2.2 The protocol over TCP 56 2.3 Protocol version negotiation 57 2.3.1 Protocol major version negotiation 58 2.3.2 Protocol minor version negotiation 59 2.4 Use of Kerberos V 60 2.5 Use of ASN.1 61 2.6 Internationalization 62 2.6.1 Normalization Forms for UTF-8 Strings 63 2.6.2 Language Negotiation 64 2.7 Protocol Extensibility 65 2.8 Protocol Subsets 66 3 Protocol Elements 67 3.1 PDUs 68 3.2 Operations 69 3.2.1 Null 70 3.2.2 Change Kerberos Password 71 3.2.3 Set Kerberos Password 72 3.2.4 Set Kerberos Keys 73 3.2.5 Generate Kerberos Keys 74 3.2.6 Get New Keys 75 3.2.7 Commit New Keys 76 3.2.8 Get Password Quality Policy 77 3.2.9 Get Principal Aliases 78 3.2.10 Get Realm's Supported Kerberos V Version and Features 79 4 ASN.1 Module 80 6 IANA Considerations 81 7 Security Considerations 82 8 Acknowledgements 83 9 References 84 9.1 Normative References 85 9.2 Informative References 86 10 Authors' Addresses 87 11 Notes to the RFC Editor 89 Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 1 Introduction 97 Up to this point Kerberos V has lacked a single, standard protocol 98 for changing passwords and keys. While several vendor-specific 99 protocols exist for changing Kerberos passwords/keys, none are 100 properly internationalized and all are incomplete in one respect or 101 another and none are sufficiently extensible to cope with new 102 features that may be added to Kerberos V at some future time. 104 This document defines a protocol that is somewhat backward-compatible 105 with the "kpasswd" protocol, version 1 [KPASSWDv1] and a derivative 106 defined in [RFC3244] that uses more or less the same protocol 107 framing. 109 This new protocol is designed to be extensible and properly 110 internationalized. 112 2 The Protocol 114 The structure of the protocol is quite similar to that of typical RPC 115 protocols. Each transaction consists of a data structure specific to 116 an operation which is then wrapped in a data structure which is 117 general to all operations of the protocol. These data structures are 118 defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they 119 are encoded using the Distinguished Encoding Rules (DER) [X690]. 121 The protocol data is wrapped in a KRB-PRIV, or, in some cases, a 122 KRB-ERROR, and framed in a header that is backwards compatible with 123 version 1 [KPASSWDv1] of this protocol and [RFC3244]. 125 [Discussion: Should the v1/rfc3244 framing and port numbers be 126 dropped?] 128 2.1 Transports 130 The service SHOULD accept requests on UDP port 464 and TCP port 464. 131 This is the same port used by version 1 [KPASSWDv1] of this protocol, 132 but version 2 is a completely different protocol sharing with 133 [KPASSWDv1] and [RFC3244] only the outer framing. 135 [Discussion: Should we remove UDP support? I think so [Nico].] 137 2.2 Protocol Framing 139 For compatibility with the original Kerberos password changing 140 protocol developed at MIT as well as RFC3244, the first 4 bytes of 141 the message consist of a 2-byte network byte order message length, 142 followed by a 2 byte network byte order protocol version number, 143 followed by a 2 byte network byte order length for an optional 144 AP-REQ, AP-REP or KRB-ERROR, followed by the same, if present, 145 followed by a KRB-PRIV (optional in TCP) containing the actual 146 protocol message encoded in DER [X690]. 148 In the case of TCP there is an additional 4 byte network byte order 149 length prepended to the frame described above as per-RFC3244. 151 The protocol version number MUST be set to 2 for this protocol. 153 Bytes on the wire description of the framing: 155 0 1 2 3 156 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | message length | protocol version number | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | AP-REQ length (0 if absent) | AP-REQ data (if present) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | KRB-PRIV message | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 The same framing applies equally to requests and responses, but 166 responses use AP-REP and/or KRB-ERROR instead of AP-REQ: 168 0 1 2 3 169 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | message length | protocol version number | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | AP-REP length (0 if absent) | AP-REP data (if present) | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | KRB-PRIV message | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 0 1 2 3 179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | message length | protocol version number | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | KRB-ERROR length (0 if absent)| KRB-ERROR data (if present) | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 For the UDP case the AP-REQ/AP-REP/KRB-ERROR MUST always be included. 188 Note that this framing is used by version 1 [KPASSWDv1] and version 189 0xff80 [RFC3244], though the latter does not use the framing when 190 responding with KRB-ERROR messages. 192 Version 0xff80 servers may respond to requests with an un-framed 193 KRB-ERROR and e-data set as per-RFC3244 [RFC3244], otherwise clients 194 and server MUST always use this framing. See section 2.3. 196 2.2.1 The protocol over UDP 198 In the UDP case there is a single message from the client and a 199 single response from the server with no state kept between requests, 200 and each request MUST include a Kerberos AP-REQ and a KRB-PRIV and 201 each response MUST carry an AP-REP, or KRB-ERROR and a KRB-PRIV. 203 Both the client and server MUST destroy the sub-session key, if any, 204 resulting from the AP exchange after each operation. 206 UDP clients MUST not request the use of sequence numbers, otherwise 207 they cannot generate the KRB-PRIV prior to receiving the AP-REP. 209 2.2.2 The protocol over TCP 211 The initial message from the client MUST carry an AP-REQ and the 212 response to any request bearing an AP-REQ MUST carry an AP-REP. 214 Subsequent messages MAY involve Kerberos V AP exchanges, but 215 generally the client SHOULD NOT initiate a new AP exchange except 216 when it desires to authenticate as a different principal, when the 217 ticket last used for authentication expires or when the server 218 responds with an error indicating that the client must 219 re-authenticate. 221 KRB-PRIV messages should use the session or sub-session key 222 established in the most recent AP exchange performed over the same 223 TCP connection. 225 After each new AP exchange the client and server MUST destroy the 226 sub-session key, if any, resulting from the previous AP exchange. 228 Servers MAY close open sessions at any time. 230 2.3 Protocol version negotiation 232 There are several major versions of this protocol. Version 2 also 233 introduces a notion of protocol minor versions for use in negotiating 234 protocol extensions. As of this time only one minor version is 235 defined for major version 2: minor version 0, defined herein. 237 2.3.1 Protocol major version negotiation 239 Version 2 clients that also support other versions, such as 240 [KPASSWDv1] or [RFC3244] SHOULD attempt to use version 2 of the 241 protocol first and then MAY try other versions if the server responds 242 with either a message framed as described in section 2.2 but with a 243 protocol version number other than 2, or a KRB-ERROR with an error 244 code of KRB5_KPASSWD_BAD_VERSION in the e-data field. 246 Note that some version 1 servers return a KRB-ERROR indicating that 247 versions other than 1 of the change password protocol are not 248 supported rather than an AP-REP and a KRB-PRIV containing the error 249 data. 251 Also note that some [RFC3244] implementations do not return any 252 responses to requests for protocol versions other than 0xff80, and in 253 the TCP case close the TCP connection. 255 As a result change password protocol major version negotiation is 256 subject to downgrade attacks. Therefore major version negotiation is 257 NOT RECOMMENDED. 259 Version 2 servers SHOULD respond to non-v2 requests using whatever 260 response is appropriate for the versions used by the clients, but if 261 a server does not do this or know how to do this then it MUST respond 262 with an error framed as in section 2.2, using an AP-REP and KRB-PRIV 263 if the client's AP-REQ can be accepted, or a KRB-ERROR (framed) 264 otherwise and using a ProtocolErrorCode value of 265 unsupported-major-version or . 267 2.3.2 Protocol minor version negotiation 269 Version 2 clients are free to use whatever protocol minor version and 270 message extensions are available to them in their initial messages to 271 version 2 servers, provided that the minor versions (other than 0) 272 have been defined through IETF documents and registered with the 273 IANA. 275 Version 2 servers MUST answer with the highest protocol minor version 276 number supported by the server and the client. 278 Version 2 clients MUST use the protocol minor version used in a 279 server's reply for any subsequent messages in the same TCP session. 281 See section 2.7 for further description of the protocol's 282 extensibility and its relation to protocol minor versions and the 283 negotiation thereof. 285 2.4 Use of Kerberos V 287 This protocol makes use of messages defined in [RFC1510] and 288 [clarifications]. Specifically, AP-REQ, AP-REP, KRB-ERROR and 289 KRB-PRIV. 291 All operations are to be performed by the server on behalf of the 292 client principal. 294 Clients SHOULD use "kadmin/setpw" as the principal name of the server 295 for all requests except when changing the client principal's own 296 password, when expired, for which they should use "kadmin/changepw". 298 The client MUST request mutual authentication and the client MUST NOT 299 request the use of sequence numbers when using the protocol over 300 UDP, but it MUST request the use of sequence numbers when running 301 over TCP. 303 Clients SHOULD use INITIAL tickets for change password requests. 304 Servers MAY force the use of INITIAL tickets for any request - see 305 section 3.2. 307 2.5 Use of ASN.1 309 This protocol's messages are defined in ASN.1, using only features 310 from [X680]. All ASN.1 types defined herein are to be encoded in 311 DER [X690]. A complete ASN.1 module is given in section 4. The 312 ASN.1 tagging environment for this module is EXPLICIT. 314 The DER encoding of the ASN.1 PDUs are exchanged wrapped in a 315 KRB-PRIV as described above and/or as e-data in KRB-ERROR messages. 317 2.6 Internationalization 319 This protocol's request PDU carries an optional field indicating the 320 languages spoken by the client user; the client SHOULD send its list 321 of spoken languages to the server (once per-TCP session). All 322 strings in the protocol are UTF-8 strings. 324 The server SHOULD localize all strings intended for users to a 325 language in common with the languages spoken by the client user. 327 For TCP sessions servers MUST cache the optional language tag lists 328 from prior requests for use with subsequent requests that exclude the 329 language tag list. Clients MAY expect such server behaviour and send 330 the language tag lists only when they change or even just once 331 per-TCP session. Clients SHOULD send the server the language tag 332 list at least once. 334 Kerberos principal and realm names used in this protocol MUST be 335 constrained as per the specification of the version of Kerberos V 336 used by the client. 338 2.6.1 Normalization Forms for UTF-8 Strings 340 No normalization form is required for string types other than 341 for PrincipalName and Realm, which two types are constrained by the 342 specification of the version of Kerberos V used by the client, and 343 the password fields in the change password operation, which MUST be 344 normalized according to [k5stringprep]. 346 2.6.2 Language Negotiation 348 The server MUST pick a language from the client's input list or 349 the default language tag (see [RFC3066]) for text in its responses 350 which is meant for the user to read. 352 The server SHOULD use a language selection algorithm such that 353 consideration is first given to exact matches between the client's 354 spoken languages and the server's available locales, followed by 355 "fuzzy" matches where only the first sub-tags of the client's 356 language tag list are used for matching against the servers available 357 locales. 359 When the server has a message catalog for one of the client's spoken 360 languages the server SHOULD localize any text strings intended for 361 users to read. 363 2.7 Protocol Extensibility 364 The protocol is defined in ASN.1 and uses extensibility markers 365 throughout. As such, the module presented herein can be extended 366 within the framework of [X680]. 368 Typed holes are not used in this protocol as it is very simple and 369 does not require the ability to deal with abstract data types defined 370 in different layers. For this reason, the only way to extend this 371 protocol is by extending the ASN.1 module within the framework of the 372 IETF; all future extensions to this protocol have to be defined in 373 IETF documents unless otherwise specified in a future IETF revision 374 of this protocol. 376 A protocol minor version number is used to negotiate use of 377 extensions. See section 2.3.2 for the minor version negotiation. 379 Message extensions are to be closely tied to protocol minor numbers. 381 Clients MAY use any protocol minor version that they support in 382 initial requests, and MUST use the protocol minor version indicated 383 in the server's initial reply in any subsequent requests in the same 384 TCP session. 386 Servers SHOULD ignore additions to the ASN.1 types, in initial 387 requests, where the syntax allows them that they do not understand, 388 except for extensions to the "Op-req" type, which MUST result in an 389 error; servers MAY respond with an error (ProtocolErrorCode value of 390 unsupported-minor-version) to clients that use minor versions 391 unsupported by the server in their initial requests. 393 Servers MUST select the highest minor version in common with their 394 clients for use in replies. 396 2.8 Protocol Subsets 398 The structure of the protocol is such that the ASN.1 syntaxes for the 399 various operations supported by the protocol are independent of the 400 each other. Client and server mplementations MAY implement subsets 401 of the overall protocol by removing some alternatives to the Op-req, 402 Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4. 404 For example, it should be possible to have a password-change only 405 client that cannot set principal's keys - and vice versa. 407 3 Protocol Elements 409 The protocol as defined herein supports the following operations 410 relating to the management of Kerberos principal's passwords or keys: 412 - change password 413 - set password (administrative) 414 - set new keys 415 - generate new keys 416 - get new, un-committed keys 417 - commit new keys 418 - get password policy name and/or description of principal 419 - list aliases of a principal 420 - list enctypes and version of Kerberos V supported by realm 422 These operations are needed to support Kerberos V interoperability 423 between clients and KDCs of different implementation origins. 425 The operation for retrieving a list of aliases of a principal is 426 needed where KDCs implement aliasing of principal names and allows 427 clients to properly setup their "keytabs" when principal aliasing is 428 in use. 430 Operations such as creation or deletion of principals are outside the 431 scope of this document, and should be performed via other means, such 432 as through directories or other Kerberos administration protocols. 434 The individual operations are described in section 3.2. 436 3.1 PDUs 438 The types "Request," "Response" and "Error-Response" are the ASN.1 439 module's PDUs. 441 The "Request" and "Response" PDUs are always to be sent wrapped in 442 KRB-PRIV messages, except for the "Error-Response" PDU which MUST be 443 sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail, 444 otherwise it MUST be sent wrapped in a KRB-PRIV. 446 The ASN.1 syntax for the PDUs is given in section 4. 448 Note that the first field of each PDU is the major version of the 449 protocol, defaulted to 2, meaning that it is never included in 450 version 2 exchanges. Similarly, the second field of each PDU is the 451 minor version, defaulted to 0. 453 The request, responses and error PDUs consist of an outer structure 454 ("Request," "Response" and "Error-Response") containing fields common 455 to all requests/responses, and an inner structure for fields that are 456 specific to each operation's requests/responses. The inner structure 457 is optional in the case of the Error-Response PDU and need not be 458 included when generic errors occur for which there is a suitable 459 ProtocolErrorCode. 461 Specifically, the outer Request structure has a field for passing a 462 client user's spoken (read) languages to the server. It also has two 463 optional fields for identifying the requested operation's target 464 principal's name and realm (if not sent then the server MUST use the 465 client principal name and realm from the AP exchange as the target). 467 The Response and Error PDUs' outer structures include a field 468 indicating the language that the server has chosen for localization 469 of text intended to be displayed to users; this field is defaulted 470 to "i-default". This language tag applies to all UTF8 strings 471 in the inner structure (Op-rep and Op-err) that are meant to be 472 displayed to users. 474 The protocol error codes are: 476 - proto-generic-error 478 An operation-specific error ocurred, see the inner Op-error. 480 - proto-format-error 481 - proto-unsupported-major-version 482 - proto-unsupported-minor-version 483 - proto-unsupported-operation 485 - proto-wrong-service-principal 487 Use kadmin/setpw for the server's principal name. 489 - proto-re-authentication-required 491 The server demands that the client re-authenticate through a new 492 AP exchange. 494 - proto-initial-ticket-required 496 Use of an INITIAL ticket is required for the requested 497 operation. 499 - proto-client-and-target-realm-mismatch 501 The server requires that the client's principal name and the 502 target principal of the operation share the same realm name. 504 - proto-target-principal-unknown 505 - proto-authorization-failed 507 3.2 Operations 509 This section describes the semantics of each operation request and 510 response defined in the ASN.1 module in section 4. 512 3.2.1 Null 514 NAME 516 null - Null or "ping" operation 518 DESCRIPTION 520 The null request is intended for use with TCP; its purpose is 521 similar to RPC null procedures and is akin to a "ping" operation. 523 ERRORS 525 None. 527 3.2.2 Change Kerberos Password 529 NAME 531 change-pw - Change password operation 533 SYNOPSIS 535 Req-change-pw(old-pw, [new-pw], [etypes]) -> 536 Rep-change-pw([info-text], [new-pw], [etypes]) | 537 Err-change-pw([help-text], error code, [error info]) 539 DESCRIPTION 541 Change a principal's password. 543 The change password request has one required field and three 544 optional fields: "old-pw" (required), "new-pw" and "etypes", 545 corresponding to the target principal's old password, new password 546 and desired enctypes for the new long-term keys. 548 The server MUST validate the old password and MUST check the 549 quality of the new password, if sent, according the password 550 quality policy associated with the target principal. 552 The server SHOULD require that the old password be sent or that 553 the client's ticket be INITIAL, or both, when the client principal 554 and the target principal are the same. 556 A client MAY request that the server generate a new password by 557 excluding the new password from its request, in which case the 558 server MUST either generate a new password or respond with an 559 error indicating that it does not support this feature. 561 Server-generated passwords MUST meet the target principal's 562 password quality policy. It is RECOMMENDED that server-generated 563 passwords be user-friendly, that is, memorable and that the target 564 principal's preferred languages be taken into account by the 565 password generation alogrithm used by the server. 567 RETURN 569 Upon successful password changes the server responds with a 570 Rep-change-pw. The fields of Rep-change-pw are all optional and 571 include: 573 - 'info-text' which the server can use to send a message to the 574 user such as "Your new password will expire in 90 days," for 575 example. 577 - 'new-pw' which the server MUST include if the client 578 requested that the server generate a new password; generated 579 passwords MUST pass the target principal's password quality 580 policy. 582 - 'etypes' which the server MAY include to indicate which types 583 of long-term keys it created for the target principal and 584 which the server MUST include if the client specified a set 585 of enctypes in its request. 587 ERRORS 589 The server may respond to change password requests with protocol 590 or operation errors. See section 3.1 for a description of 591 protocol error codes. 593 All operation errors include an optional 'help-text' field by 594 which the server can describe the error in a human-readable, 595 localizaed string. 597 Change password error codes include: 599 - generic-error 601 - old-pw-incorrect 603 - wont-generate-new-pw 605 The server will not generate a new password for this 606 principal or does not support password generation in general. 608 - new-pw-rejected-generic 610 The client's proposed new password failed the target 611 principal's password quality policy. 613 The server MUST include a description of the password quality 614 policy or aspect of it that the client's proposed new 615 password failed to meet. 617 The server MAY generate and send a new password that the 618 client can then use as a new password and which is guaranteed 619 to pass the target principal's current password quality 620 policy. 622 - etype-not-supported 624 The client requested an enctype that the KDC does not 625 support. 627 3.2.3 Set Kerberos Password 628 NAME 630 set-pw - Set password operation 632 SYNOPSIS 634 Req-set-pw([languages], [new-pw], [etypes]) -> 635 Rep-set-pw([info-text], [new-pw], [etypes]) | 636 Err-set-pw([help-text], error code, [error info]) 638 DESCRIPTION 640 Administratively set a principal's password. 642 The change password request has three optional fields: 643 "languages", "new-pw" and "etypes", corresponding to the target 644 principal's preferred languages, new password and desired enctypes 645 for the new long-term keys. 647 The server MUST check the quality of the new password, if sent, 648 according the password quality policy associated with the target 649 principal. 651 The server SHOULD require that the client use the change-pw 652 operation instead of set-pw when the client principal and the 653 target principal are the same. 655 A client MAY request that the server generate a new password by 656 excluding the new password from its request, in which case the 657 server MUST either generate a new password or respond with an 658 error indicating that it does not support this feature. 660 Server-generated passwords MUST meet the target principal's 661 password quality policy. It is RECOMMENDED that server-generated 662 passwords be user-friendly, that is, memorable and that the target 663 principal's preferred languages be taken into account by the 664 password generation alogrithm used by the server. 666 RETURN 668 Upon successful password changes the server responds with a 669 Rep-change-pw. The fields of Rep-change-pw are all optional and 670 include: 672 - 'info-text' which the server can use to send a message to the 673 user such as "Your new password will expire in 90 days," for 674 example. 676 - 'new-pw' which the server MUST include if the client 677 requested that the server generate a new password; generated 678 passwords MUST pass the target principal's password quality 679 policy. 681 - 'etypes' which the server MAY include to indicate which types 682 of long-term keys it created for the target principal and 683 which the server MUST include if the client specified a set 684 of enctypes in its request. 686 ERRORS 688 The server may respond to change password requests with protocol 689 or operation errors. See section XYZ for a description of 690 protocol error codes. 692 All operation errors include an optional 'help-text' field by 693 which the server can describe the error in a human-readable, 694 localizaed string. 696 Change password error codes include: 698 - generic-error 700 - use-change-pw 702 The server demands that the client use the change-pw 703 operation for the target principal of the set-pw request. 705 - wont-generate-new-pw 707 The server will not generate a new password for this 708 principal or does not support password generation in general. 710 - new-pw-rejected-generic 712 The client's proposed new password failed the target 713 principal's password quality policy. 715 The server MUST include a description of the password quality 716 policy or aspect of it that the client's proposed new 717 password failed to meet. 719 The server MAY generate and send a new password that the 720 client can then use as a new password and which is guaranteed 721 to pass the target principal's current password quality 722 policy. 724 - etype-not-supported 726 The client requested an enctype that the KDC does not 727 support. 729 3.2.4 Set Kerberos Keys 731 NAME 732 set-keys 734 SYNOPSIS 736 Req-set-keys(new-keys, commit?, [isupport]) -> 737 Rep-set-keys([info-text], kvno, aliases, [isupport]) 739 DESCRIPTION 741 The set-keys request consists of two required fields and one 742 optional field: "new-keys", "commit" (a boolean field - see below) 743 and "isupport", an optional field for indicating to the KDC what 744 Kerberos V features are supported by the target principal. 746 When "commit" is true the KDC makes the new keys available for 747 issueing tickets encrypted in them immediately. Otherwise the 748 client MUST follow up with a commit-keys request to make the keys 749 available. 751 If a principal has keys are awaiting commitment when a new 752 set-keys request for that principal s made then the KDC MUST 753 overwrite the deferred keys. 755 RETURN 757 For successful set-keys operations the server returns: 759 - Informational text, optional. 761 - The new kvno for the target principal. 763 - A list of aliases of the target principal known to the KDC 764 (optional). 766 - The set of Kerberos V features supported by the KDC 767 (optional). 769 ERRORS 771 The server may respond with the following errors: 773 - generic 774 - deferred-commit-no-support 775 - etype-no-support 777 3.2.5 Generate Kerberos Keys 779 NAME 781 gen-keys 783 SYNOPSIS 784 Req-gen-keys(etypes, [entropy], commit?, [isupport]) -> 785 Rep-set-keys([info-text], key, kvno, aliases, [isupport]) 787 DESCRIPTION 789 The gen-keys is similar to the set-keys request (see section 790 3.2.4) but differs in that the server generates keys of 791 client-requested enctypes, rather than the client providing 792 specific keys. 794 The gen-keys request consists of two required fields and two 795 optional fields: "etypes" (the enctypes of the new keys), 796 "entropy", "commit" and "isupport" (see section 3.2.4). 798 If a principal has keys are awaiting commitment when a new 799 set-keys request for that principal s made then the KDC MUST 800 overwrite the deferred keys. 802 RETURN 804 For successful set-keys operations the server returns: 806 - Informational text, optional. 808 - The new kvno for the target principal. 810 - The new key (only one is needed). 812 - A list of aliases of the target principal known to the KDC 813 (optional). 815 - The set of Kerberos V features supported by the KDC 816 (optional). 818 ERRORS 820 The server may respond with the following errors: 822 - generic 823 - deferred-commit-no-support 824 - etype-no-support 826 3.2.6 Get New Keys 828 NAME 830 get-keys 832 SYNOPSIS 834 Req-get-keys(kvno) -> 835 Rep-get-keys([info-text], keys, aliases, [isupport]) | 836 Err-get-keys([help-text], error code, [error info]) 837 DESCRIPTION 839 This request allows a client to get the keys set or generated in a 840 previous set-keys or gen-keys request with deferred commitment.. 842 RETURN 844 If the target principal and kvno correspond to uncommitted keys 845 the server MUST respond with the actual keys that would be set by 846 a subsequent commit-keys request. Otherwise the server MUST 847 respond with an error (meaning that this operation cannot be used 848 to extract keys from the KDC that may be in use). 850 ERRORS 852 - generic 853 - kvno-committed 854 - no-such-kvno 856 3.2.7 Commit New Keys 858 NAME 860 commit-keys 862 SYNOPSIS 864 Req-commit-keys(kvno) -> 865 Rep-commit-keys() | 866 Err-commit-keys([help-text], error code, [error info]) 868 DESCRIPTION 870 The commit-keys operation allows a client to bring a principal's 871 new keys into use at the KDC. 873 Clients SHOULD make a commit-keys request corresponding to a 874 deferred commitment set-keys/gen-keys operation as soon as the 875 local key database for the target principal is updated. 877 The target principal name and the kvno MUST match those from a 878 prior set-keys or gen-keys operation. 880 Servers MAY expire delayed key commitments at will. Servers 881 SHOULD expire uncommitted new keys after a reasonable amount of 882 time (600 seconds is RECOMMENDED). 884 Servers MUST respond to new set-keys requests for principals with 885 pending, uncommitted new keys by expiring the uncommitted new keys 886 and proceeding as if there had been no expired new keys. 888 ERRORS 889 - generic 890 - new-keys-conflict (A set-keys or gen-keys request succeeded 891 subsequent to the request that matches this 892 {principal, kvno} tuple.) 894 3.2.8 Get Password Quality Policy 896 NAME 898 get-pw-policy 900 SYNOPSIS 902 Req-get-pw-policy() -> 903 Rep-get-pw-policy([policy name], [policy description]) 905 DESCRIPTION 907 Returns a description of the target principal's associated 908 password quality policy, if any, as a list of localized 909 UTF8String values. 911 Clients can use this operation in conjunction with the change-pw 912 operation to obtain text that can be displayed to the user before 913 the user actually enters a new password. 915 It is common for sites to set policies with respect to password 916 quality. It is beyond the scope of this document to describe such 917 policies. Management of password quality policies' actual content 918 is also beyond the scope of this protocol. 920 ERRORS 922 No operation errors are defined. 924 3.2.9 Get Principal Aliases 926 NAME 928 get-print-aliases 930 SYNOPSIS 932 Req-get-princ-aliases() -> 933 Rep-get-princ-aliases(aliases) 935 DESCRIPTION 937 Returns a list of aliases of the target principal. 939 ERRORS 940 No operation-specific errors. 942 3.2.10 Get Realm's Supported Kerberos V Version and Features 944 NAME 946 get-realm-krb5-support 948 SYNOPSIS 950 Req-get-realm-krb5-support() -> 951 Rep-get-realm-krb5-support(isupport) 953 DESCRIPTION 955 Returns set of Kerberos V features support by the target 956 principal's realm's KDCs. 958 ERRORS 960 No operation-specific errors. 962 3.3 Principal Aliases 964 Applications that use Kerberos often have to derive acceptor 965 principal names from hostnames entered by users. Such hostnames may 966 be aliases, they may be fully qualified, partially qualified or not 967 qualified at all. Some implementations have resorted to deriving 968 principal names from such hostnames by utilizing the names services 969 to canonicalize the hostname first; such practices are not secure 970 unless the name service are secure, which often aren't. 972 One method for securely deriving principal names from hostnames is to 973 alias principals at the KDC such that the KDC will issue tickets for 974 principal names which are aliases of others. It is helpful for 975 principals to know what are their aliases as known by the KDCs. 977 Note that changing a principal's aliases is out of scope for this 978 protocol. 980 3.4 Kerberos V Feature Negotiation 982 ... 984 4 ASN.1 Module 986 DEFINITIONS EXPLICIT TAGS ::= BEGIN 988 -- From [clarifications] with modifications 989 PrincipalName ::= SEQUENCE { 990 name-string [1] SEQUENCE OF UTF8String 991 } 992 Realm ::= UTF8String 994 -- NOTE WELL: Principal and realm names MUST be constrained by the 995 -- specification of the version of Kerberos V used by the 996 -- client. 997 -- 998 -- [Perhaps PrincipalName should be a SEQUENCE of an optional name 999 -- type and a UTF8String, for simplicity.] 1001 -- From [clarifications] 1002 Int32 ::= INTEGER (-2147483648..2147483647) 1003 UInt32 ::= INTEGER (0..4294967295) 1005 -- Based on [clarifications] 1006 Etype ::= Int32 -- as in [clarifications] 1007 Key ::= SEQUENCE { 1008 enc-type [0] Etype, -- from Kerberos 1009 key [1] OCTET STRING, 1010 ... 1011 } 1013 Language-Tag ::= UTF8String -- Constrained by [RFC3066] 1015 -- Empty, extensible SEQUENCEs are legal ASN.1 1016 Extensible-NULL ::= SEQUENCE { 1017 ... 1018 } 1020 -- Kerberos clients negotiate some parameters relating to their peers 1021 -- indirectly through the KDC. Today this is true of ticket session 1022 -- key enctypes, but in the future this indirect negotiation may also 1023 -- occur with respect to the minor version of Kerberos V to be used 1024 -- between clients and servers. Additionally, KDCs may need to know 1025 -- what authorization-data types are supported by service principals, 1026 -- both, for compatibility with legacy software and for optimization. 1027 -- 1028 -- Thesefore it is important for KDCs to know what features of 1029 -- Kerberos V each service principal supports. 1030 -- 1031 -- In version 2.0 of this protocol the clients and servers may notify 1032 -- each other of their support for: 1033 -- 1034 -- - KerberosV minor version (rfc1510 -> 0, clarifications ->1) 1035 -- - enctypes 1036 -- - authorization data types 1037 -- - transited encoding data types 1038 -- 1039 -- All authorization-data types defined in [clarifications] are 1040 -- assumed to be supported if the minor version is 1 and do not need 1041 -- to be included in the ad-type list. 1042 -- 1043 -- Int32 is used for enctype and transited encoding data type 1044 -- identifiers. 1046 -- 1047 -- An extensible CHOICE of Int32 is used for authorization data 1048 -- types. 1050 KerberosV-TR-ID ::= Int32 1052 KerberosV-AD-ID ::= CHOICE { 1053 ad-int [0] Int32, 1054 ... 1055 } 1057 KerberosVSupportNego ::= SEQUENCE { 1058 version [0] ENUM { 1059 rfc1510, 1060 clarifications, -- replace with assigned RFC number 1061 -- add extensions 1062 ... 1063 } 1064 enc-types [1] SEQUENCE OF Etype, 1065 ad-types [2] SEQUENCE OF KerberosV-AD-ID OPTIONAL, 1066 -- authorization data types 1067 tr-enc-types [3] SEQUENCE OF KerberosV-TR-ID OPTIONAL, 1068 -- transited encoding types 1069 ... 1070 -- A future extended Kerberos V may have optional features, in 1071 -- which case there might be an additional choice here, not of 1072 -- NULL, but of some other, possibly structured, type. 1073 } 1075 Request ::= [APPLICATION 0] SEQUENCE { 1076 pvno-minor [0] INTEGER DEFAULT 0, 1077 languages [1] SEQUENCE OF Language-Tag OPTIONAL, 1078 -- Should be defaulted to the SEQUENCE of "i-default" 1079 targ-name [2] PrincipalName OPTIONAL, 1080 targ-realm [3] Realm OPTIONAL, 1081 -- If targ-name/realm are missing then the request 1082 -- applies to the principal of the client 1083 operation [4] Op-req, 1084 ... 1085 } 1087 Response ::= [APPLICATION 1] SEQUENCE { 1088 pvno-minor [0] INTEGER DEFAULT 0, 1089 language [1] Language-Tag DEFAULT "i-default", 1090 result [2] Op-rep, 1091 ... 1092 } 1094 Error-Response ::= [APPLICATION 2] SEQUENCE { 1095 pvno-minor [0] INTEGER DEFAULT 0, 1096 language [1] Language-Tag DEFAULT "i-default", 1097 error-code [2] ProtocolErrorCode, 1098 help-text [3] UTF8String OPTIONAL, 1099 op-error [4] Op-err OPTIONAL, 1100 ... 1101 } 1103 Op-req ::= CHOICE { 1104 null [0] Req-null, 1105 change-pw [1] Req-change-pw, 1106 set-pw [2] Req-set-pw, 1107 set-keys [3] Req-set-keys, 1108 gen-keys [4] Req-gen-keys, 1109 get-keys [5] Req-get-keys, 1110 commit-keys [6] Req-commit-keys, 1111 get-pw-policy [7] Req-get-pw-policy, 1112 get-princ-aliases [8] Req-get-princ-aliases, 1113 get-realm-krb5-support [9] Req-get-realm-krb5-support, 1114 ... 1115 } 1117 Op-rep ::= CHOICE { 1118 null [0] Rep-null, 1119 change-pw [1] Rep-change-pw, 1120 set-pw [2] Rep-set-pw, 1121 set-keys [3] Rep-set-keys, 1122 gen-keys [4] Req-gen-keys, 1123 get-keys [5] Req-get-keys, 1124 commit-keys [6] Rep-commit-keys, 1125 get-pw-policy [7] Rep-get-pw-policy, 1126 get-princ-aliases [8] Rep-get-princ-aliases, 1127 get-realm-krb5-support [9] Rep-get-realm-krb5-support, 1128 ... 1129 } 1131 Op-err ::= CHOICE { 1132 null [0] Err-null, 1133 change-pw [1] Err-change-pw, 1134 set-pw [2] Err-set-pw, 1135 set-keys [3] Err-set-keys, 1136 gen-keys [4] Err-gen-keys, 1137 get-keys [5] Err-get-keys, 1138 commit-keys [6] Err-commit-keys, 1139 get-pw-policy [7] Err-get-pw-policy, 1140 get-princ-aliases [8] Err-get-princ-aliases, 1141 get-realm-krb5-support [9] Err-get-realm-krb5-support, 1142 ... 1143 } 1145 ProtocolErrorCode ::= ENUM { 1146 proto-format-error, 1147 proto-unsupported-major-version, 1148 proto-unsupported-minor-version, 1149 proto-unsupported-operation, -- Request CHOICE tag unknown 1150 proto-generic-see-op-error, -- See Op-error 1151 proto-wrong-service-principal, -- Use kadmin/setpw 1152 proto-re-authentication-required, 1153 proto-initial-ticket-required, 1154 proto-client-and-target-realm-mismatch, 1155 proto-target-principal-unknown, 1156 proto-authorization-failed, 1157 ... 1158 } 1160 -- 1161 -- Requests and responses 1162 -- 1164 -- NULL request, much like ONC RPC's NULL procedure - NOT extensible 1165 Req-null ::= NULL 1167 Rep-null ::= NULL 1169 Err-null ::= NULL 1171 -- Change password 1172 Req-change-pw ::= SEQUENCE { 1173 old-pw [0] UTF8String, 1174 new-pw [1] UTF8String OPTIONAL, 1175 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 1176 ... 1177 } 1179 Rep-change-pw ::= SEQUENCE { 1180 info-text [0] UTF8String OPTIONAL, 1181 new-pw [1] UTF8String OPTIONAL, 1182 -- generated by the server if present 1183 -- (and requested by the client) 1184 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 1185 ... 1186 } 1188 Err-change-pw ::= SEQUENCE { 1189 help-text [0] UTF8String OPTIONAL, 1190 error [1] CHOICE { 1191 op-generic-error [0] Extensible-NULL, 1192 op-old-pw-incorrect [1] Extensible-NULL, 1193 op-wont-generate-new-pw [2] Extensible-NULL, 1194 op-new-pw-rejected-generic [3] SEQUENCE { 1195 policy [1] SEQUENCE OF UTF8String, 1196 suggested-pw [2] UTF8String OPTIONAL, 1197 ... 1198 } 1199 op-etype-not-supported [4] SEQUENCE { 1200 supported-etypes [1] SEQUENCE OF Etype, 1201 ... 1202 }, 1203 ... 1204 }, 1205 ... 1206 } 1208 -- Set password 1209 Req-set-pw ::= SEQUENCE { 1210 languages [0] SEQUENCE OF Language-Tag OPTIONAL, 1211 new-pw [1] UTF8String OPTIONAL, 1212 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 1213 ... 1214 } 1216 Rep-set-pw ::= SEQUENCE { 1217 info-text [0] UTF8String OPTIONAL, 1218 new-pw [1] UTF8String OPTIONAL, 1219 -- generated by the server if present 1220 -- (and requested by the client) 1221 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 1222 ... 1223 } 1225 Err-set-pw ::= SEQUENCE { 1226 help-text [0] UTF8String OPTIONAL, 1227 error [1] CHOICE { 1228 op-generic-error [0] Extensible-NULL, 1229 op-use-change-pw [1] Extensible-NULL, 1230 op-wont-generate-new-pw [2] Extensible-NULL, 1231 op-new-pw-rejected-generic [3] SEQUENCE { 1232 policy [1] SEQUENCE OF UTF8String, 1233 suggested-pw [2] UTF8String OPTIONAL, 1234 ... 1235 } 1236 op-etype-not-supported [4] SEQUENCE { 1237 supported-etypes [1] SEQUENCE OF Etype, 1238 ... 1239 }, 1240 ... 1241 }, 1242 ... 1243 } 1245 -- Set keys 1246 Req-set-keys ::= SEQUENCE { 1247 keys [0] SEQUENCE OF Key, 1248 commit [1] BOOLEAN, 1249 -- TRUE -> install keys now 1250 -- 1251 -- FALSE -> require set-keys-commit 1252 -- before issuing tickets 1253 -- encrypted with these keys. 1254 -- 1255 -- See commit-keys op 1256 isupport [2] KerberosVSupportNego OPTIONAL, 1257 -- For future Kerberos V extensions KDCs 1258 -- may need to know what krb5 version is 1259 -- supported by individual service 1260 -- principals. This field provides a 1261 -- way to tell the KDC what version of 1262 -- Kerberos V the target principal 1263 -- supports. 1264 ... 1265 } 1267 Rep-set-keys ::= SEQUENCE { 1268 info-text [0] UTF8String OPTIONAL, 1269 kvno [1] UInt32, 1270 aliases [2] SEQUENCE OF SEQUENCE { 1271 name [0] PrincipalName, 1272 realm [1] Realm OPTIONAL, 1273 ... 1274 }, 1275 isupport [3] KerberosVSupportNego OPTIONAL, 1276 ... 1277 -- Should there be ETYPE-INFO2 stuff here? 1278 } 1280 Err-set-keys ::= SEQUENCE { 1281 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1282 error [1] CHOICE { 1283 op-generic [0] Extensible-NULL, 1284 op-deferred-commit-no-support [1] Extensible-NULL, 1285 op-etype-no-support [2] SEQUENCE OF { 1286 supported-etypes [1] SEQUENCE OF Etype, 1287 ... 1288 } 1289 ... 1290 } 1291 } 1293 -- Generate keys 1294 Req-gen-keys ::= SEQUENCE { 1295 etypes [0] SEQUENCE (1..) OF Etype, 1296 entropy [1] OCTET STRING OPTIONAL, 1297 commit [2] BOOLEAN, 1298 -- TRUE -> install keys now 1299 -- 1300 -- FALSE -> require set-keys-commit 1301 -- before issuing tickets 1302 -- encrypted with these keys. 1303 -- 1304 -- See commit-keys op 1305 isupport [3] KerberosVSupportNego OPTIONAL, 1306 -- For future Kerberos V extensions KDCs 1307 -- may need to know what krb5 version is 1308 -- supported by individual service 1309 -- principals. This field provides a 1310 -- way to tell the KDC what version of 1311 -- Kerberos V the target principal 1312 -- supports. 1313 ... 1314 } 1316 Rep-gen-keys ::= SEQUENCE { 1317 info-text [0] UTF8String OPTIONAL, 1318 kvno [1] UInt32, 1319 key [2] Key, 1320 aliases [3] SEQUENCE OF SEQUENCE { 1321 name [0] PrincipalName, 1322 realm [1] Realm OPTIONAL, 1323 ... 1324 }, 1325 isupport [4] KerberosVSupportNego OPTIONAL, 1326 ... 1327 -- Should there be ETYPE-INFO2 stuff here? 1328 } 1330 Err-gen-keys ::= Err-set-keys 1332 -- Get un-committed key request 1333 Req-get-keys ::= SEQUENCE { 1334 kvno [0] UInt32, 1335 ... 1336 } 1338 Rep-get-keys ::= SEQUENCE { 1339 info-text [0] UTF8String OPTIONAL, 1340 keys [1] SEQUENCE OF Key, 1341 aliases [2] SEQUENCE OF SEQUENCE { 1342 name [0] PrincipalName, 1343 realm [1] Realm OPTIONAL, 1344 ... 1345 }, 1346 isupport [3] KerberosVSupportNego OPTIONAL, 1347 ... 1348 -- Should there be ETYPE-INFO2 stuff here? 1349 } 1351 Err-get-keys ::= SEQUENCE { 1352 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1353 error [1] CHOICE { 1354 op-generic [0] Extensible-NULL, 1355 op-kvno-committed [1] Extensible-NULL, 1356 op-no-such-kvno [1] Extensible-NULL, 1357 ... 1358 } 1359 } 1361 -- Commit a set keys request 1362 Req-commit-keys ::= SEQUENCE { 1363 kvno [0] UInt32, 1364 ... 1365 } 1367 Rep-commit-keys ::= Extensible-NULL 1369 Err-commit-keys ::= SEQUENCE { 1370 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 1371 error [1] CHOICE { 1372 op-generic [0] Extensible-NULL, 1373 op-kvno-expired [1] Extensible-NULL, 1374 -- The client took too long to respond. 1375 op-kvno-unknown [2] Extensible-NULL, 1376 -- The targ princ/kvno is invalid or unknown to the 1377 -- server (perhaps it lost track of state) 1378 op-new-keys-conflict [3] Extensible-NULL, 1379 -- A new-keys/commit-keys request subsequent to the 1380 -- new-keys that produced the kvno has completed 1381 -- and incremented the principal's kvno 1382 ... 1383 } 1384 ... 1385 } 1387 -- Get password policy 1388 Req-get-pw-policy ::= Extensible-NULL 1390 Rep-get-pw-policy ::= SEQUENCE { 1391 policy-name [0] UTF8String OPTIONAL, 1392 description [1] SEQUENCE OF UTF8String OPTIONAL, 1393 ... 1394 } 1396 Err-get-pw-policy ::= Extensible-NULL 1398 -- Get principal aliases 1399 Req-get-princ-aliases ::= Extensible-NULL 1401 Rep-get-princ-aliases ::= SEQUENCE { 1402 help-text [0] UTF8String OPTIONAL, 1403 aliases [1] SEQUENCE OF SEQUENCE { 1404 name [0] PrincipalName, 1405 realm [1] Realm OPTIONAL, 1406 ... 1407 }, 1408 ... 1409 } 1411 Err-get-princ-aliases ::= Extensible-NULL 1413 -- Get list of enctypes supported by KDC for new keys 1414 Req-get-realm-krb5-support ::= Extensible-NULL 1416 Rep-get-realm-krb5-support ::= SEQUENCE { 1417 isupport [0] KerberosVSupportNego, 1418 -- Version of Kerberos V supported by 1419 -- the target realm. 1420 ... 1421 } 1423 Err-get-realm-krb5-support ::= Extensible-NULL 1425 END 1427 6 IANA Considerations 1429 None. 1431 7 Security Considerations 1433 Implementors and site administrators should note that the redundancy 1434 of UTF-8 encodings varies by Unicode codepoint used. Password 1435 quality policies should, therefore, take this into account when 1436 estimating the amount of redundancy and entropy in a proposed new 1437 password. [?? It's late at night - I think this is correct.] 1439 Kerberos set/change password/key protocol major version negotiation 1440 cannot be done securely. A downgrade attack is possible against 1441 clients that attempt to negotiate the protocol major version to use 1442 with a server. It is not clear at this time that the attacker would 1443 gain much from such a downgrade attack other than denial of service 1444 (DoS) by forcing the client to use a protocol version which does not 1445 support some feature needed by the client (Kerberos V in general is 1446 subject to a variety of DoS attacks anyways [RFC1510]). 1448 This protocol does not have Perfect Forward Security (PFS). As a 1449 result, any passive network snooper watching password/key changing 1450 operations who has stolen a principal's password or long-term keys 1451 can find out what the new ones are. 1453 [More text needed] 1455 8 Acknowledgements 1457 The authors would like to thank Raeburn, Tom Yu, Martin Rex, Sam 1458 Hartman, Tony Andrea, Paul W. Nelson, Marcus Watts, Love, Joel N. 1459 Weber II, Jeffrey Hutzelman and other participants from the IETF 1460 Kerberos Working Group for their assistance. 1462 9 References 1464 9.1 Normative References 1466 [RFC2026] 1467 S. Bradner, RFC2026: "The Internet Standard Process - Revision 1468 3," October 1996, Obsoletes - RFC 1602, Status: Best Current 1469 Practice. 1471 [RFC2119] 1472 S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to 1473 Indicate Requirement Levels," March 1997, Status: Best Current 1474 Practice. 1476 [X680] 1477 Abstract Syntax Notation One (ASN.1): Specification of Basic 1478 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC 1479 International Standard 8824-1:1998. 1480 http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf 1482 [X690] 1483 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), 1484 Canonical Encoding Rules (CER) and Distinguished Encoding Rules 1485 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International 1486 Standard 8825-1:1998. 1487 http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf 1489 [clarifications] 1490 RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg- 1491 kerberos-clarifications. 1493 [k5stringprep] 1494 RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg- 1495 utf8-profile. 1497 [RFC3066] 1498 H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of 1499 Languages," January 2001, Obsoletes RFC1766, Status: Best Current 1500 Practice. 1502 [KPASSWDv1] 1503 (Reference needed!) 1505 9.2 Informative References 1507 [RFC3244] 1508 M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000 1509 Kerberos Change Password and Set Password Protocols," February 1510 2002, Status: Informational. 1512 10 Authors' Addresses 1514 Nicolas Williams 1515 Sun Microsystems 1516 5300 Riata Trace Ct 1517 Austin, TX 78727 1518 Email: nicolas.williams@sun.com 1520 Jonathan Trostle 1521 Cisco Systems 1522 170 W. Tasman Dr. 1523 San Jose, CA 95134 1524 Email: jtrostle@cisco.com 1526 Mike Swift 1527 University of Washington 1528 Seattle, WA 1529 Email: mikesw@cs.washington.edu 1531 John Brezak 1532 Microsoft 1533 1 Microsoft Way 1534 Redmond, WA 98052 1535 Email: jbrezak@microsoft.com 1537 Bill Gossman 1538 Cisco Systems 1539 500 108th Ave. NE, Suite 500 1540 Bellevue, WA 98004 1541 Email: bgossman@cisco.com 1543 11 Notes to the RFC Editor 1545 This document has two KRB WG drafts as normative references and 1546 cannot progress until those drafts progress, but no other draft 1547 depends on this one. 1549 Full Copyright Statement 1551 Copyright (C) The Internet Society (2003). All Rights Reserved. 1553 This document and translations of it may be copied and furnished to 1554 others, and derivative works that comment on or otherwise explain it 1555 or assist in its implementation may be prepared, copied, published 1556 and distributed, in whole or in part, without restriction of any 1557 kind, provided that the above copyright notice and this paragraph are 1558 included on all such copies and derivative works. However, this 1559 document itself may not be modified in any way, such as by removing 1560 the copyright notice or references to the Internet Society or other 1561 Internet organizations, except as needed for the purpose of 1562 developing Internet standards in which case the procedures for 1563 copyrights defined in the Internet Standards process must be 1564 followed, or as required to translate it into languages other than 1565 English. 1567 The limited permissions granted above are perpetual and will not be 1568 revoked by the Internet Society or its successors or assigns. 1570 This document and the information contained herein is provided on an 1571 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1572 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1573 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1574 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1575 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1577 Acknowledgement 1579 Funding for the RFC Editor function is currently provided by the 1580 Internet Society.