1
2
3
4
5Network Working Group                                        M. Horowitz
6<draft-ietf-cat-kerb-chg-password-02.txt>                Stonecast, Inc.
7Internet-Draft                                              August, 1998
8
9                   Kerberos Change Password Protocol
10
11Status of this Memo
12
13   This document is an Internet-Draft.  Internet-Drafts are working
14   documents of the Internet Engineering Task Force (IETF), its areas,
15   and its working groups.  Note that other groups may also distribute
16   working documents as Internet-Drafts.
17
18   Internet-Drafts are draft documents valid for a maximum of six months
19   and may be updated, replaced, or obsoleted by other documents at any
20   time.  It is inappropriate to use Internet-Drafts as reference
21   material or to cite them other than as ``work in progress.''
22
23   To learn the current status of any Internet-Draft, please check the
24   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
25   Directories on ftp.ietf.org (US East Coast), nic.nordu.net
26   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
27   Rim).
28
29   Distribution of this memo is unlimited.  Please send comments to the
30   <cat-ietf@mit.edu> mailing list.
31
32Abstract
33
34   The Kerberos V5 protocol [RFC1510] does not describe any mechanism
35   for users to change their own passwords.  In order to promote
36   interoperability between workstations, personal computers, terminal
37   servers, routers, and KDC's from multiple vendors, a common password
38   changing protocol is required.
39
40
41
42Overview
43
44   When a user wishes to change his own password, or is required to by
45   local policy, a simple request of a password changing service is
46   necessary.  This service must be implemented on at least one host for
47   each Kerberos realm, probably on one of the kdc's for that realm.
48   The service must accept requests on UDP port 464 (kpasswd), and may
49   accept requests on TCP port 464 as well.
50
51   The protocol itself consists of a single request message followed by
52   a single reply message.  For UDP transport, each message must be
53   fully contained in a single UDP packet.
54
55
56
57
58
59
60
61
62Horowitz                                                        [Page 1]
63
64Internet Draft      Kerberos Change Password Protocol       August, 1998
65
66
67Request Message
68
69       0                   1                   2                   3
70       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
71      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
72      |         message length        |    protocol version number    |
73      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
74      |          AP_REQ length        |         AP-REQ data           /
75      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
76      /                        KRB-PRIV message                       /
77      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
78
79   message length (16 bits)
80      Contains the length of the message, including this field, in bytes
81      (big-endian integer)
82   protocol version number (16 bits)
83      Contains the hex constant 0x0001 (big-endian integer)
84   AP-REQ length (16 bits)
85      length (big-endian integer) of AP-REQ data, in bytes.
86   AP-REQ data, as described in RFC1510 (variable length)
87      This AP-REQ must be for the service principal
88      kadmin/changepw@REALM, where REALM is the REALM of the user who
89      wishes to change his password.  The Ticket in the AP-REQ must be
90      derived from an AS request (thus having the INITIAL flag set), and
91      must include a subkey in the Authenticator.
92   KRB-PRIV message, as described in RFC1510 (variable length)
93      This KRB-PRIV message must be generated using the subkey in the
94      Authenticator in the AP-REQ data.  The user-data component of the
95      message must consist of the user's new password.
96
97   The server must verify the AP-REQ message, decrypt the new password,
98   perform any local policy checks (such as password quality, history,
99   authorization, etc.) required, then set the password to the new value
100   specified.
101
102   The principal whose password is to be changed is the principal which
103   authenticated to the password changing service.  This protocol does
104   not address administrators who want to change passwords of principal
105   besides their own.
106
107
108Reply Message
109
110       0                   1                   2                   3
111       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
112      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
113      |         message length        |    protocol version number    |
114      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
115      |          AP_REP length        |         AP-REP data           /
116      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
117      /                KRB-PRIV or KRB-ERROR message                  /
118      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
119
120   message length (16 bits)
121
122
123
124Horowitz                                                        [Page 2]
125
126Internet Draft      Kerberos Change Password Protocol       August, 1998
127
128
129      Contains the length of the message, including this field, in bytes
130      (big-endian integer),
131   protocol version number (16 bits)
132      Contains the hex constant 0x0001 (big-endian integer)
133   AP-REP length (16 bits)
134      length of AP-REP data, in bytes.  If the the length is zero, then
135      the last field will contain a KRB-ERROR message instead of a KRB-
136      PRIV message.
137   AP-REP data, as described in RFC1510 (variable length)
138      The AP-REP corresponding to the AP-REQ in the request packet.
139   KRB-PRIV or KRB-ERROR message, as described in RFC1510 (variable
140      length)
141      If the AP-REP length is zero, then this field contains a KRB-ERROR
142      message.  Otherwise, it contains a KRB-PRIV message.  This KRB-
143      PRIV message must be generated using the subkey in the
144      Authenticator in the AP-REQ data.
145
146      The user-data component of the KRB-PRIV message, or e-data
147      component of the KRB-ERROR message, must consist of the following
148      data:
149
150       0                   1                   2                   3
151       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
152      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
153      |          result code          |        result string          /
154      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
155
156      result code (16 bits)
157         The result code must have one of the following values (big-
158         endian integer):
159         0x0000 if the request succeeds.  (This value is not permitted
160            in a KRB-ERROR message.)
161         0x0001 if the request fails due to being malformed
162         0x0002 if the request fails due to a "hard" error processing
163            the request (for example, there is a resource or other
164            problem causing the request to fail)
165         0x0003 if the request fails due to an error in authentication
166            processing
167         0x0004 if the request fails due to a "soft" error processing
168            the request (for example, some policy or other similar
169            consideration is causing the request to be rejected).
170         0xFFFF if the request fails for some other reason.
171         Although only a few non-zero result codes are specified here,
172         the client should accept any non-zero result code as indicating
173         failure.
174      result string (variable length)
175         This field should contain information which the server thinks
176         might be useful to the user, such as feedback about policy
177         failures.  The string must be encoded in UTF-8.  It may be
178         omitted if the server does not wish to include it.  If it is
179         present, the client should display the string to the user.
180         This field is analogous to the string which follows the numeric
181         code in SMTP, FTP, and similar protocols.
182
183
184
185
186Horowitz                                                        [Page 3]
187
188Internet Draft      Kerberos Change Password Protocol       August, 1998
189
190
191Dropped and Modified Messages
192
193   An attacker (or simply a lossy network) could cause either the
194   request or reply to be dropped, or modified by substituting a KRB-
195   ERROR message in the reply.
196
197   If a request is dropped, no modification of the password/key database
198   will take place.  If a reply is dropped, the server will (assuming a
199   valid request) make the password change.  However, the client cannot
200   distinguish between these two cases.
201
202   In this situation, the client should construct a new authenticator,
203   re-encrypt the request, and retransmit.  If the original request was
204   lost, the server will treat this as a valid request, and the password
205   will be changed normally.  If the reply was lost, then the server
206   should take care to notice that the request was a duplicate of the
207   prior request, because the "new" password is the current password,
208   and the password change time is within some implementation-defined
209   replay time window.  The server should then return a success reply
210   (an AP-REP message with result code == 0x0000) without actually
211   changing the password or any other information (such as modification
212   timestamps).
213
214   If a success reply was replaced with an error reply, then the
215   application performing the request would return an error to the user.
216   In this state, the user's password has been changed, but the user
217   believes that it has not.  If the user attempts to change the
218   password again, this will probably fail, because the user cannot
219   successfully provide the old password to get an INITIAL ticket to
220   make the request.  This situation requires administrative
221   intervention as if a password was lost.  This situation is,
222   unfortunately, impossible to prevent.
223
224
225Security Considerations
226
227   This document deals with changing passwords for Kerberos.  Because
228   Kerberos is used for authentication and key distribution, it is
229   important that this protocol use the highest level of security
230   services available to a particular installation.  Mutual
231   authentication is performed, so that the server knows the request is
232   valid, and the client knows that the request has been received and
233   processed by the server.
234
235   There are also security issues relating to dropped or modified
236   messages which are addressed explicitly.
237
238
239References
240
241   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
242      Authentication Service (V5)", RFC 1510, September 1993.
243
244
245
246
247
248Horowitz                                                        [Page 4]
249
250Internet Draft      Kerberos Change Password Protocol       August, 1998
251
252
253Author's Address
254
255   Marc Horowitz
256   Stonecast, Inc.
257   108 Stow Road
258   Harvard, MA 01451
259
260   Phone: +1 978 456 9103
261   Email: marc@stonecast.net
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310Horowitz                                                        [Page 5]
311
312