idnits 2.17.1 draft-ietf-krb-wg-kerberos-set-passwd-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 695. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2007) is 6254 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Expires: September 6, 2007 March 5, 2007 6 Kerberos Set/Change Key/Password Protocol Version 2 7 draft-ietf-krb-wg-kerberos-set-passwd-06.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 6, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document specifies an extensible protocol for setting keys and 41 changing the passwords of Kerberos V principals. 43 Table of Contents 45 1. Conventions used in this document . . . . . . . . . . . . 3 46 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. The Protocol . . . . . . . . . . . . . . . . . . . . . . . 5 48 3.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3.1.1. Protocol Framing . . . . . . . . . . . . . . . . . . . . . 5 50 3.2. Protocol Version Negotiation . . . . . . . . . . . . . . . 6 51 3.2.1. Protocol Major Version Negotiation . . . . . . . . . . . . 6 52 3.2.2. Protocol Minor Version Negotiation . . . . . . . . . . . . 7 53 3.3. Use of Kerberos V and Key Exchange . . . . . . . . . . . . 7 54 3.4. Use of ASN.1 . . . . . . . . . . . . . . . . . . . . . . . 8 55 3.5. Internationalization . . . . . . . . . . . . . . . . . . . 8 56 3.5.1. Normalization Forms for UTF-8 Strings . . . . . . . . . . 8 57 3.5.2. Language Negotiation . . . . . . . . . . . . . . . . . . . 8 58 3.6. Protocol Extensibility . . . . . . . . . . . . . . . . . . 9 59 3.7. Protocol Subsets . . . . . . . . . . . . . . . . . . . . . 9 60 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . 10 61 4.1. Password Quality Policies . . . . . . . . . . . . . . . . 10 62 4.1.1. Standard Password Quality Policies . . . . . . . . . . . . 11 63 4.2. PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 4.3. Operations . . . . . . . . . . . . . . . . . . . . . . . . 14 65 4.3.1. Null . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 4.3.2. Change Kerberos Password . . . . . . . . . . . . . . . . . 14 67 4.3.3. Set Kerberos Password . . . . . . . . . . . . . . . . . . 14 68 4.3.4. Set Kerberos Keys . . . . . . . . . . . . . . . . . . . . 14 69 4.3.5. Generate Kerberos Keys . . . . . . . . . . . . . . . . . . 15 70 4.3.6. Get New Keys . . . . . . . . . . . . . . . . . . . . . . . 15 71 4.3.7. Commit New Keys . . . . . . . . . . . . . . . . . . . . . 16 72 4.3.8. Get Password Quality Policy . . . . . . . . . . . . . . . 16 73 4.3.9. Get Principal Aliases . . . . . . . . . . . . . . . . . . 16 74 4.3.10. Get Realm's Supported Kerberos V Version and Features . . 16 75 4.3.11. Retrieve Principal's S2K Params and Preferred Params . . . 17 76 4.4. Principal Aliases . . . . . . . . . . . . . . . . . . . . 17 77 4.5. Kerberos V Feature Negotiation . . . . . . . . . . . . . . 17 78 5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . 18 79 6. Security Considerations . . . . . . . . . . . . . . . . . 19 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . 20 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 83 Author's Address . . . . . . . . . . . . . . . . . . . . . 21 84 Intellectual Property and Copyright Statements . . . . . . 22 86 1. Conventions used in this document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. Introduction 94 Up to this point Kerberos V has lacked a single, standard protocol 95 for changing passwords and keys. While several vendor-specific 96 protocols exist for changing Kerberos passwords/keys, none are 97 properly internationalized and all are incomplete in one respect or 98 another and none are sufficiently extensible to cope with new 99 features that may be added to Kerberos V at some future time. 101 This document defines a protocol that is somewhat backward-compatible 102 with the "kpasswd" protocol defined in [RFC3244] that uses more or 103 less the same protocol framing. 105 This new protocol is designed to be extensible and properly 106 internationalized. 108 3. The Protocol 110 The structure of the protocol is quite similar to that of typical RPC 111 protocols. Each transaction consists of a data structure specific to 112 an operation which is then wrapped in a data structure which is 113 general to all operations of the protocol. These data structures are 114 defined with the Abstract Syntax Notation 1 (ASN.1) [CCITT.X680.2002] 115 and they are encoded using the Distinguished Encoding Rules (DER) 116 [CCITT.X690.2002]. 118 All protocol data is wrapped KRB-PRIV messages, or, in some cases, a 119 KRB-ERROR, and framed in a header that is backwards compatible with 120 [RFC3244]. 122 3.1. Transports 124 The service supports only connection-oriented transports, 125 specifically TCP, and SHOULD accept requests on TCP port 464, the 126 same as in [RFC3244]. 128 3.1.1. Protocol Framing 130 Requests and responses are exchanged using the same framing as in 131 [RFC3244], but with the following differences: 133 o the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1) 135 o the 'AP-REQ length' field of the request can be set to 0x0, in 136 which case the 'AP-REQ' field of the request is excluded 138 o the 'KRB-PRIV' field of the request and reply is mutually 139 exclusive with the 'AP-REQ' field of the request 141 o the 'AP-REP length' field of the reply can be set to 0x0, in which 142 case the 'AP-REP' field of the reply is excluded 144 o all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can 145 be or has been accepted by the server 147 o any KRB-ERROR messages are framed and sent in the 'AP-REP' field 148 of the reply 150 The initial message from the client MUST carry an AP-REQ and the 151 response to any request bearing an AP-REQ MUST carry an AP-REP or 152 MUST be a KRB-ERROR. 154 Subsequent messages exchanged on the same TCP connection MAY involve 155 Kerberos V AP exchanges, but generally the client SHOULD NOT initiate 156 a new AP exchange except when it desires to authenticate as a 157 different principal, when the ticket last used for authentication 158 expires or when the server responds with an error indicating that the 159 client must re-authenticate. 161 3.2. Protocol Version Negotiation 163 There are several major versions of this protocol. Version 2 also 164 introduces a notion of protocol minor versions for use in negotiating 165 protocol extensions. As of this time only one minor version is 166 defined for major version 2: minor version 0, defined herein. 168 3.2.1. Protocol Major Version Negotiation 170 Version 2 clients that also support other versions, such as 0xff80, 171 as in [RFC3244], SHOULD attempt to use version 2 of the protocol 172 first. 174 Servers which do not support version 2 of this protocol typically 175 include their preferred version number in the reply and/or may 176 include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a 177 status code of KRB5_KPASSWD_MALFORMED. 179 Note that some [RFC3244] server implementations close the TCP 180 connection without returning any other response. Note also that 181 there is no integrity protection for the major version number in the 182 protocol framing or for any data in a KRB-ERROR. 184 As a result change password protocol major version negotiation is 185 subject to downgrade attacks. Therefore major version negotiation is 186 NOT RECOMMENDED. 188 Where the server indicates that it does not support version 2, the 189 client MAY, but SHOULD NOT, unless configured to do so, fall back on 190 another major version of this protocol. 192 Version 2 servers MAY respond to non-v2 requests using whatever 193 response is appropriate for the versions used by the clients, but if 194 a server does not do this or know how to do this then it MUST respond 195 with an error framed as in Section 3.1.1, using an AP-REP and KRB- 196 PRIV if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise 197 and using a ProtocolErrorCode value of unsupported-major-version. 199 It is expected that implementations of as yet unspecified future 200 major versions of this protocol will be required to support version 2 201 integrity protected error replies for properly indicating no support 202 for version 2 of the protocl. We also hope that no further major 203 versions of this protocol will be needed. 205 3.2.2. Protocol Minor Version Negotiation 207 Version 2 clients are free to use whatever protocol minor version and 208 message extensions are available to them in their initial messages to 209 version 2 servers, provided that the minor versions (other than 0) 210 have been defined through IETF documents. 212 Version 2 servers MUST answer with the highest protocol minor version 213 number supported by the server and the client. 215 Version 2 clients MUST use the protocol minor version used in a 216 server's reply for any subsequent messages in the same TCP session. 218 See Section 3.6 for further description of the protocol's 219 extensibility and its relation to protocol minor versions and the 220 negotiation thereof. 222 3.3. Use of Kerberos V and Key Exchange 224 This protocol makes use of messages defined in [RFC4120]. 225 Specifically, AP-REQ, AP-REP, KRB-ERROR and KRB-PRIV. 227 All operations are to be performed by the server on behalf of the 228 client principal. 230 Clients SHOULD use "kadmin/setpw" as the principal name of the server 231 for all requests except when changing the client principal's own 232 expired password, for which they should use "kadmin/changepw". The 233 "kadmin/changepw" service exists to allow KDCs to limit principals 234 with expired passwords to getting initial tickets to the password 235 changing service only and only for changing expired passwords. 237 Servers MUST limit clients that used the "kadmin/changepw" service 238 principal name to changing the password of the client principal. 240 The client MUST request mutual authentication and the client MUST 241 MUST request the use of sequence numbers. 243 Servers MAY force the use of INITIAL or fresh tickets for any 244 requests -- see Section 4.3. Traditionally users with expired 245 passwords are allowed only INITIAL tickets for the password changing 246 server, therefore clients MUST support the use of INITIAL tickets. 248 Servers MUST specify a sub-session key. 250 The encrypted part of KRB-PRIVs MUST be encrypted with the server's 251 sub-session key and key usage 20 (client->server) or 21 252 (server->client). 254 After each new AP exchange the client and server MUST destroy the 255 session keys, if any, resulting from the previous AP exchange. 257 3.4. Use of ASN.1 259 This protocol's messages are defined in ASN.1, using only features 260 from [CCITT.X680.2002]. All ASN.1 types defined herein are to be 261 encoded in DER [CCITT.X690.2002]. A complete ASN.1 module is given 262 in Section 5. 264 The DER encoding of the ASN.1 PDUs are exchanged wrapped in a KRB- 265 PRIV as described above and/or as e-data in KRB-ERROR messages. 267 3.5. Internationalization 269 This protocol's request PDU carries an optional field indicating the 270 languages spoken by the client user; the client SHOULD send its list 271 of spoken languages to the server (once per-TCP session). 273 The server SHOULD localize all strings intended for display to users 274 to a language in common with the languages spoken by the client user. 276 Strings for Kerberos principal and realm names used in this protocol 277 are be constrained as per [RFC4120]. 279 3.5.1. Normalization Forms for UTF-8 Strings 281 Because Kerberos V [RFC4120] restricts principal names, realm names 282 and passwords to IA5String, this protocol uses UTF8String with an 283 extensible constraint to IA5String. 285 Future versions of Kerberos may relax this constraint; if so then a 286 minor version of this protocol should relax this constraint 287 accordingly. 289 3.5.2. Language Negotiation 291 The server MUST pick a language from the client's input list or the 292 default language tag (see [RFC3066]) for text in its responses which 293 is meant for the user to read. 295 The server SHOULD use a language selection algorithm such that 296 consideration is first given to exact matches between the client's 297 spoken languages and the server's available locales, followed by 298 "fuzzy" matches where only the first sub-tags of the client's 299 language tag list are used for matching against the servers available 300 locales. 302 Servers MUST cache the optional language tag lists from prior 303 requests for use with subsequent requests that exclude the language 304 tag list. Clients MAY expect such server behaviour and send the 305 language tag lists only once per-TCP session. Clients SHOULD send 306 the server the language tag list at least once. 308 When the server has a message catalog for one of the client's spoken 309 languages the server SHOULD localize any text strings intended for 310 display to users. 312 3.6. Protocol Extensibility 314 The protocol is defined in ASN.1 and uses extensibility markers 315 throughout. As such, the module presented herein can be extended 316 within the framework of [CCITT.X680.2002]. 318 Typed holes are not used in this protocol as it is very simple and 319 does not require the ability to deal with abstract data types defined 320 in different layers. For this reason, the only way to extend this 321 protocol is by extending the ASN.1 module within the framework of the 322 IETF; all future extensions to this protocol have to be defined in 323 IETF documents unless otherwise specified in a future IETF revision 324 of this protocol. 326 A protocol minor version number is used to negotiate use of 327 extensions. See Section 3.2.2 for the minor version negotiation. 329 Servers SHOULD ignore unknown additions to the ASN.1 types, in 330 initial requests, where the syntax allows them, except for extensions 331 to the "Op-req" type, which MUST result in an error. 333 Servers MUST respond with an error (ProtocolErrorCode value of proto- 334 unsupported-operation) to clients that use operations unknown to the 335 server. 337 3.7. Protocol Subsets 339 The structure of the protocol is such that the ASN.1 syntaxes for the 340 various operations supported by the protocol are independent of the 341 each other. Client and server implementations MAY implement subsets 342 of the overall protocol by removing some alternatives to the Op-req, 343 Op-rep and Op-err CHOICEs from the ASN.1 module given in Section 5. 345 For example, it should be possible to have a password-change only 346 client that cannot set principal's keys - and vice versa. 348 4. Protocol Elements 350 The protocol as defined herein supports the following operations 351 relating to the management of Kerberos principal's passwords or keys: 353 o change password (or enctypes and string-to-key parameters) 355 o set password (administrative) 357 o set new keys 359 o generate new keys 361 o get new, un-committed keys 363 o commit new keys 365 o get password policy name and/or description of principal 367 o list aliases of a principal 369 o list enctypes and version of Kerberos V supported by realm 371 The operation for retrieving a list of aliases of a principal is 372 needed where KDCs implement aliasing of principal names and allows 373 clients to properly setup their key databases when principal aliasing 374 is in use. 376 Operations such as creation or deletion of principals are outside the 377 scope of this document, and should be performed via other means, such 378 as through directories or other Kerberos administration protocols. 380 The individual operations are described in Section 4.3. 382 4.1. Password Quality Policies 384 Servers may reject new user passwords for failing to meet password 385 quality policies. When this happens the server must be able to 386 communicate the policy to the user so that the user may select a 387 better password. 389 The protocol allows for two ways to do this: 391 o through error codes that identify specific password quality 392 policies known; 394 o through localized error strings. 396 The use of localized error strings allows servers to convey non- 397 standard password quality policies to users, but it requires server- 398 side message catalogs for localization and support for language 399 negotiation. The use of error codes only allows for standard 400 password quality policies that clients must be aware of a priori, 401 therefore use of error codes requires the distribution of new message 402 catalogs to clients whenever new error codes are added; this 403 simplifies servers at the expense of password quality extensibility. 405 When a server would reject a password due to its failing to meet a 406 standard password quality policy the the server MUST use the 407 appropriate error codes (see below) and the server SHOULD send a 408 localized error message to the user. 410 When a server would reject a password due to its failing to meet a 411 non-standard password quality policy (one not described herein) the 412 the server MUST send a localized error message to the user. 414 4.1.1. Standard Password Quality Policies 416 o pwq-too-soon 418 It is too soon for the principal to change its password or long- 419 term keys. 421 o pwq-history 423 The new password is one that the principal has used before or is 424 too similar to a password that it has used before. 426 o pwq-too-short 428 The new password is too short. 430 o pwq-dictionary-words 432 The new password is or contains words that are in the dictionary. 434 o pwq-prohibited-codepoints 436 The new password contains prohibited codepoints. 438 o pwq-need-more-char-classes 440 The new password does not have characters from enough character 441 classes (lower-case letters, upper-case letters, digits, 442 punctuation, etc...). 444 4.2. PDUs 446 The types "Request," "Response" and "Error-Response" are the ASN.1 447 module's PDUs. 449 The "Request" and "Response" PDUs are always to be sent wrapped in 450 KRB-PRIV messages, except for the "Error-Response" PDU which MUST be 451 sent as KRB-ERROR e-data (see Section 3.3) when AP exchanges fail, 452 otherwise it MUST be sent wrapped in a KRB-PRIV. 454 The ASN.1 syntax for the PDUs is given in Section 5. 456 Note that the first field of each PDU is the major version of the 457 protocol, defaulted to 2, meaning that it is never included in 458 version 2 exchanges. Similarly, the second field of each PDU is the 459 minor version, defaulted to 0. 461 The request, responses and error PDUs consist of an outer structure 462 ("Request," "Response" and "Error-Response") containing fields common 463 to all requests, responses and errors, respectively, and an inner 464 structure for fields that are specific to each operation's requests/ 465 responses. The inner structure is optional in the case of the Error- 466 Response PDU and need not be included when generic errors occur for 467 which there is a suitable ProtocolErrorCode. 469 Specifically, the outer Request structure has a field for passing a 470 client user's spoken (read) languages to the server. It also has two 471 optional fields for identifying the requested operation's target 472 principal's name and realm (if not sent then the server MUST use the 473 client's principal name and realm as the target). A boolean field 474 for indicating whether or not the request should be dry-run is also 475 included; dry-runs can be used to test server policies, and servers 476 MUST NOT modify any principals when processing dry-run requests. 478 The Response and Error PDUs' outer structures include a field 479 indicating the language that the server has chosen for localization 480 of text intended to be displayed to users; this field is defaulted to 481 "i-default". This language tag applies to all UTF8 strings in the 482 inner structure (Op-rep and Op-err) that are meant to be displayed to 483 users. 485 The protocol error codes are: 487 o proto-generic-error 489 An operation-specific error ocurred, see the inner Op-error. 491 o proto-format-error 493 The server failed to parse a message sent by the client. 495 o proto-unsupported-major-version 497 The server does not support the major version of this protocol 498 requested by the client. 500 o proto-unsupported-minor-version 502 The server does not support the minor version of this protocol 503 requested by the client. 505 o proto-unsupported-operation 507 The server does not support the operation requested by the client. 509 o proto-wrong-service-principal 511 Use kadmin/setpw for the server's principal name. 513 o proto-re-authentication-required 515 The server demands that the client re-authenticate through a new 516 AP exchange. 518 o proto-initial-ticket-required 520 Use of an INITIAL ticket is required for the requested operation. 522 o proto-client-and-target-realm-mismatch 524 The server requires that the client's principal name and the 525 target principal of the operation share the same realm name. 527 o proto-target-principal-unknown 529 The target of the client's operation is not a valid principal. 531 o proto-authorization-failed 532 The client principal is not authorized to perform the requested 533 operation. 535 o proto-fresh-ticket-required 537 The server would like the client to re-authenticate using a fresh 538 ticket. 540 4.3. Operations 542 This section describes the semantics of each operation request and 543 response defined in the ASN.1 module in Section 5. 545 4.3.1. Null 547 4.3.2. Change Kerberos Password 549 4.3.3. Set Kerberos Password 551 4.3.4. Set Kerberos Keys 552 4.3.5. Generate Kerberos Keys 554 4.3.6. Get New Keys 555 4.3.7. Commit New Keys 557 4.3.8. Get Password Quality Policy 559 4.3.9. Get Principal Aliases 561 4.3.10. Get Realm's Supported Kerberos V Version and Features 562 4.3.11. Retrieve Principal's S2K Params and Preferred Params 564 4.4. Principal Aliases 566 Applications that use Kerberos often have to derive acceptor 567 principal names from hostnames entered by users. Such hostnames may 568 be aliases, they may be fully qualified, partially qualified or not 569 qualified at all. Some implementations have resorted to deriving 570 principal names from such hostnames by utilizing the names services 571 to canonicalize the hostname first; such practices are not secure 572 unless the name service are secure, which often aren't. 574 One method for securely deriving principal names from hostnames is to 575 alias principals at the KDC such that the KDC will issue tickets for 576 principal names which are aliases of others. It is helpful for 577 principals to know what are their aliases as known by the KDCs. 579 Note that changing a principal's aliases is out of scope for this 580 protocol. 582 4.5. Kerberos V Feature Negotiation 584 Principals and realms' KDCs may need to know about additional 585 Kerberos V features and extensions that they each support. Several 586 operations (see above) provide a way for clients and servers to 587 exchange such infomration, in the form of lists of types supported 588 for the various typed holes used in Kerberos V. 590 5. ASN.1 Module 591 6. Security Considerations 593 Implementors and site administrators should note that the redundancy 594 of UTF-8 encodings of passwords varies by language. Password quality 595 policies SHOULD, therefore, take this into account when estimating 596 the amount of redundancy and entropy in a proposed new password. 598 Kerberos set/change password/key protocol major version negotiation 599 cannot be done securely; a downgrade attack is possible against 600 clients that attempt to negotiate the protocol major version to use 601 with a server. It is not clear at this time that the attacker would 602 gain much from such a downgrade attack other than denial of service 603 (DoS) by forcing the client to use a protocol version which does not 604 support some feature needed by the client (Kerberos V in general is 605 subject to a variety of DoS attacks anyways [RFC4120]). Clients 606 SHOULD NOT negotiate support for legacy major versions of this 607 protocol unless configured otherwise. 609 This protocol does not have Perfect Forward Security (PFS). As a 610 result, any passive network snooper watching password/key changing 611 operations who has stolen a principal's password or long-term keys 612 can find out what the new ones are. 614 7. References 616 7.1. Normative References 618 [CCITT.X680.2002] 619 International International Telephone and Telegraph 620 Consultative Committee, "Abstract Syntax Notation One 621 (ASN.1): Specification of basic notation", 622 CCITT Recommendation X.680, July 2002. 624 [CCITT.X690.2002] 625 International International Telephone and Telegraph 626 Consultative Committee, "ASN.1 encoding rules: 627 Specification of basic encoding Rules (BER), Canonical 628 encoding rules (CER) and Distinguished encoding rules 629 (DER)", CCITT Recommendation X.690, July 2002. 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, March 1997. 634 [RFC3066] Alvestrand, H., "Tags for the Identification of 635 Languages", RFC 3066, January 2001. 637 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 638 Kerberos Network Authentication Service (V5)", RFC 4120, 639 July 2005. 641 7.2. Informative References 643 [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows 644 2000 Kerberos Change Password and Set Password Protocols", 645 RFC 3244, February 2002. 647 Author's Address 649 Nicolas Williams 650 Sun Microsystems 651 5300 Riata Trace Ct 652 Austin, TX 78727 653 US 655 Email: Nicolas.Williams@sun.com 657 Full Copyright Statement 659 Copyright (C) The IETF Trust (2007). 661 This document is subject to the rights, licenses and restrictions 662 contained in BCP 78, and except as set forth therein, the authors 663 retain all their rights. 665 This document and the information contained herein are provided on an 666 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 667 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 668 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 669 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 670 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 671 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 673 Intellectual Property 675 The IETF takes no position regarding the validity or scope of any 676 Intellectual Property Rights or other rights that might be claimed to 677 pertain to the implementation or use of the technology described in 678 this document or the extent to which any license under such rights 679 might or might not be available; nor does it represent that it has 680 made any independent effort to identify any such rights. Information 681 on the procedures with respect to rights in RFC documents can be 682 found in BCP 78 and BCP 79. 684 Copies of IPR disclosures made to the IETF Secretariat and any 685 assurances of licenses to be made available, or the result of an 686 attempt made to obtain a general license or permission for the use of 687 such proprietary rights by implementers or users of this 688 specification can be obtained from the IETF on-line IPR repository at 689 http://www.ietf.org/ipr. 691 The IETF invites any interested party to bring to its attention any 692 copyrights, patents or patent applications, or other proprietary 693 rights that may cover technology that may be required to implement 694 this standard. Please address the information to the IETF at 695 ietf-ipr@ietf.org. 697 Acknowledgment 699 Funding for the RFC Editor function is provided by the IETF 700 Administrative Support Activity (IASA).