draft-ietf-cat-kerberos-set-passwd-04.txt   draft-ietf-cat-kerberos-set-passwd-05.txt 
INTERNET-DRAFT Mike Swift Network Working Group Jonathan Trostle
draft-ietf-cat-kerberos-set-passwd-04.txt University of WA INTERNET-DRAFT Cisco Systems
March 2001 Jonathan Trostle Category: Standards Track Mike Swift
Cisco Systems University of WA
John Brezak John Brezak
Microsoft Microsoft
Bill Gossman Bill Gossman
Cybersafe Cisco Systems
Kerberos Set/Change Password: Version 2 Kerberos Set/Change Password: Version 2
<draft-ietf-cat-kerberos-set-passwd-05.txt>
0. Status Of This Memo 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 [1]. all provisions of Section 10 of RFC2026 [6].
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-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet- time. It is inappropriate to use Internet- Drafts as reference
Drafts as reference material or to cite them other than as material or to cite them other than as "work in progress."
"work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
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 This draft expires on October 31st, 2001. Please send comments to the
on this document should be sent to the CAT working group discussion authors.
list: ietf-cat-wg@stanford.edu.
This draft expires on September 30th, 2001.
1. Abstract 1. Abstract
The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), This proposal specifies a Kerberos (RFC 1510 [3]) change/set password
does not allow for an administrator to set a password for a new user. protocol and a Kerberos change/set key protocol. The protocol
This functionality is useful in some environments, and this proposal consists of a single request and reply message. The request message
extends [4] to allow password setting. The changes are: adding new includes both AP_REQ and KRB_PRIV submessages; the new password is
fields to the request message to indicate the principal which is contained in the KRB_PRIV submessage which is encrypted in the
having its password set, not requiring the initial flag in the service session key from the ticket. The original Kerberos change password
ticket, using a new protocol version number, and adding three new protocol did not allow for an administrator to set a password for a
result codes. We also extend the set/change protocol to allow a new user. This functionality is useful in some environments, and this
client to send a sequence of keys to the KDC instead of a cleartext proposal allows password setting as well as password changing. The
password. If in the cleartext password case, the cleartext password protocol includes fields in the request message to indicate the
fails to satisfy password policy, the server should use the result principal which is having its password set. We also extend the
code KRB5_KPASSWD_POLICY_REJECT. 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 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC-2119 [2]. document are to be interpreted as described in RFC2119 [7].
3. The Protocol 3. Definitions from RFC 1510
The service MUST accept requests on UDP port 464 and TCP port 464 as We include some of the relevant ASN.1 definitions from RFC 1510 in
well. The protocol consists of a single request message followed by this section.
a single reply message. For UDP transport, each message must be fully
Realm ::= GeneralString
PrincipalName ::= SEQUENCE {
name-type[0] INTEGER,
name-string[1] SEQUENCE OF GeneralString
}
KerberosTime ::= GeneralizedTime
-- Specifying UTC time zone (Z)
HostAddress ::= SEQUENCE {
addr-type[0] INTEGER,
address[1] OCTET STRING
}
EncryptedData ::= SEQUENCE {
etype[0] INTEGER, -- EncryptionType
kvno[1] INTEGER OPTIONAL,
cipher[2] OCTET STRING -- ciphertext
}
EncryptionKey ::= SEQUENCE {
keytype[0] INTEGER,
keyvalue[1] OCTET STRING
}
Checksum ::= SEQUENCE {
cksumtype[0] INTEGER,
checksum[1] OCTET STRING
}
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER, -- indicates Version 5
msg-type [1] INTEGER, -- indicates KRB_AP_REQ
ap-options[2] APOptions,
ticket[3] Ticket,
authenticator[4] EncryptedData
}
APOptions ::= BIT STRING {
reserved (0),
use-session-key (1),
mutual-required (2)
}
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER, -- indicates Version 5
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData
}
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags[0] TicketFlags,
key[1] EncryptionKey,
crealm[2] Realm,
cname[3] PrincipalName,
transited[4] TransitedEncoding,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
caddr[9] HostAddresses OPTIONAL,
authorization-data[10] AuthorizationData OPTIONAL
}
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno[0] INTEGER,
crealm[1] Realm,
cname[2] PrincipalName,
cksum[3] Checksum OPTIONAL,
cusec[4] INTEGER,
ctime[5] KerberosTime,
subkey[6] EncryptionKey OPTIONAL,
seq-number[7] INTEGER OPTIONAL,
authorization-data[8] AuthorizationData OPTIONAL
}
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER, -- represents Kerberos V5
msg-type [1] INTEGER, -- represents KRB_AP_REP
enc-part [2] EncryptedData
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] INTEGER,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] INTEGER OPTIONAL
}
Here is the syntax of the KRB_ERROR message:
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ctime[2] KerberosTime OPTIONAL,
cusec[3] INTEGER OPTIONAL,
stime[4] KerberosTime,
susec[5] INTEGER,
error-code[6] INTEGER,
crealm[7] Realm OPTIONAL,
cname[8] PrincipalName OPTIONAL,
realm[9] Realm, -- Correct realm
sname[10] PrincipalName, -- Correct name
e-text[11] GeneralString OPTIONAL,
e-data[12] OCTET STRING OPTIONAL
}
The KRB_PRIV message is used to send the request and reply data:
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
enc-part[3] EncryptedData
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data[0] OCTET STRING,
timestamp[1] KerberosTime OPTIONAL,
usec[2] INTEGER OPTIONAL,
seq-number[3] INTEGER OPTIONAL,
s-address[4] HostAddress,
-- sender's addr
r-address[5] HostAddress OPTIONAL
-- recip's addr
}
4. The Protocol
The service SHOULD accept requests on UDP port 464 and TCP port 464
as well. Use of other ports can significantly increase the complexity
and size of IPSEC policy rulesets in organizations that have IPSEC
capable nodes.
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. 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 that precedes the message and specifies the length of the message.
requirement is consistent with the TCP transport header in 1510bis. This requirement is consistent with the TCP transport header in
1510bis.
Request Message Request 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_REQ length | AP-REQ data / | AP_REQ length | AP-REQ data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 93 skipping to change at page 5, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All 16 bit fields are in network byte 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 0x0002 (network protocol version number: contains the hex constant 0x0002 (network
byte order). byte order).
AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, AP-REQ length: length of AP-REQ data, in bytes. If the length is
then the last field contains a KRB-ERROR message instead of a KRB-PRIV zero, then the last field contains a KRB-ERROR message instead of a
message. KRB-PRIV message.
AP-REQ data: (see [3]) For a change password/key request, the AP-REQ AP-REQ data: (see [3]) For a change password/key request, the AP-REQ
message service ticket sname, srealm principal identifier is message service ticket sname, srealm principal identifier is
kadmin/changepw@REALM where REALM is the realm of the change password kadmin/changepw@REALM where REALM is the realm of the change password
service. The same applies to a set password/key request except the service. The same applies to a set password/key request except the
principal identifier is kadmin/setpw@REALM. To enable setting of principal identifier is kadmin/setpw@REALM. To enable setting of
passwords/keys, it is not required that the initial flag be set in the passwords/keys, it is not required that the initial flag be set in
Kerberos service ticket. The initial flag is required for change requests, the Kerberos service ticket. The initial flag is required for change
but not for set requests. We have the following definitions: requests, but not for set requests. We have the following
definitions:
old passwd initial flag target principal can be old passwd initial flag target principal can be
in request? required? distinct from in request? required? distinct from
authenticating principal? authenticating principal?
change password: yes yes no change password: yes yes no
set password: no policy (*) yes set password: no policy (*) yes
set key: no policy (*) yes set key: no policy (*) yes
skipping to change at line 127 skipping to change at page 6, line 9
policy (*): implementations SHOULD allow administrators to set the policy (*): implementations SHOULD allow administrators to set the
initial flag required for set requests policy to either yes or no. initial flag required for set requests policy to either yes or no.
Clients MUST be able to retry set requests that fail due to error 7 Clients MUST be able to retry set requests that fail due to error 7
(initial flag required) with an initial ticket. Clients SHOULD NOT (initial flag required) with an initial ticket. Clients SHOULD NOT
cache service tickets targetted at kadmin/changepw. cache service tickets targetted at kadmin/changepw.
KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted
using the session key from the ticket in the AP-REQ. using the session key from the ticket in the AP-REQ.
The user-data component of the message consists of the following ASN.1 The user-data component of the message consists of the following
encoded structure: ASN.1 encoded structure:
ChangePasswdData :: = SEQUENCE { ChangePasswdData :: = SEQUENCE {
newpasswdorkeys[0] NewPasswdOrKeys, newpasswdorkeys[0] NewPasswdOrKeys,
targname[1] PrincipalName OPTIONAL, targname[1] PrincipalName OPTIONAL,
-- only present in set password/key: the principal -- only present in set password/key: the
-- which will have its password or keys set. Not -- principal which will have its password
-- present in a set request if the client principal -- or keys set. Not present in a set request
-- from the ticket is the principal having its -- if the client principal from the ticket is
-- passwords or keys set. -- the principal having its passwords or keys
-- set.
targrealm[2] Realm OPTIONAL, targrealm[2] Realm OPTIONAL,
-- only present in set password/key: the realm for -- only present in set password/key: the realm
-- the principal which will have its password or -- for the principal which will have its
-- keys set. Not present in a set request if the -- password or keys set. Not present in a set
-- client principal from the ticket is the principal -- request if the client principal from the
-- having its passwords or keys set. -- ticket is the principal having its
-- passwords or keys set.
flags[3] RequestFlags OPTIONAL flags[3] RequestFlags OPTIONAL
-- 32 bit string -- 32 bit string
} }
NewPasswdOrKeys :: = CHOICE { NewPasswdOrKeys :: = CHOICE {
passwords[0] PasswordSequence, -- change/set passwd passwords[0] PasswordSequence, -- chg/set passwd
keyseq[1] KeySequences -- change/set key keyseq[1] KeySequences -- chg/set key
} }
KeySequences :: = SEQUENCE OF KeySequence KeySequences :: = SEQUENCE OF KeySequence
KeySequence :: = SEQUENCE { KeySequence :: = SEQUENCE {
key[0] EncryptionKey, key[0] EncryptionKey,
salt[1] OCTET STRING OPTIONAL, salt[1] OCTET STRING OPTIONAL,
salt-type[2] INTEGER OPTIONAL salt-type[2] INTEGER OPTIONAL
} }
PasswordSequence :: = SEQUENCE { PasswordSequence :: = SEQUENCE {
newpasswd[0] OCTET STRING, newpasswd[0] OCTET STRING,
oldpasswd[1] OCTET STRING OPTIONAL oldpasswd[1] OCTET STRING OPTIONAL
-- oldpasswd always present for change password -- oldpasswd always present for change
-- but not present for set password, set key, or -- password but not present for set
-- change key -- password, set key, or change key
} }
RequestFlags :: = BIT STRING { RequestFlags :: = BIT STRING {
reserved(0), reserved(0),
request-srv-gen-keys(1) -- only in change/set keys request-srv-gen-keys(1)
-- only in change/set keys
-- if the client desires -- if the client desires
-- server to contribute to keys; -- server to contribute to
-- keys;
-- server will return keys -- server will return keys
} }
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 or change the password principal in the ticket is authorized to set/change the password/keys
(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/keys. The server field if present), and decrypt the new password/keys. The server also
also checks whether the initial flag is required for this request, 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 newpasswdorkeys field contains either the new cleartext password The newpasswdorkeys field contains either the new cleartext password
(with the old cleartext password for a change password operation), (with the old cleartext password for a change password operation), or
or a sequence of encryption keys with their respective salts. a sequence of encryption keys with their respective salts.
In the cleartext password case, if the old password is sent in the In the cleartext password case, if the old password is sent in the
request, the request MUST be a change password request. If the old request, the request MUST be a change password request. If the old
password is not present in the request, the request MUST be a set password is not present in the request, the request MUST be a set
password request. The server should apply policy checks to the old password request. The server should apply policy checks to the old
and new password after verifying that the old password is valid. and new password after verifying that the old password is valid. The
The server can check validity by obtaining a key from the old server can check validity by obtaining a key from the old password
password with a keytype that is present in the KDC database for the with a keytype that is present in the KDC database for the user and
user and comparing the keys for equality. The server then generates comparing the keys for equality. The server then generates the
the appropriate keytypes from the password and stores them in the KDC appropriate keytypes from the password and stores them in the KDC
database. If all goes well, status 0x0000 is returned to the client database. If all goes well, status 0x0000 is returned to the client
in the reply message (see below). For a change password operation, in the reply message (see below). For a change password operation,
the initial flag in the service ticket MUST be set. the initial flag in the service ticket MUST be set.
In the key sequence case, the sequence of keys is sent to the change In the key sequence case, the sequence of keys is sent to the change
or set password service (kadmin/changepw or kadmin/setpw respectively). or set password service (kadmin/changepw or kadmin/setpw
For a principal that can act as a server, its preferred keytype should respectively). For a principal that can act as a server, its
be sent as the first key in the sequence, but the KDC is not required preferred keytype should be sent as the first key in the sequence,
to honor this preference. Application servers should use the key but the KDC is not required to honor this preference. Application
sequence option for changing/setting their keys. The change/set password servers should use the key sequence option for changing/setting their
services should check that all keys are in the proper format, returning keys. The change/set password services should check that all keys are
the KRB5_KPASSWD_MALFORMED error otherwise. in the proper format, returning the KRB5_KPASSWD_MALFORMED error
otherwise.
For change/set key, the request message may include the request flags bit For change/set key, the request message may include the request flags
string with the request-srv-gen-keys bit set. In this case, the client bit string with the request-srv-gen-keys bit set. In this case, the
is requesting that the server add entropy to its keys in the KeySequences client is requesting that the server add entropy to its keys in the
field. When using this option, the client SHOULD attempt to generate KeySequences field. When using this option, the client SHOULD attempt
pseudorandom keys with as much entropy as possible in its request. The to generate pseudorandom keys with as much entropy as possible in its
server will return the final key sequence in a KeySequences structure in request. The server will return the final key sequence in a
the edata of the reply message. The server does not store any of the KeySequences structure in the edata of the reply message. The server
new keys at this point. The client MUST make a subsequent change/set does not store any of the new keys at this point. The client MUST
key request without the request-srv-gen-keys bit; if the server returns make a subsequent change/set key request without the request-srv-
KRB5_KPASSWD_SUCCESS for this second request, then the new keys have gen-keys bit; if the server returns KRB5_KPASSWD_SUCCESS for this
been written into the database. A conformant server MUST support this second request, then the new keys have been written into the
option. database. A conformant server MUST support this option.
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 message / / KRB-PRIV message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All 16 bit fields are in network byte 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 0x0002 (network protocol version number: contains the hex constant 0x0002 (network
byte order). (The reply message has the same format as in [4]). byte order). (The reply message has the same format as in the
original Kerberos change password protocol).
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
then the last field contains a KRB-ERROR message instead of a KRB-PRIV zero, then the last field contains a KRB-ERROR message instead of a
message. An implementation should check this field to determine KRB-PRIV message. An implementation should check this field to
whether a KRB-ERROR message or KRB-PRIV message has been returned. determine whether a KRB-ERROR message or KRB-PRIV message has been
returned.
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 from [4]: This KRB-PRIV message must be encrypted using the KRB-PRIV message: This KRB-PRIV message must be encrypted using the
session key from the ticket in the AP-REQ. session key from the ticket in the AP-REQ.
The server will respond with a KRB-PRIV message unless it cannot 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 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.
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 | minor status | | result code | key version (only on success) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key version (only on success) | edata / | result string length | result string /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| edata /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
result code (16 bits) (result codes 0-4 are from [4]): result code (16 bits) (result codes 0-4 are the same as in the
original Kerberos change password protocol):
The result code must have one of the following values (network The result code must have one of the following values (network
byte order): byte order):
KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is KRB5_KPASSWD_SUCCESS 0 request succeeds (This
not allowed in a KRB-ERROR value is not allowed in a
message) KRB-ERROR message)
KRB5_KPASSWD_MALFORMED 1 request fails due to being KRB5_KPASSWD_MALFORMED 1 request fails due to being
malformed malformed
KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" KRB5_KPASSWD_HARDERROR 2 request fails due to "hard"
error in processing the request error in processing the
(for example, there is a resource request (for example, there
or other problem causing the is a resource or other
request to fail) problem 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
authentication processing error in authentication
processing
KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft
error in processing the request error 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_INITIALFLAG_NEEDED 7 initial flag required KRB5_KPASSWD_INITIALFLAG_NEEDED 7 initial flag required
KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails
policy; the result string should policy; the result string
include a text message to be should include a text
presented to the user. message to be presented to
the user.
KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not
(only in response to a set exist (only in response to
password or set key request). a set password or set key
request).
KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
containing at least one etype that is containing at least one etype that
not supported by the KDC. The response is not supported by the KDC. The
edata contains an ASN.1 encoded response edata contains an ASN.1
PKERB-ETYPE-INFO type that specifies encoded PKERB-ETYPE-INFO type that
the etypes that the KDC supports: specifies the etypes that the KDC
supports:
KERB-ETYPE-INFO-ENTRY :: = SEQUENCE { KERB-ETYPE-INFO-ENTRY :: = SEQUENCE
{
encryption-type[0] INTEGER, encryption-type[0] INTEGER,
salt[1] OCTET STRING salt[1] OCTET STRING
OPTIONAL -- not sent, client OPTIONAL -- not sent, client
-- ignores if sent -- ignores if sent
} }
PKERB-ETYPE-INFO ::= SEQUENCE OF PKERB-ETYPE-INFO ::= SEQUENCE OF
KERB-ETYPE-INFO-ENTRY KERB-ETYPE-INFO-ENTRY
The client should retry the request The client should retry the request
using only etypes (keytypes) that are using only etypes (keytypes) that
contained within the PKERB-ETYPE-INFO are contained within the
structure in the previous response. PKERB-ETYPE-INFO structure in the
previous response.
KRB5_KPASSWD_ETYPE_SRVGENKEYS 11 the request has the request- KRB5_KPASSWD_ETYPE_SRVGENKEYS 11 the request has the request-
srv-gen-keys flag set and the srv-gen-keys flag set and the
server is returning the server is returning the
KeySequence structure defined KeySequence structure defined
above in the edata field of the above in the edata field of the
reply. The server returns one key reply. The server returns one
sequence structure of the same key sequence structure of the
keytype for each key sequence same keytype for each key
structure in the client request, sequence structure in the
unless it does not support one of client request, unless it does
the keytypes (or etypes). In that not support one of the keytypes
case, it returns error (or etypes). In that case, it
returns error
KRB5_KPASSWD_ETYPE_NOSUPP as KRB5_KPASSWD_ETYPE_NOSUPP as
discussed above. The server MUST discussed above. The server MUST
add keylength number of bits of add keylength number of bits of
entropy to each key. The assumption entropy to each key. The
here is that the client may have assumption here is that the
added insufficient entropy to the client may have added
request keys. The server SHOULD use insufficient entropy to the
the client key from each request keys. The server SHOULD
use the client key from each
KeySequence structure as input KeySequence structure as input
into the final keyvalue for the into the final keyvalue for the
returned key. returned key.
0xFFFF is returned if the request fails for some other reason. 0xFFFF is returned if the request fails for some other reason.
The client must interpret any non-zero result code as a failure. The client must interpret any non-zero result code as a failure.
minor status (16 bits):
This field contains a minor status code. It can be used to index key version (16 bits - optional):
into a catalog of strings and the indexed string can then be Present if and only if the result
displayed to the user. Additional information on a password
set/change policy failure is one use for this string.
key version (16 bits - optional): present if and only if the result
code is KRB5_KPASSWD_SUCCESS. This contains the key version of code is KRB5_KPASSWD_SUCCESS. This contains the key version of
the new key(s). the new key(s).
edata: used to convey additional information as defined by the
result string length (16 bits):
Gives the length of the following result string field, in bytes.
If the result string is not present, the length is zero.
result string (optional):
This field is a UTF-8 encoded string which can be displayed
to the user. Specific reasons for a password set/change policy
failure is one possible use for this string.
edata (optional):
Used to convey additional information as defined by the
result code. result code.
4. Acknowledgements 5. Acknowledgements
The authors thank Tony Andrea for his input to the document. The authors thank Ken Raeburn, Sam Hartman, Tony Andrea, and other
participants from the IETF Kerberos Working Group for their input to
the document.
5. References 6. Security Considerations
Password policies should be enforced to make sure that users do not
pick passwords (for change password/key) that are vulnerable to brute
force password guessing attacks.
7. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
[3] J. Kohl, C. Neuman. The Kerberos Network Authentication [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5), Request for Comments 1510. Service (V5), Request for Comments 1510.
[4] M. Horowitz. Kerberos Change Password Protocol, 8. Expiration Date
ftp://ds.internic.net/internet-drafts/
draft-ietf-cat-kerb-chg-password-02.txt
6. Expiration Date
This draft expires on September 30th, 2001. This draft expires on October 31st, 2001.
7. Authors' Addresses 9. 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
Mike Swift Mike Swift
University of Washington University of Washington
Seattle, WA Seattle, WA
Email: mikesw@cs.washington.edu Email: mikesw@cs.washington.edu
John Brezak John Brezak
Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Email: jbrezak@microsoft.com Email: jbrezak@microsoft.com
Bill Gossman Bill Gossman
Cybersafe Corporation Cisco Systems
1605 NW Sammamish Rd. 500 108th Ave. NE, Suite 500
Issaquah, WA 98027-5378 Bellevue, WA 98004
Email: bill.gossman@cybersafe.com Email: bgossman@cisco.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
 End of changes. 56 change blocks. 
156 lines changed or deleted 333 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/