312 lines
11 KiB
Plaintext
312 lines
11 KiB
Plaintext
|
||
|
||
|
||
|
||
Network Working Group M. Horowitz
|
||
<draft-ietf-cat-kerb-chg-password-02.txt> Stonecast, Inc.
|
||
Internet-Draft August, 1998
|
||
|
||
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 ftp.ietf.org (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 August, 1998
|
||
|
||
|
||
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 August, 1998
|
||
|
||
|
||
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 a few 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, such as feedback about policy
|
||
failures. The string must be encoded in UTF-8. It may be
|
||
omitted if the server does not wish to include it. If it is
|
||
present, the client should display the string to the user.
|
||
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 August, 1998
|
||
|
||
|
||
Dropped and Modified Messages
|
||
|
||
An attacker (or simply a lossy network) could cause either the
|
||
request or reply to be dropped, or modified by substituting a KRB-
|
||
ERROR message in the reply.
|
||
|
||
If a request is dropped, no modification of the password/key database
|
||
will take place. If a reply is dropped, the server will (assuming a
|
||
valid request) make the password change. However, the client cannot
|
||
distinguish between these two cases.
|
||
|
||
In this situation, the client should construct a new authenticator,
|
||
re-encrypt the request, and retransmit. If the original request was
|
||
lost, the server will treat this as a valid request, and the password
|
||
will be changed normally. If the reply was lost, then the server
|
||
should take care to notice that the request was a duplicate of the
|
||
prior request, because the "new" password is the current password,
|
||
and the password change time is within some implementation-defined
|
||
replay time window. The server should then return a success reply
|
||
(an AP-REP message with result code == 0x0000) without actually
|
||
changing the password or any other information (such as modification
|
||
timestamps).
|
||
|
||
If a success reply was replaced with an error reply, then the
|
||
application performing the request would return an error to the user.
|
||
In this state, the user's password has been changed, but the user
|
||
believes that it has not. If the user attempts to change the
|
||
password again, this will probably fail, because the user cannot
|
||
successfully provide the old password to get an INITIAL ticket to
|
||
make the request. This situation requires administrative
|
||
intervention as if a password was lost. This situation is,
|
||
unfortunately, impossible to prevent.
|
||
|
||
|
||
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 or modified
|
||
messages which are addressed explicitly.
|
||
|
||
|
||
References
|
||
|
||
[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
|
||
Authentication Service (V5)", RFC 1510, September 1993.
|
||
|
||
|
||
|
||
|
||
|
||
Horowitz [Page 4]
|
||
|
||
Internet Draft Kerberos Change Password Protocol August, 1998
|
||
|
||
|
||
Author's Address
|
||
|
||
Marc Horowitz
|
||
Stonecast, Inc.
|
||
108 Stow Road
|
||
Harvard, MA 01451
|
||
|
||
Phone: +1 978 456 9103
|
||
Email: marc@stonecast.net
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Horowitz [Page 5]
|
||
|