1 2Kerberos Working Group Jonathan Trostle 3INTERNET-DRAFT Cisco Systems 4Category: Standards Track Mike Swift 5 University of WA 6 John Brezak 7 Microsoft 8 Bill Gossman 9 Cisco Systems 10 Nicolas Williams 11 Sun Microsystems 12 13 14 15 Kerberos Set/Change Password: Version 2 16 <draft-ietf-krb-wg-kerberos-set-passwd-00.txt> 17 18 19 20 21Status of this Memo 22 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026 [RFC2026]. 25 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 30 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet- Drafts as reference 34 material or to cite them other than as "work in progress." 35 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 38 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 41 42 This draft expires on December 31st, 2001. Please send comments to 43 the authors. 44 45 46Copyright Notice 47 48 Copyright (C) The Internet Society (2003). All Rights Reserved. 49 50Abstract 51 52 This proposal specifies an extensible protocol for setting keys and 53 changing the passwords of Kerberos [RFC1510] principals. 54 55 The protocol support a single operation per-session when run over UDP, or 56 57Trostle et. al. [Page 1] 58 59DRAFT Kerberos Set/Change Password v2 Expires November 2003 60 61 multiple operations per-session when run over TCP. Clients can 62 change their own principal's password or keys or they can change 63 other principals', provided that they are properly authorized to do 64 so. 65 66 Additional related features include the ability to determine the 67 known aliases of Kerberos principals. This feature will facilitate 68 the implementation of aliasing of target principal names in KDC 69 requests by allowing principals to know which names are aliases of 70 their canonical principal names. Principal aliasing is needed to 71 properly support the use of aliases and short-form names by users 72 without requiring that clients canonicalize principal names, possibly 73 using insecure name services in the process. 74 75 This protocol uses IETF language tags [RFC3066] to negotiate proper 76 localization of help messages intended for users. UTF-8 is used 77 throughout for strings, suitably constrained, where necessary, by the 78 minor version of Kerberos V in use by clients and servers. 79 801. Introduction 81 82 Kerberos lacks a single, standard protocol for changing passwords and 83 keys. While several vendor-specific protocols exist for changing 84 Kerberos passwords/keys, none are properly internationalized. 85 86 This document defines a protocol that is somewhat backward-compatible 87 with the "kpasswd" protocol, version 1 [KPASSWDv1] and a derivative 88 defined in [RFC3244] that uses more or less the same protocol framing. 89 90 This new protocol is designed to be extensible and properly 91 internationalized. 92 932. Conventions used in this document 94 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 98 993. Table of Contents 100 101 1. Introduction 102 2. Conventions used in this document 103 3. Table of Contents 104 4. The Protocol 105 4.1 Transports 106 4.2 Protocol Framing 107 4.2.1 The protocol over UDP 108 4.2.2 The protocol over TCP 109 4.3 Protocol version negotiation 110 4.3.1 Protocol major version negotiation 111 4.3.2 Protocol minor version negotiation 112 4.4 Use of Kerberos V 113 4.4.1 Use of KRB-ERROR 114 115Trostle et. al. [Page 2] 116 117DRAFT Kerberos Set/Change Password v2 Expires November 2003 118 119 4.5 Use of ASN.1 120 4.6 Protocol internationalization 121 4.6.1 Normalization forms for UTF-8 strings 122 4.6.2 Language negotiation 123 4.7 Protocol Extensibility 124 4.8 Protocol Subsets 125 5 Protocol Operations 126 5.1 PDUs 127 6 ASN1 Module 128 7 Descriptions of each protocol requests and responses 129 7.1 Null Request 130 7.2 Change Password 131 7.3 Set Keys Requests 132 7.5 The Get Policy Request 133 7.6 The Get Aliases Request 134 7.7 The Get Supported Enctypes Request 135 8 IANA Considerations 136 9 Security Considerations 137 10 Description of TLV Encoding of Sample Subsets of the Protocol 138 10.1 TLV encoding of the Null request and response 139 10.2 TLV encoding of Error-Response 140 10.3 TLV encoding of the change password requests and responses 141 10.4 TLV encoding of Change Keys requests and responses 142 11 Acknowledgements 143 12 References 144 13 Expiration Date 145 14 Authors' Addresses 146 15 Notes to the RFC Editor 147 1484. The Protocol 149 150 The structure of the protocol is quite similar to that of typical RPC 151 protocols. Each operation has a structure for each client request and 152 a structure for each server response. Each transaction consists of a 153 single operation; the abstract syntax for the protocol implies the 154 use, on the wire, of an operation identifier associated with an 155 opaque blob representing the request of response. The protocol data 156 is wrapped in a KRB-PRIV and framed in a header that is backwards 157 compatible with version 1 of this protocol. 158 1594.1 Transports 160 161 The service SHOULD accept requests on UDP port 464 and TCP port 464. 162 This is the same port used by version 1 [KPASSWDv1] of this protocol, 163 but version 2 is a completely different protocol sharing with version 164 1 only the outer framing. 165 1664.2 Protocol Framing 167 168 For compatibility with the original Kerberos password changing 169 protocol developed at MIT, the first 4 bytes of the message consist 170 of a 2-byte network byte order message length, followed by a 2 byte 171 network byte order protocol version number, followed by a 2 byte 172 173Trostle et. al. [Page 3] 174 175DRAFT Kerberos Set/Change Password v2 Expires November 2003 176 177 network byte order length for an optional AP-REQ, AP-REP or 178 KRB-ERROR, followed by the same, if present, followed by a KRB-PRIV 179 (optional in TCP) containing the actual protocol message encoded in 180 DER [X690]. 181 182 In the case of TCP there is an additional 4 byte network byte order 183 length prepended to the frame described above. 184 185 The protocol version number MUST be set to 2 for this protocol. 186 187 Bytes on the wire description of the framing: 188 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | message length | protocol version number | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | AP-REQ length (0 if absent) | AP-REQ data (if present) / 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 / KRB-PRIV message / 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 199 The same framing applies equally to requests and responses, but 200 responses use AP-REP and/or KRB-ERROR instead of AP-REQ: 201 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | message length | protocol version number | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | AP-REP length (0 if absent) | AP-REP data (if present) / 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 / KRB-PRIV message / 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | message length | protocol version number | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | KRB-ERROR length (0 if absent)| KRB-ERROR data (if present) / 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 220 For the UDP case the AP-REQ/AP-REP/KRB-ERROR MUST always be included. 221 222 Note that this framing is used by version 1 [KPASSWDv1] and version 223 0xff80 [RFC3244], though the latter does not use the framing when 224 responding with KRB-ERROR messages. 225 226 Servers MAY respond to version 0xff80 requests with an un-framed 227 KRB-ERROR and e-data set as per-RFC3244 [RFC3244], otherwise clients 228 and server MUST always use this framing. See section 4.3. 229 230 231Trostle et. al. [Page 4] 232 233DRAFT Kerberos Set/Change Password v2 Expires November 2003 234 2354.2.1 The protocol over UDP 236 237 In the UDP case there is a single message from the client and a 238 single response from the server with no state kept between requests, 239 and each request MUST include a Kerberos AP-REQ and a KRB-PRIV and 240 each response MUST carry an AP-REP, or KRB-ERROR and a KDB-PRIV. 241 Both the client and server MUST destroy the authentication context 242 after each operation. 243 244 UDP clients MUST not request the use of sequence numbers, otherwise 245 it cannot generate the KRB-PRIV prior to receiving the AP-REP. 246 Clients MAY refuse to operate version 2 of the protocol over UDP; it 247 is RECOMMENDED that servers reject version 2 UDP requests. 248 2494.2.2 The protocol over TCP 250 251 When used with the TCP transport, there is a 4 octet header in 252 network byte order that precedes the message and specifies the length 253 of the message. 254 255 The initial message from the client MUST carry an AP-REQ and the 256 response to any request bearing an AP-REQ MUST carry an AP-REP. 257 258 Subsequent messages MAY involve Kerberos V AP exchanges, but 259 generally the client SHOULD NOT initiate a new AP exchange except 260 when it desires to authenticate as a different principal, when 261 its current authentication context is about to expire or when the 262 server responds with an error indicating that the client must 263 re-initialize the authentication context (possibly due to the 264 previous context expiring). 265 266 The server MUST NOT process any requests that do not contain an 267 AP-REQ unless a non-expired authentication context is currently 268 established with the client on the same TCP connection. 269 270 Servers MAY close open sessions at any time. 271 2724.3 Protocol version negotiation 273 274 There are several major versions of this protocol. Version 2 also 275 introduces a notion of protocol minor versions for use in negotiating 276 protocol extensions. As of this time only one minor version is 277 defined for major version 2: minor version 0. 278 2794.3.1 Protocol major version negotiation 280 281 Version 2 clients that also support other versions, such as 282 [KPASSWDv1] or [rfc3244] SHOULD attempt to use version 2 of the 283 protocol first and then try other versions if the server 284 responds with either a message framed as described in section 4.2 but 285 with a protocol version number other than 2 (in the case of 286 [KPASSWDv1], or a KRB-ERRROR with an error code of 287 KRB5_KPASSWD_BAD_VERSION in the e-data field [RFC3244]. 288 289Trostle et. al. [Page 5] 290 291DRAFT Kerberos Set/Change Password v2 Expires November 2003 292 293 294 Note that some version 1 servers return a KRB-ERROR indicating that 295 versions other than 1 of the change password protocol are not 296 supported rather than an AP-REP and a KRB-PRIV containing the error 297 data. Therefore change password protocol negotiation is subject to 298 downgrade attacks where version 2 clients support version 1 of this 299 protocol. 300 301 Also note that some [RFC3244] implementations do not return any 302 responses to requests for protocol versions other than 0xff80, and in 303 the TCP case close the TCP connection. 304 305 Version 2 servers MAY support other versions of the Kerberos password 306 change protocol. 307 308 Version 2 servers SHOULD respond to non-v2 requests using whatever 309 response is appropriate for the versions used by the clients, but if 310 a server does not do this or know how to do this then it MUST respond 311 with an error framed as in section 4.2, using an AP-REP and KRB-PRIV 312 if the client's AP-REQ can be accepted, or a KRB-ERROR (framed) 313 otherwise and using a ProtocolErrorCode value of 314 unsupported-major-version. 315 3164.3.2 Protocol minor version negotiation 317 318 Version 2 clients are free to use whatever protocol minor version and 319 message extensions are available to them in their initial messages to 320 version 2 servers, provided that the minor versions (other than 0) 321 have been defined through IETF documents and registered with the 322 IANA. 323 324 Version 2 clients and servers MUST support all protocol minor 325 versions between 0 to the highest version supported by the client and 326 server. That is, a client or server that supports minor version 4 327 MUST also support minor versions 0, 1, 2 and 3. 328 329 Version 2 servers MUST answer with the highest protocol minor version 330 number supported by the server and the client. 331 332 Version 2 clients MUST use the protocol minor version used in a 333 server's reply for any subsequent messages in the same session 334 (currently this only applies to TCP sessions). 335 336 See section 4.7 for further description of the protocol's 337 extensibility and its relation to protocol minor versions and the 338 negotiation thereof. 339 3404.4 Use of Kerberos V 341 342 This protocol makes use of messages defined in [RFC1510] and 343 [clarifications]. Specifically, AP-REQ, AP-REP, KRB-ERROR and 344 KRB-PRIV. Because of the proposed extensions to Kerberos V which 345 will require a new ASN.1 module, and because of the ways that the 346 347Trostle et. al. [Page 6] 348 349DRAFT Kerberos Set/Change Password v2 Expires November 2003 350 351 Kerberos V ASN.1 types will change, this protocol cannot safely 352 import any types from the Kerberos V module, therefore the Kerberos 353 PDUs are encoded as OCTET STRINGs herein. 354 355 All operations are to be performed by the server on behalf of the 356 client principal. 357 358 The client SHOULD use "kadmin/changepw" as the server principal name 359 for this protocol. The server MUST have a principal name of 360 "kadmin/changepw" and MAY have a principal name of "kadmin/setpw." 361 362 The client MUST request mutual authentication and the client MUST NOT 363 request the use of sequence numbers when using the protocol over 364 UDP, but it MUST request the use of sequence numbers when running 365 over TCP. 366 367 The server MUST reject requests that operate on the same principal as 368 the client's if the client's principal is not in the same realm as 369 the server's principal name or if the client's ticket is not INITIAL. 370 371 The server MAY reject all requests from clients operating on 372 principals not in the client's realm. The server MAY reject all 373 requests operating on principals other than the client's. 374 3754.4.1 Use of KRB-ERROR 376 377 When an error arises during the AP exchange for which 378 [clarifications] does not provide an appropriate error code then the 379 server MUST use KRB_ERR_GENERIC as the error, a localized (if 380 possible [er, is that ok, pre-extensions? probably not]) error string 381 for the e-text field of KRB-ERROR and the encoding of an 382 Error-Response PDU (see section 6) as e-data. 383 3844.5 Use of ASN.1 385 386 This protocol's messages are defined in ASN.1, using only features 387 from [X680]. All ASN.1 types defined herein are to be encoded in 388 DER [X690]. A complete ASN.1 module is given in section 6. The 389 ASN.1 tagging environment for this module is EXPLICIT. 390 391 The DER encoding of the ASN.1 PDUs are exchanged wrapped in a 392 KRB-PRIV as described above. 393 3944.6 Protocol internationalization 395 396 Protocol requests have an optional field indicationg the languages 397 spoken by the client user; the client SHOULD send its list of spoken 398 languages to the server (once per-TCP session), but if future 399 extensions to the Kerberos protocol should add similar functionality 400 then the client SHOULD NOT use this field when using the extended 401 Kerberos protocol. All strings in the protocol are UTF-8 strings. 402 The server SHOULD localize all strings intended for users to a 403 language in common with the languages spoken by the client user. 404 405Trostle et. al. [Page 7] 406 407DRAFT Kerberos Set/Change Password v2 Expires November 2003 408 409 410 For TCP sessions servers MUST cache the optional language tag lists 411 from prior requests for use with requests that exclude the language 412 tag list. Clients MAY expect such server behaviour and send the 413 language tag lists only when they change or even just once per-TCP 414 session. Clients SHOULD send the server the language tag list at 415 least once, with or before any actual operation. 416 417 Kerberos principal and realm names used in this protocol MUST be 418 constrained as per the specification of the version of Kerberos V 419 used by the client. 420 4214.6.1 Normalization forms for UTF-8 strings 422 423 No normalization form is required for string types other than 424 for PrincipalName and Realm, which two types are constrained by the 425 specification of the version of Kerberos V used by the client, and 426 the password fields in the change password operation, which MUST be 427 normalized according to [k5stringprep]. 428 4294.6.2 Language negotiation 430 431 The server MUST pick a language from the client's input list or 432 the default language tag (see [RFC3066]) for text in its responses 433 which is meant for the user to read. 434 435 The server SHOULD use a language selection algorithm such that 436 consideration is first given to exact matches between the client's 437 spoken languages and the server's available locales, followed by 438 "fuzzy" matches where only the first sub-tags of the client's 439 language tag list are used for matching against the servers available 440 locales. 441 442 When the server has a message catalog for one of the client's spoken 443 languages the server SHOULD localize any text strings intended for 444 users to read. 445 4464.7 Protocol Extensibility 447 448 The protocol is defined in ASN.1 and uses extensibility markers 449 throughout. As such, the module presented herein can be extended 450 within the framework of [X680]. 451 452 Typed holes are not used in this protocol as it is very simple and 453 does not require the ability to deal with abstract data types defined 454 in different layers. For this reason, the only way to extend this 455 protocol is by extending the ASN.1 module within the framework of the 456 IETF; all future extensions to this protocol have to be defined in 457 IETF documents unless otherwise specified in a future IETF revision 458 of this protocol. 459 460 A protocol minor version number is used to negotiate use of 461 extensions. See section 4.3.2 for the minor version negotiation. 462 463Trostle et. al. [Page 8] 464 465DRAFT Kerberos Set/Change Password v2 Expires November 2003 466 467 468 Message extensions are to be closely tied to protocol minor numbers. 469 Clients MAY use any protocol minor version that they support in 470 initial requests, and MUST use the protocol minor version indicated 471 in the server's initial reply in any subsequent requests in the same 472 session (this only applies in the TCP case). Clients MAY cache the 473 minor version number supported by any given server for a reasonably 474 short and finite amount of time - 24 hours is the maximum RECOMMENDED 475 time for caching server minor version information. 476 477 Servers SHOULD ignore protocol extensions and minor versions that they 478 do not understand in initial requests, except for extensions to the 479 "Op-req" type, which MUST result in an error; servers MAY respond 480 with an error (ProtocolErrorCode value of unsupported-minor-version) 481 to clients that use minor versions unsupported by the server in their 482 initial requests. 483 484 Servers MUST select the highest minor version in common with their 485 clients for use in replies. 486 487 Servers MAY support a subset of the operations defined in this 488 protocol but MUST support all the PDUs. 489 4904.8 Protocol Subsets 491 492 The structure of the protocol is such that the ASN.1 syntaxes for the 493 various operations supported by the protocol are independent of the 494 each other. Clients and servers MAY implement subsets of the overall 495 protocol. 496 497 The structure of this protocol and the properties of the 498 tag-length-value (TLV) DER encoding of ASN.1 make it possible to 499 describe the encoding of individual operations' messages very simply. 500 501 In the interest of facilitating ease of implementation for trivial 502 subsets of this protocol, without the need for ASN.1 compilers, 503 section 10 describes examples of TLV layouts of some individual 504 protocol operations (but the DER encodings of tags, lengths and 505 UNIVERSAL values is not described). 506 507 5085 Protocol Operations 509 510 The protocol as defined herein supports the following operations 511 relating to the management of Kerberos principal's passwords or keys: 512 513 - change password 514 - set key 515 - get password policy name and/or description of principal 516 - list aliases of a principal 517 - list enctypes supported by realm 518 519 These operations are needed to support Kerberos V interoperability 520 521Trostle et. al. [Page 9] 522 523DRAFT Kerberos Set/Change Password v2 Expires November 2003 524 525 between clients and KDCs of different implementation origins. 526 527 The operation for retrieving a list of aliases of a principal is 528 needed where KDCs implement aliasing of principal names and allows 529 clients to properly setup their "keytabs" when principal aliasing is 530 in use. 531 532 Operations such as creation or deletion of principals are outside the 533 scope of this document, and should be performed via directories or 534 other Kerberos administration protocols. However, it is conceivable 535 that such operations could be added to this protocol at a later 536 point. 537 538 Operations can be added to the protocol only via future IETF RFCs. 539 540 The individual operations are described in section 7. 541 5425.1 PDUs 543 544 The types "Request," "Response" and "Error-Response" are the ASN.1 545 module's PDUs. 546 547 The "Request" and "Response" PDUs are always to be sent wrapped in 548 KRB-PRIV messages, except for the "Error-Response" PDU which MUST be 549 sent as KRB-ERROR e-data (see section 4.4.1) when AP exchanges fail, 550 otherwise it MUST be sent wrapped in a KRB-PRIV. 551 552 The PDUs are described in section 6. 553 554 5556 ASN1 Module 556 557DEFINITIONS EXPLICIT TAGS ::= BEGIN 558 559-- Unsafe: IMPORT AP-REQ, AP-REP, KRB-ERROR, KRB-PRIV, PrincipalName, 560-- Realm, KerberosString, FROM KerberosV5Spec2 561 562-- From [clarifications] 563PrincipalName ::= SEQUENCE { 564 name-type [0] Int32, 565 name-string [1] SEQUENCE OF UTF8String 566} 567Realm ::= UTF8String 568-- NOTE WELL: Principal and realm names MUST be constrained by the 569-- specification of the version of Kerberos V used by the 570-- client. 571-- 572-- [Perhaps PrincipalName should be a SEQUENCE of an optional name type 573-- and a UTF8String, for simplicity.] 574 575-- From [clarifications] 576Int32 ::= INTEGER (-2147483648..2147483647) 577UInt32 ::= INTEGER (0..4294967295) 578 579Trostle et. al. [Page 10] 580 581DRAFT Kerberos Set/Change Password v2 Expires November 2003 582 583 584-- Based on EncryptionKey type from [clarifications] 585Key ::= SEQUENCE { 586 enc-type [0] Int32, -- from Kerberos 587 key [1] OCTET STRING, 588 ... 589} 590 591Etype ::= Int32 -- as in [clarifications] 592-- Perhaps we should use an extensible CHOICE of Int32? 593 594Language-Tag ::= UTF8String -- Constrained by [RFC3066] 595 596-- Use LangTaggedText instead of UTF8String for *-text fields and remove 597-- "language" field? 598-- 599-- LangTaggedText should be used as e-text for KRB-ERROR, at least in 600-- extensions, perhaps in [clarifications] 601LangTaggedText ::= SEQUENCE { 602 language [0] Language-Tag OPTIONAL, 603 text [1] UTF8String, 604 ... 605} 606 607Request ::= [APPLICATION 0] SEQUENCE { 608 pvno-major [0] INTEGER DEFAULT 2, 609 pvno-minor [1] INTEGER DEFAULT 0, 610 languages [2] SEQUENCE OF Language-Tag OPTIONAL, 611 targ-name [3] PrincipalName OPTIONAL, 612 targ-realm [4] Realm OPTIONAL, 613 -- If targ-name/realm are missing then the request 614 -- applies to the principal of the client 615 operation [5] Op-req, 616 ... 617} 618 619Response ::= [APPLICATION 1] SEQUENCE { 620 pvno-major [0] INTEGER DEFAULT 2, 621 pvno-minor [1] INTEGER DEFAULT 0, 622 language [2] Language-Tag DEFAULT "i-default", 623 result [3] Op-rep OPTIONAL, 624 ... 625} 626 627Error-Response ::= [APPLICATION 2] SEQUENCE { 628 pvno-major [0] INTEGER DEFAULT 2, 629 pvno-minor [1] INTEGER DEFAULT 0, 630 language [2] Language-Tag DEFAULT "i-default", 631 error-code [3] ProtocolErrorCode, 632 help-text [4] UTF8String OPTIONAL, 633 op-error [5] Op-error OPTIONAL, 634 ... 635} 636 637Trostle et. al. [Page 11] 638 639DRAFT Kerberos Set/Change Password v2 Expires November 2003 640 641 642Op-req ::= CHOICE { 643 null [0] Req-null, 644 change-pw [1] Req-change-pw, 645 set-keys [2] Req-set-keys, 646 get-pw-policy [3] Req-get-pw-policy, 647 get-princ-aliases [4] Req-get-princ-aliases, 648 get-supported-etypes [5] Req-get-supported-etypes, 649 ... 650} 651 652Op-rep ::= CHOICE { 653 null [0] Rep-null, 654 change-pw [1] Rep-change-pw, 655 set-keys [2] Rep-set-keys, 656 get-pw-policy [3] Rep-get-pw-policy, 657 get-princ-aliases [4] Rep-get-princ-aliases, 658 get-supported-etypes [5] Rep-get-supported-etypes, 659 ... 660} 661 662Op-error ::= CHOICE { 663 null [0] Err-null, 664 change-pw [1] Err-change-pw, 665 set-keys [2] Err-set-keys, 666 get-pw-policy [3] Err-get-pw-policy, 667 get-princ-aliases [4] Err-get-princ-aliases, 668 get-supported-etypes [5] Err-get-supported-etypes, 669 ... 670} 671 672ProtocolErrorCode ::= ENUM { 673 -- Remember, ASN.1 enums are zero-based 674 generic-error, 675 unsupported-major-version, 676 unsupported-minor-version, 677 unsupported-operation, 678 authorization-failed, 679 initial-ticket-required, 680 target-principal-unknown, 681 ... 682} 683 684-- 685-- Requests and responses 686-- 687 688-- NULL request, much like ONC RPC's NULL procedure 689Req-null ::= NULL 690 691Rep-null ::= NULL 692 693Err-null ::= NULL 694 695Trostle et. al. [Page 12] 696 697DRAFT Kerberos Set/Change Password v2 Expires November 2003 698 699 700-- Change password 701Req-change-pw ::= SEQUENCE { 702 old-pw [0] UTF8String, 703 new-pw [1] UTF8String OPTIONAL, 704 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 705 ... 706} 707 708Rep-change-pw ::= SEQUENCE { 709 info-text [0] UTF8String OPTIONAL, 710 new-pw [1] UTF8String OPTIONAL, 711 -- generated by the server if present 712 -- (and requested by the client) 713 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, 714 ... 715} 716 717Err-change-pw ::= SEQUENCE { 718 help-text [0] UTF8String OPTIONAL, 719 code [1] ENUM { 720 generic, 721 wont-generate-new-pw, 722 old-pw-incorrect, 723 new-pw-rejected-generic, 724 pw-change-too-soon, 725 ... 726 }, 727 suggested-new-pw [2] UTF8String OPTIONAL, 728 ... 729} 730 731-- Change/Set keys 732 733Req-set-keys ::= SEQUENCE { 734 etypes [0] SEQUENCE (1..) OF Etype, 735 entropy [1] OCTET STRING OPTIONAL, 736 -- The client can provide entropy for 737 -- the server's use while generating 738 -- keys. 739 ... 740} 741 742Rep-set-keys ::= SEQUENCE { 743 info-text [0] UTF8String OPTIONAL, 744 kvno [1] UInt32, 745 keys [2] SEQUENCE (1..) OF Key, 746 -- The server always makes the keys. 747 aliases [3] SEQUENCE OF SEQUENCE { 748 name [0] PrincipalName, 749 realm [1] Realm OPTIONAL, 750 ... 751 } OPTIONAL, 752 753Trostle et. al. [Page 13] 754 755DRAFT Kerberos Set/Change Password v2 Expires November 2003 756 757 ... 758} 759 760Err-set-keys ::= SEQUENCE { 761 help-text [0] UTF8String OPTIONAL, -- Reason for rejection 762 enctypes [1] SEQUENCE of Etype OPTIONAL, -- supported enctypes 763 code [2] ENUM { 764 etype-no-support, 765 ... 766 } 767} 768 769-- Get password policy 770Req-get-pw-policy ::= NULL 771 772Rep-get-pw-policy ::= SEQUENCE { 773 help-text [0] UTF8String OPTIONAL, 774 policy-name [1] UTF8String OPTIONAL, 775 description [2] UTF8String OPTIONAL, 776 ... 777} 778 779Err-get-pw-policy ::= NULL 780 781-- Get principal aliases 782Req-get-princ-aliases ::= NULL 783 784Rep-get-princ-aliases ::= SEQUENCE { 785 help-text [0] UTF8String OPTIONAL, 786 aliases [1] SEQUENCE OF SEQUENCE { 787 name [0] PrincipalName, 788 realm [1] Realm OPTIONAL, 789 ... 790 } OPTIONAL, 791 ... 792} 793 794Err-get-princ-aliases ::= NULL 795 796-- Get list of enctypes supported by KDC for new keys 797Req-get-supported-etypes ::= NULL 798 799Rep-get-supported-etypes ::= SEQUENCE OF Etype 800 801Err-get-supported-etypes ::= NULL 802 803END 804 8057 Descriptions of each protocol requests and responses 806 807 This section describes the semantics of each operation request and 808 response defined in the ASN.1 module in section 6. 809 810 811Trostle et. al. [Page 14] 812 813DRAFT Kerberos Set/Change Password v2 Expires November 2003 814 815 Requests and responses consist of an outer structure ("Request," 816 "Response" and "Error-Response") containing fields common to all 817 requests/responses, and an inner structure for fields that are 818 specific to each operation's requests/responses. 819 820 Specifically, the outer Request structure has a field for passing a 821 client's spoken (read) languages to the server. It also has two 822 optional fields for identifying the operation's target principal's 823 name and realm (if not sent then the server MUST use the client 824 principal name and realm from the AP exchange as the target). 825 826 The Response and Error PDU' outer structures include a field 827 indicating the language that the server has chosen for localization 828 of text intended to be displayed to users. 829 830 All three PDUs, "Request," "Response," and "Error-Response" include a 831 protocol version number and the two responses include an optional 832 field through which the server can indicate which language, from the 833 client's list, the server can "speak." 834 8357.1 Null Request 836 837 The null request is intended for use with TCP; its purpose is similar 838 to RPC null procedures and is akin to a "ping" operation. 839 8407.2 Change Password 841 842 The change password request has two fields: old-pw (old password - 843 required) and new-pw (new password - optional). The server MUST 844 validate the old password and MUST check the quality of the new 845 password, if sent, according to the password policy associated with 846 the client's principal before accepting the request. If the client 847 does not specify a new password the server MUST either generate one 848 and return it in the response or reject the request with 849 wont-generate-new-pw as the Err-change-pw message's error code. 850 851 If the server rejects a client's proposed new password it SHOULD 852 include a description of the password quality policy in effect for 853 the target principal and/or an explanation of what was wrong with the 854 proposed password in the help-text field of the Err-change-pw 855 message. Additionally, servers MAY include a randomly generated, but 856 preferably user-friendly password in the suggested-new-pw field of 857 Err-change-pw messages when the client's proposed new password 858 violates the target principal's password quality policy; of course, 859 any such suggested new password MUST pass the target principal's 860 password quality policy. 861 862 Clients MAY specify key enctypes to set with new passwords, but 863 generally SHOULD NOT do so. If a client requests specific enctypes 864 then the server MUST NOT create keys from the new password of any 865 enctype other than those requested by the client. 866 867 Servers MAY indicate the enctypes of the keys created with new 868 869Trostle et. al. [Page 15] 870 871DRAFT Kerberos Set/Change Password v2 Expires November 2003 872 873 passwords, but SHOULD NOT do so unless the client requested specific 874 enctypes - in which case the server MUST include the new key enctypes 875 in the change password response. 876 8777.3 Set Keys Requests 878 879 The set keys request consists of a sequence of key enctypes and an 880 optional OCTET STRING of client-provided entropy. 881 882 The server generates keys of the requested enctypes and returns them. 883 The server MAY utilize some, all or none of the client-provided 884 entropy, if any, to generate the keys, but the server SHOULD input 885 some entropy in the process. 886 887 The server SHOULD also include a list of the target principal's 888 aliases, if there are any. 889 8907.5 The Get Policy Request 891 892 It is common for sites to set policies with respect to password 893 quality. It is beyond the scope of this document to describe such 894 policies. However, it is reasonable for password policies to have 895 names and as such for this protocol to associate named password 896 quality policies with principals. It may also be reasonable for 897 users to learn of their password quality policies. 898 899 The protocol therefore provides an operation for retrieving the name 900 and/or description of the password policy that applies to the target 901 principal name. 902 903 Management of password quality policies' actual content is beyond the 904 scope of this protocol. 905 9067.6 The Get Aliases Request 907 908 This request allows a client to obtain a list of aliases associated 909 with a principal so that the client can properly configure the 910 principal's "keytab." 911 912 Principal aliases are principal names for which the KDC will issue 913 tickets (with the alias being either the client or target principal 914 name of such tickets) using the same key as the "canonical" principal 915 name, but without canonicalizing the aliased names in KDC exchanges. 916 9177.7 The Get Supported Enctypes Request 918 919 This request allows a client to learn of the target principal's 920 realm's supported enctypes. 921 922 9238 IANA Considerations 924 925 ... 926 927Trostle et. al. [Page 16] 928 929DRAFT Kerberos Set/Change Password v2 Expires November 2003 930 931 9329 Security Considerations 933 934 Implementors and site administrators should note that the redundancy 935 of UTF-8 encodings varies by Unicode codepoint used. Password 936 quality policies should, therefore, take this into account when 937 estimating the amount of redundancy and entropy in a proposed new 938 password. [?? It's late at night - I think this is correct.] 939 940 Kerberos set/change password/key protocol major version negotiation 941 cannot be done securely. A downgrade attack is possible against 942 clients that attempt to negotiate the protocol major version to use 943 with a server. It is not clear at this time that the attacker would 944 gain much from such a downgrade attack other than denial of service 945 (DoS) by forcing the client to use a protocol version which does not 946 support some feature needed by the client (Kerberos V in general is 947 subject to a variety of DoS attacks anyways [RFC1510]). 948 949 [More text needed] 950 95110 Description of TLV Encoding of Sample Subsets of the Protocol 952 953 This section provides example descriptions of the TLV DER encodings of 954 some requests and responses. This section is not intended to be 955 authoritative and implementors are encouraged to base their 956 implementations on the ASN.1 syntax given in section 6. These TLV 957 descriptions are given here in the interest of promoting 958 implementation of this protocol even by implementors who do not have 959 access to ASN.1 development tools. 960 961 Tags are described as T(<tag>) where <tag> is a letter denoting the 962 tag type (u for UNIVERSAL, a for APPLICATION, c for CONTEXT and p for 963 PRIVATE) and a number or universal type name. 964 965 Lengths and values are described as L{<value>}, where <value> is a 966 description of the encoding of the value, except for scalar UNIVERSAL 967 types, where <value> shall be '<' description of value '>'. 968 969 Optional fields are enclosed in square brackets ('[' and ']'). 970 971 Repetition is denoted by ellipsis ("..."). 972 973 Extensibility is denoted by "[...]". 974 975 Comments are introduced by "--" as in ASN.1 976 97710.1 TLV encoding of the Null request and response 978 979 -- Null Request 980 -- Outer application tag 981 T(a0)L{T(uSEQUENCE)L{ 982 -- "preamble" 983 -- pvno-major == 2 so it is left out 984 985Trostle et. al. [Page 17] 986 987DRAFT Kerberos Set/Change Password v2 Expires November 2003 988 989 -- pvno-minor == 0 so it is left out 990 -- optional languages list 991 [T(c2)L{ 992 T(uSEQUENCE)L{ 993 T(uUTF8String)L{<language tag>} 994 ... 995 } 996 }] 997 -- optional targ-name 998 [T(c3)L{ 999 Tc(uSEQUENCE)L{ 1000 -- name-type 1001 T(c0)L{T(uINTEGER)L{<name-type>}} 1002 -- name-string 1003 T(c1)L{ 1004 T(uSEQUENCE)L{ 1005 [T(uUTF8String)L{<component name>}] 1006 ... 1007 } 1008 } 1009 } 1010 }] 1011 -- optional targ-realm 1012 [T(c4)L{T(uUTF8String)L{<realm name>}}] 1013 -- end of preamble 1014 1015 -- operation choice tag 1016 T(c5)L{ 1017 -- null CHOICE (this tag indicates the CHOICE taken; replace this 1018 -- TLV with the TLV for any operation to get the Request encoding 1019 -- of that operation) 1020 T(c0)L{ 1021 -- Req-null (this is the encoding of the value of the CHOICE 1022 -- taken); NULL has no LV part. 1023 T(uNULL) 1024 } 1025 } 1026 -- extensions 1027 [...] 1028 }} 1029 1030 -- Null Response 1031 -- Outer application tag 1032 T(a1)L{T(uSEQUENCE)L{ 1033 -- "preamble" 1034 -- pvno-major == 2 so it is left out 1035 -- pvno-minor == 0 so it is left out 1036 -- optional language 1037 [T(c1)L{T(uUTF8String)L{<language tag>}}] 1038 -- end preamble 1039 -- operation choice tag 1040 T(c2)L{ 1041 -- null CHOICE 1042 1043Trostle et. al. [Page 18] 1044 1045DRAFT Kerberos Set/Change Password v2 Expires November 2003 1046 1047 T(c0)L{ 1048 T(uNULL) 1049 } 1050 } 1051 }} 1052 105310.2 TLV encoding of Error-Response 1054 1055 -- Error Response 1056 -- Outer application tag 1057 T(a1)L{T(uSEQUENCE)L{ 1058 -- "preamble" 1059 -- pvno-major == 2 so it is left out 1060 -- pvno-minor == 0 so it is left out 1061 -- optional language 1062 [T(c2)L{T(uUTF8String)L{<language tag>}}] 1063 -- end preamble 1064 -- error code 1065 T(c3)L{T(uENUM)L{<error code}} 1066 T(c4)L{T(uUTF8String)L{<error text}} 1067 -- optional CHOICE 1068 T(c5)L{ 1069 -- CHOICE TLV goes here 1070 T(c<choice taken>)L{<value of CHOICE taken>} 1071 } 1072 -- extensions 1073 [...] 1074 }} 1075 107610.3 TLV encoding of the change password requests and responses 1077 1078 -- Req-change-pw 1079 -- choice tag 1080 T(c1)L{ 1081 T(uSEQUENCE)L{ 1082 -- old password 1083 T(c0)L{T(uUTF8String)L{<password string>}} 1084 -- new password (optional; if missing server must generate it) 1085 [T(c1)L{T(uUTF8String)L{<password string>}}] 1086 -- extensions 1087 [...] 1088 } 1089 } 1090 1091 -- Rep-change-pw 1092 -- choice tag 1093 T(c1)L{ 1094 T(uSEQUENCE)L{ 1095 -- optional informational text 1096 [T(c0)L{T(uUTF8String)L{<text>}}] 1097 -- new password (optional; see section 6) 1098 [T(c1)L{T(uUTF8String)L{<new password>}}] 1099 -- extensions 1100 1101Trostle et. al. [Page 19] 1102 1103DRAFT Kerberos Set/Change Password v2 Expires November 2003 1104 1105 [...] 1106 } 1107 } 1108 1109 -- Err-change-pw 1110 -- choice tag 1111 T(c1)L{ 1112 T(uSEQUENCE)L{ 1113 -- optional help text 1114 [T(c0)L{T(uUTF8String)L{<text>}}] 1115 -- error code 1116 T(c1)L{T(uENUM)L{<error code>}}] 1117 -- extensions 1118 [...] 1119 } 1120 } 1121 112210.4 TLV encoding of Change Keys requests and responses 1123 1124 -- Req-set-keys 1125 -- choice tag 1126 T(c1)L{ 1127 T(uSEQUENCE)L{ 1128 -- new key enctypes 1129 T(c0)L{T(uSEQUENCE)L{ 1130 T(uINTEGER)L{<etype integer>}, 1131 ... 1132 }} 1133 -- optional entropy 1134 [T(c1)L{T(uOCTET STRING)L{<entropy>}}] 1135 -- extensions 1136 [...] 1137 } 1138 } 1139 1140 -- Rep-set-keys 1141 -- choice tag 1142 T(c1)L{ 1143 T(uSEQUENCE)L{ 1144 -- optional informational text 1145 [T(c0)L{T(uUTF8String)L{<text>}}] 1146 -- new kvno 1147 T(c1)L{T(uINTEGER)L{<new kvno>}} 1148 -- new keys 1149 T(c2)L{T(uSEQUENCE)L{ 1150 -- first key 1151 T(uSEQUENCE)L{ 1152 T(uINTEGER)L{<etype>} 1153 T(uOCTET STRING)L{<key>} 1154 -- extensions to Key 1155 [...] 1156 } 1157 -- additional keys, if any 1158 1159Trostle et. al. [Page 20] 1160 1161DRAFT Kerberos Set/Change Password v2 Expires November 2003 1162 1163 ... 1164 }} 1165 -- optional aliases 1166 [T(c3)L{T(uSEQUENCE)L{ 1167 -- first alias 1168 T(uSEQUENCE)L{ 1169 -- principal name 1170 T(uSEQUENCE)L{ 1171 T(uUTF8String)L{<component1>}, 1172 -- components 2..N, if any 1173 ... 1174 } 1175 T(uUTF8String)L{<realm name>} 1176 -- extensions 1177 [...] 1178 } 1179 -- additional aliases, if any 1180 ... 1181 }}] 1182 -- extensions 1183 [...] 1184 } 1185 } 1186 1187 -- Err-set-keys 1188 -- choice tag 1189 T(c1)L{ 1190 T(uSEQUENCE)L{ 1191 -- optional help text 1192 [T(c0)L{T(uUTF8String)L{<text>}}] 1193 -- KDC supported enctypes 1194 [T(c1)L{T(uSEQUENCE)L{ 1195 T(uINTEGER)L{<etype integer>}, 1196 ... 1197 }}] 1198 -- error code 1199 T(c2)L{T(uENUM)L{<error code>}}] 1200 -- extensions 1201 [...] 1202 } 1203 } 1204 120511 Acknowledgements 1206 1207 The authors would like to thank Sam Hartman, Paul W. Nelson and 1208 Marcus Watts for their assistance. 1209 1210 The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony 1211 Andrea, Paul W. Nelson, Marcus Watts and other participants from the 1212 IETF Kerberos Working Group for their input to the document. 1213 121412 References 1215 1216 1217Trostle et. al. [Page 21] 1218 1219DRAFT Kerberos Set/Change Password v2 Expires November 2003 1220 122112.1 Normative References 1222 1223 [RFC2026] 1224 S. Bradner, RFC2026: "The Internet Standard Process - Revision 1225 3," October 1996, Obsoletes - RFC 1602, Status: Best Current 1226 Practice. 1227 1228 [RFC2119] 1229 S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to 1230 Indicate Requirement Levels," March 1997, Status: Best Current 1231 Practice. 1232 1233 [X680] 1234 Abstract Syntax Notation One (ASN.1): Specification of Basic 1235 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC 1236 International Standard 8824-1:1998. 1237 http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf 1238 1239 [X690] 1240 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), 1241 Canonical Encoding Rules (CER) and Distinguished Encoding Rules 1242 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International 1243 Standard 8825-1:1998. 1244 http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf 1245 1246 [RFC1510] 1247 J. Kohl and B. C. Neuman, RFC1510: "The Kerberos Network 1248 Authentication Service (v5)," September 1993, Status: Proposed 1249 Standard. 1250 1251 [clarifications] 1252 RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg- 1253 kerberos-clarifications. 1254 1255 [k5stringprep] 1256 RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg- 1257 utf8-profile. 1258 1259 [RFC3066] 1260 H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of 1261 Languages," January 2001, Obsoletes RFC1766, Status: Best Current 1262 Practice. 1263 1264 [KPASSWDv1] 1265 (Reference needed!) 1266 126712.1 Informative References 1268 1269 [RFC3244] 1270 M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000 1271 Kerberos Change Password and Set Password Protocols," February 1272 2002, Status: Informational. 1273 1274 1275Trostle et. al. [Page 22] 1276 1277DRAFT Kerberos Set/Change Password v2 Expires November 2003 1278 127913 Authors' Addresses 1280 1281 Jonathan Trostle 1282 Cisco Systems 1283 170 W. Tasman Dr. 1284 San Jose, CA 95134 1285 Email: jtrostle@cisco.com 1286 1287 Mike Swift 1288 University of Washington 1289 Seattle, WA 1290 Email: mikesw@cs.washington.edu 1291 1292 John Brezak 1293 Microsoft 1294 1 Microsoft Way 1295 Redmond, WA 98052 1296 Email: jbrezak@microsoft.com 1297 1298 Bill Gossman 1299 Cisco Systems 1300 500 108th Ave. NE, Suite 500 1301 Bellevue, WA 98004 1302 Email: bgossman@cisco.com 1303 1304 Nicolas Williams 1305 Sun Microsystems 1306 5300 Riata Trace Ct 1307 Austin, TX 78727 1308 Email: nicolas.williams@sun.com 1309 131014 Notes to the RFC Editor 1311 1312 This document has two KRB WG drafts as normative references and 1313 cannot progress until those drafts progress, but no other draft 1314 depends on this one. 1315 1316Full Copyright Statement 1317 1318 Copyright (C) The Internet Society (2003). All Rights Reserved. 1319 1320 This document and translations of it may be copied and furnished to 1321 others, and derivative works that comment on or otherwise explain it 1322 or assist in its implementation may be prepared, copied, published 1323 and distributed, in whole or in part, without restriction of any 1324 kind, provided that the above copyright notice and this paragraph are 1325 included on all such copies and derivative works. However, this 1326 document itself may not be modified in any way, such as by removing 1327 the copyright notice or references to the Internet Society or other 1328 Internet organizations, except as needed for the purpose of 1329 developing Internet standards in which case the procedures for 1330 copyrights defined in the Internet Standards process must be 1331 followed, or as required to translate it into languages other than 1332 1333Trostle et. al. [Page 23] 1334 1335DRAFT Kerberos Set/Change Password v2 Expires November 2003 1336 1337 English. 1338 1339 The limited permissions granted above are perpetual and will not be 1340 revoked by the Internet Society or its successors or assigns. 1341 1342 This document and the information contained herein is provided on an 1343 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1344 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1345 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1346 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1347 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1348 1349Acknowledgement 1350 1351 Funding for the RFC Editor function is currently provided by the 1352 Internet Society. 1353