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