draft-ietf-cat-kerberos-set-passwd-05.txt   draft-ietf-cat-kerberos-set-passwd-06.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Network Working Group Jonathan Trostle Network Working Group Jonathan Trostle
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Category: Standards Track Mike Swift Category: Standards Track Mike Swift
University of WA University of WA
John Brezak John Brezak
Microsoft Microsoft
Bill Gossman Bill Gossman
Cisco Systems Cisco Systems
Kerberos Set/Change Password: Version 2 Kerberos Set/Change Password: Version 2
<draft-ietf-cat-kerberos-set-passwd-05.txt> <draft-ietf-cat-kerberos-set-passwd-06.txt>
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 [6]. 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 Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "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.
This draft expires on October 31st, 2001. Please send comments to the This draft expires on December 31st, 2001. Please send comments to
authors. the authors.
1. Abstract 1. Abstract
This proposal specifies a Kerberos (RFC 1510 [3]) change/set password This proposal specifies a Kerberos (RFC 1510 [3]) change/set password
protocol and a Kerberos change/set key protocol. The protocol protocol and a Kerberos change/set key protocol. The protocol
consists of a single request and reply message. The request message consists of a single request and reply message. The request message
includes both AP_REQ and KRB_PRIV submessages; the new password is includes both AP-REQ and KRB-PRIV submessages; the new password is
contained in the KRB_PRIV submessage which is encrypted in the contained in the KRB-PRIV submessage which is encrypted in the
session key from the ticket. The original Kerberos change password subsession key from the AP-REQ. The original Kerberos change password
protocol did not allow for an administrator to set a password for a protocol did not allow for an administrator to set a password for a
new user. This functionality is useful in some environments, and this new user. This functionality is useful in some environments, and this
proposal allows password setting as well as password changing. The proposal allows password setting as well as password changing. The
protocol includes fields in the request message to indicate the protocol includes fields in the request message to indicate the
principal which is having its password set. We also extend the principal which is having its password set. We also extend the
set/change protocol to allow a client to send a sequence of keys to 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 the KDC instead of a cleartext password. If in the cleartext password
case, the cleartext password fails to satisfy password policy, the case, the cleartext password fails to satisfy password policy, the
server should use the result code KRB5_KPASSWD_POLICY_REJECT. server should use the result code KRB5_KPASSWD_POLICY_REJECT.
skipping to change at page 4, line 6 skipping to change at page 4, line 6
enc-part [2] EncryptedData enc-part [2] EncryptedData
} }
EncAPRepPart ::= [APPLICATION 27] SEQUENCE { EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime, ctime [0] KerberosTime,
cusec [1] INTEGER, cusec [1] INTEGER,
subkey [2] EncryptionKey OPTIONAL, subkey [2] EncryptionKey OPTIONAL,
seq-number [3] INTEGER OPTIONAL seq-number [3] INTEGER OPTIONAL
} }
Here is the syntax of the KRB_ERROR message: Here is the syntax of the KRB-ERROR message:
KRB-ERROR ::= [APPLICATION 30] SEQUENCE { KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno[0] INTEGER, pvno[0] INTEGER,
msg-type[1] INTEGER, msg-type[1] INTEGER,
ctime[2] KerberosTime OPTIONAL, ctime[2] KerberosTime OPTIONAL,
cusec[3] INTEGER OPTIONAL, cusec[3] INTEGER OPTIONAL,
stime[4] KerberosTime, stime[4] KerberosTime,
susec[5] INTEGER, susec[5] INTEGER,
error-code[6] INTEGER, error-code[6] INTEGER,
crealm[7] Realm OPTIONAL, crealm[7] Realm OPTIONAL,
cname[8] PrincipalName OPTIONAL, cname[8] PrincipalName OPTIONAL,
realm[9] Realm, -- Correct realm realm[9] Realm, -- Correct realm
sname[10] PrincipalName, -- Correct name sname[10] PrincipalName, -- Correct name
e-text[11] GeneralString OPTIONAL, e-text[11] GeneralString OPTIONAL,
e-data[12] OCTET STRING OPTIONAL e-data[12] OCTET STRING OPTIONAL
} }
The KRB_PRIV message is used to send the request and reply data: The KRB-PRIV message is used to send the request and reply data:
KRB-PRIV ::= [APPLICATION 21] SEQUENCE { KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno[0] INTEGER, pvno[0] INTEGER,
msg-type[1] INTEGER, msg-type[1] INTEGER,
enc-part[3] EncryptedData enc-part[3] EncryptedData
} }
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data[0] OCTET STRING, user-data[0] OCTET STRING,
timestamp[1] KerberosTime OPTIONAL, timestamp[1] KerberosTime OPTIONAL,
skipping to change at page 5, line 13 skipping to change at page 5, line 13
This requirement is consistent with the TCP transport header in This requirement is consistent with the TCP transport header in
1510bis. 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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 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). byte order).
AP-REQ length: length of AP-REQ data, in bytes. If the length is 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 zero, then the last field contains a KRB-ERROR message instead of a
KRB-PRIV 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. The authenticator in the
passwords/keys, it is not required that the initial flag be set in AP-REQ MUST contain a subsession key (which will be used to encrypt
the Kerberos service ticket. The initial flag is required for change the KRB-PRIV user data field - see below). The KDC may have stronger
requests, but not for set requests. We have the following pseudorandom generating capability then the clients; thus, the client
definitions: SHOULD use the session key as an input (along with additional locally
pseudorandom generated bits) into the generation of the subsession
key. 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 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 page 5, line 51 skipping to change at page 6, line 4
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
change key: no yes no change key: no yes no
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 subsession key from the authenticator in the AP-REQ. The
authenticator MUST contain a subsession key. The timestamp and usec
fields of the KRB-PRIV message MUST be present, and the data values
MUST be copies of the same data values from the authenticator. The
recipient should ignore the sender address field in the KRB-PRIV
message.
The user-data component of the message consists of the following The user-data component of the message contains the DER encoding of
ASN.1 encoded structure: the ChangePasswdData ASN.1 type described below:
ChangePasswdData :: = SEQUENCE { ChangePasswdData :: = SEQUENCE {
newpasswdorkeys[0] NewPasswdOrKeys, passwds [0] PasswordSequence OPTIONAL,
targname[1] PrincipalName OPTIONAL, keys [1] KeySequences OPTIONAL,
-- exactly one of the above two will be
-- present, else KRB5_KPASSWD_MALFORMED
-- error will be returned by the server.
targname[2] PrincipalName OPTIONAL,
-- only present in set password/key: the -- only present in set password/key: the
-- principal which will have its password -- principal which will have its password
-- or keys set. Not present in a set request -- or keys set. Not present in a set request
-- if the client principal from the ticket is -- if the client principal from the ticket is
-- the principal having its passwords or keys -- the principal having its passwords or keys
-- set. -- set.
targrealm[2] Realm OPTIONAL, targrealm[3] Realm OPTIONAL,
-- only present in set password/key: the realm -- only present in set password/key: the realm
-- for the principal which will have its -- for the principal which will have its
-- password or keys set. Not present in a set -- password or keys set. Not present in a set
-- request if the client principal from the -- request if the client principal from the
-- ticket is the principal having its -- ticket is the principal having its
-- passwords or keys set. -- passwords or keys set.
flags[3] RequestFlags OPTIONAL flags[4] RequestFlags OPTIONAL
-- 32 bit string -- 32 bit string
} }
NewPasswdOrKeys :: = CHOICE { KeySequences ::= SEQUENCE (SIZE (1..MAX)) OF KeySequence
passwords[0] PasswordSequence, -- chg/set passwd
keyseq[1] KeySequences -- chg/set key
}
KeySequences :: = SEQUENCE OF KeySequence
KeySequence :: = SEQUENCE { KeySequence :: = SEQUENCE {
key[0] EncryptionKey, key[0] EncryptionKey,
salt[1] OCTET STRING OPTIONAL, salt[1] OCTET STRING OPTIONAL,
-- depends on enc type, not currently used
salt-type[2] INTEGER OPTIONAL salt-type[2] INTEGER OPTIONAL
-- depends on enc type, not currently used
} }
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 -- oldpasswd always present for change
-- password but not present for set -- password but not present for set
-- password, set key, or change key -- password, set key, or change key
-- NOTE: the passwords are UTF8 strings.
} }
RequestFlags :: = BIT STRING { RequestFlags ::= BIT STRING (SIZE (32..MAX))
reserved(0), -- reserved(0)
request-srv-gen-keys(1) -- request-srv-gen-keys(1)
-- only in change/set keys -- only in change/set keys
-- if the client desires -- if the client desires
-- server to contribute to -- server to contribute to
-- keys; -- 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/change the password/keys 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 also field if present), and decrypt the new password/keys. The server 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 If the passwds field is present, it contains the new cleartext
(with the old cleartext password for a change password operation), or password (with the old cleartext password for a change password
a sequence of encryption keys with their respective salts. operation). Otherwise the keys field is present, and it contains a
sequence of encryption keys.
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. The and new password after verifying that the old password is valid. The
server can check validity by obtaining a key from the old password 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 with a keytype that is present in the KDC database for the user and
comparing the keys for equality. The server then generates the comparing the keys for equality. The server then generates 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 or set password service (kadmin/changepw or kadmin/setpw
respectively). For a principal that can act as a server, its respectively). For a principal that can act as a server, its
preferred keytype should be sent as the first key in the sequence, preferred keytype should be sent as the first key in the sequence,
but the KDC is not required to honor this preference. Application but the KDC is not required to honor this preference. Application
servers should use the key sequence option for changing/setting their servers SHOULD use the key sequence option for changing/setting their
keys. The change/set password services should check that all keys are keys. The change/set password services should check that all keys are
in the proper format, returning the KRB5_KPASSWD_MALFORMED error in the proper format, returning the KRB5_KPASSWD_MALFORMED error
otherwise. otherwise.
For change/set key, the request message may include the request flags For change/set key, the request message may include the request flags
bit string with the request-srv-gen-keys bit set. In this case, the bit string with the request-srv-gen-keys bit set. In this case, the
client is requesting that the server add entropy to its keys in the client is requesting that the server add entropy to its keys in the
KeySequences field. When using this option, the client SHOULD attempt KeySequences field. When using this option, the client SHOULD attempt
to generate pseudorandom keys with as much entropy as possible in its to generate pseudorandom keys with as much entropy as possible in its
request. The server will return the final key sequence in a request. The server will return the final key sequence in a
skipping to change at page 8, line 12 skipping to change at page 8, line 25
second request, then the new keys have been written into the second request, then the new keys have been written into the
database. A conformant server MUST support this 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 the byte order). (The reply message has the same format as in the
original Kerberos change password protocol). original Kerberos change password protocol).
AP-REP length: length of AP-REP data, in bytes. If the length is 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 zero, then the last field contains a KRB-ERROR message instead of a
KRB-PRIV message. An implementation should check this field to KRB-PRIV message. An implementation should check this field to
determine whether a KRB-ERROR message or KRB-PRIV message has been determine whether a KRB-ERROR message or KRB-PRIV message has been
returned. 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. The subkey MUST be present in the AP-REP message.
KRB-PRIV message: 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. subkey from the AP-REP message. The client should ignore the sender
address (the server's address) in the KRB-PRIV message. Reflection
attacks are prevented since the subkey is used to encrypt the user-
data field of the KRB-PRIV message. The timestamp and usec fields of
the KRB-PRIV message MUST be present, and the data values MUST be
copies of the same data values from the AP-REP message.
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
skipping to change at page 9, line 33 skipping to change at page 10, line 4
KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft
error in processing the error in processing the
request 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 policy; the result string
should include a text should include a text
message to be presented to message to be presented to
the user. the user.
KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not KRB5_KPASSWD_WRONG_SRV 9 policy failure: the client
sent change/set key and
should have sent change/set
passwd, or vice-versa.
KRB5_KPASSWD_BAD_PRINCIPAL 10 target principal does not
exist (only in response to exist (only in response to
a set password or set key a set password or set key
request). request).
KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence KRB5_KPASSWD_ETYPE_NOSUPP 11 the request contains a key sequence
containing at least one etype that containing at least one etype that
is not supported by the KDC. The is not supported by the KDC. The
response edata contains an ASN.1 response edata contains an ASN.1
encoded PKERB-ETYPE-INFO type that DER encoded PKERB-ETYPE-INFO type
specifies the etypes that the KDC that specifies the etypes that the
supports: 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 -- may ignore 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 using only etypes (keytypes) that
are contained within the are contained within the
PKERB-ETYPE-INFO structure in the PKERB-ETYPE-INFO structure in the
previous response. previous response.
KRB5_KPASSWD_ETYPE_SRVGENKEYS 11 the request has the request- KRB5_KPASSWD_ETYPE_SRVGENKEYS 12 See the following paragraph.
srv-gen-keys flag set and the
server is returning the The KRB5_KPASSWD_ETYPE_SRVGENKEYS result code is returned when
KeySequence structure defined the request has the request-srv-gen-keys flag set and the
above in the edata field of the server is returning the KeySequences structure defined above in
reply. The server returns one the edata field of the reply. The server returns one key sequence
key sequence structure of the structure of the same keytype for each key sequence structure in
same keytype for each key the client request, unless it does not support one of the
sequence structure in the keytypes (or etypes). In that case, it returns error
client request, unless it does KRB5_KPASSWD_ETYPE_NOSUPP as discussed above. The server MUST
not support one of the keytypes add keylength number of bits of entropy to each key, where
(or etypes). In that case, it keylength is the number of actual key bits in the key (minus
returns error any parity or non-entropy contributing bits). The assumption
KRB5_KPASSWD_ETYPE_NOSUPP as here is that the client may have added insufficient entropy
discussed above. The server MUST to the request keys. The server SHOULD use the client key from
add keylength number of bits of each KeySequence structure as input into the final keyvalue for
entropy to each key. The the returned key. The client MUST make another request after
assumption here is that the receiving a reply with this status, since no keys have been
client may have added written into the database.
insufficient entropy to the
request keys. The server SHOULD
use the client key from each
KeySequence structure as input
into the final keyvalue for the
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.
key version (16 bits - optional): key version (16 bits - optional):
Present if and only if the result 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).
result string length (16 bits): result string length (16 bits):
skipping to change at page 11, line 11 skipping to change at page 11, line 36
This field is a UTF-8 encoded string which can be displayed This field is a UTF-8 encoded string which can be displayed
to the user. Specific reasons for a password set/change policy to the user. Specific reasons for a password set/change policy
failure is one possible use for this string. failure is one possible use for this string.
edata (optional): edata (optional):
Used to convey additional information as defined by the Used to convey additional information as defined by the
result code. result code.
5. Acknowledgements 5. Acknowledgements
The authors thank Ken Raeburn, Sam Hartman, Tony Andrea, and other The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony
participants from the IETF Kerberos Working Group for their input to Andrea, Nicolas Williams, and other participants from the IETF
the document. Kerberos Working Group for their input to the document.
6. Security Considerations 6. Security Considerations
Password policies should be enforced to make sure that users do not Password policies should be enforced to make sure that users do not
pick passwords (for change password/key) that are vulnerable to brute pick passwords (for change password/key) that are vulnerable to brute
force password guessing attacks. force password guessing attacks.
7. References 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.
8. Expiration Date 8. Expiration Date
This draft expires on October 31st, 2001. This draft expires on December 31st, 2001.
9. 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
 End of changes. 32 change blocks. 
75 lines changed or deleted 90 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/