idnits 2.17.1 draft-ietf-cat-kerberos-extra-tgt-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1510, but the abstract doesn't seem to directly say this. It does mention RFC1510 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...-Drafts are ...' == Line 16 has weird spacing: '... months and ...' == Line 17 has weird spacing: '...-Drafts as...' == Line 18 has weird spacing: '...ference mater...' == Line 28 has weird spacing: '...tion of this ...' (Using the creation date from RFC1510, updated by this document, for RFC5378 checks: 1993-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 139 looks like a reference -- Missing reference section? '2' on line 142 looks like a reference -- Missing reference section? '3' on line 147 looks like a reference -- Missing reference section? '4' on line 150 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jonathan Trostle 2 draft-ietf-cat-kerberos-extra-tgt-00.txt Cisco Systems 3 Updates: RFC 1510 Michael M. Swift 4 expires December 24, 1998 Microsoft 6 Extension to Kerberos V5 For Additional Initial Encryption 8 0. Status Of This Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other docu- 17 ments at any time. It is inappropriate to use Internet-Drafts as 18 reference material or to cite them other than as ``work in pro- 19 gress.'' 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 The distribution of this memo is unlimited. It is filed as 29 draft-ietf-cat-kerberos-extra-tgt-00.txt, and expires December 24, 30 1998. Please send comments to the authors. 32 1. Abstract 34 This document defines an extension to the Kerberos protocol 35 specification (RFC 1510) [1] to enable a preauthentication field in 36 the AS_REQ message to carry a ticket granting ticket. The session 37 key from this ticket granting ticket will be used to 38 cryptographically strengthen the initial exchange in either the 39 conventional Kerberos V5 case or in the case the user stores their 40 encrypted private key on the KDC [2]. 42 2. Motivation 44 In Kerberos V5, the initial exchange with the KDC consists of the 45 AS_REQ and AS_REP messages. For users, the encrypted part of the 46 AS_REP message is encrypted in a key derived from a password. 47 Although a password policy may be in place to prevent dictionary 48 attacks, brute force attacks may still be a concern due to 49 insufficient key length. 51 This draft specifies an extension to the Kerberos V5 protocol to 52 allow a ticket granting ticket to be included in an AS_REQ message 53 preauthentication field. The session key from this ticket granting 54 ticket will be used to cryptographically strengthen the initial 55 exchange in either the conventional Kerberos V5 case or in the case 56 the user stores their encrypted private key on the KDC [2]. The 57 session key from the ticket granting ticket is combined with the 58 user password key (key K2 in the encrypted private key on KDC 59 option) using HMAC to obtain a new triple des key that is used in 60 place of the user key in the initial exchange. The ticket granting 61 ticket could be obtained by the workstation using its host key. 63 3. The Extension 65 The following new preauthentication type is proposed: 67 PA-EXTRA-TGT 22 69 The preauthentication-data field contains a ticket granting ticket 70 encoded as an ASN.1 octet string. The server realm of the ticket 71 granting ticket must be equal to the realm in the KDC-REQ-BODY of 72 the AS_REQ message. In the absence of a trust relationship, the 73 local Kerberos client should send the AS_REQ message without this 74 extension. 76 In the conventional (non-pkinit) case, we require the RFC 1510 77 PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message. 78 If neither it or the PA-PK-KEY-REQ preauthentication field is 79 included in the AS_REQ message, the KDC will reply with a 80 KDC_ERR_PREAUTH_FAILED error message. 82 We propose the following new etypes: 84 des3-cbc-md5-xor 16 85 des3-cbc-sha1-xor 17 87 The encryption key is obtained by: 89 (1) Obtaining an output M from the HMAC-SHA1 function [3] using 90 the user password key (the key K2 in the encrypted private 91 key on KDC option of pkinit) as the text and the triple des 92 session key as the K input in HMAC: 94 M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1. 96 The session key from the accompanying ticket granting ticket 97 must be a triple des key when one of the triple des xor 98 encryption types is used. 99 (2) Concatenate the output M (20 bytes) with the first 8 non-parity 100 bits of the triple-des ticket granting ticket session key to 101 get 168 bits that will be used for the new triple-des encryption 102 key. 103 (3) Set the parity bits of the resulting key. 105 The resulting triple des key is used to encrypt the timestamp 106 for the PA-ENC-TIMESTAMP preauthentication value (or in the 107 encrypted private key on KDC option of pkinit, it is used in 108 place of the key K2 to both sign in the PA-PK-KEY-REQ and for 109 encryption in the PA-PK-KEY-REP preauthentication types). 111 If the KDC decrypts the encrypted timestamp and it is not within 112 the appropriate clock skew period, the KDC will reply with the 113 KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if 114 the above ticket granting ticket fails to decrypt properly, or if 115 it is not a valid ticket. 117 The KDC will create the shared triple des key from the ticket 118 granting ticket session key and the user password key (the key K2 119 in the encrypted private key on KDC case) using HMAC as specified 120 above and use it to validate the AS_REQ message and then to 121 encrypt the encrypted part of the AS_REP message (use it in place 122 of the key K2 for encryption in the PA-PK-KEY-REP preauthentication 123 field). 125 We propose to add an optional bit to the KDC database for each user 126 to indicate whether the new preauthentication type is required. 128 A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a 129 preauthentication field containing a ticket granting ticket, 130 a randomly generated subkey encrypted in the session key from 131 the ticket, and a timestamp structure encrypted in the user 132 password and then the randomly generated subkey was proposed. 133 Some advantages of the current proposal are that the KDC has two 134 fewer decryptions to perform per request and the client does not 135 have to generate a random key. 137 4. Bibliography 139 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication 140 Service (V5). Request for Comments 1510. 142 [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle. 143 Public Key Cryptography for Initial Authentication in Kerberos. 144 ftp://ds.internic.net/internet-drafts/ 145 draft-ietf-cat-kerberos-pkinit-06.txt 147 [3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for 148 Message Authentication. Request for Comments 2104. 150 [4] J. Pato. Using Pre-authentication to Avoid Password Guessing 151 Attacks. OSF DCE SIG Request for Comments 26.0. 153 5. Acknowledgement: We thank Ken Hornstein for some helpful comments. 155 6. Authors' Addresses 157 Jonathan Trostle 158 170 W. Tasman Dr. 159 San Jose, CA 95134, U.S.A. 161 Email: jtrostle@cisco.com 162 Phone: (408) 527-6201 164 Michael Swift 165 Microsoft 166 One Microsoft Way 167 Redmond, Washington, 98052, U.S.A. 169 Email: mikesw@microsoft.com