7 Network Working Group M. Horowitz
8 <draft-ietf-cat-kerb-chg-password-00.txt> Cygnus Solutions
9 Internet-Draft March, 1997
12 Kerberos Change Password Protocol
16 This document is an Internet-Draft. Internet-Drafts are working
17 documents of the Internet Engineering Task Force (IETF), its areas,
18 and its working groups. Note that other groups may also distribute
19 working documents as Internet-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 To learn the current status of any Internet-Draft, please check the
27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
28 Directories on ds.internic.net (US East Coast), nic.nordu.net
29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
32 Distribution of this memo is unlimited. Please send comments to the
33 <cat-ietf@mit.edu> mailing list.
37 The Kerberos V5 protocol [RFC1510] does not describe any mechanism
38 for users to change their own passwords. In order to promote
39 interoperability between workstations, personal computers, terminal
40 servers, routers, and KDC's from multiple vendors, a common password
41 changing protocol is required.
47 When a user wishes to change his own password, or is required to by
48 local policy, a simple request of a password changing service is
49 necessary. This service must be implemented on at least one host for
50 each Kerberos realm, probably on one of the kdc's for that realm.
51 The service must accept requests on UDP port 464 (kpasswd), and may
52 accept requests on TCP port 464 as well.
54 The protocol itself consists of a single request message followed by
55 a single reply message. For UDP transport, each message must be
56 fully contained in a single UDP packet.
67 Internet Draft Kerberos Change Password Protocol March, 1997
73 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
74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
75 | message length | protocol version number |
76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
77 | AP_REQ length | AP-REQ data /
78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
82 message length (16 bits)
83 Contains the length of the message, including this field, in bytes
85 protocol version number (16 bits)
86 Contains the hex constant 0x0001 (big-endian integer)
87 AP-REQ length (16 bits)
88 length (big-endian integer) of AP-REQ data, in bytes.
89 AP-REQ data, as described in RFC1510 (variable length)
90 This AP-REQ must be for the service principal
91 kadmin/changepw@REALM, where REALM is the REALM of the user who
92 wishes to change his password. The Ticket in the AP-REQ must be
93 derived from an AS request (thus having the INITIAL flag set), and
94 must include a subkey in the Authenticator.
95 KRB-PRIV message, as described in RFC1510 (variable length)
96 This KRB-PRIV message must be generated using the subkey in the
97 Authenticator in the AP-REQ data. The user-data component of the
98 message must consist of the user's new password.
100 The server must verify the AP-REQ message, decrypt the new password,
101 perform any local policy checks (such as password quality, history,
102 authorization, etc.) required, then set the password to the new value
105 The principal whose password is to be changed is the principal which
106 authenticated to the password changing service. This protocol does
107 not address administrators who want to change passwords of principal
114 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
115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
116 | message length | protocol version number |
117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
118 | AP_REP length | AP-REP data /
119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
120 / KRB-PRIV or KRB-ERROR message /
121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
123 message length (16 bits)
129 Internet Draft Kerberos Change Password Protocol March, 1997
132 Contains the length of the message, including this field, in bytes
133 (big-endian integer),
134 protocol version number (16 bits)
135 Contains the hex constant 0x0001 (big-endian integer)
136 AP-REP length (16 bits)
137 length of AP-REP data, in bytes. If the the length is zero, then
138 the last field will contain a KRB-ERROR message instead of a KRB-
140 AP-REP data, as described in RFC1510 (variable length)
141 The AP-REP corresponding to the AP-REQ in the request packet.
142 KRB-PRIV or KRB-ERROR message, as described in RFC1510 (variable
144 If the AP-REP length is zero, then this field contains a KRB-ERROR
145 message. Otherwise, it contains a KRB-PRIV message. This KRB-
146 PRIV message must be generated using the subkey in the
147 Authenticator in the AP-REQ data.
149 The user-data component of the KRB-PRIV message, or e-data
150 component of the KRB-ERROR message, must consist of the following
154 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
155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
156 | result code | result string /
157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
159 result code (16 bits)
160 The result code must have one of the following values (big-
162 0x0000 if the request succeeds. (This value is not permitted
163 in a KRB-ERROR message.)
164 0x0001 if the request fails due to being malformed
165 0x0002 if the request fails due to a "hard" error processing
166 the request (for example, there is a resource or other
167 problem causing the request to fail)
168 0x0003 if the request fails due to an error in authentication
170 0x0004 if the request fails due to a "soft" error processing
171 the request (for example, some policy or other similar
172 consideration is causing the request to be rejected).
173 0xFFFF if the request fails for some other reason.
174 Although only four non-zero result codes are specified here,
175 the client should accept any non-zero result code as indicating
177 result string (variable length)
178 This field should contain information which the server thinks
179 might be useful to the user. No particular format is mandated,
180 and the field may be omitted if the server does not wish to
181 include it. This field is analogous to the string which
182 follows the numeric code in SMTP, FTP, and similar protocols.
191 Internet Draft Kerberos Change Password Protocol March, 1997
194 Security Considerations
196 This document deals with changing passwords for Kerberos. Because
197 Kerberos is used for authentication and key distribution, it is
198 important that this protocol use the highest level of security
199 services available to a particular installation. Mutual
200 authentication is performed, so that the server knows the request is
201 valid, and the client knows that the request has been received and
202 processed by the server.
204 There are also security issues relating to dropped, stolen, or
205 modified messages. An attacker (or simply a lossy network) could
206 cause either the request or reply to be dropped, or substitute a KRB-
207 ERROR message in the reply.
209 If a reply is dropped, it is reasonable for the client to construct a
210 new authenticator, re-encrypt the request, and retransmit. If the
211 request was lost, the server will treat this as a valid request, and
212 all should work normally. If the reply was lost, then the server
213 should take care to notice that the request was a duplicate of the
214 prior request, and indicate success without actually changing the
215 password or any other information (such as modification timestamps).
217 If a success reply was replaced with an error reply, then one would
218 expect that the user would attempt the operation again. Again, the
219 server should recognize the request as a duplicate and indicate
220 success without changing the password. If the user is required to
221 provide the old password again, but the password was actually changed
222 successfully, then some user confusion could result. This is,
223 unfortunately, impossible to prevent.
228 [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
229 Authentication Service (V5)", RFC 1510, September 1993.
236 955 Massachusetts Avenue
239 Phone: +1 617 354 7688
240 Email: marc@cygnus.com