Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (8.12.9) with ESMTP id m32IENHW017190; Wed, 2 Apr 2008 14:14:23 -0400 (EDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m32IEGCF025625; Wed, 2 Apr 2008 14:14:16 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m3290XV2032615 for ; Wed, 2 Apr 2008 05:00:33 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m3290LNx016829 for ; Wed, 2 Apr 2008 05:00:22 -0400 (EDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mit.edu (Spam Firewall) with ESMTP id 07E3ED8A8AF for ; Wed, 2 Apr 2008 05:00:00 -0400 (EDT) Received: by fg-out-1718.google.com with SMTP id 13so2055542fge.20 for ; Wed, 02 Apr 2008 02:00:00 -0700 (PDT) Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding; bh=JBRUsWfvWYUXq3ik1a11Zjddmp9dJOy5aQcRmzKeC3s=; b=ixaWmyF7cQgvTkyk4oIBv++M9iQl0hIgLcbqkUjxphaEV9JZVIx6Yo+zFAJfdajPK25++z/tKhQvm/1fYAEavE4Dmo2IZL7e6GHPwHC8H5lHf6408NAkzkxFEU+DQjAuKXDRC+2MD6ZXff/Xr/6nlopfbxwCyoNHQc9a662E6lw= Domainkey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding; b=pzNuPtjskF6Sv84HAHG7RLLaV0zcUaauDjSFC57kLnUhwtVpfn7Nz4mjOrv5TesIvTLlHNpB4YlyrHEEO0isZEkNXmNq8A5d3XaTx6IBx8ux2if6nqQJp8YxWe33agtKLbFoOtfmk63vPmLhkp+k6ZF1dcWqvd5HnYZ3/CENNhc= Received: by 10.86.82.16 with SMTP id f16mr6145891fgb.60.1207126800153; Wed, 02 Apr 2008 02:00:00 -0700 (PDT) Received: from l102796.int.cboss.ru ( [195.245.232.177]) by mx.google.com with ESMTPS id 3sm930268fge.7.2008.04.02.01.59.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Apr 2008 01:59:46 -0700 (PDT) Message-ID: <47F34AFC.2050502@gmail.com> Date: Wed, 02 Apr 2008 12:59:40 +0400 From: Igor Mammedov User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: krb5-bugs@mit.edu Subject: "Key table entry not found while getting initial credentials" + KRB5KDC_ERR_PREAUTH_REQUIRED Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-BY: MIMEDefang 2.42 X-Mailman-Approved-At: Wed, 02 Apr 2008 14:14:15 -0400 CC: krbdev@mit.edu X-Beenthere: krb5-bugs-incoming@mailman.mit.edu X-Mailman-Version: 2.1.6 Precedence: list Sender: krb5-bugs-incoming-bounces@PCH.MIT.EDU Errors-To: krb5-bugs-incoming-bounces@PCH.MIT.EDU Content-Length: 2702 Hi folks, Maybe I've found a bug in krb5 libs code. Here is the thing: When we store user password in keytab with des-cbc-md5 encryption with "addent -password -p TESTUSERNAME -k 1 -e des-cbc-md5" we receive error KRB5KDC_ERR_PREAUTH_REQUIRED from the server and kinit says "Key table entry not found while getting initial credentials". Also note that in the dump of the client-server conversation there is no field "padata" in the request. -------------- Incorrect case -------------------- User Datagram Protocol, Src Port: 46944 (46944), Dst Port: kerberos (88) Kerberos AS-REQ Pvno: 5 MSG Type: AS-REQ (10) KDC_REQ_BODY Padding: 0 KDCOptions: 40000010 (Forwardable, Renewable OK) Client Name (Principal): TESTUSERNAME Realm: MY.TEST.REALM Server Name (Unknown): krbtgt/MY.TEST.REALM from: 2008-04-02 07:56:30 (Z) till: 2008-04-03 07:56:30 (Z) Nonce: 1207122990 Encryption Types: rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5 User Datagram Protocol, Src Port: kerberos (88), Dst Port: 46944 (46944) Kerberos KRB-ERROR Pvno: 5 MSG Type: KRB-ERROR (30) stime: 2008-04-02 07:55:18 (Z) susec: 502936 error_code: KRB5KDC_ERR_PREAUTH_REQUIRED (25) Realm: MY.TEST.REALM Server Name (Unknown): krbtgt/MY.TEST.REALM e-data However if we add entry into keytab this way: "addent -password -p TESTUSERNAME -k 1 -e rc4-hmac" Then client sends "padata" in the request and the server replies with a valid TGT. So this is probably a bug in the client code (kinit or krb5 libs), if it is not then could someone clarify why it works this way? ------------- Normal case -------------------------- User Datagram Protocol, Src Port: 41142 (41142), Dst Port: kerberos (88) Kerberos AS-REQ Pvno: 5 MSG Type: AS-REQ (10) padata: PA-ENC-TIMESTAMP Type: PA-ENC-TIMESTAMP (2) Value: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX... rc4-hmac KDC_REQ_BODY Padding: 0 KDCOptions: 40000010 (Forwardable, Renewable OK) Client Name (Principal): TESTUSERNAME Realm: MY.TEST.REALM Server Name (Unknown): krbtgt/MY.TEST.REALM from: 2008-04-02 08:05:01 (Z) till: 2008-04-03 08:05:01 (Z) Nonce: 1207123501 Encryption Types: rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5 User Datagram Protocol, Src Port: kerberos (88), Dst Port: 41142 (41142) Kerberos AS-REP Pvno: 5 MSG Type: AS-REP (11) Client Realm: MY.TEST.REALM Client Name (Principal): TESTUSERNAME Ticket enc-part rc4-hmac -- Best regards, ------------------------- Igor Mammedov, niallain "at" gmail.com