Network Working Group Mike Swift
INTERNET-DRAFT University of WA
Category: Informational Jonathan Trostle
Cisco Systems
John Brezak
Microsoft
Windows 2000 Kerberos Change Password and Set Password Protocols
<draft-trostle-win2k-cat-kerberos-set-passwd-03.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026 except that the right to produce derivative
works is not granted.
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 memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Comments and suggestions on this document are encouraged. Comments
on this document should be sent to the authors.
This draft expires on January 31st, 2002.
1. Abstract
This memo specifies the Windows 2000 Kerberos [1] change password and
set password protocols. The Windows 2000 Kerberos change password
protocol interoperates with the original Kerberos change password
protocol. Change password is a request reply protocol that includes a
KRB_PRIV message that contains the new password for the user.
The original change password protocol does not allow an administrator
to set a password for a new user. This functionality is useful in
Swift, Trostle, Brezak [Page 1]
INTERNET DRAFT July 2001 Expires January 2002
some environments, and this proposal extends the change password
protocol to allow password setting. The changes are: adding new
fields to the request message to indicate the principal which is
having its password set, not requiring the initial flag in the
service ticket, using a new protocol version number, and adding three
new result codes.
2. The Protocol
The service accepts requests on UDP port 464 and TCP port 464 as
well. 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
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 big-endian order.
message length field: contains the number of bytes in the message
including this field.
protocol version number: contains the hex constant 0xff80 (big-endian
integer).
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 [1]) The AP-REQ message must be for the service
principal kadmin/changepw@REALM, where REALM is the REALM of the user
who wishes to change/set his password. The ticket in the AP-REQ must
must include a subkey in the Authenticator. To enable setting of
passwords, it is not required that the initial flag be set in the
Kerberos service ticket.
KRB-PRIV message (see [1]) This user-data field in the KRB-PRIV
message is encrypted using the subkey from the authenticator in the
AP-REQ data. The usec and seq-number fields of the KRB_PRIV message
are present and have the same value as the seq-number field in the
Swift, Trostle, Brezak [Page 2]
INTERNET DRAFT July 2001 Expires January 2002
authenticator from the AP_REQ message (the seq-number in the
authenticator will be present). The server ignores the optional r-
address field in the KRB_PRIV message, if it is present.
The user-data component of the message consists of the following
ASN.1 structure encoded as an OCTET STRING:
ChangePasswdData ::= SEQUENCE {
newpasswd[0] OCTET STRING,
targname[2] PrincipalName OPTIONAL,
targrealm[3] Realm OPTIONAL
}
The server must verify the AP-REQ message, check whether the client
principal in the ticket is authorized to set/change the password
(either for that principal, or for the principal in the targname
field if present), and decrypt the new password. 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.
The newpasswd field contains the cleartext password, and the server
will apply any local policy checks including password policy checks.
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).
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 big-endian order.
message length field: contains the number of bytes in the message
including this field.
protocol version number: contains the hex constant 0x0001 (big-endian
integer). (The reply message has the same format as the original
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.
Swift, Trostle, Brezak [Page 3]
INTERNET DRAFT July 2001 Expires January 2002
AP-REP data: the AP-REP is the response to the AP-REQ in the request
packet.
KRB-PRIV message: This KRB-PRIV message must be encrypted with the
subsession key from the authenticator in the AP-REQ data.
The server will respond with a KRB-PRIV message unless it cannot
decode the client AP-REQ or KRB-PRIV message, in which case it will
respond with a KRB-ERROR message. NOTE: Unlike change password
version 1, the KRB-ERROR message will be sent back without any
encapsulation.
The user-data component of the KRB-PRIV message, or e-data component
of the KRB-ERROR message, consists 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 | result string /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
result code (16 bits) (result codes 0-4 are from the original change
password protocol):
The result code must have one of the following values
(big-endian integer):
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_INITIAL_FLAG_NEEDED 7 initial flag required
Swift, Trostle, Brezak [Page 4]
INTERNET DRAFT July 2001 Expires January 2002
0xFFFF is returned if the request fails for some other reason.
Although only a few non-zero result codes are specified here,
the client should accept any non-zero result code as indicating
failure.
result string:
This field contains information which might be useful to
the user, such as feedback about policy failures. The string
is encoded in UTF-8. It may be omitted if the server does not
wish to include it. If it is present, the client will display
the string to the user.
3. Security Considerations
Password policies should be enforced to make sure that users do not
pick passwords (for change password) that are vulnerable to brute
force password guessing attacks. An administrator who is authorized
to set other principal's passwords is highly trusted and must also
carefully protect his/her own credentials.
4. References
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5). Request for Comments 1510.
5. Authors' Addresses
Jonathan Trostle
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
Email: jtrostle@cisco.com
Mike Swift
University of WA
Seattle, WA
mikesw@cs.washington.edu
John Brezak
1 Microsoft Way
Redmond, WA 98052
jbrezak@microsoft.com
Swift, Trostle, Brezak [Page 5]