From nico@cryptonector.com Sat Feb 1 10:36:38 2014 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 AF7E01A05DE for ; Sat, 1 Feb 2014 10:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 BrC0ydn0gczs for ; Sat, 1 Feb 2014 10:36:37 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id B09E11A044C for ; Sat, 1 Feb 2014 10:36:37 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 6518D778061 for ; Sat, 1 Feb 2014 10:36:33 -0800 (PST) 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=I+PILDdSn4Li7EA3wQCP g71JAPM=; b=UKe/MMvjs80ylwcDbZBKDJjs/OUhSYu1+vNoLNG+c6gIwYqiWIzF IrUEGKm8/SK0FhJC1f7CM527u1QGy3bsLlE86kwYe8bU1UOFYKs8WUsgQu7YaANw sQq7xLiST0lkqrGBAYo+/6J8UktKsDwAcPTjarLfu/vZHfUuCmV4xNE= Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 10BC777805F for ; Sat, 1 Feb 2014 10:36:32 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id x55so760667wes.4 for ; Sat, 01 Feb 2014 10:36:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mc4XTPeUFL0YlBA5EEdZPsw+S6TSmWakjBbH6eWvBrM=; b=m6g1BFYnjXnysaIYrPZ/gO2n0lX5RYV3MB4g7XSuukhmpAJf7ngk+WnrdOMzCBBhXk a4vEPhxPAfSbgIOfaqoth+cFdWeL7FP/GCbjgVStTpqcy/i93ZTaHBWBIY+JS4jPC/+L l+4ToCh+kYlvY+YHuTY3qK1LP59GX+DvGc6K+cCn34V7OReEy8Weaqfra6eOdGviP6ec KpALg2WVtnBhYQIMxXOV3tqMTcHYQbcronrnwefthKmwozLPdJ6znyWwHrhkvzPNIxrz FlmQ18RJIZrNjIt8W1qsWdhmIexREsbh35mRj48Bs0HQ0GOklBmgRNgntiIoeppUYD31 McpQ== MIME-Version: 1.0 X-Received: by 10.180.72.195 with SMTP id f3mr3121734wiv.61.1391279791095; Sat, 01 Feb 2014 10:36:31 -0800 (PST) Received: by 10.227.198.69 with HTTP; Sat, 1 Feb 2014 10:36:31 -0800 (PST) In-Reply-To: <22979F1F-33E3-4073-88EF-A491965B01B7@padl.com> References: <22979F1F-33E3-4073-88EF-A491965B01B7@padl.com> Date: Sat, 1 Feb 2014 12:36:31 -0600 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , =?UTF-8?B?TG92ZSBIw7ZybnF1aXN0IMOFc3RyYW5k?= Subject: Re: [kitten] CredUI 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, 01 Feb 2014 18:36:38 -0000 On Fri, Jan 31, 2014 at 8:06 PM, Luke Howard wrote: > * an API/SPI to acquire a credential given an arbitrary dictionary (currently we implemented this using gss_set_cred_option(), as that can output a credential, but a new entry point would be cleaner) You want gss_acquire_cred_from(). http://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions From ghudson@mit.edu Sat Feb 1 11:58:35 2014 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 4C09B1A05E9 for ; Sat, 1 Feb 2014 11:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, 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 GbSwXwKKoXkt for ; Sat, 1 Feb 2014 11:58:34 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id D7EAA1A0604 for ; Sat, 1 Feb 2014 11:58:33 -0800 (PST) X-AuditID: 1209190e-f79ee6d000000c40-d6-52ed51e564e7 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 55.90.03136.5E15DE25; Sat, 1 Feb 2014 14:58:29 -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 s11JwRGn031506; Sat, 1 Feb 2014 14:58:28 -0500 Received: from [18.101.8.250] (vpn-18-101-8-250.mit.edu [18.101.8.250]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s11JwN6j030998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Feb 2014 14:58:26 -0500 Message-ID: <52ED51DF.9030702@mit.edu> Date: Sat, 01 Feb 2014 14:58:23 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nico Williams , Luke Howard References: <22979F1F-33E3-4073-88EF-A491965B01B7@padl.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixG6nrvs08G2Qwb1TMhZHN69isZi2dR+7 xd1L/9ktTl07wubA4vHy1DlGj2OfrzB6LFnyk8lj7odpLAEsUVw2Kak5mWWpRfp2CVwZD67P Zil4z1Zx5YZbA+Mj1i5GTg4JAROJqRNfMUPYYhIX7q1n62Lk4hASmM0kcbx/DyuEs4FRYuG6 eUwQzmEmiYn3HjKCtPAKqEksnf4TbBSLgKrEtQtn2EBsNgFliYNnv7GA2KICYRJ3/6+FqheU ODnzCVhcRMBdYtOZCWD1zAL1Eov+NYDVCAvISBw6sBRqcwOjxKtt98EWcAoESlzv+8QOcauk xLZFx9ghmnUk3vU9YIaw5SW2v53DPIFRaBaSfbOQlM1CUraAkXkVo2xKbpVubmJmTnFqsm5x cmJeXmqRrrFebmaJXmpK6SZGUAxwSvLtYPx6UOkQowAHoxIP7wTft0FCrIllxZW5hxglOZiU RHn7QEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeP3UgXK8KYmVValF+TApaQ4WJXHexBlvgoQE 0hNLUrNTUwtSi2CyMhwcShK8SsBYFxIsSk1PrUjLzClBSDNxcIIM5wEaLgRSw1tckJhbnJkO kT/FqCglzrs5ACghAJLIKM2D64WlqFeM4kCvCPP+BqniAaY3uO5XQIOZgAb3HHgNMrgkESEl 1cCoMl3ydPjZ9S/6f/MwxEdO27fG6Gpk7/9tc/58kvqzXGpXgexcmbdJW6IelL1XmZhsujn1 I+vb/MNnTx7VE6haclKqilcxjHf2Gz7bu+wv/3S6X2XlLmtMvvo76MzVi9+tgiK+KzVVd2b4 slT/Forn4OhSfhe3lPdg5NSP2vlaknMDJv7sXcOsxFKckWioxVxUnAgAO3gqJCwDAAA= Cc: "kitten@ietf.org" , =?ISO-8859-1?Q?Love_H=F6rnquis?= =?ISO-8859-1?Q?t_=C5strand?= Subject: Re: [kitten] CredUI 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, 01 Feb 2014 19:58:35 -0000 On 02/01/2014 01:36 PM, Nico Williams wrote: > On Fri, Jan 31, 2014 at 8:06 PM, Luke Howard wrote: >> * an API/SPI to acquire a credential given an arbitrary dictionary (currently we implemented this using gss_set_cred_option(), as that can output a credential, but a new entry point would be cleaner) > > You want gss_acquire_cred_from(). > > http://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions I believe the consensus at the time was that gss_key_value_set_desc could be used for answers to authentication questions, but the cred_store parameter to gss_acquire_cred_from cannot. See: http://mailman.mit.edu/pipermail/krbdev/2012-July/011105.html IIRC Nico or Sam had some ideas on what an initial cred acquisition API might look like (given that it's not just gss_acquire_cred_from), but I can't seem to find a writeup. From lukeh@padl.com Sun Feb 2 17:56:03 2014 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 826601A0159 for ; Sun, 2 Feb 2014 17:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 3Yve4c1WNMpz for ; Sun, 2 Feb 2014 17:56:02 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id CBFC71A0155 for ; Sun, 2 Feb 2014 17:56:01 -0800 (PST) Received: by us.padl.com with ESMTP id s131tZxf031915; Sun, 2 Feb 2014 20:55:45 -0500 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Luke Howard In-Reply-To: <52ED51DF.9030702@mit.edu> Date: Mon, 3 Feb 2014 12:55:34 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22979F1F-33E3-4073-88EF-A491965B01B7@padl.com> <52ED51DF.9030702@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.1822) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.8 Cc: "kitten@ietf.org" , =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= Subject: Re: [kitten] CredUI 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, 03 Feb 2014 01:56:03 -0000 On 2 Feb 2014, at 6:58 am, Greg Hudson wrote: > On 02/01/2014 01:36 PM, Nico Williams wrote: >> On Fri, Jan 31, 2014 at 8:06 PM, Luke Howard wrote: >>> * an API/SPI to acquire a credential given an arbitrary dictionary = (currently we implemented this using gss_set_cred_option(), as that can = output a credential, but a new entry point would be cleaner) >>=20 >> You want gss_acquire_cred_from(). >>=20 >> http://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions >=20 > I believe the consensus at the time was that gss_key_value_set_desc > could be used for answers to authentication questions, but the > cred_store parameter to gss_acquire_cred_from cannot. See: >=20 > http://mailman.mit.edu/pipermail/krbdev/2012-July/011105.html >=20 > IIRC Nico or Sam had some ideas on what an initial cred acquisition = API > might look like (given that it's not just gss_acquire_cred_from), but = I > can't seem to find a writeup. At least we have gss_const_key_value_set_t, even if we use a new API (as = mentioned earlier, it could also be gss_set_cred_option with a well = known OID). -- Luke= From wwwrun@rfc-editor.org Wed Feb 12 08:12:40 2014 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 C2A5B1A05E1 for ; Wed, 12 Feb 2014 08:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_81=0.6, RP_MATCHES_RCVD=-0.548, 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 bgR4FANj00jp for ; Wed, 12 Feb 2014 08:12:38 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id D791F1A0335 for ; Wed, 12 Feb 2014 08:12:37 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EAC757FC3B6; Wed, 12 Feb 2014 08:12:36 -0800 (PST) To: Nicolas.Williams@sun.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, shawn.emery@oracle.com, josh.howlett@ja.net, hartmans-ietf@mit.edu From: RFC Errata System Message-Id: <20140212161236.EAC757FC3B6@rfc-editor.org> Date: Wed, 12 Feb 2014 08:12:36 -0800 (PST) Cc: kitten@ietf.org, rfc-editor@rfc-editor.org Subject: [kitten] [Technical Errata Reported] RFC4402 (3888) 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, 12 Feb 2014 16:12:40 -0000 The following errata report has been submitted for RFC4402, "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4402&eid=3888 -------------------------------------- Type: Technical Reported by: Benjamin Kaduk Section: 2 Original Text ------------- PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn) Corrected Text -------------- PRF+(K, L, S) = truncate(L, T0 || T1 || .. || Tn) Notes ----- Implementors have started the counter for the PRF+ construction at 0, not 1. Instructions: ------------- This errata 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4402 (draft-ietf-kitten-krb5-gssapi-prf-04) -------------------------------------- Title : A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism Publication Date : February 2006 Author(s) : N. Williams Category : PROPOSED STANDARD Source : Kitten (GSS-API Next Generation) Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Feb 14 07:32:02 2014 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 CDBB41A02BA; Fri, 14 Feb 2014 07:31:54 -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 pM2yZs-OUfQ9; Fri, 14 Feb 2014 07:31:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3C21A02AC; Fri, 14 Feb 2014 07:31:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214153152.6941.44556.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 07:31:52 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Pb-CAo0wsAkvbebaGCcPSdTG1WM Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-13.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: Fri, 14 Feb 2014 15:31:55 -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 : A set of SASL Mechanisms for OAuth Authors : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-13.txt Pages : 19 Date : 2014-02-14 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP- based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-13 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 Fri Feb 14 13:45:35 2014 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 DF5581A0423; Fri, 14 Feb 2014 13:45:31 -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 YyD72EIsAfaG; Fri, 14 Feb 2014 13:45:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 847DD1A040E; Fri, 14 Feb 2014 13:45:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214214526.22958.30728.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 13:45:26 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/uPQadgKQJvO7l8zS3qXSYFrvMuM Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-iakerb-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: Fri, 14 Feb 2014 21:45:32 -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 : Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB) Authors : Jim Schaad Larry Zhu Jeffery Altman Filename : draft-ietf-kitten-iakerb-01.txt Pages : 11 Date : 2014-02-14 Abstract: This document defines extensions to the Kerberos protocol and the GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to exchange messages with the KDC using the GSS-API acceptor as the proxy, by encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-iakerb/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-iakerb-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-iakerb-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 Fri Feb 14 15:25:49 2014 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 60D3B1A04C5; Fri, 14 Feb 2014 15:25:48 -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 1MdL3kgcDOag; Fri, 14 Feb 2014 15:25:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EED1A04D5; Fri, 14 Feb 2014 15:25:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214232545.20507.78561.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:25:45 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/wp8SGr-sYMo1X4ZIQcIWr-xw_R8 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-kerberos-iana-registries-03.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: Fri, 14 Feb 2014 23:25:48 -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 : Move Kerberos protocol parameter registries to IANA Author : Tom Yu Filename : draft-ietf-kitten-kerberos-iana-registries-03.txt Pages : 8 Date : 2014-02-14 Abstract: The Keberos 5 network authentication protocol has several numeric protocol parameters. Most of these parameters are not currently under IANA maintenance. This document requests that IANA take over the maintenance of the remainder of these Kerberos parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-kerberos-iana-registries/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-kerberos-iana-registries-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-kerberos-iana-registries-03 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 Fri Feb 14 15:47:32 2014 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 C9C5F1A0517 for ; Fri, 14 Feb 2014 15:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 VbvUNI_ETEWz for ; Fri, 14 Feb 2014 15:47:19 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 948051A0519 for ; Fri, 14 Feb 2014 15:47:19 -0800 (PST) Received: from mail195-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Fri, 14 Feb 2014 23:47:17 +0000 Received: from mail195-tx2 (localhost [127.0.0.1]) by mail195-tx2-R.bigfish.com (Postfix) with ESMTP id 8F34D2C0394 for ; Fri, 14 Feb 2014 23:47:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:199.135.140.18; KIP:(null); UIP:(null); IPV:NLI; H:mail.usda.gov; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zzzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1f96jzzz2fh109h2a8h839h8e3h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h21a6h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received-SPF: pass (mail195-tx2: domain of fs.fed.us designates 199.135.140.18 as permitted sender) client-ip=199.135.140.18; envelope-from=bnordgren@fs.fed.us; helo=mail.usda.gov ; ail.usda.gov ; Received: from mail195-tx2 (localhost.localdomain [127.0.0.1]) by mail195-tx2 (MessageSwitch) id 1392421636203681_17757; Fri, 14 Feb 2014 23:47:16 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.253]) by mail195-tx2.bigfish.com (Postfix) with ESMTP id 2C1C560062 for ; Fri, 14 Feb 2014 23:47:16 +0000 (UTC) Received: from mail.usda.gov (199.135.140.18) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Feb 2014 23:47:16 +0000 Received: from 001FSN2MMR1-014.001f.mgd2.msft.net (199.135.140.69) by 001FSN2MMR1-008.001f.mgd2.msft.net (199.135.140.18) with Microsoft SMTP Server (TLS) id 14.3.174.2; Fri, 14 Feb 2014 23:47:14 +0000 Received: from 001FSN2MPN1-045.001f.mgd2.msft.net ([169.254.5.105]) by 001FSN2MMR1-014.001f.mgd2.msft.net ([199.135.140.69]) with mapi id 14.03.0174.002; Fri, 14 Feb 2014 23:47:14 +0000 From: "Nordgren, Bryce L -FS" To: "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-iakerb-01.txt Thread-Index: AQHPKc4cm+IW3OJF6UmZF4IrjmPqZpq1YLmQ Date: Fri, 14 Feb 2014 23:47:13 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E68DE37@001FSN2MPN1-045.001f.mgd2.msft.net> References: <20140214214526.22958.30728.idtracker@ietfa.amsl.com> In-Reply-To: <20140214214526.22958.30728.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.26.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fs.fed.us X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/khTqK-8MNqNngSkrlakY93Rn8MQ Subject: Re: [kitten] I-D Action: draft-ietf-kitten-iakerb-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, 14 Feb 2014 23:47:25 -0000 > For example, in remote access scenarios, the client must initially > authenticate to an access point in order to gain full access to the netwo= rk. > Here the client may be unable to directly contact the KDC either because = it > does not have an IP address, or the access point packet filter does > not allow the client to send packets to the Internet before it > authenticates to the access point. "Remote access" to me means "outside the firewall of the organization opera= ting the KDC, which is not exposed to the public internet." What you appear= to be talking about is authenticating to an access point which is operated= by the same entity which operates the KDC? So the big question is: if an organization is hiding their KDC behind a fir= ewall, or they just haven't configured their access points to use the KDC a= s a back end, how is a proxy easier to implement or more secure than just c= onfiguring access thru their firewall or access point? Or really how does p= roviding 1000 routes to the KDC thru any public-facing, Kerberos-authentica= ted service (nfs, web apps, ssh...) beat just opening up port 88 to the wid= e world? Not trying to be a pita, just not seeing it yet... Bryce This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you= have received this message in error, please notify the sender and delete t= he email immediately. From nobody Fri Feb 14 15:58:16 2014 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 A3F8E1A0332 for ; Fri, 14 Feb 2014 15:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 fUHeJqtekuxQ for ; Fri, 14 Feb 2014 15:58:10 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0931A0486 for ; Fri, 14 Feb 2014 15:58:10 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 8FF4F9406E for ; Fri, 14 Feb 2014 15:58:08 -0800 (PST) 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:content-transfer-encoding; s= cryptonector.com; bh=yRRyAWd5zBrgotGepcxI9ZamGgs=; b=S83Fat9ner7 23x2HFHO5DimHwuZEiCy5Dq+WGoNdl+20Y17FPU2sUxOJ07sJuam8WtO46b8ydye jo8JSrOVIMVhXRQ5uG0iMXvE0a4dEwD24HxH+IryrglpblXTbajty67vB2e5hzMr +7+zgDfW3jWdb0RJsJ+Czn94YCIXHx3s= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 44B369406D for ; Fri, 14 Feb 2014 15:58:08 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id u57so9084034wes.41 for ; Fri, 14 Feb 2014 15:58:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oTWOcbiXWMUIa6SXzLHyHeolcA/+TLww6VcbIuTHpgs=; b=AEKCrRnmwKd2t/rKpHaIH4NBH8ZbrixBIlskv+/w5QxAVJqs5PkBMhH8vQ/qSV5QW2 UAkz8uTpxBSxW7zG9CtktjVHS9azD9Q+jr9X68bfEVPgtyaNF4fgR/fUe00rwF7O3pOS quSBpdZETLQv3VxUOkxJXv4VycC9c+CUewkeDo5HyK32/oSY5AyYuUWv+hCuv4RWMRWv RkR16uMzwZCTBCQZqQaEcYAZCwLhcYzlRUrRX0GNtMUsrwroWOqLsuYLD64R2XqcflC6 TENCChzSjvPrjfJ2bxq7aJnryhJ/Jz4Ph71A1ILmc+Jo+sXmudAM/peZwD6BJO69Gzgz ZfUA== MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr4300041wib.5.1392422286550; Fri, 14 Feb 2014 15:58:06 -0800 (PST) Received: by 10.217.108.132 with HTTP; Fri, 14 Feb 2014 15:58:06 -0800 (PST) In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E68DE37@001FSN2MPN1-045.001f.mgd2.msft.net> References: <20140214214526.22958.30728.idtracker@ietfa.amsl.com> <82E7C9A01FD0764CACDD35D10F5DFB6E68DE37@001FSN2MPN1-045.001f.mgd2.msft.net> Date: Fri, 14 Feb 2014 17:58:06 -0600 Message-ID: From: Nico Williams To: "Nordgren, Bryce L -FS" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/wLTXyXPl-oRQvXRBacZny15Kh8Y Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-iakerb-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, 14 Feb 2014 23:58:12 -0000 On Fri, Feb 14, 2014 at 5:47 PM, Nordgren, Bryce L -FS wrote: > "Remote access" to me means "outside the firewall of the organization ope= rating the KDC, which is not exposed to the public internet." What you appe= ar to be talking about is authenticating to an access point which is operat= ed by the same entity which operates the KDC? > > So the big question is: if an organization is hiding their KDC behind a f= irewall, or they just haven't configured their access points to use the KDC= as a back end, how is a proxy easier to implement or more secure than just= configuring access thru their firewall or access point? Or really how does= providing 1000 routes to the KDC thru any public-facing, Kerberos-authenti= cated service (nfs, web apps, ssh...) beat just opening up port 88 to the w= ide world? > > Not trying to be a pita, just not seeing it yet... The remote access protocol might not be able to allow any traffic other than EAP until the user is authenticated. Also, to use Kerberos outside the firewall would require configuring the firewall to permit DNS and Kerberos, which might be too difficult, and anyways might be considered risky (considering all that can be smuggled in DNS and Kerberos messages). Nico -- From nobody Sat Feb 15 09:22:06 2014 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 92CAB1A021A for ; Sat, 15 Feb 2014 09:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 BZ1A4x-_owNI for ; Sat, 15 Feb 2014 09:22:03 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7770D1A00EF for ; Sat, 15 Feb 2014 09:22:03 -0800 (PST) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1FHM0g9017442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Feb 2014 12:22:00 -0500 Received: from [10.3.113.19] ([10.3.113.19]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1FHLxe6004920; Sat, 15 Feb 2014 12:21:59 -0500 From: Simo Sorce To: "Nordgren, Bryce L -FS" In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E68DE37@001FSN2MPN1-045.001f.mgd2.msft.net> References: <20140214214526.22958.30728.idtracker@ietfa.amsl.com> <82E7C9A01FD0764CACDD35D10F5DFB6E68DE37@001FSN2MPN1-045.001f.mgd2.msft.net> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Sat, 15 Feb 2014 12:21:58 -0500 Message-ID: <1392484918.22754.5.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/-3wRiiXumzNCR4uuqFnEDs8qGB0 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-iakerb-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: Sat, 15 Feb 2014 17:22:05 -0000 On Fri, 2014-02-14 at 23:47 +0000, Nordgren, Bryce L -FS wrote: > > For example, in remote access scenarios, the client must initially > > authenticate to an access point in order to gain full access to the network. > > Here the client may be unable to directly contact the KDC either because it > > does not have an IP address, or the access point packet filter does > > not allow the client to send packets to the Internet before it > > authenticates to the access point. > > "Remote access" to me means "outside the firewall of the organization > operating the KDC, which is not exposed to the public internet." What > you appear to be talking about is authenticating to an access point > which is operated by the same entity which operates the KDC? > > So the big question is: if an organization is hiding their KDC behind > a firewall, or they just haven't configured their access points to use > the KDC as a back end, how is a proxy easier to implement or more > secure than just configuring access thru their firewall or access > point? Or really how does providing 1000 routes to the KDC thru any > public-facing, Kerberos-authenticated service (nfs, web apps, ssh...) > beat just opening up port 88 to the wide world? > > Not trying to be a pita, just not seeing it yet... The most immediate use case you may think about is GSSAPI authenticated VPN, where the KDC is inaccessible until you get on the VPN, w/o IAKERB you have a Catch22 situation. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Sat Feb 15 12:23:37 2014 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 283C61A02BE for ; Sat, 15 Feb 2014 12:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ghigcOjFp85T for ; Sat, 15 Feb 2014 12:23:30 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF171A028A for ; Sat, 15 Feb 2014 12:23:29 -0800 (PST) Received: from mail42-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.22; Sat, 15 Feb 2014 20:23:27 +0000 Received: from mail42-ch1 (localhost [127.0.0.1]) by mail42-ch1-R.bigfish.com (Postfix) with ESMTP id 892C83405B0; Sat, 15 Feb 2014 20:23:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:199.135.140.12; KIP:(null); UIP:(null); IPV:NLI; H:mail.usda.gov; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzd772hzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1f96jzz1de097hz2fh109h2a8h839h8e2h8e3h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h21a6h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255ehbe9i1155h) Received-SPF: pass (mail42-ch1: domain of fs.fed.us designates 199.135.140.12 as permitted sender) client-ip=199.135.140.12; envelope-from=bnordgren@fs.fed.us; helo=mail.usda.gov ; ail.usda.gov ; Received: from mail42-ch1 (localhost.localdomain [127.0.0.1]) by mail42-ch1 (MessageSwitch) id 1392495805372277_13028; Sat, 15 Feb 2014 20:23:25 +0000 (UTC) Received: from CH1EHSMHS032.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail42-ch1.bigfish.com (Postfix) with ESMTP id 56EB232005F; Sat, 15 Feb 2014 20:23:25 +0000 (UTC) Received: from mail.usda.gov (199.135.140.12) by CH1EHSMHS032.bigfish.com (10.43.70.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 15 Feb 2014 20:23:24 +0000 Received: from 001FSN2MPN1-045.001f.mgd2.msft.net ([169.254.5.105]) by 001FSN2MMR1-002.001f.mgd2.msft.net ([199.135.140.12]) with mapi id 14.03.0174.002; Sat, 15 Feb 2014 20:23:22 +0000 From: "Nordgren, Bryce L -FS" To: Simo Sorce Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-iakerb-01.txt Thread-Index: AQHPKc4cm+IW3OJF6UmZF4IrjmPqZpq1YLmQgAEwhwCAAAjoMA== Date: Sat, 15 Feb 2014 20:23:22 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E68DEFD@001FSN2MPN1-045.001f.mgd2.msft.net> References: <20140214214526.22958.30728.idtracker@ietfa.amsl.com> <82E7C9A01FD0764CACDD35D10F5DFB6E68DE37@001FSN2MPN1-045.001f.mgd2.msft.net> <1392484918.22754.5.camel@willson.li.ssimo.org> In-Reply-To: <1392484918.22754.5.camel@willson.li.ssimo.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.26.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fs.fed.us X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/5h1zCBzrDwmf4KlcN87qXfdWu08 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-iakerb-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: Sat, 15 Feb 2014 20:23:33 -0000 LS0gQ2xhcmlmeWluZyBkaXNjdXNzaW9uIG9uIGRyYWZ0LWlldGYta2l0dGVuLWlha2VyYi0wMS50 eHQgLS0NCg0KPiBUaGUgcmVtb3RlIGFjY2VzcyBwcm90b2NvbCBtaWdodCBub3QgYmUgYWJsZSB0 byBhbGxvdyBhbnkgdHJhZmZpYyBvdGhlciB0aGFuIEVBUA0KPiB1bnRpbCB0aGUgdXNlciBpcyBh dXRoZW50aWNhdGVkLg0KDQpTbyBpZiBJIHVuZGVyc3RhbmQgdGhpcyBjb3JyZWN0bHksIHRoZSBj dXJyZW50IHNpdHVhdGlvbiBpcyB0aGF0IHRoZSByZW1vdGUgYWNjZXNzIHBvaW50IGNvdWxkIGJl IGNvbmZpZ3VyZWQgdG8gdXNlIEtlcmJlcm9zIGFzIGEgYmFja2VuZCwgc2VydmluZyBhcyBhIGtp bmQgb2Ygb25lLXdheSBpZGVudGl0eSBnYXRld2F5IGJldHdlZW4gdHdvIHByb3RvY29scy4gVGhl IHByb3Bvc2VkIGltcHJvdmVtZW50IGlzIHRvIGVsaW1pbmF0ZSB0aGUgbmVlZCB0byBiZSBhIGdh dGV3YXkgYnkgYWxsb3dpbmcgdGhlIGFjY2VzcyBwb2ludCB0byByZWxheSBtZXNzYWdlcyBiZXR3 ZWVuIGEga2VyYmVyb3MgY2xpZW50IGFuZCBhIEtEQyB3aGljaCBvdGhlcndpc2UgaGF2ZSBubyBt ZWFucyBvZiBjb21tdW5pY2F0aW9uLiBUaGUgbmV0IGNoYW5nZSBpcyB0aGF0IGNsaWVudHMgdXNl IEtlcmJlcm9zIGluc3RlYWQgb2Ygd2hhdGV2ZXIgd2FzIHVzZWQgcHJldmlvdXNseSwgYWNjZXNz IHBvaW50cyByZXF1aXJlIG5ldyBmaXJtd2FyZSwgYW5kIGNsaWVudHMgZ2V0IGEgVEdUIGVhcmxp ZXIgaW4gdGhlIHByb2Nlc3MuDQoNCj4gVGhlIG1vc3QgaW1tZWRpYXRlIHVzZSBjYXNlIHlvdSBt YXkgdGhpbmsgYWJvdXQgaXMgR1NTQVBJIGF1dGhlbnRpY2F0ZWQNCj4gVlBOLCB3aGVyZSB0aGUg S0RDIGlzIGluYWNjZXNzaWJsZSB1bnRpbCB5b3UgZ2V0IG9uIHRoZSBWUE4sIHcvbyBJQUtFUkIg eW91DQo+IGhhdmUgYSBDYXRjaDIyIHNpdHVhdGlvbi4NCg0KTXkgY3VycmVudCBzaXR1YXRpb24g aXMgdGhhdCBJIHBvd2VyIHVwIG15IGxhcHRvcCBhdCBob21lLCBsb2cgaW50byBXaW5kb3dzIHVz aW5nIGNhY2hlZCBjcmVkZW50aWFscywgbWFudWFsbHkgc3RhcnQgdGhlIFZQTiBjbGllbnQsIHBy b3ZpZGUgY3JlZGVudGlhbHMgdG8gdGhlIFZQTiBzZXJ2ZXIgdXNpbmcgc29tZSBtZWFucywgYW5k IHRoZSBWUE4gc2VydmVyIHZhbGlkYXRlcyB0aGlzIGluZm9ybWF0aW9uIHVzaW5nIG9uZSBvZiB0 d28gYmFja2VuZHMgKExEQVAgdXNlcm5hbWUvcGFzc3dvcmQgb3IgbGluY3Bhc3MvSFNQRC0xMiBj YXJkL1BLSSkuIEFnYWluIHRoZSBWUE4gc2VydmVyIGFjdHMgYXMgYSBraW5kIG9mIGlkZW50aXR5 IGdhdGV3YXkgYW5kIGFnYWluIHRoZSBwcm9wb3NlZCBpbXByb3ZlbWVudCBpcyB0byBlbGltaW5h dGUgdGhlIG5lZWQgdG8gYmUgYSBnYXRld2F5LiBMb29rcyBsaWtlIHRoZSBuZXQgY2hhbmdlIG1h eSBhbHNvIGJlIHNhbWUgYXMgYWJvdmUuDQoNCg0KLS0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1r aXR0ZW4taWFrZXJiLTAxLnR4dCAtLQ0KDQpDb21tZW50IDE6IENsYXJpZnkgZXhhY3RseSB3aGF0 IHRoZSBiZW5lZml0IGlzLiBXaHkgYXJlIHRoZSBjdXJyZW50IGdhdGV3YXkgc3RyYXRlZ2llcyBu b3QgZ29vZCBlbm91Z2ggYW5kIHdoYXQgc3BlY2lmaWNhbGx5IGlzIGdhaW5lZCBieSBpbXBsZW1l bnRpbmcgSUFLRVJCPyAoU2hvdWxkIGJlIGVhc3kuKQ0KDQpDb21tZW50cyAyIGFuZCAzIGFyZSBy ZWFsbHkgImRpc2N1c3Npb24gaXRlbXMiLiAoYmVsb3cpDQoNCkNvbW1lbnQgNDogIlByb3h5IiBo YXMgYWxyZWFkeSBiZWVuIGRlZmluZWQgaW4gNDEyMC4gU3RyZXNzIHRoYXQgdGhlIHVzYWdlIG9m ICJwcm94eSIgaW4gdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbXBseSB0aGF0IHRoZSBjbGllbnQg YWxsb3dzIGl0cyB0aWNrZXRzIHRvIGJlIHVzZWQgYnkgIm90aGVycyIuDQoNCkNvbW1lbnQgNTog VGhpcyBhcHByb2FjaCBtYXkgYmUgc3VtbWFyaXplZCBhcyBhICJtZXNzYWdlIHJlbGF5IiBmcm9t IGNsaWVudCB0byBhcHAgdG8gS0RDLiBDb21wYXJlIGFuZCBjb250cmFzdCB0aGlzIGFwcHJvYWNo IHdpdGggYSAidGlja2V0IHJlbGF5Iiwgd2hlcmUgYSBzdHJhd21hbiAoZmFrZSkgS0RDIHJlcXVl c3RzIGFuZCByZWxheXMgcHJveGlhYmxlIGFuZC9vciBmb3J3YXJkYWJsZSB0aWNrZXRzIGZyb20g dGhlICJyZWFsIiBLREMgb24gdGhlIGNsaWVudCdzIGJlaGFsZiwgdXNpbmcgaXRzIG93biBpZGVu dGl0eS4gT3V0bGluZSB0aGUgdHJhZGVvZmZzIGluIHRlcm1zIG9mIGNvbXBhdGliaWxpdHkgd2l0 aCBkZXBsb3llZCBLcmI1IGNsaWVudHMgYW5kIEtEQ3MsIGFtb3VudCBvZiAiZXh0ZW5zaW9uIiBy ZXF1aXJlZCwgdHlwZXMgb2Ygc2l0dWF0aW9ucyB0byB3aGljaCB0aGUgYXBwcm9hY2ggYXBwbGll cywgc3RhdGUgaW5mb3JtYXRpb24gcmVxdWlyZWQgYXQgdGhlIHJlbGF5IHBvaW50LCBhbmQgc2Vj dXJpdHkgaW1wbGljYXRpb25zLiBNYWtlIHRoZSBjYXNlIHRoYXQgIm1lc3NhZ2UgcmVsYXkiIGlz IGEgc3VwZXJpb3Igc3RyYXRlZ3ksIGFuZCBzaG93IHRoYXQgYWx0ZXJuYXRpdmVzIHdlcmUgY29u c2lkZXJlZCBhbmQgcmVqZWN0ZWQuDQoNCkNvbW1lbnQgNjogVGhpcyBtZXNzYWdlIHJlbGF5IGFw cHJvYWNoIGludGVudGlvbmFsbHkgZXN0YWJsaXNoZXMgbWFueSBwZXJzaXN0ZW50ICJtZW4gaW4g dGhlIG1pZGRsZSIsIHBvdGVudGlhbGx5IHBpZ2d5YmFja2luZyBvbiBldmVyeSBrZXJiZXJpemVk IGFwcCB5b3UgaGF2ZS4gIE5vdGUgdGhpcyBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMu DQoNCg0KLS0gVGVjaG5pY2FsIGRpc2N1c3Npb24gYWJvdXQgZHJhZnQtaWV0Zi1raXR0ZW4taWFr ZXJiLTAxLnR4dCAtLQ0KDQpDb21tZW50cyAyIGFuZCAzIGJvaWwgZG93biB0bzogc2hvdWxkIGFu IElBS0VSQiBlbmFibGVkIEtlcmJlcm9zIGNsaWVudCBrZWVwIHRyYWNrIG9mIEtEQyBjb25uZWN0 aW9uIGZhaWx1cmVzIHNvIHRoYXQgaXQgY2FuIHRyeSBhbmQgZ2V0IHRpY2tldHMgd2hlbiBpdCBs YXRlciBkaXNjb3ZlcnMgYSBwYXRoIHRvIHRoZSBLREM/IENvbnZlcnNlbHksIHNob3VsZCBhbiBJ QUtFUkIgZW5hYmxlZCBLZXJiZXJvcyBjbGllbnQga2VlcCB0cmFjayBvZiBwcm94aWVzIHNvIHRo YXQgaXQgZG9lc24ndCBqdXN0IGdpdmUgdXAgd2hlbiBpdCBjYW4ndCBjb250YWN0IHRoZSBLREM/ IERldGFpbHMgYmVsb3cuDQoNCjJuZCBjb21tZW50IGRldGFpbHMuLi5Qcm94aWVzIG1heSBiZSBh c2tlZCB0byBhY3F1aXJlIHRpY2tldHMgZm9yIG90aGVyIHNlcnZpY2VzLCBhbmQgdGhlIG9yZGVy IGluIHdoaWNoIHNlcnZpY2VzIGFyZSBhY2Nlc3NlZCBieSBjbGllbnRzICBzZWVtcyB0byBtYXR0 ZXIuIChQZXJzb24gQSBpcyBhdCBob21lLCBhY2Nlc3Npbmcgd2ViIHNlcnZpY2VzICJYIiBhbmQg IlkiLiBCb3RoIFggYW5kIFkgYXJlIGtlcmJlcml6ZWQuIFggaXMgSUFLRVJCIGVuYWJsZWQgYW5k IFkgaXMgbm90LiBJZiBBIGNvbm5lY3RzIHRvIFggZmlyc3QsIGl0IFNIT1VMRCByZXF1ZXN0IGEg dGlja2V0IGZvciBZIHVzaW5nIFggb25jZSBpdCBkaXNjb3ZlcnMgdGhhdCBZIGlzbid0IElBS0VS QiBlbmFibGVkLiBJZiBBIGNvbm5lY3RzIHRvIFkgZmlyc3QsIGl0IGhhcyBubyBUR1Qgbm9yIGEg bWVhbnMgb2YgZ2V0dGluZyBvbmUsIHNvIFkgbXVzdCBiZWhhdmUgbGlrZSBhIGdhdGV3YXkuIEFm dGVyIEEgY29ubmVjdHMgdG8gWCwgYW5kICJkaXNjb3ZlcnMiIGEgcGF0aHdheSB0byBpdHMgS0RD LCBzaG91bGQgaXQgdGhlbiByZXF1ZXN0IHRpY2tldHMgZm9yIFk/IEhvdyBpcyBZIGluZm9ybWVk IHRoYXQgQSBub3cgaGFzIGEgdGlja2V0PyApIFRoaXMgbWF5IG5vdCByZXF1aXJlIG11Y2ggaW4g dGhlIHdheSBvZiB2ZXJiYWdlLCBidXQgSSB0aGluayBpdCBwcm9iYWJseSBzaG91bGQgYmUgaW5j bHVkZWQuIFRoZSBwcm9wb3NlZCBpbXByb3ZlbWVudCBpcyB0byBlbGltaW5hdGUgZ2F0ZXdheWxp a2UgYmVoYXZpb3IuDQoNCjNyZCBjb21tZW50IGRldGFpbHMuLi53aGF0IGlmIHRoZSBzZXJ2aWNl IGFsc28gZG9lcyBub3QgaGF2ZSBhIHBhdGggdG8gdGhlIEtEQz8gSW4gdGhlIFZQTiBleGFtcGxl IGFib3ZlLCBJIGxvZyBpbiB0byBteSBob3N0IHVzaW5nIGNhY2hlZCBjcmVkZW50aWFscy4gT25j ZSBJIGNvbm5lY3QgdG8gYW4gSUFLRVJCIHByb3h5IChWUE4gc2VydmVyKSwgc2hvdWxkIHRoZSBo b3N0IHRyeSB0byBncmFiIGEgdmFsaWQgdGlja2V0Pw0KDQoNCkJyeWNlDQoNCg0KDQoNCg0KVGhp cyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gZ2VuZXJhdGVkIGJ5IHRo ZSBVU0RBIHNvbGVseSBmb3IgdGhlIGludGVuZGVkIHJlY2lwaWVudHMuIEFueSB1bmF1dGhvcml6 ZWQgaW50ZXJjZXB0aW9uIG9mIHRoaXMgbWVzc2FnZSBvciB0aGUgdXNlIG9yIGRpc2Nsb3N1cmUg b2YgdGhlIGluZm9ybWF0aW9uIGl0IGNvbnRhaW5zIG1heSB2aW9sYXRlIHRoZSBsYXcgYW5kIHN1 YmplY3QgdGhlIHZpb2xhdG9yIHRvIGNpdmlsIG9yIGNyaW1pbmFsIHBlbmFsdGllcy4gSWYgeW91 IGJlbGlldmUgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgZW1haWwgaW1tZWRpYXRlbHkuDQo= From nobody Sat Feb 15 13:06:21 2014 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 AEDFC1A02BA for ; Sat, 15 Feb 2014 13:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 WxTJQd1_GdTh for ; Sat, 15 Feb 2014 13:06:18 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4EE1A02CE for ; Sat, 15 Feb 2014 13:06:18 -0800 (PST) Received: from mail35-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Sat, 15 Feb 2014 21:06:16 +0000 Received: from mail35-ch1 (localhost [127.0.0.1]) by mail35-ch1-R.bigfish.com (Postfix) with ESMTP id 3BE33220589; Sat, 15 Feb 2014 21:06:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:199.135.140.11; KIP:(null); UIP:(null); IPV:NLI; H:mail.usda.gov; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1f96jzzz2fh109h2a8h839h8e2h8e3h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h21a6h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255ehbe9i1155h) Received-SPF: pass (mail35-ch1: domain of fs.fed.us designates 199.135.140.11 as permitted sender) client-ip=199.135.140.11; envelope-from=bnordgren@fs.fed.us; helo=mail.usda.gov ; ail.usda.gov ; Received: from mail35-ch1 (localhost.localdomain [127.0.0.1]) by mail35-ch1 (MessageSwitch) id 1392498372954643_27772; Sat, 15 Feb 2014 21:06:12 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail35-ch1.bigfish.com (Postfix) with ESMTP id B37D7320055; Sat, 15 Feb 2014 21:06:12 +0000 (UTC) Received: from mail.usda.gov (199.135.140.11) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 15 Feb 2014 21:06:12 +0000 Received: from 001FSN2MPN1-045.001f.mgd2.msft.net ([169.254.5.105]) by 001FSN2MMR1-001.001f.mgd2.msft.net ([199.135.140.11]) with mapi id 14.03.0174.002; Sat, 15 Feb 2014 21:06:11 +0000 From: "Nordgren, Bryce L -FS" To: Nico Williams Thread-Topic: firewalls and cross realm trusts Thread-Index: Ac8qjUsOYuIqh0sTSEi4V0d8zmaVfg== Date: Sat, 15 Feb 2014 21:06:10 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E68DF75@001FSN2MPN1-045.001f.mgd2.msft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.26.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fs.fed.us X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/bWGRB6RxUDVC56yxA4rbvpT2340 Cc: "kitten@ietf.org" Subject: [kitten] firewalls and cross realm trusts 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, 15 Feb 2014 21:06:20 -0000 DQpJIGFwcHJlY2lhdGUgeW91ciBwYXRpZW5jZSBpbiBhZHZhbmNlLiA6KQ0KDQo+IEFsc28sIHRv IHVzZSBLZXJiZXJvcyBvdXRzaWRlIHRoZSBmaXJld2FsbCB3b3VsZCByZXF1aXJlIGNvbmZpZ3Vy aW5nIHRoZQ0KPiBmaXJld2FsbCB0byBwZXJtaXQgRE5TIGFuZCBLZXJiZXJvcywgd2hpY2ggbWln aHQgYmUgdG9vIGRpZmZpY3VsdCwgYW5kDQo+IGFueXdheXMgbWlnaHQgYmUgY29uc2lkZXJlZCBy aXNreSAoY29uc2lkZXJpbmcgYWxsIHRoYXQgY2FuIGJlIHNtdWdnbGVkIGluDQo+IEROUyBhbmQg S2VyYmVyb3MgbWVzc2FnZXMpLg0KDQpQbGVhc2UgZWxhYm9yYXRlIHRoZXNlIGlzc3VlcyB3aXRo aW4gdGhlIGNvbnRleHQgb2YgY3Jvc3MtcmVhbG0gdHJ1c3RzIGFuZCBwZXJoYXBzIHlvdXIgcGtj cm9zcyBkcmFmdC4gSXQgc2VlbXMgbGlrZSBubyBtYXR0ZXIgd2hlcmUgeW91IGFyZSwgeW91J3Jl IGFsd2F5cyBvdXRzaWRlIG9mIHNvbWVib2R5J3MgZmlyZXdhbGwgYW5kIEROUyBpcyBub3QgdmVy eSBtb2JpbGl0eSBmcmllbmRseS4NCg0KSW4gcGFydGljdWxhciwgSSdtIGN1cmlvdXMgYWJvdXQg dGhlIGZvbGxvd2luZzogU2F5IHBlcnNvbiBBIGFuZCBsYXB0b3AgQiBiZWxvbmcgdG8gcmVhbG0g WC4gUGVyc29uIEEgYW5kIGxhcHRvcCBCIHZpc2l0IHJlYWxtIFkuIFBlcnNvbiBBIGlzIHRoZSBz YW1lLCBsYXB0b3AgQiBpcyB0aGUgc2FtZSwgYnV0IGxhcHRvcCBCJ3MgRE5TIGVudHJ5IChpZiBp dCBleGlzdHMpIGlzIG5vdyBpc3N1ZWQgYnkgcmVhbG0gWSBpbnN0ZWFkIG9mIFguIEFzc3VtZSBu byBmaXJld2FsbHMgYW5kIHJlYWxtcyBYIGFuZCBZIGhhdmUgYSBjcm9zcyByZWFsbSB0cnVzdC4g V2lsbCBsYXB0b3AgQiBiZSByZWNvZ25pemVkIGJ5IHJlYWxtIFggZXZlbiB0aG91Z2ggaXRzIERO UyBpcyB3cm9uZz8gOikgQ2FuIGl0LCBmb3IgaW5zdGFuY2UsIGJlIGFuIE5GUyBjbGllbnQ/DQoN Ck5vdyBYIGFuZCBZIGJvdGggaGF2ZSBmaXJld2FsbHMuICBTYXkgcmVhbG1zIFggYW5kIFkgZG9u J3QgaGF2ZSBhIGNyb3NzIHJlYWxtIHRydXN0LCBidXQgdGhleSBib3RoIGFyZSBwa2Nyb3NzIGZy aWVuZGx5LiBDYW4gcGtjcm9zcyArIGlha2VyYiBhbGxvdyByZWFsbSBZIHRvIGNvbnRhY3QgcmVh bG0gWCB0byB2YWxpZGF0ZSBwZXJzb24gQSBhbmQgbGFwdG9wIEI/IENhbiBwa2Nyb3NzIGNvbmNl cHRzIGJlIHVzZWQgdG8gZWxpbWluYXRlIHRoZSBuZWVkIGZvciBZICB0byBjb250YWN0IFg/IChl LmcuLCBBIGFuZCBCIGhhdmUgYmVlbiBpc3N1ZWQgY2VydGlmaWNhdGVzIHNpZ25lZCBieSBYLCB3 aGljaCBoYXMgYSBjZXJ0aWZpY2F0ZSB0aGF0IFkgd291bGQgZWl0aGVyIHRydXN0IG9yIG5vdCwg c28gd2h5IGJvdGhlciBjb250YWN0aW5nIGEgZmlyZXdhbGxlZCBYPykNCg0KQnJ5Y2UNCg0KDQoN Cg0KDQoNCg0KDQpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiBn ZW5lcmF0ZWQgYnkgdGhlIFVTREEgc29sZWx5IGZvciB0aGUgaW50ZW5kZWQgcmVjaXBpZW50cy4g QW55IHVuYXV0aG9yaXplZCBpbnRlcmNlcHRpb24gb2YgdGhpcyBtZXNzYWdlIG9yIHRoZSB1c2Ug b3IgZGlzY2xvc3VyZSBvZiB0aGUgaW5mb3JtYXRpb24gaXQgY29udGFpbnMgbWF5IHZpb2xhdGUg dGhlIGxhdyBhbmQgc3ViamVjdCB0aGUgdmlvbGF0b3IgdG8gY2l2aWwgb3IgY3JpbWluYWwgcGVu YWx0aWVzLiBJZiB5b3UgYmVsaWV2ZSB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSBlbWFpbCBpbW1l ZGlhdGVseS4NCg== From nobody Sun Feb 16 09:14:55 2014 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 6225E1A00F2 for ; Sun, 16 Feb 2014 09:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 2H57FRxCfp66 for ; Sun, 16 Feb 2014 09:14:52 -0800 (PST) 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 D8CD81A0016 for ; Sun, 16 Feb 2014 09:14:51 -0800 (PST) X-AuditID: 12074422-f79526d000000c47-9b-5300f2095faf Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 38.16.03143.902F0035; Sun, 16 Feb 2014 12:14:49 -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 s1GHEmQQ024210 for ; Sun, 16 Feb 2014 12:14:49 -0500 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s1GHElCR019627 for ; Sun, 16 Feb 2014 12:14:48 -0500 From: Greg Hudson To: kitten@ietf.org Date: Sun, 16 Feb 2014 12:14:26 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUixG6nosv5iSHYYO0mWYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro/v8VraCdaIVh1ecZ2lgfCDQxcjJISFgIjHtcgsThC0mceHe erYuRi4OIYHZTBIT3p5mgnCOM0q8+vIXKtPBJHF3x1oWkBY2AWWJg2e/gdkiAsISu7e+Ywax hQUMJN6+mcfaxcjBwSKgKrGy3RQkzCtgKPHn5i1WCFtQ4uTMJ2CtzAJaEjf+vWSawMgzC0lq FpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbqmermZJXqpKaWbGMHB4aK0g/HnQaVDjAIc jEo8vAvTGIKFWBPLiitzDzFKcjApifLeeQ8U4kvKT6nMSCzOiC8qzUktPsQowcGsJMLLfQco x5uSWFmVWpQPk5LmYFES5621+BUkJJCeWJKanZpakFoEk5Xh4FCS4I34CNQoWJSanlqRlplT gpBm4uAEGc4DNLz5A8jw4oLE3OLMdIj8KUZFKXHeBSAJAZBERmkeXC8sel8xigO9Isy7EqSK Bxj5cN2vgAYzAQ1edfpvENDgkkSElFQDY8aMGpMfcwsSXme+rpwyL+5DyY3ixCUCyjdSP5Wf qUhcO6/82xNfi7awzIX1F95Lf9yie5bto6jDYc0g9VKeGdO/XTx46qFssNlV37cfiq5tOVnx LVKA8+q0N4WtysoLmM16QjxkzimrW5hUn915br10GVPOv+/LRSyyjs48Jub1zFnauXzjCyWW 4oxEQy3mouJEAKP8uFC5AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/aUmrdsAXckoNBootCqDR9Csyhrs Subject: [kitten] Comments on draft-ietf-kitten-iakerb-01 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, 16 Feb 2014 17:14:54 -0000 Content comments: > Exts field in the GSS-API authenticator [RFC6542] MUST contain an > extension of the type GSS_EXTS_IAKERB_FINISHED The rest of the draft uses GSS_EXTS_FINISHED. > and the extension data contains the ASN.1 DER encoding of the > structure IAKERB-FINISHED. The rest of the draft uses KRB-FINISHED. > Initiators behave as follows: > > o If the acceptor token is framed, then use the protocol as defined > above. I suggest: o If the first acceptor token begins with generic token framing as described in section 3.1 of [RFC 2743], then use the protocol as defined in this document. > o Else I suggest: o If the first acceptor token is missing the generic token framing (i.e. the token begins with the two-byte token ID 05 01), then > * All future tokens sent to the acceptor are to be unframed. This bullet is unnecessary and should be removed. All versions of the MIT IAKERB acceptor will process framed messages, as I said here: http://www.ietf.org/mail-archive/web/kitten/current/msg03993.html > Acceptors behave as follows: > > o If you framed the response token, use the finish extension > processing defined in the main document. > > o If you did not frame the response token, use the finish extension > processing defined in the previous paragraph. This doesn't provide useful advice for interoperating with an MIT initiator, as a standard acceptor will always frame the response token. I suggest: Acceptors behave as follows: o If the AP-REQ authenticator contains an extension of type 1 containing a KRB-FINISHED message, then process the extension as if it were of type GSS_EXTS_FINISHED, except with a key usage of KEY_USAGE_IAKERB_FINISHED (42) instead of KEY_USAGE_FINISHED (41). Editorial comments (only on the new text): > MIT implemented an earlier draft of this specification, details on how > to inter operate with that implementation can be found in Appendix A. This is a run-on sentence. Using a semicolon instead of a comma would fix it. > pnp The gss-mic field in the KRB-FINISHED structure contains There is a stray "pnp" at the beginning here. > concatenated in chronological order (note that GSS-API context token > exchanges are synchronous.) The period should be outside the parens, or the parenthetical should be a separate sentence (in which case the period stays inside the parens). > MIT implemented an early draft version of this document, this section > gives a method for detecting and interoperating with that version. This is another run-on sentence. It's probably best to split it into two sentences at the comma. From nobody Sun Feb 16 11:39:59 2014 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 135671A0275 for ; Sun, 16 Feb 2014 11:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 IfbWYzemMUc1 for ; Sun, 16 Feb 2014 11:39:56 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7C01A0262 for ; Sun, 16 Feb 2014 11:39:56 -0800 (PST) X-AuditID: 12074424-f79e26d000000c70-eb-5301140963c5 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id E6.BC.03184.90411035; Sun, 16 Feb 2014 14:39:53 -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 s1GJdruW002486 for ; Sun, 16 Feb 2014 14:39:53 -0500 Received: from [18.101.8.142] (vpn-18-101-8-142.mit.edu [18.101.8.142]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s1GJdo7D026954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 16 Feb 2014 14:39:52 -0500 Message-ID: <53011405.4050904@mit.edu> Date: Sun, 16 Feb 2014 14:39:49 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: kitten@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixG6nosspwhhsMH+xocXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcezEFsaCZ5wVzbN2sTUwvmbvYuTkkBAwkbj1ezcbhC0mceHe ejBbSGA2k8TjNuYuRi4g+zijRMfPHUwQzi0miVfPTjCCVPEKqEk8mP+MCcRmEVCVePHhCzOI zSagLHHw7DcWEFtUIEzi7v+1UPWCEidnPgGLiwgIS+ze+g6sXljAVmLJho1MEJsNJZ7OvANW wylgJPH22l+oSyUlti06BmYzC+hIvOt7wAxhy0tsfzuHeQKj4CwkK2YhKZuFpGwBI/MqRtmU 3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2M4GB1UdnB2HxI6RCjAAejEg9vwuP/QUKs iWXFlbmHGCU5mJREeauFGIOF+JLyUyozEosz4otKc1KLDzFKcDArifAuZQTK8aYkVlalFuXD pKQ5WJTEeWstfgUJCaQnlqRmp6YWpBbBZGU4OJQkeJmFgRoFi1LTUyvSMnNKENJMHJwgw3mA huuA1PAWFyTmFmemQ+RPMSpKifN+FQRKCIAkMkrz4HphyeQVozjQK8K8uiDtPMBEBNf9Cmgw E9DgVaf/BgENLklESEk1MM5kczg+c0LilztX7m348WWmj5/4dQv9z32+fz5mLn6Y5b36Np+s 8SfBk+rF8xleMnziE9j2ONzh+fdNalYxU72UGswqujomzl+4+WHz03unc/4d3Jh9YuuGl0/+ 6ebt+Hjva8TF2tVruLbNyWW4ePyOkPuqWalCDb1Cn9bzrdgitel2oItkbvIaJZbijERDLeai 4kQAdYrkTQEDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/uwCae1EvZVIL__DxkV3Be3FMhYs Subject: Re: [kitten] Comments on draft-ietf-kitten-iakerb-01 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, 16 Feb 2014 19:39:58 -0000 On 02/16/2014 12:14 PM, Greg Hudson wrote: > This doesn't provide useful advice for interoperating with an MIT > initiator, as a standard acceptor will always frame the response token. > I suggest: > > Acceptors behave as follows: > > o If the AP-REQ authenticator contains an extension of type 1 > containing a KRB-FINISHED message, then process the extension as if > it were of type GSS_EXTS_FINISHED, except with a key usage of > KEY_USAGE_IAKERB_FINISHED (42) instead of KEY_USAGE_FINISHED (41). I missed a necessary bullet point here. Before the AP-REQ bullet point, I suggest: o After the first initiator token, allow initiator tokens to omit generic token framing. This allowance is required only for IAKERB_PROXY messages (those using token ID 05 01), not for tokens defined in [RFC4121]. It might also be worthwhile to say that, for the purpose of computing the KRB-FINISHED checksum, initiators and acceptors should both use the tokens they sent or received without modification--that is, don't insert synthetic generic token framing or modify the token to have the standardized extension type. But I don't have suggested wording, and it should be fairly obvious even if we don't say it. From nobody Sun Feb 16 13:18:17 2014 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 6D8651A0413 for ; Sun, 16 Feb 2014 13:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 8FPgInmgNy4R for ; Sun, 16 Feb 2014 13:18:13 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9E21A02D3 for ; Sun, 16 Feb 2014 13:18:13 -0800 (PST) Received: from mail93-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.22; Sun, 16 Feb 2014 21:18:10 +0000 Received: from mail93-va3 (localhost [127.0.0.1]) by mail93-va3-R.bigfish.com (Postfix) with ESMTP id ACC1A1E01C7; Sun, 16 Feb 2014 21:18:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:199.135.140.13; KIP:(null); UIP:(null); IPV:NLI; H:mail.usda.gov; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzd772hzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1f96jzzz2fh109h2a8h839h8e2h8e3h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h21a6h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255ehbe9i1155h) Received-SPF: pass (mail93-va3: domain of fs.fed.us designates 199.135.140.13 as permitted sender) client-ip=199.135.140.13; envelope-from=bnordgren@fs.fed.us; helo=mail.usda.gov ; ail.usda.gov ; Received: from mail93-va3 (localhost.localdomain [127.0.0.1]) by mail93-va3 (MessageSwitch) id 1392585489251939_3181; Sun, 16 Feb 2014 21:18:09 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.253]) by mail93-va3.bigfish.com (Postfix) with ESMTP id 37CB244004A; Sun, 16 Feb 2014 21:18:09 +0000 (UTC) Received: from mail.usda.gov (199.135.140.13) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 16 Feb 2014 21:18:09 +0000 Received: from 001FSN2MPN1-045.001f.mgd2.msft.net ([169.254.5.105]) by 001FSN2MMR1-003.001f.mgd2.msft.net ([199.135.140.13]) with mapi id 14.03.0174.002; Sun, 16 Feb 2014 21:18:08 +0000 From: "Nordgren, Bryce L -FS" To: Russ Allbery Thread-Topic: [kitten] PKCROSS and philosophical tangents... Thread-Index: AQHPHsGSVIDV+Fq6S8CZNUDcti9KcJq4eGaw Date: Sun, 16 Feb 2014 21:18:07 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E68E044@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E683D80@001FSN2MPN1-046.001f.mgd2.msft.net> <201401311750.s0VHoV9a010086@hedwig.cmf.nrl.navy.mil> <82E7C9A01FD0764CACDD35D10F5DFB6E684319@001FSN2MPN1-046.001f.mgd2.msft.net> <87bnyrc3co.fsf@windlord.stanford.edu> In-Reply-To: <87bnyrc3co.fsf@windlord.stanford.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.26.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fs.fed.us X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/YSRK259FW54FiJo-B7xu7ibgQg0 Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS and philosophical tangents... 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, 16 Feb 2014 21:18:15 -0000 > Password changes are interoperable provided that they're limited to > operations that can be performed via the kpasswd protocol (and provided > you can deal with the kpasswd protocol, which is rather broken, but usual= ly > workable in practice provided everyone understands the required > assumptions). Please excuse the noob question. Was looking for this and found: * draft-ietf-cat-kerb-chg-password-02 (appears dead as of 1998) * RFC3244 (Informational/Microsoft implementation) * draft-ietf-krb-wg-kerberos-set-passwd-08 (appears dead as of 2008 but is = referenced in 2013-era RFC6880) I didn't find an actual standards track RFC kpasswd document...Could you po= int me at the kpasswd protocol definition? Thx, Bryce This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you= have received this message in error, please notify the sender and delete t= he email immediately. From nobody Sun Feb 16 13:22:35 2014 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 8481B1A02C1 for ; Sun, 16 Feb 2014 13:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 tsT_dj8uTx0s for ; Sun, 16 Feb 2014 13:22:31 -0800 (PST) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0A11A02B7 for ; Sun, 16 Feb 2014 13:22:31 -0800 (PST) Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 37EA7100F2A; Sun, 16 Feb 2014 13:22:29 -0800 (PST) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 6958D100ED5; Sun, 16 Feb 2014 13:22:27 -0800 (PST) Received: by windlord.stanford.edu (Postfix, from userid 1000) id A9CE72F44E; Sun, 16 Feb 2014 13:22:27 -0800 (PST) From: Russ Allbery To: "Nordgren\, Bryce L -FS" In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E68E044@001FSN2MPN1-045.001f.mgd2.msft.net> (Bryce L. Nordgren's message of "Sun, 16 Feb 2014 21:18:07 +0000") Organization: The Eyrie References: <82E7C9A01FD0764CACDD35D10F5DFB6E683D80@001FSN2MPN1-046.001f.mgd2.msft.net> <201401311750.s0VHoV9a010086@hedwig.cmf.nrl.navy.mil> <82E7C9A01FD0764CACDD35D10F5DFB6E684319@001FSN2MPN1-046.001f.mgd2.msft.net> <87bnyrc3co.fsf@windlord.stanford.edu> <82E7C9A01FD0764CACDD35D10F5DFB6E68E044@001FSN2MPN1-045.001f.mgd2.msft.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Sun, 16 Feb 2014 13:22:27 -0800 Message-ID: <87d2imrbvw.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Zqv5AdVzPadmkHFv25D2QtdZiWo Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS and philosophical tangents... 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, 16 Feb 2014 21:22:33 -0000 "Nordgren, Bryce L -FS" writes: >> Password changes are interoperable provided that they're limited to >> operations that can be performed via the kpasswd protocol (and provided >> you can deal with the kpasswd protocol, which is rather broken, but >> usually workable in practice provided everyone understands the required >> assumptions). > Please excuse the noob question. Was looking for this and found: > * draft-ietf-cat-kerb-chg-password-02 (appears dead as of 1998) > * RFC3244 (Informational/Microsoft implementation) > * draft-ietf-krb-wg-kerberos-set-passwd-08 (appears dead as of 2008 but > is referenced in 2013-era RFC6880) > I didn't find an actual standards track RFC kpasswd document...Could you > point me at the kpasswd protocol definition? RFC 3244 is the one that everyone uses, I think. I'm not positive if krb5_change_password is an alternative API to the same protocol or if it tries an older protocol as well. -- Russ Allbery (eagle@eyrie.org) From nobody Mon Feb 17 19:58:32 2014 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 877841A0430 for ; Mon, 17 Feb 2014 19:58:29 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 eHt2dbcrMNme for ; Mon, 17 Feb 2014 19:58:27 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 040941A030F for ; Mon, 17 Feb 2014 19:58:26 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 069D12005D105; Mon, 17 Feb 2014 19:58:24 -0800 (PST) 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=cHdcDWqlRnmt0r 5wO4/K43oTGzQ=; b=Ie+iLHgNxgUxt8cC6Fc8iv9J/Q358e+07P/NuOaAXDUB6g ccIBc0YOP4MoTcmsgcCv6BFsxk377f3u5qBH2bk6jxVh6iQ0VS+qTRjjP2ybFcAS Ekz/G76g37YaklmOPgLxLeF5C2/gnGD5YrN4yO9DKzgWukZo+iI0WAQYt4QnI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id B3DE82005D104; Mon, 17 Feb 2014 19:58:23 -0800 (PST) Date: Mon, 17 Feb 2014 21:58:23 -0600 From: Nico Williams To: "Nordgren, Bryce L -FS" Message-ID: <20140218035821.GA20790@localhost> References: <82E7C9A01FD0764CACDD35D10F5DFB6E68DF75@001FSN2MPN1-045.001f.mgd2.msft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E68DF75@001FSN2MPN1-045.001f.mgd2.msft.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/qBikmZkVQOyTEoUtKoSE3Qjk5Rc Cc: "kitten@ietf.org" Subject: Re: [kitten] firewalls and cross realm trusts 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, 18 Feb 2014 03:58:29 -0000 On Sat, Feb 15, 2014 at 09:06:10PM +0000, Nordgren, Bryce L -FS wrote: > > Also, to use Kerberos outside the firewall would require configuring the > > firewall to permit DNS and Kerberos, which might be too difficult, and > > anyways might be considered risky (considering all that can be smuggled in > > DNS and Kerberos messages). > > Please elaborate these issues within the context of cross-realm trusts > and perhaps your pkcross draft. It seems like no matter where you are, > you're always outside of somebody's firewall and DNS is not very > mobility friendly. If you're using a remote access protocol then you're outside the firewall until you establish the necessary tunnel. (Almost by definition, since the remote access gateway [and protocol] generally exists only to get past a firewall.) > In particular, I'm curious about the following: Say person A and > laptop B belong to realm X. Person A and laptop B visit realm Y. > Person A is the same, laptop B is the same, but laptop B's DNS entry Laptops shouldn't count on having names published in the DNS reliably and kept up to date in real-time. > (if it exists) is now issued by realm Y instead of X. Assume no DNS entries aren't issued by Kerberos realms :) (Frequently realms' KDC and DNS zones' infrastructures are co-located, at least in Microsoft's Active Directory. But that's incidental, not essential.) > firewalls and realms X and Y have a cross realm trust. Will laptop B > be recognized by realm X even though its DNS is wrong? :) Can it, for > instance, be an NFS client? Yes, it doesn't have to have its IP address be resolvable to its hostname, whatever it might be, nor does that need to match the laptop's client credentials in any way. At least the Solaris/Illumos NFS stack will work fine, both as to mobile clients and their servers, at least as to authentication. And this will work even without any machine credentials. (The laptop might not get root-equivalent access to any NFS shares though. The Solaris/Illumos NFS server will want the client's credential to be a host-based name for the "root" service and will want the hostname from that name to match the name observed through the name service. But this is probably not a problem.) > Now X and Y both have firewalls. Say realms X and Y don't have a > cross realm trust, but they both are pkcross friendly. Can pkcross + Today that can't happen: there's no PKCROSS protocol. > iakerb allow realm Y to contact realm X to validate person A and > laptop B? Can pkcross concepts be used to eliminate the need for Y to > contact X? (e.g., A and B have been issued certificates signed by X, > which has a certificate that Y would either trust or not, so why > bother contacting a firewalled X?) If there's no trust path from X to Y of any kind, then nothing can make this work, not PKI, not Kerberos, nothing. I think you're asking if there's an offline (in that X is not reachable from Y) mechanism for X's users to be able to authenticate to Y. Needham-Shroeder is out, as it's online. PK-based protocols can do it, but PKIX is not really offline: there's CRLs to check (and/or OCSP). That includes PKINIT and a hypothetical PKCROSS, but again, if the client's PKIX credentials aren't fresh enough then the protocol will become online and therefore fail. The main reason to want PKCROSS is really to complete a PKI/Kerberos duality, leading to more application protocols being available with a single credential than would be the case otherwise. It's just one more bridge in a world that needs more bridges because of how it came about. There really isn't anything you can do here to address your hypothetical use case: Y will just have to be able to reach some part of X's infrastructure. This isn't usually a problem, and it's neither the motivation for IAKERB, nor PKINIT, nor PKCROSS. IAKERB exists to deal with the lack of any network connectivity at network attachment time. The client wants to authenticate with a mechanism (Kerberos, but it could be something else) that requires connectivity to one or more infrastructure services, but this can't be retrofitted into the network attachment protocol (for whatever reasons). IAKERB basically invites the network attachment point to engage in a very limited form of routing. The client's realm's KDCs (and possibly others'), as well as the network attachment point's, will have to be reachable from the inside (from within Y), but not necessarily from the outside. (Of course, a client could smuggle all sorts of things in Kerberos payloads, just as clients can do the same over DNS. A network that wants to prevent this will simply not allow IAKERB to be used to reach any realms' KDCs not on a white-list, or perhaps it won't allow IAKERB at all.) Nico -- From nobody Mon Feb 17 22:29:02 2014 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 9BA981A05FD for ; Mon, 17 Feb 2014 22:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 FTETSR1Os3gq for ; Mon, 17 Feb 2014 22:28:59 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id F2FA21A05E8 for ; Mon, 17 Feb 2014 22:28:58 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1I6StIo024692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 18 Feb 2014 06:28:56 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1I6SsmH016895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Feb 2014 06:28:55 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1I6SsOe016890 for ; Tue, 18 Feb 2014 06:28:54 GMT Received: from [10.159.121.224] (/10.159.121.224) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Feb 2014 22:28:54 -0800 Message-ID: <5302FD95.2000704@oracle.com> Date: Mon, 17 Feb 2014 23:28:37 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20131203 Thunderbird/17.0.6 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/nvmGk18S1oYzvRmHhujjN0o1l7I Subject: [kitten] IETF 89 - Draft Agenda 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, 18 Feb 2014 06:29:00 -0000 Please provide any additions or updates to the draft agenda posted here: http://www.ietf.org/proceedings/89/agenda/agenda-89-kitten by Monday UTC 23:59. Thanks, Shawn. -- kitten co-chair From nobody Tue Feb 18 16:14:30 2014 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 5FA891A02BB for ; Tue, 18 Feb 2014 16:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 dG2549wv9Yte for ; Tue, 18 Feb 2014 16:14:26 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 817271A0246 for ; Tue, 18 Feb 2014 16:14:26 -0800 (PST) Received: from mail39-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Wed, 19 Feb 2014 00:14:22 +0000 Received: from mail39-tx2 (localhost [127.0.0.1]) by mail39-tx2-R.bigfish.com (Postfix) with ESMTP id C4D786027B; Wed, 19 Feb 2014 00:14:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:199.135.140.12; KIP:(null); UIP:(null); IPV:NLI; H:mail.usda.gov; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1f96jzz1de097hz2fh109h2a8h839h8e2h8e3h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h21a6h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255ehbe9i1155h) Received-SPF: pass (mail39-tx2: domain of fs.fed.us designates 199.135.140.12 as permitted sender) client-ip=199.135.140.12; envelope-from=bnordgren@fs.fed.us; helo=mail.usda.gov ; ail.usda.gov ; Received: from mail39-tx2 (localhost.localdomain [127.0.0.1]) by mail39-tx2 (MessageSwitch) id 1392768861340271_5522; Wed, 19 Feb 2014 00:14:21 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.234]) by mail39-tx2.bigfish.com (Postfix) with ESMTP id 4E09C120084; Wed, 19 Feb 2014 00:14:21 +0000 (UTC) Received: from mail.usda.gov (199.135.140.12) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 19 Feb 2014 00:14:20 +0000 Received: from 001FSN2MPN1-045.001f.mgd2.msft.net ([169.254.5.105]) by 001FSN2MMR1-002.001f.mgd2.msft.net ([199.135.140.12]) with mapi id 14.03.0174.002; Wed, 19 Feb 2014 00:14:19 +0000 From: "Nordgren, Bryce L -FS" To: Nico Williams Thread-Topic: firewalls and cross realm trusts Thread-Index: Ac8qjUsOYuIqh0sTSEi4V0d8zmaVfgB0F/6AACWsI8A= Date: Wed, 19 Feb 2014 00:14:18 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E68E5CF@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E68DF75@001FSN2MPN1-045.001f.mgd2.msft.net> <20140218035821.GA20790@localhost> In-Reply-To: <20140218035821.GA20790@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.26.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fs.fed.us X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/4MXhSTy8JvfHson9nQCbMieOYpE Cc: "kitten@ietf.org" Subject: Re: [kitten] firewalls and cross realm trusts 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, 19 Feb 2014 00:14:29 -0000 > DNS entries aren't issued by Kerberos realms :) (Frequently realms' KDC = and > DNS zones' infrastructures are co-located, at least in Microsoft's Active > Directory. But that's incidental, not essential.) > Yes, it doesn't have to have its IP address be resolvable to its hostname= , > whatever it might be, nor does that need to match the laptop's client > credentials in any way. I fear I miscommunicated. The laptop's identity in the KDC is likely an NT_= SRV_HST host/home.dns.here. The fact that NT_SRV_HST is used conveys inform= ation about the host: specifically "home.dns.here" is supposed to be the in= ternet domain name per RFC4120 section 6.2.1. The client side services supp= orting an nfs connection (idmapd, etc) would be "nfs/home.dns.here". I guess a better question would have been: Can hosts given NT_SRV_HST princ= ipal names still function within the Kerberos universe if their DNS entry d= oes not exist or does not match that in the principal name? If it's even po= ssible that a KDC or service could use the hostname in the principal as par= t of its authorization decision, and RFC4120 tells it how to derive hostnam= e from principal name, then it seems to me that this is an essential, not i= ncidental, feature of the Kerberos protocol. Does this suggest that if one wants to promote mobility-friendly deployment= s, that host principals should be NT_PRINCIPALS? Is it just lucky chance th= at the Solaris NFS stack works for mobile clients, or was it compelled to b= y the protocol itself? > I think you're asking if there's an offline (in that X is not reachable f= rom Y) > mechanism for X's users to be able to authenticate to Y. Yes. > Needham-Shroeder is out, as it's online. PK-based protocols can do it, b= ut > PKIX is not really offline: there's CRLs to check (and/or OCSP). > That includes PKINIT and a hypothetical PKCROSS, but again, if the client= 's > PKIX credentials aren't fresh enough then the protocol will become online > and therefore fail. A couple of things: online and offline are not necessarily binary quantitie= s. Maybe a service has a pre-configured path to a KDC unavailable to a clie= nt. Connectivity between entities may also be "spotty", allowing an opportu= nistic refreshing of credentials which does not necessarily align with dema= nd for services. One thing I have been asked to do in the past is to create a little portabl= e network having a raid server for scientists to upload data to during a fi= eld campaign. The usage pattern would be to come to the network island on t= he conference table, plug in, transfer data, paw through other people's dat= a, and go back to their hotels at night; checking email and such. In this situation, if their clients were "disconnect-aware", they could ren= ew their tickets every night. Alternatively, allowing services to accept ex= pired tickets would also go a long way toward making Kerberos more disconne= ct-tolerant. > There really isn't anything you can do here to address your hypothetical = use > case: Y will just have to be able to reach some part of X's infrastructur= e. This > isn't usually a problem, and it's neither the motivation for IAKERB, nor = PKINIT, > nor PKCROSS. What I'm really trying to get at is: disconnects break Kerberos so often th= at all machines using it have a fallback plan (cached credentials); so is i= t worth trying to define a fallback that's actually a part of the protocol? > IAKERB exists to deal with the lack of any network connectivity at networ= k > attachment time. The client wants to authenticate with a mechanism > (Kerberos, but it could be something else) that requires connectivity to = one > or more infrastructure services, but this can't be retrofitted into the n= etwork > attachment protocol (for whatever reasons). May I restate this? The Kerberos model assumes uninterrupted connectivity b= etween the KDC and all clients. IAKERB is motivated by the fact that an "ad= mission onto the network" authorization decision inherently means that the = client not on the network is not connected to the KDC. IAKERB enhances Kerb= eros by allowing new authorization decisions formerly prohibited by the tec= hnical design. IAKERB seems to have a lot of potential beyond its initial motivation. In p= articular, it could serve to reduce the number of situations in which a cli= ent would have to rely on cached credentials. This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you= have received this message in error, please notify the sender and delete t= he email immediately. From nobody Tue Feb 18 17:04:50 2014 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 E97221A0426 for ; Tue, 18 Feb 2014 17:04:48 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 hZ8SZxtStDHa for ; Tue, 18 Feb 2014 17:04:46 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id A30C61A029E for ; Tue, 18 Feb 2014 17:04:46 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id C9E002005D907; Tue, 18 Feb 2014 17:04:43 -0800 (PST) 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=MBWA7REOmZREOm om7afwgKL0EjM=; b=dowJuwDCDs6CGqYfGFk+LH6X75wT27fn0nBGOax0l0X6kv G0JNuvbpB3nnGPsTD8IsKwRxleH4Ltauh1rubhXGaFGg8FcrEtaDjMqjbRlbzHWP YMU1B+LGZfIHa7Hnhc5HPMr2xFJpZ8YqtJd34N2q2WOpnEVhXiDbRZIGEnWJI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPA id 705962005D904; Tue, 18 Feb 2014 17:04:43 -0800 (PST) Date: Tue, 18 Feb 2014 19:04:42 -0600 From: Nico Williams To: "Nordgren, Bryce L -FS" Message-ID: <20140219010440.GA23004@localhost> References: <82E7C9A01FD0764CACDD35D10F5DFB6E68DF75@001FSN2MPN1-045.001f.mgd2.msft.net> <20140218035821.GA20790@localhost> <82E7C9A01FD0764CACDD35D10F5DFB6E68E5CF@001FSN2MPN1-045.001f.mgd2.msft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E68E5CF@001FSN2MPN1-045.001f.mgd2.msft.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/e8btjfqrXACmXuyzBSRuS-Qku0Q Cc: "kitten@ietf.org" Subject: Re: [kitten] firewalls and cross realm trusts 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, 19 Feb 2014 01:04:49 -0000 On Wed, Feb 19, 2014 at 12:14:18AM +0000, Nordgren, Bryce L -FS wrote: > > Yes, it doesn't have to have its IP address be resolvable to its hostname, > > whatever it might be, nor does that need to match the laptop's client > > credentials in any way. > > I fear I miscommunicated. The laptop's identity in the KDC is likely > an NT_SRV_HST host/home.dns.here. The fact that NT_SRV_HST is used > [...] You're assuming that, probably due to habit from working with Kerberos, but nothing says that a) the laptop must have _client_ credentials, b) that they must be host-based, nor c) that they must correspond to whatever the laptop's apparent current FQDN might be. I know because I was involved in seeing to it that Solaris' NFS stack doesn't have these requirements :) Of course, it once did, and for the same reason that you thought it might: because someone thought it should because they thought that the situation (device authentication) was symmetric. But that's wrong: it's not symmetric at all. The client of a host-based service starts out knowing the desired service and host names, while a service does not start out knowing its client's names until they authenticate. Constructing a desired target service name out of the desired hostname for it is a form of light-weight authorization of the service to the client. Once the service is authenticated, it's also implicitly authorized. (This is feasible when the client has a priori knowledge of the server's hostname.) The service, on the other hand, has to authorize clients based on their authenticated names. > I guess a better question would have been: Can hosts given NT_SRV_HST > principal names still function within the Kerberos universe if their > DNS entry does not exist or does not match that in the principal name? As a client, yes, *typically* because most service applications don't actually care about the form of the client's name, with very few exceptions. I mentioned one such exception (root equivalent access to NFS shares). That exception derives from the fact that the server's root-equivalent authorization check is based on client name forms. Though even then, nothing actually requires such a check, and it exists as it does mostly due to inertia. > If it's even possible that a KDC or service could use the hostname in > the principal as part of its authorization decision, and RFC4120 tells > it how to derive hostname from principal name, then it seems to me > that this is an essential, not incidental, feature of the Kerberos > protocol. When acting as a client it's only incidental, not essential. When acting as a service it's essential (for services whose names are specifically intended to be host-based names). Nothing stops a service from requiring specific name forms from their clients, or applying arbitrary authorization checks. But generally the only requirement is that there be some sort of authorization, not a particular for. Whereas clients authorize host-based services by the form of their names matching the desired service and host names. > Does this suggest that if one wants to promote mobility-friendly > deployments, that host principals should be NT_PRINCIPALS? Is it just > lucky chance that the Solaris NFS stack works for mobile clients, or > was it compelled to by the protocol itself? It's not by chance. The Solaris Kerberos team noticed the need for that as part of eating their own dogfood long ago. [...] > > Needham-Shroeder is out, as it's online. PK-based protocols can do it, but > > PKIX is not really offline: there's CRLs to check (and/or OCSP). > > That includes PKINIT and a hypothetical PKCROSS, but again, if the client's > > PKIX credentials aren't fresh enough then the protocol will become online > > and therefore fail. > > A couple of things: online and offline are not necessarily binary > quantities. Maybe a service has a pre-configured path to a KDC > unavailable to a client. Connectivity between entities may also be > "spotty", allowing an opportunistic refreshing of credentials which > does not necessarily align with demand for services. Offline/online is very much a binary attribute of a protocol (or deployments). If two entities cannot authenticate (and authorize) each other due to needing but lacking connectivity to online infrastructure, then the protocol is online; otherwise it's offline. The only middle-of-the-road is a fallback from online to offline behavior, but such fallbacks generally have security considerations. If you have such a fallback then you have an offline protocol anyways. > One thing I have been asked to do in the past is to create a little > portable network having a raid server for scientists to upload data to > during a field campaign. The usage pattern would be to come to the > network island on the conference table, plug in, transfer data, paw > through other people's data, and go back to their hotels at night; > checking email and such. The host-based client credential naming issue is eithe a non-issue or a bug in the services you're using. The online nature of Kerberos (but also, really, PKIX) means that you must either give visitors local credentials or you must have connectivity back to [possibly a small portion of] the visitors' home networks. > In this situation, if their clients were "disconnect-aware", they > could renew their tickets every night. Alternatively, allowing > services to accept expired tickets would also go a long way toward > making Kerberos more disconnect-tolerant. That would work for PKIX (get OCSP responses and if the services are happy with at least 8-10 hours of OCSP response freshness, then all's good). For Kerberos the users would have to get all the service tickets they'll need during that day. One way or another that will mean cross-realm operations, *unless* you give visitors local credentials. > > There really isn't anything you can do here to address your hypothetical use > > case: Y will just have to be able to reach some part of X's infrastructure. This > > isn't usually a problem, and it's neither the motivation for IAKERB, nor PKINIT, > > nor PKCROSS. > > What I'm really trying to get at is: disconnects break Kerberos so > often that all machines using it have a fallback plan (cached > credentials); so is it worth trying to define a fallback that's > actually a part of the protocol? The nature of Needham-Schroeder is such that the protocol is and must be online unless you have all of a) a list of services you'll need tickets for a priori (difficult), b) connectivity and trust paths to get them once (difficult), c) workable freshness (ticket lifetime, cert/OCSP response freshness) policies (feasible). The story doesn't end there though. You can use hx509 to bridge Kerberos to PKI. And later you can even bridge back to Kerberos using PKINIT (this is my proposal for PKCROSS!). PKI requires only (c), workable freshness policies, so you can get there. The last mile will be online when using Kerberos, offline when using PKIX with the hx509-acquired cert. In the Kerberos case, if you're using hx509/PKCROSS then the last mile will be online but local to the local site (in your use case). So either way Kerberos and PKI can work for this use case. > > IAKERB exists to deal with the lack of any network connectivity at > > network attachment time. The client wants to authenticate with a > > mechanism (Kerberos, but it could be something else) that requires > > connectivity to one or more infrastructure services, but this can't > > be retrofitted into the network attachment protocol (for whatever > > reasons). > > May I restate this? The Kerberos model assumes uninterrupted > connectivity between the KDC and all clients. IAKERB is motivated by Well, Needham-Shroeder does. Kerberos is an incarnation of Needham-Schroeder, but it's not pure (PKINIT, hx509, past efforts at PKCROSS and PKTAPP). > the fact that an "admission onto the network" authorization decision > inherently means that the client not on the network is not connected > to the KDC. IAKERB enhances Kerberos by allowing new authorization > decisions formerly prohibited by the technical design. Well, by allowing message flow. Authorization is orthogonal (but you can't have it until you have authentication, which is what IAKERB makes feasible in these cases). > IAKERB seems to have a lot of potential beyond its initial motivation. > In particular, it could serve to reduce the number of situations in > which a client would have to rely on cached credentials. There's no reason not to use IAKERB outside its originally intended use cases, but those will remain the primary use cases. Don't mix up IAKERB with PKCROSS and such :) Nico -- From nobody Tue Feb 18 21:07:27 2014 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 8300B1A04B7 for ; Tue, 18 Feb 2014 21:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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, RP_MATCHES_RCVD=-0.548, 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 q78KGXNLKmtL for ; Tue, 18 Feb 2014 21:07:22 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 75FDA1A0557 for ; Tue, 18 Feb 2014 21:07:22 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id x3so2035773qcv.30 for ; Tue, 18 Feb 2014 21:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5kukI50XRysMz5MzhIa+C5cOxz8fRssuiD3PBQEdeG8=; b=J973c6rvQIexLg89YHRYLduyS/lnfaU0H1mfAq1w/ICTRiIsqVYPkod3ygrBEZX/zw JNHr1q8FrSwlQkW22KydQFxqtESYX30iiEK89R0MkFZIYLixpNlZMw85AwqtaqP7AI0h cO9qTIiGRLo6sckoxO5tSPgy8dyb/7ShAmh64= 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:date :message-id:subject:from:to:cc:content-type; bh=5kukI50XRysMz5MzhIa+C5cOxz8fRssuiD3PBQEdeG8=; b=Gi8mgQeNFnKnIROeEKrnyG9F8I36OuOqWLSHPuGW14Ekf3TxqXVNxjD6/W59dgMSt6 lU7oM2vNzId6HOj/ULtImCd1tgUwkhaQAOkRl7QkS0npllsHSpG+xL6DLkQoQx1CRfRc pKHZuMVGJDcEG6UoXIrpr5l8qKGhtU1BI5kEni4leIeu+kFB5iTWY8OlMT7M6qQeW8AH Ct9hbzAVRIcGOsEn2LZGWC5ZAbE2rtHz8W6q0IxtM5VQPkp8Eimomec1NcnI1hmXPr3j Fi/ekO+fraETyznzvR6gqvwmWmxiHSzj4t6M7oVKPamJp4TZbag5w4Kpg/aU/0+GioGB beyg== X-Gm-Message-State: ALoCoQk/rYCiQqQYcD1gXke2V3cKDQUmlOdnZ5qs4aFSpi9FTz3N2sZcmECp4nPRwwdAnGIDLCGzak5zuC3Oov14JOuw0inqJaqMBHnzFX+SgeiG1SrnDynjxdhGBMEFkLoghuJBQq5AzLCSTjlNt2RUYGf3b7G/LRfrquGewepyg/P2s4/Lz8g5kaFNIJh5OSgF+NgtP/MO MIME-Version: 1.0 X-Received: by 10.140.39.20 with SMTP id u20mr44733qgu.73.1392786439065; Tue, 18 Feb 2014 21:07:19 -0800 (PST) Received: by 10.229.113.131 with HTTP; Tue, 18 Feb 2014 21:07:18 -0800 (PST) In-Reply-To: <1389054308.10730.YahooMailNeo@web125604.mail.ne1.yahoo.com> References: <52AE9A65.1010700@oracle.com> <1389054229.19390.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1389054308.10730.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Tue, 18 Feb 2014 21:07:18 -0800 Message-ID: From: Ryan Troll To: Bill Mills Content-Type: multipart/alternative; boundary=001a11c123b6f2fef904f2bb5c47 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/7CQJSZSzgrM8fl3JveEa5CkANK0 Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 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, 19 Feb 2014 05:07:25 -0000 --001a11c123b6f2fef904f2bb5c47 Content-Type: text/plain; charset=UTF-8 Version -13 was released, and "user=" is not present. Can this be placed back in prior to approval as an RFC? It's optional, present to encourage implementors to use the same field name for this data (if required by their implementation), and was previously part of the GS2-header which was recently removed. -R On Mon, Jan 6, 2014 at 4:25 PM, Bill Mills wrote: > That said, your extant implementation might argue for leaving the GS2 > header in there... > > > > -bill > > > -------------------------------- > William J. Mills > "Paranoid" Yahoo! > > > > On , Bill Mills wrote: > Now that it's not duplicating the gs2 stuff it makes some sense. It can > be easily added back. > > Any objection to adding the "user" field back in? > > -bill > > > -------------------------------- > William J. Mills > "Paranoid" Yahoo! > > > > On Monday, January 6, 2014 4:10 PM, Ryan Troll > wrote: > > > MAJOR: > > * Removing the GS2-header (which was done in revision -11) also removed > the ability for the client to specify an authorization identity. If the > lack of an authorization identity is acceptable (and I suspect it is not > for some), then the document needs to state these mechanisms do not support > authz-id. > > > > The loss of the authz-id is a problem for us. Last year we discussed the > use case with the list, came to the conclusion that what our use case > needed was access to the authz-id; and agreed that we'd pull it from the > GS2-header. > > Now that the GS2-header is gone, it would be beneficial to provide a > standard, but optional, way for clients to provide the authz-id to the > service. This would ensure compatibility across services which require the > authz-id; while not requiring it for *all* SASL-OAuth clients. > > The original proposal had been to define a reserved keyword ("user") which > could be part of the initial client response. Should this be re-added? > > -R > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > > > > --001a11c123b6f2fef904f2bb5c47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Version -13 was released, and "user=3D" is not p= resent.

