From nobody Mon Jan 2 00:39:21 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 359F91294EF; Mon, 2 Jan 2017 00:39:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tim Wicinski To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148334635017.21940.7658516693051800431.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2017 00:39:10 -0800 Archived-At: Cc: kitten@ietf.org, draft-ietf-kitten-rfc6112bis.all@ietf.org, ietf@ietf.org Subject: [kitten] Review of draft-ietf-kitten-rfc6112bis-03 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 08:39:10 -0000 Reviewer: Tim Wicinski Review result: Ready Hi I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document Reviewed: draft-ietf-kitten-rfc6112bis Status: Ready Summary: The -03 version addressed the minor issues I had found during reading. From nobody Tue Jan 3 09:51:57 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5BB129993; Tue, 3 Jan 2017 09:51:52 -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: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148346591275.28031.8160025114081132270.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 09:51:52 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-krb-auth-indicator-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 17:51:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation of the IETF. Title : Authentication Indicator in Kerberos Tickets Authors : Anupam Jain Nathan Kinder Nathaniel McCallum Filename : draft-ietf-kitten-krb-auth-indicator-05.txt Pages : 5 Date : 2017-01-03 Abstract: This document updates section "6. Assigned Numbers" of RFC 7751 in order to specify an extension in the Kerberos protocol. It defines a new authorization data type AD-AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-auth-indicator/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicator-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-auth-indicator-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 4 09:53:42 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2966B1296AB; Wed, 4 Jan 2017 09:53:33 -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: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148355241316.12949.931834298417786291.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 09:53:33 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-krb-auth-indicator-06.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 17:53:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation of the IETF. Title : Authentication Indicator in Kerberos Tickets Authors : Anupam Jain Nathan Kinder Nathaniel McCallum Filename : draft-ietf-kitten-krb-auth-indicator-06.txt Pages : 6 Date : 2017-01-04 Abstract: This document updates RFC 4120 in order to specify an extension in the Kerberos protocol. It defines a new authorization data type AD- AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-auth-indicator/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicator-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-auth-indicator-06 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 Thu Jan 5 11:47:41 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444CB129654; Thu, 5 Jan 2017 11:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.301 X-Spam-Level: X-Spam-Status: No, score=-7.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ziZHGatVHtu; Thu, 5 Jan 2017 11:47:36 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67443129653; Thu, 5 Jan 2017 11:47:36 -0800 (PST) X-AuditID: 12074425-80fff70000001995-49-586ea2d7c2d9 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 61.0C.06549.7D2AE685; Thu, 5 Jan 2017 14:47:35 -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 v05JlX8R011228; Thu, 5 Jan 2017 14:47:34 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v05JlTRQ027616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jan 2017 14:47:31 -0500 Date: Thu, 5 Jan 2017 13:47:29 -0600 From: Benjamin Kaduk To: Christian Huitema Message-ID: <20170105194728.GU8460@kduck.kaduk.org> References: <005f01d263d5$84b14680$8e13d380$@huitema.net> <006f01d263d8$435dc430$ca194c90$@huitema.net> <20170103062001.GN8460@kduck.kaduk.org> <00c901d26766$566e9ae0$034bd0a0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c901d26766$566e9ae0$034bd0a0$@huitema.net> User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IR4hTV1r2+KC/C4OUtPou5Lb9ZLCY3zma3 mPFnIrPF0c2rWCwmvLnNajH36yxWiw8LH7I4sHvcmnGKxWPJkp9MHu/3XWULYI7isklJzcks Sy3St0vgylje9Yyx4I17xZfnz1gbGPutuhg5OCQETCS6N2V1MXJxCAm0MUl8+T+DFcLZwCjx +fw0JgjnCpPEoy+n2boYOTlYBFQk5h3byw5iswHZDd2XmUFsEQFtiTWz74E1MAvsZpT4s38x E0hCWMBP4vX1yywgNq+AscThlsuMEFMPM0q8OPOQGSIhKHFy5hOwImYBLYkb/14ygdzHLCAt sfwfB0iYU8BK4sCfF6wgtqiAskTDjAfMExgFZiHpnoWkexZC9wJG5lWMsim5Vbq5iZk5xanJ usXJiXl5qUW6Fnq5mSV6qSmlmxhBQc7uorqDcc5fr0OMAhyMSjy8EV55EUKsiWXFlbmHGCU5 mJREeVNnAIX4kvJTKjMSizPii0pzUosPMUpwMCuJ8K6bB5TjTUmsrEotyodJSXOwKInzXsp0 jxASSE8sSc1OTS1ILYLJynBwKEnwci8EahQsSk1PrUjLzClBSDNxcIIM5wEaXgFSw1tckJhb nJkOkT/FqCglzlu5ACghAJLIKM2D6wUlIYns/TWvGMWBXhHm/QLSzgNMYHDdr4AGMwEN3h6Q DTK4JBEhJdXAWLu2W4M7yYXbpCTqTvMWsQ+bkuS3dvkWXXLl/WXqPSNuWw773RmnxUo2CU/k u/gzedM9V2PXtxcmmHyuLvFjXDzB05rha7e1/wTBpe/2pEwRLj0ZUb/L1Tog/mhuiuLXW8pT fu2NVD301OW8Q+N6nXQmvX/1+t967qmm9L37G7Rn9fGDnBMilViKMxINtZiLihMBVU0XNB0D AAA= Archived-At: Cc: 'secdir' , draft-ietf-kitten-krb-auth-indicator.all@ietf.org, kitten@ietf.org, 'IESG' Subject: Re: [kitten] [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 19:47:39 -0000 On Thu, Jan 05, 2017 at 07:13:55AM -0800, Christian Huitema wrote: > Thanks for the corrections. I checked the new draft version, > draft-ietf-kitten-krb-auth-indicator-06, and the changes address my concern. > The new section "4. Assigned Numbers" provides a clear update to RFC 4120, > and the added paragraph in the security section addresses cross-realm > indicator collisions. Thanks for finding the new document -- I was going to send you a pointer today to confirm that it addressed your concerns, but you beat me to it. > One point, though. The new section 4 states: > > o The table in Section 5.2.6 of RFC 4120 [RFC4120] is updated to map > the ad-type 97 to "DER encoding of AD-AUTHENTICATION-INDICATOR". > > Should that not be "DER encoding of AD-AUTHENTICATION-INDICATOR wrapped in a > CANMAC container"? I don't think so, but will loop in the WG to confirm. The ad-type should indicate what is immediately inside the next encoding layer of the ad-data. So a Ticket might have an AuthorizationData that contains ad-type 1 (AD-IF-RELEVANT), that itself contains AuthorizationData with ad-type 96 (AD-CAMMAC), that in turn contains AuthorizationData with ad-type 97 (AD-AUTHENTICATION-INDICATOR). So, 97 should appear only at the lowest level, and correspond to ad-data that's just the AD-AUTHENTICATION-INDICATOR itself. But thanks again for double-checking! -Ben > > > > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Monday, January 2, 2017 10:20 PM > To: Christian Huitema > Cc: 'IESG' ; 'secdir' ; > draft-ietf-kitten-krb-auth-indicator.all@ietf.org; nkinder@redhat.com; > npmccallum@redhat.com > Subject: Re: [secdir] SECDIR review of > draft-ietf-kitten-krb-auth-indicator-04 > > Hi Christian, > > Thanks for the review! > > On Sat, Dec 31, 2016 at 06:39:21PM -0800, Christian Huitema wrote: > > Copying to Nathan Kinder and Nathaniel McCallum, since their mail server > > rejects messages relayed by the IETF server. > > > > -----Original Message----- > > From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Christian > Huitema > > Sent: Saturday, December 31, 2016 6:20 PM > > To: 'IESG' ; 'secdir' ; > > draft-ietf-kitten-krb-auth-indicator.all@ietf.org > > Subject: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04 > > > [...] > > The document is almost ready, by I wish a few issues were addressed before > > publication. > > > > My first issue is that the document describes an update to the Kerberos > > protocol specification, RFC 4120, but does not define the specific way in > > which RFC 4120 is updated. Could the draft be updated to include something > > like the section "6. Assigned Numbers" of RFC 7751? If I understand > > correctly, the changes are a new ad-type number 97, pointing to a CAMMAC > > container, in which the "elements" are encoded according to the syntax > > specified in Appendix A of the draft. Having that explained succinctly > would > > help future readers. > > I noticed the "Updates but doesn't really update" issue while preparing the > shepherd review, and opted to leave in the "Updates" marker since it's > probably something an implementor of 4120 should know about. > The "Assigned Numbers" section is a good idea, thanks for pointing it out > (and yes, you understand correctly). > > Authors, can you prepare another update? > > > My second issue is with the use of site-defined strings. I understand that > > the site defined strings are defined by the administrator of a realm. What > > happens if these strings appear outside the original realm, for example in > > an environment connecting multiple realms? Don't we have a potential there > > for name collision? Should there not be some guidance to implementers? > > There is maybe some potential for confusion, though not, I think, at the > protocol level. The authentication indicator should always originate from > the realm of orignial authentication, which is the realm of the client > principal (in general). Even with some of the more exotic flows, like > anonymous (or semi-anonymous) principals and making cross-realm TGS > requests for foreign-realm TGTs, the client principal's realm is unchanged, > so at a protocol level, the meaning of "this realm asserts that this > authentication mechanism was used" remains clear. The confusion is when > applications just check strings against a table without special-casing > foreign-realm principals (which is likely to happen and the natural thing > for application authors to do; I am not trying to belittle the issue > you raised). > > In many cases, cross-realm operations occur when the administrators > of the different realms are tightly coordinated (or even the same > group), in which case they probably use the same semantics for the > authentication indicator. In cases where the administrators of the > different realms are genuinely different organizations, there are already > risks for application services in such realms, such as for applications > that grant access to "valid user". That said, the authentication indicator > does introduce a new type of risk, and it is appropriate to have some > text about it in the security considerations. > > Authors, do you think you can come up with text, or should one of us > try to make a contribution? > > > I note that the proposed short string syntax forbids use of the ":" > > character in site-defined strings. Did the WG look at the consequences of > > that choice? If site administrators cannot use the URI like syntax, what > is > > the preferred way of defining unique strings and preventing collisions? > > I don't think the WG looked at the consequences, no -- IIRC this requirement > was introduced at my urging due to the shepherd review, in order to > avoid conflict between the two classes of possible values. If URIs must > be LoA profiles and site-local values must be not-URIs, then there is > no conflict. > > My expectation is that what will happen in practice is that the site-local > short strings will actually be implementation-local, and the name of the > preauthentication plugin or module will be used, like "otp" or "pkinit" > or "spake". I don't expect anyone to try to make globally unique values, > but of course there are always options like UUIDs or using alternate > separator characters for those who wish to try. (It is debatable whether > UUIDs count as "short", but there is no enforcement on "short", so > they are in practice fair game.) > > > What are application services supposed to do when they encounter URI or > > site-defined strings that they do not understand? > > The same thing they do now (in practice) when receiving other unknown > authorization data types: ignore it. (This is in violation of the > spec, that says unknown types should be treated as critical unless > wrapped in AD-IF-RELEVANT, but that behavior is not implemented in the > major implementations.) That may end up being a default-deny or > default-permit mode, depending on the application service's configuration. > > > The ASN.1 syntax defines the element as a "SEQUENCE OF UTF8String". The > > document mentions that "Each UTF8String value is a short string". How > short > > exactly should these strings be? How many of them should an application > > expect in the "SEQUENCE OF" element? The syntax itself does not constrain > > the length or number of these strings. Are we not worried with potential > > interoperability issues? Could this be abused in some attacks? Should the > > security considerations mention that? > > If I remember the history of the document correctly, there is intentionally > no limit. URIs for LoA profiles could end up being pretty long, and > there was a desire to not artificially limit those; it doesn't seem > worth complicating the semantics of the indicator just to impose a length > restriction on the non-URI strings. As far as the number of elements in > the sequence, in practice there is probably no issue, since the > authentication indicator is issued by the KDC in response to the actual > authentication that occurred -- well-behaved KDCs should only include > as many strings as authentication methods were used (which is in practice > one or two at the moment, and probably not going to get much above three > ever). There is always the concern about a client parsing > untrusted/unvalidated input, but the consumer should be validating the > MAC(s) in the CAMMAC container before parsing, and the implementation > ticket size (and similar) constraints will also limit the possible > size here. > > So, probably no attacks (absent compromised KDCs, which have other > ways to wreak havoc) and probably no need for security consideration > mention. I can't come up with any potential interoperability issues, > either, but I didn't spend a whole lot of time thinking about it. > > Thanks again, > > Ben > From nobody Thu Jan 5 11:58:00 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC13E129601; Thu, 5 Jan 2017 11:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czbU5Ybi5S5f; Thu, 5 Jan 2017 11:57:53 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C13129654; Thu, 5 Jan 2017 11:57:53 -0800 (PST) X-AuditID: 12074423-4c3ff70000003dbe-4b-586ea53f0feb 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 (Symantec Messaging Gateway) with SMTP id 13.8D.15806.F35AE685; Thu, 5 Jan 2017 14:57:52 -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 v05JvoD3028325; Thu, 5 Jan 2017 14:57:51 -0500 Received: from [18.101.8.126] (vpn-18-101-8-126.mit.edu [18.101.8.126]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v05Jvmw0030807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jan 2017 14:57:49 -0500 To: Benjamin Kaduk , Christian Huitema References: <005f01d263d5$84b14680$8e13d380$@huitema.net> <006f01d263d8$435dc430$ca194c90$@huitema.net> <20170103062001.GN8460@kduck.kaduk.org> <00c901d26766$566e9ae0$034bd0a0$@huitema.net> <20170105194728.GU8460@kduck.kaduk.org> From: Greg Hudson Message-ID: Date: Thu, 5 Jan 2017 14:57:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170105194728.GU8460@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IR4hRV1nVYmhdhMH2bkMXclt8sFpMbZ7Nb zPgzkdni6OZVLBYfFj5kcWD1uDXjFIvHkiU/mQKYorhsUlJzMstSi/TtErgyXu55y1LwlKVi Yv9PpgbGb8xdjJwcEgImEq/b7jB1MXJxCAm0MUkc7t0AlhAS2MAo8elUNkTiCJPE/V37wBLC ApESW2/PZwKxRQS8JT42zWKBKHrLKHHywxdmEIdZYAKjxIzPJ9hBqtgElCXW79/KAmLzClhJ tBzqZQSxWQRUJKa3/gSq4eAQFYiQaDicDlEiKHFy5hOwck6g854eWAq2mFlAT2LH9V+sELa8 xPa3c5gnMArMQtIyC0nZLCRlCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuma6eVmluilppRu YgQFMruL8g7Gl33ehxgFOBiVeHgjvPIihFgTy4orcw8xSnIwKYnyps4ACvEl5adUZiQWZ8QX leakFh9ilOBgVhLhXTcPKMebklhZlVqUD5OS5mBREue9lOkeISSQnliSmp2aWpBaBJOV4eBQ kuCVWwLUKFiUmp5akZaZU4KQZuLgBBnOAzRcejHI8OKCxNzizHSI/ClGXY4D71c8ZRJiycvP S5US560DKRIAKcoozYObA05AqRx1rxjFgd4S5p0Iso4HmLzgJr0CWsIEtGR7QDbIkpJEhJRU A6O4j89kkftXVtqXtB5U7vBf17smtKNRYYNOMUPLL5l/5RyZBSIqE1m6J8p1l3wr8CnOesqg 9OfLXuHN5+xnn1tX89Io1fK1YX/W++rL9+wOnf5nv/vUUoHDRWknzz2qrWLef/vaV62tld7f Waewm+aHqV/6J86mriTJKxl9qXFZ+uu1dkkL7JRYijMSDbWYi4oTAc4q4jEbAwAA Archived-At: Cc: kitten@ietf.org, draft-ietf-kitten-krb-auth-indicator.all@ietf.org, 'IESG' , 'secdir' Subject: Re: [kitten] [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 19:57:56 -0000 On 01/05/2017 02:47 PM, Benjamin Kaduk wrote: > I don't think so, but will loop in the WG to confirm. > The ad-type should indicate what is immediately inside the next encoding > layer of the ad-data. So a Ticket might have an AuthorizationData that > contains ad-type 1 (AD-IF-RELEVANT), that itself contains AuthorizationData > with ad-type 96 (AD-CAMMAC), that in turn contains AuthorizationData with > ad-type 97 (AD-AUTHENTICATION-INDICATOR). So, 97 should appear only at > the lowest level, and correspond to ad-data that's just the > AD-AUTHENTICATION-INDICATOR itself. I agree with Ben. From nobody Thu Jan 5 12:18:53 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E660512948A for ; Thu, 5 Jan 2017 12:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mdwn18orqKk for ; Thu, 5 Jan 2017 12:18:50 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 CB51D1293EB for ; Thu, 5 Jan 2017 12:18:50 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cPEUq-0005rm-SX for kitten@ietf.org; Thu, 05 Jan 2017 21:18:50 +0100 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cPEUp-0005KE-6V for kitten@ietf.org; Thu, 05 Jan 2017 15:18:48 -0500 Received: (qmail 28148 invoked from network); 5 Jan 2017 20:18:46 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.38.210]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Jan 2017 20:18:46 -0000 From: "Christian Huitema" To: "'Benjamin Kaduk'" References: <005f01d263d5$84b14680$8e13d380$@huitema.net> <006f01d263d8$435dc430$ca194c90$@huitema.net> <20170103062001.GN8460@kduck.kaduk.org> <00c901d26766$566e9ae0$034bd0a0$@huitema.net> <20170105194728.GU8460@kduck.kaduk.org> In-Reply-To: <20170105194728.GU8460@kduck.kaduk.org> Date: Thu, 5 Jan 2017 12:18:40 -0800 Message-ID: <042f01d26790$e936a5f0$bba3f1d0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEaPs7iLwqOaTNknblhLQFEtN95CQJSROSwAhA+0NYCGZkF0AHkJ1kioledNuA= X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.03) X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49KxQtGn3AswOT8Z9YHdvpk1TugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqRU0WDTzT2VA4QSJJCiEdMRcOb18WfxGyg6Om6u4YYm8Ex7JmehmyvzkXA 1zAmRsc5hjoyEb9Oq0NWpyO3vrfYnGR8JorokUtMqNDt1Oktij3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB8y9Ga5iCmdJFIvDEJb+pKRQRCdMNhge1Unb77YyuZq46nmCFK02cH99LuT/CgH0hRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU2Z0wfN9VTx9JdR4F4pphrEJ0EukYkH0+QwgTkvGReJqS3AA1zi4L4OJ0M18xnuBW/6 592ULW4vfh/b1HrXegYtEnYI0EWZRGihOmWEw9sJYqlGM+xDguDxJnnDh3alUJG6elFFgxvixKHD +ndZqoQq0JFb5sY5yvsuaKnQYvhP+274nM+117vLjWiTA8zC3e5qTjAEzQR26Rr0dPOgWImrjs9/ BX0barm2Y4IT1WcBZEH9asyhHPHrk1fOl/Hbtww= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Recommended-Action: accept Archived-At: Cc: 'secdir' , draft-ietf-kitten-krb-auth-indicator.all@ietf.org, kitten@ietf.org, 'IESG' Subject: Re: [kitten] [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 20:18:52 -0000 On Thursday, January 5, 2017 11:47 AM, Benjamin Kaduk wrote: > > Thanks for finding the new document -- I was going to send you a pointer > today to confirm that it addressed your concerns, but you beat me to it. Blame Tero Kivinen. He sent me a reminder this morning. >> One point, though. The new section 4 states: >> >> o The table in Section 5.2.6 of RFC 4120 [RFC4120] is updated to map >> the ad-type 97 to "DER encoding of AD-AUTHENTICATION-INDICATOR". >> >> Should that not be "DER encoding of AD-AUTHENTICATION-INDICATOR wrapped in a >> CAMMAC container"? > > I don't think so, but will loop in the WG to confirm. > The ad-type should indicate what is immediately inside the next encoding > layer of the ad-data. So a Ticket might have an AuthorizationData that > contains ad-type 1 (AD-IF-RELEVANT), that itself contains AuthorizationData > with ad-type 96 (AD-CAMMAC), that in turn contains AuthorizationData with > ad-type 97 (AD-AUTHENTICATION-INDICATOR). So, 97 should appear only at > the lowest level, and correspond to ad-data that's just the > AD-AUTHENTICATION-INDICATOR itself. OK, I get that now. It was not entirely obvious from reading the text. What is supposed to happen if the outside Authorization Data type is set to 97 instead of 96? Should that be specified somewhere? The text says: Authorization data elements of type AD-AUTHENTICATION-INDICATOR MUST be included in an AD-CAMMAC container so that their contents can be verified as originating from the KDC. That's a fine constraint for the sender, but what about receivers? -- Christian Huitema From nobody Thu Jan 5 12:39:39 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3430B129446 for ; Thu, 5 Jan 2017 12:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCDNMqYfFzmz for ; Thu, 5 Jan 2017 12:39:37 -0800 (PST) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) (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 691E4129415 for ; Thu, 5 Jan 2017 12:39:37 -0800 (PST) Received: by mail-it0-f54.google.com with SMTP id x2so914167itf.1 for ; Thu, 05 Jan 2017 12:39:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Bcya9tiKOzoC4numKkh8Qtikzk4BmNGvNbSS7DFiASc=; b=n4ZVKjY2n4xPnxEfksFg/slCZH7J1Byh31fzoYjklPUGXLZAmESKp/MC/BRM+qT2+P VFE6oTqeKUSbcaC+BCYI6dS2KpOmbxBHKR4Vs7fCBzKprFlXXBBTe843v5HXg7D4N7Kh VotIQgPY4C7kufrvZSoOow1ev3slC5Oa4dMo2LEhKW/csc2YwFcPKiCSjyn0ETMM+xVY RD9rAJiHUXfmnbommKTK/MBxgxCubvqdsVE01vXMV3nNN0/qXudZ25MVshSLOZxkZsp+ 7kZYHymwnQOMLzRD562JM2tpHuEJk8ELrcquE/ipaCRXVa8iOf0ZDCBg3BAINEGXweNN wl/w== X-Gm-Message-State: AIkVDXLIH0060zGPv2QVs3zU4Q7vj1r6uMc/0rBixiOJJBuRstGV5koa6lDy4j35Lw4dFgmug8okLScLO17Bip/H X-Received: by 10.36.203.194 with SMTP id u185mr6954747itg.93.1483648776660; Thu, 05 Jan 2017 12:39:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.34.195 with HTTP; Thu, 5 Jan 2017 12:39:36 -0800 (PST) In-Reply-To: <042f01d26790$e936a5f0$bba3f1d0$@huitema.net> References: <005f01d263d5$84b14680$8e13d380$@huitema.net> <006f01d263d8$435dc430$ca194c90$@huitema.net> <20170103062001.GN8460@kduck.kaduk.org> <00c901d26766$566e9ae0$034bd0a0$@huitema.net> <20170105194728.GU8460@kduck.kaduk.org> <042f01d26790$e936a5f0$bba3f1d0$@huitema.net> From: Nathaniel McCallum Date: Thu, 5 Jan 2017 15:39:36 -0500 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: secdir , draft-ietf-kitten-krb-auth-indicator.all@ietf.org, kitten@ietf.org, IESG Subject: Re: [kitten] [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 20:39:39 -0000 On Thu, Jan 5, 2017 at 3:18 PM, Christian Huitema wrote: > On Thursday, January 5, 2017 11:47 AM, Benjamin Kaduk wrote: >> >> Thanks for finding the new document -- I was going to send you a pointer >> today to confirm that it addressed your concerns, but you beat me to it. > > Blame Tero Kivinen. He sent me a reminder this morning. > >>> One point, though. The new section 4 states: >>> >>> o The table in Section 5.2.6 of RFC 4120 [RFC4120] is updated to map >>> the ad-type 97 to "DER encoding of AD-AUTHENTICATION-INDICATOR". >>> >>> Should that not be "DER encoding of AD-AUTHENTICATION-INDICATOR wrapped > in a >>> CAMMAC container"? >> >> I don't think so, but will loop in the WG to confirm. >> The ad-type should indicate what is immediately inside the next encoding >> layer of the ad-data. So a Ticket might have an AuthorizationData that >> contains ad-type 1 (AD-IF-RELEVANT), that itself contains > AuthorizationData >> with ad-type 96 (AD-CAMMAC), that in turn contains AuthorizationData with >> ad-type 97 (AD-AUTHENTICATION-INDICATOR). So, 97 should appear only at >> the lowest level, and correspond to ad-data that's just the >> AD-AUTHENTICATION-INDICATOR itself. > > OK, I get that now. It was not entirely obvious from reading the text. > > What is supposed to happen if the outside Authorization Data type is set to > 97 instead of 96? Should that be specified somewhere? The text says: > > Authorization data elements of type AD-AUTHENTICATION-INDICATOR MUST > be included in an AD-CAMMAC container so that their contents can be > verified as originating from the KDC. > > That's a fine constraint for the sender, but what about receivers? 5. Security Considerations ... Application servers MUST validate the AD-CAMMAC container before making authorization decisions based on AD-AUTHENTICATION-INDICATOR elements. Application servers MUST NOT make authorization decisions based on AD-AUTHENTICATION-INDICATOR elements which appear outside of AD-CAMMAC containers. ... From nobody Thu Jan 5 14:35:03 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EFF129717 for ; Thu, 5 Jan 2017 14:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8t-FSx7JN7Q for ; Thu, 5 Jan 2017 14:34:58 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 8CA44129789 for ; Thu, 5 Jan 2017 14:34:57 -0800 (PST) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cPGcZ-0008B8-KB for kitten@ietf.org; Thu, 05 Jan 2017 23:34:56 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cPGcY-0007eo-Bb for kitten@ietf.org; Thu, 05 Jan 2017 17:34:54 -0500 Received: (qmail 23007 invoked from network); 5 Jan 2017 22:34:54 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.5]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Jan 2017 22:34:53 -0000 From: "Christian Huitema" To: "'Nathaniel McCallum'" References: <005f01d263d5$84b14680$8e13d380$@huitema.net> <006f01d263d8$435dc430$ca194c90$@huitema.net> <20170103062001.GN8460@kduck.kaduk.org> <00c901d26766$566e9ae0$034bd0a0$@huitema.net> <20170105194728.GU8460@kduck.kaduk.org> <042f01d26790$e936a5f0$bba3f1d0$@huitema.net> In-Reply-To: Date: Thu, 5 Jan 2017 14:34:47 -0800 Message-ID: <045e01d267a3$ed12d410$c7387c30$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEaPs7iLwqOaTNknblhLQFEtN95CQJSROSwAhA+0NYCGZkF0AHkJ1kiAwSBZ48C3tfbXaIorGEA X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.04) X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49Nd7AN7sevoJn7jQtAGeOfdTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoEa2bm6jOIc5l+F6ffSlBzRcOb18WfxGyg6Om6u4YYm1AhbOs6y7r/qE8u CXAcqRA5hjoyEb9Oq0NWpyO3vrfYvxyiiU8VkSVtodr6VFoM0T3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBCDRZgQnFYkq0SOLrmvxpFxQRCdMNhge1Unb77YyuZq7wk85aMwGs/fhx7ekSIUrURBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU2Z0wfN9VTx9JdR4F4pphrEJ0EukYkH0+QwgTkvGReJqS3AA1zi4L4OJ0M18xnuBW/6 592ULW4vfh/b1HrXegYtEg3+oKQu5V7ahFi27iVOuSPoeLWQJ8RtpKK8GNAss9+6elFFgxvixKHD +ndZqoQq0JFb5sY5yvsuaKnQYvhP+274nM+117vLjWiTA8zC3e5qTjAEzQR26Rr0dPOgWImrjs9/ BX0barm2Y4IT1WcBZEH9asyhHPHrk1fOl/Hbtww= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Recommended-Action: accept Archived-At: Cc: 'secdir' , draft-ietf-kitten-krb-auth-indicator.all@ietf.org, kitten@ietf.org, 'IESG' Subject: Re: [kitten] [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 22:34:59 -0000 On Thursday, January 5, 2017 12:40 PM, Nathaniel McCallum wrote: >> What is supposed to happen if the outside Authorization Data type is = set to >> 97 instead of 96? Should that be specified somewhere? The text says: >> >> Authorization data elements of type AD-AUTHENTICATION-INDICATOR = MUST >> be included in an AD-CAMMAC container so that their contents can = be >> verified as originating from the KDC. >> >> That's a fine constraint for the sender, but what about receivers? > > 5. Security Considerations > > ... Application servers MUST validate the AD-CAMMAC container before > making authorization decisions based on AD-AUTHENTICATION-INDICATOR > elements. Application servers MUST NOT make authorization decisions > based on AD-AUTHENTICATION-INDICATOR elements which appear outside = of > AD-CAMMAC containers. ... You are right, and I was confused.=20 As far as I am concerned, the draft is fine and ready for publication. = The "reserved number" section and the additional paragraph in the = security consideration addressed the concerned that I raised in the = initial review. -- Christian Huitema From nobody Mon Jan 16 12:23:29 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2B512965E for ; Mon, 16 Jan 2017 12:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muYoJD_fxRy4 for ; Mon, 16 Jan 2017 12:23:26 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 4CB3612965C for ; Mon, 16 Jan 2017 12:23:26 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id j82so20134796ybg.1 for ; Mon, 16 Jan 2017 12:23:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=MLuQOK2sWzcYx+WJAtRofsCBNLC2m7E/dgmt7GYhPIE=; b=NEpevsbtOEyUpMmo50iSalV1wAB8ayLE4dxej5A8AXYrEwqcpaqG8rRtQK/fa2qHN0 H8QjOS8iWu78cDHeuy/WYzeF2j0mfOVCWGMlF24H2ktjiBteg0O4/3XP9wbDXGGC9yjM NNRsevw5LH1BkOTaQt/nP8CHed3GBPy7eY2MSW7ZOhBSmCiZR2amNb5nEcnj1N8lEw2O QNuk9c/PzlDRcJKYf7z6Jfk0Y3khMuRTSoqD52kYOc7JKG6tJ1sEQ3UiWNnH7s1RfdOa Mgam8Bpq6TnMVbBsW61ldRJCW9hUKTX3LRj1CwCo1zI0pMVkuCYR0HA7lg9REPkGcO3x +7fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=MLuQOK2sWzcYx+WJAtRofsCBNLC2m7E/dgmt7GYhPIE=; b=MKyMrCnMz1c4n7d3XvhOzeYz4Nhrd0lx/xB7xbsJmh9wBJxeAolAYVYYyo43QcXWBp dszGDGiR9wMVAXQ+R5gNTz2zIleJOMB7jyXov65xFG5KbEyBLT0eds24+zSxmBcVcZK3 zeHPgxidWQXSc5jLGtCIx08a7c63q+MjBWh6Cq3oFlcwPb0VTDU8bG58eC6tbJj0zT2A vjH1H5xeKMhnF32eX1bgqNjZ07DUS/PoL2DU5F+WBTobEmQfQ5u3by24SHNP8cooq7nZ 6pe1vKtZQCtAQw0bdNo89ZH8vWD/VD5hTNUdiTinxn7fzy8T1Km3Z0vVsA7QTARvqXBe ixyg== X-Gm-Message-State: AIkVDXJt7HYkjp14+AzezFXgtvNoK95StDHlovFOSMd7GsGJw6g1rPcRZV2JEXHBcoOazdnYYCvVCzgoPUTG5w== X-Received: by 10.37.19.69 with SMTP id 66mr23480282ybt.119.1484598205316; Mon, 16 Jan 2017 12:23:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.48.197 with HTTP; Mon, 16 Jan 2017 12:22:44 -0800 (PST) In-Reply-To: <20161113213909.5397CB80A0A@rfc-editor.org> References: <20161113213909.5397CB80A0A@rfc-editor.org> From: Lars Francke Date: Mon, 16 Jan 2017 21:22:44 +0100 Message-ID: To: kitten@ietf.org Content-Type: multipart/alternative; boundary=001a113e3cdea9877505463bf451 Archived-At: Subject: [kitten] Fwd: [Editorial Errata Reported] RFC4752 (4863) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 20:23:28 -0000 --001a113e3cdea9877505463bf451 Content-Type: text/plain; charset=UTF-8 Hi, I submitted a RFC Errata (see below) for RFC 4752 in November 2016. Stephen Farrell asked me to forward the request to this mailing list for comments and (dis-)approval. It looks like a relatively simple typo. I'm looking forward to comments. Cheers, Lars ---------- Forwarded message ---------- From: RFC Errata System Date: Sun, Nov 13, 2016 at 10:39 PM Subject: [Editorial Errata Reported] RFC4752 (4863) The following errata report has been submitted for RFC4752, "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4752&eid=4863 -------------------------------------- Type: Editorial Reported by: Lars Francke Section: 3.1 - 3.3 Original Text ------------- conf_flag Corrected Text -------------- conf_req_flag Notes ----- The three sections 3.1, 3.2 and 3.3 refer to a flag "conf_flag" which does not exist in the GSS_Wrap call as specified in RFC 2743 ( https://tools.ietf.org/html/rfc2743#page-65). The correct name is "conf_req_flag". I also looked in the previous version of RFC 2743 -> RFC 2078 but the same applies there. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4752 (draft-ietf-sasl-gssapi-08) -------------------------------------- Title : The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism Publication Date : November 2006 Author(s) : A. Melnikov, Ed. Category : PROPOSED STANDARD Source : Simple Authentication and Security Layer Area : Security Stream : IETF Verifying Party : IESG --001a113e3cdea9877505463bf451 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I submitted a RFC Errata (see below= ) for RFC 4752 in November 2016.=C2=A0Stephen Farrell asked me to forward t= he request to this mailing list for comments and (dis-)approval.
=
It looks like a relatively simple typo. I'm looking forw= ard to comments.

Cheers,
Lars
=
---------- Forwarded message ----------
F= rom: RFC Errata System = <rfc-edit= or@rfc-editor.org>
Date: Sun, Nov 13, 2016 at 10:39 PM
= Subject: [Editorial Errata Reported] RFC4752 (4863)


The followin= g errata report has been submitted for RFC4752,
"The Kerberos V5 ("GSSAPI") Simple Authentication and Securi= ty Layer (SASL) Mechanism".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/err= ata_search.php?rfc=3D4752&eid=3D4863

--------------------------------------
Type: Editorial
Reported by: Lars Francke <lars.francke@gmail.com>

Section: 3.1 - 3.3

Original Text
-------------
conf_flag

Corrected Text
--------------
conf_req_flag

Notes
-----
The three sections 3.1, 3.2 and 3.3 refer to a flag "conf_flag" w= hich does not exist in the GSS_Wrap call as specified in RFC 2743 (https://tools.ietf.org/html/rfc2743#page-65). The corr= ect name is "conf_req_flag".

I also looked in the previous version of RFC 2743 -> RFC 2078 but the sa= me applies there.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4752 (draft-ietf-sasl-gssapi-08)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The Kerberos = V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mec= hanism
Publication Date=C2=A0 =C2=A0 : November 2006
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A. Melnikov, Ed.
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Simple Authenticat= ion and Security Layer
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

--001a113e3cdea9877505463bf451-- From nobody Wed Jan 18 16:29:07 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19C4129400 for ; Wed, 18 Jan 2017 16:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUYT9vRC6b78 for ; Wed, 18 Jan 2017 16:29:04 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 1EBDD129444 for ; Wed, 18 Jan 2017 16:29:04 -0800 (PST) X-AuditID: 12074422-21bff70000006f09-a4-5880084d88dc Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 0F.AC.28425.D4800885; Wed, 18 Jan 2017 19:29:02 -0500 (EST) 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 v0J0T16D023518; Wed, 18 Jan 2017 19:29:01 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v0J0SvgD030045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Jan 2017 19:29:00 -0500 Date: Wed, 18 Jan 2017 18:28:57 -0600 From: Benjamin Kaduk To: Lars Francke Message-ID: <20170119002857.GO8460@kduck.kaduk.org> References: <20161113213909.5397CB80A0A@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixG6nruvH0RBh8P2XqMXRzatYLA4vWcJs MX3vNXYHZo+13VfZPHbOusvusWTJT6YA5igum5TUnMyy1CJ9uwSujO9377EWrBWpWLDkNVsD 4y/+LkZODgkBE4lFe58zdzFycQgJtDFJdP3uYIVwNjJK3Hx9nh3CucokcXfdMhaQFhYBVYnt faeZQWw2ARWJhu7LYLaIgKbE65uXWUFsZgE9iat7vjKB2MICrhKzLu0Gi/MKGEtsO3UVrF5I oE5i07vdjBBxQYmTM5+wQPRqSdz49xKolwPIlpZY/o8DJMwpECjRcvAj2BhRAWWJhhkPmCcw CsxC0j0LSfcshO4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE31cjNL9FJTSjcxgkPXRWkH 48R/XocYBTgYlXh4O4rqI4RYE8uKK3MPMUpyMCmJ8l5naIgQ4kvKT6nMSCzOiC8qzUktPsQo wcGsJMKrxwyU401JrKxKLcqHSUlzsCiJ81atqIwQEkhPLEnNTk0tSC2CycpwcChJ8LqzAzUK FqWmp1akZeaUIKSZODhBhvMADfcFqeEtLkjMLc5Mh8ifYlSUEudtYANKCIAkMkrz4HpBqUUi e3/NK0ZxoFeEeaNB2nmAaQmu+xXQYCagwVbK9SCDSxIRUlINjJmlvTIJotv0FvFYiEy/wtDd r/L9sND06TMV7iqrpPqc8+FT3R+0b1qknXLOc0krhZbn7279sJ9gtv/nmrA/vv0X6yXNRdao /p4384wg/83fzIt8VEss1dM6vJWXfFc/9kvc+Gm2zJa5zteXWEpPSmA/rpd79p6y4xNHvbMp IeHpQWX3eq1XKrEUZyQaajEXFScCAJM4o5kIAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: [Editorial Errata Reported] RFC4752 (4863) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 00:29:06 -0000 Yes, it looks like a typo and simple fix; sorry for the slowness in responding. Stephen, kindly mark as verified at your convenience. Thanks, Ben On Mon, Jan 16, 2017 at 09:22:44PM +0100, Lars Francke wrote: > Hi, > > I submitted a RFC Errata (see below) for RFC 4752 in November 2016. Stephen > Farrell asked me to forward the request to this mailing list for comments > and (dis-)approval. > > It looks like a relatively simple typo. I'm looking forward to comments. > > Cheers, > Lars > > ---------- Forwarded message ---------- > From: RFC Errata System > Date: Sun, Nov 13, 2016 at 10:39 PM > Subject: [Editorial Errata Reported] RFC4752 (4863) > > > The following errata report has been submitted for RFC4752, > "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) > Mechanism". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4752&eid=4863 > > -------------------------------------- > Type: Editorial > Reported by: Lars Francke > > Section: 3.1 - 3.3 > > Original Text > ------------- > conf_flag > > Corrected Text > -------------- > conf_req_flag > > Notes > ----- > The three sections 3.1, 3.2 and 3.3 refer to a flag "conf_flag" which does > not exist in the GSS_Wrap call as specified in RFC 2743 ( > https://tools.ietf.org/html/rfc2743#page-65). The correct name is > "conf_req_flag". > > I also looked in the previous version of RFC 2743 -> RFC 2078 but the same > applies there. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4752 (draft-ietf-sasl-gssapi-08) > -------------------------------------- > Title : The Kerberos V5 ("GSSAPI") Simple Authentication and > Security Layer (SASL) Mechanism > Publication Date : November 2006 > Author(s) : A. Melnikov, Ed. > Category : PROPOSED STANDARD > Source : Simple Authentication and Security Layer > Area : Security > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From lars.francke@gmail.com Fri Jan 20 12:15:05 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AE31293F0 for ; Fri, 20 Jan 2017 12:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdM36_tfAY1Z for ; Fri, 20 Jan 2017 12:15:04 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 D229E1293F5 for ; Fri, 20 Jan 2017 12:15:03 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id l23so69514872ybj.2 for ; Fri, 20 Jan 2017 12:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DOT57VjPbFwX416JfBi0qMibEijcuwOVWaBqtiPM1Ow=; b=X6WeQQrkQ8pWG+3fNIYNw2ph7LhohjLNl4eZVcvA87O41JzXAcOIDUGssHU/r1CO2c qJmjsFJ3ogyJFHn1NhXsc+P1PCV26xRrR+rgQLlbhclFbDRWDhzOYOI17XU1o7wS4wjW 1ntRhZ0RbKWsCmV/nfGD8wL3LYF0gv5MDDpwyibic8cq5xi+9iUwZzbtDqpO9S3S+lnW UyxGOmGOgwKczb6RkaKJ8cI6pYpj29lmLdTmhU5mCyxFK/mwnxRXkWEoIXFi3prLi921 YI8fSQ3fHIFqhTHsQ2TZY+3oc0xU2gFoFWiZJpKTDuX1q/TwxAwQLjBA6jFSXCWSi0Vy jhtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DOT57VjPbFwX416JfBi0qMibEijcuwOVWaBqtiPM1Ow=; b=UVnU/f+fTtVUH4x1qN0HzBtbHRU+xJGeIxJxmrnEQSEfg/EaNdvMF7k9SntOvgr6ia Y83mj94E3dOFWgPbI2BvboYg23pvAdvhCqbSp9s+Hf2ojKVlAwvS8dPoGwskV0PxjZis PWNKEk1C33jWyepIzyfmrOyvTKmEgXAM1XD/taG0RG0NPf5ykLCXjOlMH6JsGsJRA7BE LUqOgxbXQgvUzxTD0kzaPSc7z1BY0eTYo/1zagabYgna+rxjp6uo48fRAMrk2jLBLH1M qhWVD79MzSymaap8ldqh2hkVS+AcYvP8eIg48o596JQepMtMKTJ+iklJJLeTXtcpkeIT IG9g== X-Gm-Message-State: AIkVDXK8J5brZYSGhBwdXAJDw+vsNHEMritoCPZfzITCVKXtChMjmbb0bxbUGIiv81o1a4EQVtzTPvGpBvQ4bA== X-Received: by 10.37.19.69 with SMTP id 66mr12996430ybt.119.1484943303050; Fri, 20 Jan 2017 12:15:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.48.197 with HTTP; Fri, 20 Jan 2017 12:14:22 -0800 (PST) In-Reply-To: <20170119002857.GO8460@kduck.kaduk.org> References: <20161113213909.5397CB80A0A@rfc-editor.org> <20170119002857.GO8460@kduck.kaduk.org> From: Lars Francke Date: Fri, 20 Jan 2017 21:14:22 +0100 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a113e3cde170e4a05468c4e73 Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: [Editorial Errata Reported] RFC4752 (4863) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 20:15:06 -0000 --001a113e3cde170e4a05468c4e73 Content-Type: text/plain; charset=UTF-8 Thanks for taking a look Ben and Stephen for verifying. On Thu, Jan 19, 2017 at 1:28 AM, Benjamin Kaduk wrote: > Yes, it looks like a typo and simple fix; sorry for the slowness in > responding. > > Stephen, kindly mark as verified at your convenience. > > Thanks, > > Ben > > On Mon, Jan 16, 2017 at 09:22:44PM +0100, Lars Francke wrote: > > Hi, > > > > I submitted a RFC Errata (see below) for RFC 4752 in November 2016. > Stephen > > Farrell asked me to forward the request to this mailing list for comments > > and (dis-)approval. > > > > It looks like a relatively simple typo. I'm looking forward to comments. > > > > Cheers, > > Lars > > > > ---------- Forwarded message ---------- > > From: RFC Errata System > > Date: Sun, Nov 13, 2016 at 10:39 PM > > Subject: [Editorial Errata Reported] RFC4752 (4863) > > > > > > The following errata report has been submitted for RFC4752, > > "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer > (SASL) > > Mechanism". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4752&eid=4863 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Lars Francke > > > > Section: 3.1 - 3.3 > > > > Original Text > > ------------- > > conf_flag > > > > Corrected Text > > -------------- > > conf_req_flag > > > > Notes > > ----- > > The three sections 3.1, 3.2 and 3.3 refer to a flag "conf_flag" which > does > > not exist in the GSS_Wrap call as specified in RFC 2743 ( > > https://tools.ietf.org/html/rfc2743#page-65). The correct name is > > "conf_req_flag". > > > > I also looked in the previous version of RFC 2743 -> RFC 2078 but the > same > > applies there. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4752 (draft-ietf-sasl-gssapi-08) > > -------------------------------------- > > Title : The Kerberos V5 ("GSSAPI") Simple Authentication > and > > Security Layer (SASL) Mechanism > > Publication Date : November 2006 > > Author(s) : A. Melnikov, Ed. > > Category : PROPOSED STANDARD > > Source : Simple Authentication and Security Layer > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > > --001a113e3cde170e4a05468c4e73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for taking a look Ben and Stephen for verifying.

On Thu, Jan 19= , 2017 at 1:28 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
Yes, it looks like a typo and simple fix; sorry = for the slowness in responding.

Stephen, kindly mark as verified at your convenience.

Thanks,

Ben

On Mon, Jan 16, 2017 at 09:22:44PM +0100, Lars Francke wrote:
> Hi,
>
> I submitted a RFC Errata (see below) for RFC 4752 in November 2016. St= ephen
> Farrell asked me to forward the request to this mailing list for comme= nts
> and (dis-)approval.
>
> It looks like a relatively simple typo. I'm looking forward to com= ments.
>
> Cheers,
> Lars
>
> ---------- Forwarded message ----------
> From: RFC Errata System <rfc-editor@rfc-editor.org>
> Date: Sun, Nov 13, 2016 at 10:39 PM
> Subject: [Editorial Errata Reported] RFC4752 (4863)
>
>
> The following errata report has been submitted for RFC4752,
> "The Kerberos V5 ("GSSAPI") Simple Authentication and S= ecurity Layer (SASL)
> Mechanism".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/= errata_search.php?rfc=3D4752&eid=3D4863
>
> --------------------------------------
> Type: Editorial
> Reported by: Lars Francke <lars.francke@gmail.com>
>
> Section: 3.1 - 3.3
>
> Original Text
> -------------
> conf_flag
>
> Corrected Text
> --------------
> conf_req_flag
>
> Notes
> -----
> The three sections 3.1, 3.2 and 3.3 refer to a flag "conf_flag&qu= ot; which does
> not exist in the GSS_Wrap call as specified in RFC 2743 (
> https://tools.ietf.org/html/rfc2743#page-65= ). The correct name is
> "conf_req_flag".
>
> I also looked in the previous version of RFC 2743 -> RFC 2078 but t= he same
> applies there.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC4752 (draft-ietf-sasl-gssapi-08)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The Kerb= eros V5 ("GSSAPI") Simple Authentication and
> Security Layer (SASL) Mechanism
> Publication Date=C2=A0 =C2=A0 : November 2006
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A. Melnikov, Ed. > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Simple Authen= tication and Security Layer
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security=
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten


--001a113e3cde170e4a05468c4e73-- From nobody Mon Jan 23 08:57:09 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A726912959A; Mon, 23 Jan 2017 08:57:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148519062764.29562.14436143550538746567.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2017 08:57:07 -0800 Archived-At: Cc: kitten@ietf.org, draft-ietf-kitten-krb-auth-indicator.all@ietf.org, ietf@ietf.org Subject: [kitten] Review of draft-ietf-kitten-krb-auth-indicator-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 16:57:07 -0000 Reviewer: Robert Sparks Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-kitten-krb-auth-indicator-06 Reviewer: Robert Sparks Review Date: 2017-01-23 IETF LC End Date: 2017-01-06 IESG Telechat date: 2017-02-02 Summary: Ready for publication as Proposed Standard Thanks for addressing my comments From nobody Tue Jan 24 18:12:53 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7F2129608 for ; Tue, 24 Jan 2017 18:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMuLL9AB8iAJ for ; Tue, 24 Jan 2017 18:12:50 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 A4E38129606 for ; Tue, 24 Jan 2017 18:12:50 -0800 (PST) X-AuditID: 1209190d-10fff70000005a52-e1-588809a08081 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id C4.4A.23122.0A908885; Tue, 24 Jan 2017 21:12:49 -0500 (EST) 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 v0P2CmMT017682 for ; Tue, 24 Jan 2017 21:12:48 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v0P2Cje6024502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 24 Jan 2017 21:12:47 -0500 Date: Tue, 24 Jan 2017 20:12:45 -0600 From: Benjamin Kaduk To: kitten@ietf.org Message-ID: <20170125021244.GH8460@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixG6nrruQsyPC4FuXvMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMffWUdaCuSwVk/o3MjcwHmLuYuTkkBAwkVjac5ypi5GLQ0ig jUniz/JFrBDOcUaJ/2s2MkI4r5kkZq6+yQbSwiKgKvGi8xgriM0moCLR0H0ZbJSIgLDE7q3v wGxhAXeJB3Nawep5BYwlpj+fzghhC0qcnPmEBcRmFtCSuPHvJdBqDiBbWmL5Pw6QsKiAskTD jAfMExh5ZyHpmIWkYxZCxwJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6Rnq5mSV6qSmlmxhB ocQpybuD8d9dr0OMAhyMSjy8L1LaI4RYE8uKK3MPMUpyMCmJ8l6+CBTiS8pPqcxILM6ILyrN SS0+xCjBwawkwruWpSNCiDclsbIqtSgfJiXNwaIkziuu0RghJJCeWJKanZpakFoEk5Xh4FCS 4E3gAGoULEpNT61Iy8wpQUgzcXCCDOcBGr4HpIa3uCAxtzgzHSJ/ilGX49SnCy+ZhFjy8vNS pcR5XUGKBECKMkrz4OaAUoBE9v6aV4ziQG8J86qBVPEA0wfcpFdAS5iAllxgbgdZUpKIkJJq YNx+6sQGNY2D9Wuz9+VaTcyxNTuxq1nZ1z53dfy1WaYB7pOuCzv+s9O6VKk8bcn76AXu06S/ PX1pxRktw5XzqmwC/4RLkgH/P7Wvvif/LeRR1CPR3D9vwtq8StvLSr4+Wtv7/46ww7PE0mUM tgsUvY7e8HuXdqZJkrnD2Wo723Tx5sZbJjoHniuxFGckGmoxFxUnAgCONCpu3AIAAA== Archived-At: Subject: [kitten] Call for adoption: draft-mccallum-kitten-krb-service-discovery X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 02:12:52 -0000 Hi all, This message begins a two-week call for adoption of draft-mccallum-kitten-krb-service-discovery (the current version of which is https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-03). Though to some extent the document is documenting an existing deployment, there may be value to be gained from having WG approval of a mechanism perceived as a general improvement to the kerberos protocol. Please send messages of support, opposition, and other comments to the WG list. For the chairs, Ben From nobody Fri Jan 27 09:18:10 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8810812969B for ; Fri, 27 Jan 2017 09:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk9SIyafjZRD for ; Fri, 27 Jan 2017 09:18:02 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A834812944D for ; Fri, 27 Jan 2017 09:18:00 -0800 (PST) X-AuditID: 12074423-efbff7000000167a-03-588b80c6af14 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 01.81.05754.6C08B885; Fri, 27 Jan 2017 12:17:59 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v0RHHwkr019123 for ; Fri, 27 Jan 2017 12:17:58 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v0RHHt72032118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 27 Jan 2017 12:17:57 -0500 Date: Fri, 27 Jan 2017 11:17:55 -0600 From: Benjamin Kaduk To: kitten@ietf.org Message-ID: <20170127171754.GR8460@kduck.kaduk.org> References: <20170125021244.GH8460@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170125021244.GH8460@kduck.kaduk.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUixG6nonu8oTvCYOUOPoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro7nlMFvBdNaKJTuXsTcwzmfpYuTkkBAwkWj8fpUdxBYSaGOS OPzYu4uRC8g+zijxpOclM4TzGiixeypTFyMHB4uAqsSui3EgDWwCKhIN3ZeZQWwRAWGJ3Vvf MYOUCAuESSx+JAAS5hUwllg+5SMbxHxjiXsvbzJDxAUlTs58AnYDs4CWxI1/L8GmMwtISyz/ xwES5gQ6bf69V2AlogLKEg0zHjBPYOSfhaR7FpLuWQjdCxiZVzHKpuRW6eYmZuYUpybrFicn 5uWlFuma6eVmluilppRuYgQHnYvyDsaXfd6HGAU4GJV4eDVyuiOEWBPLiitzDzFKcjApifJy WwCF+JLyUyozEosz4otKc1KLDzFKcDArifCurAHK8aYkVlalFuXDpKQ5WJTEecU1GiOEBNIT S1KzU1MLUotgsjIcHEoSvOn1QI2CRanpqRVpmTklCGkmDk6Q4TxAw7VBaniLCxJzizPTIfKn GHU5Tn268JJJiCUvPy9VSpw3CqRIAKQoozQPbg4oWUhk7695xSgO9JYwrwdIFQ8w0cBNegW0 hAloifiPLpAlJYkIKakGxrDXPfbSWrslPEP+LctVs6la/q1JPHyF2qknucZ7T0QY/uz+Kbgs fsqUyOrPV3vYb9Y+f7KqR/oh8yr9Wv94E7t1u/tZvk2YuHFK4iamd/M4m80OXPvrJ1Ic/13G 342tqvTVlYC8qJ7uyzNnGDZ6pwYKM1xdIH8k9tzZF2/KPN9YLmoJmvjYQ4mlOCPRUIu5qDgR AEMldqjxAgAA Archived-At: Subject: Re: [kitten] Call for adoption: draft-mccallum-kitten-krb-service-discovery X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 17:18:08 -0000 On Tue, Jan 24, 2017 at 08:12:45PM -0600, Benjamin Kaduk wrote: > Hi all, > > This message begins a two-week call for adoption of > draft-mccallum-kitten-krb-service-discovery (the current version of which is > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-03). > > Though to some extent the document is documenting an existing deployment, > there may be value to be gained from having WG approval of a mechanism > perceived as a general improvement to the kerberos protocol. > > Please send messages of support, opposition, and other comments to the > WG list. With no hats, I support adopting this document. -Ben From nobody Mon Jan 30 16:27:24 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B095A129706 for ; Mon, 30 Jan 2017 16:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmMd_RW6cA_4 for ; Mon, 30 Jan 2017 16:27:22 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 6D1DD12970F for ; Mon, 30 Jan 2017 16:27:21 -0800 (PST) X-AuditID: 1209190d-19fff700000061f6-ad-588fd9e8eaf0 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id B3.A1.25078.8E9DF885; Mon, 30 Jan 2017 19:27:20 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v0V0RJQ8018252 for ; Mon, 30 Jan 2017 19:27:20 -0500 Received: from [18.101.8.159] (vpn-18-101-8-159.mit.edu [18.101.8.159]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v0V0RIkP015540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 30 Jan 2017 19:27:19 -0500 To: kitten@ietf.org References: <20170125021244.GH8460@kduck.kaduk.org> From: Greg Hudson Message-ID: Date: Mon, 30 Jan 2017 19:27:17 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170125021244.GH8460@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixG6novviZn+EwYGbchZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpkVv9gLVjNV/Lp2kaWBsYWpi5GDQ0LARGLegdwuRk4OIYE2 Joltixi7GLmA7OOMEkdOPWKFcG4zSXzvOQPWICwQJrH4kQBIg4iAsMTure+YIZqNJe69vAlm swkoS6zfv5UFxOYVsJJ42beJCcRmEVCVWNA9ixVkjKhAhETD4XSIEkGJkzOfgJVzAp0z/94r MJtZQE9ix/VfrBC2vMT2t3OYJzDyz0LSMgtJ2SwkZQsYmVcxyqbkVunmJmbmFKcm6xYnJ+bl pRbpGunlZpbopaaUbmIEhR2nJO8Oxn93vQ4xCnAwKvHwarT1RwixJpYVV+YeYpTkYFIS5WWd AhTiS8pPqcxILM6ILyrNSS0+xCjBwawkwrvnBlCONyWxsiq1KB8mJc3BoiTOK67RGCEkkJ5Y kpqdmlqQWgSTleHgUJLgXQDSKFiUmp5akZaZU4KQZuLgBBnOAzT8MNjw4oLE3OLMdIj8KUZd jlOfLrxkEmLJy89LlRLnvQdSJABSlFGaBzcHnC5SOea/YhQHekuYNx6kigeYauAmvQJawgS0 xP1VH8iSkkSElFQDY8aeXxsvMb5bLtQvJ58ju+zrz133Jp5S8aljiNqj4Lbn9rbnzTHh+/je aCc9MbB6b5XKaROk/lP6pN+plld/P+lfUNW6VZQm68DVe/7oxFCTVoU3f9W2OzfHV1kkfqq7 uTzGkY13mWSp7gP5dw/cHxWU5pVtviC9fOIxr6rNRWw7nremazGdU2Ipzkg01GIuKk4EAGmJ HwHyAgAA Archived-At: Subject: Re: [kitten] Call for adoption: draft-mccallum-kitten-krb-service-discovery X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 00:27:23 -0000 On 01/24/2017 09:12 PM, Benjamin Kaduk wrote: > This message begins a two-week call for adoption of > draft-mccallum-kitten-krb-service-discovery (the current version of which is > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-03). I support adopting this document. From nobody Tue Jan 31 14:56:39 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A969129BF5 for ; Tue, 31 Jan 2017 14:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2T7eBIwJyoX for ; Tue, 31 Jan 2017 14:56:36 -0800 (PST) Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com [209.85.216.171]) (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 E914B129642 for ; Tue, 31 Jan 2017 14:56:35 -0800 (PST) Received: by mail-qt0-f171.google.com with SMTP id v23so248594890qtb.0 for ; Tue, 31 Jan 2017 14:56:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=s1BAa1FWmWC58ITW7U6IXcwT+O81XV4bXoqH48E6a6I=; b=HwR/fFIrvhQxPvk4evS6gKciRLXXQYb7KHmV/IWWoVx+d0MLA4cFlaGBAv+mhGlrEL g0lDYETzab+tecj+AnWFsOrmyMt932g2MA8BCzgHUr1Bj5cuW8tbot9sEMMTNM3sE5Lg tNtB/Ykk2Vy9cQ+/+kNXoFC6l4Gp6AkKTTIXqxAvaFe85sa7ZO3+YQ/4C3YHZqI4TkJj InPz4or5i8jl3gNSpcBsbtyyHTutMZzmPZLjKsuBHBh1j5AcyjJqFSh+qVjqI7x3RcUI YFuzvbnsu9Jm9EcrhNlOIgzsp2OC1Ozkk9UX8Q6VqNhkAl/SXMFZ/1IZ06rqLMFnvOW0 eO2g== X-Gm-Message-State: AIkVDXKFrZvNtz+Tmc+2NyY+MzIErEOTDWue71L0bKQmt+mWI39mXl2U/NJRGTxjVgLB0RWxM5pycKXde6fQ2Usd X-Received: by 10.200.43.201 with SMTP id n9mr29637656qtn.243.1485903394641; Tue, 31 Jan 2017 14:56:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.168.220 with HTTP; Tue, 31 Jan 2017 14:56:04 -0800 (PST) From: Matt Rogers Date: Tue, 31 Jan 2017 17:56:04 -0500 Message-ID: To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] advancing some documents to the IESG X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 22:56:37 -0000 >Benjamin Kaduk Wed, 31 August 2016 01:51 UTC > >In other PKINIT-related work, the most recent threads the chairs have >about draft-ietf-kitten-pkinit-alg-agility indicate that it should also be >ready to advance, but given how long ago they were, some additional >research is in order to verify that. More (re-)reviews wouldn't hurt, >either! I=E2=80=99ve looked over draft-ietf-kitten-pkinit-alg-agility-00 and it appears to resolve all the items from the most recent thread (https://www.ietf.org/mail-archive/web/kitten/current/msg05133.html). No issues from me. Regards, Matt From nobody Tue Jan 31 16:41:44 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD3212969C for ; Tue, 31 Jan 2017 16:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH9RKJcAPRoM for ; Tue, 31 Jan 2017 16:41:41 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945AD12965D for ; Tue, 31 Jan 2017 16:41:41 -0800 (PST) X-AuditID: 1209190c-a3fff700000078b4-e4-58912ec39652 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F7.49.30900.3CE21985; Tue, 31 Jan 2017 19:41:40 -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 v110fdAc008880 for ; Tue, 31 Jan 2017 19:41:39 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v110faRJ014641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 31 Jan 2017 19:41:38 -0500 Date: Tue, 31 Jan 2017 18:41:36 -0600 From: Benjamin Kaduk To: kitten@ietf.org Message-ID: <20170201004135.GL8460@kduck.kaduk.org> References: <20170125021244.GH8460@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170125021244.GH8460@kduck.kaduk.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixCmqrXtEb2KEwZvVIhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxowp81gKrrFVPG4+wNrAuIe1i5GTQ0LARGLv+kfMILaQQBuT xOXTcV2MXED2cUaJ1q4r7BDOayaJCU0TGLsYOThYBFQl9v8PAGlgE1CRaOi+DNYsIiAssXvr OzBbWCBJYnXPFRYQm1fAWGLvkwZWiAXGEvde3mSGiAtKnJz5BKyGWUBL4sa/l0wg45kFpCWW /+MACXMC3Tb/3iuwElEBZYmGGQ+YJzDyz0LSPQtJ9yyE7gWMzKsYZVNyq3RzEzNzilOTdYuT E/PyUot0DfVyM0v0UlNKNzGCw06SZwfjmTdehxgFOBiVeHg/nJ4QIcSaWFZcmXuIUZKDSUmU N70DKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE97H6xAgh3pTEyqrUonyYlDQHi5I4r4RGY4SQ QHpiSWp2ampBahFMVoaDQ0mClxMYX0KCRanpqRVpmTklCGkmDk6Q4TxAw/VAaniLCxJzizPT IfKnGHU5Tn268JJJiCUvPy9VSpw3TxeoSACkKKM0D24OKF1IZO+vecUoDvSWMK8LSBUPMNXA TXoFtIQJaIn7qz6QJSWJCCmpBsaN6mWmBradcX3OITcZH67PipnKUz1zVyxf/8flOqe74x2U hB5/nNQifM/4u/XxqHN3G05s7DY1+u7UF/Tv74Fn0h05FzueiHdoejFP5LgtWCz0+p+NZc0v Rs9f/8sfxRTMnWh0JK6S7eREd8MDHZcqkrb8fPSy/er2PsH8f+kszdZ33S/UhCmxFGckGmox FxUnAgBXE5LJ8gIAAA== Archived-At: Subject: Re: [kitten] FINAL WEEK: Call for adoption: draft-mccallum-kitten-krb-service-discovery X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 00:41:42 -0000 Reminder: there is one week left in this call for adoption. -Ben On Tue, Jan 24, 2017 at 08:12:45PM -0600, Benjamin Kaduk wrote: > Hi all, > > This message begins a two-week call for adoption of > draft-mccallum-kitten-krb-service-discovery (the current version of which is > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-03). > > Though to some extent the document is documenting an existing deployment, > there may be value to be gained from having WG approval of a mechanism > perceived as a general improvement to the kerberos protocol. > > Please send messages of support, opposition, and other comments to the > WG list. > > For the chairs, > > Ben > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Tue Jan 31 23:00:33 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3162E129961 for ; Tue, 31 Jan 2017 23:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKZ5lfluNCd0 for ; Tue, 31 Jan 2017 23:00:30 -0800 (PST) Received: from mail-it0-f48.google.com (mail-it0-f48.google.com [209.85.214.48]) (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 BA4BC1293F2 for ; Tue, 31 Jan 2017 23:00:30 -0800 (PST) Received: by mail-it0-f48.google.com with SMTP id r185so11473561ita.0 for ; Tue, 31 Jan 2017 23:00:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ProZ+RMMo06BQ7i7EzY2WXF2ETyuTIuTyVCfdsQRBpM=; b=MIsSDlBOidlHF3NU5bzFCfw/HLkU2z6Hi0KxKZxYr80yHsAYR+Tq2HsBMqJ5+QnIgZ jgZAqziNHbeLg7+qmS+6gjipvsQZiWiqjF2/3yQwKlsIYIWT8VY669ka1VBrtLabI/4R aH2tGu/pXFmqfXWtJzLD7Qy99WFAO9fVVC7YGPpWwPhE3aqOqFIeIXY5pD7pZpE5Jrxk phRIy8twd4XbdPL8hj51BIXwAGuhYB1zuSD13KTwIEjgkEEo19MlDit2nvAcsLS53Nd2 ENQv6TBp9nF/e4fyaEQ0Zo0qLs5apPI4lCEUQEvBhqGFxS+x3XB5ToeeiCJfCUnP57G/ 068g== X-Gm-Message-State: AIkVDXIed3F+R2rknjN1wiseKKaSz984R5lNczuLg2O9qow8WfE5BzkLeb0lLmt4FhGwUgk6MFaLGcDqd9Luyk9u X-Received: by 10.36.254.66 with SMTP id w63mr23512889ith.28.1485932429952; Tue, 31 Jan 2017 23:00:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.179.196 with HTTP; Tue, 31 Jan 2017 23:00:29 -0800 (PST) Received: by 10.107.179.196 with HTTP; Tue, 31 Jan 2017 23:00:29 -0800 (PST) In-Reply-To: <20170125021244.GH8460@kduck.kaduk.org> References: <20170125021244.GH8460@kduck.kaduk.org> From: Nathaniel McCallum Date: Wed, 1 Feb 2017 08:00:29 +0100 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=94eb2c030bc6a61c9d0547729a00 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Call for adoption: draft-mccallum-kitten-krb-service-discovery X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 07:00:32 -0000 --94eb2c030bc6a61c9d0547729a00 Content-Type: text/plain; charset=UTF-8 As an author of the draft, I support its adoption. On Jan 25, 2017 3:12 AM, "Benjamin Kaduk" wrote: > Hi all, > > This message begins a two-week call for adoption of > draft-mccallum-kitten-krb-service-discovery (the current version of which > is > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-03 > ). > > Though to some extent the document is documenting an existing deployment, > there may be value to be gained from having WG approval of a mechanism > perceived as a general improvement to the kerberos protocol. > > Please send messages of support, opposition, and other comments to the > WG list. > > For the chairs, > > Ben > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --94eb2c030bc6a61c9d0547729a00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As an author of the draft, I support its adoption.
<= div class=3D"gmail_extra">
On Jan 25, 2017 3:= 12 AM, "Benjamin Kaduk" <kadu= k@mit.edu> wrote:
Hi all,

This message begins a two-week call for adoption of
draft-mccallum-kitten-krb-service-discovery (the current version of wh= ich is
https://tools.ietf.org/htm= l/draft-mccallum-kitten-krb-service-discovery-03).

Though to some extent the document is documenting an existing deployment, there may be value to be gained from having WG approval of a mechanism
perceived as a general improvement to the kerberos protocol.

Please send messages of support, opposition, and other comments to the
WG list.

For the chairs,

Ben

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
--94eb2c030bc6a61c9d0547729a00--