+++ /dev/null
-
-INTERNET-DRAFT Mike Swift
-draft-ietf-cat-kerberos-set-passwd-02.txt Microsoft
-March 2000 Jonathan Trostle
- Cisco Systems
- John Brezak
- Microsoft
- Bill Gossman
- Cybersafe
-
- Kerberos Set/Change Password: Version 2
-
-
-0. Status Of This Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026 [1].
-
- 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."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- Comments and suggestions on this document are encouraged. Comments
- on this document should be sent to the CAT working group discussion
- list:
- ietf-cat-wg@stanford.edu
-
-1. Abstract
-
- The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]),
- does not allow for an administrator to set a password for a new user.
- This functionality is useful in some environments, and this proposal
- extends [4] to allow password setting. The changes are: adding new
- fields to the request message to indicate the principal which is
- having its password set, not requiring the initial flag in the service
- ticket, using a new protocol version number, and adding three new
- result codes. We also extend the set/change protocol to allow a
- client to send a sequence of keys to the KDC instead of a cleartext
- password. If in the cleartext password case, the cleartext password
- fails to satisfy password policy, the server should use the result
- code KRB5_KPASSWD_POLICY_REJECT.
-
-2. Conventions used in this document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-\f
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
- this document are to be interpreted as described in RFC-2119 [2].
-
-3. The Protocol
-
- The service must accept requests on UDP port 464 and TCP port 464 as
- well. The protocol 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.
-
- For TCP transport, there is a 4 octet header in network byte order
- precedes the message and specifies the length of the message. This
- requirement is consistent with the TCP transport header in 1510bis.
-
-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 /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- All 16 bit fields are in network byte order.
-
- message length field: contains the number of bytes in the message
- including this field.
-
- protocol version number: contains the hex constant 0x0002 (network
- byte order).
-
- AP-REQ length: length of AP-REQ data, in bytes. If the length is zero,
- then the last field contains a KRB-ERROR message instead of a KRB-PRIV
- message.
-
- AP-REQ data: (see [3]) The AP-REQ message must be for the service
- principal kadmin/changepw@REALM, where REALM is the REALM of the user
- who wishes to change/set his password. The ticket in the AP-REQ must
- must include a subkey in the Authenticator. To enable setting of
- passwords/keys, it is not required that the initial flag be set in the
- Kerberos service ticket. The initial flag is required for change requests,
- but not for set password requests. We have the following definitions:
-
- old passwd initial flag target principal can be
- in request? required? distinct from
- authenticating principal?
-
- change password: yes yes no
-
- set password: no no yes
-
- set key: no policy yes
- determined
-\f
- KRB-PRIV message (see [3]) This KRB-PRIV message must be generated
- using the subkey from the authenticator in the AP-REQ data.
-
- The user-data component of the message consists of the following ASN.1
- structure encoded as an OCTET STRING:
-
- ChangePasswdData :: = SEQUENCE {
- newpasswdorkeys[0] NewPasswdOrKeys,
- targname[1] PrincipalName OPTIONAL,
- -- only present in set password: the principal
- -- which will have its password set
- targrealm[2] Realm OPTIONAL,
- -- only present in set password: the realm for
- -- the principal which will have its password set
-
- }
-
- NewPasswdOrKeys :: = CHOICE {
- passwords[0] PasswordSequence,
- keyseq[1] KeySequences
- }
-
- KeySequences :: = SEQUENCE OF KeySequence
-
- KeySequence :: = SEQUENCE {
- key[0] EncryptionKey,
- salt[1] OCTET STRING OPTIONAL,
- salt-type[2] INTEGER OPTIONAL
- }
-
- PasswordSequence :: = SEQUENCE {
- newpasswd[0] OCTET STRING,
- oldpasswd[1] OCTET STRING OPTIONAL
- -- oldpasswd always present for change password
- -- but not present for set password
- }
-
- The server must verify the AP-REQ message, check whether the client
- principal in the ticket is authorized to set or change the password
- (either for that principal, or for the principal in the targname
- field if present), and decrypt the new password/keys. The server
- also checks whether the initial flag is required for this request,
- replying with status 0x0007 if it is not set and should be. An
- authorization failure is cause to respond with status 0x0005. For
- forward compatibility, the server should be prepared to ignore fields
- after targrealm in the structure that it does not understand.
-
- The newpasswdorkeys field contains either the new cleartext password
- (with the old cleartext password for a change password operation),
- or a sequence of encryption keys with their respective salts.
-
- In the cleartext password case, if the old password is sent in the
- request, the request is defined to be a change password request. If
- the old password is not present in the request, the request is a set
- password request. The server should apply policy checks to the old
- and new password after verifying that the old password is valid.
- The server can check validity by obtaining a key from the old
- password with a keytype that is present in the KDC database for the
- user and comparing the keys for equality. The server then generates
- the appropriate keytypes from the password and stores them in the KDC
-\f
- database. If all goes well, status 0x0000 is returned to the client
- in the reply message (see below). For a change password operation,
- the initial flag in the service ticket MUST be set.
-
- In the key sequence case, the sequence of keys is sent to the set
- password service. For a principal that can act as a server, its
- preferred keytype should be sent as the first key in the sequence,
- but the KDC is not required to honor this preference. Application
- servers should use the key sequence option for changing/setting their
- keys. The set password service should check that all keys are in the
- proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise.
-
-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 message /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- All 16 bit fields are in network byte order.
-
- message length field: contains the number of bytes in the message
- including this field.
-
- protocol version number: contains the hex constant 0x0002 (network
- byte order). (The reply message has the same format as in [4]).
-
- AP-REP length: length of AP-REP data, in bytes. If the length is zero,
- then the last field contains a KRB-ERROR message instead of a KRB-PRIV
- message.
-
- AP-REP data: the AP-REP is the response to the AP-REQ in the request
- packet.
-
- KRB-PRIV from [4]: This KRB-PRIV message must be generated using the
- subkey in the authenticator in the AP-REQ data.
-
- The server will respond with a KRB-PRIV message unless it cannot
- validate the client AP-REQ or KRB-PRIV message, in which case it will
- respond with a KRB-ERROR message. NOTE: Unlike change password version
- 1, the KRB-ERROR message will be sent back without any encapsulation.
-
- 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 /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | edata /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-\f
- result code (16 bits) (result codes 0-4 are from [4]):
- The result code must have one of the following values (network
- byte order):
- KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not
- allowed in a KRB-ERROR message)
- KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed
- KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in
- processing the request (for example,
- there is a resource or other problem
- causing the request to fail)
- KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in
- authentication processing
- KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error
- in processing the request
- KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
- KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported
- KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
- KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy;
- the result string should include a text message to be presented
- to the user.
- KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist
- (only in response to a set password request).
- KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
- containing at least one etype that is not supported by the KDC.
- The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO
- type that specifies the etypes that the KDC supports:
-
- KERB-ETYPE-INFO-ENTRY :: = SEQUENCE {
- encryption-type[0] INTEGER,
- salt[1] OCTET STRING OPTIONAL -- not sent
- }
-
- PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY
-
- The client should retry the request using only etypes (keytypes)
- that are contained within the PKERB-ETYPE-INFO structure in the
- previous response.
- 0xFFFF if the request fails for some other reason.
- The client must interpret any non-zero result code as a failure.
- result string - from [4]:
- This field is a UTF-8 encoded string which should be displayed
- to the user by the client. Specific reasons for a password
- set/change policy failure is one use for this string.
- edata: used to convey additional information as defined by the
- result code.
-
-4. References
-
- [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
- 9, RFC 2026, October 1996.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997
-
- [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
- Service (V5), Request for Comments 1510.
-\f
- [4] M. Horowitz. Kerberos Change Password Protocol,
- ftp://ds.internic.net/internet-drafts/
- draft-ietf-cat-kerb-chg-password-02.txt
-
-5. Expiration Date
-
- This draft expires in September 2000.
-
-6. Authors' Addresses
-
- Jonathan Trostle
- Cisco Systems
- 170 W. Tasman Dr.
- San Jose, CA 95134
- Email: jtrostle@cisco.com
-
- Mike Swift
- 1 Microsoft Way
- Redmond, WA 98052
- Email: mikesw@microsoft.com
-
- John Brezak
- 1 Microsoft Way
- Redmond, WA 98052
- Email: jbrezak@microsoft.com
-
- Bill Gossman
- Cybersafe Corporation
- 1605 NW Sammamish Rd.
- Issaquah, WA 98027-5378
- Email: bill.gossman@cybersafe.com
-
git.samba.org / samba.git / blobdiff