Can this be placed back in prior to approval as = an RFC? =C2=A0It's optional, present to encourage implementors to use t= he same field name for this data (if required by their implementation), and= was previously part of the GS2-header which was recently removed.

-R




On Mon, Jan 6, 2014 = at 4:25 PM, Bill Mills <wmills@yahoo-inc.com> wrote:
That said, your extant i= mplementation might argue for leaving the GS2 header in there...


=C2=A0
-bill


--------------------------= ------
William J. Mills
"Paranoid" Yahoo!



On , Bill Mills <wmills@yahoo-inc.com> wrote:
Now that it's not duplic= ating the gs2 stuff it makes some sense.=C2=A0 It can be easily added back.=

Any objection to adding the "= user" field back in?
=C2=A0
-bill


= --------------------------------
William J. Mills
"Paranoid" Yahoo!


On Monday, January 6, 2014 4:10 PM, Ryan Troll <rtroll@googlers.com> wrote= :

MAJOR:

* Removing the GS2-header (which was done in revision -11) also removed the= ability for the client to specify an authorization identity. =C2=A0If the = lack of an authorization identity is acceptable (and I suspect it is not fo= r some), then the document needs to state these mechanisms do not support a= uthz-id.


The loss o= f the authz-id is a problem for us. =C2=A0Last year we discussed the use ca= se with the list, came to the conclusion that what our use case needed was = access to the authz-id; and agreed that we'd pull it from the GS2-heade= r.

