diff options
Diffstat (limited to 'doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt')
| -rw-r--r-- | doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt | 174 |
1 files changed, 0 insertions, 174 deletions
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt b/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt deleted file mode 100644 index b3ec336b6..000000000 --- a/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt +++ /dev/null @@ -1,174 +0,0 @@ -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 |