draft-ietf-cat-kerberos-set-passwd-03.txt   draft-ietf-cat-kerberos-set-passwd-04.txt 
INTERNET-DRAFT Mike Swift INTERNET-DRAFT Mike Swift
draft-ietf-cat-kerberos-set-passwd-03.txt Microsoft draft-ietf-cat-kerberos-set-passwd-04.txt University of WA
April 2000 Jonathan Trostle March 2001 Jonathan Trostle
Cisco Systems Cisco Systems
John Brezak John Brezak
Microsoft Microsoft
Bill Gossman Bill Gossman
Cybersafe Cybersafe
Kerberos Set/Change Password: Version 2 Kerberos Set/Change Password: Version 2
0. Status Of This Memo 0. Status Of This Memo
skipping to change at line 37 skipping to change at line 37
"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 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 draft expires on September 30th, 2001.
1. Abstract 1. Abstract
The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]),
does not allow for an administrator to set a password for a new user. does not allow for an administrator to set a password for a new user.
This functionality is useful in some environments, and this proposal This functionality is useful in some environments, and this proposal
extends [4] to allow password setting. The changes are: adding new extends [4] to allow password setting. The changes are: adding new
fields to the request message to indicate the principal which is fields to the request message to indicate the principal which is
having its password set, not requiring the initial flag in the service having its password set, not requiring the initial flag in the service
ticket, using a new protocol version number, and adding three new ticket, using a new protocol version number, and adding three new
skipping to change at line 63 skipping to change at line 64
code KRB5_KPASSWD_POLICY_REJECT. 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 document are to be interpreted as described in RFC-2119 [2]. this document are to be interpreted as described in RFC-2119 [2].
3. The Protocol 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.
Request Message Request Message
skipping to change at line 100 skipping to change at line 101
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 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 [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. The ticket in the AP-REQ principal identifier is kadmin/setpw@REALM. To enable setting of
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 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, Kerberos service ticket. The initial flag is required for change requests,
but not for set requests. We have the following definitions: 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
skipping to change at line 117 skipping to change at line 117
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 generated KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted
using the subkey from the authenticator in the AP-REQ data. 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 ASN.1
structure encoded as an OCTET STRING: 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 principal
-- which will have its password or keys set. Not -- which will have its password or keys set. Not
-- present in a set request if the client principal -- present in a set request if the client principal
-- from the ticket is the principal having its -- from the ticket is the principal having its
-- passwords or keys set. -- 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 for
-- the principal which will have its password or -- the principal which will have its password or
-- keys set. Not present in a set request if the -- keys set. Not present in a set request if the
-- client principal from the ticket is the principal -- client principal from the ticket is the principal
-- having its passwords or keys set. -- having its passwords or keys set.
flags[3] RequestFlags OPTIONAL
-- 32 bit string
} }
NewPasswdOrKeys :: = CHOICE { NewPasswdOrKeys :: = CHOICE {
passwords[0] PasswordSequence, -- change/set passwd passwords[0] PasswordSequence, -- change/set passwd
keyseq[1] KeySequences -- change/set key keyseq[1] KeySequences -- change/set key
} }
KeySequences :: = SEQUENCE OF KeySequence KeySequences :: = SEQUENCE OF KeySequence
KeySequence :: = SEQUENCE { KeySequence :: = SEQUENCE {
skipping to change at line 157 skipping to change at line 160
keyseq[1] KeySequences -- change/set key keyseq[1] KeySequences -- change/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 password
-- but not present for set password, set key, or -- but not present for set password, set key, or
-- change key -- change key
} }
RequestFlags :: = BIT STRING {
reserved(0),
request-srv-gen-keys(1) -- only in change/set keys
-- if the client desires
-- server to contribute to 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 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/keys. The server field if present), and decrypt the new password/keys. The server
also 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.
skipping to change at line 202 skipping to change at line 212
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 respectively).
For a principal that can act as a server, its preferred keytype should 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 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 to honor this preference. Application servers should use the key
sequence option for changing/setting their keys. The change/set password sequence option for changing/setting their keys. The change/set password
services should check that all keys are in the proper format, returning services should check that all keys are in the proper format, returning
the KRB5_KPASSWD_MALFORMED error otherwise. the KRB5_KPASSWD_MALFORMED error otherwise.
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 client
is requesting that the server add entropy to its keys in the KeySequences
field. When using this option, the client SHOULD attempt to generate
pseudorandom keys with as much entropy as possible in its request. The
server will return the final key sequence in a KeySequences structure in
the edata of the reply message. The server does not store any of the
new keys at this point. The client MUST make a subsequent change/set
key request without the request-srv-gen-keys bit; if the server returns
KRB5_KPASSWD_SUCCESS for this second request, then the new keys have
been written into the 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 /
skipping to change at line 224 skipping to change at line 247
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 [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. An implementation should check this field to 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 generated using the KRB-PRIV from [4]: This KRB-PRIV message must be encrypted using the
subkey in the authenticator in the AP-REQ data. 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. NOTE: Unlike change password version respond with a KRB-ERROR message.
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 | minor status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| edata / | key version (only on success) | edata /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
result code (16 bits) (result codes 0-4 are from [4]): result code (16 bits) (result codes 0-4 are from [4]):
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 not
allowed in a KRB-ERROR message) KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is
KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed not allowed in a KRB-ERROR
KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in message)
processing the request (for example, KRB5_KPASSWD_MALFORMED 1 request fails due to being
there is a resource or other problem malformed
causing the request to fail)
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 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
in processing the request KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft
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_INITIAL_FLAG_NEEDED 7 initial flag required
KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy; KRB5_KPASSWD_INITIALFLAG_NEEDED 7 initial flag required
the result string should include a text message to be presented
to the user. 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 KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist
(only in response to a set password request). (only in response to 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 not supported by the KDC. containing at least one etype that is
The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO not supported by the KDC. The response
type that specifies the etypes that the KDC supports: edata contains an ASN.1 encoded
PKERB-ETYPE-INFO type that 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 OPTIONAL -- not sent salt[1] OCTET STRING
OPTIONAL -- not sent, client
-- ignores if sent
} }
PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY PKERB-ETYPE-INFO ::= SEQUENCE OF
KERB-ETYPE-INFO-ENTRY
The client should retry the request using only etypes (keytypes) The client should retry the request
that are contained within the PKERB-ETYPE-INFO structure in the using only etypes (keytypes) that are
previous response. contained within the PKERB-ETYPE-INFO
0xFFFF if the request fails for some other reason. structure in the previous response.
KRB5_KPASSWD_ETYPE_SRVGENKEYS 11 the request has the request-
srv-gen-keys flag set and the
server is returning the
KeySequence structure defined
above in the edata field of the
reply. The server returns one key
sequence structure of the same
keytype for each key sequence
structure in the client request,
unless it does not support one of
the keytypes (or etypes). In that
case, it returns error
KRB5_KPASSWD_ETYPE_NOSUPP as
discussed above. The server MUST
add keylength number of bits of
entropy to each key. The assumption
here is that the client may have
added 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.
The client must interpret any non-zero result code as a failure. The client must interpret any non-zero result code as a failure.
result string - from [4]: minor status (16 bits):
This field is a UTF-8 encoded string which should be displayed This field contains a minor status code. It can be used to index
to the user by the client. Specific reasons for a password into a catalog of strings and the indexed string can then be
displayed to the user. Additional information on a password
set/change policy failure is one use for this string. 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
the new key(s).
edata: used to convey additional information as defined by the edata: used to convey additional information as defined by the
result code. result code.
4. Acknowledgements 4. Acknowledgements
The authors thank Tony Andrea for his input to the document. The authors thank Tony Andrea for his input to the document.
5. References 5. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
skipping to change at line 313 skipping to change at line 386
[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, [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
6. Expiration Date 6. Expiration Date
This draft expires in October 2000. This draft expires on September 30th, 2001.
7. Authors' Addresses 7. 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
1 Microsoft Way University of Washington
Redmond, WA 98052 Seattle, WA
Email: mikesw@microsoft.com Email: mikesw@cs.washington.edu
John Brezak John Brezak
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 Cybersafe Corporation
1605 NW Sammamish Rd. 1605 NW Sammamish Rd.
Issaquah, WA 98027-5378 Issaquah, WA 98027-5378
 End of changes. 29 change blocks. 
48 lines changed or deleted 121 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/