From nobody Mon Mar 2 11:23:41 2015 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 866751A88EA for ; Mon, 2 Mar 2015 11:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0Voh3jOwOart for ; Mon, 2 Mar 2015 11:23:39 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id EF31E1A6FF9 for ; Mon, 2 Mar 2015 11:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1425324218; d=isode.com; s=selector; i=@isode.com; bh=lgbzHvyIr+Bdajqe6T89n6qDKW1WkznYGF5t7EVlrdE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=FGxowJSjYWrnfqgaPmG43qLiz+CJE0yuQAvlC3H2gEsCSFnI3kHwLx/6svWHGdXMqEFm2I PI+eGQHRLPEek6aNpEo9zJG/r+gPvdiUFkSGlSYf1xAidOPQaDagEJwIKvpsjpphHoV4CY wbKPSrWnGq9a2VuJ+ikfwLpRC7PNHn4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 2 Mar 2015 19:23:37 +0000 Message-ID: <54F4B8B8.8090406@isode.com> Date: Mon, 02 Mar 2015 19:23:36 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: Simon Josefsson , Tony Hansen References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> In-Reply-To: <87zj82f1yj.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding 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: Mon, 02 Mar 2015 19:23:40 -0000 On 25/02/2015 15:25, Simon Josefsson wrote: > Tony Hansen writes: > >> On 2/24/15 6:56 AM, Stephen Farrell wrote: >>> But in addition, there were two substantive issues that ought be >>> resolved before IETF LC: >>> >>> 1. a new channel binding or requiring tls-session-hash (and I guess >>> some explanatory text about why that is good/needed) >> To recap: >> >> Simon Josefsson made this comment: >> >>> Since SCRAM was published, we have learned that the tls-unique channel >>> binding is insecure -- it would be nice if we could combine the SHA256 >>> update with another default channel binding type to resolve that >>> problem. In my view, the problem with SCRAM today isn't primarily its >>> use of SHA1 but it's broken channel binding. >> Martin Thompson responded: >> >>> We have a solution for that: >>> https://tools.ietf.org/html/draft-ietf-tls-session-hash >> I've read through tls-session-hash and am unsure how to proceed here. >> >> One of my goals when proposing SCRAM-SHA-256 was to not change the >> protocol at all, other than updating the hash algorithm. >> >> I'm not sure how to incorporate a recommendation for session hashing >> here. I'm thinking this would be best handled by adding something to >> the Security Considerations section. Does that seem right? >> >> Would anyone be willing to suggest text changes for these comments? > I believe the problem is that RFC 5802 is insecure as currently > specified, and we are bringing this up as a problem with your draft, > which is unfair to you since the problem was not introduced by you. > > If people like the tls-session-hash approach (I'm not in that category, > but there may be consensus around it), the proper fix is to update RFC > 5802 and reference tls-session-hash as a normative reference. This will > take care of the problem, as you could copy that text into your > document. If you are looking for a text change here, it would be: > > To be secure SCRAM-SHA-256-PLUS has to be used over a TLS channel that > MUST have [TLS-SESSION-HASH] negotiated. > > Personally, I would prefer to change to another mandatory channel > binding that is secure for all TLS versions. Before we make the decisions between referencing tls-session-hash versa a new channel binding, can you sketch out how the new channel binding is going to be defined? (If we choose to define a new channel binding, I think Kitten WG is the right place for doing this work.) From nobody Mon Mar 2 12:56:25 2015 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 CD51E1A1BCF for ; Mon, 2 Mar 2015 12:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 3lQTTR-agled for ; Mon, 2 Mar 2015 12:56:23 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 B4AB11A0127 for ; Mon, 2 Mar 2015 12:56:22 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:1db3:13ed:7278:5ac4]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t22Ku50Q022237 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 2 Mar 2015 21:56:06 +0100 From: Simon Josefsson To: Alexey Melnikov References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150302:alexey.melnikov@isode.com::LnT9veOJKL8ydbgf:25Nz X-Hashcash: 1:22:150302:kitten@ietf.org::0R087gey8dFc6UGx:7B7R X-Hashcash: 1:22:150302:tony@att.com::kFhWf9p2Q17Ogmzm:MT1i Date: Mon, 02 Mar 2015 21:56:04 +0100 In-Reply-To: <54F4B8B8.8090406@isode.com> (Alexey Melnikov's message of "Mon, 02 Mar 2015 19:23:36 +0000") Message-ID: <87r3t7xgnv.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.6 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding 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: Mon, 02 Mar 2015 20:56:24 -0000 --=-=-= Content-Type: text/plain Alexey Melnikov writes: >> Personally, I would prefer to change to another mandatory channel >> binding that is secure for all TLS versions. > Before we make the decisions between referencing tls-session-hash > versa a new channel binding, can you sketch out how the new channel > binding is going to be defined? Please see: https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJU9M5kAAoJEIYLf7sy+BGds8wH/0wZpv5pSJBUrM+ifG9vopK8 JEKjGeESQBVvays4rwiIXXR29sjhX7mJQBuIGnQpd4tjnkdS/FEMvN9CFIqvoRJ0 N1YSqVGO/BBl0zzt2xHrGZiYW+tVM3OzwJFQKoVz0033Yc4S6bIElcFAa+QHY+rU Vfay++0VTRLykaF2vOpYRfKxhBCZkxuluwj9pZChJ+4gW0tB5ID/7H6GfPWBQ2Uc PePcU8lxSI9f18TXnUMxIDl8ClPAurMZaALJ5OER6jkwT768yiHOWjPgOrwEGVpS KWldW7qvmDfmH7EAWiDKwnR1iJJHgvK4kLVXMavGHAmYWZ18BIo/j/Gextrt5H4= =LEVv -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 4 03:08:40 2015 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 6707B1A1B71 for ; Wed, 4 Mar 2015 03:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7lKp37txhvJQ for ; Wed, 4 Mar 2015 03:08:37 -0800 (PST) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4CA1A1B49 for ; Wed, 4 Mar 2015 03:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1425467316; d=isode.com; s=selector; i=@isode.com; bh=DjrDkdP7FfkRMTzS+Y277i3mclNVtgbj0LHu+DaVx/k=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=EIIH8Vnco++om3jDs3wAHVPa9Vyhjpvq6l5Xv1P13W1SccJ8y3Ayefoo2TUaE72YdQ17Fa kNZpgtCycr5Ju8XPmTV13qSdnZylKXRSznWT6Ph1tsSl1RZiTqgB2mMQbDFtim4GDAjqMc Hc6IOy2vocwbAuCQ2ztnIRao5Jxq1Jc=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 4 Mar 2015 11:08:35 +0000 Message-ID: <54F6E7A6.5020403@isode.com> Date: Wed, 04 Mar 2015 11:08:22 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: Simon Josefsson References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <87r3t7xgnv.fsf@latte.josefsson.org> In-Reply-To: <87r3t7xgnv.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding 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: Wed, 04 Mar 2015 11:08:38 -0000 Hi Simon, On 02/03/2015 20:56, Simon Josefsson wrote: > Alexey Melnikov writes: > >>> Personally, I would prefer to change to another mandatory channel >>> binding that is secure for all TLS versions. >> Before we make the decisions between referencing tls-session-hash >> versa a new channel binding, can you sketch out how the new channel >> binding is going to be defined? > Please see: > https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 Great. Missed this earlier. I am fine to recommend using your channel binding from draft-josefsson-sasl-tls-cb-03. I sent you a question about draft-josefsson-sasl-tls-cb-0. If you think they should be discussed on the mailing list, feel free to reply to my private email and CC the mailing list. From nobody Thu Mar 5 09:58:01 2015 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 7EBB11A212D for ; Thu, 5 Mar 2015 09:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 h4B65wYTxqYX for ; Thu, 5 Mar 2015 09:57:59 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 E13FA1A1EF4 for ; Thu, 5 Mar 2015 09:57:58 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t25HvwFJ004079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 5 Mar 2015 12:57:58 -0500 Received: from vpn-51-119.rdu2.redhat.com (vpn-51-119.rdu2.redhat.com [10.10.51.119]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t25HvplR025755 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 5 Mar 2015 12:57:58 -0500 Message-ID: <1425578271.2715.5.camel@redhat.com> From: Nathaniel McCallum To: kitten@ietf.org Date: Thu, 05 Mar 2015 12:57:51 -0500 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: [kitten] Kerberos Service Discovery using DNS 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, 05 Mar 2015 17:58:00 -0000 I have uploaded a new draft: http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/ If you'd like to discuss it, reply to this message. :) Nathaniel From nobody Thu Mar 5 14:21:25 2015 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 6005D1A9025 for ; Thu, 5 Mar 2015 14:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 y9o81ijLZvgN for ; Thu, 5 Mar 2015 14:21:21 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AABC1A9074 for ; Thu, 5 Mar 2015 14:21:21 -0800 (PST) Received-SPF: none (cmu.edu: No applicable sender policy available) receiver=smtp02.srv.cs.cmu.edu; identity=mailfrom; envelope-from="jhutz@cmu.edu"; helo="[128.2.193.239]"; client-ip=128.2.193.239 Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id t25MLI3J010960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 5 Mar 2015 17:21:19 -0500 (EST) Message-ID: <1425594078.10529.74.camel@MINBAR.FAC.CS.CMU.EDU> From: Jeffrey Hutzelman To: Benjamin Kaduk Date: Thu, 05 Mar 2015 17:21:18 -0500 In-Reply-To: References: <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> <5492032F.9050607@mit.edu> <20141217230505.GD9443@localhost> <20141220001633.GD12662@localhost> <1421269970.18482.184.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Archived-At: Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] RFC2743 errata 4251 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, 05 Mar 2015 22:21:23 -0000 On Wed, 2015-02-25 at 11:40 -0500, Benjamin Kaduk wrote: > Section 2.2.4 says: > > o GSS_S_FAILURE indicates that the context is recognized, but that > the GSS_Process_context_token() operation could not be performed > for reasons unspecified at the GSS-API level. > > It should say: > > o GSS_S_FAILURE indicates that the context is recognized, but > either the GSS_Process_context_token() operation could not be > performed for reasons unspecified at the GSS-API level, or the peer > had an error consuming the last context token sent to it. The latter > occurs when the local side became fully established and produced one > last token which was sent to the peer, but the peer encountered an > error while processing that last context token. In either case the > minor status code provides additional information. > > In the case of successful processing of error tokens, the minor > status code provides information from the input token. The display > string outputs of GSS_Display_status() as applied to such minor > status codes should indicate that the error originated on the remote > peer, along with the nature of the error. Note that there is no > way to distinguish failures of GSS_Process_context_token() from > error token information other than to read the human-readable status > display strings. Sounds good. From nobody Fri Mar 6 12:02:27 2015 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 7FFF71A7018 for ; Fri, 6 Mar 2015 12:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 l7Q2R6GWEHHL for ; Fri, 6 Mar 2015 12:02:24 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F58A1A6FF2 for ; Fri, 6 Mar 2015 12:02:24 -0800 (PST) X-AuditID: 12074424-f79356d000004839-cc-54fa07cebfd2 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.FD.18489.FC70AF45; Fri, 6 Mar 2015 15:02:23 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t26K2MEt008078 for ; Fri, 6 Mar 2015 15:02:22 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t26K2KcV010169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 6 Mar 2015 15:02:22 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t26K2Kxx004858; Fri, 6 Mar 2015 15:02:20 -0500 (EST) Date: Fri, 6 Mar 2015 15:02:20 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUixCmqrHue/VeIwaPlXBZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvKpC9gK5nJXTNzYwdzAuJazi5GTQ0LARGLmrBZGCFtM4sK9 9WxdjFwcQgKLmSQ+r++Hco4xSnQcX8IE4VxnktgzZwILSIuQQL3ErI9dbCA2i4CWxIFzk8Bs NgEViZlvNoLZIgLCEru3vmMGsYUF4iTe/LgM1ssr4CDx5NElsNWiAjoSq/dPgYoLSpyc+QTM ZgaauXz6NpYJjHyzkKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGuul5tZopeaUrqJ ERRO7C4qOxibDykdYhTgYFTi4e2Q+hkixJpYVlyZe4hRkoNJSZRXkuFXiBBfUn5KZUZicUZ8 UWlOavEhRgkOZiUR3r4vQOW8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwc ShK8s9iAhgoWpaanVqRl5pQgpJk4OEGG8wANLwGp4S0uSMwtzkyHyJ9iVJQS5z0JkhAASWSU 5sH1wuL9FaM40CvCvBNAqniAqQKu+xXQYCagwVpiP0AGlyQipKQaGI2Y10m/KVruuNtkRy9b h0PdxO/cGUsS7tzfYVBsmV79s/TRn61XPvfONuAuVd+uUaQV/fDcAQMP9n+FlmdnlTxLnau5 o1Gwd4meoG7QRcfZVpcvxBwRO6SiX+8ROL/7gkBU0azjk+aozdi5qndbdqbWatnp3Q6caxaa 2yW9U/KQeWIkp38rWomlOCPRUIu5qDgRABh65FDSAgAA Archived-At: Subject: [kitten] Fwd: New Version Notification for draft-kaduk-kitten-des-des-des-die-die-die-00.txt 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: Fri, 06 Mar 2015 20:02:26 -0000 It's probably about time to start thinking about deprecating RC4/3DES... -Ben ---------- Forwarded message ---------- Date: Fri, 6 Mar 2015 14:48:48 -0500 From: internet-drafts@ietf.org To: Michiko Short , Benjamin Kaduk , Michiko Short , Benjamin Kaduk Subject: New Version Notification for draft-kaduk-kitten-des-des-des-die-die-die-00.txt A new version of I-D, draft-kaduk-kitten-des-des-des-die-die-die-00.txt has been successfully submitted by Benjamin Kaduk and posted to the IETF repository. Name: draft-kaduk-kitten-des-des-des-die-die-die Revision: 00 Title: Deprecate 3DES and RC4 in Kerberos Document date: 2015-03-06 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-kaduk-kitten-des-des-des-die-die-die-00.txt Status: https://datatracker.ietf.org/doc/draft-kaduk-kitten-des-des-des-die-die-die/ Htmlized: http://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00 Abstract: The 3DES and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should be begun for their use in Kerberos. 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. The IETF Secretariat From nobody Fri Mar 6 12:28:11 2015 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 3E6A81A702A for ; Fri, 6 Mar 2015 12:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 WSg-pzgCY97I for ; Fri, 6 Mar 2015 12:28:08 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD93E1A7023 for ; Fri, 6 Mar 2015 12:28:08 -0800 (PST) Received: by iecrp18 with SMTP id rp18so20712782iec.10 for ; Fri, 06 Mar 2015 12:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zBv2UfwefOkvv4p38+t1dojpN3p3qApxUF5U1zPFb7Y=; b=MvF7cTZ+JVmPwqr/94kUxTQQny+kjsxTLXG+w4deKhVLWq0jHAPMcrwpT4cAmfjIez hg9EAY70G7EgRiMQYYuq0XIDK4PCBVEUQ0n+dvGB2cjCkFqpQHDLd/u3GEXoEVq4kztx jmiUdCTWqYwF9h6Ik7b/+QWs7WFjgvNrcQUFUr9k2afO2xdsiHO/k1Ro8FgCVi0GkKhX YwacHG2kjirNNTZt+Tw0c5bUZqOBGlyqj/+AmSv9qZ3ClmsKXIPwslBjBnehIEYYN0vK naZ+3OqKl92e2/+AzcZ98kvx2j3ho0vv/37V+a5htgr1HSfwHeIiXTXY2OQTsre/+p67 QnJQ== MIME-Version: 1.0 X-Received: by 10.43.63.80 with SMTP id xd16mr12824806icb.21.1425673688186; Fri, 06 Mar 2015 12:28:08 -0800 (PST) Received: by 10.64.17.38 with HTTP; Fri, 6 Mar 2015 12:28:08 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Mar 2015 15:28:08 -0500 Message-ID: From: Chaskiel Grundman To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: New Version Notification for draft-kaduk-kitten-des-des-des-die-die-die-00.txt 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: Fri, 06 Mar 2015 20:28:10 -0000 I'm not going to object to the principle of deprecating DES3, but claiming that AES "quickly followed" DES3 is inaccurate. The first mention of DES3 in the mit krb5 commit history is Author: tytso Date: Thu Jan 11 03:29:50 1996 +0000 Fix return type for mit_des3_string_to_key(). git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@7297 dc483132-0cff-0310-8789-dd5450dbe970 It also appeared in the first heimdal release in 1999 (but GSSAPI did not interop with MIT until somewhere between late 0.3 and 0.6.) Some AES code appeared in MIT krb5 in 2003, but I don't know if it corresponds to what was standardized in rfc3962 in 2005. Heimdal did not release AES until 0.7 in 2005 From nobody Fri Mar 6 12:49:37 2015 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 CD1B71A7034 for ; Fri, 6 Mar 2015 12:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 a3A4mEfa947x for ; Fri, 6 Mar 2015 12:49:34 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420FE1A6F12 for ; Fri, 6 Mar 2015 12:49:33 -0800 (PST) X-AuditID: 12074425-f79846d0000054e1-e1-54fa12dcc6bb 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 dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id FF.9C.21729.CD21AF45; Fri, 6 Mar 2015 15:49:32 -0500 (EST) 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 t26KnQnP001687; Fri, 6 Mar 2015 15:49:26 -0500 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t26KnOE5026863; Fri, 6 Mar 2015 15:49:25 -0500 From: Tom Yu To: Chaskiel Grundman References: Date: Fri, 06 Mar 2015 15:49:24 -0500 In-Reply-To: (Chaskiel Grundman's message of "Fri, 6 Mar 2015 15:28:08 -0500") Message-ID: Lines: 33 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrXtH6FeIwfFFXBavPzxjsTi6eRWL A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxs+k/S8Fxropb93cwNTDu5ehi5OSQEDCR WNV3iRXCFpO4cG89WxcjF4eQwGImiWdLj0A5Gxgl5l6fzgzhvGaUuLRuHTtIC5uAtMTxy7uY QGwRAW2JdZ/vAnVwcDALmEr8+2EFEhYWyJS43PQabIOQQDujRMfaYhCbRUBV4vTc3UwgMzkF pjJKvH3bCzaTV0BX4vn+cywgc3gEOCXaN/pAhAUlTs58wgJiMwtoSdz495JpAqPALCSpWUhS CxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFula6OVmluilppRuYgQFJLuL6g7GCYeUDjEKcDAq 8fB2SP0MEWJNLCuuzD3EKMnBpCTKO5P7V4gQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd6+L0Dl vCmJlVWpRfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIcHEoSvNGCQEMFi1LTUyvSMnNK ENJMHJwgw3mAhu8CqeEtLkjMLc5Mh8ifYtTlODR7z0wmIZa8/LxUKXHeWSBFAiBFGaV5cHNg ieQVozjQW8K86SBVPMAkBDfpFdASJqAlWmI/QJaUJCKkpBoYIybPO5V6aInG5vKHkbM3Zs7o Xpawy/bxL3m10oOVvypFivZnc0wq38l19pqAANMEh69TfjdumHRo2TGpKSd31e/3OLqTrX7p 22CZ1Qt7BU4ZNPbVJHBwzIq9FXesuve1cchyy9+OV99s5Q1amNjz6wS3zxt2kbmTfLWWXJvN JrOj/BHfXf31y5VYijMSDbWYi4oTAVkFS2//AgAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: New Version Notification for draft-kaduk-kitten-des-des-des-die-die-die-00.txt 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: Fri, 06 Mar 2015 20:49:37 -0000 Chaskiel Grundman writes: > I'm not going to object to the principle of deprecating DES3, but > claiming that AES "quickly followed" DES3 is inaccurate. The first > mention of DES3 in the mit krb5 commit history is > > Author: tytso > Date: Thu Jan 11 03:29:50 1996 +0000 > > Fix return type for mit_des3_string_to_key(). > > > git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@7297 > dc483132-0cff-0310-8789-dd5450dbe970 I believe that krb5-1.2 (around 2000) was the first to have substantial support for DES3. krb5-1.1 (around 1999) only supported it for ticket encryption, not session keys. It might also have been a variant that didn't do key derivation. > It also appeared in the first heimdal release in 1999 (but GSSAPI did > not interop with MIT until somewhere between late 0.3 and 0.6.) > > Some AES code appeared in MIT krb5 in 2003, but I don't know if it > corresponds to what was standardized in rfc3962 in 2005. Heimdal did > not release AES until 0.7 in 2005 Thanks for the historical information. I think it's most important to note that we believe that deployed code that supports DES3 but not AES is rare, partly as a result of this history. Please provide some more details if there is evidence to the contrary. -Tom From nobody Fri Mar 6 13:43:32 2015 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 F088D1A8762 for ; Fri, 6 Mar 2015 13:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Umt_Wcmpd7hg for ; Fri, 6 Mar 2015 13:43:29 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797D21A8735 for ; Fri, 6 Mar 2015 13:43:29 -0800 (PST) X-AuditID: 1209190c-f79696d000005933-90-54fa1f808dd2 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 8C.AB.22835.08F1AF45; Fri, 6 Mar 2015 16:43:28 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t26LhRGn022764; Fri, 6 Mar 2015 16:43:28 -0500 Received: from [18.101.8.131] (vpn-18-101-8-131.mit.edu [18.101.8.131]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t26LhPfi013135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 Mar 2015 16:43:27 -0500 Message-ID: <54FA1F7D.2050703@mit.edu> Date: Fri, 06 Mar 2015 16:43:25 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Nathaniel McCallum , kitten@ietf.org References: <1425578271.2715.5.camel@redhat.com> In-Reply-To: <1425578271.2715.5.camel@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixCmqrNsg/yvE4NB2aYujm1exWMz9OovV gcljyZKfTB7v911lC2CK4rJJSc3JLEst0rdL4MrY1LKDqWANf8XNRffZGxh38XQxcnJICJhI rNy2lBXCFpO4cG89WxcjF4eQwGImiROv9rGAJIQENjBKdM8rgkgcZpL4/XU+E0iCV0BN4uLq l0A2BweLgKpE750ykDCbgLLE+v1bwXpFBcIkZq+7yAhRLihxcuYTFpByEQF7iYWNCSBhYQEr ic0blzBCrDKQeLl0Fdh0TgFDiZk/VrGB2MwCehI7rv9ihbDlJZq3zmaewCgwC8nUWUjKZiEp W8DIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0EyM4SCV5djC+Oah0iFGAg1GJ h7dD6meIEGtiWXFl7iFGSQ4mJVFePblfIUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEePu+AJXz piRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwioMMFSxKTU+tSMvMKUFI M3FwggznARpuDFLDW1yQmFucmQ6RP8WoKCXO6wWSEABJZJTmwfXCksgrRnGgV4R5w0GqeIAJ CK77FdBgJqDBWmI/QAaXJCKkpBoYWesfxegIbN7198bPawUFi39f2ehra1PxMvnEq2d9Fm6X X5z1s1SPyZrOknBAcf3sbW0+rf8FH175bNS46ODXM+/j/l93q7tr7to4V9lJe0povPST/jWK liWWOs+mr/SbeN9omvCb1+qrY5vPXWS77pl80nYf4/asdR5rHB2vaRvf2uv7SLbBV4mlOCPR UIu5qDgRAFieEMX9AgAA Archived-At: Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Fri, 06 Mar 2015 21:43:32 -0000 On 03/05/2015 12:57 PM, Nathaniel McCallum wrote: > http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/ I'm on board with this in general. Some specific issues to be hashed out: 1. URL formats for basic RFC 4120 over UDP/TCP The draft uses udp://hostname[:port] and tcp://hostname[:port] for these. The IANA registry notes some application-specific precedent for the use of a "udp" scheme but there is no formal spec for it, and there is no registration for "tcp" at all. Obviously these URI schemes are very context-dependent; a generic application such as a web browser would have no idea what to do with a TCP or UDP URL. On the other hand, we are also proposing a very context-specific use of HTTP for MS-KKDCP, and there is a ton of precedent for that (basically any kind of RPC over HTTP). 2. UDP/TCP preference Some implementation guidance may be necessary on this. Implementations are currently used to having their own preference of UDP versus TCP, perhaps based on the packet size. The current draft does allow the URI records to express no preference of UDP versus TCP; one can simply give them the same priority and don't use weights. But if the URI records express a preference, should a client always honor that preference, or can it ignore it--say, if the packet is large? 3. Precedence of URI versus SRV Discussion elsewhere suggested that the URI records, if present, should have precedence over SRV records; if a client finds URI records, it shouldn't do SRV lookups. The draft should probably say that explicitly. 4. Security considerations MS-KKDCP can offer security benefits for Kerberos traffic because it uses TLS. These added protections are mostly lost if unsecured URI records are used to discover the proxy URL. This is not a deal-breaker as there are other reasons to use a proxy, but we should explicitly state this in the security considerations. From nobody Fri Mar 6 13:58:23 2015 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 07EFF1A0167 for ; Fri, 6 Mar 2015 13:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2eZTMCjApVpU for ; Fri, 6 Mar 2015 13:58:19 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 13D051A0100 for ; Fri, 6 Mar 2015 13:58:19 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t26LwInH009167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 6 Mar 2015 16:58:18 -0500 Received: from vpn-62-173.rdu2.redhat.com (vpn-62-173.rdu2.redhat.com [10.10.62.173]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t26LwHJw017914 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 6 Mar 2015 16:58:18 -0500 Message-ID: <1425679096.2550.9.camel@redhat.com> From: Nathaniel McCallum To: Greg Hudson Date: Fri, 06 Mar 2015 16:58:16 -0500 In-Reply-To: <54FA1F7D.2050703@mit.edu> References: <1425578271.2715.5.camel@redhat.com> <54FA1F7D.2050703@mit.edu> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Fri, 06 Mar 2015 21:58:21 -0000 On Fri, 2015-03-06 at 16:43 -0500, Greg Hudson wrote: > On 03/05/2015 12:57 PM, Nathaniel McCallum wrote: > > http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/ > > I'm on board with this in general. Some specific issues to be > hashed out: > > 1. URL formats for basic RFC 4120 over UDP/TCP > > The draft uses udp://hostname[:port] and tcp://hostname[:port] for > these. The IANA registry notes some application-specific precedent > for the use of a "udp" scheme but there is no formal spec for it, > and there is no registration for "tcp" at all. Obviously these URI > schemes are very context-dependent; a generic application such as a > web browser would have no idea what to do with a TCP or UDP URL. On > the other hand, we are also proposing a very context-specific use of > HTTP for MS-KKDCP, and there is a ton of precedent for that > (basically any kind of RPC over HTTP). I think this is a very fair assessment of the situation. Assuming context-dependent usage permits us a certain succinctness. If needed, a prefix for all of these could remove this necessary context. However, we would likely need a different prefix for the KDC and kpasswd cases. > 2. UDP/TCP preference > > Some implementation guidance may be necessary on this. > Implementations are currently used to having their own preference of > UDP versus TCP, perhaps based on the packet size. > > The current draft does allow the URI records to express no > preference of UDP versus TCP; one can simply give them the same > priority and don't use weights. But if the URI records express a > preference, should a client always honor that preference, or can it > ignore it--say, if the packet is large? I would say that the client must never ignore the DNS preference. Large packets are not usually generated on the fly by clients but are either server responses to clients or are the result of server- configured preauth mechs. This means that the server in question has been configured to cause these large packet sizes. Because of this, the DNS preferences should match the server's configuration. Anything other than this is a misconfiguration. I'd be happy to add a statement to this effect in the draft. > 3. Precedence of URI versus SRV > > Discussion elsewhere suggested that the URI records, if present, > should have precedence over SRV records; if a client finds URI > records, it shouldn't do SRV lookups. The draft should probably say > that explicitly. I think this is somewhat implied by section 8. However, I can make an explicit statement to this effect. > 4. Security considerations > > MS-KKDCP can offer security benefits for Kerberos traffic because it > uses TLS. These added protections are mostly lost if unsecured URI > records are used to discover the proxy URL. This is not a deal- > breaker as there are other reasons to use a proxy, but we should > explicitly state this in the security considerations. +1 From nobody Fri Mar 6 14:58:55 2015 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 5D3FE1A6F33 for ; Fri, 6 Mar 2015 14:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 oBeiYiV77Jkm for ; Fri, 6 Mar 2015 14:58:51 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 836FD1A1BC6 for ; Fri, 6 Mar 2015 14:58:51 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t26MwoQW030353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 6 Mar 2015 17:58:50 -0500 Received: from [10.3.113.41] (ovpn-113-41.phx2.redhat.com [10.3.113.41]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t26Mwn3Y004935; Fri, 6 Mar 2015 17:58:50 -0500 Message-ID: <1425682729.2889.24.camel@willson.usersys.redhat.com> From: Simo Sorce To: Greg Hudson Date: Fri, 06 Mar 2015 17:58:49 -0500 In-Reply-To: <54FA1F7D.2050703@mit.edu> References: <1425578271.2715.5.camel@redhat.com> <54FA1F7D.2050703@mit.edu> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Fri, 06 Mar 2015 22:58:53 -0000 On Fri, 2015-03-06 at 16:43 -0500, Greg Hudson wrote: > On 03/05/2015 12:57 PM, Nathaniel McCallum wrote: > > http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/ > > I'm on board with this in general. I like it too. > Some specific issues to be hashed out: > > 1. URL formats for basic RFC 4120 over UDP/TCP > > The draft uses udp://hostname[:port] and tcp://hostname[:port] for > these. The IANA registry notes some application-specific precedent for > the use of a "udp" scheme but there is no formal spec for it, and there > is no registration for "tcp" at all. Obviously these URI schemes are > very context-dependent; a generic application such as a web browser > would have no idea what to do with a TCP or UDP URL. On the other hand, > we are also proposing a very context-specific use of HTTP for MS-KKDCP, > and there is a ton of precedent for that (basically any kind of RPC over > HTTP). > > 2. UDP/TCP preference > > Some implementation guidance may be necessary on this. Implementations > are currently used to having their own preference of UDP versus TCP, > perhaps based on the packet size. > > The current draft does allow the URI records to express no preference of > UDP versus TCP; one can simply give them the same priority and don't use > weights. But if the URI records express a preference, should a client > always honor that preference, or can it ignore it--say, if the packet is > large? I think the client SHOULD use the URI order in preference, but MAY override it if it knows that the packet size will make it impossible to use the URI preferred method. (Ie if the URI makes UDP preferred but the client knows the size for the specific exchange is going to be too large for UDP, it may decide to do straight TCP/MS-KKDCP instead). > 3. Precedence of URI versus SRV > > Discussion elsewhere suggested that the URI records, if present, should > have precedence over SRV records; if a client finds URI records, it > shouldn't do SRV lookups. The draft should probably say that explicitly. +1 > 4. Security considerations > > MS-KKDCP can offer security benefits for Kerberos traffic because it > uses TLS. These added protections are mostly lost if unsecured URI > records are used to discover the proxy URL. This is not a deal-breaker > as there are other reasons to use a proxy, but we should explicitly > state this in the security considerations. True, but DNSSEC may help in this case, so it is not that weak, should be pointed out anyway. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Fri Mar 6 18:43:32 2015 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 B3CFA1A87BF; Fri, 6 Mar 2015 18:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 EBL-vsYXKybB; Fri, 6 Mar 2015 18:43:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFB71A87B3; Fri, 6 Mar 2015 18:43:28 -0800 (PST) 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: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 18:43:28 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 02:43:29 -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 Working Group 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-01.txt Pages : 7 Date : 2015-03-06 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 which 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: http://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-freshness-01 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 9 15:33:57 2015 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 65E5D1ACD6E for ; Mon, 9 Mar 2015 15:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MrthKfJygXon for ; Mon, 9 Mar 2015 15:33:53 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0071A88B0 for ; Mon, 9 Mar 2015 15:33:48 -0700 (PDT) X-AuditID: 1209190d-f792d6d000001fc7-f9-54fe1fcb54eb 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 dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 1B.4F.08135.BCF1EF45; Mon, 9 Mar 2015 18:33:47 -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 t29MXkji030705 for ; Mon, 9 Mar 2015 18:33:47 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t29MXjFJ027470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 9 Mar 2015 18:33:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t29MXj8n025089; Mon, 9 Mar 2015 18:33:45 -0400 (EDT) Date: Mon, 9 Mar 2015 18:33:44 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixG6nonta/l+IQd9eCYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY8Nqi4J3TBUzPl1jbmBcxNTFyMkhIWAi8fvebBYIW0ziwr31 bF2MXBxCAouZJKZP+8MK4RxjlNg0rxfKuc4k0fDlJiNIi5BAvcTK6y3MIDaLgJZE2/ep7CA2 m4CKxMw3G9lAbBEBYYndW9+B1QgLqEtcvbqXFcTmFXCQuPl6E5gtKqAjsXr/FBaIuKDEyZlP wGxmoJnLp29jmcDINwtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6Rnq5mSV6qSml mxhBwcQpybuD8d1BpUOMAhyMSjy8Aqf/hAixJpYVV+YeYpTkYFIS5VUR/xcixJeUn1KZkVic EV9UmpNafIhRgoNZSYTXnQ0ox5uSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivD waEkwftQDqhRsCg1PbUiLTOnBCHNxMEJMpwHaPgekBre4oLE3OLMdIj8KUZdjgXt+2cyCbHk 5eelSonzXgQpEgApyijNg5sDSwKvGMWB3hLmzQGp4gEmELhJr4CWMAEtYWf+A7KkJBEhJdXA yB49Y/HleedjvfiiFZkvJV7elHvuqIfmBqsG3VCbtjvvS0uvNkcoym++el1RZNHCJ6r2jyzb H/auNLPOuCgdyWTHde6U/82dV6c7TZhaZH1hnZnguRVHJwtdKHwyjc10cd8Bo9rn1pcfnxV5 FXXDVvc8/7/LUlv63x+9xD4x6M0tzSMHHE63nlJiKc5INNRiLipOBAAPX5453QIAAA== Archived-At: Subject: [kitten] draft agenda for Dallas posted 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: Mon, 09 Mar 2015 22:33:55 -0000 Hi all, I posted [1] a draft agenda based on the responses received when we received scheduling requests. My notes from then seem incomplete, though, so please double-check if you think you requested a slot. Please let the chairs know if you would like to request a change to the agenda. Thank you, Ben [1] http://tools.ietf.org/wg/kitten/agenda From nobody Mon Mar 9 15:59:46 2015 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 C9E831ACE2D; Mon, 9 Mar 2015 15:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 S2z8REQdrn9v; Mon, 9 Mar 2015 15:59:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFC41ACE23; Mon, 9 Mar 2015 15:59:24 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309225924.25360.58204.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 15:59:24 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-cammac-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:59:35 -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 Working Group of the IETF. Title : Kerberos Authorization Data Container Authenticated by Multiple MACs Authors : Simo Sorce Tom Yu Thomas Hardjono Filename : draft-ietf-kitten-cammac-02.txt Pages : 10 Date : 2015-03-09 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-cammac-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-cammac-02 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 9 15:59:47 2015 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 9C1D01ACE35; Mon, 9 Mar 2015 15:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3q-Ns74uditD; Mon, 9 Mar 2015 15:59:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC051ACE25; Mon, 9 Mar 2015 15:59:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , "RFC Editor" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309225924.25360.25614.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 15:59:24 -0700 Archived-At: Subject: [kitten] New Version Notification - draft-ietf-kitten-cammac-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:59:42 -0000 A new version (-02) has been submitted for draft-ietf-kitten-cammac: http://www.ietf.org/internet-drafts/draft-ietf-kitten-cammac-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-cammac-02 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. IETF Secretariat. From nobody Mon Mar 9 15:59:49 2015 Return-Path: X-Original-To: expand-draft-ietf-kitten-cammac.all@virtual.ietf.org Delivered-To: kitten@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 491591ACE37; Mon, 9 Mar 2015 15:59:42 -0700 (PDT) X-Original-To: xfilter-draft-ietf-kitten-cammac.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-kitten-cammac.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1D01ACE35; Mon, 9 Mar 2015 15:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3q-Ns74uditD; Mon, 9 Mar 2015 15:59:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC051ACE25; Mon, 9 Mar 2015 15:59:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , "RFC Editor" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309225924.25360.25614.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 15:59:24 -0700 Archived-At: Subject: [kitten] New Version Notification - draft-ietf-kitten-cammac-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:59:42 -0000 A new version (-02) has been submitted for draft-ietf-kitten-cammac: http://www.ietf.org/internet-drafts/draft-ietf-kitten-cammac-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-cammac-02 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. IETF Secretariat. From nobody Mon Mar 9 18:05:11 2015 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 77B591ACEDE for ; Mon, 9 Mar 2015 18:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fM4y-2gspo3m for ; Mon, 9 Mar 2015 18:05:07 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 256CC1ACED9 for ; Mon, 9 Mar 2015 18:05:06 -0700 (PDT) X-AuditID: 12074422-f79d16d0000024cf-c5-54fe4342c7be Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 22.69.09423.2434EF45; Mon, 9 Mar 2015 21:05:06 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2A155VW020815 for ; Mon, 9 Mar 2015 21:05:06 -0400 Received: from [18.101.8.208] (vpn-18-101-8-208.mit.edu [18.101.8.208]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2A154Sq008963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 9 Mar 2015 21:05:05 -0400 Message-ID: <54FE4340.4070400@mit.edu> Date: Mon, 09 Mar 2015 21:05:04 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: kitten@ietf.org References: <20150309225924.25360.58204.idtracker@ietfa.amsl.com> In-Reply-To: <20150309225924.25360.58204.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixCmqrOvk/C/EYMtKaYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY+aj+6wFd4QqTq96y9zA+IKvi5GTQ0LAROL7n63MELaYxIV7 69m6GLk4hAQWM0lcvXSOBSQhJHCMUeLI/FyIxE0miU+zr4EleAXUJLr6ZoHZLAKqEh2Xe9lA bDYBZYn1+7eCxUUFwiRmr7vICFEvKHFy5hOwuIiAsMTure/ANgsLOEr86D3ECrHMUWLpk1Ng NZwCThJ9LbvBbGYBPYkd13+xQtjyEs1bZzNPYBSYhWTsLCRls5CULWBkXsUom5JbpZubmJlT nJqsW5ycmJeXWqRrqpebWaKXmlK6iREUlOwuSjsYfx5UOsQowMGoxMPLYPIvRIg1say4MvcQ oyQHk5Iob6kjUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr4QWUI43JbGyKrUoHyYlzcGiJM67 6QdfiJBAemJJanZqakFqEUxWhoNDSYLX3wmoUbAoNT21Ii0zpwQhzcTBCTKcB2j4GpAa3uKC xNzizHSI/ClGRSlx3jqQhABIIqM0D64XljReMYoDvSLMuwfkbh5gwoHrfgU0mAloMDvzH5DB JYkIKakGxhDmO/9DGaYu8Fg9oVPtmP7i948+6kvenFp9Mq7+5OGNAddC/lRffl2kZ7nM/8Or /TNvfDZOWnHFSengwk18a3ZeMouPfhAVc3pbLevj/vkFt6OjdwoFN0sc3/j3j9qu+sUd3SVL ixYI7fllL3xV942C7e3F+vH7O+X0A7OU8v5qKctukzqzoEyJpTgj0VCLuag4EQAQFTqX9QIA AA== Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-cammac-02.txt 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: Tue, 10 Mar 2015 01:05:09 -0000 On 03/09/2015 06:59 PM, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-cammac-02 I'm not sure the new wording is quite right. The new draft contains: A KDC SHOULD only make verbatim copies of CAMMAC contents to a new CAMMAC when it has authenticated the CAMMAC as originating from a local realm KDC [...] When a KDC makes verbatim copies of CAMMAC contents to a new CAMMAC without having authenticated the first CAMMAC as originating from a local realm KDC, it SHOULD NOT apply a kdc-verifier to the new CAMMAC. The first recommendation doesn't contain an exception for ticket modification requests, where it is safe to copy a CAMMAC with only an svc-verifier as long as the new CAMMAC also contains only an svc-verifier. The second recommendation is confusing because it seems to apply only to a situation where the KDC is already violating the first SHOULD. One possible exception is when a realm's policy allows a KDC to make a verbatim copy of CAMMAC contents from a cross-realm TGT from designated "fully-trusted" remote realms. The local realm KDC can safely apply a kdc-verifier to a new CAMMAC based on the cross- realm TGT, because the client realm name in the resulting new ticket will be that of the remote realm. The presence of a remote client realm name allows the local realm KDC to identify the originator of the CAMMAC contents as being a remote realm. I agree with the first sentence but not the other two. I don't think the client principal communicates the origin of all CAMMAC assertions. For example, the authorization data in a CAMMAC might assert something like "this client principal is a member of the wheel group," where the client principal is in a foreign realm and "wheel" is in a group namespace applying to the server realm. Such an assertion should hopefully come from, or be explicitly vetted by, the server realm's KDC, not the foreign client realm. The KDC might have a policy which says that the foreign realm is higher-privilege and uses the same group namespace, but that would be a deliberate decision to trust the foreign realm, not a safe decision based on how the resulting CAMMAC will be interpreted. Also, a typo: "KDCM AY" should be "KDC MAY". From nobody Mon Mar 9 19:28:33 2015 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 C32811A00BD for ; Mon, 9 Mar 2015 19:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 n3FahQcbX7aY for ; Mon, 9 Mar 2015 19:28:30 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2951A0058 for ; Mon, 9 Mar 2015 19:28:10 -0700 (PDT) X-AuditID: 1209190f-f79546d000007593-a6-54fe56b48bcb 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 dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id C7.10.30099.9B65EF45; Mon, 9 Mar 2015 22:28:09 -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 t2A2Rrw3028966; Mon, 9 Mar 2015 22:27:54 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2A2Rpre002732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Mar 2015 22:27:52 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2A2Ro8D024551; Mon, 9 Mar 2015 22:27:50 -0400 (EDT) Date: Mon, 9 Mar 2015 22:27:50 -0400 (EDT) From: Benjamin Kaduk To: Tom Yu In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nrrsz7F+IwZs2TYvXH56xWBzdvIrF gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mro6P7EWNDHWjHj4DuWBsZ2li5GTg4JAROJ K31H2CFsMYkL99azdTFycQgJLGaSmHJlFiOEs4FRYvLLV6wQzkEmiQfnfzOCtAgJ1Eu82TMf rJ1FQEvi+bNjbCA2m4CKxMw3G8FsEQFJiWNPzjOD2MwCNhLrPy8DGsTBISyQLfF5lh9ImFNA T+Lr5ltg5bwCDhL3L3+E2rWcUeLd1Zlgp4oK6Eis3j+FBaJIUOLkzCcsEDO1JJZP38YygVFw FpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9HIzS/RSU0o3MYJClVOSfwfjt4NK hxgFOBiVeHhXGP4LEWJNLCuuzD3EKMnBpCTKaxcCFOJLyk+pzEgszogvKs1JLT7EKMHBrCTC K6EFlONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuBdCTJUsCg1PbUi LTOnBCHNxMEJMpwHaHhFKMjw4oLE3OLMdIj8KUZdjgXt+2cyCbHk5eelSonzTgApEgApyijN g5sDSzGvGMWB3hLmPQxSxQNMT3CTXgEtYQJaws78B2RJSSJCSqqBcdqNzKec55ST0h6f9/CY +99GmVm9mHvus6ZC5Zc8YS4eT+INu0yKuuZLXpI+8zknReNYYG95yy29POHnO4K6jTMPnrjw YlFS7BX3m582mOXWhvybo8p0eF+n58GPLw9Ex/fdOcG3TGRKKPPfN4reFhl1Jw301jyrsFC/ VXRtc1ntbeUVd039lFiKMxINtZiLihMBGaCjwwwDAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: New Version Notification for draft-kaduk-kitten-des-des-des-die-die-die-00.txt 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: Tue, 10 Mar 2015 02:28:32 -0000 On Fri, 6 Mar 2015, Tom Yu wrote: > Thanks for the historical information. I think it's most important to > note that we believe that deployed code that supports DES3 but not > AES is rare, partly as a result of this history. Please provide some > more details if there is evidence to the contrary. It was somewhat difficult to tell from just the commit logs when a given feature (enctype) was fully present and functional/supported, since they seem to have come in piecewise everywhere. I'm not sure if release notes are any better, but I agree that we should try to do a better job of research before publishing this document. -Ben From nobody Tue Mar 10 11:29:35 2015 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 031931A8795 for ; Tue, 10 Mar 2015 11:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 8K0u7ZtqammX for ; Tue, 10 Mar 2015 11:29:33 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D8DBF1A87A7 for ; Tue, 10 Mar 2015 11:29:31 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 56C402004F4D4 for ; Tue, 10 Mar 2015 11:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=DqLr2BcjazljHrUomucZ 0qgdn1E=; b=ha5uoOfOb70OKnfV+TDSAcVqx9AdesnVVaLs9OW4+vJ0JGGrTNm1 KRE6hhS3f0KPeoW+6jrGsefDk5PWgEY9bTurCHoIKuIqvlRTdbvu6iwvrr3cFkh4 s8ZBIIaH8Afh4yHWVohBVV2IHiNNquhv7w+S7AWce4b9YyyMqwTx2Ao= Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 2D6AF2004F4CA for ; Tue, 10 Mar 2015 11:29:30 -0700 (PDT) Received: by igbhn18 with SMTP id hn18so34029365igb.2 for ; Tue, 10 Mar 2015 11:29:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.85.82 with SMTP id p18mr36280047icl.58.1426012169052; Tue, 10 Mar 2015 11:29:29 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Tue, 10 Mar 2015 11:29:28 -0700 (PDT) In-Reply-To: <1425578271.2715.5.camel@redhat.com> References: <1425578271.2715.5.camel@redhat.com> Date: Tue, 10 Mar 2015 13:29:28 -0500 Message-ID: From: Nico Williams To: Nathaniel McCallum Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Tue, 10 Mar 2015 18:29:34 -0000 I am in favor of adopting this proposal, or any proposal like it. Using SRV RRs turns out to be somewhat problematic. As we add transports, we add DNS lookups. It'd be nicer to do one lookup, and get all the information. URI RRs allow this, though I'm not sure that URIs are really what we need here (but that's a detail we can discuss after we adopt). Nico -- From nobody Tue Mar 10 14:27:12 2015 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 A0C091A8A20 for ; Tue, 10 Mar 2015 14:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 P0ncxTv96NTa for ; Tue, 10 Mar 2015 14:27:07 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF471A00F1 for ; Tue, 10 Mar 2015 14:27:07 -0700 (PDT) Received: from [10.0.1.225] ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id 1xT31q00B10HQrX01xT5LQ; Tue, 10 Mar 2015 22:27:05 +0100 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Rick van Rein In-Reply-To: <1425578271.2715.5.camel@redhat.com> Date: Tue, 10 Mar 2015 22:27:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2CB0CE49-2109-4666-9FFA-33538244E84E@openfortress.nl> References: <1425578271.2715.5.camel@redhat.com> To: Nathaniel McCallum X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Tue, 10 Mar 2015 21:27:10 -0000 Hello Nathaniel, > I have uploaded a new draft:=20 > = http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discover= y/ Please consider deprecating the SRV-based procedure; without = deprecation, implementatations are pretty much convicted to implementing = both mechanisms forevermore, which is silly from both KISS and security = viewpoints. Please specify the implications for naming in certificates, such as for = PKINIT. Please do not overlool SCTP; it has the reliability and size-scalability = of TCP but the speed and ordering advantages of UDP. Even when Kerberos = does not currently use SCTP, it may need to in future updates, possibly = to handle large key sizes during PKINIT. I hope this is helpful. Cheers, -Rick= From nobody Tue Mar 10 15:05:49 2015 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 EFF241A8F46 for ; Tue, 10 Mar 2015 15:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ETQaCrxdV0lS for ; Tue, 10 Mar 2015 15:05:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 40F521A9054 for ; Tue, 10 Mar 2015 15:05:46 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2AM5ieY007836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 10 Mar 2015 18:05:44 -0400 Received: from unused (unused [10.10.51.153] (may be forged)) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2AM5hKi014531 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Mar 2015 18:05:44 -0400 Message-ID: <1426025143.16339.10.camel@redhat.com> From: Nathaniel McCallum To: Rick van Rein Date: Tue, 10 Mar 2015 18:05:43 -0400 In-Reply-To: <2CB0CE49-2109-4666-9FFA-33538244E84E@openfortress.nl> References: <1425578271.2715.5.camel@redhat.com> <2CB0CE49-2109-4666-9FFA-33538244E84E@openfortress.nl> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Tue, 10 Mar 2015 22:05:48 -0000 On Tue, 2015-03-10 at 22:27 +0100, Rick van Rein wrote: > Hello Nathaniel, > > > I have uploaded a new draft: > > http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/ > > > Please consider deprecating the SRV-based procedure; without > deprecation, implementatations are pretty much convicted to > implementing both mechanisms forevermore, which is silly from both > KISS and security viewpoints. Is there specific IETF language I need to use for this? Section 8 in the current document does imply that this method replaces the previous SRV lookup. I will definitely be making this more explicit. > Please specify the implications for naming in certificates, such as > for PKINIT. I'm not sure how this relates. PKINIT is not a transport. Are you suggesting that we need to document the security considerations of using MS-KKDCP? If so, I don't think that's our job since: 1. We are not defining transports, just discovery of transports. 2. MS-KKDCP is not an IETF protocol. > Please do not overlool SCTP; it has the reliability and size- > scalability of TCP but the speed and ordering advantages of UDP. > Even when Kerberos does not currently use SCTP, it may need to in > future updates, possibly to handle large key sizes during PKINIT. Since there is not currently an SCTP protocol defined, we cannot write a method for discovering it. Feel free to work on one. :) Nathaniel From nobody Tue Mar 10 16:07:24 2015 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 31C8F1A90AF for ; Tue, 10 Mar 2015 16:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 aVRj2Y8k_LVE for ; Tue, 10 Mar 2015 16:07:21 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262F51A90AD for ; Tue, 10 Mar 2015 16:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1426028819; x=1426633619; q=dns/txt; h=VBR-Info:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: OpenPGP:Content-Type; bh=U/DDKjyBhluj1FXbLiKOl6F7AXjtws4sxlraQqQ 6UsA=; b=ixE7GAraOhOiT/Dn/33RlFRquEp+0t7qodaEygoOnLsKGxLoBooRJtL vnitn/tzTJEG9Z3x18gokHEhcGzi0C5ft/k9ceNfRFBi2VNBTRvKuHojjlEVRURr mO4hRlYauujgz5kSFt4Zq2SD1fQjjUvxZ+sMoXCXqou1uWoLgSZ8= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Tue, 10 Mar 2015 19:06:59 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Tue, 10 Mar 2015 19:06:58 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1.2:AES-SHA:128) (MDaemon PRO v15.0.0rc4) with ESMTPSA id md50000837163.msg for ; Tue, 10 Mar 2015 19:06:57 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Tue, 10 Mar 2015 19:06:57 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1511d32960=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <54FF790B.5070300@secure-endpoints.com> Date: Tue, 10 Mar 2015 19:06:51 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tom Yu , Chaskiel Grundman References: In-Reply-To: OpenPGP: id=92B69A04; url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040108010002080500010300" Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: New Version Notification for draft-kaduk-kitten-des-des-des-die-die-die-00.txt 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: Tue, 10 Mar 2015 23:07:23 -0000 This is a cryptographically signed message in MIME format. --------------ms040108010002080500010300 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/6/2015 3:49 PM, Tom Yu wrote: > Chaskiel Grundman writes: >=20 >> I'm not going to object to the principle of deprecating DES3, but >> claiming that AES "quickly followed" DES3 is inaccurate. The first >> mention of DES3 in the mit krb5 commit history is >> >> Author: tytso >> Date: Thu Jan 11 03:29:50 1996 +0000 >> >> Fix return type for mit_des3_string_to_key(). >> >> >> git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@7297 >> dc483132-0cff-0310-8789-dd5450dbe970 >=20 > I believe that krb5-1.2 (around 2000) was the first to have substantial= > support for DES3. krb5-1.1 (around 1999) only supported it for ticket > encryption, not session keys. It might also have been a variant that > didn't do key derivation. DES3 support was a point of issue with Microsoft in late 1998/1999 when the Common Solutions Group was invited to Redmond for meetings regarding the feature set for Windows 2000. DES3 support was standardized in Telnet in RFCs 2947 and 2948 based upon the prior existence of DES3 support in Kerberos 5. The RFCs were published in September 2000 and the work on them began more than a year before that which means that DES3 was deployed at Columbia in mid-1999. Rijndael was announced as the AES algorithm in October 2000. The first AES support was added to MIT krb5 by commit e697a50c77314b0294b3a94329fb82e0c8692e56 Author: Ken Raeburn Date: Mon Feb 3 21:10:25 2003 +0000 AES implementation by Briad Gladman; tweaked for krb5 tree git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@15141 dc483132-0cff-0310-8789-dd5450dbe970 and was released as part of MIT krb5 1.3. Jeffrey Altman --------------ms040108010002080500010300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhBA DYgfV2Wuja6XFlzP7gwyMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMTAxMDIwMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGcbqJKktdkAl+5/3n tX55BjmX/xriz7C8WyWnI3IeaKHdj4Ya/VhSGfxBi58Uo4V7wV+VXAObK+EkLgO/t2OdtUOw z04SX8ZRpyZxvw5YlL50ieRRtk7SKxGfLVbxJV1pfGnRB6aM1zOxuETvdsiYclTcoRJXKoMH lUmrC+f4jF2bxu6DQPVod5Ho2kJc5ViO1mbnTz7L2fuRWmH9afQra8Q6UaJWnJHr1ZSqkWpj a0a2Gx47C85CYffAoTX1+ujuYwg0LA8C3RL0FnGvalH4dalsfTgpskhEGXKRpMMAli8Oq7bO Ob1oxziM9+yR5+v30vZ37adC2vx8L1m4F7WXAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFM2J7jAkKtP8wun+3s5rv727EDkeMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBALZrEhzBTZdbzJznEexkWvYmIu1A2s8B 95qMfk08aTvg+3D6F6wUGeZVJ/7x8vrTxIQ9vvYvfbXjDBdpWLnVoUaeEM2i//16x21NHqfA Fw5qtSxy4YQATuQIqevk96K2vIIjjL/vrIwZevwPBPpk/XhAI4Mfuzo89buT+pJB9pEVE8IC NUPVduydcZAJ0R0m8qQVIsKEYqAkULD1U6P8OKl8alblGFkFuqXISPbeMlg4OA8M5BV5IxHI GfUnXhOHH/AL1xE9GVt4DmGd8y96y+ljJHV/mD93NvJaH04W6ounDb8RBVt8DRvq0MLHtWap UHlG3zH8i/IJ8p9jQ5XdyRExggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEANiB9XZa6NrpcWXM/u DDIwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwMzEwMjMwNjUxWjAjBgkqhkiG9w0BCQQxFgQU4la4vAh4E7x/KF4Yz2Cvd9L9 Z/QwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQA2IH1dlro2ulxZcz+4MMjCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBADYgfV2Wuja6XFlzP7gwyMA0GCSqGSIb3DQEB AQUABIIBACUwLDwyM8Xd6QBIBLogfZ4t3GYf/3OkrYdci4egjdQjuZ52Qbv/G8kTZEczO+EE c04ZW/82Q/NIYrkRzvW4tn8IlWrbToQgYfg1llyUSMQdfuh8WvIqhp+OolR//OARVX42mMTD 19WKqmjacArzrvcBhmo57TJefXCia0DdcAi83Hk0lqWYdJF7WE/K1NDtepmIvVpndmZgMakr +5WHUtpXCi6aSLWOk5mYyI8tHGpTxTS/oMKXwQA2ZZV4LwgFlbG2CkF+nYyjDL6aXB1KJhas QeTdjOmd0PhkeHK0bnZiP56LWC9QeuIhoXwNTX4ViQFBB5NdOz7+0lTjRPTWlaMAAAAAAAA= --------------ms040108010002080500010300-- From nobody Tue Mar 10 16:50:15 2015 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 A913D1A90BB for ; Tue, 10 Mar 2015 16:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 PWA4BUIKyNJ0 for ; Tue, 10 Mar 2015 16:50:12 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A41851A8AC2 for ; Tue, 10 Mar 2015 16:50:12 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 60D3C2005E612 for ; Tue, 10 Mar 2015 16:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=pLrcjEgU7rfQMwHpB0rpds3jVeQ=; b=LBXRB3rQN56 z0GjDM2mR8dQS+z0D872YYkykd9O9Ok6TI3WdB8MZflrnHXqAPrYRcO40e27aqd+ uLOIuNMp5uX0TegBB9RjvkJ7HtB9NQAD6eWY+MuvpXhQvSMg390vd6uI4uPeXGG/ KBRJ5aSBU/EKudD5Kdl5Y10BSdolFZpk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id 2E1342005E609 for ; Tue, 10 Mar 2015 16:50:12 -0700 (PDT) Date: Tue, 10 Mar 2015 18:50:11 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20150310235010.GB7286@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [kitten] On GSS credential "stores" 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: Tue, 10 Mar 2015 23:50:13 -0000 The GSS-API, all versions up to and including v2 update 1, with all Standards-Track extensions to date, has a purposefully nebulous concept of credential store (the "place(s)" where credentials are kept). GSS_Acquire_cred(), GSS_Add_cred(), the default CREDENTIAL HANDLE, and the GSS_Store_cred() extension, all interact with a "credential store", but the details are specific to each operating system / implementation. There is no discussion in the specs of how one finds this "credential store" in any other context, how one creates a store, or how one ensures that a "session" or a "process" has a "credential store" associated with it. All out of scope; see RFC2743 section 1.1.1.2 [0]. For implementors of common sorts of acceptor applications (e.g., SSHv2 servers) that want to make delegated credentials available to other processes, some of these details matter a great deal. But even knowing such details, before GSS_Store_cred() implementors needed special access to a mechanism's internals to be able to make a delegatged credential available to a user session's processes, or simply could not do anything with delegated credentials. That's because delegated CREDENTIAL HANDLEs are a sort of anonymous object[1], with a manifestation only in the process that called GSS_Accept_sec_context(). In the original GSS-API there was no way to make delegated credentials available to other processes. GSS_Store_cred() fixes that problem, still leaving the background details about "credential stores" in the background. As far as I'm concerned, the GSS-APIv2u1 with GSS_Store_cred() has a sufficiently complete and usable (and used!) interface to credentials for most applications. Sure, it's not rich enough to replace "kinit" with "gssinit", and "klist" with "gsslist", and so on. But applications like "ssh" and "sshd" can be written correctly. It's worth pointing out that CREDENTIAL HANDLEs are really just that: a way to reference what is typically an external object (like file handles in most programming language environments). But delegated CREDENTIAL HANDLEs are anonymous objects, as explained above. This is useful to know, if we consider future extensions, such as functions for obtaining credentials with passwords, smartcards, and so on. As we consider such extensions, we can either have them interact with the credential store, or have them produce CREDENTIAL HANDLEs that are like delegated ones, and which need to be explicitly "stored" to be made available to other processes in a session. The GSS_Store_cred() approach is nice: it allows us to limit side-effects in functions that output CREDENTIAL HANDLEs, and lets us separate the function of storing them from the function of making them. I urge this approach on anyone working in this space. That's not to say that we couldn't also develop a more complete interface to the credential store. One could have functions to create and destroy credential stores, set the current credential store for a process or session, get a handle to the current credential store, get a list of credentials in the store, destroy credentials in the store, refresh/replace them, get handles to credentials in the store, add credentials to the store, and so on. Such aren't strictly necessary, though perhaps they would be useful enough to design and implement. Just that as long as we don't go there, we should stick with the GSS-APIv2u1+GSS_Store_cred() model of credential stores. [0] We wouldn't want these RFCs to talk about such mundane details as "fork()", "exec()", "spawn()", "process", "access token", "real, effective, and saved UID", "environment variables", and all sorts of other OS-specific details. Indeed they don't. [1] Note: not anonymous _principal_. Nico -- From nobody Tue Mar 10 17:18:21 2015 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 C188E1A8830 for ; Tue, 10 Mar 2015 17:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 nMOKt2__8goT for ; Tue, 10 Mar 2015 17:18:18 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CF29C1A01F7 for ; Tue, 10 Mar 2015 17:18:18 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id B3E9E2005D82E for ; Tue, 10 Mar 2015 17:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=eRfUGFzkGPdF4ZQWt51GQjDb3BI=; b=S6CvXQu2Cht 9CN7zyZPuNvWI/Z54by4WlAECiP+Q9K2PzoL6Hy+Nv+qVRNzQsbhXDoet7JQv9N9 XACHzUYRx2WYjeTQImDK5KMa+a46IwzNHlNS6QrMfYk/T9M1eBr9baQQiz2PEsDX 3TA8dedA4DHXnRcbDLu3OBdmB1/cvKwU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id 77EA62005D82D for ; Tue, 10 Mar 2015 17:18:18 -0700 (PDT) Date: Tue, 10 Mar 2015 19:18:17 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20150311001817.GC7286@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred() 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: Wed, 11 Mar 2015 00:18:19 -0000 The subject came up today, and I thought I'd state my opinion here about permissible and impermissible side-effects of GSS_Acquire_cred(). (And, indirectly, GSS_Init_sec_context() and GSS_Accept_sec_context().) It's certainly permissible for GSS_Acquire_cred() to have some kind of side-effects. It's clear that GSS_Acquire_cred() was intended to get a "handle" to credentials that exist. But side-effects crop up if we want it to bring credentials into existence that weren't there before -- that's a big side-effect, but it's also idempotent, and GSS apps in particular can't really notice such a side-effect as the state transition is from no-credentials to have-credentials [for some NAME(s) anyways]. For example, there have been implementations that if necessary would pop-up a modal dialog asking the user for their password in order to acquire credentials that would otherwise be unavailable. Such an implementation has two side-effects: a) the modal interaction with the user, and b) that credentials become available that had not been there before. In some sense (a) is not a side-effect (it's not a modification of the state of the world). (b) is a side-effect, but an idempotent one (see above). Can we go from examples to principles? Let's try. I can see three principles: a) no side-effects outside caching, b) idempotent side-effects only, c) what principles? anything goes. The [implementation- and Kerberos-specific] question that came up was (rephrased by me; others can chime in with additional questions like it): Given a keytab[0], can a call to GSS_Acquire_cred() change the contents of a session's ccache[1], and if so, can it change the default principal name? Principle (a) would lead to a generic answer like: tickets can be cached, but notions of default principal cannot be set nor changed. Principle (b) would lead to a generic answer like; tickets can be cached, the caches can be created, and the notion of default principal can be set if not already set, but cannot be changed. Principle (c) allows any reasonable answer. In implementation-specific terms, (a) means that GSS_Acquire_cred() can acquire a new TGT for the same principal(s) for which the default cccol[2] or default ccache has TGTs, and it can re-initialize such ccaches, but it cannot change the default principal for a session. This leaves a corner case: you have a keytab but no cccol/ccache. For that case the answer is that if there's no way make a good selection of default principal, then the the TGT(s) should be saved somewhere if possible, but still not be made available as the default credential (perhaps this means that the TGTs are acquired every time they are needed, and never cached). In implementation-specific terms, (b) means the same as (a) except that if there's no cccol/ccache already, then the implementation can pick any principal it likes from the keytab, and set it as the default principal. My preference is for (a), and if I can't get (a) (certainly some implementations don't adhere to it) then (b); (c) is out. [0] A file containing long-term secret encryption keys for Kerberos principals. [1] A file containing Kerberos tickets, possibly acquire with use of a keytab. Typically a ccahce has tickets for just one client principal. [2] A collection of ccaches, each for a different client principal. Nico -- From nobody Wed Mar 11 02:25:56 2015 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 B38B51A905C for ; Wed, 11 Mar 2015 02:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 o1dc-X05w7hh for ; Wed, 11 Mar 2015 02:25:52 -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 02B831A710D for ; Wed, 11 Mar 2015 02:25:51 -0700 (PDT) Received: from [10.0.1.225] ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id 29Rn1q00H10HQrX019RpPZ; Wed, 11 Mar 2015 10:25:49 +0100 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 From: Rick van Rein In-Reply-To: <1426025143.16339.10.camel@redhat.com> Date: Wed, 11 Mar 2015 10:25:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1425578271.2715.5.camel@redhat.com> <2CB0CE49-2109-4666-9FFA-33538244E84E@openfortress.nl> <1426025143.16339.10.camel@redhat.com> To: Nathaniel McCallum X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Wed, 11 Mar 2015 09:25:54 -0000 Hi Nathaniel, >> Please consider deprecating the SRV-based procedure; without=20 >> deprecation, implementatations are pretty much convicted to=20 >> implementing both mechanisms forevermore, which is silly from both=20 >> KISS and security viewpoints. >=20 > Is there specific IETF language I need to use for this? I don=E2=80=99t know of any, but the word =E2=80=9Cdeprecated=E2=80=9D = seems to me to make a big difference. Formally, it=E2=80=99s still true of course that = clients choose whether to adopt any new standard into their code, but practically it means that clients could get away with only implementing the new approach. For DNS admins, it would mean that they had to create both descriptors because old clients won=E2=80=99t upgrade, but that = hardly sounds like a problem to me =E2=80=94 except from the design ideal that all knowledge should be concentrated in one place. >> Please specify the implications for naming in certificates, such as=20= >> for PKINIT. >=20 > I'm not sure how this relates. I=E2=80=99m not sure if there is a problem, but it seems to be = worthwhile to consider. SRV records point to a hostname, not an IP address. This hostname is then acceptable for certificates in many protocols =E2=80=94 but = I=E2=80=99m not sure if that applies to the KDC=E2=80=99s certificates for PKINIT as = well. Note that an alternative is also possible, that is to require the domain name to be used as a certificate name. The fact that you define a URI means that new habits / choices may follow, and especially if the URI contains IP addresses instead of host names. > Are you=20 > suggesting that we need to document the security considerations of=20 > using MS-KKDCP? No. >> Please do not overlool SCTP; it has the reliability and size- >> scalability of TCP but the speed and ordering advantages of UDP. =20 >> Even when Kerberos does not currently use SCTP, it may need to in=20 >> future updates, possibly to handle large key sizes during PKINIT. >=20 > Since there is not currently an SCTP protocol defined, we cannot write=20= > a method for discovering it. Feel free to work on one. :) Hmm, yes this chicken-and-egg problem is everywhere where new protocols are introduced, and it is generally considered valid = reasoning. I won=E2=80=99t press this hard, but think it leads to an impasse, which = is why I mentioned it; you are very specific about UDP and TCP and so you are explicitly passing by SCTP. -Rick= From nobody Wed Mar 11 07:39:50 2015 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 C338A1ACDDA for ; Wed, 11 Mar 2015 07:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 D_3dugcKBwNj for ; Wed, 11 Mar 2015 07:39:47 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202FE1ACDB6 for ; Wed, 11 Mar 2015 07:39:46 -0700 (PDT) X-AuditID: 1209190e-f79bb6d0000030e8-aa-550053b156d8 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 dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id F3.44.12520.1B350055; Wed, 11 Mar 2015 10:39:45 -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 t2BEdiO7019856; Wed, 11 Mar 2015 10:39:45 -0400 Received: from [18.101.8.239] (vpn-18-101-8-239.mit.edu [18.101.8.239]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BEdghM013104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Mar 2015 10:39:43 -0400 Message-ID: <550053AE.2020701@mit.edu> Date: Wed, 11 Mar 2015 10:39:42 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Rick van Rein , Nathaniel McCallum References: <1425578271.2715.5.camel@redhat.com> <2CB0CE49-2109-4666-9FFA-33538244E84E@openfortress.nl> <1426025143.16339.10.camel@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT190YzBBqsPewvsXRzatYLOZ+ncVq 8fTVPTYHZo8lS34yeWz418Tm8X7fVbYA5igum5TUnMyy1CJ9uwSujJ3TZjIX7OesuPQ5pYHx DnsXIyeHhICJRO/9qVC2mMSFe+vZuhi5OIQEFjNJbDjXygrhbGSU2DvvODuEc4RJ4sWxC2At vAJqEmt2LmLuYuTgYBFQlfi00BkkzCagLLF+/1YWEFtUIExi9rqLjBDlghInZz4Bi4sIxEps vvUfLM4sICxxYfteVhBbWMBKYvPGJYwQu44ySqya+QGsiFPAWeLuyvVMEA3qEn/mXWKGsOUl mrfOZp7AKDgLyY5ZSMpmISlbwMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdYLzezRC81pXQT IyioOSX5djB+Pah0iFGAg1GJh3fGrP8hQqyJZcWVuYcYJTmYlER5l/kxhArxJeWnVGYkFmfE F5XmpBYfYpTgYFYS4d0RCJTjTUmsrEotyodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHg UJLg1QoCahQsSk1PrUjLzClBSDNxcIIM5wEazgpSw1tckJhbnJkOkT/FqCglzssGkhAASWSU 5sH1wpLOK0ZxoFeEeS1AqniACQuu+xXQYCagwSzWQE/yFpckIqSkGhhnJ1x87K248YA177IT J+/Oyys0Wuy111JRmUOpK4tDf7PH+5Ab+2tuCF98Z7l7yyKhbYvOsbmv4NHn3Pyj7VJeksTl MPWn0WLff7ZO1TL96qmfVrXERj6/0lty08naOSvetngXzPc6YbX048sncZPN12ssNd0aLixy 5vS+4IYpK1QnnhC4u+qvEktxRqKhFnNRcSIACUcqgBUDAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Wed, 11 Mar 2015 14:39:48 -0000 On 03/11/2015 05:25 AM, Rick van Rein wrote: > SRV records point to a hostname, not an IP address. This hostname > is then acceptable for certificates in many protocols — but I’m not > sure if that applies to the KDC’s certificates for PKINIT as well. RFC 4556 requires that the KDC certificate contain a SAN of type id-pkinit-san whose value is the TGT principal name for the realm, and also an extended key usage value of id-pkinit-KPKdc. The above applies "unless the client knows by some other means that the KDC certificate is intended for a Kerberos KDC," and generally client implementations do provide a way to use a standard SSL server cert for the KDC with appropriate configuration. In MIT krb5, the client must have the valid PKINIT cert hostnames for the realm explicitly configured in krb5.conf for this option; we do not pay any attention to the hostname from the transport lookup. I wouldn't object to security considerations language to make it explicit that an unauthenticated transport hostname MUST NOT be used to validate a PKINIT certificate (and maybe that a DNSSEC-authenticated transport hostname SHOULD NOT be used), but I don't know that it is necessary. From nobody Wed Mar 11 07:54:09 2015 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 D8EF61ACE1D for ; Wed, 11 Mar 2015 07:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_52=0.6, SPF_SOFTFAIL=0.665] autolearn=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 Z7Gy9JFnb3aU for ; Wed, 11 Mar 2015 07:54:01 -0700 (PDT) Received: from mo6-p05-ob.smtp.rzone.de (mo6-p05-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5305::5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB311A88E6 for ; Wed, 11 Mar 2015 07:54:01 -0700 (PDT) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwNKmLapmn/F6ALVwJJj3BivRgq1kLaRAO5Q== X-RZG-CLASS-ID: mo05 Received: from [10.56.51.213] ([88.128.80.143]) by smtp.strato.de (RZmta 37.3 DYNA|AUTH) with ESMTPSA id q07706r2BErxcO4 (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) for ; Wed, 11 Mar 2015 15:53:59 +0100 (CET) Message-ID: <550056FF.80706@samba.org> Date: Wed, 11 Mar 2015 15:53:51 +0100 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "kitten@ietf.org" OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7KdoKaIe6MXB0hbpwbaUwOpsNJ4FemGot" Archived-At: Subject: [kitten] AuthorizationData Type registry? 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: Wed, 11 Mar 2015 14:54:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7KdoKaIe6MXB0hbpwbaUwOpsNJ4FemGot Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I'm wondering if there's a place where AuthorizationData types are listed. rfc4120.txt hash section "7.5.4. Authorization Data Types", but there're a lot a values missing. E.g. 142 was used by early MIT and Heimdal releases for KRB5-AUTHDATA-SIGNTICKET, it seems this got renumbered to 512 because [MS-KILE] has KERB-AD-RESTRICTION-ENTRY (141) and KERB-LOCAL (142). For "Pre-Authentication and Typed Data" there's a much better list, e.g. in rfc6113.txt section "7.1. Pre-Authentication and Typed Data". This seems to be the current list: http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.x= html#pre-authentication But http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.x= html doesn't list AuthorizationData types. metze --7KdoKaIe6MXB0hbpwbaUwOpsNJ4FemGot Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUAVwMACgkQm70gjA5TCD+IcwCgtKbW19REBrHxyMHRsU152MUZ pdYAn1m4zgXz1YL4mx30XpWJnNcDpJKI =Ry3f -----END PGP SIGNATURE----- --7KdoKaIe6MXB0hbpwbaUwOpsNJ4FemGot-- From nobody Wed Mar 11 07:57:47 2015 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 8A06A1A8792 for ; Wed, 11 Mar 2015 07:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 2qcEOfRs4ShZ for ; Wed, 11 Mar 2015 07:57:42 -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 E97C91A00F6 for ; Wed, 11 Mar 2015 07:57:41 -0700 (PDT) Received: from [10.0.1.225] ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id 2Exd1q00R10HQrX01ExeVj; Wed, 11 Mar 2015 15:57:40 +0100 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 From: Rick van Rein In-Reply-To: <550053AE.2020701@mit.edu> Date: Wed, 11 Mar 2015 15:57:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8E0CF4DF-E9B0-4CA5-82AE-B0AF0D4EE089@openfortress.nl> References: <1425578271.2715.5.camel@redhat.com> <2CB0CE49-2109-4666-9FFA-33538244E84E@openfortress.nl> <1426025143.16339.10.camel@redhat.com> <550053AE.2020701@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Wed, 11 Mar 2015 14:57:45 -0000 Hi, >> SRV records point to a hostname, not an IP address. This hostname >> is then acceptable for certificates in many protocols =E2=80=94 but = I=E2=80=99m not >> sure if that applies to the KDC=E2=80=99s certificates for PKINIT as = well. >=20 > RFC 4556 requires that the KDC certificate contain a SAN of type > id-pkinit-san whose value is the TGT principal name for the realm, and > also an extended key usage value of id-pkinit-KPKdc. That takes my concern away. -Rick= From nobody Wed Mar 11 08:09:52 2015 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 815431AC41D for ; Wed, 11 Mar 2015 08:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nHqDGq-Fcjrv for ; Wed, 11 Mar 2015 08:09:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (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 061E81A8845 for ; Wed, 11 Mar 2015 08:09:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DBD84282FC2; Wed, 11 Mar 2015 15:09:40 +0000 (UTC) Date: Wed, 11 Mar 2015 15:09:40 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20150311150940.GL18819@mournblade.imrryr.org> References: <1425578271.2715.5.camel@redhat.com> <2CB0CE49-2109-4666-9FFA-33538244E84E@openfortress.nl> <1426025143.16339.10.camel@redhat.com> <550053AE.2020701@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550053AE.2020701@mit.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [kitten] Kerberos Service Discovery using DNS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 15:09:50 -0000 On Wed, Mar 11, 2015 at 10:39:42AM -0400, Greg Hudson wrote: > I wouldn't object to security considerations language to make it > explicit that an unauthenticated transport hostname MUST NOT be used to > validate a PKINIT certificate (and maybe that a DNSSEC-authenticated > transport hostname SHOULD NOT be used), but I don't know that it is > necessary. For PKINIT, where the user is expected to have some sort of pre-existing trust relationship with the realm, adding DNSSEC as a trusted "introducer" indeed may be unwise as a default. In other contexts, where DNS is already an "introducer" of a remote realm to the clients or KDC of a local realm one might employ DNSSEC-validated results in security-relevant decisions. Nico and I discussed some time back an idea for building cross-realm keys between two "stranger" realms "on the fly", based on DANE. There is certainly room for using DNSSEC-validated information with automated unattended bootstrapping of secure channels to new realms (if this is something that the local KDC is configured to do). However, PKINIT should generally rely on "more local" trust anchors. I deploy a single private root CA cert for PKINIT. -- Viktor. From nobody Wed Mar 11 08:26:21 2015 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 468371A8883 for ; Wed, 11 Mar 2015 08:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 F11VOFOi8Gfv for ; Wed, 11 Mar 2015 08:26:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 36DC51A8878 for ; Wed, 11 Mar 2015 08:26:20 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2BFQIbk028368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Mar 2015 11:26:19 -0400 Received: from unused (unused [10.10.52.96] (may be forged)) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2BFQHOh014470 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Mar 2015 11:26:17 -0400 Message-ID: <1426087576.3471.19.camel@redhat.com> From: Nathaniel McCallum To: Rick van Rein Date: Wed, 11 Mar 2015 11:26:16 -0400 In-Reply-To: References: <1425578271.2715.5.camel@redhat.com> <2CB0CE49-2109-4666-9FFA-33538244E84E@openfortress.nl> <1426025143.16339.10.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Wed, 11 Mar 2015 15:26:21 -0000 On Wed, 2015-03-11 at 10:25 +0100, Rick van Rein wrote: > > > Please do not overlool SCTP; it has the reliability and size- > > > scalability of TCP but the speed and ordering advantages of UDP. > > > Even when Kerberos does not currently use SCTP, it may need to > > > in future updates, possibly to handle large key sizes during > > > PKINIT. > > > > Since there is not currently an SCTP protocol defined, we cannot > > write a method for discovering it. Feel free to work on one. :) > > Hmm, yes this chicken-and-egg problem is everywhere where new > protocols are introduced, and it is generally considered valid > reasoning. > I won’t press this hard, but think it leads to an impasse, which is > why I mentioned it; you are very specific about UDP and TCP and so > you are explicitly passing by SCTP. This isn't a chicken-and-egg problem. There is a dependency, but it is not circular. Future transports and services will define new URI formats and prefixes, respectively, in their own RFCs. The scope of this draft is to define: 1. an extensible discovery protocol 2. prefixes for pre-existing services 3. URI formats for pre-existing transports In short, don't feel like we have to cram SCTP into this draft. As I mentioned before, please feel free to write up an SCTP draft. It can define a URI format and reference this draft as a normative reference. Nathaniel From nobody Wed Mar 11 08:39:24 2015 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 5AB931A8971 for ; Wed, 11 Mar 2015 08:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EXmIsSKlq4m1 for ; Wed, 11 Mar 2015 08:39:18 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358D61A0222 for ; Wed, 11 Mar 2015 08:39:18 -0700 (PDT) X-AuditID: 1209190f-f79546d000007593-57-550061a563d7 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 dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 7C.04.30099.5A160055; Wed, 11 Mar 2015 11:39:17 -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 t2BFdGuu016273; Wed, 11 Mar 2015 11:39:16 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BFdEjI005015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 11:39:15 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2BFdEgW004096; Wed, 11 Mar 2015 11:39:14 -0400 (EDT) Date: Wed, 11 Mar 2015 11:39:14 -0400 (EDT) From: Benjamin Kaduk To: "Stefan (metze) Metzmacher" In-Reply-To: <550056FF.80706@samba.org> Message-ID: References: <550056FF.80706@samba.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6nors0kSHUYM9Zboujm1exWFxc9pPF gcljyZKfTB5zd/UxBjBFcdmkpOZklqUW6dslcGUcWP+AqeAhZ0XjgY+sDYzTOLoYOTkkBEwk HizfwAphi0lcuLeerYuRi0NIYDGTxISb5xlBEkICGxklZi5xgEgcYpLoeLiHBcJpYJRYt/wo G0gVi4C2xO0/r1lAbDYBFYmZbzaCxUUEDCUufn0PNolZQF3i25k3YLawgJnEhHW7mEBsTqD4 tcmNQGdwcPAKOEhM+28IsVhN4s6mhWAjRQV0JFbvnwJm8woISpyc+YQFYqSWxPLp21gmMArO QpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6JXm5miV5qSukmRlCgckry72D8dlDp EKMAB6MSD++MWf9DhFgTy4orcw8xSnIwKYny3gljCBXiS8pPqcxILM6ILyrNSS0+xCjBwawk wrsjECjHm5JYWZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTBezgBqFGwKDU9 tSItM6cEIc3EwQkynAdo+GWQGt7igsTc4sx0iPwpRkUpcd5VIAkBkERGaR5cLyyRvGIUB3pF mHcaSBUPMAnBdb8CGswENJjFGuhJ3uKSRISUVANj1o11rsmW3F9+Hg7V8ty3vvT3n0CZRw7/ 40Mfm5Q9DT60IE35aP7Ke+ev2x5+9vK8VFbc07wH59Z4/5OL7qxeNXtN9II+sR3FcQ7XvrG1 nw00T0y1j7h7r8CnSm9xbjL3wbbu5+u3cDSf6GP8uduj8Hzn9LAtwd+evYrMjn5+IahzLf8j oekvlFiKMxINtZiLihMBTjkZCf8CAAA= Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AuthorizationData Type registry? 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: Wed, 11 Mar 2015 15:39:23 -0000 On Wed, 11 Mar 2015, Stefan (metze) Metzmacher wrote: > Hi, > > I'm wondering if there's a place where AuthorizationData types > are listed. rfc4120.txt hash section "7.5.4. Authorization Data Types", > but there're a lot a values missing. > > E.g. 142 was used by early MIT and Heimdal releases for > KRB5-AUTHDATA-SIGNTICKET, > it seems this got renumbered to 512 because [MS-KILE] has > KERB-AD-RESTRICTION-ENTRY (141) and KERB-LOCAL (142). > > For "Pre-Authentication and Typed Data" there's a much better list, e.g. > in rfc6113.txt section "7.1. Pre-Authentication and Typed Data". > This seems to be the current list: > http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml#pre-authentication > > But > http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml > doesn't > list AuthorizationData types. The document https://tools.ietf.org/html/draft-ietf-kitten-kerberos-iana-registries-03 proposes to move control of this number space over to IANA, but that document has been lingering around due to lack of WG energy. Its author (Tom Yu) currently maintains a local registry for many Kerberos numbers which have not yet been transitioned to IANA. -Ben Kaduk From nobody Wed Mar 11 09:03:57 2015 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 19C711A03F9 for ; Wed, 11 Mar 2015 09:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ls3okCqDc3ed for ; Wed, 11 Mar 2015 09:03:54 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006F31ACD3E for ; Wed, 11 Mar 2015 09:01:36 -0700 (PDT) X-AuditID: 12074423-f79066d0000058b8-66-550066dfcfb5 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 dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 33.C6.22712.FD660055; Wed, 11 Mar 2015 12:01:35 -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 t2BG1Yw0019929; Wed, 11 Mar 2015 12:01:35 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BG1WKT014091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 12:01:33 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2BG1V8F006900; Wed, 11 Mar 2015 12:01:31 -0400 (EDT) Date: Wed, 11 Mar 2015 12:01:31 -0400 (EDT) From: Benjamin Kaduk To: Nathaniel McCallum In-Reply-To: <1425679096.2550.9.camel@redhat.com> Message-ID: References: <1425578271.2715.5.camel@redhat.com> <54FA1F7D.2050703@mit.edu> <1425679096.2550.9.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nons/jSHU4MsPZYujm1exWMz9OovV gcljyZKfTB7v911lC2CK4rJJSc3JLEst0rdL4Mron3yauWApZ8XPttWMDYxr2bsYOTkkBEwk rp78wQhhi0lcuLeerYuRi0NIYDGTRMPPJnYIZyOjxLKGtVDOISaJJ5O7GCGcBkaJL6chZrEI aEts+DiLDcRmE1CRmPlmI5gtIqAnsWzfBKAGDg5mASOJC78yQMLCAlYSmzcuAVvNKWAosej2 OVYQm1fAQaLv8E9mEFtIoEBi1qGzYONFBXQkVu+fwgJRIyhxcuYTMJtZQEti+fRtLBMYBWch Sc1CklrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10wvN7NELzWldBMjOFRdlHcw/jmodIhR gINRiYd3xqz/IUKsiWXFlbmHGCU5mJREeQOSGUKF+JLyUyozEosz4otKc1KLDzFKcDArifDu CATK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8D5IAWoULEpNT61I y8wpQUgzcXCCDOcBGn4BpIa3uCAxtzgzHSJ/ilFRSpxXKBUoIQCSyCjNg+uFpZJXjOJArwjz uoNU8QDTEFz3K6DBTECDWayBnuQtLklESEk1MOpJnNmc85s3smn1D6OM5a2Nr21X9H9/VKWd eWbP/APxKkcq024etK07fnIV05P3WlJKW8Le+8ov0DrWsufE84D1ypwWJVesirfWaW6b0tiU zN3Fx7Ui8u8CuW/cD8O57p3RDfsq/Z63u/tI67ucxRkz1hw8vt2Pu9f74cHKOrbpIiyrJl98 xajEUpyRaKjFXFScCABALPQzAAMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Wed, 11 Mar 2015 16:03:56 -0000 On Fri, 6 Mar 2015, Nathaniel McCallum wrote: > On Fri, 2015-03-06 at 16:43 -0500, Greg Hudson wrote: > > > > The current draft does allow the URI records to express no > > preference of UDP versus TCP; one can simply give them the same > > priority and don't use weights. But if the URI records express a > > preference, should a client always honor that preference, or can it > > ignore it--say, if the packet is large? > > I would say that the client must never ignore the DNS preference. > Large packets are not usually generated on the fly by clients but are > either server responses to clients or are the result of server- > configured preauth mechs. This means that the server in question has > been configured to cause these large packet sizes. Because of this, > the DNS preferences should match the server's configuration. Anything > other than this is a misconfiguration. The client can always supply arbitrary authdata and request its inclusion in the ticket. The KDC need not know in advance when this might happen or what it might include. > I'd be happy to add a statement to this effect in the draft. I would prefer Simo's approach. -Ben From nobody Wed Mar 11 09:06:31 2015 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 451E21A0054 for ; Wed, 11 Mar 2015 09:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 6NXisG9_nmZ3 for ; Wed, 11 Mar 2015 09:06:28 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D511ACD0E for ; Wed, 11 Mar 2015 09:05:32 -0700 (PDT) X-AuditID: 12074425-f79846d0000054e1-93-550067ca1142 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id B8.88.21729.BC760055; Wed, 11 Mar 2015 12:05:31 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2BG5UUK032574; Wed, 11 Mar 2015 12:05:30 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BG5Q3D015968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 12:05:29 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2BG5Qud007385; Wed, 11 Mar 2015 12:05:26 -0400 (EDT) Date: Wed, 11 Mar 2015 12:05:26 -0400 (EDT) From: Benjamin Kaduk To: Nathaniel McCallum In-Reply-To: <1425578271.2715.5.camel@redhat.com> Message-ID: References: <1425578271.2715.5.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrHs6nSHUoOs2h8XRzatYLOZ+ncXq wOSxZMlPJo/3+66yBTBFcdmkpOZklqUW6dslcGUs3PmZraCdo2LVnCPMDYy72LoYOTkkBEwk /rxczw5hi0lcuLceKM7FISSwmEniScN3FghnI6PE4v27GSGcQ0wSzXdusIC0CAk0MErM6rMD sVkEtCXeX9wBNpZNQEVi5puNYLaIgJ7Esn0TGEFsZgFhifXnZjCD2MICVhKbNy4Bi3MKGErM /LEKrJ5XwEHi9uf7zBDzDSReLl3FBGKLCuhIrN4/hQWiRlDi5MwnLBAztSSWT9/GMoFRcBaS 1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0LfRyM0v0UlNKNzGCQpXdRXUH44RDSocY BTgYlXh4HWb8DxFiTSwrrsw9xCjJwaQkyhuQzBAqxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3 RyBQjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgjc+DahRsCg1PbUi LTOnBCHNxMEJMpwHaPh6kBre4oLE3OLMdIj8KUZFKXHeepCEAEgiozQPrheWSl4xigO9Isy7 EaSKB5iG4LpfAQ1mAhrMYg30JG9xSSJCSqqBcVPcOTHxVbO79hYxF5c/W/zNZ3LslmjxHKml e8rXW/rkW11glxWcfYaR+YCp6oOnl6aKvwut6VR6/G21933bORc6mIS1VyZ37mVKE+r05v7v +5S9u1tgfjTD5fftkYsXrxb5fTtqzyzGo3qs28O7XDZeUDdMcTveu3Tx+/DrUroMWTEMXv5c SizFGYmGWsxFxYkAtpZf/wADAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Wed, 11 Mar 2015 16:06:30 -0000 On Thu, 5 Mar 2015, Nathaniel McCallum wrote: > I have uploaded a new draft: > http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/ > > If you'd like to discuss it, reply to this message. :) I'm generally in favor of something like this. A few things that came to mind while reading it that have not already been raised: You cover kerberos and kpasswd, but not kadmin. Any reason why? (MIT's code does not currently support using DNS to locate an admin server, but that's not a reason to reject adding it to a discovery protocol in its own right.) I'm uncertain that section 3 is necessary. Section 7.2.3.1 of RFC 4120 seems to just be saying "you can't make two kerberos realms that differ only in case"; whatever case is used for the DNS query, the response will be the same. Section 5.1 calls out that the default path differs from that in [MS-KKDCP]. It seems like some justification for this deviation should be offered, or the gratuitous difference removed. -Ben From nobody Wed Mar 11 09:31:00 2015 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 561CA1ACE38 for ; Wed, 11 Mar 2015 09:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qzOV9T69idVH for ; Wed, 11 Mar 2015 09:30:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 74F8B1ACE3D for ; Wed, 11 Mar 2015 09:30:57 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2BGUuiB024465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Mar 2015 12:30:56 -0400 Received: from unused (unused [10.10.52.96] (may be forged)) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2BGUqaL011042 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Mar 2015 12:30:54 -0400 Message-ID: <1426091451.3471.35.camel@redhat.com> From: Nathaniel McCallum To: Benjamin Kaduk Date: Wed, 11 Mar 2015 12:30:51 -0400 In-Reply-To: References: <1425578271.2715.5.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Wed, 11 Mar 2015 16:30:59 -0000 On Wed, 2015-03-11 at 12:05 -0400, Benjamin Kaduk wrote: > On Thu, 5 Mar 2015, Nathaniel McCallum wrote: > > > I have uploaded a new draft: > > > http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/ > > > > If you'd like to discuss it, reply to this message. :) > > I'm generally in favor of something like this. > > A few things that came to mind while reading it that have not > already been > raised: > > You cover kerberos and kpasswd, but not kadmin. Any reason why? > (MIT's code does not currently support using DNS to locate an admin > server, but that's not a reason to reject adding it to a discovery > protocol in its own > right.) My understanding is that kadmin is a proprietary protocol and has not been standardized. If that is incorrect, I can certainly add it. Does it already have a standardized discovery protocol? > I'm uncertain that section 3 is necessary. Section 7.2.3.1 of RFC > 4120 seems to just be saying "you can't make two kerberos realms > that differ only in case"; whatever case is used for the DNS query, > the response will > be the same. Do I understand you correctly to suggest that I simply remove section 3 altogether and say nothing about realm-to-domain translation? > Section 5.1 calls out that the default path differs from that in [MS- > KKDCP]. It seems like some justification for this deviation should > be > offered, or the gratuitous difference removed. Good point. My justification is simply that the default provided by MS- KKDCP will confuse DNS admins. They will see a URI that looks like this: https://kdc.foo.com They will expect this behavior from past experience: https://kdc.foo.com/ But they will actually get this behavior: https://kdc.foo.com/KdcProxy Even if we were to use a different URI scheme, I think this behavior expectation mismatch will be pronounced. I suspect the use of /KdcProxy is really just an implementation detail. Its only appearance is in Section 2.1 and its meaning is rather vague. I would like some clarification from MS regarding this question. Nathaniel From nobody Wed Mar 11 09:35:38 2015 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 5771C1A1A73 for ; Wed, 11 Mar 2015 09:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HFWyOSEhsuOS for ; Wed, 11 Mar 2015 09:35:35 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB1C1A004B for ; Wed, 11 Mar 2015 09:35:35 -0700 (PDT) X-AuditID: 12074424-f79356d000004839-a3-55006ed63c5a Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 15.2E.18489.6DE60055; Wed, 11 Mar 2015 12:35:34 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2BGZS5H004249; Wed, 11 Mar 2015 12:35:28 -0400 Received: from [18.101.8.239] (vpn-18-101-8-239.mit.edu [18.101.8.239]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BGZLCn026971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Mar 2015 12:35:27 -0400 Message-ID: <55006EC9.1030101@mit.edu> Date: Wed, 11 Mar 2015 12:35:21 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Kaduk , Nathaniel McCallum References: <1425578271.2715.5.camel@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IR4hRV1r2WxxBq0H5RwuLo5lUsFnO/zmJ1 YPJYsuQnk8f7fVfZApiiuGxSUnMyy1KL9O0SuDI+T7nHWtDBWjFrWjdTA2M/SxcjJ4eEgInE jhXr2CBsMYkL99YD2VwcQgKLmSR2t59ggXA2MkrMmryXGcI5wiTx68FLsHZeATWJpjUfGUFs FgFViUvz7jOD2GwCyhLr928FqxEVCJOYve4iI0S9oMTJmU/A4iICfhLXny0HW80sICxxYfte VhBbWMBKYvPGJWD1QgKpEo+6toHVcwo4Sjx9+54Vol5PYsf1X1C2vETz1tnMExgFZyFZMQtJ 2SwkZQsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpmuvlZpbopaaUbmIEhTC7i8oOxuZDSocY BTgYlXh4Z8z6HyLEmlhWXJl7iFGSg0lJlDcgmSFUiC8pP6UyI7E4I76oNCe1+BCjBAezkgjv jkCgHG9KYmVValE+TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBO+zXKBGwaLU9NSK tMycEoQ0EwcnyHAeoOEGeSDDiwsSc4sz0yHypxh1ORa075/JJMSSl5+XKiXOexRkkABIUUZp HtwcWOp5xSgO9JYw7yGQKh5g2oKb9ApoCRPQEhZroId5i0sSEVJSDYzaVVIOT5eruzm2xp4J FesQ+62gEZ3vMp1JKt5rkoX/6xPte1VPhNrwm3mdM317z3Bd5/o02zuzD9xY7H08yVj32f/O HWyZT2R/nrPfwGF0Vrg8W6PP8WK5/LpbNrcT9Vtuv8+bKK2vGZObFX6j4pj5qxulitre4gmV dTu3LyqfXpZtuLsvS4mlOCPRUIu5qDgRALAvRDsYAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Wed, 11 Mar 2015 16:35:37 -0000 On 03/11/2015 12:05 PM, Benjamin Kaduk wrote: > Section 5.1 calls out that the default path differs from that in > [MS-KKDCP]. It seems like some justification for this deviation should be > offered, or the gratuitous difference removed. Section 2.1 of [MS-KKDCP] states, "The URI uses the virtual directory /KdcProxy unless otherwise configured." I don't know what this actually means. I doubt it means that software should convert a URI like http://hostname to http://hostname/KdcProxy. In a similar vein it seems weird for this document to say anything about a default path. A URI always has a path component; it may be empty. From nobody Wed Mar 11 09:44:16 2015 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 88C311A1B17 for ; Wed, 11 Mar 2015 09:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2nVejYooR8ck for ; Wed, 11 Mar 2015 09:44:12 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9011A1AFC for ; Wed, 11 Mar 2015 09:44:12 -0700 (PDT) X-AuditID: 1209190e-f79bb6d0000030e8-13-550070db63cb 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 dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 85.C0.12520.BD070055; Wed, 11 Mar 2015 12:44:11 -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 t2BGiAdj006417; Wed, 11 Mar 2015 12:44:10 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BGi80o030270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 12:44:09 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2BGi77E012221; Wed, 11 Mar 2015 12:44:07 -0400 (EDT) Date: Wed, 11 Mar 2015 12:44:07 -0400 (EDT) From: Benjamin Kaduk To: Nathaniel McCallum In-Reply-To: <1426091451.3471.35.camel@redhat.com> Message-ID: References: <1425578271.2715.5.camel@redhat.com> <1426091451.3471.35.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrnu7gCHUYPM0Poujm1exWMz9OovV gcljyZKfTB7v911lC2CK4rJJSc3JLEst0rdL4MqYcVm44Ltoxd1WyQbGdYJdjJwcEgImErMb T7BB2GISF+6tB7K5OIQEFjNJ3HtznQnC2cgosXj5I3YI5xCTRN+3lVBOA6PE+n0XWUD6WQS0 JbpbZjCC2GwCKhIz32wEmysioCexbN8EsDizgLDE+nMzmEFsYQEric0bl4DFOQWMJF7tWQg2 h1fAQaLraTMzxIIeRommxvNMIAlRAR2J1funQBUJSpyc+YQFYqiWxPLp21gmMArOQpKahSS1 gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6xXm5miV5qSukmRlCockry7WD8elDpEKMAB6MS D++MWf9DhFgTy4orcw8xSnIwKYnyBiQzhArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4d0RCJTj TUmsrEotyodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLgzcsHahQsSk1PrUjLzClB SDNxcIIM5wEaHgdSw1tckJhbnJkOkT/FqCglzpsCkhAASWSU5sH1wlLJK0ZxoFeEebeBVPEA 0xBc9yugwUxAg1msgZ7kLS5JREhJNTBmrBL7nrv+xi4Gxjk7ONg++VSJca7blPhw24fYw1+X LW5Qilk3bZmza1fI4d8cWX2aN54XB761MTAUKpH8q/Sq6/1Jr9baGI/I6BY+xilFjPuu5vS+ a/zovMRCfLXVZ8EXVcKr7VYZ7+RaZLL6RUi48i27K1PzHXfs3VrfuIL5RFWzfGDznI1KLMUZ iYZazEXFiQDNfGPgAAMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Wed, 11 Mar 2015 16:44:14 -0000 On Wed, 11 Mar 2015, Nathaniel McCallum wrote: > On Wed, 2015-03-11 at 12:05 -0400, Benjamin Kaduk wrote: > > On Thu, 5 Mar 2015, Nathaniel McCallum wrote: > > > > > I have uploaded a new draft: > > > > > http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/ > > > > > > If you'd like to discuss it, reply to this message. :) > > > > I'm generally in favor of something like this. > > > > A few things that came to mind while reading it that have not > > already been > > raised: > > > > You cover kerberos and kpasswd, but not kadmin. Any reason why? > > (MIT's code does not currently support using DNS to locate an admin > > server, but that's not a reason to reject adding it to a discovery > > protocol in its own > > right.) > > My understanding is that kadmin is a proprietary protocol and has not > been standardized. If that is incorrect, I can certainly add it. Does > it already have a standardized discovery protocol? There are at least two different proprietary kadmin protocols. SRV records for _kerberos-adm._tcp.[realm] are documented by both MIT and Heimdal, and exist at many sites. It looks like Heimdal doesn't actually implement client support for them, either, though, judging by git grep. (The corresponding draft-ietf-cat-krb-dns-locate seems to have withered and died.) > > I'm uncertain that section 3 is necessary. Section 7.2.3.1 of RFC > > 4120 seems to just be saying "you can't make two kerberos realms > > that differ only in case"; whatever case is used for the DNS query, > > the response will > > be the same. > > Do I understand you correctly to suggest that I simply remove section 3 > altogether and say nothing about realm-to-domain translation? That's my suggestion. I am not 100% confident that it is correct, though. > > Section 5.1 calls out that the default path differs from that in [MS- > > KKDCP]. It seems like some justification for this deviation should > > be > > offered, or the gratuitous difference removed. > > Good point. My justification is simply that the default provided by MS- > KKDCP will confuse DNS admins. > > They will see a URI that looks like this: > https://kdc.foo.com > > They will expect this behavior from past experience: > https://kdc.foo.com/ > > But they will actually get this behavior: > https://kdc.foo.com/KdcProxy > > Even if we were to use a different URI scheme, I think this behavior > expectation mismatch will be pronounced. > > I suspect the use of /KdcProxy is really just an implementation > detail. Its only appearance is in Section 2.1 and its meaning is > rather vague. I would like some clarification from MS regarding this > question. I guess I am satisfied by Greg's response on this point. -Ben From nobody Wed Mar 11 09:54:40 2015 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 553451A1B48 for ; Wed, 11 Mar 2015 09:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HF-2GFQZitVt for ; Wed, 11 Mar 2015 09:54:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 D96431A0235 for ; Wed, 11 Mar 2015 09:54:37 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2BGsahn012736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Mar 2015 12:54:36 -0400 Received: from unused (unused [10.10.52.96] (may be forged)) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2BGsYr3027162 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Mar 2015 12:54:35 -0400 Message-ID: <1426092874.3471.48.camel@redhat.com> From: Nathaniel McCallum To: Greg Hudson Date: Wed, 11 Mar 2015 12:54:34 -0400 In-Reply-To: <55006EC9.1030101@mit.edu> References: <1425578271.2715.5.camel@redhat.com> <55006EC9.1030101@mit.edu> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Wed, 11 Mar 2015 16:54:39 -0000 On Wed, 2015-03-11 at 12:35 -0400, Greg Hudson wrote: > On 03/11/2015 12:05 PM, Benjamin Kaduk wrote: > > Section 5.1 calls out that the default path differs from that in > > [MS-KKDCP]. It seems like some justification for this deviation > > should be > > offered, or the gratuitous difference removed. > > Section 2.1 of [MS-KKDCP] states, "The URI uses the virtual > directory /KdcProxy unless otherwise configured." I don't know what > this actually means. I doubt it means that software should convert a > URI like http://hostnameto http://hostname/KdcProxy. > > In a similar vein it seems weird for this document to say anything > about a default path. A URI always has a path component; it may be > empty. Perhaps it would be better to say that the path may be empty and that the client MUST NOT try to replace an empty path with a default value? Nathaniel From nobody Wed Mar 11 09:56:40 2015 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 2D3331A1B8A for ; Wed, 11 Mar 2015 09:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 KLJ6c9TaZ7ga for ; Wed, 11 Mar 2015 09:56:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 B85F11A1B80 for ; Wed, 11 Mar 2015 09:56:37 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2BGubYl014461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Mar 2015 12:56:37 -0400 Received: from unused (unused [10.10.52.96] (may be forged)) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2BGuZ4k015626 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Mar 2015 12:56:36 -0400 Message-ID: <1426092995.3471.50.camel@redhat.com> From: Nathaniel McCallum To: Benjamin Kaduk Date: Wed, 11 Mar 2015 12:56:35 -0400 In-Reply-To: References: <1425578271.2715.5.camel@redhat.com> <1426091451.3471.35.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Wed, 11 Mar 2015 16:56:39 -0000 On Wed, 2015-03-11 at 12:44 -0400, Benjamin Kaduk wrote: > On Wed, 11 Mar 2015, Nathaniel McCallum wrote: > > > On Wed, 2015-03-11 at 12:05 -0400, Benjamin Kaduk wrote: > > > On Thu, 5 Mar 2015, Nathaniel McCallum wrote: > > > > > > > I have uploaded a new draft: > > > > > > > > http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/ > > > > > > > > If you'd like to discuss it, reply to this message. :) > > > > > > I'm generally in favor of something like this. > > > > > > A few things that came to mind while reading it that have not > > > already been > > > raised: > > > > > > You cover kerberos and kpasswd, but not kadmin. Any reason why? > > > (MIT's code does not currently support using DNS to locate an > admin > > server, but that's not a reason to reject adding it to a > discovery > > protocol in its own > > > right.) > > > > My understanding is that kadmin is a proprietary protocol and has > not > been standardized. If that is incorrect, I can certainly add > it. Does > it already have a standardized discovery protocol? > > There are at least two different proprietary kadmin protocols. SRV > records for _kerberos-adm._tcp.[realm] are documented by both MIT > and Heimdal, and exist at many sites. It looks like Heimdal doesn't > actually implement client support for them, either, though, judging > by git > grep. (The corresponding draft-ietf-cat-krb-dns-locate seems to > have withered and died.) I am hesitant to attempt to define a discovery method for an unstandardized service. I would rather the service be standardized and define its own prefix at that time. Nathaniel From nobody Wed Mar 11 11:04:06 2015 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 58B311A1BEE for ; Wed, 11 Mar 2015 11:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Iy17JI98OHHh for ; Wed, 11 Mar 2015 11:03:48 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADD11A1BBE for ; Wed, 11 Mar 2015 11:03:47 -0700 (PDT) X-AuditID: 12074423-f79066d0000058b8-33-55008382b455 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 1F.71.22712.28380055; Wed, 11 Mar 2015 14:03:46 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2BI3jgs017881; Wed, 11 Mar 2015 14:03:45 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BI3htR001037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 14:03:45 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2BI3hDH022883; Wed, 11 Mar 2015 14:03:43 -0400 (EDT) Date: Wed, 11 Mar 2015 14:03:43 -0400 (EDT) From: Benjamin Kaduk To: mitchikos@microsoft.com In-Reply-To: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> Message-ID: References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrNvUzBBq8KxL0uLo5lUsFusvrmJx YPJYsuQnk0frjr/sAUxRXDYpqTmZZalF+nYJXBkHDxxhLHjOXbGzK7+B8QNHFyMnh4SAicTD lU/YIWwxiQv31rN1MXJxCAksZpKYPXkalLORUeLzy93sEM4hJolFj+9DZRoYJWZefwTWzyKg LXFu9k4WEJtNQEVi5puNbCC2iIC0RNuZw2A2s4CwxPpzM5i7GDk4hAW8JV6v0QUJcwo4SXya 84YVxOYVcJA42b2BEcQWEnCUOP3/OpgtKqAjsXr/FBaIGkGJkzOfsECM1JJYPn0bywRGwVlI UrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p3cQIClR2F+UdjH8OKh1i FOBgVOLhnTHrf4gQa2JZcWXuIUZJDiYlUd76eoZQIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8 WyuBcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKEryXG4EaBYtS01Mr 0jJzShDSTBycIMN5gIarNYEMLy5IzC3OTIfIn2JUlBLn9QBJCIAkMkrz4HphieQVozjQK8K8 rSBVPMAkBNf9CmgwE9BgFmugJ3mLSxIRUlINjIYsESl3Uq99ze7q2pLLfuhH+lENtRWlbzO+ qch7mIicK2ixaru0XEeis8ogUH2+87qActdnunm2E75eEJ8euELOyjQlclLaw8lZSzOiN0sv nN+iZdNYqjnT7MMhxvYSsXkH1iV/to/rFpzApvYvVL5Sa29ocIqYaM3XzGoDrVP9H4rchLSV WIozEg21mIuKEwEv8pO7/wIAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt 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: Wed, 11 Mar 2015 18:03:57 -0000 Hi Michiko, On Fri, 6 Mar 2015, internet-drafts@ietf.org wrote: > > 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 Working Group 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-01.txt > Pages : 7 > Date : 2015-03-06 > > 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 which 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: > http://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-freshness-01 Thanks for the update. It looks like this addresses all of Greg's questions, so I expect we will put this in the queue for WGLC. -Ben From nobody Wed Mar 11 11:05:34 2015 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 96A051A1B96 for ; Wed, 11 Mar 2015 11:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 s3mGZVOgVF0z for ; Wed, 11 Mar 2015 11:05:32 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53EE1A1B89 for ; Wed, 11 Mar 2015 11:05:31 -0700 (PDT) X-AuditID: 1209190f-f79546d000007593-8d-550083ea79e9 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 dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 13.B1.30099.AE380055; Wed, 11 Mar 2015 14:05:30 -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 t2BI5Tx6019091; Wed, 11 Mar 2015 14:05:30 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BI5STS001657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 14:05:29 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2BI5RFr023118; Wed, 11 Mar 2015 14:05:27 -0400 (EDT) Date: Wed, 11 Mar 2015 14:05:27 -0400 (EDT) From: Benjamin Kaduk To: michikos@microsoft.com In-Reply-To: Message-ID: References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixG6nrvuqmSHU4PcxNYujm1exWPzr5nNg 8liy5CeTR+uOv+wBTFFcNimpOZllqUX6dglcGYtmLmArmMtbcfZ0RgPjK84uRk4OCQETiV/t 1xkhbDGJC/fWs3UxcnEICSxmknh7ZTs7SEJIYCOjROt/TYjEISaJaXfeMkE4DYwSLz4+ZAKp YhHQlli/fjIriM0moCIx881GoFEcHCICUhJfvheChJkFhCXWn5vBDBIWFvCWeL1GFyTMKeAo ceLjerApvAIOEte+HGGC2Fsm0bt3PguILSqgI7F6/xQWiBpBiZMzn7BAjNSSWD59G8sERsFZ SFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3ECApRTkn+HYzfDiod YhTgYFTi4Z0x63+IEGtiWXFl7iFGSQ4mJVHe+nqGUCG+pPyUyozE4oz4otKc1OJDjBIczEoi vFsrgXK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8zk1AjYJFqemp FWmZOSUIaSYOTpDhPEDD1UBqeIsLEnOLM9Mh8qcYFaXEeT1AEgIgiYzSPLheWAp5xSgO9Iow bytIFQ8w/cB1vwIazAQ0mMUa6Ene4pJEhJRUA2NXvEhyZazc+yWrrkcbPzp7rUF1pbzLntf1 mdfK1omfWBi8fNXm/+1zLfVicxWKRXgOz6hi1PH5c6enJ+y3iPy+qiXnIhVtZ37KeywuIyXQ eCvH6kLSBNmei7vyD8b3WJ76IvBd5WrbqXOWx3xXbX9yYaLojrIH+UmVbzduMRFgFau7tLXi orASS3FGoqEWc1FxIgAg1umP/AIAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt 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: Wed, 11 Mar 2015 18:05:33 -0000 Whoops, muscle memory failed on the email address. -Ben On Wed, 11 Mar 2015, Benjamin Kaduk wrote: > Hi Michiko, > > On Fri, 6 Mar 2015, internet-drafts@ietf.org wrote: > > > > > 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 Working Group 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-01.txt > > Pages : 7 > > Date : 2015-03-06 > > > > 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 which 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: > > http://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-freshness-01 > > Thanks for the update. > > It looks like this addresses all of Greg's questions, so I expect we will > put this in the queue for WGLC. > > -Ben > From nobody Wed Mar 11 11:31:08 2015 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 30E661A7014 for ; Wed, 11 Mar 2015 11:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 GCUT0jVyIILP for ; Wed, 11 Mar 2015 11:31:04 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449E81A7013 for ; Wed, 11 Mar 2015 11:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1426098641; x=1426703441; q=dns/txt; h=VBR-Info:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: OpenPGP:Content-Type; bh=IqrSkwWnlP02eJp5ZG83M+QZXxBZUyXYRDfJwIx 2FPw=; b=VkKp3aodsmphOcz1rEZ7D9Nq0Te9wNuQOsnAobZwY3Yb399HwyLHKPj O+rkULjOh5xIH93rNeomV/N8HUw7JLaofYRC3gQfnpccYpYdJP5tdPvJyiNGgF+X 57SetuW6iAdlmXPeWwK62nALTzrUcI9dLDl2RHPpVmHDR9mYfmv8= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Wed, 11 Mar 2015 14:30:41 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Wed, 11 Mar 2015 14:30:41 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1.2:AES-SHA:128) (MDaemon PRO v15.0.0) with ESMTPSA id md50000837736.msg for ; Wed, 11 Mar 2015 14:30:40 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Wed, 11 Mar 2015 14:30:40 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1512ab8e34=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <550089C9.3080302@secure-endpoints.com> Date: Wed, 11 Mar 2015 14:30:33 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Kaduk , Nathaniel McCallum References: <1425578271.2715.5.camel@redhat.com> <1426091451.3471.35.camel@redhat.com> In-Reply-To: OpenPGP: id=92B69A04; url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080704020506080104000506" Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Wed, 11 Mar 2015 18:31:07 -0000 This is a cryptographically signed message in MIME format. --------------ms080704020506080104000506 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/11/2015 12:44 PM, Benjamin Kaduk wrote: > On Wed, 11 Mar 2015, Nathaniel McCallum wrote: >=20 >> On Wed, 2015-03-11 at 12:05 -0400, Benjamin Kaduk wrote: >>> On Thu, 5 Mar 2015, Nathaniel McCallum wrote: >>> >>>> I have uploaded a new draft: >>>> >>> http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-dis= covery/ >>>> >>>> If you'd like to discuss it, reply to this message. :) >>> >>> I'm generally in favor of something like this. >>> >>> A few things that came to mind while reading it that have not >>> already been >>> raised: >>> >>> You cover kerberos and kpasswd, but not kadmin. Any reason why? >>> (MIT's code does not currently support using DNS to locate an admin >>> server, but that's not a reason to reject adding it to a discovery >>> protocol in its own >>> right.) >> >> My understanding is that kadmin is a proprietary protocol and has not >> been standardized. If that is incorrect, I can certainly add it. Does >> it already have a standardized discovery protocol? >=20 > There are at least two different proprietary kadmin protocols. And this is why SRV records for kadmin is not standardized. > SRV records for _kerberos-adm._tcp.[realm] are documented by both > MIT and Heimdal, and exist at many sites. It looks like Heimdal doesn'= t > actually implement client support for them, either, though, judging by = git > grep.=20 Using the same SRV record for both MIT and Heimdal is in my opinion a bad mistake since each kadmin service implementation is incompatible with the other. _mit-kerberos-adm._tcp.[realm] _heimdal-kerberos-adm._tcp.[realm] would have been much better. > (The corresponding draft-ietf-cat-krb-dns-locate seems to have > withered and died.) No. The part of this I-D that were acceptable to the working group were incorporated in RFC 4120. Jeffrey Altman --------------ms080704020506080104000506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhBA DYgfV2Wuja6XFlzP7gwyMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMTAxMDIwMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGcbqJKktdkAl+5/3n tX55BjmX/xriz7C8WyWnI3IeaKHdj4Ya/VhSGfxBi58Uo4V7wV+VXAObK+EkLgO/t2OdtUOw z04SX8ZRpyZxvw5YlL50ieRRtk7SKxGfLVbxJV1pfGnRB6aM1zOxuETvdsiYclTcoRJXKoMH lUmrC+f4jF2bxu6DQPVod5Ho2kJc5ViO1mbnTz7L2fuRWmH9afQra8Q6UaJWnJHr1ZSqkWpj a0a2Gx47C85CYffAoTX1+ujuYwg0LA8C3RL0FnGvalH4dalsfTgpskhEGXKRpMMAli8Oq7bO Ob1oxziM9+yR5+v30vZ37adC2vx8L1m4F7WXAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFM2J7jAkKtP8wun+3s5rv727EDkeMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBALZrEhzBTZdbzJznEexkWvYmIu1A2s8B 95qMfk08aTvg+3D6F6wUGeZVJ/7x8vrTxIQ9vvYvfbXjDBdpWLnVoUaeEM2i//16x21NHqfA Fw5qtSxy4YQATuQIqevk96K2vIIjjL/vrIwZevwPBPpk/XhAI4Mfuzo89buT+pJB9pEVE8IC NUPVduydcZAJ0R0m8qQVIsKEYqAkULD1U6P8OKl8alblGFkFuqXISPbeMlg4OA8M5BV5IxHI GfUnXhOHH/AL1xE9GVt4DmGd8y96y+ljJHV/mD93NvJaH04W6ounDb8RBVt8DRvq0MLHtWap UHlG3zH8i/IJ8p9jQ5XdyRExggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEANiB9XZa6NrpcWXM/u DDIwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwMzExMTgzMDMzWjAjBgkqhkiG9w0BCQQxFgQUFzLnAT1PKxTNTtAeMFRsC9cH 4U0wbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQA2IH1dlro2ulxZcz+4MMjCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBADYgfV2Wuja6XFlzP7gwyMA0GCSqGSIb3DQEB AQUABIIBAK/B8HvbJQSLO/xpc7QoRWKCwU4hqlzYo1jsQmMl0P/rt4jPFLyPpW/fkBeQotGK BC+wfbkjWbE3KHyvfgrOlXR4Ht9ZAlOZZeB8ZY58le6Q67rSxsQQ6d6im6K4M8eLPX4WIacU IsT76amYO6m2WEQ5OLBdyQ/eH9nFyBQYD0v7LKKMmnCARdiHKP/0Ozqny7w2Dne/fI00HTHg 0M5e9OSJ/pNPgRBvMgbse/Rxqacjz0G62QVdzppHbJ9NIhiv/YQwebTk31vFSfYGw9Jr51ig K89KoPVJ3QgxN1fqidbGu/WH5fu2zRvlKk+39BLUmtCab4dZfX/VzeTbeDA+sKUAAAAAAAA= --------------ms080704020506080104000506-- From nobody Wed Mar 11 14:02:26 2015 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 A58661A0267 for ; Wed, 11 Mar 2015 14:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 U1hGkF-6PXTg for ; Wed, 11 Mar 2015 14:02:19 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95CDC1A0199 for ; Wed, 11 Mar 2015 14:02:18 -0700 (PDT) X-AuditID: 12074425-f79846d0000054e1-b8-5500ad59df47 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 3E.14.21729.95DA0055; Wed, 11 Mar 2015 17:02:17 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2BL2BlU020104; Wed, 11 Mar 2015 17:02:11 -0400 Received: from [18.101.8.239] (vpn-18-101-8-239.mit.edu [18.101.8.239]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BL29ku019109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Mar 2015 17:02:10 -0400 Message-ID: <5500AD51.5030902@mit.edu> Date: Wed, 11 Mar 2015 17:02:09 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Kaduk , michikos@microsoft.com References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1o1cyxBqcP2gpMXRzatYLP518zkw eSxZ8pPJo3XHX/YApigum5TUnMyy1CJ9uwSujGl7HzAXnGKuOHvsHnMD4yemLkZODgkBE4kd /+dC2WISF+6tZ+ti5OIQEljMJNE/7TEjhLORUWLzyR9MEM4RJolHi5vBWngF1CTmv9rNCGKz CKhKbNp3HCzOJqAssX7/VhYQW1QgTGL2uouMEPWCEidnPgGLiwhYSRxvmMoOYjMLCEtc2L6X tYuRg0NYwFvi9RpdiF2rGSUeXHnMBhLnFHCU2LDUBaJcT2LH9V+sELa8xPa3c5gnMArOQrJh FpKyWUjKFjAyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdK10MvNLNFLTSndxAgKX3YX1R2MEw4p HWIU4GBU4uF1mPE/RIg1say4MvcQoyQHk5Io740FDKFCfEn5KZUZicUZ8UWlOanFhxglOJiV RHi3VgLleFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeOXXADUKFqWm p1akZeaUIKSZODhBhvMADc8CqeEtLkjMLc5Mh8ifYtTlWNC+fyaTEEtefl6qlDivNEiRAEhR Rmke3BxY2nnFKA70ljDv+tVAVTzAlAU36RXQEiagJSzWQA/zFpckIqSkGhiXSt1U9utUj/fW WCr/acXrFYfePQ1pPPawpD3/Y0f9So0bfvd93m/ddVn6kfr6zQsvb41OXLxUVpzdmGn7e9uF D1X5L515uH1i04W4hPREDYlvrw6ufvZj4vXbK4s0Qu6xp0w1T1cwzf39PH6VaPrFA0HMv6/P fBiyuex9afvhl1rzPtj/sD+dr8RSnJFoqMVcVJwIABSFG+IWAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt 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: Wed, 11 Mar 2015 21:02:24 -0000 On Wed, 11 Mar 2015, Benjamin Kaduk wrote: > It looks like this addresses all of Greg's questions, so I expect we will > put this in the queue for WGLC. I still believe that section 2.1 is not necessary; clients should not need to indicate support for PA_AS_FRESHNESS for a KDC to send it the method-data of a preauth-required error. My last statement on the topic is here: http://www.ietf.org/mail-archive/web/kitten/current/msg05326.html From nobody Wed Mar 11 14:24:18 2015 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 5C0041A87D9 for ; Wed, 11 Mar 2015 14:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 3dHtjxuT5jeX for ; Wed, 11 Mar 2015 14:24:10 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5B41A87D2 for ; Wed, 11 Mar 2015 14:24:10 -0700 (PDT) X-AuditID: 1209190c-f79696d000005933-66-5500b2796ef5 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 dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E6.B0.22835.972B0055; Wed, 11 Mar 2015 17:24:09 -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 t2BLO8qd008850 for ; Wed, 11 Mar 2015 17:24:09 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BLO7TQ027558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 11 Mar 2015 17:24:08 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2BLO6ex018890; Wed, 11 Mar 2015 17:24:06 -0400 (EDT) Date: Wed, 11 Mar 2015 17:24:06 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <54FE4340.4070400@mit.edu> Message-ID: References: <20150309225924.25360.58204.idtracker@ietfa.amsl.com> <54FE4340.4070400@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUixCmqrVu5iSHU4OJ1BYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr42VTN1vBXJmKzytb2RsYz4t1MXJySAiYSOzf95kFwhaTuHBv PVsXIxeHkMBiJomlE7uZIZzjjBKfPjSyQjg3mCSmfb7IBOE0MEr8P/+NFaSfRUBbYsaEy+wg NpuAisTMNxvZQGwRAWGJ3VvfMYPYwgKOEj96D4HVcwqoS2zYfRCsnlfAQeLT4yNgdwgJxEgc /PAcrEZUQEdi9f4pLBA1ghInZz4Bs5kFtCSWT9/GMoFRYBaS1CwkqQWMTKsYZVNyq3RzEzNz ilOTdYuTE/PyUot0DfVyM0v0UlNKNzGCA1CSZwfjm4NKhxgFOBiVeHhnzPofIsSaWFZcmXuI UZKDSUmU98YChlAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxbK4FyvCmJlVWpRfkwKWkOFiVx 3k0/+EKEBNITS1KzU1MLUotgsjIcHEoSvC0bgRoFi1LTUyvSMnNKENJMHJwgw3mAhp8DqeEt LkjMLc5Mh8ifYlSUEufdCZIQAElklObB9cISxCtGcaBXhHkfbgCq4gEmF7juV0CDmYAGs1gD PclbXJKIkJJqYEzpKp6ZobtAP3fHa8e5jA/z0iSWXQkuPSY6f1KsLEfdkhaP94XyE6+dSixa zbgkIu8Tu3LKXLenp7kENINvS+ZbJLVYTXvsoioWtu7vo7OBtuuUdUUl8n8+sZi7huXSZcHH X9vsFghWcqxNTj256fbvziVLRI5OvhC65EPqjUD3q/v+azfd+6XEUpyRaKjFXFScCACgYAsF 6wIAAA== Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-cammac-02.txt 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: Wed, 11 Mar 2015 21:24:15 -0000 On Mon, 9 Mar 2015, Greg Hudson wrote: > On 03/09/2015 06:59 PM, internet-drafts@ietf.org wrote: > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-cammac-02 > > I'm not sure the new wording is quite right. The new draft contains: > > A KDC SHOULD only make verbatim copies of CAMMAC contents to a new > CAMMAC when it has authenticated the CAMMAC as originating from a > local realm KDC [...] > > When a KDC makes verbatim copies of CAMMAC contents to a new CAMMAC > without having authenticated the first CAMMAC as originating from a > local realm KDC, it SHOULD NOT apply a kdc-verifier to the new > CAMMAC. > > The first recommendation doesn't contain an exception for ticket > modification requests, where it is safe to copy a CAMMAC with only an > svc-verifier as long as the new CAMMAC also contains only an > svc-verifier. The second recommendation is confusing because it seems > to apply only to a situation where the KDC is already violating the > first SHOULD. I'm not sure that we need to be in the business of saying when the KDC SHOULD make verbatim copies at all. What if we instead come at it from something along these lines: ======== The presence of a CAMMAC in a ticket indicates that the contents of the CAMMAC have been validated and are certified by the KDC. During TGS processing, this validation may take the place of merely checking that the existing CAMMAC was issued by a KDC in the local realm; this is the case when any of the criteria below are true. In this case the KDC just makes a verbatim copy of the existing CAMMAC with no validation other than the issuer validation. [include 1, 2, and 3 from the -02] This validation can also take the place of confirming that a foreign-realm KDC has issued the existing CAMMAC in a cross-realm TGT. Local policy may grant certain foreign realms privileged status and allow verbatim copying of CAMMACs issued by KDCs from those realms. In other cases, local policy may require filtering of the CAMMAC contents (e.g., to remove group membership information) from cross-realm TGTs issued by foreign-realm KDCs. The nature of such filtering is entirely a matter of local policy. The validation can also take the place of ensuring that the scope of the generated CAMAMC is limited to the same or narrower scope than the entity which generated the existing CAMMAC. This is the case for a CAMMAC containing a svc-verifier but no kdc-verifier, when the target service of the containing ticket does not use the S4U2Proxy extension or realm policy disallows the use of S4U2Proxy by that service, because the only entity other than the KDC which could have generated the existing CAMMAC is that target service, and the generated CAMMAC would only be usable by that same target service. It is safe to make a verbatim copy of the CAMMAC and generate a new svc-verifier, but no kdc-verifier. Note that in this situation, adding a kdc-verifier to the generated CAMMAC would increase the scope of the certification, since the kdc-verifier certifies that the CAMMAC was validated by the KDC, but the input CAMMAC could have been generated by the target service. A kdc-verifier MUST NOT be included in the generated CAMMAC in this case, in the absence of explicit policy configuration (such as for cross-realm TGTs). ======== We would probably still need to say something about omitting the kdc-verifier when all the KDCs in the local realm filter out client-submitted CAMMACs. -Ben From nobody Wed Mar 11 14:26:12 2015 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 87BD11A87D5 for ; Wed, 11 Mar 2015 14:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 oqruZ3JDH0EB for ; Wed, 11 Mar 2015 14:26:09 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15111A87CD for ; Wed, 11 Mar 2015 14:26:08 -0700 (PDT) X-AuditID: 1209190d-f792d6d000001fc7-04-5500b2efbc1f 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 dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 09.A3.08135.FE2B0055; Wed, 11 Mar 2015 17:26:07 -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 t2BLQ6t7023312; Wed, 11 Mar 2015 17:26:07 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BLQ51l028228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 17:26:06 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2BLQ4gV019129; Wed, 11 Mar 2015 17:26:04 -0400 (EDT) Date: Wed, 11 Mar 2015 17:26:04 -0400 (EDT) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: <5500AD51.5030902@mit.edu> Message-ID: References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6nrvt+E0Oowa6DxhZHN69isfjXzefA 5LFkyU8mj9Ydf9kDmKK4bFJSczLLUov07RK4MnZtdy84z1Kxr6+dqYHxInMXIyeHhICJxLqX t1ggbDGJC/fWs4HYQgKLmSSOHrbqYuQCsjcyStx718IM4Rxikljw7D8ThNPAKLFnxjywdhYB bYmbE4+xg9hsAioSM99sBBslIqAo8XvlW0YQmxmkpusTUJyDQ1jAW+L1Gl2QMKeAusSpP0/A xvAKOEjM3HKdHWL+MUaJX9PbwBKiAjoSq/dPgSoSlDg5E6KBWUBLYvn0bSwTGAVnIUnNQpJa wMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdILzezRC81pXQTIyhMOSV5dzC+O6h0iFGAg1GJ h9dhxv8QIdbEsuLK3EOMkhxMSqK8NxYwhArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4d1aCZTj TUmsrEotyodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLgbdkI1ChYlJqeWpGWmVOC kGbi4AQZzgM0/BxIDW9xQWJucWY6RP4Uoy7Hgvb9M5mEWPLy81KlxHl3ghQJgBRllObBzYGl l1eM4kBvCfNeBKniAaYmuEmvgJYwAS1hsQZ6mLe4JBEhJdXAOI3B2CxRYMvmb0uzp+jVVTC0 uq7XfPew6oDa0wjHojubRAOddVJ/dh3p8FSZvdMnUDJDpFbVlUd/Y2CEb0pUiX31vrfzryzY I6G87Q+Ts+YdA9+air7DZh/1Dr/8u8IzLzpaLP6j44kTBdLbDu69e3SiQcGljLW8om9nbjGZ tv/31e0aEwTNlViKMxINtZiLihMB6P7ggAoDAAA= Archived-At: Cc: kitten@ietf.org, michikos@microsoft.com Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt 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: Wed, 11 Mar 2015 21:26:10 -0000 On Wed, 11 Mar 2015, Greg Hudson wrote: > On Wed, 11 Mar 2015, Benjamin Kaduk wrote: > > It looks like this addresses all of Greg's questions, so I expect we will > > put this in the queue for WGLC. > > I still believe that section 2.1 is not necessary; clients should not > need to indicate support for PA_AS_FRESHNESS for a KDC to send it the > method-data of a preauth-required error. > > My last statement on the topic is here: > > http://www.ietf.org/mail-archive/web/kitten/current/msg05326.html Oops, sorry I missed that. Yes, I believe you are correct. -Ben From nobody Thu Mar 12 01:14:02 2015 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 2C6911A1BB0 for ; Thu, 12 Mar 2015 01:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_SOFTFAIL=0.665] autolearn=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 DERnhVfhNCWi for ; Thu, 12 Mar 2015 01:13:59 -0700 (PDT) Received: from mo6-p05-ob.smtp.rzone.de (mo6-p05-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5305::12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FD11A1A3B for ; Thu, 12 Mar 2015 01:13:58 -0700 (PDT) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwNKmLapmn/F6ALVwDLiPBgvgq94PEpw8VXhI+lWjiTXYr3xjcFlcuhFMFBLi9XtQ7 X-RZG-CLASS-ID: mo05 Received: from [IPv6:2001:4dd5:c896:0:646e:5246:30bf:2bd3] (2001-4dd5-c896-0-646e-5246-30bf-2bd3.ipv6dyn.netcologne.de [IPv6:2001:4dd5:c896:0:646e:5246:30bf:2bd3]) by smtp.strato.de (RZmta 37.3 AUTH) with ESMTPSA id d06550r2C8DtoRs (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate); Thu, 12 Mar 2015 09:13:55 +0100 (CET) Message-ID: <55014ABB.3070506@samba.org> Date: Thu, 12 Mar 2015 09:13:47 +0100 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <550056FF.80706@samba.org> In-Reply-To: OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rsAhHiUkG1EOAj7Jmu3Lg7ffdKPklfenA" Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AuthorizationData Type registry? 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, 12 Mar 2015 08:14:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rsAhHiUkG1EOAj7Jmu3Lg7ffdKPklfenA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Benjamin, >> But >> http://www.iana.org/assignments/kerberos-parameters/kerberos-parameter= s.xhtml >> doesn't >> list AuthorizationData types. >=20 > The document > https://tools.ietf.org/html/draft-ietf-kitten-kerberos-iana-registries-= 03 > proposes to move control of this number space over to IANA, but that > document has been lingering around due to lack of WG energy. Thanks for the pointer! > Its author (Tom Yu) currently maintains a local registry for many Kerbe= ros > numbers which have not yet been transitioned to IANA. Tom, is your registry available somewhere? Thanks! metze --rsAhHiUkG1EOAj7Jmu3Lg7ffdKPklfenA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUBSsIACgkQm70gjA5TCD9FmACgz6hfLMItdV4iYXUlD5pF3quS PngAn1kEZPGB+pAA7J/kLErKJDOzwcZ+ =YVw3 -----END PGP SIGNATURE----- --rsAhHiUkG1EOAj7Jmu3Lg7ffdKPklfenA-- From nobody Thu Mar 12 15:27:31 2015 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 221B41A87C3 for ; Thu, 12 Mar 2015 15:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 z2jtqLVORfm3 for ; Thu, 12 Mar 2015 15:27:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B94D1A87AE for ; Thu, 12 Mar 2015 15:27:22 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB209.namprd03.prod.outlook.com (10.255.230.140) with Microsoft SMTP Server (TLS) id 15.1.112.13; Thu, 12 Mar 2015 22:27:03 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.76]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.76]) with mapi id 15.01.0112.000; Thu, 12 Mar 2015 22:27:03 +0000 From: Michiko Short To: Benjamin Kaduk , Greg Hudson , Sam Hartman Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt Thread-Index: AQHQXCX307vPZrskK0qMbSTckV74FZ0XxPqAgAAGrwCAAaK8oA== Date: Thu, 12 Mar 2015 22:27:03 +0000 Message-ID: References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] authentication-results: MIT.EDU; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB209; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(13464003)(24454002)(74316001)(15975445007)(86612001)(2900100001)(2171001)(19580395003)(76576001)(86362001)(76176999)(33656002)(2656002)(62966003)(93886004)(40100003)(92566002)(50986999)(102836002)(230783001)(87936001)(19580405001)(99286002)(46102003)(54356999)(122556002)(77156002)(106116001)(2950100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB209; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BL2PR03MB209; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB209; x-forefront-prvs: 05134F8B4F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2015 22:27:03.3542 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB209 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt 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, 12 Mar 2015 22:27:25 -0000 Sam, Are you ok with pulling the client request behavior?=20 -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@MIT.EDU]=20 Sent: Wednesday, March 11, 2015 2:26 PM To: Greg Hudson Cc: Michiko Short; kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt On Wed, 11 Mar 2015, Greg Hudson wrote: > On Wed, 11 Mar 2015, Benjamin Kaduk wrote: > > It looks like this addresses all of Greg's questions, so I expect we=20 > > will put this in the queue for WGLC. > > I still believe that section 2.1 is not necessary; clients should not=20 > need to indicate support for PA_AS_FRESHNESS for a KDC to send it the=20 > method-data of a preauth-required error. > > My last statement on the topic is here: > > http://www.ietf.org/mail-archive/web/kitten/current/msg05326.html Oops, sorry I missed that. Yes, I believe you are correct. -Ben From nobody Fri Mar 13 07:18:19 2015 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 981721A8909 for ; Fri, 13 Mar 2015 07:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=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 sNisqdrIO639 for ; Fri, 13 Mar 2015 07:18:16 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DBF1A88DB for ; Fri, 13 Mar 2015 07:18:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 06CF620660; Fri, 13 Mar 2015 10:17:03 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiiMuhdTRKam; Fri, 13 Mar 2015 10:17:02 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 13 Mar 2015 10:17:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 479EC8043A; Fri, 13 Mar 2015 10:18:11 -0400 (EDT) From: Sam Hartman To: Michiko Short References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> Date: Fri, 13 Mar 2015 10:18:11 -0400 In-Reply-To: (Michiko Short's message of "Thu, 12 Mar 2015 22:27:03 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt 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: Fri, 13 Mar 2015 14:18:17 -0000 Yes, if you include the freshness token in its own pa-type, that is also fine, and I'm sorry I missed that. From nobody Fri Mar 13 09:50:25 2015 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 A43441A87BD for ; Fri, 13 Mar 2015 09:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 pQTKPIKEC4ig for ; Fri, 13 Mar 2015 09:50:22 -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 D9AA01A010C for ; Fri, 13 Mar 2015 09:50:21 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB211.namprd03.prod.outlook.com (10.255.230.146) with Microsoft SMTP Server (TLS) id 15.1.112.13; Fri, 13 Mar 2015 16:50:01 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.76]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.76]) with mapi id 15.01.0112.000; Fri, 13 Mar 2015 16:50:01 +0000 From: Michiko Short To: Sam Hartman Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt Thread-Index: AQHQXZiJ07vPZrskK0qMbSTckV74FZ0an2mg Date: Fri, 13 Mar 2015 16:50:01 +0000 Message-ID: References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] authentication-results: spf=none (sender IP is ) smtp.mailfrom=michikos@microsoft.com; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB211; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(979002)(6009001)(377454003)(13464003)(76576001)(2900100001)(99286002)(102836002)(19580405001)(19580395003)(86612001)(2656002)(2950100001)(86362001)(40100003)(93886004)(230783001)(122556002)(33656002)(87936001)(2171001)(77156002)(62966003)(46102003)(64706001)(50986999)(106116001)(106356001)(54356999)(76176999)(74316001)(92566002)(110136001)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB211; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BL2PR03MB211; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB211; x-forefront-prvs: 05143A8241 received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2015 16:50:01.4951 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB211 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt 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: Fri, 13 Mar 2015 16:50:23 -0000 Once the tool reopens then I will submit the version without the client req= uest behavior.=20 -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 Sent: Friday, March 13, 2015 7:18 AM To: Michiko Short Cc: Benjamin Kaduk; Greg Hudson; Sam Hartman; kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt Yes, if you include the freshness token in its own pa-type, that is also f= ine, and I'm sorry I missed that. From nobody Fri Mar 13 11:56:15 2015 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 139EB1A908E for ; Fri, 13 Mar 2015 11:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 C96-X3U1C2CM for ; Fri, 13 Mar 2015 11:56:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0756.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:756]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B43F1A8AB6 for ; Fri, 13 Mar 2015 11:56:12 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) with Microsoft SMTP Server (TLS) id 15.1.112.13; Fri, 13 Mar 2015 18:55:45 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.76]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.76]) with mapi id 15.01.0112.000; Fri, 13 Mar 2015 18:55:45 +0000 From: Michiko Short To: Sam Hartman Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt Thread-Index: AQHQXZiJ07vPZrskK0qMbSTckV74FZ0an2mggAAi1zA= Date: Fri, 13 Mar 2015 18:55:45 +0000 Message-ID: References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] authentication-results: mit.edu; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB210; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(230783001)(86612001)(86362001)(102836002)(110136001)(46102003)(92566002)(106116001)(76576001)(99286002)(33656002)(62966003)(77156002)(2656002)(2171001)(87936001)(551544002)(74316001)(93886004)(2900100001)(122556002)(50986999)(54356999)(76176999)(40100003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB210; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BL2PR03MB210; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB210; x-forefront-prvs: 05143A8241 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2015 18:55:45.4806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB210 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt 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: Fri, 13 Mar 2015 18:56:14 -0000 Once the tool reopens then I will submit the version without the client req= uest behavior.=20 [Michiko Short] Creating a freshness token will be a crypto hit on the KDC,= so sending freshness tokens to clients who will never use them will negati= vely impact KDC performance with no gains. If the PKInit client does not ex= plicitly ask for the token, then clients using password authentication will= also have freshness tokens generated and sent to them.=20 From nobody Fri Mar 13 12:26:31 2015 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 C59031A1B59 for ; Fri, 13 Mar 2015 12:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 XvXTg96QEq9N for ; Fri, 13 Mar 2015 12:26:28 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27EC1A1AFC for ; Fri, 13 Mar 2015 12:26:27 -0700 (PDT) X-AuditID: 1209190f-f79546d000007593-01-550339e2e35e 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 dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 9B.B4.30099.2E933055; Fri, 13 Mar 2015 15:26:26 -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 t2DJQKv3005568; Fri, 13 Mar 2015 15:26:21 -0400 Received: from [18.101.8.176] (vpn-18-101-8-176.mit.edu [18.101.8.176]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2DJQIvC029501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 13 Mar 2015 15:26:19 -0400 Message-ID: <550339DA.6000109@mit.edu> Date: Fri, 13 Mar 2015 15:26:18 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Michiko Short , Sam Hartman References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT131kyRxqsOWJjsXXtgdsFkc3r2Kx +NfN58DssWTJTyaP1h1/2T1WTj3NHsAcxWWTkpqTWZZapG+XwJWx7M4PtoJnPBUzLx1hamCc wdXFyMkhIWAi8X79ZXYIW0ziwr31bF2MXBxCAouZJPae6WeHcDYySix7/xkqc4RJYl/PNSaQ Fl4BNYmTP2ezgNgsAqoSu6buBIuzCShLrN+/FSwuKhAmMXvdRUaIekGJkzOfgMVFBCIkPv9q BKtnFnCXOP/zJVANB4ewgLfE6zW6ELs2M0vc2b6BDaSGUyBaYtqjs4wQ9XoSO67/YoWw5SWa t85mnsAoOAvJillIymYhKVvAyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10QvN7NELzWldBMj KKg5Jfl3MH47qHSIUYCDUYmHt6OKKVSINbGsuDL3EKMkB5OSKO8TVeZQIb6k/JTKjMTijPii 0pzU4kOMEhzMSiK8jYpAOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4l CV5uYPQKCRalpqdWpGXmlCCkmTg4QYbzAA3faQEyvLggMbc4Mx0if4pRUUqclx2kWQAkkVGa B9cLSzqvGMWBXhHmjQRp5wEmLLjuV0CDmYAG109nAhlckoiQkmpgNC56k2YbO3118HJ7dpap CZcvTt3A4VzEqBw9LWrRFttv/Lv2L2h5dLW1w85wTtCfBQknuO23dm55/j/13s8Jy3rXOitO 0XzJOIPpuF26lmjxqy8mpT9+tl3/zXi9ZL76bL0p7yZt7c5JS4z86C6g8XTXgkO2vr031F/I 7ozfsXlqlcW2v+d6LyqxFGckGmoxFxUnAgB32pyUFQMAAA== Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt 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: Fri, 13 Mar 2015 19:26:29 -0000 On 03/13/2015 02:55 PM, Michiko Short wrote: > Once the tool reopens then I will submit the version without the client request behavior. > > [Michiko Short] Creating a freshness token will be a crypto hit on the KDC, so sending freshness tokens to clients who will never use them will negatively impact KDC performance with no gains. If the PKInit client does not explicitly ask for the token, then clients using password authentication will also have freshness tokens generated and sent to them. That's worth considering. Here are my thoughts: * A freshness token doesn't have to be unique to a request or client; it just has to be unknown to an attacker far in advance of an AS exchange. A KDC could compute a new global freshness token every five minutes or so (by encrypting the current time in a TGS key, for instance) and use it for many requests. * A KDC only needs to send a freshness token if it is offering PKINIT (or a future mechanism which also uses freshness tokens). I guess it's unusual for that to be a per-client decision by the KDC; typically either the KDC is configured with PKINIT support or it isn't, and it offers PKINIT to all clients if it is. * Is AES encryption a significant load factor on modern KDCs? I don't have numbers for our KDC at the moment. It probably depends a lot on whether AES-NI can be used. * If a client wants to save the KDC the effort of computing a freshness token, it has to decide ahead of time whether it might be able to use PKINIT (or a future mechanism which also uses freshness tokens). This is generally possible, but maybe a bit complex. From nobody Sun Mar 15 14:45:32 2015 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 CF8311A1B91 for ; Sun, 15 Mar 2015 14:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hUg-6KK-evMo for ; Sun, 15 Mar 2015 14:45:29 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6C91A1B8E for ; Sun, 15 Mar 2015 14:45:27 -0700 (PDT) X-AuditID: 1209190d-f792d6d000001fc7-77-5505fd769b8f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 30.A6.08135.67DF5055; Sun, 15 Mar 2015 17:45:26 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2FLjKAj018835; Sun, 15 Mar 2015 17:45:21 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2FLjJ7u005581; Sun, 15 Mar 2015 17:45:20 -0400 From: Tom Yu To: Benjamin Kaduk References: Date: Sun, 15 Mar 2015 17:45:18 -0400 In-Reply-To: (Benjamin Kaduk's message of "Fri, 6 Mar 2015 15:02:20 -0500") Message-ID: Lines: 9 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixCmqrFv2lzXU4NxxRYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY2HLfdaCG8wVi9Y1MDUw9jJ3MXJwSAiYSPQ/sO1i5AQyxSQu 3FvP1sXIxSEksJhJ4l5bFzuEs5FR4uX7m1DOG0aJSav3sYC0sAlISxy/vIsJxBYRUJJYfLaF DcRmFhCVOLfuCCuILSyQKXG56TWYLSTgIHFxay9YDYuAqsSyqcvB1nEKNDFKdH7oZQdJ8Aro SpzcP5kRxOYR4JDYe+cEK0RcUOLkzCcsEAu0JG78e8k0gVFgFpLULCSpBYxMqxhlU3KrdHMT M3OKU5N1i5MT8/JSi3SN9HIzS/RSU0o3MYLDT5J3B+O7g0qHGAU4GJV4eH+YsIYKsSaWFVfm HmKU5GBSEuX12QoU4kvKT6nMSCzOiC8qzUktPsQowcGsJMLL8g0ox5uSWFmVWpQPk5LmYFES 5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwVv9B6hRsCg1PbUiLTOnBCHNxMEJMpwHaHgtSA1v cUFibnFmOkT+FKMux50p/xcxCbHk5eelSonzJoEUCYAUZZTmwc2BpY1XjOJAbwnzXgWp4gGm HLhJr4CWMAEtqZ/OBLKkJBEhJdXAeN2nP/3Ob/VAlaV5e4Qzl8Zfv3fUbnXQa9fmB2yLhRVP y8jme773mbzn8DK5JLP761snXw+1MXzbLWH0+IDXK04e6asKhyc+TCr37jFnXTFBJ+9rZeq1 s7d4X3LtyFUT+3VDuXH2+/9J9rzsz7vztqkeflj6J+/VpoOufVadx/YF7Jl6Y5/XfiWW4oxE Qy3mouJEAKWT8gj2AgAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: New Version Notification for draft-kaduk-kitten-des-des-des-die-die-die-00.txt 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: Sun, 15 Mar 2015 21:45:31 -0000 Section 6.1: Several instances of des-cbc-sha1-kd should probably be des3-cbc-sha1-kd. On the other hand, RFC 3961 isn't consistent about whether the algorithm name is des3-cbc-sha1-kd, des3-cbc-hmac-sha1-kd, or des3-hmac-sha1-kd. Also in Section 6.1: The single-DES enctype family doesn't use n-fold; it uses a "fan-fold" that alternately reverses 56-bit chunks. I think the other observations in that section about the des3 string-to-key algorithm are true. From nobody Sun Mar 15 20:46:59 2015 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 1ACF11A0077 for ; Sun, 15 Mar 2015 20:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9C6khFNl0FS8 for ; Sun, 15 Mar 2015 20:46:56 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF83A1A0074 for ; Sun, 15 Mar 2015 20:46:56 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2G3kssM014060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Mar 2015 03:46:56 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2G3kqxw018963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Mar 2015 03:46:53 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2G3kq0L018960; Mon, 16 Mar 2015 03:46:52 GMT Received: from [192.168.10.106] (/114.250.158.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 15 Mar 2015 20:46:52 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Wang Weijun In-Reply-To: Date: Mon, 16 Mar 2015 11:46:46 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> To: kitten@ietf.org, OpenJDK Dev list X-Mailer: Apple Mail (2.2070.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Cc: Thomas.Maslen@software.dell.com Subject: [kitten] On stream-based GSSContext methods in RFC 5653 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: Mon, 16 Mar 2015 03:46:58 -0000 Hi All I discussed with my colleagues on the stream-based methods and we think = they are not well-designed: 1. A library should not define a wire protocol and assume the peer is = using the same. http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-05 = requires the application to define it. 2. It's impossible to implement these methods correctly when the = mechanism token has no self-framing or the library has no knowledge of = the token format (for example, as a bridge talking to another GSS library). Therefore, I propose to deprecate these methods in an I-D. By = deprecation, I'd like to remove the methods from the main content and = describe the reason in a "Changes since RFC 5653" section. The = specification for the methods will be moved to an appendix or the = "Changes since RFC 5653" section will contain links to sections inside = RFC 5653. In Oracle JDK and OpenJDK, we would like to mark these methods as = @deprecated. The existing implementations will be still supported. Thanks Max From nobody Wed Mar 18 13:07:21 2015 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 00D9A1A00FA for ; Wed, 18 Mar 2015 13:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 bdRvLhaEtGMR for ; Wed, 18 Mar 2015 13:07:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E086D1A1B92 for ; Wed, 18 Mar 2015 13:07:18 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB209.namprd03.prod.outlook.com (10.255.230.140) with Microsoft SMTP Server (TLS) id 15.1.118.15; Wed, 18 Mar 2015 20:06:57 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.76]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.76]) with mapi id 15.01.0112.000; Wed, 18 Mar 2015 20:06:57 +0000 From: Michiko Short To: Greg Hudson , Sam Hartman Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt Thread-Index: AQHQXZiJ07vPZrskK0qMbSTckV74FZ0an2mggAAi1zCAAAm3AIAH5dPg Date: Wed, 18 Mar 2015 20:06:57 +0000 Message-ID: References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> <550339DA.6000109@mit.edu> In-Reply-To: <550339DA.6000109@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] authentication-results: mit.edu; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB209; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(479174004)(377454003)(51704005)(93886004)(2656002)(551544002)(230783001)(76176999)(54356999)(50986999)(2171001)(87936001)(46102003)(19580405001)(19580395003)(106116001)(33656002)(86362001)(99286002)(62966003)(86612001)(76576001)(122556002)(2950100001)(92566002)(77156002)(2900100001)(102836002)(40100003)(74316001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB209; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BL2PR03MB209; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB209; x-forefront-prvs: 051900244E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2015 20:06:57.6578 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB209 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt 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: Wed, 18 Mar 2015 20:07:21 -0000 I think a KDC implementation can always choose to send a Freshness token, b= ut that should be an implementation option not a requirement. Having a KDC = only send the Freshness Token on client gives the option to limit generatin= g Freshness tokens to just PKInit clients.=20 -----Original Message----- From: Greg Hudson [mailto:ghudson@mit.edu]=20 Sent: Friday, March 13, 2015 12:26 PM To: Michiko Short; Sam Hartman Cc: Benjamin Kaduk; kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt On 03/13/2015 02:55 PM, Michiko Short wrote: > Once the tool reopens then I will submit the version without the client r= equest behavior.=20 >=20 > [Michiko Short] Creating a freshness token will be a crypto hit on the KD= C, so sending freshness tokens to clients who will never use them will nega= tively impact KDC performance with no gains. If the PKInit client does not = explicitly ask for the token, then clients using password authentication wi= ll also have freshness tokens generated and sent to them.=20 That's worth considering. Here are my thoughts: * A freshness token doesn't have to be unique to a request or client; it ju= st has to be unknown to an attacker far in advance of an AS exchange. A KDC could compute a new global freshness token every five minutes or so = (by encrypting the current time in a TGS key, for instance) and use it for = many requests. * A KDC only needs to send a freshness token if it is offering PKINIT (or a= future mechanism which also uses freshness tokens). I guess it's unusual = for that to be a per-client decision by the KDC; typically either the KDC i= s configured with PKINIT support or it isn't, and it offers PKINIT to all c= lients if it is. * Is AES encryption a significant load factor on modern KDCs? I don't have= numbers for our KDC at the moment. It probably depends a lot on whether A= ES-NI can be used. * If a client wants to save the KDC the effort of computing a freshness tok= en, it has to decide ahead of time whether it might be able to use PKINIT (= or a future mechanism which also uses freshness tokens). This is generally= possible, but maybe a bit complex. From nobody Wed Mar 18 19:37:08 2015 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 8FF2E1A8034 for ; Wed, 18 Mar 2015 19:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 weSluXfr9tB4 for ; Wed, 18 Mar 2015 19:37:07 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F140A1A802A for ; Wed, 18 Mar 2015 19:37:06 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id A6D6D76806E; Wed, 18 Mar 2015 19:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=9eCYfOrKtqd2gZ R/gebzWHSoZBM=; b=gzfZta3o0PwAHyNokvmUHbmlF0RwmnIvh9nvIzW3qQgFPZ rEbaLO6snzMaMaT4v9QYZVfApetrCrz36YY/Eeo67ADsCxgAJXGfKZgAp00Y+ApQ HcGxXJCuUn5bO06q8J70lScWHlWYj4oALVg4sN4BwQZf+6w141wO3O7Glk8QM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPA id 38C8776806D; Wed, 18 Mar 2015 19:37:05 -0700 (PDT) Date: Wed, 18 Mar 2015 21:37:04 -0500 From: Nico Williams To: Wang Weijun Message-ID: <20150319023703.GA8099@localhost> References: <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org, Thomas.Maslen@software.dell.com, OpenJDK Dev list Subject: Re: [kitten] On stream-based GSSContext methods in RFC 5653 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, 19 Mar 2015 02:37:07 -0000 On Mon, Mar 16, 2015 at 11:46:46AM +0800, Wang Weijun wrote: > I discussed with my colleagues on the stream-based methods and we > think they are not well-designed: I agree. From nobody Wed Mar 18 19:52:22 2015 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 AD24E1A8701 for ; Wed, 18 Mar 2015 19:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 GdHfOIl4uKyT for ; Wed, 18 Mar 2015 19:52:19 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DDBF51A8700 for ; Wed, 18 Mar 2015 19:52:19 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 9BE052005E61A for ; Wed, 18 Mar 2015 19:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=QXhwH9LVntsL4AxENgq32whCBbY=; b=h7e3wCJ8mWW LmMiKN6jZjhBgzikLhKEpvslXGnNPK6++T00gGUuH54NJHDzzk60RUEN4pDYa765 iNpP9K9kdX/2RxH11cPblVdYb8WlZDPwI8OTq1ChXChMtDQx2Ce0UFlPeg5rMZ8h w+64Q9hWTTdDr39VpfZ2Jk0oOqIK+wOw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 6B2752005E619 for ; Wed, 18 Mar 2015 19:52:18 -0700 (PDT) Date: Wed, 18 Mar 2015 21:52:02 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20150319025202.GB8099@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [kitten] Clarification of gss_add_cred() behavior 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, 19 Mar 2015 02:52:20 -0000 I need a clarification of RFCs 2743 and 2744 as to GSS_add_cred(). Is it really the case that calling GSS_Add_cred() with no input_cred_handle (GSS_C_NO_CREDENTIAL) must ignore desired_name even when it is not the GSS_C_NO_NAME?? I think the answer is that this text in RFC2743 section 2.1.4, page 39: If GSS_C_NO_CREDENTIAL is specified as input_cred_handle, a non-NULL output_cred_handle must be supplied. For the case of GSS_C_NO_CREDENTIAL as input_cred_handle, GSS_Add_cred() will create the credential referenced by its output_cred_handle based on default behavior. That is, the call will have the same effect as if the caller had previously called GSS_Acquire_cred(), specifying the same usage and passing GSS_C_NO_NAME as the desired_name parameter (thereby obtaining an explicit credential handle corresponding to default behavior), had passed that credential handle to GSS_Add_cred(), and had finally called GSS_Release_cred() on the credential handle received from GSS_Acquire_cred(). and the corresponding and matching text in RFC2744 section 5.3, are subtly wrong. This text should have read thusly: If GSS_C_NO_CREDENTIAL is specified as input_cred_handle, a non-NULL output_cred_handle must be supplied. For the case of GSS_C_NO_CREDENTIAL as input_cred_handle and desired_name as GSS_C_NO_NAME, GSS_Add_cred() will create the credential referenced by its output_cred_handle based on default behavior. ... That is, it should be possible to call GSS_Add_cred() with input_cred_handle == GSS_C_NO_CREDENTIAL and a desired_name != GSS_C_NO_NAME, and get a CREDENTIAL HANDLE for that desired_name. Otherwise GSS_Add_cred() is mostly useless. I think this must have been a drafting error. It's obvious to me, but maybe someone has a very different opinion as to this (Martin?). Nico -- From nobody Wed Mar 18 20:00:11 2015 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 433DF1A8547 for ; Wed, 18 Mar 2015 20:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AwRLpFF2Sxlr for ; Wed, 18 Mar 2015 20:00:05 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912A01A802A for ; Wed, 18 Mar 2015 20:00:05 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2J303hs021092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Mar 2015 03:00:04 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2J2vAje008349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Mar 2015 02:57:11 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t2J2vA7Z013795; Thu, 19 Mar 2015 02:57:10 GMT Received: from [192.168.10.107] (/114.250.174.244) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Mar 2015 19:57:10 -0700 Message-ID: <550A3AF9.4020701@oracle.com> Date: Thu, 19 Mar 2015 10:56:57 +0800 From: Weijun Wang User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Nico Williams References: <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> <20150319023703.GA8099@localhost> In-Reply-To: <20150319023703.GA8099@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Cc: kitten@ietf.org, Thomas.Maslen@software.dell.com, OpenJDK Dev list Subject: Re: [kitten] On stream-based GSSContext methods in RFC 5653 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, 19 Mar 2015 03:00:10 -0000 So what's your suggestion on their future? A: Remove them and say "they are removed" in a "Changed since" section. B: Move them to an appendix and say "they will not be developed anymore and please do not use them". C: Keep them in the old section and say "they will not be developed anymore and please do not use them". Thanks Max On 3/19/2015 10:37, Nico Williams wrote: > On Mon, Mar 16, 2015 at 11:46:46AM +0800, Wang Weijun wrote: >> I discussed with my colleagues on the stream-based methods and we >> think they are not well-designed: > > I agree. > From nobody Thu Mar 19 06:32:31 2015 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 6E28E1A8A70 for ; Thu, 19 Mar 2015 06:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Vgm7TPOe_uW2 for ; Thu, 19 Mar 2015 06:32:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 21E301A8A74 for ; Thu, 19 Mar 2015 06:32:24 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2JDWKjW032095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 19 Mar 2015 09:32:21 -0400 Received: from [10.3.113.73] (ovpn-113-73.phx2.redhat.com [10.3.113.73]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2JDWJgl001166; Thu, 19 Mar 2015 09:32:20 -0400 Message-ID: <1426771934.2981.127.camel@willson.usersys.redhat.com> From: Simo Sorce To: Nico Williams Date: Thu, 19 Mar 2015 09:32:14 -0400 In-Reply-To: <20150311001817.GC7286@localhost> References: <20150311001817.GC7286@localhost> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred() 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, 19 Mar 2015 13:32:29 -0000 On Tue, 2015-03-10 at 19:18 -0500, Nico Williams wrote: > The subject came up today, and I thought I'd state my opinion here about > permissible and impermissible side-effects of GSS_Acquire_cred(). (And, > indirectly, GSS_Init_sec_context() and GSS_Accept_sec_context().) > > It's certainly permissible for GSS_Acquire_cred() to have some kind of > side-effects. > > It's clear that GSS_Acquire_cred() was intended to get a "handle" to > credentials that exist. But side-effects crop up if we want it to bring > credentials into existence that weren't there before -- that's a big > side-effect, but it's also idempotent, and GSS apps in particular can't > really notice such a side-effect as the state transition is from > no-credentials to have-credentials [for some NAME(s) anyways]. > > For example, there have been implementations that if necessary would > pop-up a modal dialog asking the user for their password in order to > acquire credentials that would otherwise be unavailable. Such an > implementation has two side-effects: a) the modal interaction with the > user, and b) that credentials become available that had not been there > before. In some sense (a) is not a side-effect (it's not a modification > of the state of the world). (b) is a side-effect, but an idempotent > one (see above). > > Can we go from examples to principles? Let's try. > > I can see three principles: > > a) no side-effects outside caching, > b) idempotent side-effects only, > c) what principles? anything goes. > > The [implementation- and Kerberos-specific] question that came up was > (rephrased by me; others can chime in with additional questions like it): > > Given a keytab[0], can a call to GSS_Acquire_cred() change the > contents of a session's ccache[1], and if so, can it change the > default principal name? > > Principle (a) would lead to a generic answer like: tickets can be > cached, but notions of default principal cannot be set nor changed. > > Principle (b) would lead to a generic answer like; tickets can be > cached, the caches can be created, and the notion of default principal > can be set if not already set, but cannot be changed. > > Principle (c) allows any reasonable answer. > > In implementation-specific terms, (a) means that GSS_Acquire_cred() can > acquire a new TGT for the same principal(s) for which the default > cccol[2] or default ccache has TGTs, and it can re-initialize such > ccaches, but it cannot change the default principal for a session. This > leaves a corner case: you have a keytab but no cccol/ccache. For that > case the answer is that if there's no way make a good selection > of default principal, then the the TGT(s) should be saved somewhere if > possible, but still not be made available as the default credential > (perhaps this means that the TGTs are acquired every time they are > needed, and never cached). > > In implementation-specific terms, (b) means the same as (a) except that > if there's no cccol/ccache already, then the implementation can pick any > principal it likes from the keytab, and set it as the default principal. > > My preference is for (a), and if I can't get (a) (certainly some > implementations don't adhere to it) then (b); (c) is out. > > [0] A file containing long-term secret encryption keys for Kerberos > principals. > > [1] A file containing Kerberos tickets, possibly acquire with use of a > keytab. Typically a ccahce has tickets for just one client > principal. > > [2] A collection of ccaches, each for a different client principal. I tend to agree with you in abstract, however given b) is the actual, and I would say expected in many cases, behavior, I do not't think we can retroactively mandate a), but b) should be good enough. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Mar 19 08:01:26 2015 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 A57031ACD88 for ; Thu, 19 Mar 2015 08:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 czLT03TZ11fQ for ; Thu, 19 Mar 2015 08:01:19 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F17231ACD85 for ; Thu, 19 Mar 2015 08:01:18 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id B3F0235004F; Thu, 19 Mar 2015 08:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=+4hhABd+7mZ4kt e/Ckof8lgS98k=; b=VLAND3Ar9kh9uvzb5fXr+XVwPBM2yxdSA75IAaUlUIQZ2/ YVsAXf0K7EkbKfZGIL1TvBAmzZ7JDqXPQiNkdbTnW8ek0PxeEf0+gA0qnbtxjxfp VjqBapGQUwPU6SyC7aw07QTs7Pc6QwIofAFnP2L/8cShfOE6j++CbSN/Ym5zs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id 0F644350078; Thu, 19 Mar 2015 08:01:17 -0700 (PDT) Date: Thu, 19 Mar 2015 10:01:16 -0500 From: Nico Williams To: Weijun Wang Message-ID: <20150319150115.GC8099@localhost> References: <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> <20150319023703.GA8099@localhost> <550A3AF9.4020701@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550A3AF9.4020701@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org, Thomas.Maslen@software.dell.com, OpenJDK Dev list Subject: Re: [kitten] On stream-based GSSContext methods in RFC 5653 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, 19 Mar 2015 15:01:20 -0000 On Thu, Mar 19, 2015 at 10:56:57AM +0800, Weijun Wang wrote: > So what's your suggestion on their future? > > A: Remove them and say "they are removed" in a "Changed since" section. Remove them and mention that they used to be there and they have been removed, "do not use". Nico -- From nobody Thu Mar 19 08:17:28 2015 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 671C41A020A for ; Thu, 19 Mar 2015 08:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 xb_npYZ2h9xT for ; Thu, 19 Mar 2015 08:17:25 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 392F01A03D5 for ; Thu, 19 Mar 2015 08:17:21 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id BA0201B4078; Thu, 19 Mar 2015 08:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=s/t/ULpB1p/H6C ZciGrqOj6aCSo=; b=fG3h2IF9dRk9SDGeMewpZ8+02VOFkESEKcZetPNInK5T5j orhNSoez4lvpl0cRMh684HosNK/uTy2ZMFz3iR/qmMRF1nfeOQcvs3hbaTIHNrA8 8Rlm4heSMH29EDDv75KL6HsFFOPJ5bRbp+BcXFZCmm+xtcZ6KTk9UBI2LvuqY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPA id 333CB1B405F; Thu, 19 Mar 2015 08:17:20 -0700 (PDT) Date: Thu, 19 Mar 2015 10:17:19 -0500 From: Nico Williams To: Simo Sorce Message-ID: <20150319151718.GD8099@localhost> References: <20150311001817.GC7286@localhost> <1426771934.2981.127.camel@willson.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1426771934.2981.127.camel@willson.usersys.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred() 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, 19 Mar 2015 15:17:26 -0000 On Thu, Mar 19, 2015 at 09:32:14AM -0400, Simo Sorce wrote: > On Tue, 2015-03-10 at 19:18 -0500, Nico Williams wrote: > > I can see three principles: > > > > a) no side-effects outside caching, > > b) idempotent side-effects only, > > c) what principles? anything goes. > > I tend to agree with you in abstract, however given b) is the actual, > and I would say expected in many cases, behavior, I do not't think we > can retroactively mandate a), but b) should be good enough. ISTR hearing someone (you?) say (a couple of weeks ago on a krbdev call) that creating a default ccache with one of N > 1 principals' keytab creds is sometimes surprising to users, and I can see why it would be! This is a form of (b). The problem here is setting the default principal name when none had already been set -- a non-trivial side-effect. I'm inclined to consider (b) a bug. A low-priority bug perhaps, but a bug. Implementations could do something else. E.g., not cache (thus increasing load on clients and KDCs), or cache in a "shadow default ccache", or switch to DIR ccache. Those are details. The main thing is that (b) is surprising. Nico -- From nobody Thu Mar 19 08:20:20 2015 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 74E031ACDBD for ; Thu, 19 Mar 2015 08:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 3ZDwIgED7nyz for ; Thu, 19 Mar 2015 08:20:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 74E9D1ACD79 for ; Thu, 19 Mar 2015 08:20:13 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2JFKAHo008433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 19 Mar 2015 11:20:11 -0400 Received: from [10.3.113.73] (ovpn-113-73.phx2.redhat.com [10.3.113.73]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2JFKAXh005587; Thu, 19 Mar 2015 11:20:10 -0400 Message-ID: <1426778409.2981.129.camel@willson.usersys.redhat.com> From: Simo Sorce To: Nico Williams Date: Thu, 19 Mar 2015 11:20:09 -0400 In-Reply-To: <20150319151718.GD8099@localhost> References: <20150311001817.GC7286@localhost> <1426771934.2981.127.camel@willson.usersys.redhat.com> <20150319151718.GD8099@localhost> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred() 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, 19 Mar 2015 15:20:19 -0000 On Thu, 2015-03-19 at 10:17 -0500, Nico Williams wrote: > On Thu, Mar 19, 2015 at 09:32:14AM -0400, Simo Sorce wrote: > > On Tue, 2015-03-10 at 19:18 -0500, Nico Williams wrote: > > > I can see three principles: > > > > > > a) no side-effects outside caching, > > > b) idempotent side-effects only, > > > c) what principles? anything goes. > > > > I tend to agree with you in abstract, however given b) is the actual, > > and I would say expected in many cases, behavior, I do not't think we > > can retroactively mandate a), but b) should be good enough. > > ISTR hearing someone (you?) say (a couple of weeks ago on a krbdev call) > that creating a default ccache with one of N > 1 principals' keytab > creds is sometimes surprising to users, and I can see why it would be! > This is a form of (b). The problem here is setting the default > principal name when none had already been set -- a non-trivial side-effect. > > I'm inclined to consider (b) a bug. A low-priority bug perhaps, but a bug. > > Implementations could do something else. E.g., not cache (thus increasing > load on clients and KDCs), or cache in a "shadow default ccache", or > switch to DIR ccache. Those are details. The main thing is that (b) is > surprising. I guess it may be surprising in some cases, and expected in others, unfortunately. If you set the KRB5_CLIENT_KTNAME variable in recent MIT releases you expect a default ccache to be created with whatever is in the keytab for example. But you'd be surprised otherwise. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Mar 19 09:28:54 2015 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 C46E71A1AE8 for ; Thu, 19 Mar 2015 09:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 qKEJStZwI8_F for ; Thu, 19 Mar 2015 09:28:50 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3AD1A1ADF for ; Thu, 19 Mar 2015 09:28:50 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 6C6CF678083; Thu, 19 Mar 2015 09:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=zYvt2MC3IxQ59c zJB/1r9DZYo7E=; b=ufsAReL7ohaHUnSDtlrlq9U1ze9eSpp5OT/XXLPWxmr6/n kObYnHi5Oh4IjGVirhFkvKhch271UYjrfXR7PR8/W84k+RGScT0abPImvbxALycu kYat/rerbktZQ875rsFSx5KpQqcbkU3kmlAs0AzvgOmNZYmUNIhtTvHkDrwUk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 255E2678063; Thu, 19 Mar 2015 09:28:50 -0700 (PDT) Date: Thu, 19 Mar 2015 11:28:49 -0500 From: Nico Williams To: Simo Sorce Message-ID: <20150319162847.GG8099@localhost> References: <20150311001817.GC7286@localhost> <1426771934.2981.127.camel@willson.usersys.redhat.com> <20150319151718.GD8099@localhost> <1426778409.2981.129.camel@willson.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1426778409.2981.129.camel@willson.usersys.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred() 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, 19 Mar 2015 16:28:51 -0000 On Thu, Mar 19, 2015 at 11:20:09AM -0400, Simo Sorce wrote: > I guess it may be surprising in some cases, and expected in others, > unfortunately. > If you set the KRB5_CLIENT_KTNAME variable in recent MIT releases you > expect a default ccache to be created with whatever is in the keytab for > example. But you'd be surprised otherwise. Since it's both, sometimes surprising and sometimes expected, you get to pick what to end up with. Perhaps one behavior will cause more customer calls than the other. But I think there are compromises that get you (a) without breaking anyone. Again: - have a shadow default ccache for the case of acquiring a credential from a keytab when there is no default ccache - use the DIR ccache (does it have the option of not setting a default ccache in the collection?) - don't cache tickets when the default ccache does not exist - if there are keys for only one principal in the keytab, then set the default principal, else don't (and use one of the above fixes) And you could always add yet another environment variable, and/or krb5.conf parameter. To me it seems clear that GSS applications that do simple things like GSS_Init/Accept_sec_context() with the GSS_C_NO_CREDENTIAL, or which call GSS_Acquire/Add_cred(), do not cause other processes in the system to "break". Actually, this should be true for all GSS apps that do not call GSS_Store_cred() (whose entire purpose is to have side-effects). Even if you change nothing, I'm inclined to say that (a) is preferred and note that (b) is what one sometimes gets, therefore one must read the implementation's docs. I'd like to see this fixed (see above). Nico -- From nobody Thu Mar 19 10:04:58 2015 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 DFBFE1A1EFF for ; Thu, 19 Mar 2015 10:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 r-kEOLut08bN for ; Thu, 19 Mar 2015 10:04:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 4969F1A6EE1 for ; Thu, 19 Mar 2015 10:04:49 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2JH4l1V022406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 19 Mar 2015 13:04:47 -0400 Received: from [10.3.113.73] (ovpn-113-73.phx2.redhat.com [10.3.113.73]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2JH4k4N019986; Thu, 19 Mar 2015 13:04:46 -0400 Message-ID: <1426784686.2981.130.camel@willson.usersys.redhat.com> From: Simo Sorce To: Nico Williams Date: Thu, 19 Mar 2015 13:04:46 -0400 In-Reply-To: <20150319162847.GG8099@localhost> References: <20150311001817.GC7286@localhost> <1426771934.2981.127.camel@willson.usersys.redhat.com> <20150319151718.GD8099@localhost> <1426778409.2981.129.camel@willson.usersys.redhat.com> <20150319162847.GG8099@localhost> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred() 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, 19 Mar 2015 17:04:57 -0000 On Thu, 2015-03-19 at 11:28 -0500, Nico Williams wrote: > On Thu, Mar 19, 2015 at 11:20:09AM -0400, Simo Sorce wrote: > > I guess it may be surprising in some cases, and expected in others, > > unfortunately. > > If you set the KRB5_CLIENT_KTNAME variable in recent MIT releases you > > expect a default ccache to be created with whatever is in the keytab for > > example. But you'd be surprised otherwise. > > Since it's both, sometimes surprising and sometimes expected, you get to > pick what to end up with. Perhaps one behavior will cause more customer > calls than the other. > > But I think there are compromises that get you (a) without breaking > anyone. Again: > > - have a shadow default ccache for the case of acquiring a credential > from a keytab when there is no default ccache > > - use the DIR ccache (does it have the option of not setting a default > ccache in the collection?) > > - don't cache tickets when the default ccache does not exist > > - if there are keys for only one principal in the keytab, then set > the default principal, else don't (and use one of the above fixes) > > And you could always add yet another environment variable, and/or > krb5.conf parameter. > > To me it seems clear that GSS applications that do simple things like > GSS_Init/Accept_sec_context() with the GSS_C_NO_CREDENTIAL, or which > call GSS_Acquire/Add_cred(), do not cause other processes in the system > to "break". Actually, this should be true for all GSS apps that do not > call GSS_Store_cred() (whose entire purpose is to have side-effects). > > Even if you change nothing, I'm inclined to say that (a) is preferred > and note that (b) is what one sometimes gets, therefore one must read > the implementation's docs. I'd like to see this fixed (see above). Would you consider an explicitly set KRB5CCNAME env variable as an indication the admin is ok with acquired credentials ending up there ? Ie a) but using KRB5CCNAME presence as an indication a ccache can be used ? Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Mar 19 10:33:14 2015 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 AC6A11A873A for ; Thu, 19 Mar 2015 10:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 uI8YdWnwDb7d for ; Thu, 19 Mar 2015 10:33:08 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 79C321A701E for ; Thu, 19 Mar 2015 10:33:08 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 193D3200D3094; Thu, 19 Mar 2015 10:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=+4TnQ/uN4Vem87 2N7VoMS0sBZt4=; b=ksvQOrx8YyFt2DXUZQWL3aae7ZwJB3WkP1mAbS75XpqfXj GhvbPSaK9gPJlYjqtnPovsV9z9myPwan/uxCpOKROgc8T58ilaUNcClutp6K/oNT 6FGYvLj4gqHOJi0VYKBSxDbXmkoAnnpza92dVeQvqTXB9uKDt1hnqc9XpDLIQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPA id A359B200D3090; Thu, 19 Mar 2015 10:33:07 -0700 (PDT) Date: Thu, 19 Mar 2015 12:33:06 -0500 From: Nico Williams To: Simo Sorce Message-ID: <20150319173305.GH8099@localhost> References: <20150311001817.GC7286@localhost> <1426771934.2981.127.camel@willson.usersys.redhat.com> <20150319151718.GD8099@localhost> <1426778409.2981.129.camel@willson.usersys.redhat.com> <20150319162847.GG8099@localhost> <1426784686.2981.130.camel@willson.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1426784686.2981.130.camel@willson.usersys.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred() 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, 19 Mar 2015 17:33:13 -0000 On Thu, Mar 19, 2015 at 01:04:46PM -0400, Simo Sorce wrote: > Would you consider an explicitly set KRB5CCNAME env variable as an > indication the admin is ok with acquired credentials ending up there ? > Ie a) but using KRB5CCNAME presence as an indication a ccache can be > used ? That helps, though there can still be non-determinism when the ccache does not exist yet. (But if the admin/user set it, why wouldn't they also kinit -k to remove all doubt?) From nobody Thu Mar 19 10:44:06 2015 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 B31BC1A8772 for ; Thu, 19 Mar 2015 10:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jWyyE5SbbsPu for ; Thu, 19 Mar 2015 10:44:03 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4C41A7000 for ; Thu, 19 Mar 2015 10:44:03 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id E6FEA31CED5; Thu, 19 Mar 2015 17:44:02 +0000 (UTC) Received: from [10.3.113.73] (ovpn-113-73.phx2.redhat.com [10.3.113.73]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2JHi2t6004451; Thu, 19 Mar 2015 13:44:02 -0400 Message-ID: <1426787041.2981.135.camel@willson.usersys.redhat.com> From: Simo Sorce To: Nico Williams Date: Thu, 19 Mar 2015 13:44:01 -0400 In-Reply-To: <20150319173305.GH8099@localhost> References: <20150311001817.GC7286@localhost> <1426771934.2981.127.camel@willson.usersys.redhat.com> <20150319151718.GD8099@localhost> <1426778409.2981.129.camel@willson.usersys.redhat.com> <20150319162847.GG8099@localhost> <1426784686.2981.130.camel@willson.usersys.redhat.com> <20150319173305.GH8099@localhost> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred() 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, 19 Mar 2015 17:44:04 -0000 On Thu, 2015-03-19 at 12:33 -0500, Nico Williams wrote: > On Thu, Mar 19, 2015 at 01:04:46PM -0400, Simo Sorce wrote: > > Would you consider an explicitly set KRB5CCNAME env variable as an > > indication the admin is ok with acquired credentials ending up there ? > > Ie a) but using KRB5CCNAME presence as an indication a ccache can be > > used ? > > That helps, though there can still be non-determinism when the ccache > does not exist yet. (But if the admin/user set it, why wouldn't they > also kinit -k to remove all doubt?) Because, at least with the current implementation of the Keytab initiation feature in MIT, if you kinit explicitly then gss_init_sec_context will not take over and keep initiating when credentials expires etc... I understand this may be simply an implementation issue/bug and it can be decided differently, but in general keytab initiation is used to allow unattended systems work on their own, so the admin will start a service with all the evn var set right and let it to it's own thing, requiring to script a manual kinit would defeat the purpose. So I am trying to see if you think a) is compatible with something priming an empty initial ccache provided that both KRB5CCNAME and KRB5_CLIENT_KTNAME have been set in the environment (both required). Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Mar 19 11:48:52 2015 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 3C6C51A879E for ; Thu, 19 Mar 2015 11:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4Ohr6OLK9D-x for ; Thu, 19 Mar 2015 11:48:49 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239131A8792 for ; Thu, 19 Mar 2015 11:48:48 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-e7-550b1a0f792f 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 dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 52.14.03488.F0A1B055; Thu, 19 Mar 2015 14:48:47 -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 t2JImlN7015546; Thu, 19 Mar 2015 14:48:47 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2JImiDF013103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Mar 2015 14:48:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2JImiGb013196; Thu, 19 Mar 2015 14:48:44 -0400 (EDT) Date: Thu, 19 Mar 2015 14:48:44 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20150319025202.GB8099@localhost> Message-ID: References: <20150319025202.GB8099@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrssvxR1qcPmtpcXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGUsfLeZteCbYEXzmqUsDYzL+LoYOTkkBEwk Oq6vZoawxSQu3FvPBmILCSxmklhzkr+LkQvI3sgocezxYxYI5xCTRMPsBmYIp4FR4kr3ObAW FgFtiS3Xe8BGsQmoSMx8sxEsLiKgKXF93lIwm1lAWGL9uRlANRwcwgJ2EtumOoGEOQX0JN5e 7GIDCfMKOEjsOFMHcYSuRNvpw2ATRQV0JFbvn8ICYvMKCEqcnPmEBWKilsTy6dtYJjAKzkKS moUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGukV5uZoleakrpJkZQmHJK8u5gfHdQ6RCj AAejEg/vTwHuUCHWxLLiytxDjJIcTEqivIvEgUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeO+J AeV4UxIrq1KL8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR4j0sANQoWpaanVqRl 5pQgpJk4OEGG8wANfwZSw1tckJhbnJkOkT/FqCglzqsjCZQQAElklObB9cLSyCtGcaBXhHkN QKp4gCkIrvsV0GAmoMH/arlABpckIqSkGhiXHDkgyHa/tHKj1LmLzU8jl9WcfV/dcOQ+t8nM buNzR6uvXXxd8a3kpq+zVljtJ4GMidusdSulZ+i2H7zf5v7nXpHZ7Z7m3xcclh7Ud5TL2nlz crVxNQtLEcuBWQxr/v2051l7UneBP2/rRtMIAWG9FWe+VPA+3iOptWnrxt9u6udTz082Wdet xFKckWioxVxUnAgAHFGNov4CAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Clarification of gss_add_cred() behavior 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, 19 Mar 2015 18:48:51 -0000 On Wed, 18 Mar 2015, Nico Williams wrote: > I need a clarification of RFCs 2743 and 2744 as to GSS_add_cred(). > > Is it really the case that calling GSS_Add_cred() with no > input_cred_handle (GSS_C_NO_CREDENTIAL) must ignore desired_name > even when it is not the GSS_C_NO_NAME?? > > I think the answer is that this text in RFC2743 section 2.1.4, page 39: > > If GSS_C_NO_CREDENTIAL is specified as input_cred_handle, a non-NULL > output_cred_handle must be supplied. For the case of > GSS_C_NO_CREDENTIAL as input_cred_handle, GSS_Add_cred() will create > the credential referenced by its output_cred_handle based on default > behavior. That is, the call will have the same effect as if the > caller had previously called GSS_Acquire_cred(), specifying the same > usage and passing GSS_C_NO_NAME as the desired_name parameter > (thereby obtaining an explicit credential handle corresponding to > default behavior), had passed that credential handle to > GSS_Add_cred(), and had finally called GSS_Release_cred() on the > credential handle received from GSS_Acquire_cred(). > > and the corresponding and matching text in RFC2744 section 5.3, are > subtly wrong. This text should have read thusly: > > If GSS_C_NO_CREDENTIAL is specified as input_cred_handle, a non-NULL > output_cred_handle must be supplied. For the case of > GSS_C_NO_CREDENTIAL as input_cred_handle and desired_name as > GSS_C_NO_NAME, GSS_Add_cred() will create > the credential referenced by its output_cred_handle based on default > behavior. ... > > That is, it should be possible to call GSS_Add_cred() with > input_cred_handle == GSS_C_NO_CREDENTIAL and a > desired_name != GSS_C_NO_NAME, and get a CREDENTIAL HANDLE for that > desired_name. > > Otherwise GSS_Add_cred() is mostly useless. > > I think this must have been a drafting error. It's obvious to me, but > maybe someone has a very different opinion as to this (Martin?). But a GSS credential can only represent a single identity ("entity", see 1.1.1.1)! Identities are represented by (non-mechanism) names, so it is not clear to me that this is a drafting error. If you know what name you want credentials for, you should use it. -Ben From nobody Thu Mar 19 12:16:55 2015 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 520541A8835 for ; Thu, 19 Mar 2015 12:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 3X424KPJZjR8 for ; Thu, 19 Mar 2015 12:16:52 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E64751A8840 for ; Thu, 19 Mar 2015 12:16:50 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id B6D68940AF; Thu, 19 Mar 2015 12:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=b8eU5kUO4YMWDe mVQj3/IS0/X48=; b=xotXo+iYrqiYrupSlN0HYZqi7bQMdyvdHir+Q9RrDBa91w Vef/v98ddkKYDQ1n/jmFeCHw1AnWd81OfMmazS/9sGepnC6OHcSSIXDpQ8hO+NUw jtidcixs59nClzRAHHpQtBno5q4/kXacZjNA1IRWjXZkUTpSkQLDbnUlQZefo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 0E1C19409B; Thu, 19 Mar 2015 12:16:49 -0700 (PDT) Date: Thu, 19 Mar 2015 14:16:41 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150319191640.GK8099@localhost> References: <20150319025202.GB8099@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Clarification of gss_add_cred() behavior 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, 19 Mar 2015 19:16:53 -0000 On Thu, Mar 19, 2015 at 02:48:44PM -0400, Benjamin Kaduk wrote: > But a GSS credential can only represent a single identity ("entity", see > 1.1.1.1)! Identities are represented by (non-mechanism) names, so it is > not clear to me that this is a drafting error. If you know what name you > want credentials for, you should use it. That's not what this is about. I'm not asking for multiple elements for the same mech but different desired_names. The problem is the spec effectivel says that when input_cred_handle == GSS_C_NO_CREDENTIAL then desired_name is ignored. This seems like a mistake. Nico -- From nobody Thu Mar 19 12:40:07 2015 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 4788E1A8BC0 for ; Thu, 19 Mar 2015 12:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hkG7MLcTv_My for ; Thu, 19 Mar 2015 12:40:04 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (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 6D1771A8BC1 for ; Thu, 19 Mar 2015 12:40:04 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C4079283011; Thu, 19 Mar 2015 19:40:02 +0000 (UTC) Date: Thu, 19 Mar 2015 19:40:02 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20150319194002.GG4309@mournblade.imrryr.org> References: <20150319025202.GB8099@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [kitten] Clarification of gss_add_cred() behavior X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 19:40:06 -0000 On Thu, Mar 19, 2015 at 02:48:44PM -0400, Benjamin Kaduk wrote: > > I think this must have been a drafting error. It's obvious to me, but > > maybe someone has a very different opinion as to this (Martin?). > > But a GSS credential can only represent a single identity ("entity", see > 1.1.1.1)! Identities are represented by (non-mechanism) names, so it is > not clear to me that this is a drafting error. If you know what name you > want credentials for, you should use it. The situation as I understand it is as follows. 1. gss_add_cred() is intended to build a credential handle *incrementally*, adding credentials one mechanism at a time. Either for a default name, or for an explicit name that agrees with any previous credentials in the input handle. 2. For this interface to be useful, the initial state one must be able to start with an empty credential handle and build up from there. This presumably is specified via a NULL input credential, and still the same name for which one wants creds. 3. So how are the desired "name" and "mech" used when going from no creds (NULL input handle) to a handle with a first credential element? 4. The text says that a default credential handle is implicitly constructed with GSS_C_NO_NAME, and we add to that! But what if the acquired default credential has a conflicting name, and potentially already has elements for the same or other mechanisms? What is that text really trying to say, and why? -- Viktor. From nobody Thu Mar 19 12:50:33 2015 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 81E591A8EA9 for ; Thu, 19 Mar 2015 12:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0iLrCgHoR7WI for ; Thu, 19 Mar 2015 12:50:27 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54BC21A8824 for ; Thu, 19 Mar 2015 12:50:25 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-c3-550b28804d48 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 dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B9.87.03700.0882B055; Thu, 19 Mar 2015 15:50:24 -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 t2JJoO6Q028567 for ; Thu, 19 Mar 2015 15:50:24 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2JJoMaR016377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 19 Mar 2015 15:50:23 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2JJoMCQ021033; Thu, 19 Mar 2015 15:50:22 -0400 (EDT) Date: Thu, 19 Mar 2015 15:50:22 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <20150319194002.GG4309@mournblade.imrryr.org> Message-ID: References: <20150319025202.GB8099@localhost> <20150319194002.GG4309@mournblade.imrryr.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUixG6notugwR1qsG2SvsXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWrbe6aCq5IVB4/nNTB+FO5i5OSQEDCRuLy6gwXCFpO4cG89 WxcjF4eQwGImiSV/OlghnOOMEj+OXGeBcG4wSaxau4wZwmlglLjz5CkrSD+LgLbEr95jzCA2 m4CKxMw3G9lAbBEBYYndW98BxTk4hAXsJLZNdQIJcwpYSax+tQSshFfAQeLPlDmMEDMnMEoc PzGDESQhKqAjsXr/FBaIIkGJkzOfgNnMAloSy6dvY5nAKDALSWoWktQCRqZVjLIpuVW6uYmZ OcWpybrFyYl5ealFumZ6uZkleqkppZsYweHnoryD8c9BpUOMAhyMSjy8AcLcoUKsiWXFlbmH GCU5mJREecNlgEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeO+JAeV4UxIrq1KL8mFS0hwsSuK8 m37whQgJpCeWpGanphakFsFkZTg4lCR4DdSBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCG/1cDGV5c kJhbnJkOkT/FqCglznsXJCEAksgozYPrhaWHV4ziQK8I8/qArOABpha47ldAg5mABv+r5QIZ XJKIkJJqYNTe6iGz2+hVRXjoP6+e3VnLo+ztwys+nvoR7dv0OmEzx/vz507x3T5l01UzKeBD lMN0e+0bl/5v2n7jf7Tr03c36iZ2n1IzKfK43nHRgIXhFccegZ27Oa5fWlGm4zVrqUTCsuXV E07vfd/h9qaxe+Llp0/Wvw7rmV6497Lz+eR3//evexg6XbhXiaU4I9FQi7moOBEAXrnWkuoC AAA= Archived-At: Subject: Re: [kitten] Clarification of gss_add_cred() behavior 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, 19 Mar 2015 19:50:31 -0000 On Thu, 19 Mar 2015, Viktor Dukhovni wrote: > On Thu, Mar 19, 2015 at 02:48:44PM -0400, Benjamin Kaduk wrote: > > > > I think this must have been a drafting error. It's obvious to me, but > > > maybe someone has a very different opinion as to this (Martin?). > > > > But a GSS credential can only represent a single identity ("entity", see > > 1.1.1.1)! Identities are represented by (non-mechanism) names, so it is > > not clear to me that this is a drafting error. If you know what name you > > want credentials for, you should use it. > > The situation as I understand it is as follows. > > 1. gss_add_cred() is intended to build a credential handle > *incrementally*, adding credentials one mechanism at a time. > Either for a default name, or for an explicit name that > agrees with any previous credentials in the input handle. Well, I am not sure that it makes sense to try to do this for the default name (but see below). > 2. For this interface to be useful, the initial state one must > be able to start with an empty credential handle and build up > from there. This presumably is specified via a NULL input > credential, and still the same name for which one wants > creds. There is GSS_Acquire_cred to obtain the first credential element. > 3. So how are the desired "name" and "mech" used when going > from no creds (NULL input handle) to a handle with a first > credential element? A GSS_C_NO_CREDENTIAL input handle is not a representation of no creds, but rather a request to start from the default credentials. The default credentials must have some name associated with them, but we don't (necessarily?) know what that name is. My reading is that the only reliable way to request the name associated with the default credentials is to pass GSS_C_NO_NAME and not try to explicitly name the default identity. Now, maybe implementing this by completely ignoring the supplied desired_name is not very friendly, but it makes some amount of sense to me. > 4. The text says that a default credential handle is implicitly > constructed with GSS_C_NO_NAME, and we add to that! But what > if the acquired default credential has a conflicting name, and > potentially already has elements for the same or other mechanisms? I think that the attempt to add the new credential must fail. In general, if one is going to be doing anything with the default credentials, one has to only use the default credentials. If there are other credentials in play, only the specific (known) credentials should be used, to the exclusion of the default credentials. > What is that text really trying to say, and why? I guess my reading has the issue that if my reading is correct, why would they have mentioned the GSS_C_NO_CREDENTIAL case at all for GSS_Add_cred. Nico says: > The problem is the spec effectivel says that when input_cred_handle == > GSS_C_NO_CREDENTIAL then desired_name is ignored. This seems like a > mistake. My reply is that GSS_C_NO_CREDENTIAL means the default credentials which in turn means the default name. There's no use for an explcit name when the default name is being used. -Ben From nobody Thu Mar 19 12:50:51 2015 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 E6EBB1A8EA9 for ; Thu, 19 Mar 2015 12:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 bb7v1fGYtWOg for ; Thu, 19 Mar 2015 12:50:49 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 027961A8F40 for ; Thu, 19 Mar 2015 12:50:49 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 7505520047B82 for ; Thu, 19 Mar 2015 12:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=NMifAtnpKVhB6J7/JeJvSYcNC0g =; b=XV4hoflcZ47N4jCqt9O1ebFZ5n5wiVhOOs9ImrS4wSjkYxAA5o8Q47EwWT7 09nZmR87MoWbnBki0gpM1yUYQOCLuQW23QApIbOY6nTb1MAwneaU8T4YsQnhaiG5 Zlb5seNAw0f9S2TLaxEj5jWqB5puWGsK+vPHfnRNDNZ6tqr4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id 40DF820047B81 for ; Thu, 19 Mar 2015 12:50:48 -0700 (PDT) Date: Thu, 19 Mar 2015 14:50:47 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20150319195046.GL8099@localhost> References: <20150319025202.GB8099@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150319025202.GB8099@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [kitten] Clarification of gss_add_cred() behavior 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, 19 Mar 2015 19:50:50 -0000 Here's what I want (and which I always thought was a possible way to use gss_add_cred()): /* * Build a cred handle one elment-at-a-time. * * Here some_name is a gss_name_t value other than GSS_C_NO_NAME, * and some_mech is a gss_OID value other than GSS_C_NO_OID. */ maj = gss_add_cred(&min, GSS_C_NO_CREDENTIAL, some_name, some_mech, GSS_C_INITIATE, GSS_C_INDEFINITE, 0, &new_cred, NULL, NULL, NULL); if (maj == GSS_S_COMPLETE) { /* Yes! I have a cred handle for {some_mech, some_name}! */ ... /* * Now I can gss_add_cred() more elements to the brand-new * new_cred, one element-at-a-time. */ maj = gss_add_cred(&min, new_cred, some_name, other_mech, GSS_C_INITIATE, GSS_C_INDEFINITE, 0, NULL, NULL, NULL, NULL); ... } This would be a handy use-case when the caller wants to initiate a security context as the same initiator principal as a previous time, and with the same mechanism (think: SSHv2 re-key exchange with GSS), which is useful when one wants to re-delegate a fresh credential for the same initiator principal to some target. Now, the text in RFCs 2743 and 2744 as to what happens when input_cred_handle == GSS_C_NO_CREDENTIAL means that my some_name desired_name must get ignored in the above code, which makes the above not feasible at all. But it's worse than that: I can't even use gss_add_cred() to get a single-mechanism element credential handle if I don't already have one. It means I can't really use gss_add_cred() without also first using gss_acquire_cred(). Using gss_acquire_cred() at all is obnoxious when you have a single mechanism that you want a credential for. With the text as-is the only real use of gss_add_cred() is to function as a would-be gss_duplicate_cred() when you ask for an output_cred_handle. But it's a rather difficult-to-use cred handle dup function... Nico -- On Wed, Mar 18, 2015 at 09:52:02PM -0500, Nico Williams wrote: > I think the answer is that this text in RFC2743 section 2.1.4, page 39: > > If GSS_C_NO_CREDENTIAL is specified as input_cred_handle, a non-NULL > output_cred_handle must be supplied. For the case of > GSS_C_NO_CREDENTIAL as input_cred_handle, GSS_Add_cred() will create > the credential referenced by its output_cred_handle based on default > behavior. That is, the call will have the same effect as if the > caller had previously called GSS_Acquire_cred(), specifying the same > usage and passing GSS_C_NO_NAME as the desired_name parameter > (thereby obtaining an explicit credential handle corresponding to > default behavior), had passed that credential handle to > GSS_Add_cred(), and had finally called GSS_Release_cred() on the > credential handle received from GSS_Acquire_cred(). > > and the corresponding and matching text in RFC2744 section 5.3, are > subtly wrong. [...] From nobody Thu Mar 19 12:56:11 2015 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 45EF81A8F46 for ; Thu, 19 Mar 2015 12:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 l6T1URz8iWwL for ; Thu, 19 Mar 2015 12:56:07 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8CADB1A8F40 for ; Thu, 19 Mar 2015 12:56:07 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 74221594058; Thu, 19 Mar 2015 12:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=NEN4CIMC05ZO9H Q1HrG5D8D9C1I=; b=ea16J8xkjwHVm66Zv04mCi3eOxhXPkPNxka6tkVhhpKvAD 9OQOgqF0s4YqzMgPU2BM+vetf0gzf9Rnft7zsa6jpbbRRbVW8wLbmBllCEOj4Eyl 2tGcA+VPkOz3cSf17Lw68UIvMgb8qJzP+8PqxZ4iCYIbXD/9OvzP753pOYwbs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id DAC8E594054; Thu, 19 Mar 2015 12:56:06 -0700 (PDT) Date: Thu, 19 Mar 2015 14:56:06 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150319195605.GM8099@localhost> References: <20150319025202.GB8099@localhost> <20150319194002.GG4309@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Clarification of gss_add_cred() behavior 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, 19 Mar 2015 19:56:08 -0000 On Thu, Mar 19, 2015 at 03:50:22PM -0400, Benjamin Kaduk wrote: > Nico says: > > The problem is the spec effectivel says that when input_cred_handle == > > GSS_C_NO_CREDENTIAL then desired_name is ignored. This seems like a > > mistake. > > My reply is that GSS_C_NO_CREDENTIAL means the default credentials which > in turn means the default name. There's no use for an explcit name when > the default name is being used. But I have a desired_name, and if it is the GSS_C_NO_NAME, then sure, that means "default", but if it's not, then gss_add_cred() is useless. Think about what the quoted RFC text means... First GSS will acquire a default credential (for what mechanisms? not stated!). THEN it will try to add an element for the desired_mech... which element should already be present, therefore GSS_Add_cred() with input_cred_handle == GSS_C_NO_CREDENTIAL -> same as GSS_Acquire_cred() with desired_name == GSS_C_NO_NAME. But then I can never use GSS_Add_cred() to acquire a signle-element credential, and I must always use GSS_Acquire_cred() for that (which is lame for several reasons). This totally conflicts with the stated purpose of GSS_Add_cred(): GSS_Add_cred() enables callers to construct credentials iteratively by adding credential elements in successive operations, corresponding to different mechanisms. This offers particular value in multi- mechanism environments, as the major_status and minor_status values returned on each iteration are individually visible and can therefore be interpreted unambiguously on a per-mechanism basis. A credential element is identified by the name of the principal to which it refers. [...] Nico -- From nobody Thu Mar 19 12:57:27 2015 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 2361E1A1EF3 for ; Thu, 19 Mar 2015 12:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8m5rdC819Uys for ; Thu, 19 Mar 2015 12:57:21 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (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 A803C1A1A70 for ; Thu, 19 Mar 2015 12:57:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9A3B5283011; Thu, 19 Mar 2015 19:57:20 +0000 (UTC) Date: Thu, 19 Mar 2015 19:57:20 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20150319195720.GI4309@mournblade.imrryr.org> References: <20150319025202.GB8099@localhost> <20150319194002.GG4309@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [kitten] Clarification of gss_add_cred() behavior X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 19:57:26 -0000 On Thu, Mar 19, 2015 at 03:50:22PM -0400, Benjamin Kaduk wrote: > > 2. For this interface to be useful, the initial state one must > > be able to start with an empty credential handle and build up > > from there. This presumably is specified via a NULL input > > credential, and still the same name for which one wants > > creds. > > There is GSS_Acquire_cred to obtain the first credential element. So I believe that you're saying that gss_add_cred() not intended to be able to add the *first* credential element. That is: 1. Always call gss_acquire_cred() with a singleton mechanism set (to get the first mechanism) and desired name. 2. Then, as appropriate, call gss_add_cred() for any *additional* mechanisms. This makes the API more unpleasant to use, but sounds plausibly consistent with the text... -- Viktor. From nobody Thu Mar 19 14:05:00 2015 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 40B811ACEC4 for ; Thu, 19 Mar 2015 14:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 p7OVHM--EY5I for ; Thu, 19 Mar 2015 14:04:58 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4B21ACEBD for ; Thu, 19 Mar 2015 14:04:58 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id 1493E2005E807 for ; Thu, 19 Mar 2015 14:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=nP9+FJM7apEOKGaSYuUcXI+0aUs =; b=IsRKPa+kpdZkvXcrdTnaoPPbFW4U8Jmn/jNjbGJa0uKuYIIV3RwGf92VfFq +RYNlv1pN/gqPJfLXGc0qYT8MBmKVwkO6EaN1H+Aw4WdwEINLMe0K/ArYtPAqr91 NmOkkyMiKLBdzuamCoeI2JFzw7mB1Ms/kCNTciebFNiEIYWU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPA id D69C02005E800 for ; Thu, 19 Mar 2015 14:04:57 -0700 (PDT) Date: Thu, 19 Mar 2015 16:04:57 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20150319210456.GN8099@localhost> References: <20150319025202.GB8099@localhost> <20150319194002.GG4309@mournblade.imrryr.org> <20150319195720.GI4309@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150319195720.GI4309@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [kitten] Clarification of gss_add_cred() behavior 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, 19 Mar 2015 21:04:59 -0000 On Thu, Mar 19, 2015 at 07:57:20PM +0000, Viktor Dukhovni wrote: > On Thu, Mar 19, 2015 at 03:50:22PM -0400, Benjamin Kaduk wrote: > > > > 2. For this interface to be useful, the initial state one must > > > be able to start with an empty credential handle and build up > > > from there. This presumably is specified via a NULL input > > > credential, and still the same name for which one wants > > > creds. > > > > There is GSS_Acquire_cred to obtain the first credential element. > > So I believe that you're saying that gss_add_cred() not intended to > be able to add the *first* credential element. That is: > > 1. Always call gss_acquire_cred() with a singleton mechanism > set (to get the first mechanism) and desired name. > > 2. Then, as appropriate, call gss_add_cred() for any *additional* > mechanisms. > > This makes the API more unpleasant to use, [...] Decidedly more unpleasant. BTW, nowhere in RFCs 2743 and 2744 does it say that the minor_status output of GSS_Acquire_cred() corresponds to the one mechanism in desired_mechs when there is just one mechanism in it. But clarifying which mech the minor_status is for is one of the reasons given for GSS_Add_cred()'s very existence. Another reason given for GSS_Add_cred() is to support iterative construction of credential handles, but no mention is made of having to use GSS_Acquire_cred() to acquire a seed handle. > [...], but sounds plausibly > consistent with the text... I'm not sold on that yet. First, see above as to spec self-inconsistencies. Second, implementations seem to disagree: - MIT -> input_cred_handle == default -> allocates a new cred, honors desired_name; - Illumos -> same as MIT; - Heimdal -> input_cred_handle == default -> error; - GNU GSS -> not implemented, returns GSS_S_UNAVAILABLE; - gsskrb5 (Martin's SSPI shim) -> not implemented, returns GSS_S_FAILURE; - Illumos kgss (for RPCSEC_GSS) implements an unused kgss_add_cred() by calling up to gssd, which calls the one described above; - FreeBSD kgss (ditto) does not implement gss_add_cred() (nor kgss_add_cred()); - Linux kernel gss: does not implement any GSS functions dealing with creds, but clearly the behavior you (Viktor) and I prefer cannot be surprising: because if gss_add_cred() does anything other than fail, then it's doing what you and I want. Second, the "pleasant" behavior is clearly better. Sure, one can't rely on it, but then, neither could one rely on the default credential behavior, and that behavior always errors out in Heimdal, GNU, and gsskrb5. Incidentally, are there other implementations to check? I don't think so. I think I've checked all the open-source ones (even "PGSSAPI", which also doesn't implement gss_add_cred()). I know of none that are not open source other than Solaris' (whose lineage is the same as Illumos'). Nico -- From nobody Thu Mar 19 14:47:06 2015 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 A09981AD151 for ; Thu, 19 Mar 2015 14:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 TiETJt6Gv22w for ; Thu, 19 Mar 2015 14:47:04 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1F11AD0D2 for ; Thu, 19 Mar 2015 14:47:04 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id CBCC967C065 for ; Thu, 19 Mar 2015 14:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=qq2I3zL/8tgKXDd8wvZp/qQbRe0 =; b=A5YmrUSafpHGKAzdywjznf6rw0R8y1m1ZKxDxqstH6jfUhyF3MIbPp1PHwE hu1gDtSmmXBVtYUtBxHKWDBjwP5OFgBCq+oL2yp+Ejna5yD4c7FqtKUIM4esxbCD Si1aq467lNBrGofNXo1iCcuFyZpDusKazAyUTfAjm6zABjtA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPA id 8A38C67C06D for ; Thu, 19 Mar 2015 14:47:03 -0700 (PDT) Date: Thu, 19 Mar 2015 16:47:02 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20150319214700.GA21267@localhost> References: <20150319025202.GB8099@localhost> <20150319194002.GG4309@mournblade.imrryr.org> <20150319195720.GI4309@mournblade.imrryr.org> <20150319210456.GN8099@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150319210456.GN8099@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [kitten] Clarification of gss_add_cred() behavior 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, 19 Mar 2015 21:47:04 -0000 From: Nico Williams To: kitten@ietf.org Cc: Bcc: Subject: Re: [kitten] Clarification of gss_add_cred() behavior Message-ID: <20150319214213.GO8099@localhost> Reply-To: In-Reply-To: <20150319210456.GN8099@localhost> On the strength of what all the implementations I could check do, I'm going to make Heimdal match MIT and leave it at that. If someone wants to update the RFCs, that's fine with me. (I think it could be an erratum, but only if we agree that the RFC is either horribly broken or self-inconsistent, which we might not.) From nobody Thu Mar 19 17:20:42 2015 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 6D89B1A1A0F for ; Thu, 19 Mar 2015 17:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 cTrjNG5FrgCT for ; Thu, 19 Mar 2015 17:20:40 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CCDE1A066B for ; Thu, 19 Mar 2015 17:20:22 -0700 (PDT) X-AuditID: 12074424-f79f56d000000da5-3c-550b67c5871f 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 dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.15.03493.5C76B055; Thu, 19 Mar 2015 20:20:21 -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 t2K0KL14011167; Thu, 19 Mar 2015 20:20:21 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2K0KJPw024584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Mar 2015 20:20:20 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2K0KI1Q025007; Thu, 19 Mar 2015 20:20:18 -0400 (EDT) Date: Thu, 19 Mar 2015 20:20:18 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20150319195605.GM8099@localhost> Message-ID: References: <20150319025202.GB8099@localhost> <20150319194002.GG4309@mournblade.imrryr.org> <20150319195605.GM8099@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrXs0nTvU4NYia4ujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4cm0ee8ELporb188zNjDOZepi5OCQEDCR mL+IpYuRE8gUk7hwbz1bFyMXh5DAYiaJbfMbwBJCAhsZJfbf0YNIHGKSOL1nFxOE08AosWnq PTaQSSwC2hL3W8tAGtgEVCRmvtnIBmKLCGhKXJ+3FMxmFhCWWH9uBjNIubCAncS2qU4gYU4B PYn7f/eB7eIVcJDY0nSPGWL8c0aJGxdXgPWKCuhIrN4/BapIUOLkzCcsEDO1JJZP38YygVFw FpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9XIzS/RSU0o3MYLClN1FZQdj8yGl Q4wCHIxKPLwrRblDhVgTy4orcw8xSnIwKYnyciUAhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw JngC5XhTEiurUovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHh504AaBYtS01Mr 0jJzShDSTBycIMN5gIZ3gdTwFhck5hZnpkPkTzHqctyZ8n8RkxBLXn5eqpQ4LwtIkQBIUUZp HtwcWHp5xSgO9JYw71KQKh5gaoKb9ApoCRPQkn+1XCBLShIRUlINjAv2z/ZPYG+aLrk84P/v 89HHJ2RIzNyenh/3el764y4XZ4Wj5+7c2rTr3gQD7VST7WLLjRe6bC/m5vh17tb5v1VVWxSz +ngnK6curHdQvXuuQ2bWIhlRtR+uzh7lhycfy2JTn+L6v6EiryvW5ynvGe/Oc5vWTkjyNRZn nV0858PruUasXg2rfiqxFGckGmoxFxUnAgB5vRcXCgMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Clarification of gss_add_cred() behavior 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: Fri, 20 Mar 2015 00:20:41 -0000 On Thu, 19 Mar 2015, Nico Williams wrote: > GSS_C_NO_NAME. But then I can never use GSS_Add_cred() to acquire a > signle-element credential, and I must always use GSS_Acquire_cred() for > that (which is lame for several reasons). Perhaps I'm just being slow today, but could you say more about what these reasons for lameness are? Thanks, Ben From nobody Thu Mar 19 17:36:31 2015 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 844841A1B53 for ; Thu, 19 Mar 2015 17:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CBT3MeGwhYE2 for ; Thu, 19 Mar 2015 17:36:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (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 8DE171A1B4E for ; Thu, 19 Mar 2015 17:36:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 87D0D283011; Fri, 20 Mar 2015 00:36:25 +0000 (UTC) Date: Fri, 20 Mar 2015 00:36:25 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20150320003625.GR4309@mournblade.imrryr.org> References: <20150319025202.GB8099@localhost> <20150319194002.GG4309@mournblade.imrryr.org> <20150319195605.GM8099@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [kitten] Clarification of gss_add_cred() behavior X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 00:36:30 -0000 On Thu, Mar 19, 2015 at 08:20:18PM -0400, Benjamin Kaduk wrote: > On Thu, 19 Mar 2015, Nico Williams wrote: > > > GSS_C_NO_NAME. But then I can never use GSS_Add_cred() to acquire a > > signle-element credential, and I must always use GSS_Acquire_cred() for > > that (which is lame for several reasons). > > Perhaps I'm just being slow today, but could you say more about what these > reasons for lameness are? 1. Building a set of things via a different function for the first element than then the rest is ugly. 2. Calls to gss_acquire_cred() need a mechanism *set*, so one ends up building one-element sets for that, and disposing of those (though I'm working around that with automatic singleton mech sets): gss_OID mech = ...; gss_OID_set_desc onemech = { 1, mech }; gss_acquire_cred(..., &onemech, ...); Naively, one would allocate an empty set, add the mech to that, handle errors, ... use the set, and deallocate it. 3. Unclear semantics with respect to error reporting from gss_acquire_cred. Does it report the mechanism-specific minor code for the sole mechanism when oid set is a singleton? 4. The semantics of gss_add_cred() with GSS_C_NO_CREDENTIAL for the input cred are underspecified. (Which mechs are use to construct the missing initial cred handle? Is the desired_name ignored when the requested mech is "added", and in what sense is it "added" anyway, since other than name it would likely already be in that default credential?) The interface would be simpler and more clear if gss_add_cred() could just start from zero. -- Viktor. From nobody Thu Mar 19 17:45:36 2015 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 222831A6F7C for ; Thu, 19 Mar 2015 17:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 6YeAcCuKKy0R for ; Thu, 19 Mar 2015 17:45:29 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 25BEF1A6F28 for ; Thu, 19 Mar 2015 17:45:29 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id EB68B20058D81; Thu, 19 Mar 2015 17:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=+WGxNbAmVEFGVW +CTOyig8Eohi8=; b=OZDXv/q1Zj6mn/HxrZC2nAeBV/ABkUWNA7jrd4N+g2EJkU aJT8ouVYzw4JvWvu3+7hU9M3wF72MXudbgQz8u+XTFjqZ2C4lS0ufVAV1F47F8m8 BTm6yiLngaH3VAUts3UvCQzozJaQfp9A3eYYXfRKORyX85sOKbLT4Dw7c8a9M= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id AB7D32005CF2E; Thu, 19 Mar 2015 17:45:28 -0700 (PDT) Date: Thu, 19 Mar 2015 19:45:25 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150320004524.GC21267@localhost> References: <20150319025202.GB8099@localhost> <20150319194002.GG4309@mournblade.imrryr.org> <20150319195605.GM8099@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Clarification of gss_add_cred() behavior 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: Fri, 20 Mar 2015 00:45:30 -0000 On Thu, Mar 19, 2015 at 08:20:18PM -0400, Benjamin Kaduk wrote: > On Thu, 19 Mar 2015, Nico Williams wrote: > > GSS_C_NO_NAME. But then I can never use GSS_Add_cred() to acquire a > > signle-element credential, and I must always use GSS_Acquire_cred() for > > that (which is lame for several reasons). > > Perhaps I'm just being slow today, but could you say more about what these > reasons for lameness are? Sure: - the need to construct an OID set of one OID is lame (this is easy when one has only one or known-fixed-at-compile-time number of OIDs, but it's still lame) - minor_status is not associated with any mechanism per the specs, though one hopes that for the one-OID case minor_status is specific to that one mechanism, but if we're going to be as literal as we can in reading the spec, then this point is correct and GSS_Acquire_cred() is lame - fewer informative outputs (initiator and acceptor lifetime rec) (admittedly this one is not a big deal) The second is the real killer. It's one of the reasons given for the addition of GSS_Add_cred(). And if we interpret the spec as you propose, we can't have this feature. This is one reason to think that the spec is self-inconsistent. Other reasons to think the spec is self-inconsistent: - No information or pseudo-code or code is given showing how to iteratively construct credential handles. It probably wasn't thought through. But if the case of input_cred_handle == GSS_C_NO_CREDENTIAL && desired_name != GSS_C_NO_NAME is interpreted as I propose, then it's trivial to iteratively construct a credential handle. - It makes no sense anyways to ignore a non-default desired_name when the input_cred_handle is GSS_C_NO_CREDENTIAL, not in light of the fact that GSS_C_NO_NAME is how one refers to the default credential in GSS_Acquire_cred() calls. - In some places input_cred_handle is described as optional. Well, but GSS_C_NO_CREDENTIAL -> ignore desired_name means there's no real way to signal "I'm not providing an input cred handle", therefore it's either not optional, or the text I say is wrong is wrong. The RFC text I quoted as broken does not reflect reality for an implementation of the C bindings that I could check. I don't think anyone is proposing to implement the text I quoted. That leaves three choices: - file an erratum - publish an update - do nothing (anyone who runs into this will hopefully find this thread) I will not be submitting an I-D to update the RFCs just for this. If we have no consensus for an erratum, and no one else volunteers for the update, then it's the third choice: do nothing. Nico -- From nobody Thu Mar 19 19:15:16 2015 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 9938D1A9231 for ; Thu, 19 Mar 2015 19:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Hwonez_OmDSL for ; Thu, 19 Mar 2015 19:15:11 -0700 (PDT) Received: from amersmtp2.software.dell.com (amersmtp2.software.dell.com [12.106.87.227]) (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 C41321A9218 for ; Thu, 19 Mar 2015 19:15:10 -0700 (PDT) Received: from amersmtp2.software.dell.com (127.0.0.1) id h1e1au0171sg for ; Thu, 19 Mar 2015 19:15:10 -0700 (envelope-from ) Received: from ALVHTXW04.prod.quest.corp ([10.1.135.22]) by amersmtp2.software.dell.com (SonicWALL 8.0.7.2831) with ESMTPS (version=TLSv1 cipher=AES128-SHA bits=128/128) id 201503200215100285291; Thu, 19 Mar 2015 19:15:10 -0700 Received: from ALVMBXW01.prod.quest.corp ([fe80::48dd:e065:86b3:9cee]) by ALVHTXW04.prod.quest.corp ([::1]) with mapi id 14.03.0224.002; Thu, 19 Mar 2015 19:15:09 -0700 From: Thomas Maslen To: Wang Weijun , "kitten@ietf.org" , OpenJDK Dev list Thread-Topic: On stream-based GSSContext methods in RFC 5653 Thread-Index: AQHQX5vb/Y99Yyr37kSWo2jwGmpm850kfsqZ Date: Fri, 20 Mar 2015 02:15:08 +0000 Message-ID: References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 8.0.7.2831 X-Mlf-UniqueId: o201503200215100285291 Archived-At: Subject: Re: [kitten] On stream-based GSSContext methods in RFC 5653 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: Fri, 20 Mar 2015 02:15:14 -0000 My personal 0.02.=0A= =0A= First, my overall reaction to this is pretty much the same as my reaction t= o the GSSException change proposed in the rfc5653bis draft: I believe that= this aspect of 2853 / 5653 isn't broken and so I'm leery of "fixing" it --= but I don't feel strongly about it and I don't really object to it (much),= I mostly just want to make sure that we look before we leap.=0A= =0A= [But I do agree that if (a) we deprecate the stream-based GSSContext method= s and (b) we care about being able to both throw a GSSException and return = an error token, then (c) yes, in that case the GSSException change would th= en be necessary].=0A= =0A= To me, neither item 1 nor item 2 below is problematic for the stream-based = methods. Perhaps the assumptions that I'm using are different than yours?= =0A= =0A= What I mean by that is:=0A= =0A= I agree that if you took the raw InputStream from e.g. Socket.getInputStrea= m() and passed it to a stream-based GSSContext method then yes, it would be= problematic.=0A= =0A= But don't do that. Instead:=0A= =0A= (1) Read the token-length field from the raw InputStream. (There must = be a token-length field, or something equivalent to it -- if there wasn't, = you wouldn't be able to use the byte[]-based GSSContext methods either)=0A= =0A= (2) Use that length field to construct a wrapper InputStream (probably = a subclass of FilterInputStream) that lets you read that number of bytes an= d then returns EOF (even though the underlying raw InputStream probably sti= ll has data available). Yes, I'm definitely glossing over some details abo= ut ensuring that you always advance the underlying stream to the end of the= token, but that's just a SMOP.=0A= =0A= (3) Pass that wrapper InputStream (not the underlying raw InputStream) = to the stream-based GSSContext method.=0A= =0A= The advantage of doing this, c.f. just using the byte[]-based methods, is e= fficiency: with the byte[]-based methods you have to read the token length= , then allocate a byte[] that's at least that large and System.arraycopy() = all those bytes into it. [Unless, of course, you have already paid the pri= ce to read the entire application-protocol message into a byte[] -- in that= case, sure, it makes sense to use the byte[]-based GSSContext methods].=0A= =0A= So I believe that the InputStream parameters are useful because they allow = a more efficient implementation than using byte[].=0A= =0A= I admit that the argument for the OutputStream parameters is much weaker (h= ypothetically they could be useful if the application protocol used chunked= framing such as ASN.1 indefinite-length encoding, but in reality applicati= on protocols probably just use simple framing with a token-length field at = the beginning and so yeah, the OutputStream doesn't buy you anything, you m= ay as well just go ahead and return a byte[]).=0A= =0A= =0A= I agree that the "GSS-API authentication tokens contain a definite start an= d end" wording in RFC 2853 / 5653 makes it sound as though perhaps the orig= inal authors mistakenly believed that all GSSAPI context tokens included th= eir own framing (if so, then the stream-based methods were just a mistake c= aused by a flawed assumption, and it would be good to correct that mistake)= . I'm a Johnny-come-lately to this and I don't know what the original auth= ors actually thought / meant, but I choose to believe that no, they weren't= confused about the (non-)framing of GSSAPI context tokens and so no, the s= tream-based GSSContext methods weren't a mistake; rather, I believe that t= hey were thinking about InputStream wrappers such as the one I outlined abo= ve, so the stream-based GSSContext methods are valid (and shouldn't be depr= ecated), and the only thing that needs to be fixed is the misleading wordin= g, not the Java methods.=0A= =0A= If we do go ahead with deprecating the stream-based methods then yes, I'm f= ine with the changes that you outlined below:=0A= =0A= > [...] I propose to deprecate these methods in an I-D.=0A= > [...] In Oracle JDK and OpenJDK, we would like to mark these methods as @= deprecated. The existing implementations will be still supported.=0A= =0A= Good.=0A= =0A= Incidentally, w.r.t. Oracle JDK / OpenJDK: the current implementation assu= mes that all context-initiation tokens (not just the initial token but also= all subsequent context-initiation tokens) _do_ include framing (a GSSHeade= r). There are a couple of special-case exceptions (for the SPNEGO mechanis= m and for the SunNativeGSS provider), but in general the code requires that= all input tokens have a GSSHeader (and will error out, probably with DEFEC= TIVE_TOKEN, if they don't), and always prepends a GSSHeader to any outgoing= tokens that GSSContextSpi returns.=0A= =0A= So, even if the stream-based methods are deprecated, the current implementa= tion will still only support GSSAPI mechanisms where every context-initiati= on token has GSSHeader framing. My guess is that removing that limitation = would entail breaking the sun.security.jgss.spi (again).=0A= =0A= =0A= =0A= ________________________________________=0A= From: Wang Weijun [weijun.wang@oracle.com]=0A= Sent: Sunday, March 15, 2015 20:46=0A= To: kitten@ietf.org; OpenJDK Dev list=0A= Cc: Thomas Maslen; Benjamin Kaduk=0A= Subject: On stream-based GSSContext methods in RFC 5653=0A= =0A= Hi All=0A= =0A= I discussed with my colleagues on the stream-based methods and we think the= y are not well-designed:=0A= =0A= 1. A library should not define a wire protocol and assume the peer is using= the same. http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-05 require= s the application to define it.=0A= =0A= 2. It's impossible to implement these methods correctly when the mechanism = token has no self-framing or the library has no knowledge of the token form= at (for example,=0A= as a bridge talking to another GSS library).=0A= =0A= Therefore, I propose to deprecate these methods in an I-D. By deprecation, = I'd like to remove the methods from the main content and describe the reaso= n in a "Changes since RFC 5653" section. The specification for the methods = will be moved to an appendix or the "Changes since RFC 5653" section will c= ontain links to sections inside RFC 5653.=0A= =0A= In Oracle JDK and OpenJDK, we would like to mark these methods as @deprecat= ed. The existing implementations will be still supported.=0A= =0A= Thanks=0A= Max=0A= From nobody Thu Mar 19 20:24:35 2015 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 7C77C1A8035 for ; Thu, 19 Mar 2015 20:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jymxCCnT8NsZ for ; Thu, 19 Mar 2015 20:24:30 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CF11A0242 for ; Thu, 19 Mar 2015 20:24:29 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2K3ORKC011908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Mar 2015 03:24:28 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t2K3ORvt014747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Mar 2015 03:24:27 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t2K3ORan029301; Fri, 20 Mar 2015 03:24:27 GMT Received: from [192.168.10.106] (/114.250.174.244) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Mar 2015 20:24:26 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Wang Weijun In-Reply-To: Date: Fri, 20 Mar 2015 11:24:20 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <96E28C34-69BC-411B-A9FB-C352E270D648@oracle.com> References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> <, <>> To: Thomas Maslen X-Mailer: Apple Mail (2.2070.6) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "kitten@ietf.org" , OpenJDK Dev list Subject: Re: [kitten] On stream-based GSSContext methods in RFC 5653 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: Fri, 20 Mar 2015 03:24:32 -0000 Hi Thomas On Mar 20, 2015, at 10:15, Thomas Maslen = wrote: >=20 > My personal 0.02. >=20 > First, my overall reaction to this is pretty much the same as my = reaction to the GSSException change proposed in the rfc5653bis draft: I = believe that this aspect of 2853 / 5653 isn't broken and so I'm leery of = "fixing" it -- but I don't feel strongly about it and I don't really = object to it (much), I mostly just want to make sure that we look before = we leap. The GSSException case is not broken. It's just that the Java binding = does not have the same feature as the C binding, at least for the = token-based methods. You may say people can find a way to send the error = token using the stream-based methods without any API change, but since = we never documented anything before it could bring unexpected behavior = to current users. Also, it is too automatic and a user might want to = send a normal token but not send an error token. >=20 > [But I do agree that if (a) we deprecate the stream-based GSSContext = methods and (b) we care about being able to both throw a GSSException = and return an error token, then (c) yes, in that case the GSSException = change would then be necessary]. >=20 > To me, neither item 1 nor item 2 below is problematic for the = stream-based methods. Perhaps the assumptions that I'm using are = different than yours? For me, the main reason of (a) is that GSS-API is defined around tokens = and sending/receiving these tokens should be left to applications. Using = them, documenting them, and implementing them, are all unnecessarily = complicated. >=20 > What I mean by that is: >=20 > I agree that if you took the raw InputStream from e.g. = Socket.getInputStream() and passed it to a stream-based GSSContext = method then yes, it would be problematic. The javadoc for the methods seems to suggest that * while (!context.isEstablished()) { * * context.initSecContext(is, os); * * // send output token if generated * os.flush(); * } >=20 > But don't do that. Instead: >=20 > (1) Read the token-length field from the raw InputStream. (There = must be a token-length field, or something equivalent to it -- if there = wasn't, you wouldn't be able to use the byte[]-based GSSContext methods = either) >=20 > (2) Use that length field to construct a wrapper InputStream = (probably a subclass of FilterInputStream) that lets you read that = number of bytes and then returns EOF (even though the underlying raw = InputStream probably still has data available). Yes, I'm definitely = glossing over some details about ensuring that you always advance the = underlying stream to the end of the token, but that's just a SMOP. >=20 > (3) Pass that wrapper InputStream (not the underlying raw = InputStream) to the stream-based GSSContext method. >=20 > The advantage of doing this, c.f. just using the byte[]-based methods, = is efficiency: with the byte[]-based methods you have to read the token = length, then allocate a byte[] that's at least that large and = System.arraycopy() all those bytes into it. [Unless, of course, you = have already paid the price to read the entire application-protocol = message into a byte[] -- in that case, sure, it makes sense to use the = byte[]-based GSSContext methods]. >=20 > So I believe that the InputStream parameters are useful because they = allow a more efficient implementation than using byte[]. This is somehow what the example inside RFC 5653 7.4.8 is suggesting ByteArrayOutputStream os =3D new ByteArrayOutputStream(); ByteArrayInputStream is =3D null; do { // Re-create os? context.initSecContext(is, os); // send token if present if (os.size() > 0) sendToken(os); // check if we should expect more tokens if (context.isEstablished()) break; // another token expected from peer is =3D recvToken(); } while (true); but then the recvToken in the example above should not be defined as a = ByteArrayInputStream. >=20 > I admit that the argument for the OutputStream parameters is much = weaker (hypothetically they could be useful if the application protocol = used chunked framing such as ASN.1 indefinite-length encoding, but in = reality application protocols probably just use simple framing with a = token-length field at the beginning and so yeah, the OutputStream = doesn't buy you anything, you may as well just go ahead and return a = byte[]). Exactly, I don't know how to emit that length field before sending the = bytes into the stream. Creating a method like the following is ugly. byte[] initSecContext(InputStream ins) >=20 >=20 > I agree that the "GSS-API authentication tokens contain a definite = start and end" wording in RFC 2853 / 5653 makes it sound as though = perhaps the original authors mistakenly believed that all GSSAPI context = tokens included their own framing (if so, then the stream-based methods = were just a mistake caused by a flawed assumption, and it would be good = to correct that mistake). I'm a Johnny-come-lately to this and I don't = know what the original authors actually thought / meant, but I choose to = believe that no, they weren't confused about the (non-)framing of GSSAPI = context tokens and so no, the stream-based GSSContext methods weren't a = mistake; rather, I believe that they were thinking about InputStream = wrappers such as the one I outlined above, so the stream-based = GSSContext methods are valid (and shouldn't be deprecated), and the only = thing that needs to be fixed is the misleading wording, not the Java = methods. I don't know now. I am also late to this. >=20 > If we do go ahead with deprecating the stream-based methods then yes, = I'm fine with the changes that you outlined below: >=20 >> [...] I propose to deprecate these methods in an I-D. >> [...] In Oracle JDK and OpenJDK, we would like to mark these methods = as @deprecated. The existing implementations will be still supported. >=20 > Good. >=20 > Incidentally, w.r.t. Oracle JDK / OpenJDK: the current implementation = assumes that all context-initiation tokens (not just the initial token = but also all subsequent context-initiation tokens) _do_ include framing = (a GSSHeader). There are a couple of special-case exceptions (for the = SPNEGO mechanism and for the SunNativeGSS provider), but in general the = code requires that all input tokens have a GSSHeader (and will error = out, probably with DEFECTIVE_TOKEN, if they don't), and always prepends = a GSSHeader to any outgoing tokens that GSSContextSpi returns. >=20 > So, even if the stream-based methods are deprecated, the current = implementation will still only support GSSAPI mechanisms where every = context-initiation token has GSSHeader framing. My guess is that = removing that limitation would entail breaking the sun.security.jgss.spi = (again). We don't plan to make any change. What we can say now is that they have = a problem and could go wrong. If we add a new mechanism later that does = not have a self-framing, we might have to consume all bytes available = and treat it as the input token. --Max >=20 >=20 >=20 > ________________________________________ > From: Wang Weijun [weijun.wang@oracle.com] > Sent: Sunday, March 15, 2015 20:46 > To: kitten@ietf.org; OpenJDK Dev list > Cc: Thomas Maslen; Benjamin Kaduk > Subject: On stream-based GSSContext methods in RFC 5653 >=20 > Hi All >=20 > I discussed with my colleagues on the stream-based methods and we = think they are not well-designed: >=20 > 1. A library should not define a wire protocol and assume the peer is = using the same. http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-05 = requires the application to define it. >=20 > 2. It's impossible to implement these methods correctly when the = mechanism token has no self-framing or the library has no knowledge of = the token format (for example, > as a bridge talking to another GSS library). >=20 > Therefore, I propose to deprecate these methods in an I-D. By = deprecation, I'd like to remove the methods from the main content and = describe the reason in a "Changes since RFC 5653" section. The = specification for the methods will be moved to an appendix or the = "Changes since RFC 5653" section will contain links to sections inside = RFC 5653. >=20 > In Oracle JDK and OpenJDK, we would like to mark these methods as = @deprecated. The existing implementations will be still supported. >=20 > Thanks > Max From nobody Fri Mar 20 10:57:10 2015 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 21A551A3BA3 for ; Fri, 20 Mar 2015 10:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Tl2dDElElwGy for ; Fri, 20 Mar 2015 10:57:07 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 125AD1A1A8F for ; Fri, 20 Mar 2015 10:57:06 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-85-550c5f7210e9 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 dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id BC.04.03451.27F5C055; Fri, 20 Mar 2015 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 t2KHv5dd030692; Fri, 20 Mar 2015 13:57:06 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2KHv31A004105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Mar 2015 13:57:05 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2KHv3lg008131; Fri, 20 Mar 2015 13:57:03 -0400 (EDT) Date: Fri, 20 Mar 2015 13:57:03 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20150320004524.GC21267@localhost> Message-ID: References: <20150319025202.GB8099@localhost> <20150319194002.GG4309@mournblade.imrryr.org> <20150319195605.GM8099@localhost> <20150320004524.GC21267@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6nolsUzxNq8P2MiMXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGX8nTmTseCkRMWu3qnsDYyNwl2MnBwSAiYS izY0sELYYhIX7q1n62Lk4hASWMwkcXjSMxYIZyOjxLVfT5ggnENMErufXGIEaRESaGCU6NjJ AmKzCGhLrDn9ASzOJqAiMfPNRjYQW0RAU+L6vKVgNrOAsMT6czOYuxg5OIQF7CS2TXUCCXMK 6Etc3trCDGLzCjhIHG7+zA4x/iCTxPa/IiC2qICOxOr9U1ggagQlTs58wgIxUkti+fRtLBMY BWchSc1CklrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11QvN7NELzWldBMjOFBdlHYw/jyo dIhRgINRiYdXooI7VIg1say4MvcQoyQHk5Io78dwnlAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxK Irxt7kA53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJXq04oEbBotT0 1Iq0zJwShDQTByfIcB6g4YdjQYYXFyTmFmemQ+RPMSpKifNGgzQLgCQySvPgemGJ5BWjONAr wrw7QKp4gEkIrvsV0GAmoMH/arlABpckIqSkGhjN3x4UYd0yj7O388F8/WRfhoOliofNa0+U mbZ+vbfjqJtJuO0804zdW5j805vWe5onLTn4aKOH49EJ9nNv79c6F3RdMUv36t3K2qcnEtnu LDNZ1yw9+dfS30ceh+k8WVL/dK6+4yytCk7XqNU9fIXOe18eOHrlelLtXpHM1qsz9858sfii 87T1SizFGYmGWsxFxYkAlvIbOf8CAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Clarification of gss_add_cred() behavior 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: Fri, 20 Mar 2015 17:57:09 -0000 On Thu, 19 Mar 2015, Nico Williams wrote: > On Thu, Mar 19, 2015 at 08:20:18PM -0400, Benjamin Kaduk wrote: > > On Thu, 19 Mar 2015, Nico Williams wrote: > > > GSS_C_NO_NAME. But then I can never use GSS_Add_cred() to acquire a > > > signle-element credential, and I must always use GSS_Acquire_cred() for > > > that (which is lame for several reasons). > > > > Perhaps I'm just being slow today, but could you say more about what these > > reasons for lameness are? > > Sure: > > - the need to construct an OID set of one OID is lame (this is easy > when one has only one or known-fixed-at-compile-time number of OIDs, > but it's still lame) > > - minor_status is not associated with any mechanism per the specs, > though one hopes that for the one-OID case minor_status is specific > to that one mechanism, but if we're going to be as literal as we can > in reading the spec, then this point is correct and > GSS_Acquire_cred() is lame > > - fewer informative outputs (initiator and acceptor lifetime rec) > > (admittedly this one is not a big deal) > > The second is the real killer. It's one of the reasons given for the > addition of GSS_Add_cred(). And if we interpret the spec as you > propose, we can't have this feature. This is one reason to think that > the spec is self-inconsistent. Thanks. Yeah, that definitely counts as "lame" :) > Other reasons to think the spec is self-inconsistent: > > - No information or pseudo-code or code is given showing how to > iteratively construct credential handles. It probably wasn't thought > through. > > But if the case of input_cred_handle == GSS_C_NO_CREDENTIAL && > desired_name != GSS_C_NO_NAME is interpreted as I propose, then it's > trivial to iteratively construct a credential handle. > > - It makes no sense anyways to ignore a non-default desired_name when > the input_cred_handle is GSS_C_NO_CREDENTIAL, not in light of the > fact that GSS_C_NO_NAME is how one refers to the default credential > in GSS_Acquire_cred() calls. > > - In some places input_cred_handle is described as optional. Well, but > GSS_C_NO_CREDENTIAL -> ignore desired_name means there's no real way > to signal "I'm not providing an input cred handle", therefore it's > either not optional, or the text I say is wrong is wrong. I will need to find a chunk of time to digest all of the relevant pieces of 2743; it may not happen until after Dallas. > The RFC text I quoted as broken does not reflect reality for an > implementation of the C bindings that I could check. I don't think > anyone is proposing to implement the text I quoted. That leaves three > choices: > > - file an erratum > - publish an update > - do nothing (anyone who runs into this will hopefully find this thread) > > I will not be submitting an I-D to update the RFCs just for this. If we > have no consensus for an erratum, and no one else volunteers for the > update, then it's the third choice: do nothing. I really hope it doesn't end up as "do nothing", but time will tell. -Ben From nobody Sun Mar 22 22:26:30 2015 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 152B71A8845; Sun, 22 Mar 2015 22:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tWEOWGRGAixM; Sun, 22 Mar 2015 22:26:26 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64941A8847; Sun, 22 Mar 2015 22:26:25 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-77-550fa3ffed96 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id C4.C1.03355.FF3AF055; Mon, 23 Mar 2015 01:26:23 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2N5QNfA014303; Mon, 23 Mar 2015 01:26:23 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2N5QLC3030333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Mar 2015 01:26:22 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2N5QK9g004187; Mon, 23 Mar 2015 01:26:20 -0400 (EDT) Date: Mon, 23 Mar 2015 01:26:20 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPIsWRmVeSWpSXmKPExsUixCmqrPt/MX+owfweE4ujm1exWJx8+4rN gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ71+tYC9YI1gxf8Np5gbG6XxdjJwcEgImEpNbtrBA 2GISF+6tZ+ti5OIQEljMJLFgewMLhLORUeL71LnsEM4hJonni/9DlTUwSjy784ANpJ9FQFvi 0rK1jCA2m4CKxMw3G8HiIgLCEru3vmPuYuTgYBYQkmh7Hg0SFhawl/jb+gAszCvgKNHxPw4k LCqgI7F6/xSwi3gFBCVOznwCZjMLaEksn76NZQIj/ywkqVlIUgsYmVYxyqbkVunmJmbmFKcm 6xYnJ+blpRbpGuvlZpbopaaUbmIEh5sk3w7GrweVDjEKcDAq8fBWBPCHCrEmlhVX5h5ilORg UhLltVgAFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCyz4PKMebklhZlVqUD5OS5mBREufd9IMv REggPbEkNTs1tSC1CCYrw8GhJMEbD4wrIcGi1PTUirTMnBKENBMHJ8hwHqDhjCA1vMUFibnF mekQ+VOMilLivOIgCQGQREZpHlwvLB28YhQHekWY99YioCoeYCqB634FNJgJaPC5fD6QwSWJ CCmpBsYywRv7o7xbJ1vIpCzbJcjxKkplkk6aePfjFxtVTL9N0y6KvCV4Vub6iq3pQo4BRblz jz7rtUq9cra9w27LztTf/vI3r1h9OiH0ofrBPyORWK3mDj++t8faF2csiwmqdTLW14uWUAya m73j5sE1P65/nyow0+bsizvTLz9OujBnzaYvumZHjtopsRRnJBpqMRcVJwIApR3RDOICAAA= Archived-At: Cc: oauth@ietf.org Subject: [kitten] minor issue with scope and RFC 6749 ABNF in sasl-oauth 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: Mon, 23 Mar 2015 05:26:28 -0000 Hi all, During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I noticed an old comment from Matt back in December 2013, in http://www.ietf.org/mail-archive/web/kitten/current/msg04488.html . The relevant point here is that sending a scope of "" (the empty string) during the authorization request violates the ABNF in RFC 6749. (The other concerns seem to have been addressed by suggesting that a single scope be used, when recommending against a space-separated list.) In the current draft-ietf-kitten-sasl-oauth-19, in section 3.2.2 ("Server Response to Failed Authentication"), we provide a way for the server to tell the client what scope to use, in a custom JSON message defined in the sasl-oauth document. This error response has no obligation to comply to the ABNF of RFC 6749, so saying both that the scope field is optional and that it "may be empty which implies that unscoped tokens are required, or a scope value" does not cause any compliance issues. However, a few paragraphs down, we furthermore say that "[i]f the resource server provides no scope to the client then the client SHOULD presume an empty scope (unscoped token) is required to access the resource." The phrase "empty scope" here is concerning, and seems to suggest sending scope="", which is disallowed by RFC 6749. The simple fix would be to just replace "empty scope (unscoped token)" with "unscoped token". However, it is a bit aesthetically unpleasing to have our new JSON structure diverge from the existing ABNF guidelines; we may wish to just utilize the optionality of the scope field in the server's response to failed authentication, and remove the mention of an empty value for that field. This proposal is a change to the wire protocol, and so we would need consensus from the working group to move forward with it -- in particular, we would like to know if there are existing implementations which would be affected by this change. Please comment about the proposal to remove the option of an empty scope in the server's response to failed authentication, both from the protocol change standpoint and from its effects on existing implementations. Thank you, Ben From nobody Mon Mar 23 13:20:21 2015 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 18B2E1B29D7 for ; Mon, 23 Mar 2015 13:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 9Kz2zsZnIGiM for ; Mon, 23 Mar 2015 13:20:19 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F061B29D5 for ; Mon, 23 Mar 2015 13:20:19 -0700 (PDT) Received: by ignm3 with SMTP id m3so39637221ign.0 for ; Mon, 23 Mar 2015 13:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YzsA+3wgBzhydAQsqce+uypq9B5vKSw7m1FWAmouGT4=; b=bjIXUoAYYnU6cDz3CCUJmjunCDHP2OD7QC/XrW9eHN2tJFAR1SwvD9/baDZxr+v/VI ZfaQY6+13DkyAyhX+bx7yDNot4YTjclLA4+ggt+qvX7BVPwz7EL5UJcKgd2vS+kt2ZF1 DBWqVy5gUTTMdBOvr7VHcsCpBekHBFjao0muRpcIdhLP/nQteNI0+hdfnImMKmzuKqpA IkZ7W7Z/Trv9IKNXyCjmXo78bLdnLfWOYDo1hQCTbIgv6QqZxSxIUoTnbpJ+NNRzaQxv StSMfjA4ZRS6BhWPhqNriqKVszlIeQ5uiB1pbRw30LceySBNjQypst3A2sdXfah0CmyV qbqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YzsA+3wgBzhydAQsqce+uypq9B5vKSw7m1FWAmouGT4=; b=OgbJjdU9U4x/3OaZueEzcWRlynfSzNBf0wyW+d8JswV3V2Ykw7yp9x0mlqmHWPJlAZ wQ+sO+spvxGkuuYsywIkPRqRliQ8WfEbJkTIqPWRj5QOekBBlm8Ki0+kmgN0AU/BN7V6 hf3evWx4kzgqiEGocdM+8MAeqmrw1p7K67Uc5spgNzHUCy+LfkiaXUwRrm1et0QfjnkN rhJacXGXwVb2WDspd3O9Qh23DjGrXoPskUmNwoLFS+ngq2QUMTaenp8XeXJf2WHh1djz v3WVuStyrbCNWj1UCEu8KerczwASHG6J9zgjxQyqTLCj9f6mZ77On03rdVo7xB6bUD8i cCEQ== X-Gm-Message-State: ALoCoQknn408+1KnRdNckKLBhEvLBEUWvcOXVvxkGmmKxd+8OMCfcPI4GgZnEiLpwnqBtCwlc6DY X-Received: by 10.43.142.5 with SMTP id jg5mr10588428icc.33.1427142018873; Mon, 23 Mar 2015 13:20:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.7 with HTTP; Mon, 23 Mar 2015 13:19:48 -0700 (PDT) In-Reply-To: References: From: Jamie Nicolson Date: Mon, 23 Mar 2015 13:19:48 -0700 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a11c2da1a145ec00511fa6526 Archived-At: Cc: "kitten@ietf.org" , "oauth@ietf.org" Subject: Re: [kitten] [OAUTH-WG] minor issue with scope and RFC 6749 ABNF in sasl-oauth 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: Mon, 23 Mar 2015 20:20:21 -0000 --001a11c2da1a145ec00511fa6526 Content-Type: text/plain; charset=UTF-8 Gmail always returns a non-empty scope value in our error response, so the proposed protocol change would not affect our implementation. On Sun, Mar 22, 2015 at 10:26 PM, Benjamin Kaduk wrote: > Hi all, > > During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I noticed > an old comment from Matt back in December 2013, in > http://www.ietf.org/mail-archive/web/kitten/current/msg04488.html . > > The relevant point here is that sending a scope of "" (the empty string) > during the authorization request violates the ABNF in RFC 6749. (The > other concerns seem to have been addressed by suggesting that a single > scope be used, when recommending against a space-separated list.) > > In the current draft-ietf-kitten-sasl-oauth-19, in section 3.2.2 ("Server > Response to Failed Authentication"), we provide a way for the server to > tell the client what scope to use, in a custom JSON message defined in the > sasl-oauth document. This error response has no obligation to comply to > the ABNF of RFC 6749, so saying both that the scope field is optional and > that it "may be empty which implies that unscoped tokens are required, or > a scope value" does not cause any compliance issues. However, a few > paragraphs down, we furthermore say that "[i]f the resource server > provides no scope to the client then the client SHOULD presume an empty > scope (unscoped token) is required to access the resource." The phrase > "empty scope" here is concerning, and seems to suggest sending scope="", > which is disallowed by RFC 6749. > > The simple fix would be to just replace "empty scope (unscoped token)" > with "unscoped token". > > However, it is a bit aesthetically unpleasing to have our new JSON > structure diverge from the existing ABNF guidelines; we may wish to just > utilize the optionality of the scope field in the server's response to > failed authentication, and remove the mention of an empty value for that > field. This proposal is a change to the wire protocol, and so we would > need consensus from the working group to move forward with it -- in > particular, we would like to know if there are existing implementations > which would be affected by this change. > > Please comment about the proposal to remove the option of an empty scope > in the server's response to failed authentication, both from the protocol > change standpoint and from its effects on existing implementations. > > Thank you, > > Ben > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c2da1a145ec00511fa6526 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gmail always returns a non-empty scope value in our error = response, so the proposed protocol change would not affect our implementati= on.

On Sun, = Mar 22, 2015 at 10:26 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:<= br>
Hi all,

During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I noticed an old comment from Matt back in December 2013, in
http://www.ietf.org/mail-archive/web/kitten/current/ms= g04488.html .

The relevant point here is that sending a scope of "" (the empty = string)
during the authorization request violates the ABNF in RFC 6749.=C2=A0 (The<= br> other concerns seem to have been addressed by suggesting that a single
scope be used, when recommending against a space-separated list.)

In the current draft-ietf-kitten-sasl-oauth-19, in section 3.2.2 ("Ser= ver
Response to Failed Authentication"), we provide a way for the server t= o
tell the client what scope to use, in a custom JSON message defined in the<= br> sasl-oauth document.=C2=A0 This error response has no obligation to comply = to
the ABNF of RFC 6749, so saying both that the scope field is optional and that it "may be empty which implies that unscoped tokens are required,= or
a scope value" does not cause any compliance issues.=C2=A0 However, a = few
paragraphs down, we furthermore say that "[i]f the resource server
provides no scope to the client then the client SHOULD presume an empty
scope (unscoped token) is required to access the resource."=C2=A0 The = phrase
"empty scope" here is concerning, and seems to suggest sending sc= ope=3D"",
which is disallowed by RFC 6749.

The simple fix would be to just replace "empty scope (unscoped token)&= quot;
with "unscoped token".

However, it is a bit aesthetically unpleasing to have our new JSON
structure diverge from the existing ABNF guidelines; we may wish to just utilize the optionality of the scope field in the server's response to<= br> failed authentication, and remove the mention of an empty value for that field.=C2=A0 This proposal is a change to the wire protocol, and so we woul= d
need consensus from the working group to move forward with it -- in
particular, we would like to know if there are existing implementations
which would be affected by this change.

Please comment about the proposal to remove the option of an empty scope in the server's response to failed authentication, both from the protoc= ol
change standpoint and from its effects on existing implementations.

Thank you,

Ben

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--001a11c2da1a145ec00511fa6526-- From nobody Mon Mar 23 23:12:52 2015 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 3D0271B2CA0; Mon, 23 Mar 2015 23:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 B52BfY3YOvUX; Mon, 23 Mar 2015 23:12:46 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) (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 6EC611A8836; Mon, 23 Mar 2015 23:12:46 -0700 (PDT) Received: from [80.187.100.210] (helo=[10.132.251.125]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1YaI4x-0008BL-Vt; Tue, 24 Mar 2015 07:12:44 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----517IOCS8HCBJ0L7AJSKYP58PJB267O" Content-Transfer-Encoding: 8bit From: Torsten Lodderstedt Date: Tue, 24 Mar 2015 07:12:41 +0100 To: Benjamin Kaduk ,kitten@ietf.org Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org Subject: Re: [kitten] [OAUTH-WG] minor issue with scope and RFC 6749 ABNF in sasl-oauth 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: Tue, 24 Mar 2015 06:12:50 -0000 ------517IOCS8HCBJ0L7AJSKYP58PJB267O Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Benjamin, in my opinion, your proposal sound reasonable from a protocol perspective. kind regards, Torsten. Am 23. März 2015 06:26:20 MEZ, schrieb Benjamin Kaduk : >Hi all, > >During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I >noticed >an old comment from Matt back in December 2013, in >http://www.ietf.org/mail-archive/web/kitten/current/msg04488.html . > >The relevant point here is that sending a scope of "" (the empty >string) >during the authorization request violates the ABNF in RFC 6749. (The >other concerns seem to have been addressed by suggesting that a single >scope be used, when recommending against a space-separated list.) > >In the current draft-ietf-kitten-sasl-oauth-19, in section 3.2.2 >("Server >Response to Failed Authentication"), we provide a way for the server to >tell the client what scope to use, in a custom JSON message defined in >the >sasl-oauth document. This error response has no obligation to comply >to >the ABNF of RFC 6749, so saying both that the scope field is optional >and >that it "may be empty which implies that unscoped tokens are required, >or >a scope value" does not cause any compliance issues. However, a few >paragraphs down, we furthermore say that "[i]f the resource server >provides no scope to the client then the client SHOULD presume an empty >scope (unscoped token) is required to access the resource." The phrase >"empty scope" here is concerning, and seems to suggest sending >scope="", >which is disallowed by RFC 6749. > >The simple fix would be to just replace "empty scope (unscoped token)" >with "unscoped token". > >However, it is a bit aesthetically unpleasing to have our new JSON >structure diverge from the existing ABNF guidelines; we may wish to >just >utilize the optionality of the scope field in the server's response to >failed authentication, and remove the mention of an empty value for >that >field. This proposal is a change to the wire protocol, and so we would >need consensus from the working group to move forward with it -- in >particular, we would like to know if there are existing implementations >which would be affected by this change. > >Please comment about the proposal to remove the option of an empty >scope >in the server's response to failed authentication, both from the >protocol >change standpoint and from its effects on existing implementations. > >Thank you, > >Ben > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ------517IOCS8HCBJ0L7AJSKYP58PJB267O Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Benjamin,

in my opinion, your proposal sound reasonable from a protocol perspective.

kind regards,
Torsten.

Am 23. März 2015 06:26:20 MEZ, schrieb Benjamin Kaduk <kaduk@MIT.EDU>:
Hi all,

During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I noticed
an old comment from Matt back in December 2013, in
http://www.ietf.org/mail-archive/web/kitten/current/msg04488.html .

The relevant point here is that sending a scope of "" (the empty string)
during the authorization request violates the ABNF in RFC 6749.  (The
other concerns seem to have been addressed by suggesting that a single
scope be used, when recommending against a space-separated list.)

In the current draft-ietf-kitten-sasl-oauth-19, in section 3.2.2 ("Server
Response to Failed Authentication"), we provide a way for the server to
tell the client what scope to use, in a custom JSON message defined in the
sasl-oauth document.  This error response has no obligation to comply to
the ABNF of RFC 6749, so saying both that
the scope field is optional and
that it "may be empty which implies that unscoped tokens are required, or
a scope value" does not cause any compliance issues.  However, a few
paragraphs down, we furthermore say that "[i]f the resource server
provides no scope to the client then the client SHOULD presume an empty
scope (unscoped token) is required to access the resource."  The phrase
"empty scope" here is concerning, and seems to suggest sending scope="",
which is disallowed by RFC 6749.

The simple fix would be to just replace "empty scope (unscoped token)"
with "unscoped token".

However, it is a bit aesthetically unpleasing to have our new JSON
structure diverge from the existing ABNF guidelines; we may wish to just
utilize the optionality of the scope field in the server's response to
failed authentication, and remove the mention of an empty value for that
field.  This proposal is a change to the wire
protocol, and so we would
need consensus from the working group to move forward with it -- in
particular, we would like to know if there are existing implementations
which would be affected by this change.

Please comment about the proposal to remove the option of an empty scope
in the server's response to failed authentication, both from the protocol
change standpoint and from its effects on existing implementations.

Thank you,

Ben


OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ------517IOCS8HCBJ0L7AJSKYP58PJB267O-- From nobody Tue Mar 24 01:36:03 2015 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 160D31B2D48 for ; Tue, 24 Mar 2015 01:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7wntwE0nAwjs for ; Tue, 24 Mar 2015 01:36:01 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 EC9231B2D3C for ; Tue, 24 Mar 2015 01:36:00 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2O8a0wN010440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 24 Mar 2015 04:36:00 -0400 Received: from pspacek.brq.redhat.com (unused [10.34.128.7] (may be forged)) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2O8Zwql003725 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 24 Mar 2015 04:36:00 -0400 Message-ID: <551121EE.1070300@redhat.com> Date: Tue, 24 Mar 2015 09:35:58 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: kitten@ietf.org References: <1425578271.2715.5.camel@redhat.com> In-Reply-To: <1425578271.2715.5.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Tue, 24 Mar 2015 08:36:02 -0000 On 5.3.2015 18:57, Nathaniel McCallum wrote: > I have uploaded a new draft: > http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/ Hello, I'm late to the party so I will only one thing: It seems like a good idea to standardize _kerberos-master URI record too (with semantics equal to the one described on http://web.mit.edu/Kerberos/krb5-1.12/doc/admin/realm_config.html). Have a nice day! -- Petr Spacek @ Red Hat From nobody Tue Mar 24 05:36:46 2015 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 6F4F01A3BA6 for ; Tue, 24 Mar 2015 05:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Y83E0wuy3QuN for ; Tue, 24 Mar 2015 05:36:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41ED81B2E90 for ; Tue, 24 Mar 2015 05:36:29 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id EFD99AD026; Tue, 24 Mar 2015 12:36:28 +0000 (UTC) Received: from vpn-55-6.rdu2.redhat.com (vpn-55-6.rdu2.redhat.com [10.10.55.6]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2OCaRYw000310 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Mar 2015 08:36:28 -0400 Message-ID: <1427200587.29553.0.camel@redhat.com> From: Nathaniel McCallum To: Petr Spacek Date: Tue, 24 Mar 2015 08:36:27 -0400 In-Reply-To: <551121EE.1070300@redhat.com> References: <1425578271.2715.5.camel@redhat.com> <551121EE.1070300@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Tue, 24 Mar 2015 12:36:45 -0000 On Tue, 2015-03-24 at 09:35 +0100, Petr Spacek wrote: > On 5.3.2015 18:57, Nathaniel McCallum wrote: > > I have uploaded a new draft: > > http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/ > > Hello, > > I'm late to the party so I will only one thing: > It seems like a good idea to standardize _kerberos-master URI record > too (with > semantics equal to the one described on > http://web.mit.edu/Kerberos/krb5-1.12/doc/admin/realm_config.html). > > Have a nice day! I *think* this might be MIT specific. Maybe Greg can answer that? Nathaniel From nobody Tue Mar 24 07:20:09 2015 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 341631A875C for ; Tue, 24 Mar 2015 07:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rYQQiceFTysH for ; Tue, 24 Mar 2015 07:20:06 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C28C1A8755 for ; Tue, 24 Mar 2015 07:20:05 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-26-55117294191b 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 dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id E1.1E.03700.49271155; Tue, 24 Mar 2015 10:20:04 -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 t2OEK38J032583; Tue, 24 Mar 2015 10:20:04 -0400 Received: from [18.101.8.223] (vpn-18-101-8-223.mit.edu [18.101.8.223]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2OEK1Zg024944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2015 10:20:02 -0400 Message-ID: <55117291.2040002@mit.edu> Date: Tue, 24 Mar 2015 10:20:01 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Nathaniel McCallum , Petr Spacek References: <1425578271.2715.5.camel@redhat.com> <551121EE.1070300@redhat.com> <1427200587.29553.0.camel@redhat.com> In-Reply-To: <1427200587.29553.0.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixG6nrjulSDDU4OImQ4ujm1exWMz9OovV 4smRfiYHZo8lS34yebzfd5UtgCmKyyYlNSezLLVI3y6BK+Pq6rPsBWv5Krqa9jI2MJ7g7mLk 5JAQMJGYceA+E4QtJnHh3nq2LkYuDiGBxUwS7+f8ZoFwNjJKzDuwBSpzhEli0a2ZzCAtvAJq Ei8nbWUHsVkEVCW2nVgENopNQFli/f6tLCC2qECYxOx1Fxkh6gUlTs58AhYXEYiUWPeglxXE ZhYQlriwfS+YLSxgJbF54xKgeg6gZaUSd4/xg4Q5BYwkvu++DFWuLvFn3iVmCFteonnrbOYJ jIKzkGyYhaRsFpKyBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9HIzS/RSU0o3MYJD2UV5 B+Ofg0qHGAU4GJV4eAOWCIQKsSaWFVfmHmKU5GBSEuWd7iQYKsSXlJ9SmZFYnBFfVJqTWnyI UYKDWUmEV1gFKMebklhZlVqUD5OS5mBREufd9IMvREggPbEkNTs1tSC1CCYrw8GhJMFbVQjU KFiUmp5akZaZU4KQZuLgBBnOAzR8CkgNb3FBYm5xZjpE/hSjopQ4byFIQgAkkVGaB9cLSzWv GMWBXhHmfV0AVMUDTFNw3a+ABjMBDT6XzwcyuCQRISXVwLi+NUL6j2F8jVkcW3S/4xntRzoK H2okDi/kiZ+7yDNOx9ZS7lLo02nf/XpZ2bpFer8f84+9O/n+33sVNv//v4rcszaUb9n3oFy3 7aVM/rYvQu496Oaq4esullJojK5ffcu0z/1H6kvzbxcqOSfxbFRiiEqws3EvrJiwt/vOq0OP dzRVH2X+osRSnJFoqMVcVJwIAJOoQUcQAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS 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: Tue, 24 Mar 2015 14:20:08 -0000 On 03/24/2015 08:36 AM, Nathaniel McCallum wrote: > On Tue, 2015-03-24 at 09:35 +0100, Petr Spacek wrote: >> It seems like a good idea to standardize _kerberos-master URI record >> too (with >> semantics equal to the one described on >> http://web.mit.edu/Kerberos/krb5-1.12/doc/admin/realm_config.html). > I *think* this might be MIT specific. Maybe Greg can answer that? It does look like only MIT krb5 implements it. The semantics of _kerberos-master are "these addresses represent KDCs (usually just one) which are more up to date than the other KDCs in the realm, so retry with one of these if your first try fails for most reasons." In some realms the master KDC isn't one of the regular KDCs, in order to shed the majority of the load from the KDC which is also running kadmind. These semantics are not generally needed for a realm with fast replication (iprop with low polling delay, LDAP, etc.), but there are enough realms with slow replication that we're not about to discard those semantics. It might be good if master KDC entries could be obtained in the same DNS lookup as regular KDC entries, but none of the ways I can think of to do it are particularly elegant. We would need to be able to annotate each URI with "this is also a master KDC" or "this is only a master KDC". Shoving that tri-state into each URI scheme wouldn't be very elegant; designating magic priority values for the URI record would be a layering violation. It's not really a big deal if a second DNS lookup is needed for the fallback. I have no strong opinion on whether the discovery standard needs to talk about this. MIT krb5 can always continue to implement it as a non-standardized feature, using the same lookup behavior as the _kerberos URI record but with the label changed to _kerberos-master. From nobody Tue Mar 24 08:21:31 2015 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 34DBC1A88AE; Tue, 24 Mar 2015 08:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 5S5nuJQiHP68; Tue, 24 Mar 2015 08:21:27 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ACB51A88C7; Tue, 24 Mar 2015 08:21:26 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-06-551180f57274 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 dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 7F.04.03700.5F081155; Tue, 24 Mar 2015 11:21:25 -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 t2OFLO1g026845; Tue, 24 Mar 2015 11:21:24 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2OFLMRT013395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Mar 2015 11:21:23 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2OFLLpI003217; Tue, 24 Mar 2015 11:21:21 -0400 (EDT) Date: Tue, 24 Mar 2015 11:21:21 -0400 (EDT) From: Benjamin Kaduk To: Torsten Lodderstedt In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixCmqrfu1QTDU4MMnHoujm1exWJx8+4rN 4tWxpywOzB5Llvxk8jjW088awBTFZZOSmpNZllqkb5fAlbHpyin2gilMFUePnWRpYLzC2MXI ySEhYCIx8eJdKFtM4sK99WxdjFwcQgKLmSR2/DvPDOFsZJTYvPs2E4RziEli/+wXrBBOA6PE 37c97CD9LALaEutXnmIFsdkEVCRmvtnIBmKLCBhKtE9cyAxiMwsoSzR/OwpWLywQIPHtzwww m1PAWeLs4s8sIDavgKPE7yfzwOJCAhUSy7ZfBIuLCuhIrN4/BapGUOLkzCcsEDO1JJZP38Yy gVFwFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9HIzS/RSU0o3MYLClt1FeQfj n4NKhxgFOBiVeHgDlgiECrEmlhVX5h5ilORgUhLlne4kGCrEl5SfUpmRWJwRX1Sak1p8iFGC g1lJhHdtPVCONyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCdwpIo2BR anpqRVpmTglCmomDE2Q4D9Dwx2DDiwsSc4sz0yHypxh1Oe5M+b+ISYglLz8vVUqctxOkSACk KKM0D24OLN28YhQHekuYdx9IFQ8wVcFNegW0hAloybl8PpAlJYkIKakGRvYC0fe7F8x56vTi 4tYvfL6i19k3vJgjznS1mW2zo+rhe4lHDl1VPq5bdt2tRLOWpeFKy5MWpe45a76ezTTmVBII nrV2mnVyXsdNxmVL/druVW+N7T8TzSbxXll+em/+wj0s76coZz4L+C+w1VTjV/QZ5elp6TFy TjWT02++er7AZvaPshsX5yuxFGckGmoxFxUnAgAEPtrqEgMAAA== Archived-At: Cc: kitten@ietf.org, oauth@ietf.org Subject: Re: [kitten] [OAUTH-WG] minor issue with scope and RFC 6749 ABNF in sasl-oauth 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: Tue, 24 Mar 2015 15:21:29 -0000 Hi Torsten, On Tue, 24 Mar 2015, Torsten Lodderstedt wrote: > Hi Benjamin, > > in my opinion, your proposal sound reasonable from a protocol perspective. I should clarify that Bill came up with the idea; I just sent the mail. Thank you for reviewing it. -Ben From nobody Fri Mar 27 10:26:14 2015 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 381F71B2ABA for ; Fri, 27 Mar 2015 10:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=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 xElmWYZYUsoi for ; Fri, 27 Mar 2015 10:26:08 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22751B2AA5 for ; Fri, 27 Mar 2015 10:25:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9620D20684; Fri, 27 Mar 2015 13:24:10 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6h_zs25glTW; Fri, 27 Mar 2015 13:24:10 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 27 Mar 2015 13:24:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 979A981B6E; Fri, 27 Mar 2015 13:25:56 -0400 (EDT) From: Sam Hartman To: Benjamin Kaduk References: Date: Fri, 27 Mar 2015 13:25:56 -0400 In-Reply-To: (Benjamin Kaduk's message of "Fri, 20 Feb 2015 16:53:09 -0500 (EST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 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: Fri, 27 Mar 2015 17:26:09 -0000 Hi. I realized I never responded to this. I would prefer if you could find someone else to do the 6112 update. I can do it, but I'm fairly busy and would rather not. From nobody Fri Mar 27 10:58:27 2015 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 5759B1A88B1 for ; Fri, 27 Mar 2015 10:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.18 X-Spam-Level: *** X-Spam-Status: No, score=3.18 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 zgnVeu8U6LlI for ; Fri, 27 Mar 2015 10:58:25 -0700 (PDT) Received: from nm31-vm8.bullet.mail.bf1.yahoo.com (nm31-vm8.bullet.mail.bf1.yahoo.com [72.30.239.134]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9181A8823 for ; Fri, 27 Mar 2015 10:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427479104; bh=UlQAlSkogvwauUHDcAa1I1plRmrHYkwynHMk0iThjYU=; h=Date:From:Reply-To:To:Subject:From:Subject; b=dzYMgl8jIGhYck8/5NDcX3qRA3ewP99U7f5vnH37JSpoyreIgpAh+i/36DQHE/8BHdf4vYiel3FDrNdxDOlgj1mk2UyjJbQ3hro26sSq/SRfbzHp9l5lzsvbKlIt4qZCdmapWMLc8WL8EvOkrjf/h20Tsp/Xa/U/8+WoXgVJs95Oinj6bTp3ofnbxT7uTi29t+HDL5ts8cLbF8TZaRS72xf8RpGGkF8DCRZjc3rbYI+3x0SsguimI1ClND9/CwLxmwBR6MMAeqmKB0o0T6d4mFdUw3Tar9VsbWgqdeXcen2ctMGaguN+bJJJhnXn5cGsF/MULVtXtfFii3IzAgAj8Q== Received: from [66.196.81.174] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2015 17:58:24 -0000 Received: from [98.139.212.251] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2015 17:58:24 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 27 Mar 2015 17:58:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 51071.40794.bm@omp1060.mail.bf1.yahoo.com X-YMail-OSG: mbjdPmQVM1n8APZzxBAR6u4PrutpU9fhRT_uQmINX_EnwnnjYjOb1Dypolb9T4L dtC_UhOUQoDgaDFWV5dgJ7i6MXttf913JALs4mYHKmbb2LVhkwRdaaizPd6Oo1f7b7o9xbTRHaWe TKe2GeKJ25d9B1nCluSXvHEXG57xZF.IccSkgl4T3i03bwRhHFwZmIMb8b8tT2Z8NAqthOQnQgaM OCmKGs6rsXcLUStjjRyCn3Jf4whhaJTi.lrO5Us_3AD8Bz56ZlvjqTrqEQgVz_6hmOUIAAAg_AoM dcAbbXqFPHCIkh_q5qgnWnlN85_tbNTGQ_aJq_WZFtU2JypuTDe8KS6wMH3ilG.u9TW5jkjfKwFg TpdnQL7UDvAYhLgaSZDCYKX2XCSiH1e3jOmdJHaXxX5ctDjt_C_VSpw5VVY5yhfsq37pm1WDWgzp OAa4E76Zpp_Xa1uf1BR7.JVh_D8.eF2ON0LWBF2d_tz5dIF1cWrr6N5Dez49IQOfBDTDg5H9Ls7P zYLUvU1jIOtNKMYtRZBvnKFV8hRT3SDwyYSonbF14RlvbVHzCO3v7aWJ6kCc1SJj_._I4tvMfNEW ee6O1C9gGQjJJHBTRVWq5zhEGYHml03SVzwVvjI5JcONIMgBK_vlKlRJv6d8UKYEdIftZUkjM4q. ikVg7KG5Gu362L3x2OZ8wpeKuf15Qt3hRwQuN1vTNMhk._R1BBfMEWT3OFOZfbS3CQApolAaL5mZ 4YklzKnJqJ6AGzcH_zunoQtQZGCCneTcq0Tgo Received: by 76.13.26.138; Fri, 27 Mar 2015 17:58:23 +0000 Date: Fri, 27 Mar 2015 17:58:23 +0000 (UTC) From: Bill Mills To: Kitten WG Message-ID: <1028408660.3680954.1427479103275.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3680953_1680160356.1427479103273" Archived-At: Subject: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:58:26 -0000 ------=_Part_3680953_1680160356.1427479103273 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sending as promised to the WG meeting. My working copy of this is viewable at=C2=A0http://htmlpreview.github.io/?h= ttps://github.com/sweetums/idrafts/blob/master/draft-ietf-krb-wg-pkinit-alg= -agility-08.html=C2=A0and the HTML and XML files are at=C2=A0https://github= .com/sweetums/idrafts/ -bill=C2=A0 ------=_Part_3680953_1680160356.1427479103273 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sen= ding as promised to the WG meeting.


-bill
 
------=_Part_3680953_1680160356.1427479103273-- From nobody Fri Mar 27 11:04:03 2015 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 3909B1A8968 for ; Fri, 27 Mar 2015 11:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 4pfWWBjf-7Ir for ; Fri, 27 Mar 2015 11:04:01 -0700 (PDT) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361CE1B2B0B for ; Fri, 27 Mar 2015 11:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427479392; bh=5NaPwD/du8d1mBAKUXn4Z/B6Uj7aHpTNVyv1YQXiJMk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=SXw5nOOaCQ795T4aluuaIX3vWbRYrVWaWAmLPiFElaqk6M6Uhhfy+NrUckhrpoT/Z1XmSdhES0ea6DKr1oBjGtumeNTDAj5ruMIqNQyQhO3XHG1zitVkm7E7CxNZ7UhooRYYIx9ewaAapr0g+YH/gwT0GylBEzNf2Tvi+ybKGQ2pDNwL+7GcSGFIe10ZO6Hrlne2Vo+GUTyq+6XmFhuAsIV3gOMmjGPDDucNoD1rUZPs+F/MhdTJ69ZMDCgA6XrmbDRCRNP81i/J40h9NvAojHVtkPdS0C1POgUahB6uaJ7Ds6t9GtB0J6fi/+0QUd0s1DGHCa70jrbzfSNg4EDpuQ== Received: from [98.139.170.180] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2015 18:03:12 -0000 Received: from [98.139.212.196] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2015 18:03:12 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 27 Mar 2015 18:03:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 340723.35745.bm@omp1005.mail.bf1.yahoo.com X-YMail-OSG: 6axUohYVM1mb99DQW.sIHWEtw00JbMfBtd5n9ouqxUeQRVIRfDE7I54NytzYvQz 3kZ6jnMhRQgQUdT4wEvsGYBmvmeEhzJT7X_NeMJOrGju.r2qJnU3cyBDlPhpATAQRSOkWsikjkCl A4eroZYmqWWCpwbP3OawoVu2GJA2hGVFO9Ve3fPgZF5CDdDPDjGNKt9d4ngl0O8.GkFvPjuVWRfe 5WwNGkBGZFoJkYLMP9_Q6T953waQotn.a4qxaMm8iHfKBchxA0DHquPEerNLnMnKbEhSUgFTegEY Xm_PZ8jZhRtvfK.FTdw1L2_R_6jZy49AZcvpzbxAial87mg6ZIbAHyOZhK1bOLClcaENhFTNRryp Dwd8G0AMX.E2VmaxWrvApD_Pdu769eLzHIzEuz2vV34rgZtfATZedMTTLRS2vCoeM1opRLyjANp5 hisa_wsgY3LBzXJnXFqdFrjC.LmCyfE89RtyFAntCMBkCamB7r55UhOiJZDbcvSCwXkuy.xefat6 f8AD2Zg-- Received: by 66.196.80.112; Fri, 27 Mar 2015 18:03:11 +0000 Date: Fri, 27 Mar 2015 18:03:11 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk , Tom Yu Message-ID: <962591069.3713128.1427479391512.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3713127_1938382570.1427479391508" Archived-At: Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 18:04:02 -0000 ------=_Part_3713127_1938382570.1427479391508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ping on this to resolve.=20 On Wednesday, November 19, 2014 7:07 PM, Benjamin Kaduk wrote: =20 On Wed, 19 Nov 2014, Nico Williams wrote: > I don't think we should require that KDF OIDs only come from that arc. > Rather, we would be creating a registry with that arc from which > protocol action assignments should be taken. Agreed, we shouldn't require that KDF OIDs only come from that arc. I'm not sure I'm parsing the second sentence correctly. Tom, do you have any interest in fleshing out Nico's example into something suitable for Bill to include in the document's appendix? Thanks, Ben > (One nice result from using OIDs is that private use assignments are > feasible with no communication with any external entity.=C2=A0 There's no > reason to preclude this.=C2=A0 Nor is there a way in x.680 to constrain t= he > OBJECT IDENTIFIER type to specific arcs, IIRC -- this wouldn't stop > us, of course.) _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_3713127_1938382570.1427479391508 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ping on this to resolve.
=


=
On Wednesday, November 19, 2014 7:07 PM, Benjamin Ka= duk <kaduk@MIT.EDU> wrote:


On Wed, 19 Nov 2014, Nico Williams wrote:

> I don't think we should require that KDF OIDs on= ly come from that arc.
> Rather, we would be creating = a registry with that arc from which
> protocol action = assignments should be taken.

Agreed, w= e shouldn't require that KDF OIDs only come from that arc.
I'm not sure I'm parsing the second sentence correctly.

Tom, do you have any interest in fleshing out Nico's ex= ample into
something suitable for Bill to include in the = document's appendix?

Thanks,


= Ben

> (One nice result from using O= IDs is that private use assignments are
> feasible wit= h no communication with any external entity.  There's no
> reason to preclude this.  Nor is there a way in x.680 to con= strain the
> OBJECT IDENTIFIER type to specific arcs, = IIRC -- this wouldn't stop
> us, of course.)

______________________________________________= _
Kitten mailing list
Kitten@= ietf.org
https://www.ietf.org/mailman/= listinfo/kitten


=
------=_Part_3713127_1938382570.1427479391508-- From nobody Fri Mar 27 11:36:13 2015 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 91D581A9024 for ; Fri, 27 Mar 2015 11:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 MCT7TZ-KfOCy for ; Fri, 27 Mar 2015 11:36:09 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7297F1A9022 for ; Fri, 27 Mar 2015 11:36:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8A21DBEC9 for ; Fri, 27 Mar 2015 18:36:06 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCjUVGPU4g76 for ; Fri, 27 Mar 2015 18:36:05 +0000 (GMT) Received: from [31.133.139.135] (unknown [31.133.139.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5E269BE50 for ; Fri, 27 Mar 2015 18:36:05 +0000 (GMT) Message-ID: <5515A313.4010707@cs.tcd.ie> Date: Fri, 27 Mar 2015 18:36:03 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "kitten@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [kitten] thanks to Shawn 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: Fri, 27 Mar 2015 18:36:11 -0000 At the end of the meeting today, we had Shawn fire himself as WG chair (he hit the datatracker button himself:-). So many thanks Shawn for 8 years good work, and thanks also to Ben and Matt for running with this in future. Cheers, S. From nobody Fri Mar 27 11:47:33 2015 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 44C491A8831 for ; Fri, 27 Mar 2015 11:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 js5ionbwraba for ; Fri, 27 Mar 2015 11:47:30 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6919B1A1B63 for ; Fri, 27 Mar 2015 11:47:30 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-4c-5515a5c0b943 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 dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id A2.BF.03700.1C5A5155; Fri, 27 Mar 2015 14:47:29 -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 t2RIlNr3008927; Fri, 27 Mar 2015 14:47:23 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2RIlL00005228; Fri, 27 Mar 2015 14:47:22 -0400 From: Tom Yu To: Bill Mills References: <962591069.3713128.1427479391512.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 27 Mar 2015 14:47:20 -0400 In-Reply-To: <962591069.3713128.1427479391512.JavaMail.yahoo@mail.yahoo.com> (Bill Mills's message of "Fri, 27 Mar 2015 18:03:11 +0000") Message-ID: Lines: 39 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nrntwqWiowfrnXBZHN69isfjWdZ3Z gcljyZKfTB6zZh1mCmCK4rJJSc3JLEst0rdL4Mo48HInW8FKropff2awNzDO5+hi5OSQEDCR WHtiKhOELSZx4d56NhBbSGAxk8TXqZFdjFxA9kZGiY5DfSwQzhtGid4Tf5hBqtgEpCWOX94F 1M3BISKgLtH83RskzCxgL3H6awNYibBAvMSBjZ/YIHqbGSU+77/KCJJgEVCVOHu9hxkkwSnQ xSix7d5PsDN4BXQltn3+CNbNI8Ap0Tmxix0iLihxcuYTFogN6hJ/5l1ihrC1JZYtfM08gVFw FpKyWUjKZiEpW8DIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXTC83s0QvNaV0EyM4hF2UdzD+ Oah0iFGAg1GJh/fHbpFQIdbEsuLK3EOMkhxMSqK89YtFQ4X4kvJTKjMSizPii0pzUosPMUpw MCuJ8G6YCpTjTUmsrEotyodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLgXbAEqFGw KDU9tSItM6cEIc3EwQkynAdo+GmQGt7igsTc4sx0iPwpRkUpcd7pIAkBkERGaR5cLyzFvGIU B3pFmPcbSBUPMD3Bdb8CGswENNiwQwRkcEkiQkqqgZFz1ZqFt4rWJwRW7QqT65jrzMu5If2k atZjeZHKmQeestud2cT71rVL9CzL845HIvLfKt8+qy5wEPzwKsBeZOGB9auVn/NH5Bw0fO7v kV28wXlLoLSGypPwGTwSb8y+XwqZGd/EsueSw50GtSruxuotri4Papr/1H1dsoav4nME39VN PhoqD5RYijMSDbWYi4oTAaRpb3EMAwAA Archived-At: Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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: Fri, 27 Mar 2015 18:47:32 -0000 Bill Mills writes: > Ping on this to resolve.=20 I'm not sure I remember the context for this, so it might take a while for me to reconstruct it. > On Wednesday, November 19, 2014 7:07 PM, Benjamin Kaduk wrote: >=20=20=20=20 > > On Wed, 19 Nov 2014, Nico Williams wrote: > >> I don't think we should require that KDF OIDs only come from that arc. >> Rather, we would be creating a registry with that arc from which >> protocol action assignments should be taken. > > Agreed, we shouldn't require that KDF OIDs only come from that arc. > I'm not sure I'm parsing the second sentence correctly. > > Tom, do you have any interest in fleshing out Nico's example into > something suitable for Bill to include in the document's appendix? > > Thanks, > > Ben > >> (One nice result from using OIDs is that private use assignments are >> feasible with no communication with any external entity.=C2=A0 There's no >> reason to preclude this.=C2=A0 Nor is there a way in x.680 to constrain = the >> OBJECT IDENTIFIER type to specific arcs, IIRC -- this wouldn't stop >> us, of course.) > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > >=20=20=20 From nobody Fri Mar 27 15:30:22 2015 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 F34D71A8AF8 for ; Fri, 27 Mar 2015 11:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Lr2QWRtzDG6l for ; Fri, 27 Mar 2015 11:49:00 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903681A8908 for ; Fri, 27 Mar 2015 11:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=597; q=dns/txt; s=iport; t=1427482140; x=1428691740; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Egk9olk/vOOuVsAZmvVHvuUGs+4w1h2Q8C8pUKZ4LD4=; b=WqmRqwxbVDywbapo5eQWvHXFHQpoPl19geUrKt08RRD+8LhLzYmc5+61 0Mq9gpkcSKMlms1vx+PKWZR8xlpK3FstArRKnM7j73SaIbejh2rTmmn7f d7OsvBMWizjMW2YKCcKxqn0HaVts6TTzyCMYLMJazRpnAkOLsCSjDiUJi o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BGCQB7pRVV/5ldJa1TCYMGUloEwwmCMQqFLEkCgTlMAQEBAQEBfYQUAQEBAwEBAQE3NAsFCwIBCBgeECcLJQIEDgWIJwgNzFcBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsohB0oMweDF4EWBY5Jgg6JcJQxIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,480,1422921600"; d="scan'208";a="407591905" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 27 Mar 2015 18:49:00 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2RImx2D002081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 18:48:59 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.32]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 13:48:59 -0500 From: "Klaas Wierenga (kwiereng)" To: "kitten@ietf.org" Thread-Topic: [kitten] thanks to Shawn Thread-Index: AQHQaLz0KSiz8Qs+S0enDrKCxvD7qp0w/7UA Date: Fri, 27 Mar 2015 18:48:59 +0000 Message-ID: References: <5515A313.4010707@cs.tcd.ie> In-Reply-To: <5515A313.4010707@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.95.209] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D435131FB73614399EA1DF963D307BC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 27 Mar 2015 15:30:22 -0700 Subject: Re: [kitten] thanks to Shawn 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: Fri, 27 Mar 2015 18:49:02 -0000 thanks Shawn! -- Klaas Wierenga Identity Architect Cisco Cloud Services > On 27 Mar 2015, at 13:36, Stephen Farrell wro= te: >=20 >=20 > At the end of the meeting today, we had Shawn fire himself as > WG chair (he hit the datatracker button himself:-). >=20 > So many thanks Shawn for 8 years good work, and thanks also to > Ben and Matt for running with this in future. >=20 > Cheers, > S. >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Fri Mar 27 16:14:37 2015 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 8C3811A0104 for ; Fri, 27 Mar 2015 16:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 OFNF2QYz8gi9 for ; Fri, 27 Mar 2015 16:14:34 -0700 (PDT) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4DB1A00E1 for ; Fri, 27 Mar 2015 16:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427498073; bh=6NQLGfb11/UNV545Pex01p1bcINZRM/7YlH/dBpdqXM=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=kOpCKKy612qyiCmwCYBa8zs4Z4vpm0MzsVom4+mMkYSCA5KSqHfJsNh7eme3SNFDBWtn+skE9kZa7uijMwD0DoG8Y/EnWE5BRhkT/4K01SAEjXYH2HNhkgiiE1CbPSsYyzesNm8ERnorV4WpJYYwctmI2fjUGuM9MDsQwnlxdUdDzyvCSF6Fn+3lGSYEyS991TQ8nE9g8J1H/3ruY8vP6dcna51oNtg2EybPy7J9og7oIUSBzCaSDXYGe82ChZFeRCJXELC2zOnBXZbmrRyk+uJ4kT5u1Av9jv9UwVrcx/ecRg44OfQhI9CWMC6N5NBruH2tmWFuXtf3zu3X3KSzwg== Received: from [66.196.81.171] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2015 23:14:33 -0000 Received: from [98.139.212.203] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2015 23:14:33 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 27 Mar 2015 23:14:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 459069.5153.bm@omp1012.mail.bf1.yahoo.com X-YMail-OSG: nM4dkXQVM1k2_T6CvPl3aF5P5TRi4aaWrONe9lC54BUFfMtC4S82_bUF0yq03xx lZ5PEzBCv0tZAtcF.XGTwg5yoHMv78AW6HOepCqOciF4zKmuyzQcH_sm2eDNqbuBQD5heTvy6mbd 9cglzKAkG0YtCuZ.28UqURiwOve5.ZjF6XgPUnVPfheRz3HIEnOku29OlJMY8X0ErdUzpmpm_RS_ rJEdd7kdgGOc4ytyLbLKlQN_Q8K1w0KRQoG9DhFYlUtD6EpsEJkDrHQ.QLCEkXbMXrzKdHNBpli2 890SqQoVo8K3CVQSF9VzaqNvopXOkHd.4j.7uEe3SCc8cva4HruNFE7UQ0KLSAFEyEHiIJuSj41L VsZnmD_OY5F73YvOOBfn7ejXE6c5TPKPbc9tpqol9n_JhB..Y2AvKBVJxOAKyD6lDNNsI46EawSq _JGggNFrQuxjBtepmNsVuQ.r2M3jZKWbD59P34o9FindN__CeKYi47pEhw8Ym8W88pX3jscDUOU. gnXxNJs8h0MhA Received: by 76.13.27.35; Fri, 27 Mar 2015 23:14:33 +0000 Date: Fri, 27 Mar 2015 23:14:32 +0000 (UTC) From: Bill Mills To: "Klaas Wierenga (kwiereng)" , "kitten@ietf.org" Message-ID: <499509492.39912.1427498072469.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_39911_1655842627.1427498072464" Archived-At: Subject: Re: [kitten] thanks to Shawn X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 23:14:35 -0000 ------=_Part_39911_1655842627.1427498072464 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Indeed. =C2=A0Take a well deserved break, and thanks for showing an IETF ne= wbie the ropes.=20 On Friday, March 27, 2015 3:30 PM, Klaas Wierenga (kwiereng) wrote: =20 thanks Shawn! -- Klaas Wierenga Identity Architect Cisco Cloud Services > On 27 Mar 2015, at 13:36, Stephen Farrell wro= te: >=20 >=20 > At the end of the meeting today, we had Shawn fire himself as > WG chair (he hit the datatracker button himself:-). >=20 > So many thanks Shawn for 8 years good work, and thanks also to > Ben and Matt for running with this in future. >=20 > Cheers, > S. >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_39911_1655842627.1427498072464 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Indeed.  Take a well deser= ved break, and thanks for showing an IETF newbie the ropes.
<= br>


On Friday, March 27, 2015 3:30 PM, Klaas Wierenga (k= wiereng) <kwiereng@cisco.com> wrote:


thanks Shawn!

--
Klaas Wierenga
Identity Architec= t
Cisco Cloud Services






> On 27 Mar 2015, at 13:36, Stephen Farrell <<= a shape=3D"rect" ymailto=3D"mailto:stephen.farrell@cs.tcd.ie" href=3D"mailt= o:stephen.farrell@cs.tcd.ie">stephen.farrell@cs.tcd.ie> wrote:
>
>
> At the en= d of the meeting today, we had Shawn fire himself as
>= WG chair (he hit the datatracker button himself:-).
>=
> So many thanks Shawn for 8 years good work, and th= anks also to
> Ben and Matt for running with this in f= uture.
>
> Cheers,
> S.
>
> _______________= ________________________________
> Kitten mailing list=
> Kitten@ietf.org
>= ; https://www.ietf.org/mailman/listinfo/kitten


= _______________________________________________
Kitten ma= iling list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten


------=_Part_39911_1655842627.1427498072464-- From nobody Sat Mar 28 11:41:17 2015 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 CA0C31A8AD6 for ; Sat, 28 Mar 2015 11:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 zonWKZvxehzE for ; Sat, 28 Mar 2015 11:41:14 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1555C1A8737 for ; Sat, 28 Mar 2015 11:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1427568052; x=1428172852; q=dns/txt; h=VBR-Info:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: OpenPGP:Content-Type; bh=JmMwg+oy2V+N2u7YfG1+EqATzcun1VfuI4mjmGz xLMU=; b=py38NjKm7etxttrmJKuZOPw6TzOwx6BSNAIKNbes/+mgZEZ44Y2hjnc KHIoK0NC8+RX7IDQ0q4dWGZXGQlRPe2SeMrrPgbdXeyCO55/+95aUWgNhOWJYSJk uWDFSv/yB1RxKIqhJDdPVvNMyLXbV0ZeD0z72uoF0vILg56f3094= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Sat, 28 Mar 2015 14:40:52 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Sat, 28 Mar 2015 14:40:51 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v15.0.0) with ESMTPSA id md50000847162.msg for ; Sat, 28 Mar 2015 14:40:50 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Sat, 28 Mar 2015 14:40:50 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1529e9c664=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <5516F5AC.2040904@secure-endpoints.com> Date: Sat, 28 Mar 2015 14:40:44 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Simo Sorce , Nico Williams References: <20150311001817.GC7286@localhost> <1426771934.2981.127.camel@willson.usersys.redhat.com> <20150319151718.GD8099@localhost> <1426778409.2981.129.camel@willson.usersys.redhat.com> <20150319162847.GG8099@localhost> <1426784686.2981.130.camel@willson.usersys.redhat.com> <20150319173305.GH8099@localhost> <1426787041.2981.135.camel@willson.usersys.redhat.com> In-Reply-To: <1426787041.2981.135.camel@willson.usersys.redhat.com> OpenPGP: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030400010707020406070100" Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred() 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: Sat, 28 Mar 2015 18:41:15 -0000 This is a cryptographically signed message in MIME format. --------------ms030400010707020406070100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/19/2015 1:44 PM, Simo Sorce wrote: > On Thu, 2015-03-19 at 12:33 -0500, Nico Williams wrote: >> On Thu, Mar 19, 2015 at 01:04:46PM -0400, Simo Sorce wrote: >>> Would you consider an explicitly set KRB5CCNAME env variable as an >>> indication the admin is ok with acquired credentials ending up there = ? >>> Ie a) but using KRB5CCNAME presence as an indication a ccache can be >>> used ? >> >> That helps, though there can still be non-determinism when the ccache >> does not exist yet. (But if the admin/user set it, why wouldn't they >> also kinit -k to remove all doubt?) >=20 > Because, at least with the current implementation of the Keytab > initiation feature in MIT, if you kinit explicitly then > gss_init_sec_context will not take over and keep initiating when > credentials expires etc... >=20 > I understand this may be simply an implementation issue/bug and it can > be decided differently, but in general keytab initiation is used to > allow unattended systems work on their own, so the admin will start a > service with all the evn var set right and let it to it's own thing, > requiring to script a manual kinit would defeat the purpose. >=20 > So I am trying to see if you think a) is compatible with something > priming an empty initial ccache provided that both KRB5CCNAME and > KRB5_CLIENT_KTNAME have been set in the environment (both required). >=20 > Simo. Simo, I would be more comfortable with an environment variable or krb5.conf option that explicitly states to perform X behavior. The existence of environment variables that are useful on their own in combination should not should trigger an unexpected behavior. Especially when those environment variables are interpreted different by different Kerberos distributions. Just my two cents ... Jeffrey Altman --------------ms030400010707020406070100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhBA DYgfV2Wuja6XFlzP7gwyMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMTAxMDIwMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGcbqJKktdkAl+5/3n tX55BjmX/xriz7C8WyWnI3IeaKHdj4Ya/VhSGfxBi58Uo4V7wV+VXAObK+EkLgO/t2OdtUOw z04SX8ZRpyZxvw5YlL50ieRRtk7SKxGfLVbxJV1pfGnRB6aM1zOxuETvdsiYclTcoRJXKoMH lUmrC+f4jF2bxu6DQPVod5Ho2kJc5ViO1mbnTz7L2fuRWmH9afQra8Q6UaJWnJHr1ZSqkWpj a0a2Gx47C85CYffAoTX1+ujuYwg0LA8C3RL0FnGvalH4dalsfTgpskhEGXKRpMMAli8Oq7bO Ob1oxziM9+yR5+v30vZ37adC2vx8L1m4F7WXAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFM2J7jAkKtP8wun+3s5rv727EDkeMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBALZrEhzBTZdbzJznEexkWvYmIu1A2s8B 95qMfk08aTvg+3D6F6wUGeZVJ/7x8vrTxIQ9vvYvfbXjDBdpWLnVoUaeEM2i//16x21NHqfA Fw5qtSxy4YQATuQIqevk96K2vIIjjL/vrIwZevwPBPpk/XhAI4Mfuzo89buT+pJB9pEVE8IC NUPVduydcZAJ0R0m8qQVIsKEYqAkULD1U6P8OKl8alblGFkFuqXISPbeMlg4OA8M5BV5IxHI GfUnXhOHH/AL1xE9GVt4DmGd8y96y+ljJHV/mD93NvJaH04W6ounDb8RBVt8DRvq0MLHtWap UHlG3zH8i/IJ8p9jQ5XdyRExggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEANiB9XZa6NrpcWXM/u DDIwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwMzI4MTg0MDQ0WjAjBgkqhkiG9w0BCQQxFgQUlwYk3/Hwo+/3j0XX7DMw86OM FFkwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQA2IH1dlro2ulxZcz+4MMjCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBADYgfV2Wuja6XFlzP7gwyMA0GCSqGSIb3DQEB AQUABIIBAL0/t4PoTCo0X/FI0gAlWWWU0v/09IlLT3KTktUjabKCR395fPoIvohQi9169EaQ bFmOqr5wCq5NmrsX11yiPKZX84lx0usjTdMFZvIQrYMP/kDoSkTTRJkreq2WgLSYRp+9YTN1 Hp8NMxDVfKxqzUZV0qCW4KsTqpMhNQtI56IwrcwymteWTtel+6Jyw6BHhAwcaIL1H99HZInI 0dV9gD7JciKz/pq+u/5caSOgwpPP1/rLk6U2ulnuvNq7JXc8RmF2zMZBjVv8lmdyuMAwcUm3 xbGXKLAAE4KUO/ssk5/Y+39cgkf0531AjlJJf7IF9UR5bYzkSIFhN5V1Jl32tTIAAAAAAAA= --------------ms030400010707020406070100-- From nobody Sat Mar 28 13:44:00 2015 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 46E011A875B for ; Sat, 28 Mar 2015 13:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FlBPi7yLOerP for ; Sat, 28 Mar 2015 13:43:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 B9EBA1A8025 for ; Sat, 28 Mar 2015 13:43:57 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2SKhu3c032327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 28 Mar 2015 16:43:56 -0400 Received: from [10.3.113.20] (ovpn-113-20.phx2.redhat.com [10.3.113.20]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2SKhtds003717; Sat, 28 Mar 2015 16:43:55 -0400 Message-ID: <1427575435.8302.132.camel@willson.usersys.redhat.com> From: Simo Sorce To: Jeffrey Altman Date: Sat, 28 Mar 2015 16:43:55 -0400 In-Reply-To: <5516F5AC.2040904@secure-endpoints.com> References: <20150311001817.GC7286@localhost> <1426771934.2981.127.camel@willson.usersys.redhat.com> <20150319151718.GD8099@localhost> <1426778409.2981.129.camel@willson.usersys.redhat.com> <20150319162847.GG8099@localhost> <1426784686.2981.130.camel@willson.usersys.redhat.com> <20150319173305.GH8099@localhost> <1426787041.2981.135.camel@willson.usersys.redhat.com> <5516F5AC.2040904@secure-endpoints.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred() 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: Sat, 28 Mar 2015 20:43:59 -0000 On Sat, 2015-03-28 at 14:40 -0400, Jeffrey Altman wrote: > On 3/19/2015 1:44 PM, Simo Sorce wrote: > > On Thu, 2015-03-19 at 12:33 -0500, Nico Williams wrote: > >> On Thu, Mar 19, 2015 at 01:04:46PM -0400, Simo Sorce wrote: > >>> Would you consider an explicitly set KRB5CCNAME env variable as an > >>> indication the admin is ok with acquired credentials ending up there ? > >>> Ie a) but using KRB5CCNAME presence as an indication a ccache can be > >>> used ? > >> > >> That helps, though there can still be non-determinism when the ccache > >> does not exist yet. (But if the admin/user set it, why wouldn't they > >> also kinit -k to remove all doubt?) > > > > Because, at least with the current implementation of the Keytab > > initiation feature in MIT, if you kinit explicitly then > > gss_init_sec_context will not take over and keep initiating when > > credentials expires etc... > > > > I understand this may be simply an implementation issue/bug and it can > > be decided differently, but in general keytab initiation is used to > > allow unattended systems work on their own, so the admin will start a > > service with all the evn var set right and let it to it's own thing, > > requiring to script a manual kinit would defeat the purpose. > > > > So I am trying to see if you think a) is compatible with something > > priming an empty initial ccache provided that both KRB5CCNAME and > > KRB5_CLIENT_KTNAME have been set in the environment (both required). > > > > Simo. > > Simo, > > I would be more comfortable with an environment variable or krb5.conf > option that explicitly states to perform X behavior. The existence of > environment variables that are useful on their own in combination should > not should trigger an unexpected behavior. Especially when those > environment variables are interpreted different by different Kerberos > distributions. > > Just my two cents ... I think KRB5_CLIENT_KTNAME fits the description, its only use is to indicate which credentials to use for keytab initiation. I think it fair to assume that if an admin has explicitly set it that he wants to allow keytab initiation. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Sun Mar 29 19:55:10 2015 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 8797D1A8AD3 for ; Sun, 29 Mar 2015 19:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 DJROyDmLFwu0 for ; Sun, 29 Mar 2015 19:55:08 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8124A1A8AD2 for ; Sun, 29 Mar 2015 19:55:08 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2U2t7Cr021348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Mar 2015 02:55:07 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t2U2t72A019882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 30 Mar 2015 02:55:07 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t2U2t6t4021734 for ; Mon, 30 Mar 2015 02:55:06 GMT Received: from [10.159.67.56] (/10.159.67.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 29 Mar 2015 19:55:06 -0700 Message-ID: <5518BB57.5090409@oracle.com> Date: Sun, 29 Mar 2015 20:56:23 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20150125 Thunderbird/17.0.11 MIME-Version: 1.0 To: kitten@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 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: Mon, 30 Mar 2015 02:55:09 -0000 On 03/27/15 11:25 AM, Sam Hartman wrote: > Hi. > I realized I never responded to this. > > > I would prefer if you could find someone else to do the 6112 update. > I can do it, but I'm fairly busy and would rather not. I had volunteered to do this. Thanks for getting things started... Shawn. -- From nobody Mon Mar 30 08:37:59 2015 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 83F8E1A0041 for ; Mon, 30 Mar 2015 08:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.656 X-Spam-Level: * X-Spam-Status: No, score=1.656 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 J-IlJXytIY3k for ; Mon, 30 Mar 2015 08:37:56 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CC02C1A0084 for ; Mon, 30 Mar 2015 08:37:52 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 879BE1DE094 for ; Mon, 30 Mar 2015 08:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=bltUULrB5gp9uQv5K1sC jT+eeaM=; b=nJCmRUMk6WdDXsuCuDdjmWQI73FHj6YvgQ5zoamm2wI4d0je2k0C +TObGoTdO9oDc13c4Ji1ZwoAd7PLOGpmJOdobr7/2mnF0Y7MSWLR1aNhtGXOYgVX BeQOj0I8VNlCvqqfYTIQ4HnXWAzwCh7wjgTLVrSqIZhSzFgCf0TSsV4= Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 41F4E1DE087 for ; Mon, 30 Mar 2015 08:37:52 -0700 (PDT) Received: by ierf6 with SMTP id f6so53737010ier.2 for ; Mon, 30 Mar 2015 08:37:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.35.195 with SMTP id k3mr18579402igj.11.1427729870465; Mon, 30 Mar 2015 08:37:50 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Mon, 30 Mar 2015 08:37:50 -0700 (PDT) In-Reply-To: <5515A313.4010707@cs.tcd.ie> References: <5515A313.4010707@cs.tcd.ie> Date: Mon, 30 Mar 2015 10:37:50 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] thanks to Shawn 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: Mon, 30 Mar 2015 15:37:56 -0000 Thanks Shawn! From nobody Mon Mar 30 09:40:51 2015 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 4AA9B1A6F13 for ; Mon, 30 Mar 2015 09:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EwlrJ0E8Af31 for ; Mon, 30 Mar 2015 09:40:48 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC23E1A6F30 for ; Mon, 30 Mar 2015 09:40:44 -0700 (PDT) X-AuditID: 12074425-f79ca6d000000e5e-e8-55197c8be402 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 dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 8D.18.03678.B8C79155; Mon, 30 Mar 2015 12:40: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 t2UGegfT019611 for ; Mon, 30 Mar 2015 12:40:43 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2UGefQ8004363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 30 Mar 2015 12:40:42 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2UGefoM026213; Mon, 30 Mar 2015 12:40:41 -0400 (EDT) Date: Mon, 30 Mar 2015 12:40:40 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixG6nrttdIxlqcP2eusXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcWH1VJaCZ+wVC9ob2BoYd7F1MXJySAiYSMy6/J4dwhaTuHBv PVCci0NIYDGTxJWDF5kgnOOMEq0Xj0M5N5gkXh/pZYdwGhglvk+8xgzSzyKgLfHtxmmwuWwC KhIz32wEs0UEhCV2b30HViMsYC7R0HqDEcTmFXCUeDnzHCuILSqgI7F6/xQWiLigxMmZT8Bs ZgEtieXTt7FMYOSbhSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0LvdzMEr3UlNJN jOCAclHdwTjhkNIhRgEORiUeXod6iVAh1sSy4srcQ4ySHExKoryMlZKhQnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4o0uAcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxK Erzt1UCNgkWp6akVaZk5JQhpJg5OkOE8QMP7QGp4iwsSc4sz0yHypxh1Oe5M+b+ISYglLz8v VUqc1xGkSACkKKM0D24OLBG8YhQHekuY1xakigeYROAmvQJawgS05PQqcZAlJYkIKakGxmC5 qqZEKWmLysjXvvvUWDqXbMk6M21PaKbXAYWFuxw+z7n/YbsKV5Xvwh9GnC2PM22lWq83Jy3m L1zdFP01mCuw5MPHP3HF9iFuBtkm+/5d1fy2R2SL3ubyeLcNpg+bt9qK3b3ewrog2/mrtb37 pk/M+78nVeTq9y1N3WZSMUN+M9f5PX1MSizFGYmGWsxFxYkAny0O1t8CAAA= Archived-At: Subject: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 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: Mon, 30 Mar 2015 16:40:50 -0000 This message begins the Working Group Last Call (WGLC) of "AES Encryption with HMAC-SHA2 for Kerberos 5" . The WGLC will last two weeks, ending on Monday, April 13th. The draft is available at: https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-06 Please review the document and send comments to the Working Group mailing list or the co-chairs before the end of the WGLC. Any and all comments on the document are sought in order to access the strength of consensus. Even if you have read and commented on this or earlier versions of the draft, please feel free to comment again. This is particularly important if you found issues with the previous version. As a reminder, comments can be anything from "this looks fine" to "this is a horrible idea"; they can include suggestions for minor editorial corrections to significant editorial changes. - Your Kitten Chairs From nobody Mon Mar 30 11:30:41 2015 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 B04DA1AC3B4 for ; Mon, 30 Mar 2015 11:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.511 X-Spam-Level: X-Spam-Status: No, score=-11.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 79EVWb3xVDUa for ; Mon, 30 Mar 2015 11:30:37 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F5F1A9308 for ; Mon, 30 Mar 2015 11:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7217; q=dns/txt; s=iport; t=1427740237; x=1428949837; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=Ng7zaHkdlIPF+IRm4IUyJVcnBRUM4JBz5VUpl3HuQlA=; b=AaLdv5UHSxsl3fUJqanTGl7KMJ/5RrAhAquOukXB6SFcfI5T8cVq1996 EAhI8KjGG7EvQlNvWFls/XRaaBoruAe0WyBI02q/a1ZaB6gVjdOs4SKX3 kjQcG/tYguFF3uPNsfVe1GcA8i5zZjgdakm6g7ITQ6J+smUsXq+ciAQNl w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DqBAAklRlV/4wNJK1cgwZSWgSDDMBZgUeHODgUAQEBAQEBAXyEOAZFAwMKNgIFDwcLAgsDAgECATUCARMNBgIBAYgrowOPTJoCAQEBAQYBAQEBAQEYBIEhjjBkglCBRQWFC4YHiSuFf4EbgzCCOCGGE4Mrg0ciggEdgW9QgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,495,1422921600"; d="scan'208";a="136607287" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 30 Mar 2015 18:30:36 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2UIUaUU005084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 30 Mar 2015 18:30:36 GMT Received: from [10.129.24.55] (10.129.24.55) by xhc-aln-x08.cisco.com (173.36.12.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 30 Mar 2015 13:30:36 -0500 Message-ID: <5519964B.6010008@cisco.com> Date: Mon, 30 Mar 2015 12:30:35 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.55] Archived-At: Subject: [kitten] IETF 92 Meeting Minutes (DRAFT) 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: Mon, 30 Mar 2015 18:30:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, Below are the draft meeting minutes from the IETF 92 session on Friday (03/27). Please send corrections to the list or the chairs (kitten-chairs@tools.ietf.org). These will be posted to the meeting materials site within the next couple of days. Special thanks again to Jim Schaad for taking minutes! - - Your kitten co-chairs - -----BEGIN MINUTES----- IETF 92 - kitten Working Group Minutes ================================================================ Location: IETF 92, Dallas, TX, US (Fairmont Dallas) Room: Far East Time: 2015-03-27 1150-1320 Co-Chairs: Ben Kaduk Matt Miller Shawn Emery (really outgoing this time) Scribe: Jim Schaad Action Items ================================================================ 1) draft-ietf-kitten-rfc4402bis * Shawn Emery to submit new draft as soon as he gets access to the file 2) draft-ietf-kitten-rfc6112bis * Shawn Emery to submit new draft, but may not be until end of May 2015 3) draft-ietf-kitten-rfc5653bis * Chairs to take discussion on Java Stream API to list 4) draft-josefsson-kitten-gs2bis / draft-josefsson-sasl-tls-cb * Chairs to work on draft "liaison statement" to TLS WG about the need for a functional "tls unique" 5) draft-ietf-krb-wg-pkinit-alg-agility * Someone (Chairs?) to revive missing edits on the mailing list 6) Non-WG drafts * Chairs to discuss how/when to call for adoption of drafts. Conference Session ================================================================ 1. Preliminaries (5 min) 2. Active WG items (20 min) Chairs briefly review the status of each document, and discuss any open issues and/or recent comments on each. 2.1 CAMMAC draft-ietf-kitten-cammac 2.2 GSS-Loop draft-ietf-kitten-gss-loop 2.3 SASL/OAuth draft-ietf-kitten-sasl-oauth 2.4 4402 Update draft-ietf-kitten-rfc4402bis Shawn Emery will submit new draft as soon as he gets access to the file. 2.5 6112 Update draft-ietf-kitten-rfc6112bis Shawn Emery will do it but may take until the end of May 2.6 5653 Update draft-ietf-kitten-rfc5653bis Nico Williams thinks that the steam stuff can be removed. The GSI folks uses a self framing method with TLS, one could have used the JAVA streaming that way but not as specified. Chairs will take this discussion to the list. 2.7 AES/SHA2 draft-ietf-kitten-aes-cts-hmac-sha2 2.8 PKINIT-Fresh draft-ietf-kitten-pkinit-freshness 2.9 SASL-SAML-EC draft-ietf-kitten-sasl-saml-ec 2.10 IAKERB draft-ietf-kitten-iakerb Nico thinks should have a mechanism attribute which states that the mechanism might not succeed. There are some applications which need to avoid this state, i.e. they must always succeed. 2.11 Auth-Ind draft-ietf-kitten-krb-auth-indicator 2.12 GS2 Update draft-josefsson-kitten-gs2bis Need to get a new channel binding (e.g., draft-josefsson-sasl-tls-cb) until TLS session hash fix gets rolled out. Nico says that you need to have the session hash from TLS to be correct. This will also be necessary for the Token Binding WG as well. Need to have the chairs draft a message asking for changes from the TLS working group to get real channel bindings. 2.13 IANA-reg draft-ietf-kitten-gssapi-extensions-iana Tom Yu believes he can get it done in one or two meetings cycles, but needs help getting reviews done. 2.14 Channel Bound draft-ietf-kitten-channel-bound-flag Nico Williams is interested in moving this forward, but does not have cycles for this. He needs help to get the state swapped back in. Simo Sorce from the jabber room would like to assist with this. 2.15 PKINIT-alg draft-ietf-krb-wg-pkinit-alg-agility Need to revive the one missing edit back to the list and Bill Mills can finish with the edits. 3. Kerberos PAD (10 minutes) Ben Kaduk discussed use cases and requests seen by Simo that motivate reviving the Kerberos PAD draft. Nico Williams says this is starting to look like SIDS - NFS people might like this Group and user identification numbers need to be scoped correctly. Will be crossing name space boundaries when you cross realms Shawn Emery would also like a GSS-API interface Nico Williams says you should be able to get a smaller ticket from a service in exchange for the large ticket with all of your data in it. Stephen Farrel says that we should check with Microsoft to see if any IPR issues still apply. existing Nico Williams states that if inclusion of POSIX information is covered by IPR, this whole effort is probably dead. 4. Deprecating old Kerberos encryption types (10 minutes) Ben Kaduk presented draft-kaduk-kitten-des-des-des-die-die-die Kenny Patterson asks about key strengths. The key values could either be randomly generated or derived from passwords. If derived from passwords, biases in RC4 is the least of your attack in these issues. Shawn Emery says that some of the newer mechanisms replace password derived key generation is in stream Bill Mills says that elimination of Windows XP and 2003 servers by the PCI compliance enforcement. 5. Kerberos Service Discovery Ben Kaduk talked about draft-mccallum-kitten-krb-service-discovery. Nico supports the draft as does Simo Sorce. 6. Extra round trips in Kerberos (10 minutes) Nico will present draft-williams-kitten-krb5-extra-rt Shawn Emery agrees this would be helpful. 7. GSS-only Kerberos encryption types (10 minutes) Nico Williams talked about this proposal to bring in, e.g., GCM mode for improved performance Ben Kaduk notes that there are several name type registry entries with strong restrictions on usage context 8. PKCROSS (10 minutes) Nico Williams talked about draft-williams-kitten-krb5-pkcross and the various alternate proposals which have been made. 9. GSS generic naming attribues (10 minutes) Nico Williams talked about draft-williams-kitten-generic-naming-attributes 10. Open mic (5 min) Nico Williams regarding the registry - we may be able to drop a couple of these documents and go directly to IANA expert review on them. Chairs poll the room to see how many of the non-WG drafts people have read, in preparation for a call for adoption. Poor showing in the room-- generally the same 3 or 4 individuals. Chairs need to discuss how and when to call for adoption on some or all of the non-WG documents. - -----END MINUTES----- -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVGZZLAAoJEDWi+S0W7cO1jmUH/1oxyQdbQ0YchW5cQGQAXuhX x+s4IIjnNSR0j3uBYXSeVn++2sZ7ZdirmToWVmZ/mtqrW0AErRWjEi+c7qk9u0MG ROQAA6Ug6JzmEal43nQk7NiW+Kc8NvitR4oTJPVvYymrqk6OpDW6aEGSF1An762h KfZ51Lg2eVuJfZ+Im1T6Tx/ane6jORk46otuPg6sol94cXBmFGMv3KTwcBteKbgk 8oNQZmHrUtlPCQCacJ9ouSrPJeXmvq4pC6Hov5qYOLn7je4f5qk+c+K7TRZospUW PLhBxkhrlAYgO4b7ppRw8xDUcrOrztrIM9mrsiXjckJrgPpbyUrM0GLCRWqzdwA= =JvfT -----END PGP SIGNATURE----- From nobody Mon Mar 30 16:11:08 2015 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 D9F551A8890 for ; Mon, 30 Mar 2015 16:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 j4z1eWtU4qni for ; Mon, 30 Mar 2015 16:11:05 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id A50F81A886A for ; Mon, 30 Mar 2015 16:11:05 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-2f-5519d808516d 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 dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id C8.39.03451.908D9155; Mon, 30 Mar 2015 19:11:05 -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 t2UNB4H3009522 for ; Mon, 30 Mar 2015 19:11:04 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2UNB2H3016852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 30 Mar 2015 19:11:04 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2UNB22l015807; Mon, 30 Mar 2015 19:11:02 -0400 (EDT) Date: Mon, 30 Mar 2015 19:11:01 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUixG6nrst5QzLU4OoEdoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY+f2w+wF7UIVMyb/ZWxgvMTXxcjJISFgIvGuZxILhC0mceHe erYuRi4OIYHFTBKvPu5ghHCOM0ocnnsHKnODSeJ2w3QmCKeBUaJvSR8TSD+LgLbE7Dvb2EBs NgEViZlvNoLZIgLCEru3vmMGaRAWWMkocaCxlRUkwSvgKPGk4Qg7iC0qoCOxev8UFoi4oMTJ mU/AbGYBLYnl07exTGDkm4UkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdU73czBK9 1JTSTYzgkHJR2sH486DSIUYBDkYlHl6HeolQIdbEsuLK3EOMkhxMSqK89w9IhgrxJeWnVGYk FmfEF5XmpBYfYpTgYFYS4fXcCpTjTUmsrEotyodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgST leHgUJLgXXQNqFGwKDU9tSItM6cEIc3EwQkynAdoeCZIDW9xQWJucWY6RP4Uo6KUOG80SEIA JJFRmgfXC4v5V4ziQK8I8yqDVPEA0wVc9yugwUxAg0+vEgcZXJKIkJJqYJw1J6Z7X+ED+Zmd yn9tojVvfd+8L9WiwKMqccfWWd07ps+/4jbDvO7093aDf5Eid2wzLnB8XKYmMHnS9LRXITxv BJi3mivP5bI8eyT3Q79w/M+4FLnDsTNKj7TyHCrL/LFBZnb2zq6LBQ8V65umrWOo19gl8VZh vuKiBD7G/QJZ3wpLM+RK7imxFGckGmoxFxUnAgBTdDjt1AIAAA== Archived-At: Subject: [kitten] Fwd: Last Call: (Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension) to Proposed Standard 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: Mon, 30 Mar 2015 23:11:08 -0000 I believe this document is the TLS session hash we had discussed with regards to the GSS-API channel bindings. -Ben ---------- Forwarded message ---------- Date: Mon, 30 Mar 2015 10:58:58 -0400 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce Cc: tls@ietf.org Subject: Last Call: (Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension) to Proposed Standard The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ballot/ No IPR declarations have been submitted directly on this I-D. ID-NITs says this uses "NOT RECOMMENDED" but that that's not called out as a term. We'll fix that. From nobody Tue Mar 31 08:21:27 2015 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 E3CAA1ACE38 for ; Tue, 31 Mar 2015 08:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 3yADdPAx8blU for ; Tue, 31 Mar 2015 08:21:25 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0331ACE36 for ; Tue, 31 Mar 2015 08:21:25 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id F3DF920058DAF for ; Tue, 31 Mar 2015 08:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=DJTb5SGjaGe6W1tXenkgNM4Hwxc=; b=CACsHNwImPd fG/wI7qWWxN76s7kes3LjIM+hbt0mX5cIt9njM/KZ8LDFtBG2WUksxr/e4voStZM p5OM7l3CMoGmXy6DUr6ZmMgSa9O/LRDxdLofrSy+GUI7qdEuQJu/+T6hjUj19Qf7 spbkkF260F/Xapn+n/WM++z3WwC2SaV0= Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id A755B20058DAD for ; Tue, 31 Mar 2015 08:21:24 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so20990973ied.1 for ; Tue, 31 Mar 2015 08:21:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.164.69 with SMTP id n66mr56628396ioe.82.1427815282253; Tue, 31 Mar 2015 08:21:22 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Tue, 31 Mar 2015 08:21:22 -0700 (PDT) Date: Tue, 31 Mar 2015 10:21:22 -0500 Message-ID: From: Nico Williams To: "kitten@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [kitten] GSS-only enctypes 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: Tue, 31 Mar 2015 15:21:26 -0000 I think the consensus at the meeting was that we could indeed reuse the Kerberos enctype number space for GSS-only enctypes, since there is some precedent for this. It would be significantly easier, from an implementation perspective, to do just that. Nico -- From nobody Tue Mar 31 14:36:44 2015 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 8A8571A87DB for ; Tue, 31 Mar 2015 14:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fyCaD9cNw4du for ; Tue, 31 Mar 2015 14:36:39 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657CB1A87D2 for ; Tue, 31 Mar 2015 14:36:39 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-21-551b1366138f 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 dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 4F.23.03355.6631B155; Tue, 31 Mar 2015 17:36:38 -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 t2VLabk0014462; Tue, 31 Mar 2015 17:36:37 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2VLaa0s027279; Tue, 31 Mar 2015 17:36:37 -0400 From: Tom Yu To: Bill Mills References: <962591069.3713128.1427479391512.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 31 Mar 2015 17:36:33 -0400 In-Reply-To: (Tom Yu's message of "Fri, 27 Mar 2015 14:47:20 -0400") Message-ID: Lines: 69 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUixCmqrZsmLB1qcPMEv8XRzatYLL51XWd2 YPJYsuQnk8esWYeZApiiuGxSUnMyy1KL9O0SuDK+ndrIUjBLpOLjjonMDYx/+LoYOTgkBEwk lk6y7GLkBDLFJC7cW8/WxcjFISSwmEni+cGPbCAJIYGNjBJT98hCJN4wSlze/pkVJMEmIC1x /PIuJpBBIgLqEs3fvUHCzALyEqfWPwXrFRaIlziw8RPU0OWMEq9O/2MEqWcRUJX498ERpIZT IEPixoLp7CA2r4CuxLNXl8FsHgFOiXlvX7NAxAUlTs58wgIxX0vixr+XTBMYBWYhSc1CklrA yLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11gvN7NELzWldBMjOBgl+XYwfj2odIhRgINRiYf3 wj3JUCHWxLLiytxDjJIcTEqivAZC0qFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHi3H5EKFeJN SaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuAVABkqWJSanlqRlplTgpBm 4uAEGc4DNFwfpIa3uCAxtzgzHSJ/ilFRSpyXAyQhAJLIKM2D64Uli1eM4kCvCPMmgVTxABMN XPcroMFMQINPrxIHGVySiJCSamCsTNH/HLfpadFGkWtZvkalwnxzT//WnTdt1pVPGc4qN43C FCb8y793wdc7J8OunCeUf0nsrucN5h9WiV/xt8xkF+KzU06r/bpp+U6NbOsj3xb0S57O9r22 u+mPW6za4uvZe7YuKs41nTdxtYzY4ckhs5c0azD5mTiu7q7Tfh2/su+tZ2lR5AolluKMREMt 5qLiRACzS9cf8QIAAA== Archived-At: Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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: Tue, 31 Mar 2015 21:36:41 -0000 Here are the KDF OID related changes that I think should happen to the algorithm agility draft. Change the Appendix A ASN.1 module IMPORTS subclause that mentions PK-INIT-SPEC from PKAuthenticator, DHNonce FROM KerberosV5-PK-INIT-SPEC { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) pkinit(5) }; -- as defined in RFC 4556. to PKAuthenticator, DHNonce, id-pkinit FROM KerberosV5-PK-INIT-SPEC { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) pkinit(5) }; -- as defined in RFC 4556. (This adds id-pkinit to the imports). Change the OID list in Section 6 from id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit 6 } -- PKINIT KDFs id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER ::= { id-pkinit-kdf 1 } -- SP800 56A ASN.1 structured hash based KDF using SHA-1 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf 2 } -- SP800 56A ASN.1 structured hash based KDF using SHA-256 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf 3 } -- SP800 56A ASN.1 structured hash based KDF using SHA-512 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER ::= { id-pkinit-kdf 4 } -- SP800 56A ASN.1 structured hash based KDF using SHA-384 to id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } -- PKINIT KDFs id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER ::= { id-pkinit-kdf sha1(1) } -- SP800-56A ASN.1 structured hash based KDF using SHA-1 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf sha256(2) } -- SP800-56A ASN.1 structured hash based KDF using SHA-256 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf sha512(3) } -- SP800-56A ASN.1 structured hash based KDF using SHA-512 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER ::= { id-pkinit-kdf sha384(4) } -- SP800-56A ASN.1 structured hash based KDF using SHA-384 and also duplicate that in the Appendix A ASN.1 module. Inserting it right after the IMPORTS clause might be a good place. We can debate whether the component identifiers for the KDF OIDs should be just or ah-. We might also want to duplicate the id-pkinit definition from RFC 4556 in Section 6 (but not the Appendix A ASN.1 module), to make the full OID easier for a casual reader to derive. Any comments? -Tom From nobody Tue Mar 31 15:01:46 2015 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 5DF931AD16B for ; Tue, 31 Mar 2015 15:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 np8B2gcyRlas for ; Tue, 31 Mar 2015 15:01:43 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6250E1AD0C7 for ; Tue, 31 Mar 2015 15:01:41 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 7E114594078 for ; Tue, 31 Mar 2015 15:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=vE5KLdXvsHIe+ud2X85k 8mKxcBQ=; b=auy5l4VatviJ2aTJY0hRlHcRrT0WBRL7Ies0MwAnZHwcb19Jw6gx pho0E+yKJ4ByBUKJ/ihSURpOCP9Hs2zzfClEnl05J7M9Xx29vMCSoOSnZcrQr0Sv uZcMsZct8L58HOSkz97o752R3KIRNosKqUGbbGvFTAuKLIGizKx2GNY= Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 0871C594086 for ; Tue, 31 Mar 2015 15:01:20 -0700 (PDT) Received: by igcau2 with SMTP id au2so20541581igc.1 for ; Tue, 31 Mar 2015 15:01:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.36.104 with SMTP id p8mr7742263igj.16.1427839279643; Tue, 31 Mar 2015 15:01:19 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Tue, 31 Mar 2015 15:01:19 -0700 (PDT) In-Reply-To: References: <962591069.3713128.1427479391512.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 31 Mar 2015 17:01:19 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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: Tue, 31 Mar 2015 22:01:44 -0000 On Tue, Mar 31, 2015 at 4:36 PM, Tom Yu wrote: > Here are the KDF OID related changes that I think should happen to the > algorithm agility draft. > > Change the Appendix A ASN.1 module IMPORTS subclause that mentions > PK-INIT-SPEC from > > PKAuthenticator, DHNonce > FROM KerberosV5-PK-INIT-SPEC { > iso(1) identified-organization(3) dod(6) internet(1) > security(5) kerberosV5(2) modules(4) pkinit(5) }; > -- as defined in RFC 4556. > > to > > PKAuthenticator, DHNonce, id-pkinit > FROM KerberosV5-PK-INIT-SPEC { > iso(1) identified-organization(3) dod(6) internet(1) > security(5) kerberosV5(2) modules(4) pkinit(5) }; > -- as defined in RFC 4556. > > (This adds id-pkinit to the imports). OK. > Change the OID list in Section 6 from > > id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit 6 } > -- PKINIT KDFs > id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER ::= { id-pkinit-kdf 1 } > -- SP800 56A ASN.1 structured hash based KDF using SHA-1 > id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf 2 } > -- SP800 56A ASN.1 structured hash based KDF using SHA-256 > id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf 3 } > -- SP800 56A ASN.1 structured hash based KDF using SHA-512 > id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER ::= { id-pkinit-kdf 4 } > -- SP800 56A ASN.1 structured hash based KDF using SHA-384 > > to > > id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } > -- PKINIT KDFs Ah, that's nice. The Heimdal ASN.1 compiler shows this as "label-less" in the comments in the header file it generates. > id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER > ::= { id-pkinit-kdf sha1(1) } > -- SP800-56A ASN.1 structured hash based KDF using SHA-1 > > id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER > ::= { id-pkinit-kdf sha256(2) } > -- SP800-56A ASN.1 structured hash based KDF using SHA-256 > > id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER > ::= { id-pkinit-kdf sha512(3) } > -- SP800-56A ASN.1 structured hash based KDF using SHA-512 > > id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER > ::= { id-pkinit-kdf sha384(4) } > -- SP800-56A ASN.1 structured hash based KDF using SHA-384 > > and also duplicate that in the Appendix A ASN.1 module. Inserting it > right after the IMPORTS clause might be a good place. OK. > We can debate whether the component identifiers for the KDF OIDs should > be just or ah-. I don't think that would be a breaking change, though in general OID naming changes could be. The safe way to do this would be to leave compatibility values behind: id-pkinit-kdf-sha384 OBJECT IDENTIFIER ::= id-pkinit-kdf-ah-sha384 But I don't care. > We might also want to duplicate the id-pkinit definition from RFC 4556 > in Section 6 (but not the Appendix A ASN.1 module), to make the full OID > easier for a casual reader to derive. Sure. > Any comments? Not really. LGTM. Nico -- From nobody Tue Mar 31 15:07:22 2015 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 44C4F1A9130 for ; Tue, 31 Mar 2015 15:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 oarIyN1JSqpv for ; Tue, 31 Mar 2015 15:07:20 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 94F861ACD26 for ; Tue, 31 Mar 2015 15:07:20 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-ff-551b1a97c420 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 dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id A8.2B.03451.79A1B155; Tue, 31 Mar 2015 18:07:19 -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 t2VM7JkP012984; Tue, 31 Mar 2015 18:07:19 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2VM7HRV014715; Tue, 31 Mar 2015 18:07:18 -0400 From: Tom Yu To: Nico Williams References: <962591069.3713128.1427479391512.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 31 Mar 2015 18:07:15 -0400 In-Reply-To: (Nico Williams's message of "Tue, 31 Mar 2015 17:01:19 -0500") Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6nojtdSjrUYNIXc4ujm1exWJy6doTN 4lvXdWYHZo+Xp84xeixZ8pPJY9asw0wBzFFcNimpOZllqUX6dglcGct7VQtOslY82v6XsYHx KEsXIyeHhICJxN/jx1ghbDGJC/fWs3UxcnEICSxmkmiZsJYVwtnIKHFzwmoo5w2jxL5dzxhB WtgEpCWOX97FBGKLCGhKXJ+3lA3EZhZwkVh+4TYziC0sEC9xYOMnqLETmCSmr7oKVsQioCox eWM/M0iCU2ASo8ThXZ/ADuEV0JVYuqwDzOYR4JT49XcCG0RcUOLkzCcsEBu0JG78e8k0gVFg FpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9XIzS/RSU0o3MYID1UVpB+PPg0qH GAU4GJV4eC/ckwwVYk0sK67MPcQoycGkJMr7UEw6VIgvKT+lMiOxOCO+qDQntfgQowQHs5II 7/YjUqFCvCmJlVWpRfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIcHEoSvNGSQEMFi1LT UyvSMnNKENJMHJwgw3mAhjOC1PAWFyTmFmemQ+RPMepy3JnyfxGTEEtefl6qlDivM0iRAEhR Rmke3BxYgnnFKA70ljCvBUgVDzA5wU16BbSECWjJ6VXiIEtKEhFSUg2MWSWWCSZXFhk5R06y W+T5/jB7++3HE5WbvDhlFjM4LLvP41Ih8lD/2IwHpn0P/15nXh/1zWQlR/Ui1p0BT/eenPWF OelCo8uJaxbbrKT53yqK+Ua7T5Vyu5BYsOFPrKnwJ9e7CnoZvzwOulru4NF5W8DXtcpm3btn B07LWf3ek79mL988mzUqSizFGYmGWsxFxYkAicvcmwsDAAA= Archived-At: Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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: Tue, 31 Mar 2015 22:07:22 -0000 Nico Williams writes: > On Tue, Mar 31, 2015 at 4:36 PM, Tom Yu wrote: >> We can debate whether the component identifiers for the KDF OIDs should >> be just or ah-. > > I don't think that would be a breaking change, though in general OID > naming changes could be. The safe way to do this would be to leave > compatibility values behind: > > id-pkinit-kdf-sha384 OBJECT IDENTIFIER ::= id-pkinit-kdf-ah-sha384 > > But I don't care. I was intending to indicate, e.g., { id-pkinit-kdf sha384(4) } vs { id-pkinit-kdf ah-sha384(4) } , not the reference identifiers for the entire OIDs (id-pkinit-kdf-ah-sha384 vs id-pkinit-kdf-sha384).