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]
|
|||
|
|
|