326 lines
14 KiB
Plaintext
326 lines
14 KiB
Plaintext
|
||
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",
|
||
|
||
"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
|
||
|
||
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
|
||
|
||
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 /
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
||
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.
|
||
|
||
[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
|
||
|