diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt | 311 |
1 files changed, 0 insertions, 311 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt deleted file mode 100644 index e235bec58c02..000000000000 --- a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt +++ /dev/null @@ -1,311 +0,0 @@ - - - - -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] - |