Network Working Group Jonathan Trostle INTERNET-DRAFT Cisco Systems Category: Standards Track Mike Swift University of WA John Brezak Microsoft Bill Gossman Cisco Systems Kerberos Set/Change Password: Version 2 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [6]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This draft expires on December 31st, 2001. Please send comments to the authors. 1. Abstract This proposal specifies a Kerberos (RFC 1510 [3]) change/set password protocol and a Kerberos change/set key protocol. The protocol consists of a single request and reply message. The request message includes both AP-REQ and KRB-PRIV submessages; the new password is contained in the KRB-PRIV submessage which is encrypted in the subsession key from the AP-REQ. The original Kerberos change password protocol did not allow for an administrator to set a password for a new user. This functionality is useful in some environments, and this proposal allows password setting as well as password changing. The protocol includes fields in the request message to indicate the principal which is having its password set. We also extend the set/change protocol to allow a client to send a sequence of keys to Trostle, Swift, Brezak, Gossman [Page 1] INTERNET DRAFT June 2001 Expires December 2001 the KDC instead of a cleartext password. If in the cleartext password case, the cleartext password fails to satisfy password policy, the server should use the result code KRB5_KPASSWD_POLICY_REJECT. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [7]. 3. Definitions from RFC 1510 We include some of the relevant ASN.1 definitions from RFC 1510 in this section. Realm ::= GeneralString PrincipalName ::= SEQUENCE { name-type[0] INTEGER, name-string[1] SEQUENCE OF GeneralString } KerberosTime ::= GeneralizedTime -- Specifying UTC time zone (Z) HostAddress ::= SEQUENCE { addr-type[0] INTEGER, address[1] OCTET STRING } EncryptedData ::= SEQUENCE { etype[0] INTEGER, -- EncryptionType kvno[1] INTEGER OPTIONAL, cipher[2] OCTET STRING -- ciphertext } EncryptionKey ::= SEQUENCE { keytype[0] INTEGER, keyvalue[1] OCTET STRING } Checksum ::= SEQUENCE { cksumtype[0] INTEGER, checksum[1] OCTET STRING } AP-REQ ::= [APPLICATION 14] SEQUENCE { pvno [0] INTEGER, -- indicates Version 5 msg-type [1] INTEGER, -- indicates KRB_AP_REQ ap-options[2] APOptions, ticket[3] Ticket, authenticator[4] EncryptedData } Trostle, Swift, Brezak, Gossman [Page 2] INTERNET DRAFT June 2001 Expires December 2001 APOptions ::= BIT STRING { reserved (0), use-session-key (1), mutual-required (2) } Ticket ::= [APPLICATION 1] SEQUENCE { tkt-vno [0] INTEGER, -- indicates Version 5 realm [1] Realm, sname [2] PrincipalName, enc-part [3] EncryptedData } -- Encrypted part of ticket EncTicketPart ::= [APPLICATION 3] SEQUENCE { flags[0] TicketFlags, key[1] EncryptionKey, crealm[2] Realm, cname[3] PrincipalName, transited[4] TransitedEncoding, authtime[5] KerberosTime, starttime[6] KerberosTime OPTIONAL, endtime[7] KerberosTime, renew-till[8] KerberosTime OPTIONAL, caddr[9] HostAddresses OPTIONAL, authorization-data[10] AuthorizationData OPTIONAL } -- Unencrypted authenticator Authenticator ::= [APPLICATION 2] SEQUENCE { authenticator-vno[0] INTEGER, crealm[1] Realm, cname[2] PrincipalName, cksum[3] Checksum OPTIONAL, cusec[4] INTEGER, ctime[5] KerberosTime, subkey[6] EncryptionKey OPTIONAL, seq-number[7] INTEGER OPTIONAL, authorization-data[8] AuthorizationData OPTIONAL } AP-REP ::= [APPLICATION 15] SEQUENCE { pvno [0] INTEGER, -- represents Kerberos V5 msg-type [1] INTEGER, -- represents KRB_AP_REP enc-part [2] EncryptedData } EncAPRepPart ::= [APPLICATION 27] SEQUENCE { ctime [0] KerberosTime, cusec [1] INTEGER, subkey [2] EncryptionKey OPTIONAL, seq-number [3] INTEGER OPTIONAL Trostle, Swift, Brezak, Gossman [Page 3] INTERNET DRAFT June 2001 Expires December 2001 } Here is the syntax of the KRB-ERROR message: KRB-ERROR ::= [APPLICATION 30] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, ctime[2] KerberosTime OPTIONAL, cusec[3] INTEGER OPTIONAL, stime[4] KerberosTime, susec[5] INTEGER, error-code[6] INTEGER, crealm[7] Realm OPTIONAL, cname[8] PrincipalName OPTIONAL, realm[9] Realm, -- Correct realm sname[10] PrincipalName, -- Correct name e-text[11] GeneralString OPTIONAL, e-data[12] OCTET STRING OPTIONAL } The KRB-PRIV message is used to send the request and reply data: KRB-PRIV ::= [APPLICATION 21] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, enc-part[3] EncryptedData } EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { user-data[0] OCTET STRING, timestamp[1] KerberosTime OPTIONAL, usec[2] INTEGER OPTIONAL, seq-number[3] INTEGER OPTIONAL, s-address[4] HostAddress, -- sender's addr r-address[5] HostAddress OPTIONAL -- recip's addr } 4. The Protocol The service SHOULD accept requests on UDP port 464 and TCP port 464 as well. Use of other ports can significantly increase the complexity and size of IPSEC policy rulesets in organizations that have IPSEC capable nodes. The protocol consists of a single request message followed by a single reply message. For UDP transport, each message must be fully contained in a single UDP packet. For TCP transport, there is a 4 octet header in network byte order that precedes the message and specifies the length of the message. This requirement is consistent with the TCP transport header in Trostle, Swift, Brezak, Gossman [Page 4] INTERNET DRAFT June 2001 Expires December 2001 1510bis. Request Message 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message length | protocol version number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP-REQ length | AP-REQ data / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / KRB-PRIV message / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All 16 bit fields are in network byte order. message length field: contains the number of bytes in the message including this field. protocol version number: contains the hex constant 0x0002 (network byte order). AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, then the last field contains a KRB-ERROR message instead of a KRB-PRIV message. AP-REQ data: (see [3]) For a change password/key request, the AP-REQ message service ticket sname, srealm principal identifier is kadmin/changepw@REALM where REALM is the realm of the change password service. The same applies to a set password/key request except the principal identifier is kadmin/setpw@REALM. The authenticator in the AP-REQ MUST contain a subsession key (which will be used to encrypt the KRB-PRIV user data field - see below). The KDC may have stronger pseudorandom generating capability then the clients; thus, the client SHOULD use the session key as an input (along with additional locally pseudorandom generated bits) into the generation of the subsession key. To enable setting of passwords/keys, it is not required that the initial flag be set in the Kerberos service ticket. The initial flag is required for change requests, but not for set requests. We have the following definitions: old passwd initial flag target principal can be in request? required? distinct from authenticating principal? change password: yes yes no set password: no policy (*) yes set key: no policy (*) yes change key: no yes no Trostle, Swift, Brezak, Gossman [Page 5] INTERNET DRAFT June 2001 Expires December 2001 policy (*): implementations SHOULD allow administrators to set the initial flag required for set requests policy to either yes or no. Clients MUST be able to retry set requests that fail due to error 7 (initial flag required) with an initial ticket. Clients SHOULD NOT cache service tickets targetted at kadmin/changepw. KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted using the subsession key from the authenticator in the AP-REQ. The authenticator MUST contain a subsession key. The timestamp and usec fields of the KRB-PRIV message MUST be present, and the data values MUST be copies of the same data values from the authenticator. The recipient should ignore the sender address field in the KRB-PRIV message. The user-data component of the message contains the DER encoding of the ChangePasswdData ASN.1 type described below: ChangePasswdData ::= SEQUENCE { passwds [0] PasswordSequence OPTIONAL, keys [1] KeySequences OPTIONAL, -- exactly one of the above two will be -- present, else KRB5_KPASSWD_MALFORMED -- error will be returned by the server. targname[2] PrincipalName OPTIONAL, -- only present in set password/key: the -- principal which will have its password -- or keys set. Not present in a set request -- if the client principal from the ticket is -- the principal having its passwords or keys -- set. targrealm[3] Realm OPTIONAL, -- only present in set password/key: the realm -- for the principal which will have its -- password or keys set. Not present in a set -- request if the client principal from the -- ticket is the principal having its -- passwords or keys set. flags[4] RequestFlags OPTIONAL -- 32 bit string } KeySequences ::= SEQUENCE (SIZE (1..MAX)) OF KeySequence KeySequence ::= SEQUENCE { key[0] EncryptionKey, salt[1] OCTET STRING OPTIONAL, -- depends on enc type, not currently used salt-type[2] INTEGER OPTIONAL -- depends on enc type, not currently used } PasswordSequence ::= SEQUENCE { newpasswd[0] OCTET STRING, oldpasswd[1] OCTET STRING OPTIONAL Trostle, Swift, Brezak, Gossman [Page 6] INTERNET DRAFT June 2001 Expires December 2001 -- oldpasswd always present for change -- password but not present for set -- password, set key, or change key -- NOTE: the passwords are UTF8 strings. } RequestFlags ::= BIT STRING (SIZE (32..MAX)) -- reserved(0) -- request-srv-gen-keys(1) -- only in change/set keys -- if the client desires -- server to contribute to -- keys; -- server will return keys The server must verify the AP-REQ message, check whether the client principal in the ticket is authorized to set/change the password/keys (either for that principal, or for the principal in the targname field if present), and decrypt the new password/keys. The server also checks whether the initial flag is required for this request, replying with status 0x0007 if it is not set and should be. An authorization failure is cause to respond with status 0x0005. For forward compatibility, the server should be prepared to ignore fields after targrealm in the structure that it does not understand. If the passwds field is present, it contains the new cleartext password (with the old cleartext password for a change password operation). Otherwise the keys field is present, and it contains a sequence of encryption keys. In the cleartext password case, if the old password is sent in the request, the request MUST be a change password request. If the old password is not present in the request, the request MUST be a set password request. The server should apply policy checks to the old and new password after verifying that the old password is valid. The server can check validity by obtaining a key from the old password with a keytype that is present in the KDC database for the user and comparing the keys for equality. The server then generates the appropriate keytypes from the password and stores them in the KDC database. If all goes well, status 0x0000 is returned to the client in the reply message (see below). For a change password operation, the initial flag in the service ticket MUST be set. In the key sequence case, the sequence of keys is sent to the change or set password service (kadmin/changepw or kadmin/setpw respectively). For a principal that can act as a server, its preferred keytype should be sent as the first key in the sequence, but the KDC is not required to honor this preference. Application servers SHOULD use the key sequence option for changing/setting their keys. The change/set password services should check that all keys are in the proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise. Trostle, Swift, Brezak, Gossman [Page 7] INTERNET DRAFT June 2001 Expires December 2001 For change/set key, the request message may include the request flags bit string with the request-srv-gen-keys bit set. In this case, the client is requesting that the server add entropy to its keys in the KeySequences field. When using this option, the client SHOULD attempt to generate pseudorandom keys with as much entropy as possible in its request. The server will return the final key sequence in a KeySequences structure in the edata of the reply message. The server does not store any of the new keys at this point. The client MUST make a subsequent change/set key request without the request-srv- gen-keys bit; if the server returns KRB5_KPASSWD_SUCCESS for this second request, then the new keys have been written into the database. A conformant server MUST support this option. Reply Message 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message length | protocol version number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP-REP length | AP-REP data / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / KRB-PRIV message / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All 16 bit fields are in network byte order. message length field: contains the number of bytes in the message including this field. protocol version number: contains the hex constant 0x0002 (network byte order). (The reply message has the same format as in the original Kerberos change password protocol). AP-REP length: length of AP-REP data, in bytes. If the length is zero, then the last field contains a KRB-ERROR message instead of a KRB-PRIV message. An implementation should check this field to determine whether a KRB-ERROR message or KRB-PRIV message has been returned. AP-REP data: the AP-REP is the response to the AP-REQ in the request packet. The subkey MUST be present in the AP-REP message. KRB-PRIV message: This KRB-PRIV message must be encrypted using the subkey from the AP-REP message. The client should ignore the sender address (the server's address) in the KRB-PRIV message. Reflection attacks are prevented since the subkey is used to encrypt the user- data field of the KRB-PRIV message. The timestamp and usec fields of Trostle, Swift, Brezak, Gossman [Page 8] INTERNET DRAFT June 2001 Expires December 2001 the KRB-PRIV message MUST be present, and the data values MUST be copies of the same data values from the AP-REP message. The server will respond with a KRB-PRIV message unless it cannot validate the client AP-REQ or KRB-PRIV message, in which case it will respond with a KRB-ERROR message. The user-data component of the KRB-PRIV message, or e-data component of the KRB-ERROR message, must consist of the following data. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | result code | key version (only on success) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | result string length | result string / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | edata / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ result code (16 bits) (result codes 0-4 are the same as in the original Kerberos change password protocol): The result code must have one of the following values (network byte order): KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not allowed in a KRB-ERROR message) KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in processing the request (for example, there is a resource or other problem causing the request to fail) KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in authentication processing KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error in processing the request KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported KRB5_KPASSWD_INITIALFLAG_NEEDED 7 initial flag required Trostle, Swift, Brezak, Gossman [Page 9] INTERNET DRAFT June 2001 Expires December 2001 KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy; the result string should include a text message to be presented to the user. KRB5_KPASSWD_WRONG_SRV 9 policy failure: the client sent change/set key and should have sent change/set passwd, or vice-versa. KRB5_KPASSWD_BAD_PRINCIPAL 10 target principal does not exist (only in response to a set password or set key request). KRB5_KPASSWD_ETYPE_NOSUPP 11 the request contains a key sequence containing at least one etype that is not supported by the KDC. The response edata contains an ASN.1 DER encoded PKERB-ETYPE-INFO type that specifies the etypes that the KDC supports: KERB-ETYPE-INFO-ENTRY :: = SEQUENCE { encryption-type[0] INTEGER, salt[1] OCTET STRING OPTIONAL -- not sent, client -- may ignore if -- sent } PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY The client should retry the request using only etypes (keytypes) that are contained within the PKERB-ETYPE-INFO structure in the previous response. KRB5_KPASSWD_ETYPE_SRVGENKEYS 12 See the following paragraph. The KRB5_KPASSWD_ETYPE_SRVGENKEYS result code is returned when the request has the request-srv-gen-keys flag set and the server is returning the KeySequences structure defined above in the edata field of the reply. The server returns one key sequence structure of the same keytype for each key sequence structure in the client request, unless it does not support one of the keytypes (or etypes). In that case, it returns error KRB5_KPASSWD_ETYPE_NOSUPP as discussed above. The server MUST add keylength number of bits of entropy to each key, where Trostle, Swift, Brezak, Gossman [Page 10] INTERNET DRAFT June 2001 Expires December 2001 keylength is the number of actual key bits in the key (minus any parity or non-entropy contributing bits). The assumption here is that the client may have added insufficient entropy to the request keys. The server SHOULD use the client key from each KeySequence structure as input into the final keyvalue for the returned key. The client MUST make another request after receiving a reply with this status, since no keys have been written into the database. 0xFFFF is returned if the request fails for some other reason. The client must interpret any non-zero result code as a failure. key version (16 bits - optional): Present if and only if the result code is KRB5_KPASSWD_SUCCESS. This contains the key version of the new key(s). result string length (16 bits): Gives the length of the following result string field, in bytes. If the result string is not present, the length is zero. result string (optional): This field is a UTF-8 encoded string which can be displayed to the user. Specific reasons for a password set/change policy failure is one possible use for this string. edata (optional): Used to convey additional information as defined by the result code. 5. Acknowledgements The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Nicolas Williams, and other participants from the IETF Kerberos Working Group for their input to the document. 6. Security Considerations Password policies should be enforced to make sure that users do not pick passwords (for change password/key) that are vulnerable to brute force password guessing attacks. 7. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] J. Kohl, C. Neuman. The Kerberos Network Authentication Service (V5), Request for Comments 1510. Trostle, Swift, Brezak, Gossman [Page 11] INTERNET DRAFT June 2001 Expires December 2001 8. Expiration Date This draft expires on December 31st, 2001. 9. Authors' Addresses Jonathan Trostle Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 Email: jtrostle@cisco.com Mike Swift University of Washington Seattle, WA Email: mikesw@cs.washington.edu John Brezak Microsoft 1 Microsoft Way Redmond, WA 98052 Email: jbrezak@microsoft.com Bill Gossman Cisco Systems 500 108th Ave. NE, Suite 500 Bellevue, WA 98004 Email: bgossman@cisco.com 10. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Trostle, Swift, Brezak, Gossman [Page 12] INTERNET DRAFT June 2001 Expires December 2001 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Trostle, Swift, Brezak, Gossman [Page 13]