2 CAT Working Group Mike Swift
3 draft-trostle-win2k-cat-kerberos-set-passwd-00.txt Microsoft
4 February 2000 Jonathan Trostle
5 Category: Informational Cisco Systems
9 Extending Change Password for Setting Kerberos Passwords
12 0. Status Of This Memo
14 This document is an Internet-Draft and is in full conformance with
15 all provisions of Section 10 of RFC2026.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as
22 Internet-Drafts are draft documents valid for a maximum of six
23 months and may be updated, replaced, or obsoleted by other
24 documents at any time. It is inappropriate to use Internet-
25 Drafts as reference material or to cite them other than as
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 Comments and suggestions on this document are encouraged. Comments
35 on this document should be sent to the CAT working group discussion
37 ietf-cat-wg@stanford.edu
41 The Kerberos [1] change password protocol [2], does not allow for
42 an administrator to set a password for a new user. This functionality
43 is useful in some environments, and this proposal extends [2] to
44 allow password setting. The changes are: adding new fields to the
45 request message to indicate the principal which is having its
46 password set, not requiring the initial flag in the service ticket,
47 using a new protocol version number, and adding three new result
52 The service must accept requests on UDP port 464 and TCP port 464 as
53 well. The protocol consists of a single request message followed by
54 a single reply message. For UDP transport, each message must be fully
55 contained in a single UDP packet.
57 For TCP transport, there is a 4 octet header in network byte order
58 precedes the message and specifies the length of the message. This
60 requirement is consistent with the TCP transport header in 1510bis.
65 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
66 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
67 | message length | protocol version number |
68 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
69 | AP_REQ length | AP_REQ data /
70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
74 All 16 bit fields are in big-endian order.
76 message length field: contains the number of bytes in the message
79 protocol version number: contains the hex constant 0xff80 (big-endian
82 AP-REQ length: length of AP-REQ data, in bytes. If the length is zero,
83 then the last field contains a KRB-ERROR message instead of a KRB-PRIV
86 AP-REQ data: (see [1]) The AP-REQ message must be for the service
87 principal kadmin/changepw@REALM, where REALM is the REALM of the user
88 who wishes to change/set his password. The ticket in the AP-REQ must
89 must include a subkey in the Authenticator. To enable setting of
90 passwords, it is not required that the initial flag be set in the
91 Kerberos service ticket.
93 KRB-PRIV message (see [1]) This KRB-PRIV message must be generated
94 using the subkey from the authenticator in the AP-REQ data.
96 The user-data component of the message consists of the following ASN.1
97 structure encoded as an OCTET STRING:
99 ChangePasswdData ::= SEQUENCE {
100 newpasswd[0] OCTET STRING,
101 targname[2] PrincipalName OPTIONAL,
102 targrealm[3] Realm OPTIONAL
105 The server must verify the AP-REQ message, check whether the client
106 principal in the ticket is authorized to set/change the password
107 (either for that principal, or for the principal in the targname
108 field if present), and decrypt the new password. The server also
109 checks whether the initial flag is required for this request,
110 replying with status 0x0007 if it is not set and should be. An
111 authorization failure is cause to respond with status 0x0005. For
112 forward compatibility, the server should be prepared to ignore fields
113 after targrealm in the structure that it does not understand.
115 The newpasswd field contains the cleartext password, and the server
116 should apply any local policy checks including password policy checks.
117 The server then generates the appropriate keytypes from the password
119 and stores them in the KDC database. If all goes well, status 0x0000
120 is returned to the client in the reply message (see below).
125 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
126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
127 | message length | protocol version number |
128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
129 | AP_REP length | AP-REP data /
130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
135 All 16 bit fields are in big-endian order.
137 message length field: contains the number of bytes in the message
138 including this field.
140 protocol version number: contains the hex constant 0x0001 (big-endian
141 integer). (The reply message has the same format as in [2]).
143 AP-REP length: length of AP-REP data, in bytes. If the length is zero,
144 then the last field contains a KRB-ERROR message instead of a KRB-PRIV
147 AP-REP data: the AP-REP is the response to the AP-REQ in the request
150 KRB-PRIV from [2]: This KRB-PRIV message must be generated using the
151 subkey in the authenticator in the AP-REQ data.
153 The server will respond with a KRB-PRIV message unless it cannot
154 decode the client AP-REQ or KRB-PRIV message, in which case it will
155 respond with a KRB-ERROR message. NOTE: Unlike change password version
156 1, the KRB-ERROR message will be sent back without any encapsulation.
158 The user-data component of the KRB-PRIV message, or e-data component
159 of the KRB-ERROR message, must consist of the following data.
162 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
163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
164 | result code | result string /
165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
167 result code (16 bits) (result codes 0-4 are from [2]):
168 The result code must have one of the following values (big-
170 KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not
171 allowed in a KRB-ERROR message)
172 KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed
173 KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in
174 processing the request (for example,
175 there is a resource or other problem
176 causing the request to fail)
178 KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in
179 authentication processing
180 KRB5_KPASSWD_SOFTERROR 4 request fails due to a "soft" error
181 in processing the request
182 KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
183 KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported
184 KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
185 0xFFFF if the request fails for some other reason.
186 Although only a few non-zero result codes are specified here,
187 the client should accept any non-zero result code as indicating
189 result string - from [2]:
190 This field should contain information which the server thinks
191 might be useful to the user, such as feedback about policy
192 failures. The string must be encoded in UTF-8. It may be
193 omitted if the server does not wish to include it. If it is
194 present, the client should display the string to the user.
195 This field is analogous to the string which follows the numeric
196 code in SMTP, FTP, and similar protocols.
200 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
201 Service (V5). Request for Comments 1510.
203 [2] M. Horowitz. Kerberos Change Password Protocol.
204 ftp://ds.internic.net/internet-drafts/
205 draft-ietf-cat-kerb-chg-password-02.txt
209 This draft expires in August 2000.
211 5. Authors' Addresses
217 Email: jtrostle@cisco.com
227 jbrezak@microsoft.com