Now that the GS2-header is gone, it woul= d be beneficial to provide a standard, but optional, way for clients to pro= vide the authz-id to the service. =C2=A0This would ensure compatibility acr= oss services which require the authz-id; while not requiring it for *all* S= ASL-OAuth clients.

The original proposal had been to define= a reserved keyword ("user") which could be part of the initial c= lient response. =C2=A0Should this be re-added?

-R
=C2=A0

_______________= ________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitte= n


<= /div>



--001a11c123b6f2fef904f2bb5c47-- From nobody Tue Feb 18 21:39:36 2014 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 57CA01A0424 for ; Tue, 18 Feb 2014 21:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.22 X-Spam-Level: X-Spam-Status: No, score=-16.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] 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 UYYObxM5w-Ke for ; Tue, 18 Feb 2014 21:39:32 -0800 (PST) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id 794811A0332 for ; Tue, 18 Feb 2014 21:39:32 -0800 (PST) Received: from GQ1-EX10-CAHT19.y.corp.yahoo.com (gq1-ex10-caht19.corp.gq1.yahoo.com [10.73.119.200]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s1J5d116050359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Feb 2014 21:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1392788343; bh=XI3ccYWnmyGxia5y+PQq4yrx83SPIws3NMXNZu/x4WA=; h=References:Date:From:Reply-To:Subject:In-Reply-To; b=LIaNhcJwWCpGqq8gZx1S617o6nJ3a/nz4x1inHsSBXoI5UWCEQhCj+pdUdh9Wn3hh lyANZeIMPplhTrIbBCmMh2lCvzt0BqPwUyliILVFy1TX2+F5L67P+eiLNS69HWzBLA /QMYkNkLTmsi5ESXTxi5ixveY8j4hbK0eeQyY7is= Received: from omp1039.mail.ne1.yahoo.com (98.138.88.239) by GQ1-EX10-CAHT19.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 18 Feb 2014 21:39:00 -0800 Received: (qmail 55410 invoked by uid 1000); 19 Feb 2014 05:38:59 -0000 Received: (qmail 16262 invoked by uid 60001); 19 Feb 2014 05:38:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1392788339; bh=ohgaC1C6B+XL/vrR1hWbGQWANCHk5CdvwnOYh49S6ao=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CfjHuJAFSpY0ZLxDyAvsecRst1ezdFX0Xgw3kJnnq2A5CshTe1eFYIKAgktj4epbiymDG4uwShSc9dpJi4fGGTaWGx+ZZGgXjO0P/LkTlCHeEIvkjwQCgA++aOpbyfFfsGMf9ycLeSTh6yi561aLIbLvxTZhOLUTt4MswlvWeRM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=U9JO2LVA+wjqIPOyw6xFrHhquQBcq77jzgyCj3kMG2o4rSL5qi4kbssJk26l/gr2Y25baijBOvR+pXlrDSoQsjR9AbTie4FT5OA92EeRI1Z04Tgppi0PAqjf+H339cRPyP0fq26tgQiZU/sY2m7xO7EkpNp3vibRu3Cb1QGARk0=; X-YMail-OSG: PWF6V0kVM1lT8Iy04G3Ch.KZ9PxvotJnUqvxUzkax4hJNqZ RQWLnLVV53qUYluvNBwWXk7pndEDP84QCFc9Kg5kBgNtZi3u3nDYioUCN.5C MSLW2_lSjOsCt.VLpmRv29OorpH7shbBZ30ua.Roo_IRz54KkyO8FxKBVrRY 1SleNITU70Ph1Uj8.f_l9oSpuKG3k7lXn70ECXEiV95u4JSD4KXZKzGLHabv zWmJP.EdLGc.P9pDO_POMWYVO2Oq1MbWWm2NlsLMdXJvvJG_6io3gO54ZI.R 9MlKzpEa1ldQrBU9ZFLN7p5igLpJRgRw- Received: from [99.31.212.42] by web125602.mail.ne1.yahoo.com via HTTP; Tue, 18 Feb 2014 21:38:59 PST X-Rocket-MIMEInfo: 002.001, TXkgZXJyb3IsIEkgd2FzIHN1cHBvc2VkIHRvIHB1dCBpdCBiYWNrLgoKQ2FuIHdlIGZpeCBpdD8KCgrCoAotYmlsbAoKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpXaWxsaWFtIEouIE1pbGxzCiJQYXJhbm9pZCIgTWVtYmVyc2hpcCBZYWhvbyEKCgoKCgpPbiBUdWVzZGF5LCBGZWJydWFyeSAxOCwgMjAxNCA5OjA3IFBNLCBSeWFuIFRyb2xsIDxydHJvbGxAZ29vZ2xlcnMuY29tPiB3cm90ZToKIApWZXJzaW9uIC0xMyB3YXMgcmVsZWFzZWQsIGFuZCAidXNlcj0iIGlzIG5vdCBwcmVzZW50LgoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <52AE9A65.1010700@oracle.com> <1389054229.19390.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1389054308.10730.YahooMailNeo@web125604.mail.ne1.yahoo.com> Message-ID: <1392788339.98053.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Tue, 18 Feb 2014 21:38:59 -0800 From: Bill Mills To: Ryan Troll In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1088529044-532608147-1392788339=:98053" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 788343005 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/uAeCtirH5fCFTTT1UWSIN5U3UmM Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 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: Wed, 19 Feb 2014 05:39:34 -0000 ---1088529044-532608147-1392788339=:98053 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My error, I was supposed to put it back.=0A=0ACan we fix it?=0A=0A=0A=A0=0A= -bill=0A=0A=0A=0A--------------------------------=0AWilliam J. Mills=0A"Par= anoid" Membership Yahoo!=0A=0A=0A=0A=0A=0AOn Tuesday, February 18, 2014 9:0= 7 PM, Ryan Troll wrote:=0A =0AVersion -13 was release= d, and "user=3D" is not present.=0A=0ACan this be placed back in prior to a= pproval as an RFC? =A0It's optional, present to encourage implementors to u= se the same field name for this data (if required by their implementation),= and was previously part of the GS2-header which was recently removed.=0A= =0A-R=0A=0A=0A=0A=0A=0A=0AOn Mon, Jan 6, 2014 at 4:25 PM, Bill Mills wrote:=0A=0AThat said, your extant implementation might ar= gue for leaving the GS2 header in there...=0A>=0A>=0A>=0A>=0A>=A0=0A>-bill= =0A>=0A>=0A>=0A>--------------------------------=0A>William J. Mills=0A>"Pa= ranoid" Yahoo!=0A>=0A>=0A>=0A>=0A>=0A>=0A>On , Bill Mills wrote:=0A> =0A>Now that it's not duplicating the gs2 stuff it makes s= ome sense.=A0 It can be easily added back.=0A>=0A>=0A>=0A>Any objection to = adding the "user" field back in?=0A>=0A>=A0=0A>-bill=0A>=0A>=0A>=0A>-------= -------------------------=0A>William J. Mills=0A>"Paranoid" Yahoo!=0A>=0A>= =0A>=0A>=0A>=0A>=0A>On Monday, January 6, 2014 4:10 PM, Ryan Troll wrote:=0A> =0A>=0A>>MAJOR:=0A>>=0A>>* Removing the GS2-header= (which was done in revision -11) also removed the ability for the client t= o specify an authorization identity. =A0If the lack of an authorization ide= ntity is acceptable (and I suspect it is not for some), then the document n= eeds to state these mechanisms do not support authz-id.=0A>=0A>=0A>=0A>=0A>= The loss of the authz-id is a problem for us. =A0Last year we discussed the= use case with the list, came to the conclusion that what our use case need= ed was access to the authz-id; and agreed that we'd pull it from the GS2-he= ader.=0A>=0A>=0A>Now that the GS2-header is gone, it would be beneficial to= provide a standard, but optional, way for clients to provide the authz-id = to the service. =A0This would ensure compatibility across services which re= quire the authz-id; while not requiring it for *all* SASL-OAuth clients.=0A= >=0A>=0A>The original proposal had been to define a reserved keyword ("user= ") which could be part of the initial client response. =A0Should this be re= -added?=0A>=0A>=0A>-R=0A>=A0=0A>=0A>_______________________________________= ________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/= mailman/listinfo/kitten=0A>=0A>=0A>=0A>=0A> ---1088529044-532608147-1392788339=:98053 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
My error,= I was supposed to put it back.

Can we fix it?
=
 
-bill


-----------------------------= ---
William J. Mills
"Paranoid" Membership Yahoo!

<= /div>


On Tuesday, February 18, 2014 9:= 07 PM, Ryan Troll <rtroll@googlers.com> wrote:
= Version -13 was released, and "user=3D" is not present.

Can this be placed back in prior to approval as an RFC? &nbs= p;It's optional, present to encourage implementors to use the same field na= me for this data (if required by their implementation), and was previously = part of the GS2-header which was recently removed.
=0A

-R


=

On Mon, Jan 6, 2014 at 4:25 PM, Bill Mills <wmills@yahoo-inc.com&g= t; wrote:
=0A
That said, your extant implementation migh= t argue for leaving the GS2 header in there...
= =0A

 = ;
-bill


<= /div>
-------------------= -------------
=0AWilliam J. Mills
"Para= noid" Yahoo!



=0A
On , Bill M= ills <wmills@yaho= o-inc.com> wrote:
=0A
Now that it's not duplicating the gs2 stuff it makes= some sense.  It can be easily added back.
=0A
<= br clear=3D"none">
Any objection to adding the "user" = field back in?
=0A
 
-bil= l


--------------------------------=0AWilliam J. Mills
"Paranoid" Yahoo!



=0A
On Monday, January 6, 2014 4:10 PM, Ryan Troll <rtroll@googlers.com> wrote:=
=0A

=0AMAJOR:
=0A
=0A* Removing the GS2-header (which was done in revision -11) als= o removed the ability for the client to specify an authorization identity. =  If the lack of an authorization identity is acceptable (and I suspect= it is not for some), then the document needs to state these mechanisms do = not support authz-id.
=0A=0A

=
The loss of the authz-id is a problem for us.=  Last year we discussed the use case with the list, came to the concl= usion that what our use case needed was access to the authz-id; and agreed = that we'd pull it from the GS2-header.
=0A=0A

<= /div>
Now that the GS2-header is gone, it would be beneficial to provid= e a standard, but optional, way for clients to provide the authz-id to the = service.  This would ensure compatibility across services which requir= e the authz-id; while not requiring it for *all* SASL-OAuth clients.
= =0A=0A

The original proposal had been to = define a reserved keyword ("user") which could be part of the initial clien= t response.  Should this be re-added?

=0A
-R
 
=0A
<= /div>
______________________________________________= _
Kitten mailing list
Kitten@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/kitten<= br clear=3D"none">


=
=0A


<= /div>


---1088529044-532608147-1392788339=:98053-- From nobody Wed Feb 19 21:01:35 2014 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 659861A0320 for ; Wed, 19 Feb 2014 21:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 dQL9bhzTrNRm for ; Wed, 19 Feb 2014 21:01:33 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id BB9D91A0312 for ; Wed, 19 Feb 2014 21:01:32 -0800 (PST) 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 s1K51SfC021921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 20 Feb 2014 05:01:29 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1K51SAa015093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Feb 2014 05:01:28 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s1K51Rb7007887 for ; Thu, 20 Feb 2014 05:01:27 GMT Received: from [10.159.117.29] (/10.159.117.29) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Feb 2014 21:01:27 -0800 Message-ID: <53058C22.4010703@oracle.com> Date: Wed, 19 Feb 2014 22:01:22 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20131203 Thunderbird/17.0.6 MIME-Version: 1.0 To: "kitten@ietf.org" References: <52E4B9D0.3080404@oracle.com> In-Reply-To: <52E4B9D0.3080404@oracle.com> X-Forwarded-Message-Id: <52E4B9D0.3080404@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TTVNpOLBiT9qENq9QCiI3dHQGNg Subject: [kitten] Consensus Calls for draft-ietf-kitten-aes-cts-hmac-sha2 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, 20 Feb 2014 05:01:34 -0000 The WG is making the following consensus calls on draft-ietf-kitten-aes-cts-hmac-sha2: 1. Do we adopt CTS mode for this draft? a. Yes b. No c. Don't care or need more information 2. Do we use the confounder algorithm as specified in RFC 3961/3962 for this draft? a. Yes b. No c. Don't care or need more information If you answered "no" to any of the above, please state your objections and/or alternatives. Please provide your input before March 6th. Thank you. Shawn. -- kitten co-chair From nobody Wed Feb 19 21:22:04 2014 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 8636F1A0312 for ; Wed, 19 Feb 2014 21:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 rBp9yJqPyuuo for ; Wed, 19 Feb 2014 21:22:00 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id B178D1A02D8 for ; Wed, 19 Feb 2014 21:21:59 -0800 (PST) X-AuditID: 1209190f-f790b6d000000c3a-56-530590f349b4 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id C4.B9.03130.3F095035; Thu, 20 Feb 2014 00:21:55 -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 s1K5LtUG010401 for ; Thu, 20 Feb 2014 00:21:55 -0500 Received: from [18.101.8.69] (vpn-18-101-8-69.mit.edu [18.101.8.69]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s1K5LrG5023992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Feb 2014 00:21:55 -0500 Message-ID: <530590F0.9030904@mit.edu> Date: Thu, 20 Feb 2014 00:21:52 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: kitten@ietf.org References: <52E4B9D0.3080404@oracle.com> <53058C22.4010703@oracle.com> In-Reply-To: <53058C22.4010703@oracle.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6novt5AmuwwcXHphZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqaO/awFN5grvlxpYGtg/MfUxcjJISFgIjH91CY2CFtM4sK9 9WC2kMBsJokPTzK6GLmA7OOMEj8m9bFBONeZJKZ0dbOCVPEKqEk83PSOuYuRg4NFQFVi4qR0 kDCbgLLEwbPfWEBsUYEwibv/1zJClAtKnJz5BCwuIiAssXsrSCsnh7CAr8Sfg6uhFrtLfP16 ix3E5hTQknhx5xvUoZIS2xYdA4szC+hIvOt7wAxhy0tsfzuHeQKj4CwkK2YhKZuFpGwBI/Mq RtmU3Crd3MTMnOLUZN3i5MS8vNQiXRO93MwSvdSU0k2MoFDllOTfwfjtoNIhRgEORiUeXoar LMFCrIllxZW5hxglOZiURHmreliDhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw8mQC5XhTEiur UovyYVLSHCxK4ry1Fr+ChATSE0tSs1NTC1KLYLIyHBxKEryCwJgUEixKTU+tSMvMKUFIM3Fw ggznARr+sR9keHFBYm5xZjpE/hSjopQ4rzhIQgAkkVGaB9cLSyWvGMWBXhHm/QFSxQNMQ3Dd r4AGMwEN9trLCDK4JBEhJdXAyHnb1FIp8GvLM22ZP/5JC5pWlvzg8dRZElw0//Fk3R0TtHQ2 REy6zW33/PTqJg4vJ+kohS077VhOBHypnV6fGOi8Ovpnn0No0iSprMNsGs9qU6O2GB4IcTx8 dofzhrALQazhybHKfflhCe0zrn5XzWI1W8JZcbpaLb/7w23tBuW0U9o2B98osRRnJBpqMRcV JwIABumYmgADAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/OSf4PNKRIP_GbtdZnOKAQfglQP0 Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-aes-cts-hmac-sha2 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, 20 Feb 2014 05:22:01 -0000 On 02/20/2014 12:01 AM, Shawn M Emery wrote: > The WG is making the following consensus calls on > draft-ietf-kitten-aes-cts-hmac-sha2: > > 1. Do we adopt CTS mode for this draft? Yes. > 2. Do we use the confounder algorithm as specified in RFC 3961/3962 for > this draft? Yes. You didn't ask for rationale for positive answers, but the first two responses in http://www.ietf.org/mail-archive/web/kitten/current/msg04498.html summarize my reasoning. From nobody Wed Feb 19 21:28:20 2014 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 6225F1A054A for ; Wed, 19 Feb 2014 21:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] 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 hPFG9XJptVqD for ; Wed, 19 Feb 2014 21:28:13 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by ietfa.amsl.com (Postfix) with ESMTP id D2D591A0329 for ; Wed, 19 Feb 2014 21:28:13 -0800 (PST) Received: from GQ1-EX10-CAHT07.y.corp.yahoo.com (gq1-ex10-caht07.corp.gq1.yahoo.com [10.73.118.86]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s1K5Rs4k056144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Feb 2014 21:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1392874075; bh=6fdIBH30QiC9C91b40uvFZ82WrpCGZjS0JWVcQmfPq8=; h=References:Date:From:Reply-To:Subject:In-Reply-To; b=am4eiFSX7boQRKl1bVUXsTBOhTD9HS0MGrSCr232Olf4pjfUaYkIIv7Ikp/D9rCeP ed7nVDUhBLFxoY3UVhCtUrsZGhpm3kPqlijjhgT2Rgqn9g+EAa+B9KFDu/wTL6h5/+ +1cP82+Q5uTYhzzwp9u+4bzcRke10UDYTdispNAY= Received: from omp1088.mail.ne1.yahoo.com (98.138.101.177) by GQ1-EX10-CAHT07.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 19 Feb 2014 21:27:53 -0800 Received: (qmail 6606 invoked by uid 1000); 20 Feb 2014 05:27:52 -0000 Received: (qmail 83861 invoked by uid 60001); 20 Feb 2014 05:27:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1392874072; bh=NoIMcnjL4Jlf7L9wuH1p/FxnbMTN1I9OVt9MRzdLpEg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ZFarm44luog3svq+sLJKLrpSL++st2Uo9UiSveMYB3xR1y4UagxsyeWHAwzx93ZEZuyABXFDlAtdUXTgdVT7EGMSG+p+dMWlbKfKdRz/wzEa6og35DfB6PVloIScsNE6BNbj+nFAtecUz9MEw+/jO7eaYriNFjh2YKjbV0yBO64= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Xgc4W+99x2fk5jOeWQINTixtuJYlM/nwhJWbA//x8We0VJpIZPNwfxRYpg36ubFRq1DQC2uknTOegG6Ok8Uh6mz5ATW5jnNV2F1c+5GuGStbyRvml6pHKBidsUeJ7LJQtSyu84py/nFm3336484yLyqsc3QT3yNNPd+8LIuQfYA=; X-YMail-OSG: rezBShAVM1kWrUkFU9.2uTRDaGcaBfQzdmDGSTjHUwhyq9u JzfgPYc9tSx26VAL4rL7Euldnh_GhjvJK_NfzH2dFhBA8_J9f3qVTxiXonBL 3zjX8XLfb4l8.dDzFFSGUWFEiFRLU8Lf0lYWfZXsi8UstH9606AE0r.IyDnS XIZvKlwrZA5QiiXeS5zNpBFWjw8MhnuJtCiI6hj9RAdPwnLqUMvglXN.8MXE DRwFaexxvTe66I4bmYBDu.Qf2HUXlhBpohDy6ZgG8ACxENMvzNvVehEHhxzd gnxxrZfPNe3gbzj2d6tI- Received: from [209.131.62.115] by web125605.mail.ne1.yahoo.com via HTTP; Wed, 19 Feb 2014 21:27:52 PST X-Rocket-MIMEInfo: 002.001, MSBDCjIgQwoKU29ycnksIGJ1dCBJIGhhdmVuJ3QgYmVlbiBrZWVwaW5nIHVwIG9uIHRoYXQgZHJhZnQuwqAgSWYgeW91IG5lZWQgYW5vdGhlciBzZXJpb3VzIHJlYWQgb24gaXQgSSBjYW4gdGFrZSBhIGxvb2sgYnV0IEknbSBraW5kYSBzbGFtbWVkLgoKwqAKLWJpbGwKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KV2lsbGlhbSBKLiBNaWxscwoiUGFyYW5vaWQiIE1VWCBZYWhvbyEKCgoKCgpPbiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE5LCAyMDE0IDk6MDIgUE0sIFNoYXduIE0gRW1lcnkgPHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <52E4B9D0.3080404@oracle.com> <53058C22.4010703@oracle.com> Message-ID: <1392874072.86284.YahooMailNeo@web125605.mail.ne1.yahoo.com> Date: Wed, 19 Feb 2014 21:27:52 -0800 From: Bill Mills To: Shawn M Emery , "kitten@ietf.org" In-Reply-To: <53058C22.4010703@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1124617404-1632427176-1392874072=:86284" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 874074001 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/U8D0V4I8ZaspJzjFpSFQI4HvRcw Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-aes-cts-hmac-sha2 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: Thu, 20 Feb 2014 05:28:17 -0000 ---1124617404-1632427176-1392874072=:86284 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1 C=0A2 C=0A=0ASorry, but I haven't been keeping up on that draft.=A0 If yo= u need another serious read on it I can take a look but I'm kinda slammed.= =0A=0A=A0=0A-bill=0A=0A=0A=0A--------------------------------=0AWilliam J. = Mills=0A"Paranoid" MUX Yahoo!=0A=0A=0A=0A=0A=0AOn Wednesday, February 19, 2= 014 9:02 PM, Shawn M Emery wrote:=0A =0AThe WG is = making the following consensus calls on draft-ietf-kitten-aes-cts-hmac-sha2= :=0A=0A1. Do we adopt CTS mode for this draft?=0A=A0 =A0 a. Yes=0A=A0 =A0 = b. No=0A=A0 =A0 c. Don't care or need more information=0A=0A2. Do we use = the confounder algorithm as specified in RFC 3961/3962 for this draft?=0A= =A0 =A0 a. Yes=0A=A0 =A0 b. No=0A=A0 =A0 c. Don't care or need more info= rmation=0A=0AIf you answered "no" to any of the above, please state your ob= jections and/or alternatives.=0A=0APlease provide your input before March 6= th.=A0 Thank you.=0A=0AShawn.=0A--=0Akitten co-chair=0A=0A_________________= ______________________________=0AKitten mailing list=0AKitten@ietf.org=0Aht= tps://www.ietf.org/mailman/listinfo/kitten ---1124617404-1632427176-1392874072=:86284 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
1 C
2 = C

Sorry, but I haven't been keeping up on that draft.  If you n= eed another serious read on it I can take a look but I'm kinda slammed.
=
 
-bill


--------------------------------William J. Mills
"Paranoid" MUX Yahoo!



On Wednesday, February 19, 2014 9:02 PM, Shawn= M Emery <shawn.emery@oracle.com> wrote:
The WG is making the following consensus calls on draft-ietf= -kitten-aes-cts-hmac-sha2:

1. Do we adopt CTS mode for this draft?    a. Yes
    b. No
    c. Don't = care or need more information

2. Do we use the confounder algorithm = as specified in RFC 3961/3962 for this draft?
    a. Yes
&= nbsp;   b. No
    c. Don't care or need more informatio= n

If you answered "no" to any of the above, please state your object= ions and/or alternatives.

Please provide your input before March 6th= .  Thank you.

Shawn.
--
kitten co-chair

__________= _____________________________________
Kitten mailing list
Kitten@ietf.org=
https://www.ietf.org/mailman/listinfo/kitten

=
---1124617404-1632427176-1392874072=:86284-- From nobody Wed Feb 19 21:33:11 2014 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 1B5BA1A0618 for ; Wed, 19 Feb 2014 21:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 O58FH41Ct_98 for ; Wed, 19 Feb 2014 21:33:07 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id E28A61A0329 for ; Wed, 19 Feb 2014 21:33:07 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 665AC1B4059 for ; Wed, 19 Feb 2014 21:33:04 -0800 (PST) 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=arMEg+Np7ApoJ9KJ9EHq EWy7ztU=; b=RMqH3bcTiSgRK48Ovzf21ke5rNuWwXr/w99CI8hQ7H5aSmOWgyVf 4rtHmD4AkQHiPCjHRExcOoy7mbKEd+dLUvuQxi0grKWmN8aPFvPVNE/efpkopNGl p08lYXpJGymzFUqUhrD20x4X3+bE5AhOCWcd4cYQ2dRlMKfYxoMA0sI= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 109331B4058 for ; Wed, 19 Feb 2014 21:33:03 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id f8so5479118wiw.13 for ; Wed, 19 Feb 2014 21:33:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BGj3NC70v2asuNUpChwJYbj90wlvDhL9VMkfHIHCUZo=; b=YlAJ5TL9gxUodrZ/7qPX/QSL/mvZ75CbAre7YAlDWWOagNun4hqFVr9T/81ppnWCtk Y79H5KEFckuI7HwNefRMdFJHx4YzcDKMZ3nw4dhap8S110ykc1T5vlcdco8z4IXO8cco w1xvqT1ypCf5w6yBGQKipzb+EFjW9D7swKMpRIgPTyFgoIJIbbJWzyw9VO/ozKoGAVZX GoouAtjoF+H+s/leC8XGi0GMpbxLtcaKvKXESyNp1whIyHM0SuSelg8L4lknNhQtFvBs zkVBLDsrVCRdqcpI+KszTQB6YLA9RWACIXjpWBMlS52wzlPg5o5LHFs+Ea16Q6l1+JEt TvPg== MIME-Version: 1.0 X-Received: by 10.180.102.42 with SMTP id fl10mr5077702wib.42.1392874382422; Wed, 19 Feb 2014 21:33:02 -0800 (PST) Received: by 10.217.108.132 with HTTP; Wed, 19 Feb 2014 21:33:02 -0800 (PST) In-Reply-To: <53058C22.4010703@oracle.com> References: <52E4B9D0.3080404@oracle.com> <53058C22.4010703@oracle.com> Date: Wed, 19 Feb 2014 23:33:02 -0600 Message-ID: From: Nico Williams To: Shawn M Emery Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/sWWhOwI1Lzhd1ZEnWTKfg9hplGY Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-aes-cts-hmac-sha2 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, 20 Feb 2014 05:33:09 -0000 On Wed, Feb 19, 2014 at 11:01 PM, Shawn M Emery wrote: > The WG is making the following consensus calls on > draft-ietf-kitten-aes-cts-hmac-sha2: > > 1. Do we adopt CTS mode for this draft? > a. Yes > b. No > c. Don't care or need more information a. Yes. > 2. Do we use the confounder algorithm as specified in RFC 3961/3962 for this > draft? > a. Yes > b. No > c. Don't care or need more information c. No opinion. Getting a secure AES-SHA2 enctype is more important than optimizing one block operation away. Nico -- From nobody Thu Feb 20 06:06:09 2014 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 EDD171A0061 for ; Thu, 20 Feb 2014 06:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 7Wp0HmEpWHcn for ; Thu, 20 Feb 2014 06:06:02 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9421A0177 for ; Thu, 20 Feb 2014 06:05:57 -0800 (PST) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1KE5qtx021467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Feb 2014 09:05:53 -0500 Received: from [10.3.113.6] ([10.3.113.6]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1KE5pY9030413; Thu, 20 Feb 2014 09:05:51 -0500 From: Simo Sorce To: Shawn M Emery In-Reply-To: <53058C22.4010703@oracle.com> References: <52E4B9D0.3080404@oracle.com> <53058C22.4010703@oracle.com> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Thu, 20 Feb 2014 09:05:50 -0500 Message-ID: <1392905150.22754.210.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/orF76kfkJnLkLw2-AJveN_JnT8g Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-aes-cts-hmac-sha2 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, 20 Feb 2014 14:06:04 -0000 On Wed, 2014-02-19 at 22:01 -0700, Shawn M Emery wrote: > The WG is making the following consensus calls on draft-ietf-kitten-aes-cts-hmac-sha2: > > 1. Do we adopt CTS mode for this draft? > a. Yes > b. No > c. Don't care or need more information Yes > 2. Do we use the confounder algorithm as specified in RFC 3961/3962 for this draft? > a. Yes > b. No > c. Don't care or need more information Yes Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Feb 20 10:16:21 2014 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 E01671A019E for ; Thu, 20 Feb 2014 10:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 7pjXdhbRpvem for ; Thu, 20 Feb 2014 10:16:18 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 548021A0235 for ; Thu, 20 Feb 2014 10:16:18 -0800 (PST) X-AuditID: 1209190f-f790b6d000000c3a-4a-5306466e4d4f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 2F.2D.03130.E6646035; Thu, 20 Feb 2014 13:16:14 -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 s1KIGDve029756 for ; Thu, 20 Feb 2014 13:16:14 -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 s1KIGB8g018664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Feb 2014 13:16:13 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s1KIGBwi004826; Thu, 20 Feb 2014 13:16:11 -0500 (EST) Date: Thu, 20 Feb 2014 13:16:11 -0500 (EST) From: Benjamin Kaduk To: "kitten@ietf.org" In-Reply-To: <53058C22.4010703@oracle.com> Message-ID: References: <52E4B9D0.3080404@oracle.com> <53058C22.4010703@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUixG6nrpvnxhZscHmTtMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcWNdH3vBDuaK9auPsDcw7mLqYuTkkBAwkWhoOQ1li0lcuLee rYuRi0NIYDaTxOXXHxhBEkICxxklZvYlQSRuMEmsWfCLFcJpYJR4/WMfK0gVi4C2xOSb05lB bDYBFYmZbzaygdgiAuoSew9NZQGxhQX8Jc7ceQFWwymgJfHizjew1bwCDhLnmm8yQWxzl/j6 9RY7iC0qoCOxev8UFogaQYmTM5+A2cwClhLn/lxnm8AoMAtJahaS1AJGplWMsim5Vbq5iZk5 xanJusXJiXl5qUW6Jnq5mSV6qSmlmxhB4ccpyb+D8dtBpUOMAhyMSjy8J6TYgoVYE8uKK3MP MUpyMCmJ8s5wAgrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4W2yAcrxpiRWVqUW5cOkpDlYlMR5 ay1+BQkJpCeWpGanphakFsFkZTg4lCR461yBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGV7uADC8u SMwtzkyHyJ9iVJQS570IkhAASWSU5sH1wtLDK0ZxoFeEIap4gKkFrvsV0GAmoMElG1lBBpck IqSkGhgrVC3dP72vLl34u/uZXUXNyprKU99rjy77mFs0OeqEVOL/m2dmbTyso1N/J6Zq3RqD 2iDHgo02gRkM335uvrpka5G418qo7Bt/PZ62tn5bacBgl2P1bsGjF7rsNYd3HKs9UX06udJ8 aeXWMj2OOwlae+t9VBkOv3mou2jDdCu2v69kQrk8mZcqsRRnJBpqMRcVJwIAy9nezeoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/lD-xouhBp-NAxH8ancWwmPG432Y Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-aes-cts-hmac-sha2 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, 20 Feb 2014 18:16:20 -0000 On Wed, 19 Feb 2014, Shawn M Emery wrote: > The WG is making the following consensus calls on > draft-ietf-kitten-aes-cts-hmac-sha2: > > 1. Do we adopt CTS mode for this draft? > a. Yes > b. No > c. Don't care or need more information (a) > 2. Do we use the confounder algorithm as specified in RFC 3961/3962 for this > draft? > a. Yes > b. No > c. Don't care or need more information (a) -Ben From nobody Thu Feb 20 15:38:49 2014 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 491E11A034C for ; Thu, 20 Feb 2014 15:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 pWBiqR6cFKsc for ; Thu, 20 Feb 2014 15:38:45 -0800 (PST) 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 435771A0350 for ; Thu, 20 Feb 2014 15:38:45 -0800 (PST) X-AuditID: 12074422-f79526d000000c47-02-530692018e86 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 83.FA.03143.10296035; Thu, 20 Feb 2014 18:38:41 -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 s1KNcesk031636; Thu, 20 Feb 2014 18:38:41 -0500 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s1KNcdfL020244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Feb 2014 18:38:40 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id s1KNccm4025138; Thu, 20 Feb 2014 18:38:38 -0500 (EST) To: Shawn M Emery References: <52E4B9D0.3080404@oracle.com> <53058C22.4010703@oracle.com> From: Tom Yu Date: Thu, 20 Feb 2014 18:38:38 -0500 In-Reply-To: <53058C22.4010703@oracle.com> (Shawn M. Emery's message of "Wed, 19 Feb 2014 22:01:22 -0700") Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrcs4iS3Y4O5xeYujm1exWPS9PsTu wOSxZMlPJo+PT2+xBDBFcdmkpOZklqUW6dslcGU8XDWXsWAmS8WieUsZGxinMHcxcnJICJhI XDz0ig3CFpO4cG89kM3FISQwm0ni6pyXYEVCAhsZJU4eroFInGOSOHjiLFRVF6PEkiNtLCBV IgJaEjcaOphAbGYBdYmjz5vAxgoL+Er8ObiaDWKSu8TXr7fYuxg5ONgEpCWOLi4DCbMIqErM OtALNoZTIEvi8dSjYGN4BSwkdh7qZgSxeQQ4JX79ncAGEReUODnzCQvEKqC1/14yTWAUnIUk NQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdU73czBK91JTSTYygQGV3UdrB+POg0iFG AQ5GJR7eE1JswUKsiWXFlbmHGCU5mJREeSU7gUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeJts gHK8KYmVValF+TApaQ4WJXHeWotfQUIC6YklqdmpqQWpRTBZGQ4OJQnepxOAGgWLUtNTK9Iy c0oQ0kwcnCDDeYCGL+wHGV5ckJhbnJkOkT/FqCglzvsWpFkAJJFRmgfXC0skrxjFgV4R5n0O UsUDTEJw3a+ABjMBDS7ZyAoyuCQRISXVwNhx4O6MJXyuFyYrCnlpvao7/vNzc67kaf5wEev1 cRIH99/nqt8yhfu0abKCTo24bHr5dovXDW/OhN6Z9PNTsvUsHusvf9jnaa2qnS1VFPW2Zmqa aFaOt8fJZwJr0k9zBp/YesblwBLVApGW7/d2MSe8v6G4qtZyp8o1w7PxmZF7prhcdJip+1KJ pTgj0VCLuag4EQCwi6iF/wIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/8EwzGUP1VqOURy_XMzGZhQInm9k Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-aes-cts-hmac-sha2 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, 20 Feb 2014 23:38:47 -0000 Shawn M Emery writes: > The WG is making the following consensus calls on draft-ietf-kitten-aes-cts-hmac-sha2: > > 1. Do we adopt CTS mode for this draft? > a. Yes > b. No > c. Don't care or need more information Yes > 2. Do we use the confounder algorithm as specified in RFC 3961/3962 for this draft? > a. Yes > b. No > c. Don't care or need more information Yes, because of possible security benefits I've described earlier, and the other reasons Greg described. From nobody Thu Feb 20 16:10:46 2014 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 CDAC01A02B5 for ; Thu, 20 Feb 2014 16:10:42 -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, 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 dGDA5ZQRS1Fh for ; Thu, 20 Feb 2014 16:10:40 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id 69D8E1A035E for ; Thu, 20 Feb 2014 16:10:40 -0800 (PST) Received: from BLUPR03CA031.namprd03.prod.outlook.com (10.141.30.24) by BLUPR03MB020.namprd03.prod.outlook.com (10.255.208.42) with Microsoft SMTP Server (TLS) id 15.0.888.9; Fri, 21 Feb 2014 00:10:35 +0000 Received: from BN1AFFO11FD021.protection.gbl (2a01:111:f400:7c10::111) by BLUPR03CA031.outlook.office365.com (2a01:111:e400:879::24) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Fri, 21 Feb 2014 00:10:35 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD021.mail.protection.outlook.com (10.58.52.81) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Fri, 21 Feb 2014 00:10:35 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.195]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0174.002; Fri, 21 Feb 2014 00:10:09 +0000 From: Michiko Short To: "kitten@ietf.org" Thread-Topic: Consensus Calls for draft-ietf-kitten-aes-cts-hmac-sha2 Thread-Index: Ac8umUf/UFHV4IaWRt6uQdBq9agXPw== Date: Fri, 21 Feb 2014 00:10:09 +0000 Message-ID: <5674376E76F88641AD3748A64F0996973449897D@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(66066001)(6806004)(76482001)(94946001)(54356001)(53806001)(80022001)(93136001)(81542001)(80976001)(46102001)(93516002)(54316002)(83322001)(65816001)(86362001)(44976005)(56776001)(51856001)(20776003)(63696002)(94316002)(47776003)(50466002)(87936001)(33656001)(76796001)(83072002)(76786001)(85852003)(77096001)(92726001)(92566001)(74366001)(4396001)(76176001)(90146001)(23726002)(56816005)(558084003)(85806002)(87266001)(85306002)(74876001)(2656002)(74706001)(49866001)(95416001)(47736001)(69226001)(81342001)(50986001)(47976001)(59766001)(55846006)(77982001)(86612001)(81816001)(81686001)(79102001)(46406003)(74502001)(74662001)(47446002)(31966008)(95666003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB020; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:9D53EE16.AC90E69A.6DD6A2BC.D4C93000.20062; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01294F875B X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/nVfgfthCd0j3WeSyUyyxj5jAwZI Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-aes-cts-hmac-sha2 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, 21 Feb 2014 00:10:43 -0000 1. Do we adopt CTS mode for this draft? a. Yes 2. Do we use the confounder algorithm as specified in RFC 3961/3962 for thi= s draft? c. Don't care - Mich From nobody Thu Feb 20 21:59:39 2014 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 21F921A0426 for ; Thu, 20 Feb 2014 21:59:36 -0800 (PST) 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_20=-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 dz-01hG4o59X for ; Thu, 20 Feb 2014 21:59:33 -0800 (PST) Received: from mail.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) by ietfa.amsl.com (Postfix) with ESMTP id 263001A0425 for ; Thu, 20 Feb 2014 21:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1392962369; x=1393567169; q=dns/txt; h=DomainKey-Signature:Received:VBR-Info:Message-ID: Date:From:Organization:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:OpenPGP:Content-Type; bh=8eUyTqpWJQD0X4ON HzwaS43aOznEIKGFH5m+sc5kW/E=; b=hG7cqPgBpjCHqu+iZvfk7JqGk8hb8m1G vxuMa03Aej8br+WlvXaSAmjhbgqxJzEKWsjMuMWKNt+zCgLWpph4EGBcMiFVHv9T xKfkSV6OEaJqAApE7PSdkHAvv4n4rrzKs+RnsfSD3O7LeJuXi49sRFaDHD7ZAyZd YesyMslefsw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=l+NyT2UXVn+i49PnlPZ6v59ttrzTesWeniJHaHu1I9ZadA15T4I/As6XNW/A 8FkdUWKWYFyuEg8LdYKqjQ1oTMX0gdACxc1gHotMrAByl/bxTK13BBE0+ pDXxtkfvIgiRwuQlUzpeDimxqmQb42iD0yVWyAk+ia0SqqImudI/98=; X-MDAV-Result: clean X-MDAV-Processed: mail.secure-endpoints.com, Fri, 21 Feb 2014 00:59:29 -0500 Received: from [172.16.16.54] by secure-endpoints.com (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v13.6.2) with ESMTP id md50000596129.msg for ; Fri, 21 Feb 2014 00:59:28 -0500 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-Spam-Processed: mail.secure-endpoints.com, Fri, 21 Feb 2014 00:59:28 -0500 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: jaltman@secure-endpoints.com X-HashCash: 1:22:140221:md50000596129::R99KkJYr4n82ssF4:00008Sbu X-Return-Path: prvs=11290c1ae7=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <5306EB3D.10407@secure-endpoints.com> Date: Fri, 21 Feb 2014 00:59:25 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kitten References: <52E4B9D0.3080404@oracle.com> <53058C22.4010703@oracle.com> In-Reply-To: <53058C22.4010703@oracle.com> X-Enigmail-Version: 1.6 OpenPGP: url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030608080802090506070903" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/-GTR01fiY4vNmZDahbEmrw_K-d0 Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-aes-cts-hmac-sha2 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, 21 Feb 2014 05:59:36 -0000 This is a cryptographically signed message in MIME format. --------------ms030608080802090506070903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 1. Yes 2. Yes On 2/20/2014 12:01 AM, Shawn M Emery wrote: > The WG is making the following consensus calls on > draft-ietf-kitten-aes-cts-hmac-sha2: >=20 > 1. Do we adopt CTS mode for this draft? > a. Yes > b. No > c. Don't care or need more information >=20 > 2. Do we use the confounder algorithm as specified in RFC 3961/3962 for= > this draft? > a. Yes > b. No > c. Don't care or need more information >=20 > If you answered "no" to any of the above, please state your objections > and/or alternatives. >=20 > Please provide your input before March 6th. Thank you. >=20 > Shawn. > --=20 > kitten co-chair >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --------------ms030608080802090506070903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC 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+XXidE0HbYQwggbXMIIFv6ADAgECAhA5 oFEXaG88XscBgkTPSsu4MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEyMjMwMDAwMDBa Fw0xNTAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtcVgrUA+Zl527P0yx xfkiLZzymUZLAwif9amX6c79OHd17CN5Hg3TIRXi0exjq/z/K2eftbSfj3XatgllPtlmCktq i4daJTVLifx5G7qbcYjQgKpex/8FA3gfvJJNgMef5OwOTE1HqMJsp5CAquFjw/ReiXQqduou 1nHhUhX1AXBpaQmYDOQZwrTD41yT7qm22N67vV0viWG9x/1RdFqqtIOIyKR+ojD3IN0wufES gy7hsWgmghh4jkrclmMIXuo+AAtmJHzwzF4hCrSqdwiRXU4aghTjsmehtMT1nFfzDPylaclO p7IY4xeQm/q1cbU3uEqxhy06sYeVbh6zfTDBAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAACPkJV5NIxzjKc+WveaoM8Uc86wX0yLBm1A33z4 rLVXTWPi5kMIJ6kfE+dFWcMdyyOgZ2VcxIwneZ50LcITFv1VOfRkrX32vVChQqs8XGqerIo/ K3epyFEg01qHq/4byolXW6UOvmZb3oHhtHDGS94Vv6Fu6wV7irAdoM18cqzQsxU0nZDMnY5k 0pKJHLTrsC/uKuoWGz8xLLyeayi37ZsXsbGdazqzVMIoLvFTMjaFuoCetEbiFQZvnuHKwdbV YqyCY28Cl8DVRHrInZrz84xqFiGZNSfFRWOougT47VRDA8SVy6pOtDaOmkxcYXlh5Ezo29FB OiA0+tF8qgMmq3QxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEDmgURdobzxexwGCRM9Ky7gwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTQwMjIxMDU1OTI1WjAjBgkqhkiG9w0BCQQxFgQUk7m+KZ4bdnZbu52MqU6pQ5ie6yYwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQOaBRF2hvPF7HAYJEz0rLuDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhA5oFEXaG88XscBgkTPSsu4MA0GCSqGSIb3DQEBAQUABIIB AENDFz/WHCWhFrnkdd08NGJmRg+0WM7ACty5qNfnyBGzixnTVqTAvWqs2MF+OkWiuUnN6u0S V3kKQb9lBEwlS1o2Hmp2KK4i/p/mkkmmHTIrIclaZ4Hq7TelhlNEOcn67Frl0x3xVFTa4nxT u804fC651FZVRwaKJ8Ne4QJartQQ55aq1xMbVdP6EEvkoO47vXHAdi0Q8Iz32DHr81AkeQxB ktgf/mZpmikua4OFB20nlGsfKasAjFW7d79oV9a9SsQkbwgvVWsxUM0MIxDWkvWPLXxIi2MI ez3M71En6gpngc5IsVcsBJN9PXhChWZGRDHxT12M7BHRl0WG6IigT6QAAAAAAAA= --------------ms030608080802090506070903-- From nobody Fri Feb 21 12:20:06 2014 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 EB47C1A0242 for ; Fri, 21 Feb 2014 12:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 aH_I4oDOvN4k for ; Fri, 21 Feb 2014 12:20:03 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) by ietfa.amsl.com (Postfix) with ESMTP id CA0351A055C for ; Fri, 21 Feb 2014 12:20:00 -0800 (PST) Received: from [192.168.1.130] (50-73-160-70-pennsylvania.hfc.comcastbusiness.net [50.73.160.70]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s1LKJnPW029051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Feb 2014 15:19:55 -0500 (EST) Message-ID: <1393013989.5046.14.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Shawn M Emery Date: Fri, 21 Feb 2014 15:19:49 -0500 In-Reply-To: <53058C22.4010703@oracle.com> References: <52E4B9D0.3080404@oracle.com> <53058C22.4010703@oracle.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Cx1KbhZL-5ex8BPwnypwEprKSZg Cc: "kitten@ietf.org" , jhutz@cmu.edu Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-aes-cts-hmac-sha2 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, 21 Feb 2014 20:20:05 -0000 On Wed, 2014-02-19 at 22:01 -0700, Shawn M Emery wrote: > The WG is making the following consensus calls on draft-ietf-kitten-aes-cts-hmac-sha2: > > 1. Do we adopt CTS mode for this draft? > a. Yes > b. No > c. Don't care or need more information Yes. > 2. Do we use the confounder algorithm as specified in RFC 3961/3962 for this draft? > a. Yes > b. No > c. Don't care or need more information I'm inclined to lean toward "yes". -- Jeff