1
2CAT Working Group                                     Mike Swift 
3draft-trostle-win2k-cat-kerberos-set-passwd-00.txt    Microsoft               
4February 2000                                         Jonathan Trostle
5Category: Informational                               Cisco Systems
6                                                      John Brezak
7                                                      Microsoft
8
9         Extending Change Password for Setting Kerberos Passwords
10
11
120. Status Of This Memo
13
14   This document is an Internet-Draft and is in full conformance with 
15   all provisions of Section 10 of RFC2026. 
16
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 
20   Internet-Drafts.
21
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
26   "work in progress."
27
28   The list of current Internet-Drafts can be accessed at
29   http://www.ietf.org/ietf/1id-abstracts.txt
30
31   The list of Internet-Draft Shadow Directories can be accessed at
32   http://www.ietf.org/shadow.html.
33
34   Comments and suggestions on this document are encouraged.  Comments 
35   on this document should be sent to the CAT working group discussion 
36   list:
37                       ietf-cat-wg@stanford.edu
38
391. Abstract
40
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 
48   codes. 
49   
502. The Protocol
51
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.
56
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
59
60   requirement is consistent with the TCP transport header in 1510bis.
61
62Request Message
63
64       0                   1                   2                   3
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
71      /                        KRB-PRIV message                       /
72      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
73
74   All 16 bit fields are in big-endian order. 
75
76   message length field: contains the number of bytes in the message 
77   including this field.
78
79   protocol version number: contains the hex constant 0xff80 (big-endian 
80   integer).
81
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 
84   message.
85
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.
92
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. 
95
96   The user-data component of the message consists of the following ASN.1 
97   structure encoded as an OCTET STRING:
98
99   ChangePasswdData ::=  SEQUENCE {
100                       newpasswd[0]   OCTET STRING,
101                       targname[2]    PrincipalName OPTIONAL,
102                       targrealm[3]   Realm OPTIONAL
103                       }  
104
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. 
114
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
118
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).
121
122Reply Message
123
124       0                   1                   2                   3
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
131      /                         KRB-PRIV message                      /
132      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
133
134
135   All 16 bit fields are in big-endian order. 
136
137   message length field: contains the number of bytes in the message 
138   including this field.
139
140   protocol version number: contains the hex constant 0x0001 (big-endian 
141   integer). (The reply message has the same format as in [2]).
142
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 
145   message.
146
147   AP-REP data: the AP-REP is the response to the AP-REQ in the request 
148   packet.
149   
150   KRB-PRIV from [2]: This KRB-PRIV message must be generated using the 
151   subkey in the authenticator in the AP-REQ data.
152
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.
157
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.
160
161       0                   1                   2                   3
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
166
167      result code (16 bits) (result codes 0-4 are from [2]):
168         The result code must have one of the following values (big-
169         endian integer):
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)
177
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
188         failure.
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.
197
1983. References
199 
200   [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
201   Service (V5). Request for Comments 1510.
202
203   [2] M. Horowitz. Kerberos Change Password Protocol.
204   ftp://ds.internic.net/internet-drafts/
205   draft-ietf-cat-kerb-chg-password-02.txt
206
2074. Expiration Date
208
209   This draft expires in August 2000.   
210
2115. Authors' Addresses
212
213   Jonathan Trostle
214   Cisco Systems
215   170 W. Tasman Dr.
216   San Jose, CA 95134
217   Email: jtrostle@cisco.com
218
219   Mike Swift 
220   1 Microsoft Way
221   Redmond, WA 98052
222   mikesw@microsoft.com
223
224   John Brezak
225   1 Microsoft Way
226   Redmond, WA 98052
227   jbrezak@microsoft.com
228