11a75fc89d
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@1560 ec53bebd-3082-4978-b11e-865c3cabbd6b
253 lines
9.9 KiB
Plaintext
253 lines
9.9 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group M. Horowitz
|
||
<draft-ietf-cat-kerb-chg-password-00.txt> Cygnus Solutions
|
||
Internet-Draft March, 1997
|
||
Expire in six months
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Horowitz [Page 1]
|
||
|
||
Internet Draft Kerberos Change Password Protocol March, 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
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| message length | protocol version number |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| AP_REQ length | AP-REQ data /
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
/ KRB-PRIV message /
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
||
message length (16 bits)
|
||
Contains the length of the message, including this field, in bytes
|
||
(big-endian integer)
|
||
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, as described in RFC1510 (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, as described in RFC1510 (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 administrators who want to change passwords of principal
|
||
besides their own.
|
||
|
||
|
||
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 or KRB-ERROR message /
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
||
message length (16 bits)
|
||
|
||
|
||
|
||
Horowitz [Page 2]
|
||
|
||
Internet Draft Kerberos Change Password Protocol March, 1997
|
||
|
||
|
||
Contains the length of the message, including this field, in bytes
|
||
(big-endian integer),
|
||
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-
|
||
PRIV message.
|
||
AP-REP data, as described in RFC1510 (variable length)
|
||
The AP-REP corresponding to the AP-REQ in the request packet.
|
||
KRB-PRIV or KRB-ERROR message, as described in RFC1510 (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)
|
||
The result code must have one of the following values (big-
|
||
endian integer):
|
||
0x0000 if the request succeeds. (This value is not permitted
|
||
in a KRB-ERROR message.)
|
||
0x0001 if the request fails due to being malformed
|
||
0x0002 if the request fails due to a "hard" error processing
|
||
the request (for example, there is a resource or other
|
||
problem causing the request to fail)
|
||
0x0003 if the request fails due to an error in authentication
|
||
processing
|
||
0x0004 if the request fails due to a "soft" error processing
|
||
the request (for example, some policy or other similar
|
||
consideration is causing the request to be rejected).
|
||
0xFFFF if the request fails for some other reason.
|
||
Although only four non-zero result codes are specified here,
|
||
the client should accept any non-zero result code as indicating
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Horowitz [Page 3]
|
||
|
||
Internet Draft Kerberos Change Password Protocol March, 1997
|
||
|
||
|
||
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.
|
||
|
||
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]
|
||
|