oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

update to draft-ietf-cat-kerb-chg-password-02.txt

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@6764 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Assar Westerlund
1999-08-06 23:01:25 +00:00
parent 80562a8940
commit b7b022d9ca
2 changed files with 406 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

311
doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt Normal file
View File

@@ -0,0 +1,311 @@
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]