draft-ietf-cat-kerberos-set-passwd-02.txt   draft-ietf-cat-kerberos-set-passwd-03.txt 
INTERNET-DRAFT Mike Swift INTERNET-DRAFT Mike Swift
draft-ietf-cat-kerberos-set-passwd-02.txt Microsoft draft-ietf-cat-kerberos-set-passwd-03.txt Microsoft
March 2000 Jonathan Trostle April 2000 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 96 skipping to change at line 96
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 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]) The AP-REQ message must be for the service AP-REQ data: (see [3]) For a change password/key request, the AP-REQ
principal kadmin/changepw@REALM, where REALM is the REALM of the user message service ticket sname, srealm principal identifier is
who wishes to change/set his password. The ticket in the AP-REQ must kadmin/changepw@REALM where REALM is the realm of the change password
service. The same applies to a set password/key request except the
principal identifier is kadmin/setpw@REALM. The ticket in the AP-REQ
must include a subkey in the Authenticator. 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 password 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
set password: no no yes set password: no policy (*) yes
set key: no policy (*) yes
change key: no yes no
policy (*): implementations SHOULD allow administrators to set the
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
(initial flag required) with an initial ticket. Clients SHOULD NOT
cache service tickets targetted at kadmin/changepw.
set key: no policy yes
determined
KRB-PRIV message (see [3]) This KRB-PRIV message must be generated KRB-PRIV message (see [3]) This KRB-PRIV message must be generated
using the subkey from the authenticator in the AP-REQ data. using the subkey from the authenticator in the AP-REQ data.
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: structure encoded as an OCTET STRING:
ChangePasswdData :: = SEQUENCE { ChangePasswdData :: = SEQUENCE {
newpasswdorkeys[0] NewPasswdOrKeys, newpasswdorkeys[0] NewPasswdOrKeys,
targname[1] PrincipalName OPTIONAL, targname[1] PrincipalName OPTIONAL,
-- only present in set password: the principal -- only present in set password/key: the principal
-- which will have its password set -- which will have its password or keys set. Not
-- present in a set request if the client principal
-- from the ticket is the principal having its
-- passwords or keys set.
targrealm[2] Realm OPTIONAL, targrealm[2] Realm OPTIONAL,
-- only present in set password: the realm for -- only present in set password/key: the realm for
-- the principal which will have its password set -- the principal which will have its password or
-- keys set. Not present in a set request if the
-- client principal from the ticket is the principal
-- having its passwords or keys set.
} }
NewPasswdOrKeys :: = CHOICE { NewPasswdOrKeys :: = CHOICE {
passwords[0] PasswordSequence, passwords[0] PasswordSequence, -- change/set passwd
keyseq[1] KeySequences 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 -- but not present for set password, set key, or
-- change key
} }
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.
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 a sequence of encryption keys with their respective salts. or 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 is defined to be a change password request. If request, the request MUST be a change password request. If the old
the old password is not present in the request, the request is 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 server can check validity by obtaining a key from the old 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 password with a keytype that is present in the KDC database for the
user and comparing the keys for equality. The server then generates user and comparing the keys for equality. The server then generates
the appropriate keytypes from the password and stores them in the KDC the 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 set In the key sequence case, the sequence of keys is sent to the change
password service. For a principal that can act as a server, its or set password service (kadmin/changepw or kadmin/setpw respectively).
preferred keytype should be sent as the first key in the sequence, For a principal that can act as a server, its preferred keytype should
but the KDC is not required to honor this preference. Application be sent as the first key in the sequence, but the KDC is not required
servers should use the key sequence option for changing/setting their to honor this preference. Application servers should use the key
keys. The set password service should check that all keys are in the sequence option for changing/setting their keys. The change/set password
proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise. services 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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 277 skipping to change at line 294
previous response. previous response.
0xFFFF if the request fails for some other reason. 0xFFFF 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]: result string - from [4]:
This field is a UTF-8 encoded string which should be displayed This field is a UTF-8 encoded string which should be displayed
to the user by the client. Specific reasons for a password to the user by the client. Specific reasons for a password
set/change policy failure is one use for this string. set/change policy failure is one use for this string.
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. References 4. Acknowledgements
The authors thank Tony Andrea for his input to the document.
5. 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, [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
5. Expiration Date 6. Expiration Date
This draft expires in September 2000. This draft expires in October 2000.
6. 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 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
 End of changes. 15 change blocks. 
30 lines changed or deleted 50 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/