From bb0a23547eaef3b3aa9488e8af4b390c3b94043f Mon Sep 17 00:00:00 2001
From: Assar Westerlund <assar@sics.se>
Date: Sun, 20 Feb 2000 22:20:49 +0000
Subject: [PATCH] new stuff
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@7970 ec53bebd-3082-4978-b11e-865c3cabbd6b
---
.../draft-ietf-cat-kerberos-extra-tgt-02.txt | 174 ++++++++++
.../draft-ietf-cat-kerberos-set-passwd-01.txt | 321 ++++++++++++++++++
2 files changed, 495 insertions(+)
create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt
create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-set-passwd-01.txt
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt b/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt
new file mode 100644
index 000000000..b3ec336b6
--- /dev/null
+++ b/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt
@@ -0,0 +1,174 @@
+INTERNET-DRAFT Jonathan Trostle
+draft-ietf-cat-kerberos-extra-tgt-02.txt Cisco Systems
+Updates: RFC 1510 Michael M. Swift
+expires January 30, 2000 University of WA
+
+
+ Extension to Kerberos V5 For Additional Initial Encryption
+
+0. Status Of This Memo
+
+ This document is an Internet-Draft and is in full conformance
+ with all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet-
+ Drafts as reference material or to cite them other than as
+ "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+1. Abstract
+
+ This document defines an extension to the Kerberos protocol
+ specification (RFC 1510) [1] to enable a preauthentication field in
+ the AS_REQ message to carry a ticket granting ticket. The session
+ key from this ticket granting ticket will be used to
+ cryptographically strengthen the initial exchange in either the
+ conventional Kerberos V5 case or in the case the user stores their
+ encrypted private key on the KDC [2].
+
+
+2. Motivation
+
+ In Kerberos V5, the initial exchange with the KDC consists of the
+ AS_REQ and AS_REP messages. For users, the encrypted part of the
+ AS_REP message is encrypted in a key derived from a password.
+ Although a password policy may be in place to prevent dictionary
+ attacks, brute force attacks may still be a concern due to
+ insufficient key length.
+
+ This draft specifies an extension to the Kerberos V5 protocol to
+ allow a ticket granting ticket to be included in an AS_REQ message
+ preauthentication field. The session key from this ticket granting
+ ticket will be used to cryptographically strengthen the initial
+
+ exchange in either the conventional Kerberos V5 case or in the case
+ the user stores their encrypted private key on the KDC [2]. The
+ session key from the ticket granting ticket is combined with the
+ user password key (key K2 in the encrypted private key on KDC
+ option) using HMAC to obtain a new triple des key that is used in
+ place of the user key in the initial exchange. The ticket granting
+ ticket could be obtained by the workstation using its host key.
+
+3. The Extension
+
+ The following new preauthentication type is proposed:
+
+ PA-EXTRA-TGT 22
+
+ The preauthentication-data field contains a ticket granting ticket
+ encoded as an ASN.1 octet string. The server realm of the ticket
+ granting ticket must be equal to the realm in the KDC-REQ-BODY of
+ the AS_REQ message. In the absence of a trust relationship, the
+ local Kerberos client should send the AS_REQ message without this
+ extension.
+
+ In the conventional (non-pkinit) case, we require the RFC 1510
+ PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message.
+ If neither it or the PA-PK-KEY-REQ preauthentication field is
+ included in the AS_REQ message, the KDC will reply with a
+ KDC_ERR_PREAUTH_FAILED error message.
+
+ We propose the following new etypes:
+
+ des3-cbc-md5-xor 16
+ des3-cbc-sha1-xor 17
+
+ The encryption key is obtained by:
+
+ (1) Obtaining an output M from the HMAC-SHA1 function [3] using
+ the user password key (the key K2 in the encrypted private
+ key on KDC option of pkinit) as the text and the triple des
+ session key as the K input in HMAC:
+
+ M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1.
+
+ The session key from the accompanying ticket granting ticket
+ must be a triple des key when one of the triple des xor
+ encryption types is used.
+ (2) Concatenate the output M (20 bytes) with the first 8 non-parity
+ bits of the triple-des ticket granting ticket session key to
+ get 168 bits that will be used for the new triple-des encryption
+ key.
+ (3) Set the parity bits of the resulting key.
+
+ The resulting triple des key is used to encrypt the timestamp
+ for the PA-ENC-TIMESTAMP preauthentication value (or in the
+ encrypted private key on KDC option of pkinit, it is used in
+ place of the key K2 to both sign in the PA-PK-KEY-REQ and for
+ encryption in the PA-PK-KEY-REP preauthentication types).
+
+ If the KDC decrypts the encrypted timestamp and it is not within
+ the appropriate clock skew period, the KDC will reply with the
+ KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if
+ the above ticket granting ticket fails to decrypt properly, or if
+ it is not a valid ticket.
+
+ The KDC will create the shared triple des key from the ticket
+ granting ticket session key and the user password key (the key K2
+ in the encrypted private key on KDC case) using HMAC as specified
+ above and use it to validate the AS_REQ message and then to
+ encrypt the encrypted part of the AS_REP message (use it in place
+ of the key K2 for encryption in the PA-PK-KEY-REP preauthentication
+ field).
+
+ Local workstation policy will determine the exact behaviour of
+ the Kerberos client with respect to the extension protocol. For
+ example, the client should consult policy to decide when to use
+ use the extension. This policy could be dependent on the user
+ identity, or whether the workstation is in the same realm as the
+ user. One possibility is for the workstation logon to fail if
+ the extension is not used. Another possibility is for the KDC
+ to set a flag in tickets issued when this extension is used.
+
+ A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a
+ preauthentication field containing a ticket granting ticket,
+ a randomly generated subkey encrypted in the session key from
+ the ticket, and a timestamp structure encrypted in the user
+ password and then the randomly generated subkey was proposed.
+ Some advantages of the current proposal are that the KDC has two
+ fewer decryptions to perform per request and the client does not
+ have to generate a random key.
+
+4. Bibliography
+
+ [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
+ Service (V5). Request for Comments 1510.
+
+ [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle.
+ Public Key Cryptography for Initial Authentication in Kerberos.
+ ftp://ds.internic.net/internet-drafts/
+ draft-ietf-cat-kerberos-pkinit-08.txt
+
+ [3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for
+ Message Authentication. Request for Comments 2104.
+
+ [4] J. Pato. Using Pre-authentication to Avoid Password Guessing
+ Attacks. OSF DCE SIG Request for Comments 26.0.
+
+5. Acknowledgement: We thank Ken Hornstein for some helpful comments.
+
+6. Expires January 30, 2000.
+
+7. Authors' Addresses
+
+ Jonathan Trostle
+ 170 W. Tasman Dr.
+ San Jose, CA 95134, U.S.A.
+
+ Email: jtrostle@cisco.com
+ Phone: (408) 527-6201
+
+ Michael Swift
+ Email: mikesw@cs.washington.edu
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-01.txt b/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-01.txt
new file mode 100644
index 000000000..68892ac45
--- /dev/null
+++ b/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-01.txt
@@ -0,0 +1,321 @@
+
+INTERNET-DRAFT Mike Swift
+draft-ietf-cat-kerberos-set-passwd-01.txt Microsoft
+February 2000 Jonathan Trostle
+ Cisco Systems
+ John Brezak
+ Microsoft
+ Bill Gossman
+ Cybersafe
+
+ Kerberos Set/Change Password: Version 2
+
+
+0. Status Of This Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026 [1].
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet-
+ Drafts as reference material or to cite them other than as
+ "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Comments and suggestions on this document are encouraged. Comments
+ on this document should be sent to the CAT working group discussion
+ list:
+ ietf-cat-wg@stanford.edu
+
+1. Abstract
+
+ The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]),
+ does not allow for an administrator to set a password for a new user.
+ This functionality is useful in some environments, and this proposal
+ extends [4] to allow password setting. The changes are: adding new
+ fields to the request message to indicate the principal which is
+ having its password set, not requiring the initial flag in the service
+ ticket, using a new protocol version number, and adding three new
+ result codes. We also extend the set/change protocol to allow a
+ client to send a sequence of keys to the KDC instead of a cleartext
+ password. If in the cleartext password case, the cleartext password
+ fails to satisfy password policy, the server should use the result
+ code KRB5_KPASSWD_POLICY_REJECT.
+
+2. Conventions used in this document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
+ this document are to be interpreted as described in RFC-2119 [2].
+
+3. The Protocol
+
+ The service must accept requests on UDP port 464 and TCP port 464 as
+ well. 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.
+
+ For TCP transport, there is a 4 octet header in network byte order
+ precedes the message and specifies the length of the message. This
+ requirement is consistent with the TCP transport header in 1510bis.
+
+Request Message
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | message length | protocol version number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | AP_REQ length | AP-REQ data /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / KRB-PRIV message /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ All 16 bit fields are in network byte order.
+
+ message length field: contains the number of bytes in the message
+ including this field.
+
+ protocol version number: contains the hex constant 0x0002 (network
+ byte order).
+
+ 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
+ message.
+
+ AP-REQ data: (see [3]) The AP-REQ message must be for the service
+ principal kadmin/changepw@REALM, where REALM is the REALM of the user
+ who wishes to change/set his password. The ticket in the AP-REQ must
+ must include a subkey in the Authenticator. To enable setting of
+ passwords/keys, it is not required that the initial flag be set in the
+ Kerberos service ticket. The initial flag is required for change requests,
+ but not for set password requests. We have the following definitions:
+
+ old passwd initial flag target principal can be
+ in request? required? distinct from
+ authenticating principal?
+
+ change password: yes yes no
+
+ set password: no no yes
+
+ set key: no policy yes
+ determined
+
+ KRB-PRIV message (see [3]) This KRB-PRIV message must be generated
+ using the subkey from the authenticator in the AP-REQ data.
+
+ The user-data component of the message consists of the following ASN.1
+ structure encoded as an OCTET STRING:
+
+ ChangePasswdData :: = SEQUENCE {
+ newpasswdorkeys[0] NewPasswdOrKeys,
+ targname[1] PrincipalName OPTIONAL,
+ -- only present in set password: the principal
+ -- which will have its password set
+ targrealm[2] Realm OPTIONAL,
+ -- only present in set password: the realm for
+ -- the principal which will have its password set
+
+ }
+
+ NewPasswdOrKeys :: = CHOICE {
+ passwords[0] KeySequence,
+ keyseq[1] PasswordSequence
+
+
+ KeySequence :: = SEQUENCE {
+ key[0] EncryptionKey,
+ salt[1] OCTET STRING OPTIONAL,
+ salt-type[2] INTEGER OPTIONAL
+ }
+
+ PasswordSequence :: = SEQUENCE {
+ newpasswd[0] OCTET STRING,
+ oldpasswd[1] OCTET STRING OPTIONAL
+ -- oldpasswd always present for change password
+ -- but not set password
+ }
+
+ The server must verify the AP-REQ message, check whether the client
+ principal in the ticket is authorized to set or change the password
+ (either for that principal, or for the principal in the targname
+ field if present), and decrypt the new password/keys. The server
+ also checks whether the initial flag is required for this request,
+ replying with status 0x0007 if it is not set and should be. An
+ authorization failure is cause to respond with status 0x0005. For
+ forward compatibility, the server should be prepared to ignore fields
+ after targrealm in the structure that it does not understand.
+
+ The newpasswdorkeys field contains either the new cleartext password
+ (with the old cleartext password for a change password operation),
+ or a sequence of encryption keys with their respective salts.
+
+ In the cleartext password case, if the old password is sent in the
+ request, the request is defined to be a change password request. If
+ the old password is not present in the request, the request is a set
+ password request. The server should apply policy checks to the old
+ and new password after verifying that the old password is valid.
+ The server can check validity by obtaining a key from the old
+ password with a keytype that is present in the KDC database for the
+ user and comparing the keys for equality. The server then generates
+ the appropriate keytypes from the password and stores them in the KDC
+
+ database. If all goes well, status 0x0000 is returned to the client
+ in the reply message (see below). For a change password operation,
+ the initial flag in the service ticket MUST be set.
+
+ In the key sequence case, the sequence of keys is sent to the set
+ password service. For a principal that can act as a server, its
+ preferred keytype should be sent as the first key in the sequence,
+ but the KDC is not required to honor this preference. Application
+ servers should use the key sequence option for changing/setting their
+ keys. The set password service should check that all keys are in the
+ proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise.
+
+Reply Message
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | message length | protocol version number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | AP_REP length | AP-REP data /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / KRB-PRIV message /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ All 16 bit fields are in network byte order.
+
+ message length field: contains the number of bytes in the message
+ including this field.
+
+ protocol version number: contains the hex constant 0x0002 (network
+ 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,
+ then the last field contains a KRB-ERROR message instead of a KRB-PRIV
+ message.
+
+ AP-REP data: the AP-REP is the response to the AP-REQ in the request
+ packet.
+
+ KRB-PRIV from [4]: This KRB-PRIV message must be generated using the
+ subkey in the authenticator in the AP-REQ data.
+
+ The server will respond with a KRB-PRIV message unless it cannot
+ 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
+ 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
+ of the KRB-ERROR message, must consist of the following data.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | result code | result string /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | edata /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ result code (16 bits) (result codes 0-4 are from [4]):
+ The result code must have one of the following values (network
+ byte order):
+ KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not
+ allowed in a KRB-ERROR message)
+ KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed
+ 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
+ authentication processing
+ KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error
+ in processing the request
+ KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
+ 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;
+ the result string should include a text message to be presented
+ to the user.
+ KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist
+ (only in response to a set password request).
+ KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
+ containing at least one etype that is not supported by the KDC.
+ The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO
+ type that specifies the etypes that the KDC supports:
+
+ KERB-ETYPE-INFO-ENTRY :: = SEQUENCE {
+ encryption-type[0] INTEGER,
+ salt[1] OCTET STRING OPTIONAL -- not sent
+ }
+
+ PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY
+
+ The client should retry the request using only etypes (keytypes)
+ that are contained within the PKERB-ETYPE-INFO structure in the
+ previous response.
+ 0xFFFF if the request fails for some other reason.
+ The client must interpret any non-zero result code as a failure.
+ result string - from [4]:
+ This field is a UTF-8 encoded string which should be displayed
+ to the user by the client. Specific reasons for a password
+ set/change policy failure is one use for this string.
+ edata: used to convey additional information as defined by the
+ result code.
+
+4. References
+
+ [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+ 9, RFC 2026, October 1996.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997
+
+ [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
+ Service (V5), Request for Comments 1510.
+
+ [4] M. Horowitz. Kerberos Change Password Protocol,
+ ftp://ds.internic.net/internet-drafts/
+ draft-ietf-cat-kerb-chg-password-02.txt
+
+5. Expiration Date
+
+ This draft expires in August 2000.
+
+6. Authors' Addresses
+
+ Jonathan Trostle
+ Cisco Systems
+ 170 W. Tasman Dr.
+ San Jose, CA 95134
+ Email: jtrostle@cisco.com
+
+ Mike Swift
+ 1 Microsoft Way
+ Redmond, WA 98052
+ Email: mikesw@microsoft.com
+
+ John Brezak
+ 1 Microsoft Way
+ Redmond, WA 98052
+ Email: jbrezak@microsoft.com
+
+ Bill Gossman
+ Cybersafe Corporation
+ Email: bill.gossman@cybersafe.com
+