[2203] in Kerberos_V5_Development
password change protocol
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Wed Feb 5 20:32:47 1997
To: krbdev@MIT.EDU
From: Marc Horowitz <marc@cygnus.com>
Date: 05 Feb 1997 20:31:53 -0500
In the interest of having a standards-track password change protocol
which could be easily implemented on limited-purpose platforms
(routers, terminal servers, macos (1/2 :-)), I have written an
internet-draft describing such a protocol. I've also implemented it;
server, client, and library code is about 800 lines total.
I understand that Ted has a protocol which somewhat fits in the same
space, but it has many more options than I believe are necessary, and
the current implementation is based on the old kadmin code, and, as a
result, is complex and difficult to maintain.
I intend to submit this draft to the cat-ietf working group for
standards-track progression. I would like input from the kerberos
team before I do so.
Thanks.
Marc
Network Working Group M. Horowitz
<draft-ietf-cat-kerb-change-password-00.txt> Cygnus Solutions
Internet-Draft January, 1997
Kerberos Change Password Protocol
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list.
Abstract
The Kerberos V5 protocol [RFC1510] does not describe any mechanism
for users to change their own passwords. In order to promote
interoperability between workstations, personal computers, terminal
servers, routers, and KDC's from multiple vendors, a common password
changing protocol is required.
Overview
When a user wishes to change his own password, or is required to by
local policy, a simple request of a password changing service is
necessary. This service must be implemented on at least one host for
each Kerberos realm, probably on one of the kdc's for that realm.
The service must accept requests on UDP port 464 (kpasswd), and may
accept requests on TCP port 464 as well.
The protocol itself 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, each
message is preceded by the length of the message in octets,
represented as a two-byte big-endian integer.
Horowitz [Page 1]
Internet Draft Kerberos Change Password Protocol January, 1997
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol version number | AP-REQ length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ AP-REQ data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ KRB-PRIV message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
protocol version number (16 bits)
Contains the hex constant 0x0001 (big-endian integer)
AP-REQ length (16 bits)
length (big-endian integer) of AP-REQ data, in bytes.
AP-REQ data (variable length)
This AP-REQ must be for the service principal
kadmin/changepw@REALM, where REALM is the REALM of the user who
wishes to change his password. The Ticket in the AP-REQ must be
derived from an AS request (thus having the INITIAL flag set), and
must include a subkey in the Authenticator.
KRB-PRIV message (variable length)
This KRB-PRIV message must be generated using the subkey in the
Authenticator in the AP-REQ data. The user-data component of the
message must consist of the user's new password.
The server must verify the AP-REQ message, decrypt the new password,
perform any local policy checks (such as password quality, history,
authorization, etc.) required, then set the password to the new value
specified.
The principal whose password is to be changed is the principal which
authenticated to the password changing service. This protocol does
not address admins who wants to change another user's password.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol version number | AP-REP length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ AP-REP data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ KRB-PRIV or KRB-ERROR message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
protocol version number (16 bits)
Contains the hex constant 0x0001 (big-endian integer)
AP-REP length (16 bits)
length of AP-REP data, in bytes. If the the length is zero, then
the last field will contain a KRB-ERROR message instead of a KRB-
Horowitz [Page 2]
Internet Draft Kerberos Change Password Protocol January, 1997
PRIV message.
AP-REP data (variable length)
The AP-REP corresponding to the AP-REQ in the request packet.
KRB-PRIV or KRB-ERROR message (variable length)
If the AP-REP length is zero, then this field contains a KRB-ERROR
message. Otherwise, it contains a KRB-PRIV message. This KRB-
PRIV message must be generated using the subkey in the
Authenticator in the AP-REQ data.
The user-data component of the KRB-PRIV message, or e-data
component of the KRB-ERROR message, must consist 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)
Must be 0x0000 (big-endian integer) if the request succeeds.
(This value is not permitted in a KRB-ERROR message) If the
request fails, the result code must be 0x0001 if the request is
malformed, 0x0002 if there is a "hard" error processing the
request (for example, there is a resource or other problem
causing the request to fail), 0x0003 if there is an error in
authenticating processing, or 0x0004 if there is a "soft" error
processing the request (for example, some policy or other
similar consideration is causing the request to be rejected).
Although only three non-zero result codes are specified here,
the client should interpret any non-zero result code as a
failure.
result string (variable length)
This field should contain information which the server thinks
might be useful to the user. No particular format is mandated,
and the field may be omitted if the server does not wish to
include it. This field is analogous to the string which
follows the numeric code in SMTP, FTP, and similar protocols.
Security Considerations
This document deals with changing passwords for Kerberos. Because
Kerberos is used for authentication and key distribution, it is
important that this protocol use the highest level of security
services available to a particular installation. Mutual
authentication is performed, so that the server knows the request is
valid, and the client knows that the request has been received and
processed by the server.
There are also security issues relating to dropped, stolen, or
modified messages. An attacker (or simply a lossy network) could
cause either the request or reply to be dropped, or substitute a KRB-
ERROR message in the reply.
Horowitz [Page 3]
Internet Draft Kerberos Change Password Protocol January, 1997
If a reply is dropped, it is reasonable for the client to construct a
new authenticator, re-encrypt the request, and retransmit. If the
request was lost, the server will treat this as a valid request, and
all should work normally. If the reply was lost, then the server
should take care to notice that the request was a duplicate of the
prior request, and indicate success without actually changing the
password or any other information (such as modification timestamps).
If a success reply was replaced with an error reply, then one would
expect that the user would attempt the operation again. Again, the
server should recognize the request as a duplicate and indicate
success without changing the password. If the user is required to
provide the old password again, but the password was actually changed
successfully, then some user confusion could result. This is,
unfortunately, impossible to prevent.
References
[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
Author's Address
Marc Horowitz
Cygnus Solutions
955 Massachusetts Avenue
Cambridge, MA 02139
Phone: +1 617 354 7688
Email: marc@cygnus.com
Horowitz [Page 4]
