From nobody Thu Mar 3 12:02:05 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3871B4281; Thu, 3 Mar 2016 12:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.908 X-Spam-Level: X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqfKdxktA_g3; Thu, 3 Mar 2016 12:02:02 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7EA1B4278; Thu, 3 Mar 2016 12:01:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1795418000B; Thu, 3 Mar 2016 12:00:42 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160303200042.1795418000B@rfc-editor.org> Date: Thu, 3 Mar 2016 12:00:42 -0800 (PST) Archived-At: Cc: kitten@ietf.org, rfc-editor@rfc-editor.org Subject: [kitten] RFC 7751 on Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 20:02:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7751 Title: Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs) Author: S. Sorce, T. Yu Status: Standards Track Stream: IETF Date: March 2016 Mailbox: ssorce@redhat.com, tlyu@mit.edu Pages: 10 Characters: 23133 Updates: RFC 4120 I-D Tag: draft-ietf-kitten-cammac-04.txt URL: https://www.rfc-editor.org/info/rfc7751 DOI: http://dx.doi.org/10.17487/RFC7751 This document specifies a Kerberos authorization data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained authorization data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120. This document is a product of the Common Authentication Technology Next Generation Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Mar 3 12:02:40 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A4D1B428E; Thu, 3 Mar 2016 12:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.908 X-Spam-Level: X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS6lPuXgn_rW; Thu, 3 Mar 2016 12:02:26 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944AA1B4279; Thu, 3 Mar 2016 12:02:03 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 94B0D18000B; Thu, 3 Mar 2016 12:01:03 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160303200103.94B0D18000B@rfc-editor.org> Date: Thu, 3 Mar 2016 12:01:03 -0800 (PST) Archived-At: Cc: kitten@ietf.org, rfc-editor@rfc-editor.org Subject: [kitten] RFC 7802 on A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 20:02:28 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7802 Title: A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism Author: S. Emery, N. Williams Status: Standards Track Stream: IETF Date: March 2016 Mailbox: shawn.emery@oracle.com, nico@cryptonector.com Pages: 8 Characters: 14118 Obsoletes: RFC 4402 I-D Tag: draft-ietf-kitten-rfc4402bis-02.txt URL: https://www.rfc-editor.org/info/rfc7802 DOI: http://dx.doi.org/10.17487/RFC7802 This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. This document obsoletes RFC 4402 and reclassifies that document as Historic. RFC 4402 starts the PRF+ counter at 1; however, a number of implementations start the counter at 0. As a result, the original specification would not be interoperable with existing implementations. This document is a product of the Common Authentication Technology Next Generation Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Mar 10 05:11:59 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F46612D747 for ; Thu, 10 Mar 2016 05:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H18XRzG3d4JL for ; Thu, 10 Mar 2016 05:11:54 -0800 (PST) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832B812D743 for ; Thu, 10 Mar 2016 05:11:53 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id UDBo1s01410HQrX01DBqo8; Thu, 10 Mar 2016 14:11:51 +0100 Message-ID: <56E17292.4020302@openfortress.nl> Date: Thu, 10 Mar 2016 14:11:46 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "kitten@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: [kitten] Kerberos Realm Crossover with DNSSEC/DANE X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 13:11:57 -0000 Hello, Over the past months, I've had a student working on a proof-of-concept for Realm Crossover with Kerberos, based on DNSSEC/DANE. He will soon deliver his MSc thesis, which I might forward to interested parties. The work done concludes that it is not possible to entirely base it on PKINIT and AS-REQ/AS-REP, so I set out to define alternative message structures. I have reached a stage where things almost seem simple to me :) so may I ask for feedback on those? I created a heavily commented ASN.1 module in a number of formats, available on http://realm-xover.arpa2.net/spec/KXOVER.html http://realm-xover.arpa2.net/spec/KXOVER.txt http://realm-xover.arpa2.net/spec/KXOVER.epub http://realm-xover.arpa2.net/spec/KXOVER.asn1 http://realm-xover.arpa2.net/spec/KXOVER.pdf This is in preparation of an I-D. As far as I'm concerned, this could be a useful topic for discussion at IETF 95. Thanks, -Rick From nobody Thu Mar 10 14:29:41 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9C712DD92 for ; Thu, 10 Mar 2016 14:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Zm7305C6xAy for ; Thu, 10 Mar 2016 14:29:39 -0800 (PST) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3983112DD8E for ; Thu, 10 Mar 2016 14:29:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id AAA5CEC9D for ; Thu, 10 Mar 2016 17:29:35 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klHpwHVHdcNq for ; Thu, 10 Mar 2016 17:29:35 -0500 (EST) Received: from [192.168.1.180] (wsip-174-76-19-88.oc.oc.cox.net [174.76.19.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 4D67BECDE for ; Thu, 10 Mar 2016 17:29:32 -0500 (EST) From: "Henry B (Hank) Hotz, CISSP" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <07E0B67B-EE1E-4DA6-9FAA-AF7C223DEDD4@oxy.edu> Date: Thu, 10 Mar 2016 14:29:30 -0800 To: "kitten@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [kitten] Authorization Data Types? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 22:29:40 -0000 AFAIK we=E2=80=99ve never done much with standardizing authorization = data. (I have to accept some of the blame for that myself, = unfortunately.) Now I find myself wanting to do a proprietary extension. Any advice = (besides =E2=80=9Cdon=E2=80=99t do it=E2=80=9D)? I=E2=80=99d at least = like to minimize the side effects on standard uses. Personal: hbhotz@oxy.edu Business: hhotz@securechannels.com From nobody Thu Mar 10 17:04:04 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E807612D8C9 for ; Thu, 10 Mar 2016 17:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7e9fcRM4E17 for ; Thu, 10 Mar 2016 17:04:00 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D5712D861 for ; Thu, 10 Mar 2016 17:04:00 -0800 (PST) X-AuditID: 12074425-a83ff700000064bb-8d-56e2197e9e3b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 7C.08.25787.E7912E65; Thu, 10 Mar 2016 20:03:59 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u2B13wm1021237; Thu, 10 Mar 2016 20:03:58 -0500 Received: from [18.101.8.108] (vpn-18-101-8-108.mit.edu [18.101.8.108]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2B13n9N015893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Mar 2016 20:03:57 -0500 To: "Henry B (Hank) Hotz, CISSP" , "kitten@ietf.org" References: <07E0B67B-EE1E-4DA6-9FAA-AF7C223DEDD4@oxy.edu> From: Greg Hudson X-Enigmail-Draft-Status: N1110 Message-ID: <56E21975.20209@mit.edu> Date: Thu, 10 Mar 2016 20:03:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <07E0B67B-EE1E-4DA6-9FAA-AF7C223DEDD4@oxy.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nolsv+SjMYM8dJouP9xayWBzdvIrF gcljyZKfTB5bm/4yBzBFcdmkpOZklqUW6dslcGXsvfiatWATX8WC/UvYGhivcXcxcnJICJhI LPx1iqWLkYtDSKCNSeLr3QYoZyOjRNsbGOcIk8SljvfsIC3CAvoSv6bdYAGxRQTiJaat3sME YgsJWElsfLGREcRmE1CWWL9/KwvECjmJ3u5JYDavgIrE/5VfwGpYBFQlGrZPALNFBSIknsw9 yQhRIyhxcuYTsHpOAWuJg48mgs1nFlCX+DPvEjOELS/RvHU28wRGgVlIWmYhKZuFpGwBI/Mq RtmU3Crd3MTMnOLUZN3i5MS8vNQiXQu93MwSvdSU0k2M4FB1Ud3BOOev1yFGAQ5GJR7eD9ce hgmxJpYVV+YeYpTkYFIS5fW6DhTiS8pPqcxILM6ILyrNSS0+xCjBwawkwivO9ChMiDclsbIq tSgfJiXNwaIkzsvIwMAgJJCeWJKanZpakFoEk5Xh4FCS4JWWAGoULEpNT61Iy8wpQUgzcXCC DOcBGu4HUsNbXJCYW5yZDpE/xagoJc7LDJIQAElklObB9YJTSSpHzitGcaBXhHmXgFTxANMQ XPcroMFMQINftN4DGVySiJCSamD03hJ6W6IosfHG3Mz22bYF64t1OaImqn1X2rLFRVPdfenE bv0t1tGvBJecnhb0bvLas8//b9tQaes/MbnuaGCRSnPuV69bLVU7ll3icHTde0jpb6DBS2PJ j6cfrBPTeCXd2PPjZw0fM0OF4YkNVa82ZqidZ1vLocA362Q0x5lMjQORTOXrxVyVWIozEg21 mIuKEwFCrSEAAAMAAA== Archived-At: Subject: Re: [kitten] Authorization Data Types? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 01:04:03 -0000 On 03/10/2016 05:29 PM, Henry B (Hank) Hotz, CISSP wrote: > AFAIK we’ve never done much with standardizing authorization data. Well, we did just publish RFC 7751 (CAMMAC) and have a working group draft for ad-authentication-indicator. But it's true that we haven't done a lot with it. > Now I find myself wanting to do a proprietary extension. Any advice (besides “don’t do it”)? I’d at least like to minimize the side effects on standard uses. Negative ad-type values are reserved for local use, positive values for registered use. (RFC 4120 section 5.2.6.) Be aware of the security properties of authorization data: * It's not visible to the client or to third parties because it's in the encrypted part of the ticket. It is visible to the service and the KDC. * Clients can ask for any authorization data they want when requesting a ticket, and by default the KDC is supposed to include it. KDCs may filter out certain ad-types, but only if they know what they are. AD-KDC-ISSUED or AD-CAMMAC containers can be used to ensure to a service that authorization data was issued according to KDC policy. * Services can forge authorization data in the ticket when making a ticket modification request or S4U2Proxy request to the KDC. AD-KDC-ISSUED does not change this. AD-CAMMAC containers can be used to ensure to the KDC that authorization data was issued according to KDC policy, as long as the kdc-verifier is present and verifies correctly. * Authorization data contained in a cross-realm TGT was, at best, issued according to the policy of the source realm, not the target realm. * Authorization data is supposed to be critical by default (unless enclosed in an AD-IF-RELEVANT container), but I don't think any implementation enforces this, so in practice it's all non-critical. From nobody Fri Mar 11 05:55:53 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8BE12D6F0 for ; Fri, 11 Mar 2016 05:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2m17A8F0PvV for ; Fri, 11 Mar 2016 05:55:50 -0800 (PST) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2AC12D6D0 for ; Fri, 11 Mar 2016 05:55:49 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id Udvn1s01810HQrX01dvoXy; Fri, 11 Mar 2016 14:55:48 +0100 Message-ID: <56E2CE62.1030708@openfortress.nl> Date: Fri, 11 Mar 2016 14:55:46 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "kitten@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [kitten] TLS with Kerberos + ECDHE, new draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 13:55:51 -0000 Hello, FYI, I have completed a new I-D version for integration of Kerberos (entwined with ECDH) into TLS. I announced it at the TLS-WG but thought Kitten should know about it too. The central choice made in this draft is to embed Kerberos Ticket + Authenticator in the client X.509 Certificate, and use an Authenticator as ClientVerify. This is awkward, but it means that the rest of the integration with TLS is very smooth. > Name: draft-vanrein-tls-kdh > Revision: 02 > Title: TLS-KDH: Kerberos + Diffie-Hellman in TLS > Document date: 2016-03-11 > Group: Individual Submission > Pages: 23 > URL: https://www.ietf.org/internet-drafts/draft-vanrein-tls-kdh-02.txt > Status: https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-tls-kdh-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-vanrein-tls-kdh-02 > > Abstract: > This specification defines a TLS message flow with Kerberos-based > (mutual) authentication, binding in Elliptic-Curve Diffie-Hellman to > achieve Forward Secrecy for the session. FWIW, a demonstration of the embedded Tickets in an X.509 certificate can be found on https://github.com/arpa2/kerberos2pkix -- inluding a shell dump and a certificate example. Cheers, -Rick From nobody Fri Mar 11 15:05:39 2016 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8B312DD7D; Fri, 11 Mar 2016 15:05:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230522.15028.50846.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:22 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] kitten - Requested session has been scheduled for IETF 95 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:22 -0000 Dear Benjamin Kaduk, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. kitten Session 1 (1:00:00) Thursday, Afternoon Session II 1620-1720 Room Name: Quebracho A size: 75 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Common Authentication Technology Next Generation Area Name: Security Area Session Requester: Benjamin Kaduk Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: abfab ace httpauth httpbis cose curdle jose jsonbis oauth saag radext tls uta Second Priority: precis sidr trans nfsv4 Special Requests: --------------------------------------------------------- From nobody Thu Mar 17 08:51:40 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF03112D9B9 for ; Thu, 17 Mar 2016 08:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkC0RmdEWNFB for ; Thu, 17 Mar 2016 08:51:36 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543CF12D9AB for ; Thu, 17 Mar 2016 08:51:36 -0700 (PDT) X-AuditID: 1209190c-ed7ff7000000022a-d4-56ead2862f84 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 06.86.00554.682DAE65; Thu, 17 Mar 2016 11:51:34 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u2HFpYx1009779; Thu, 17 Mar 2016 11:51:34 -0400 Received: from [18.101.8.141] (vpn-18-101-8-141.mit.edu [18.101.8.141]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2HFpUJl000799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Mar 2016 11:51:32 -0400 To: Rick van Rein , "kitten@ietf.org" References: <56E17292.4020302@openfortress.nl> From: Greg Hudson X-Enigmail-Draft-Status: N1110 Message-ID: <56EAD282.5090708@mit.edu> Date: Thu, 17 Mar 2016 11:51:30 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E17292.4020302@openfortress.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrdt26VWYwZYmK4ujm1exWDx9dY/N gcljyZKfTB4b/jWxBTBFcdmkpOZklqUW6dslcGWsmPuPvWAud8W8z9kNjL2cXYycHBICJhIf l3xl62Lk4hASaGOSmPt/KyuEs5FR4s/26cwQzhEmiZl3HzOCtAgL2EusXLyLHcQWEfCV+DG1 hQ3EFhLQkzjTsJIZxGYTUJZYv38rC8QKOYne7klgNq+AmsT9O3vBalgEVCU+3rwHFhcViJB4 MvckI0SNoMTJmU/A4pwC+hKXr14D28UMNH/H9V+sELa8RPPW2cwTGAVmIWmZhaRsFpKyBYzM qxhlU3KrdHMTM3OKU5N1i5MT8/JSi3QN9XIzS/RSU0o3MYIDVZJnB+OZN16HGAU4GJV4eFec fhkmxJpYVlyZe4hRkoNJSZR3165XYUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeNkOAeV4UxIr q1KL8mFS0hwsSuK8hftPhwkJpCeWpGanphakFsFkZTg4lCR4qy8CNQoWpaanVqRl5pQgpJk4 OEGG8wANXwpSw1tckJhbnJkOkT/FqCglznsVJCEAksgozYPrBSeSVI7eV4ziQK8I8z4CqeIB JiG47ldAg5mABh+LAxtckoiQkmpgZF3deshx3QeJEBYHlXtKXiZTvhz/EjBddUNWj899xarz 9cXliTYKvw7UNdqtiL/7ZYK5+62zFxK5V2zbHGjNLBkb4XaS65ahy5RkNq4f0xdMnHjsnLjx GSbpF1rr/mis2GjX1b3s3tr9hhKpnM5bLk+/oLS4Z862o6b/Y/kmtOpVxh6NdMmaocRSnJFo qMVcVJwIAH2YzFH/AgAA Archived-At: Subject: Re: [kitten] Kerberos Realm Crossover with DNSSEC/DANE X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 15:51:39 -0000 On 03/10/2016 08:11 AM, Rick van Rein wrote: > http://realm-xover.arpa2.net/spec/KXOVER.html I have a few comments, although I haven't dug too deeply. * Are you sending these messages to the regular KDC ports, and then having the KDC dispatch them to a different process, or are you using a separate daemon? I'm not sure whether these messages are part of the Kerberos protocol or not. * Wrapping the messages in padata and KX-REQ/KDC-REQ-MOD/KX-REP/KDC-REP-MOD seems to add a lot of complexity for no obvious benefit. Can KX-PA-DATA messages be sent directly instead? (With an application tag, if they're part of the Kerberos protocol, and of course with a different sequence name.) If there is a need for a typed hole in the new message type, a pa-data sequence can be included in the KX messages. Or the ASN.1 sequences can be made extensible (a good practice anyway) and extensions can require standardization, if we don't think there is likely to be lots of independent interest in extending this particular message type. * Since DANE is being leveraged as an anchor, I wonder if it would be possible to cut out X.509 and PKIX, without having to reinvent them. Could we store eddsa public keys in DNS and send eddsa signatures, for instance? I realize there might be issues with key rollover and DNS caching, but I don't know whether those issues are automatically solved by using certificates. From nobody Thu Mar 17 09:57:41 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6129A12DC77 for ; Thu, 17 Mar 2016 09:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT5MZ3zV207j for ; Thu, 17 Mar 2016 09:57:35 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7606E12D99F for ; Thu, 17 Mar 2016 09:57:03 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id X4wz1s00D10HQrX014x00d; Thu, 17 Mar 2016 17:57:01 +0100 Message-ID: <56EAE1DA.3070701@openfortress.nl> Date: Thu, 17 Mar 2016 17:56:58 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Greg Hudson References: <56E17292.4020302@openfortress.nl> <56EAD282.5090708@mit.edu> In-Reply-To: <56EAD282.5090708@mit.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Kerberos Realm Crossover with DNSSEC/DANE X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 16:57:38 -0000 Hello Greg, Thanks for looking into this. > > * Are you sending these messages to the regular KDC ports, and then > having the KDC dispatch them to a different process, or are you using a > separate daemon? I'm not sure whether these messages are part of the > Kerberos protocol or not. Yes, this is the intention. That's why I've used [APPLICATION] tags that differ from what Kerberos is using now (according to my grep over RFCs that responded to "grep Kerberos"). The reason for coupling KDCs directly is so we can establish crossover keys between realms that service all their users at once, for the agreed-upon period of time. Also, the KDC can be expected to have access to DNSSEC/DANE validation, which may be more questionable for clients behind uncontrollable middle boxes. The reason for a different process to which the KDC dispatches is to avoid filling up the KDC with slow external communication including timeouts. FYI, a student of mine (Oriol Cao) worked this flow into AS, in a different daemon/process, and got it working (with syntax violations for not passing back a Ticket) as the intended DANE-based construction of ECDH crossover keys. The only issue we ran into with the kdb API was that we needed to supply a NUL-terminated ASCII string with a password, while binary key computations are probably better in this case. > > * Wrapping the messages in padata and > KX-REQ/KDC-REQ-MOD/KX-REP/KDC-REP-MOD seems to add a lot of complexity > for no obvious benefit. Can KX-PA-DATA messages be sent directly > instead? Yes, I think this would be fine. I have tried to stay as close to the existing packet structure to reduce the chances of trouble, hence the Reserved fields. But this is certainly something I can use this sort of input on :) > > (With an application tag, if they're part of the Kerberos > protocol, and of course with a different sequence name.) Yes, of course. > > If there is a > need for a typed hole in the new message type, a pa-data sequence can be > included in the KX messages. I see no such reason as yet. I'm curious what Nico thinks though; he has done some preliminary work on PKCROSS which approaches the problem from a client. That's another reason for the Reserved fields in the *-MOD structures, to give that approach some wiggling room. > > Or the ASN.1 sequences can be made > extensible (a good practice anyway) and extensions can require > standardization, if we don't think there is likely to be lots of > independent interest in extending this particular message type. OK. I saw no ",..." in RFC 4120 so I decided not to use it, but I am quite happy to move in this direction. You're actually saying the things that I didn't dare to propose! > > * Since DANE is being leveraged as an anchor, I wonder if it would be > possible to cut out X.509 and PKIX, without having to reinvent them. > Could we store eddsa public keys in DNS and send eddsa signatures, for > instance? That would simplify matters, but also disable a few potential benefits: * certificates signed by a federation CA could be used to mark the boundaries of that federation * extended key usage can be helpful to signal that a cert is indeed meant to be used this way; that enables listing certain client certificates, if the intention were to let those contact a KDC directly (as under PKCROSS) * extended key usage sets the certificates intended for KXOVER apart from those that, say, merely identify the KDC to their clients as part of PKINIT The first may be resolved by explicitly mentioning acceptable pubkeys in an accepted-remote list in the KDC config. The second may be resolved if PKCROSS uses its own mechanisms (I can't think of other EKU signals that could matter). The third seems important, but may be resolved with a _kxover prefix in DNS. > I realize there might be issues with key rollover and DNS > caching, but I don't know whether those issues are automatically solved > by using certificates. I would love to get rid of the timing restrictions in certificates for KDC use, indeed. DNS timing issues are probably the same as for DANE. We should carefully choose our semantics here; it seemds reasonable to state that the negotiated validity period for a crossover key (bounded by each KDC's max setting) cannot be reduced by a retraction in DANE. Or we could state that no new crossovers should be created if DANE is retracted. Kerberos doesn't seem to be prepared for keys being withdrawn after they are handed out in client TGTs. Then again, the situation we're talking about now is drastic. I wonder if there is a suitable DNS RRtype to do what you are proposing here? * CERT stores X.509 and OpenPGP keys * IPSECKEY and TKEY have dedicated/other purposes We might define an extra case for TLSA, using the public key (or its hash). Or we might specify to ignore surrounding certificates by default and strip it down to the public key. Thanks! -Rick From nobody Mon Mar 21 10:43:52 2016 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A95112D508; Mon, 21 Mar 2016 10:43:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321174343.31977.39539.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 10:43:43 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 17:43:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation of the IETF. Title : Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension Authors : Michiko Short Seth Moore Paul Miller Filename : draft-ietf-kitten-pkinit-freshness-04.txt Pages : 8 Date : 2016-03-21 Abstract: This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension [RFC4556] to exchange an opaque data blob that a KDC can validate to ensure that the client is currently in possession of the private key during a PKINIT AS exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-freshness/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-freshness-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 10:57:20 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C66012D9BD for ; Mon, 21 Mar 2016 10:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZmB_UzmII7L for ; Mon, 21 Mar 2016 10:57:17 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8CF712D9E1 for ; Mon, 21 Mar 2016 10:57:07 -0700 (PDT) X-AuditID: 12074425-d93ff70000007cc8-bd-56f035f2de7d Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 20.C4.31944.2F530F65; Mon, 21 Mar 2016 13:57:06 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u2LHv6oB027879 for ; Mon, 21 Mar 2016 13:57:06 -0400 Received: from [18.101.9.162] (vpn-18-101-9-162.mit.edu [18.101.9.162]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2LHv4MX018386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 21 Mar 2016 13:57:06 -0400 References: <20160321174343.31977.39539.idtracker@ietfa.amsl.com> To: kitten@ietf.org From: Greg Hudson Message-ID: <56F035EF.1030304@mit.edu> Date: Mon, 21 Mar 2016 13:57:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160321174343.31977.39539.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixG6novvJ9EOYwbYjhhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxp2Hs9gKGpgqNj34z9jAeImxi5GTQ0LARGLl/MVMILaQQBuT ROMv4y5GLiD7OKPE5PMzGCGcW0wSTRdb2UCqhAW8JVo3nwJKcAAlHCWm73cHCYsICEvs3vqO GcRmE1CWWL9/KwuIzSugJnHr1Fcwm0VAVeLLuVVgi0UFIiSezD3JCFEjKHFy5hMWkJGcAk4S l76Eg4SZBfQkdlz/xQphy0tsfzuHeQIj/ywkHbOQlM1CUraAkXkVo2xKbpVubmJmTnFqsm5x cmJeXmqRroVebmaJXmpK6SZGcOC5qO5gnPPX6xCjAAejEg8vw6r3YUKsiWXFlbmHGCU5mJRE eVfqfQgT4kvKT6nMSCzOiC8qzUktPsQowcGsJMJbCwx3Id6UxMqq1KJ8mJQ0B4uSOC8jAwOD kEB6YklqdmpqQWoRTFaGg0NJglcWpFGwKDU9tSItM6cEIc3EwQkynAdoeKYJyPDigsTc4sx0 iPwpRl2OBT9ur2USYsnLz0uVEuc9ClIkAFKUUZoHNwecMFI5F71iFAd6S5hXFWQdDzDZwE16 BbSECWiJS+Q7kCUliQgpqQbGql8Zz37IHJ+wdZv5Z64Zkfd5GGf6xTKq2Ka2FSafTZGvXTG5 xmRh6wTep8fcb25wm7NwsvPngOQDYVzsfdMS7jufXNH0MsLgsZpAXIGNg39CVOLmnrQ5p4TC df/Gyz8+O8eh1Dnr7MTaLwt45ILr2ZkfXmVqlqnp5dZhDjRaZOm60PZn9nUlluKMREMt5qLi RABEMb8z8wIAAA== Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 17:57:19 -0000 In section 2.4, I think the cross-reference for KDC_ERR_PREAUTH_FAILED should be RFC 4120; although RFC 6113 elaborates on its use, the initial definition is still in 4120. Other than that small editorial issue, my two comments to -03 are addressed. From nobody Mon Mar 21 13:20:02 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38A012DB5F for ; Mon, 21 Mar 2016 13:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCYY-qr-xIjO for ; Mon, 21 Mar 2016 13:19:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0134.outbound.protection.outlook.com [207.46.100.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA15512DB54 for ; Mon, 21 Mar 2016 13:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fdfXV+C9EjGtwABSmBQ52bUwR4inVuUWcMffA7CuSF0=; b=CMi2NdDHfddJhC41sNZBtJte32OAvPWSC10dyQ84DjlNKqp5it6g624IWH+BYG+/gUd/JRISNsJZ9qoE4rq6G/7cdEH7CO9h+dE8mdIJubky05ACd6A/VfzKoOL5MncWJVra03mK9STimdLQQWMhQq5mlseFn5Mq8d/lwr0HKfE= Received: from CO2PR03MB2262.namprd03.prod.outlook.com (10.166.92.143) by CO2PR03MB2262.namprd03.prod.outlook.com (10.166.92.143) with Microsoft SMTP Server (TLS) id 15.1.434.11; Mon, 21 Mar 2016 20:19:49 +0000 Received: from CO2PR03MB2262.namprd03.prod.outlook.com ([10.166.92.143]) by CO2PR03MB2262.namprd03.prod.outlook.com ([10.166.92.143]) with mapi id 15.01.0434.019; Mon, 21 Mar 2016 20:19:49 +0000 From: Seth Moore To: Greg Hudson , "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-04.txt Thread-Index: AQHRg5lN/uWE57iPZUSW2JbNdwXVQJ9kLvOAgAAnoHA= Date: Mon, 21 Mar 2016 20:19:49 +0000 Message-ID: References: <20160321174343.31977.39539.idtracker@ietfa.amsl.com> <56F035EF.1030304@mit.edu> In-Reply-To: <56F035EF.1030304@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:c::701] x-ms-office365-filtering-correlation-id: 40ebae68-91be-429b-7092-08d351c6274e x-microsoft-exchange-diagnostics: 1; CO2PR03MB2262; 5:onXU2RWijqP9M6ArfmKoZVRJtFS9ARwFJHhsnTJOXjRJnnLxFuKrQSt4kOxJi9LGFHXTF0NDm8TF0MKD0K0VBXtxcNDrZjWz6AYV6aUH54nHCx+HNWOF5GHakPRIKv78EJgwEfDrZHmecSj/PJ+DNg==; 24:mqZyFthoVJR51cN0PaeWiMFz9F8Idonc6jkDgORVxcPuxccevKy04H3JySnEWWRXk0zbtDG6Vk/yOy9BMTqVFmuVH1IhKhaM+K2zby/9m8U= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2262; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:CO2PR03MB2262; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2262; x-forefront-prvs: 0888B1D284 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(13464003)(377454003)(77096005)(11100500001)(81166005)(92566002)(15975445007)(10290500002)(5005710100001)(5001770100001)(8990500004)(6116002)(10090500001)(2950100001)(2900100001)(586003)(5008740100001)(107886002)(102836003)(2906002)(5002640100001)(3280700002)(106116001)(19580395003)(2501003)(1096002)(1220700001)(5003600100002)(19580405001)(189998001)(10400500002)(3660700001)(122556002)(76176999)(2171001)(5004730100002)(230783001)(54356999)(86612001)(99286002)(33656002)(87936001)(74316001)(86362001)(76576001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2262; H:CO2PR03MB2262.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2016 20:19:49.2479 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2262 Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:20:00 -0000 Thanks, Greg. I think the RFC reference mix up was due to 6113 discussing retry (Section = 2). The actual error is, indeed, defined in 4120 (7.5.9). Cheers, Seth -----Original Message----- From: Kitten [mailto:kitten-bounces@ietf.org] On Behalf Of Greg Hudson Sent: Monday, March 21, 2016 10:57 AM To: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-04.txt In section 2.4, I think the cross-reference for KDC_ERR_PREAUTH_FAILED shou= ld be RFC 4120; although RFC 6113 elaborates on its use, the initial defini= tion is still in 4120. Other than that small editorial issue, my two comments to -03 are addressed= . _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From nobody Mon Mar 21 15:32:21 2016 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E67F012D138; Mon, 21 Mar 2016 15:32:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321223215.12211.35084.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 15:32:15 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 22:32:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation of the IETF. Title : Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension Authors : Michiko Short Seth Moore Paul Miller Filename : draft-ietf-kitten-pkinit-freshness-05.txt Pages : 8 Date : 2016-03-21 Abstract: This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension [RFC4556] to exchange an opaque data blob that a KDC can validate to ensure that the client is currently in possession of the private key during a PKINIT AS exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-freshness/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-freshness-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 15:33:25 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508A412D10E for ; Mon, 21 Mar 2016 15:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq5ucPG5orsl for ; Mon, 21 Mar 2016 15:33:22 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8D112D135 for ; Mon, 21 Mar 2016 15:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tG5Usyl8/EhWluLLqHKFAjXTacz5YmKeNnvVIR3U6C8=; b=oKjs16P1DsOhOkoCktxPVy54y/IL9FSFUpSGpHWkbVF8l+hQG9aS0rG44OEFsYLWQ/bnv7y08Y5nen9funLFgldKjCXiSujNrsUhPza4bZ0UmjHKq7/u1KICL3OjlgJSDRLy3CmufZo72K5ByMW4/oBb5ZOPW/5Tc50Ny4wi5R4= Received: from BY1PR03MB1417.namprd03.prod.outlook.com (10.162.127.147) by BN3PR03MB2257.namprd03.prod.outlook.com (10.166.74.18) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 21 Mar 2016 22:33:18 +0000 Received: from BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) by BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) with mapi id 15.01.0434.021; Mon, 21 Mar 2016 22:33:17 +0000 From: Michiko Short To: Seth Moore , Greg Hudson , "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-04.txt Thread-Index: AQHRg5lMzahi3ZDUlUWCTNh7AZqQFp9kLvOAgAAn44CAACU+cA== Date: Mon, 21 Mar 2016 22:33:16 +0000 Message-ID: References: <20160321174343.31977.39539.idtracker@ietfa.amsl.com> <56F035EF.1030304@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:7::409] x-ms-office365-filtering-correlation-id: 65ce81a5-1d16-4920-336d-08d351d8cc34 x-microsoft-exchange-diagnostics: 1; BN3PR03MB2257; 5:A2Zb4Dc1HZWYIotz9+yCO3wpZZe/NoRSdiuwF4L0g95zANBVEAhzQyAmP+CTXoSPhLIMRCS7K73ywKYpETeftQSy4Jm9suUUeWQLBhd/3l4nUcM3v4AueyWHfR3pWkRGfi3PyG/Z8SJyYQuTR81+rw==; 24:832wlS9ZHQSe9w4qIB3MxyHnJ1x96GvITbPLlciS9Dh+0SiQGulBIMlvKknZ2YUKEyY2MMpHTRMSoasGbd+Hu08llep88hwK7Z9Y1bUrbI4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB2257; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR03MB2257; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2257; x-forefront-prvs: 0888B1D284 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(13464003)(5008740100001)(92566002)(5003600100002)(230783001)(54356999)(2561002)(2421001)(77096005)(19580395003)(87936001)(81166005)(76176999)(74316001)(2171001)(86362001)(86612001)(8990500004)(76576001)(15975445007)(2950100001)(122556002)(107886002)(50986999)(99286002)(5001770100001)(5004730100002)(33656002)(189998001)(10090500001)(10400500002)(3280700002)(10290500002)(6116002)(5002640100001)(2900100001)(106116001)(102836003)(1220700001)(2906002)(2501003)(19580405001)(3660700001)(5005710100001)(1096002)(586003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2257; H:BY1PR03MB1417.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2016 22:33:16.7786 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2257 Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 22:33:24 -0000 Published version 5 with that fix. -----Original Message----- From: Kitten [mailto:kitten-bounces@ietf.org] On Behalf Of Seth Moore Sent: Monday, March 21, 2016 1:20 PM To: Greg Hudson ; kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-04.txt Thanks, Greg. I think the RFC reference mix up was due to 6113 discussing retry (Section = 2). The actual error is, indeed, defined in 4120 (7.5.9). Cheers, Seth -----Original Message----- From: Kitten [mailto:kitten-bounces@ietf.org] On Behalf Of Greg Hudson Sent: Monday, March 21, 2016 10:57 AM To: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-04.txt In section 2.4, I think the cross-reference for KDC_ERR_PREAUTH_FAILED shou= ld be RFC 4120; although RFC 6113 elaborates on its use, the initial defini= tion is still in 4120. Other than that small editorial issue, my two comments to -03 are addressed= . _______________________________________________ Kitten mailing list Kitten@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fkitten&data=3D01%7c01%7cmichikos%40microsoft.co= m%7cb5e550e620d143d7a9cb08d351c638cd%7c72f988bf86f141af91ab2d7cd011db47%7c1= &sdata=3DAhUkMRzx8gVSJ8k%2f9ctr7%2bA6H329ksir3B%2bl9vFOGbA%3d _______________________________________________ Kitten mailing list Kitten@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fkitten&data=3D01%7c01%7cmichikos%40microsoft.co= m%7cb5e550e620d143d7a9cb08d351c638cd%7c72f988bf86f141af91ab2d7cd011db47%7c1= &sdata=3DAhUkMRzx8gVSJ8k%2f9ctr7%2bA6H329ksir3B%2bl9vFOGbA%3d From nobody Mon Mar 21 17:40:23 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6740512D168; Mon, 21 Mar 2016 17:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkZ6kUDn0iDT; Mon, 21 Mar 2016 17:40:20 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2E412D16E; Mon, 21 Mar 2016 17:40:16 -0700 (PDT) Received: from airhead.fritz.box ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id Yog41s00V10HQrX01ogEwY; Tue, 22 Mar 2016 01:40:14 +0100 Message-ID: <56F0945E.5070804@openfortress.nl> Date: Tue, 22 Mar 2016 01:39:58 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: draft-ietf-kitten-pkinit-freshness@ietf.org References: <20160321223215.12211.35084.idtracker@ietfa.amsl.com> In-Reply-To: <20160321223215.12211.35084.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 00:40:22 -0000 Hi, > Abstract: > This document describes how to further extend the Public Key > Cryptography for Initial Authentication in Kerberos (PKINIT) > extension [RFC4556] to exchange an opaque data blob that a KDC can > validate to ensure that the client is currently in possession of the > private key during a PKINIT AS exchange. > If I read the draft correctly, then failure of the client to comply with the KDC's idea of proper freshness quoting can end up in an infinite cycle of KRB-ERROR with freshness tokens? There is a remark about receiving the second KRB-ERROR with a freshness token (not of the first) but nothing seems to be limiting the number of freshness token handling cycles. Did I miss that? -Rick From nobody Mon Mar 21 18:39:51 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377E812D111; Mon, 21 Mar 2016 18:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NROa7fu8-zHk; Mon, 21 Mar 2016 18:39:48 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4231E12D0F3; Mon, 21 Mar 2016 18:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=v2ifOo2DJCv4lKVZyx4bLivgC91NJsVhvZpCEhIc2f0=; b=AjDvmd22ZJQFx58uRFLTdnNPiyw9b8s40HgcTmjKM9RQPjeAQmINRmsrB4X1SNbowV5qkEMUo+3TFhxO+r3V98b7F1Z6lZR0zikx7g+gpf9NKPKVQQuUzGCoxE7Z/i9u1rDNh1zybOQc7JkRG3XyZ5vPGD0ZJe4kwj293MiXQ64= Received: from BLUPR0301MB1953.namprd03.prod.outlook.com (10.164.21.23) by BLUPR0301MB1956.namprd03.prod.outlook.com (10.164.21.26) with Microsoft SMTP Server (TLS) id 15.1.443.12; Tue, 22 Mar 2016 01:39:46 +0000 Received: from BLUPR0301MB1953.namprd03.prod.outlook.com ([10.164.21.23]) by BLUPR0301MB1953.namprd03.prod.outlook.com ([10.164.21.23]) with mapi id 15.01.0443.013; Tue, 22 Mar 2016 01:39:46 +0000 From: "Paul Miller (NT)" To: Rick van Rein , "draft-ietf-kitten-pkinit-freshness@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt Thread-Index: AQHRg8GWtCp3jmD5Tk6ckYP7s1nvPZ9knzUAgAAPHEA= Date: Tue, 22 Mar 2016 01:39:45 +0000 Message-ID: References: <20160321223215.12211.35084.idtracker@ietfa.amsl.com> <56F0945E.5070804@openfortress.nl> In-Reply-To: <56F0945E.5070804@openfortress.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: openfortress.nl; dkim=none (message not signed) header.d=none;openfortress.nl; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8600:6913:e926:5952:63fa:d2e6] x-ms-office365-filtering-correlation-id: e4e3b11d-3ba4-4dc1-c98f-08d351f2d986 x-microsoft-exchange-diagnostics: 1; BLUPR0301MB1956; 5:9Wgd4gEir1KXxdxMnlS+WGPfLqmiHWbvYYX1nk2s4/JkVPf7XTUw9EYlUaqzWLOJzt2RnQ+9OEluz+sUP5UYxJP2zhcTsyK7yaPaHHHV/cBiPlBRNvbnUGAywDfv/JhWTDgk5C+7iLvRbp45Kq8jVA==; 24:VU0PRYmhLkd8rqWH0I2Q0YX+Ek6E7DNJbk21/yu2F7FpqnNJuXtbImcjxOlliCiysAaVPbOs+FNVfTyfz/QyRTS96s+GVmcrBlXmFN+boSo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0301MB1956; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR0301MB1956; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0301MB1956; x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(10090500001)(230783001)(10290500002)(76576001)(86362001)(2906002)(551544002)(586003)(5005710100001)(1096002)(33656002)(4326007)(50986999)(3280700002)(10400500002)(1220700001)(54356999)(76176999)(5002640100001)(122556002)(92566002)(77096005)(3660700001)(8990500004)(106116001)(2950100001)(2501003)(5008740100001)(81166005)(102836003)(99286002)(6116002)(189998001)(87936001)(5003600100002)(19580405001)(5001770100001)(5004730100002)(2900100001)(86612001)(74316001)(11100500001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0301MB1956; H:BLUPR0301MB1953.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2016 01:39:46.0140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0301MB1956 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 01:39:50 -0000 The KDC is stateless, so as far as the KDC is concerned there is nothing to= do about that cycle. It is the responsibility of the client not to retry = indefinitely. It's really no different than the behavior already expected of clients with= respect to KDC_ERR_TIME_SKEW and password. If the client cannot agree wit= h a KDC on a time then it needs to stop retrying. The conditions to cause = this are nearly identical as it would require that the client to round-robi= n different KDCs that have sufficient time skew from each other not to acce= pt each other's time/freshness token for password/certificate respectively. -----Original Message----- From: Rick van Rein [mailto:rick@openfortress.nl]=20 Sent: Monday, March 21, 2016 5:40 PM To: draft-ietf-kitten-pkinit-freshness@ietf.org Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt Hi, > Abstract: > This document describes how to further extend the Public Key=20 > Cryptography for Initial Authentication in Kerberos (PKINIT) extension=20 > [RFC4556] to exchange an opaque data blob that a KDC can validate to=20 > ensure that the client is currently in possession of the private key=20 > during a PKINIT AS exchange. > If I read the draft correctly, then failure of the client to comply with th= e KDC's idea of proper freshness quoting can end up in an infinite cycle of= KRB-ERROR with freshness tokens? There is a remark about receiving the se= cond KRB-ERROR with a freshness token (not of the first) but nothing seems = to be limiting the number of freshness token handling cycles. Did I miss t= hat? -Rick From nobody Tue Mar 22 00:09:59 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC40712D1AD; Tue, 22 Mar 2016 00:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6GIuBlTKfoE; Tue, 22 Mar 2016 00:09:56 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A5012D603; Tue, 22 Mar 2016 00:09:55 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id Yv9q1s00X10HQrX01v9sSe; Tue, 22 Mar 2016 08:09:52 +0100 Message-ID: <56F0EFBD.90800@openfortress.nl> Date: Tue, 22 Mar 2016 08:09:49 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Paul Miller (NT)" References: <20160321223215.12211.35084.idtracker@ietfa.amsl.com> <56F0945E.5070804@openfortress.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" , "draft-ietf-kitten-pkinit-freshness@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 07:09:58 -0000 Hi Paul, > The KDC is stateless, so as far as the KDC is concerned there is nothing to do about that cycle. And so it should be. If anything is done to defend against infinite looping clients it should probably take the form of bulk defense against attackish patterns. > It is the responsibility of the client not to retry indefinitely. May I suggest that you state that in the text? The current draft is a procedure, and could benefit from invariant statements to clarify the cases that fall outside of the intended procedure. Thanks, -Rick From nobody Tue Mar 22 05:47:47 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8949012D69A; Tue, 22 Mar 2016 05:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJuYQNLYFUWx; Tue, 22 Mar 2016 05:47:45 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE77C12D690; Tue, 22 Mar 2016 05:47:44 -0700 (PDT) X-AuditID: 12074423-3efff70000003d03-6e-56f13eeff68f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 24.8A.15619.FEE31F65; Tue, 22 Mar 2016 08:47:43 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u2MClgnG032531; Tue, 22 Mar 2016 08:47:43 -0400 Received: from [18.101.8.177] (vpn-18-101-8-177.mit.edu [18.101.8.177]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2MCldvl015776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 22 Mar 2016 08:47:40 -0400 To: Rick van Rein , "Paul Miller (NT)" References: <20160321223215.12211.35084.idtracker@ietfa.amsl.com> <56F0945E.5070804@openfortress.nl> <56F0EFBD.90800@openfortress.nl> From: Greg Hudson X-Enigmail-Draft-Status: N1110 Message-ID: <56F13EEB.70502@mit.edu> Date: Tue, 22 Mar 2016 08:47:39 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F0EFBD.90800@openfortress.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42IRYrdT131v9zHM4MYmY4urqzoYLY5uXsVi 8WnZZmaLp6/usTmweCxZ8pPJo3XHX3aPDf+a2AKYo7hsUlJzMstSi/TtErgyXp57w1rQwV1x csENlgbGfxxdjJwcEgImEs/3H2TqYuTiEBJoY5KYdukGlLORUWLzloOMEM4RJokDl3cygbQI C3hL3DzWyQpiiwjESOze3AAWFxJ4wCixqo0ZpIFZoJ9R4v+XU4wgCTYBZYn1+7eyQOyTk+jt ngRm8wqoSHy+Mx1sEIuAqsTnn3vB6kUFIiSezD3JCFEjKHFy5hOwek4BXYkPO96wg9jMAnoS O67/YoWw5SWat85mnsAoOAtJyywkZbOQlC1gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6aX m1mil5pSuokRHOIuyjsYX/Z5H2IU4GBU4uFt2PAhTIg1say4MvcQoyQHk5Ior5vcxzAhvqT8 lMqMxOKM+KLSnNTiQ4wSHMxKIrzbrYFyvCmJlVWpRfkwKWkOFiVxXkYGBgYhgfTEktTs1NSC 1CKYrAwHh5IE7ytboEbBotT01Iq0zJwShDQTByfIcB6g4TdAaniLCxJzizPTIfKnGBWlxHnb QRICIImM0jy4XnAKSuXY+IpRHOgVYV47kCoeYPqC634FNJgJaLBL5DuQwSWJCCmpBkY5kRyZ V4lirTv32DkaxvfkzpprFJaQ1tDv+ehUrINpypG9P9vzG5Z9F5b1eZ1hUPjBtX9z1d1lq5/d +ShgbvlNuN2zuGOWR+y76fyXp342a883r39iq3WYsVnK51BCHeefqop+ZhcFiT6uCdPqyt6w c/ddWnv/4tpPwdJa0/xbPl7a6q46QYmlOCPRUIu5qDgRAMwz5NwcAwAA Archived-At: Cc: "kitten@ietf.org" , "draft-ietf-kitten-pkinit-freshness@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 12:47:46 -0000 On 03/22/2016 03:09 AM, Rick van Rein wrote: >> It is the responsibility of the client not to retry indefinitely. > > May I suggest that you state that in the text? The current draft is a procedure, and could benefit from invariant statements to clarify the cases that fall outside of the intended procedure. If I understand correctly, we are worried about an infinite loop of AS-REQ -> KDC_ERR_PREAUTH_EXPIRED -> AS-REQ -> ... due to the section 2.5. If we need to alter this text anyway, I don't like the requirement that "If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that includes a freshness token, it MUST retry using the new freshness token." MUSTs are to be used when behavior "is actually required for interoperation or to limit behavior which has potential for causing harm" (RFC 2119 section 6). A client which implements RFC 6113 could respond to KDC_ERR_PREAUTH_EXPIRED the same way it already does, by retrying from the beginning, without affecting interoperability or causing harm. I suggest the following text: If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that includes a freshness token, it SHOULD retry the PKINIT-authenticated AS-REQ using the new freshness token. The client MAY restart the conversation instead. The client MUST limit the number of retries to avoid looping forever in case of a misbehaving KDC. From nobody Tue Mar 22 10:20:34 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9585A12D19A; Tue, 22 Mar 2016 10:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRvZ-rgBfa3D; Tue, 22 Mar 2016 10:20:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:763]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C60812D199; Tue, 22 Mar 2016 10:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GkIh/iX88Te8kGEf172N+TDdmH6fet4aRN8mP3m4Dtw=; b=k55iC8mRLxIsTma+whoe7W1Flb7vJXo50+v36VSCyvyx4eoPKsP6AIZrs6wBtZpNKrOAXbiJUnqy66bhy51GOIQz35H99wI9iDnlOr5lNVhigtCBVOEoDziwOnRijyO327iWt8R3dKKkHHFmfw96Qh6/21PpgbgXduRUiAFV0Pg= Received: from BY1PR03MB1417.namprd03.prod.outlook.com (10.162.127.147) by SN1PR0301MB1966.namprd03.prod.outlook.com (10.163.224.28) with Microsoft SMTP Server (TLS) id 15.1.434.16; Tue, 22 Mar 2016 17:20:12 +0000 Received: from BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) by BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) with mapi id 15.01.0434.021; Tue, 22 Mar 2016 17:20:12 +0000 From: Michiko Short To: Greg Hudson , Rick van Rein , "Paul Miller (NT)" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt Thread-Index: AQHRg8GWvlYn3zxL8kKg64f1UsNf8J9knzUAgAAQtICAAFw4gIAAXmSAgABI8fA= Date: Tue, 22 Mar 2016 17:20:11 +0000 Message-ID: References: <20160321223215.12211.35084.idtracker@ietfa.amsl.com> <56F0945E.5070804@openfortress.nl> <56F0EFBD.90800@openfortress.nl> <56F13EEB.70502@mit.edu> In-Reply-To: <56F13EEB.70502@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:1::409] x-ms-office365-filtering-correlation-id: 2723d4e2-326d-4f43-0a6d-08d3527639f5 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1966; 5:FJNwaeop99ePqi9LlX5TyI5y0r6YT5+/3YoDHEEYU9hDVHyFvS1FG57/BVjUgK5FsDQ6zyfC4G+bqDDIkWrA4e/r1rhlfPxwrtywtjWNyeQs36f/IeZMaaw4VluSdLMfEbSGBtOqvlwAPBaT2LRMuA==; 24:FOVmUkjWmHzdctBs2qWm0j9QIBjJmI5IaiHNX8PhefQV7xIfN40CL9Z9Bm2OLs0mfE/VJrW5ThvjFfn5rj0fKFXB8FK8Mhf0sYFrcpuYzks= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1966; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:SN1PR0301MB1966; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1966; x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(52314003)(24454002)(5001770100001)(122556002)(3660700001)(74316001)(10290500002)(5008740100001)(11100500001)(3280700002)(8990500004)(189998001)(5005710100001)(2900100001)(77096005)(5002640100001)(81166005)(2950100001)(93886004)(5003600100002)(2906002)(10400500002)(4001450100002)(10090500001)(4326007)(2561002)(19580395003)(102836003)(76176999)(99286002)(19580405001)(6116002)(5004730100002)(1096002)(230783001)(586003)(92566002)(76576001)(33656002)(54356999)(106116001)(1220700001)(86362001)(2171001)(87936001)(2421001)(50986999)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1966; H:BY1PR03MB1417.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2016 17:20:11.9788 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1966 Archived-At: Cc: "kitten@ietf.org" , "draft-ietf-kitten-pkinit-freshness@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 17:20:32 -0000 Since the infinite loop problem exists for Kerberos clients already, I woul= d prefer to not specify something since this is an extension to an extensio= n. However, the must is valid. Not sure how we all missed that.=20 "If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that incl= udes a freshness token, it SHOULD retry using the new freshness token." I would really like to get this to last call and get the official IANA numb= er -----Original Message----- From: Greg Hudson [mailto:ghudson@mit.edu]=20 Sent: Tuesday, March 22, 2016 5:48 AM To: Rick van Rein ; Paul Miller (NT) Cc: kitten@ietf.org; draft-ietf-kitten-pkinit-freshness@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt On 03/22/2016 03:09 AM, Rick van Rein wrote: >> It is the responsibility of the client not to retry indefinitely. >=20 > May I suggest that you state that in the text? The current draft is a pr= ocedure, and could benefit from invariant statements to clarify the cases t= hat fall outside of the intended procedure. If I understand correctly, we are worried about an infinite loop of AS-REQ = -> KDC_ERR_PREAUTH_EXPIRED -> AS-REQ -> ... due to the section 2.5. If we need to alter this text anyway, I don't like the requirement that "If= a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that include= s a freshness token, it MUST retry using the new freshness token." MUSTs a= re to be used when behavior "is actually required for interoperation or to = limit behavior which has potential for causing harm" (RFC 2119 section 6). = A client which implements RFC 6113 could respond to KDC_ERR_PREAUTH_EXPIRE= D the same way it already does, by retrying from the beginning, without aff= ecting interoperability or causing harm. I suggest the following text: If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that includes a freshness token, it SHOULD retry the PKINIT-authenticated AS-REQ using the new freshness token. The client MAY restart the conversation instead. The client MUST limit the number of retries to avoid looping forever in case of a misbehaving KDC.