--- /dev/null
+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
git.samba.org / samba.git / blobdiff