draft-ietf-cat-kerberos-set-passwd-00.txt   draft-ietf-cat-kerberos-set-passwd-01.txt 
INTERNET-DRAFT Mike Swift INTERNET-DRAFT Mike Swift
draft-ietf-cat-kerberos-set-passwd-00.txt Microsoft draft-ietf-cat-kerberos-set-passwd-01.txt Microsoft
expires March, 2000 Jonathan Trostle February 2000 Jonathan Trostle
Cisco Systems Cisco Systems
John Brezak John Brezak
Microsoft Microsoft
Bill Gossman
Cybersafe
Extending Change Password for Setting Kerberos Passwords Kerberos Set/Change Password: Version 2
0. Status Of This Memo 0. Status Of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as Drafts as reference material or to cite them other than as
skipping to change at line 37 skipping to change at line 40
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Comments and suggestions on this document are encouraged. Comments Comments and suggestions on this document are encouraged. Comments
on this document should be sent to the CAT working group discussion on this document should be sent to the CAT working group discussion
list: list:
ietf-cat-wg@stanford.edu ietf-cat-wg@stanford.edu
This document expires in March, 2000.
1. Abstract 1. Abstract
The Kerberos [1] change password protocol [2], does not allow for The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]),
an administrator to set a password for a new user. This functionality does not allow for an administrator to set a password for a new user.
is useful in some environments, and this proposal extends [2] to This functionality is useful in some environments, and this proposal
allow password setting. The changes are: adding new fields to the extends [4] to allow password setting. The changes are: adding new
request message to indicate the principal which is having its fields to the request message to indicate the principal which is
password set, not requiring the initial flag in the service ticket, having its password set, not requiring the initial flag in the service
using a new protocol version number, and adding three new result ticket, using a new protocol version number, and adding three new
codes. 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. The Protocol 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 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 well. The protocol consists of a single request message followed by
a single reply message. For UDP transport, each message must be fully a single reply message. For UDP transport, each message must be fully
contained in a single UDP packet. contained in a single UDP packet.
For TCP transport, there is a 4 octet header in network byte order For TCP transport, there is a 4 octet header in network byte order
precedes the message and specifies the length of the message. This precedes the message and specifies the length of the message. This
requirement is consistent with the TCP transport header in 1510bis. requirement is consistent with the TCP transport header in 1510bis.
skipping to change at line 73 skipping to change at line 84
0 1 2 3 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 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 | | message length | protocol version number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP_REQ length | AP-REQ data / | AP_REQ length | AP-REQ data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ KRB-PRIV message / / KRB-PRIV message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All 16 bit fields are in big-endian order. All 16 bit fields are in network byte order.
message length field: contains the number of bytes in the message message length field: contains the number of bytes in the message
including this field. including this field.
protocol version number: contains the hex constant 0xff80 (big-endian protocol version number: contains the hex constant 0x0002 (network
integer). byte order).
AP-REQ length: length of AP-REP data, in bytes. If the length is zero, 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 then the last field contains a KRB-ERROR message instead of a KRB-PRIV
message. message.
AP-REQ data: (see [1]) The AP-REQ message must be for the service 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 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 who wishes to change/set his password. The ticket in the AP-REQ must
must include a subkey in the Authenticator. 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:
KRB-PRIV message (see [1]) This KRB-PRIV message must be generated old passwd initial flag target principal can be
using the subkey from the authenticator in the AP-REQ data. The in request? required? distinct from
initial flag of the service ticket is ignored by the server unless authenticating principal?
policy dictates otherwise, in which case the request will be rejected
with result code 0x0007 if the initial flag is not set and is required change password: yes yes no
for this particular request. The user-data component of the message
consists of the following ASN.1 structure encoded as an OCTET STRING: 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 { 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] KeySequence,
keyseq[1] PasswordSequence
KeySequence :: = SEQUENCE {
key[0] EncryptionKey,
salt[1] OCTET STRING OPTIONAL,
salt-type[2] INTEGER OPTIONAL
}
PasswordSequence :: = SEQUENCE {
newpasswd[0] OCTET STRING, newpasswd[0] OCTET STRING,
targname[2] PrincipalName OPTIONAL, oldpasswd[1] OCTET STRING OPTIONAL
targrealm[3] Realm OPTIONAL -- oldpasswd always present for change password
-- but not set password
} }
The server must verify the AP-REQ message, check whether the client The server must verify the AP-REQ message, check whether the client
principal in the ticket is authorized to set/change the password principal in the ticket is authorized to set or change the password
(either for that principal, or for the principal in the targname (either for that principal, or for the principal in the targname
field if present), and decrypt the new password. The server also field if present), and decrypt the new password/keys. The server
checks whether the initial flag is required for this request, also checks whether the initial flag is required for this request,
replying with status 0x0007 if it is not set and should be. An replying with status 0x0007 if it is not set and should be. An
authorization failure is cause to respond with status 0x0005. For authorization failure is cause to respond with status 0x0005. For
forward compatibility, the server should be prepared to ignore fields forward compatibility, the server should be prepared to ignore fields
after targrealm in the structure that it does not understand. after targrealm in the structure that it does not understand.
The newpasswd field contains the cleartext password, and the server The newpasswdorkeys field contains either the new cleartext password
should apply any local policy checks including password policy checks. (with the old cleartext password for a change password operation),
The server then generates the appropriate keytypes from the password or a sequence of encryption keys with their respective salts.
and stores them in the KDC database. If all goes well, status 0x0000
is returned to the client in the reply message (see below). 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 Reply Message
0 1 2 3 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 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 | | message length | protocol version number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP_REP length | AP-REP data / | AP_REP length | AP-REP data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ KRB-PRIV or KRB-ERROR message / / KRB-PRIV message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All 16 bit fields are in big-endian order. All 16 bit fields are in network byte order.
message length field: contains the number of bytes in the message message length field: contains the number of bytes in the message
including this field. including this field.
protocol version number: contains the hex constant 0x0001 (big-endian protocol version number: contains the hex constant 0x0002 (network
integer). (The reply message has the same format as in [2]). 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, 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 then the last field contains a KRB-ERROR message instead of a KRB-PRIV
message. message.
AP-REP data: the AP-REP is the response to the AP-REQ in the request AP-REP data: the AP-REP is the response to the AP-REQ in the request
packet. packet.
KRB-PRIV or KRB-ERROR message: - from [2]: if the AP-REP length is KRB-PRIV from [4]: This KRB-PRIV message must be generated using the
zero, then this field contains a KRB-ERROR message. Otherwise, it subkey in the authenticator in the AP-REQ data.
contains a KRB-PRIV message. 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 The server will respond with a KRB-PRIV message unless it cannot
decode the client AP-REQ or KRB-PRIV message, in which case it will validate the client AP-REQ or KRB-PRIV message, in which case it will
respond with a KRB-ERROR message. 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 The user-data component of the KRB-PRIV message, or e-data component
of the KRB-ERROR message, must consist of the following data. of the KRB-ERROR message, must consist of the following data.
0 1 2 3 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 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 | result string /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| edata /
result code (16 bits) (result codes 0-4 are from [2]): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The result code must have one of the following values (big- result code (16 bits) (result codes 0-4 are from [4]):
endian integer): The result code must have one of the following values (network
byte order):
KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not
allowed in a KRB-ERROR message) allowed in a KRB-ERROR message)
KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed
KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in
processing the request (for example, processing the request (for example,
there is a resource or other problem there is a resource or other problem
causing the request to fail) causing the request to fail)
KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in
authentication processing authentication processing
KRB5_KPASSWD_SOFTERROR 4 request fails due to a "soft" error KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error
in processing the request in processing the request
KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported
KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required 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. 0xFFFF if the request fails for some other reason.
Although only a few non-zero result codes are specified here, The client must interpret any non-zero result code as a failure.
the client should accept any non-zero result code as indicating result string - from [4]:
failure. This field is a UTF-8 encoded string which should be displayed
result string - from [2]: to the user by the client. Specific reasons for a password
This field should contain information which the server thinks set/change policy failure is one use for this string.
might be useful to the user, such as feedback about policy edata: used to convey additional information as defined by the
failures. The string must be encoded in UTF-8. It may be result code.
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.
3. Bibliography 4. References
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
Service (V5). Request for Comments 1510. 9, RFC 2026, October 1996.
[2] M. Horowitz. Kerberos Change Password Protocol. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
[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/ ftp://ds.internic.net/internet-drafts/
draft-ietf-cat-kerb-chg-password-02.txt draft-ietf-cat-kerb-chg-password-02.txt
4. Expiration Date 5. Expiration Date
This draft expires on March 31, 2000. This draft expires in August 2000.
5. Authors' Addresses 6. Authors' Addresses
Jonathan Trostle Jonathan Trostle
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
Email: jtrostle@cisco.com
Email: jtrostle@cisco.com, jtrostle@world.std.com
Mike Swift Mike Swift
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
mikesw@microsoft.com Email: mikesw@microsoft.com
John Brezak John Brezak
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
jbrezak@microsoft.com Email: jbrezak@microsoft.com
Bill Gossman
Cybersafe Corporation
Email: bill.gossman@cybersafe.com
 End of changes. 38 change blocks. 
75 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/