From nobody Mon Jun 1 11:25:11 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41D61B30C6; Mon, 1 Jun 2015 11:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 qtXlswH_tqIs; Mon, 1 Jun 2015 11:25:06 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0055.outbound.protection.outlook.com [207.46.100.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74EC91B30B6; Mon, 1 Jun 2015 11:24:54 -0700 (PDT) Received: from CO2PR06CA044.namprd06.prod.outlook.com (10.141.242.44) by CY1PR0601MB1563.namprd06.prod.outlook.com (25.163.232.141) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 18:24:53 +0000 Received: from BL2FFO11OLC015.protection.gbl (2a01:111:f400:7c09::142) by CO2PR06CA044.outlook.office365.com (2a01:111:e400:142a::44) with Microsoft SMTP Server (TLS) id 15.1.172.22 via Frontend Transport; Mon, 1 Jun 2015 18:24:53 +0000 Authentication-Results: spf=pass (sender IP is 199.135.140.18) smtp.mailfrom=fs.fed.us; MIT.EDU; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.18 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.18; helo=mail.usda.gov; Received: from mail.usda.gov (199.135.140.18) by BL2FFO11OLC015.mail.protection.outlook.com (10.173.160.81) with Microsoft SMTP Server (TLS) id 15.1.184.11 via Frontend Transport; Mon, 1 Jun 2015 18:24:52 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.131]) by 001FSN2MMR1-008.001f.mgd2.msft.net ([199.135.140.18]) with mapi id 14.03.0224.003; Mon, 1 Jun 2015 18:24:29 +0000 From: "Nordgren, Bryce L -FS" To: Benjamin Kaduk Thread-Topic: [kitten] Group/Enterprise encrypted email Thread-Index: AdCaU4EBKI9vXfbmSrKplnpcKmT5cgAGnCmAAIkbNEA= Date: Mon, 1 Jun 2015 18:24:29 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBF9@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DF8C3@001FSN2MPN1-046.001f.mgd2.msft.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.27.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC015; 1:yZeta8lB2RFZPu3s1UKcao8/t4HCmx6whVqi3O3J3mfFGj0NYGm5+fxaUvw1gSVRb3Cbky4d3TeCLFuGaUyh6GeFhKBP7H2v2QIfUJ/bVXan+W9gqzTjkg/QgnO/Z7JzWqa5RVH772S46WiLoh2W/9YP9TDNuhUiBDXdoDGS2pF8FSIXgbmuN6CTG8Ie44+82VVzjtvsAAU90crEMmhEIT7ebkjAumisOuM+mkwSm4it2OoiaLH66QGQoobQ+rpAzv0+189eSllA6OxKPPLytJ1dR/Btrb8AMR+jFt7hq7I= X-Forefront-Antispam-Report: CIP:199.135.140.18; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(199003)(13464003)(164054003)(51704005)(189002)(87936001)(2656002)(2171001)(22756005)(55846006)(64706001)(77156002)(97756001)(68736005)(102836002)(22746005)(62966003)(46406003)(46102003)(6806004)(47776003)(74482002)(66066001)(19580395003)(19580405001)(69596002)(92566002)(86146001)(566704002)(50986999)(50466002)(561944003)(26826002)(86362001)(33656002)(76176999)(54356999)(104016003)(5001860100001)(2920100001)(5001960100002)(5001830100001)(5001920100001)(81156007)(106466001)(110136002)(4001540100001)(2950100001)(2900100001)(189998001)(23726002)(97736004)(80862005)(79686002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1563; H:mail.usda.gov; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1563; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CY1PR0601MB1563; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1563; X-Forefront-PRVS: 05947791E4 X-OriginatorOrg: fs.fed.us X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2015 18:24:52.7751 (UTC) X-MS-Exchange-CrossTenant-Id: 49808c08-7df8-4c41-af62-7a0827de9408 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=49808c08-7df8-4c41-af62-7a0827de9408; Ip=[199.135.140.18]; Helo=[mail.usda.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1563 Archived-At: Cc: "kitten@ietf.org" , "endymail@ietf.org" Subject: Re: [kitten] Group/Enterprise encrypted email 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, 01 Jun 2015 18:25:08 -0000 > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@MIT.EDU] > > You might have better luck on the endymail list, which is considering way= s to > improve email privacy. I don't recall whether a scheme substantially sim= ilar > to your proposal has been discussed there, but there should be a good cro= p > of people interested in improving the state of email to comment there. Hi Ben and Nico,=20 I thumbed through the endymail archives and things appear to be sort of dea= d. I forwarded the message there anyway just in case someone's still listen= ing. Lot of activity at first, then nothing till now. I just thought it was= kind of neat. :) If it fails to spark any discussion I'll move on. My proposal seems to get around a few of the problems endymail identified s= imply by using a per-message key for in-flight data only. Quite a lot of th= e endymail discussion revolves around key management/distribution for end u= sers. All of it involves using something related to the user's identity to = encrypt email. My proposal appears to be distinct from anything discussed t= here because of my focus on per-message keys unrelated to anyone's identity= . This also distinguishes it from Identity based encryption (thanks Nico!).= The EKG never holds (or releases) keys related to someone's identity. This= scheme has the potential to be a form of OTR protection by configuring the= EKG correctly, anthough if you configure the EKG to hand the key out like = candy, why bother encrypting it? Enterprises will likely not configure thei= r key guardians in this way. Drawbacks are that you can only send encrypted email if your email provider= operates an EKG, you and all your recipients have been issued "email addre= ss certificates" by the respective mail providers, and your recipients must= have a PKI anchor your email provider is configured to trust. For enterpri= ses interested in protecting their IP and operating their own email servers= , this is not likely to be problematic. I suspect webmail clients could als= o participate, as the webmail server would be decrypting the message and th= en displaying it over https. Thanks, Bryce From nobody Mon Jun 1 12:04:16 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECAB1B321F for ; Mon, 1 Jun 2015 12:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPtOQuLqsRuC for ; Mon, 1 Jun 2015 12:04:08 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64061B3217 for ; Mon, 1 Jun 2015 12:03:29 -0700 (PDT) X-AuditID: 12074423-f79496d000000d43-e0-556cac802675 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B1.BC.03395.08CAC655; Mon, 1 Jun 2015 15:03:28 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t51J3Ri7007684; Mon, 1 Jun 2015 15:03:28 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t51J3PXI011324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jun 2015 15:03:27 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t51J3Pb6015525; Mon, 1 Jun 2015 15:03:25 -0400 (EDT) Date: Mon, 1 Jun 2015 15:03:25 -0400 (EDT) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <1158268268.1500683.1432918457535.JavaMail.yahoo@mail.yahoo.com> Message-ID: References: <20150529165004.2217.7049.idtracker@ietfa.amsl.com> <1158268268.1500683.1432918457535.JavaMail.yahoo@mail.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-128065761-1433184878=:22210" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixG6nrtuwJifU4OkzCYujm1exWHzrus7s wOSxZMlPJo9Zsw4zBTBFcdmkpOZklqUW6dslcGXMeHqfreCoZMXB422sDYyNol2MnBwSAiYS x2b9ZYewxSQu3FvP1sXIxSEksJhJ4ubPHnYIZwOjxO3Tp1kgnINMEp9X3mIEaRESqJfYfWI9 WDuLgJbE440/mEFsNgEViZlvNgKN4uAQEVCXaP7uDRJmBjK/nXkD1ios4Cpx7uFaZpASTgFf iU2PhEHCvAKOEkvm/GWFWNXAKLHs5T0mkISogI7E6v1TWCCKBCVOznzCAjEzQGLPr15WCNtR ovn+FrYJjEKzkJTNQlI2C0kZhK0r8WbVQSYIW1vi/s02Npiazo3bGRcwsq1ilE3JrdLNTczM KU5N1i1OTszLSy3SNdPLzSzRS00p3cQIjhAX5R2Mfw4qHWIU4GBU4uHN6M4OFWJNLCuuzD3E KMnBpCTK+3ZlTqgQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV7ZJqAcb0piZVVqUT5MSpqDRUmc d9MPvhAhgfTEktTs1NSC1CKYrAwHh5IEr+tqoEbBotT01Iq0zJwShDQTByfIcB6g4dkgNbzF BYm5xZnpEPlTjIpS4rxZIAkBkERGaR5cLyyBvWIUB3pFmLcapIoHmPzgul8BDWYCGtwuADa4 JBEhJdXAqN9l3vle4eXJxcHrjRtfzf0axjMpsU7/+34+5eQnrz+XHl4z42Nz9t3DzT+yrfid k5aIcr73WsKpWlR24EFG+v+JO3ddFp+372Wtkdfd7e3nJ5hcYfj27fUch2o/tuucht8732yQ iBb/Pk1Xs3vzec7H03ojGe8XNWvkTv8Ts+jTfD7JNPPZtUosxRmJhlrMRcWJAJNrAQI7AwAA Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-23.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: Mon, 01 Jun 2015 19:04:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-128065761-1433184878=:22210 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Thanks for the updates, Bill -- they look good. -Ben On Fri, 29 May 2015, Bill Mills wrote: > Incorporates IESG all pending review feedback.=A0 > -bill > > > On Friday, May 29, 2015 9:50 AM, "internet-drafts@ietf.org" wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Common Authentication Technology Next G= eneration Working Group of the IETF. > > =A0 =A0 =A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : A set of SASL Mechanisms for O= Auth > =A0 =A0 =A0 =A0 Authors=A0 =A0 =A0 =A0 : William Mills > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tim Showalter > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hannes Tschofenig > =A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-kitten-sasl-oauth-23.txt > =A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0 : 24 > =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2015-05-29 > > Abstract: > =A0 OAuth enables a third-party application to obtain limited access to a > =A0 protected resource, either on behalf of a resource owner by > =A0 orchestrating an approval interaction, or by allowing the third-party > =A0 application to obtain access on its own behalf. > > =A0 This document defines how an application client uses credentials > =A0 obtained via OAuth over the Simple Authentication and Security Layer > =A0 (SASL) to access a protected resource at a resource serve.=A0 Thereby= , > =A0 it enables schemes defined within the OAuth framework for non-HTTP- > =A0 based application protocols. > > =A0 Clients typically store the user's long-term credential.=A0 This does= , > =A0 however, lead to significant security vulnerabilities, for example, > =A0 when such a credential leaks.=A0 A significant benefit of OAuth for > =A0 usage in those clients is that the password is replaced by a shared > =A0 secret with higher entropy, i.e., the token.=A0 Tokens typically > =A0 provide limited access rights and can be managed and revoked > =A0 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: > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-23 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-23 > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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/ > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > > > ---559023410-128065761-1433184878=:22210-- From nobody Mon Jun 1 12:46:44 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3681B2C34 for ; Mon, 1 Jun 2015 12:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVpVHyH4lTCL for ; Mon, 1 Jun 2015 12:46:43 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5871F1A89FE for ; Mon, 1 Jun 2015 12:46:41 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 1E1392005D006; Mon, 1 Jun 2015 12:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=YwyvozT1aTw3zi vgu76odYww9CE=; b=WfoOeePGe/4oSUXbjQ/u84kuWFpEam+88fx1TSSylg0Fuc udoYYFyxCfntUNm3UUiMJIMqEuxEkoq4GDQHmH/Mw6wdHy/tJcumi5ZZu5eOyP4L 7t7uq2aQNcX+bhJ0iB6pJ+ylznG64Tv4FHuxAg7oWoVGWd2X807hZH5yNZbU0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id E87452005D008; Mon, 1 Jun 2015 12:46:39 -0700 (PDT) Date: Mon, 1 Jun 2015 14:46:38 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150601194637.GI600@localhost> References: <1430138754.2682.10.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430138754.2682.10.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: [kitten] Bootstrapping PKINIT server certs with Re: SPAKE Preauth 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, 01 Jun 2015 19:46:44 -0000 It'd be great to be able to bootstrap PKINIT AS server certificate issuer certs with SPAKE pre-auth. I guess we could do this by having a pseudo-factor that the AS could include in the challenge, bearing the realms' trusted issuer's certificate. A client would learn the PKINIT AS server cert "trust anchors" as follows: - single-user clients can cache (e.g., in a user's home directory) realm certs extracted from successful SPAKE exchanges - multi-user clients can do the same *after* validating the issued TGTs (by getting a service Ticket for a service whose keys the client has, then decrypting that Ticket's enc-part). Nico -- From nobody Mon Jun 1 14:50:10 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3244E1A00C2; Mon, 1 Jun 2015 14:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ_aJvs02pTw; Mon, 1 Jun 2015 14:50:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA3F1A00CF; Mon, 1 Jun 2015 14:50:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150601215003.13896.68999.idtracker@ietfa.amsl.com> Date: Mon, 01 Jun 2015 14:50:03 -0700 Archived-At: Cc: kitten mailing list , kitten chair , RFC Editor Subject: [kitten] Protocol Action: 'A set of SASL Mechanisms for OAuth' to Proposed Standard (draft-ietf-kitten-sasl-oauth-23.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 21:50:07 -0000 The IESG has approved the following document: - 'A set of SASL Mechanisms for OAuth' (draft-ietf-kitten-sasl-oauth-23.txt) as Proposed Standard This document is the product of the Common Authentication Technology Next Generation Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ Technical Summary 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. Working Group Summary The review process for this document was very long and complicated. See the shepherd write-up for details, it is comprehensive and... ...long... but ends with: The fourth WGLC achieved consensus with support from both kitten and the oauth working groups. It did result in a few clarifications to the document, fixing the ABNF and examples, noting the generic SASL cancellation token functionality, and reiterating the TLS requirements for using this mechanism, but these changes were not controversial. Document Quality The long gestation period here has resulted in pretty high quality documentation of this not that hard to understand combination of schemes. I'm not sure about implementation status. Personnel The document shepherd is Benjamin Kaduk. The responsible Area Director is Stephen Farrell. From nobody Fri Jun 12 10:06:47 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188141ACD5B for ; Fri, 12 Jun 2015 10:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGZfNMAgKga2 for ; Fri, 12 Jun 2015 10:06:32 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21921ACD47 for ; Fri, 12 Jun 2015 10:06:31 -0700 (PDT) X-AuditID: 12074424-f79b06d000000cfd-4f-557b1196b450 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id D4.85.03325.6911B755; Fri, 12 Jun 2015 13:06:30 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t5CH6TL8025551 for ; Fri, 12 Jun 2015 13:06:30 -0400 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 t5CH6SsV021622 for ; Fri, 12 Jun 2015 13:06:29 -0400 From: Greg Hudson To: kitten@ietf.org Date: Fri, 12 Jun 2015 13:06:28 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUixG6nojtNsDrU4PkqCYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro3VtM2PBd/GKvdsOMzUw7hPuYuTkkBAwkVg2ZxY7hC0mceHe erYuRi4OIYHFTBLPOy8xQzjHGSU2XbkJlelgktj+ZRYLSAubgLLE+v1bwWwRAWGJ3VvfMYPY wgIWEttbm8HGsgioSkxd0MMEYvMKGEos6VnEBmELSpyc+QSsl1lAQuLgixfMExh5ZiFJzUKS WsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXXC83s0QvNaV0EyM4PFxUdjA2H1I6xCjAwajE w5ugVRUqxJpYVlyZe4hRkoNJSZS3hq86VIgvKT+lMiOxOCO+qDQntfgQowQHs5IIrywjUI43 JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYLXSgCoUbAoNT21Ii0zpwQh zcTBCTKcB2j4apAa3uKCxNzizHSI/ClGRSlxXnOQhABIIqM0D64XFr+vGMWBXhHmNQOp4gHG Plz3K6DBTECD23uqQAaXJCKkpBoYtXbNSJWql55w9Ohx83PnmgItddN3ZYk9Ob6s/l9pi6uu 45Lc+Lda06feFtU05VWqjVo8oVk8jYWJ973gxEDeqN2cx6QqP3FWZfguM1nQlRlwyG4Vm+iX GO6Nkhc65ef+O9IXOSuxvK5xMoOTxj3jZPnKud/2xG6+NvfEk+OTNS5oL6lcwsenxFKckWio xVxUnAgAGx2DZLoCAAA= Archived-At: Subject: [kitten] SPAKE preauth: deriving RFC3961 encryption keys 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, 12 Jun 2015 17:06:36 -0000 In the current design of the SPAKE preauth mechanism, once the client generates its public value, the client and KDC need to derive a series of RFC 3961 encryption keys K'[n]. Keys in this series are used for confirmation in the SPAKEResponse, to encrypt any subsequent second-factor challenges and responses, and finally for the reply key. The basic inputs for this derivation are the computed shared value K, the transcript checksum, and the encoded KDC-REQ-BODY for the request being sent or processed. The initial reply key (typically the client principal long-term key) can also be used as an input, although it was already used as an input to the SPAKE negotiation. The current draft in github [1] specifies, basically, that K'[n] is random-to-key(PRF+(initial-reply-key, "SPAKEKey"||K||cksum||body||n)). This method is convenient in that it uses only RFC 3961 operations. But it relies on the security properties of the PRF in a weird way; the assumed high-entropy information (K) is in the PRF input string, while the PRF key is assumed to be low-entropy. Let's call that alternative 1. Here are two other alternatives: 2. Each group profile [2] designates an unkeyed hash function H (e.g. SHA-256). Following a similar method to RFC 4556, we derive K'[n] as follows: H+(x, k) = k-truncate(H(1||x) || H(2||x) || ...) K'[n] = random-to-key(H+(n||"SPAKEKey"||K||cksum||body), seedlen) 3. As in (2), with the additional step of combining the result with the additional reply key using KRB-FX-CF2: H+(x, k) = k-truncate(H(1||x) || H(2||x) || ...) Ki[n] = random-to-key(H+(n||"SPAKEKey"||K||cksum||body), seedlen) K'[n] = KRB-FX-CF2(initial-reply-key, Ki[n], "pepper1", "pepper2") I don't believe this additional step is necessary, because K is already derived from the initial reply key via the SPAKE algorithm. But depending on how one reads the language of RFC 6113 section 3.2, that step might be required in order to say that we implement the "strengthening reply key" facility. That section begins: Particularly when dealing with keys based on passwords, it is desirable to increase the strength of the key by adding additional secrets to it. Examples of sources of additional secrets include the results of a Diffie-Hellman key exchange or key bits from the output of a smart card [KRB-WG.SAM]. Typically, these additional secrets can be first combined with the existing reply key and then converted to a protocol key using tools defined in Section 5.1. Section 5.1 defines KRB-FX-CF1() (which combines two passphrases), KRB-FX-CF2(), and PRF+ as an intermediate step of defining KRB-FX-CF2(). Do people have opinions on which option is best? Have I missed anything else? [1] https://github.com/npmccallum/ietf [2] Group profiles don't exist in the current draft, but we are planning to shift to numbered, registered group profiles in order to avoid interop issues with calculating M and N, representing points and producing scalars, etc. From nobody Fri Jun 12 13:08:03 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCE31B29FA; Fri, 12 Jun 2015 13:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UwI8m_CbPLp; Fri, 12 Jun 2015 13:08:00 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A0F1B29D8; Fri, 12 Jun 2015 13:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=822; q=dns/txt; s=iport; t=1434139680; x=1435349280; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yIFSihnVXodbe1gAiyHeE/CAEgZ5PSuRPn5+PoZ18mw=; b=ePOcmgdC70HnEw9YteVjhSkrAayg+w/y4nYu1NpnPAL0DMVSM/HmbRzB R6BhHl1r1dVPZaxbnxMhZWaUngGR82+rVdPrsWMICOkIgwg7Y9nxKQ/ui hLyjcSxGSRU4YKvQca+RBlDjIF9b4yxi4/ZLC4R147Fng3igfD1Ll+6+t Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AnBAC8O3tV/4QNJK1cgxBUXwaDGLpSCYFZhgICgUQ4FAEBAQEBAQGBCoQjAQEEIw8BRQEQCxoCBRYLAgIJAwIBAgE1EAYNAQcBAYgrslmkPAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGKIoRTMweCaIFFAQSMZos6hnKBMoQBgmOPciaCCh2BcVCBRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,604,1427760000"; d="scan'208";a="158806247" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 12 Jun 2015 20:07:59 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5CK7xc4006977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jun 2015 20:07:59 GMT Received: from [10.89.6.238] (10.89.6.238) by xhc-rcd-x10.cisco.com (173.37.183.84) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 12 Jun 2015 15:07:58 -0500 Message-ID: <557B3C1D.3010405@cisco.com> Date: Fri, 12 Jun 2015 14:07:57 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kitten WG References: <555DF135.50302@cisco.com> In-Reply-To: <555DF135.50302@cisco.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.89.6.238] Archived-At: Cc: Kitten WG Chairs Subject: Re: [kitten] Meeting in Prague 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, 12 Jun 2015 20:08:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So far we have received one agenda item request (SPAKE preauth). Are there any other topics the working group needs to discuss in person? If so, please send them in very soon! - - )\_/( 'o.o' =(_ _)= U -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVezwdAAoJEDWi+S0W7cO1ElQIAKSEJhBylCWmSQiB+YzXGBA7 9tnn1DmsdT/KQaCd7fMWUleo9lHlVKKvd57Zh9cPKIJ7LDWLaMgbqyYESsOG0IJ3 lbnI+ml+sLg9UTdHW9I66pG2jGr2IyBAuRf5CgYwLXx5tDTjr0yT2xr5WYt1gxWk AoSP3KcuoxW9LP+rIPlsUWjpqNiBq66aw3CwKuaigadxeleTgkcU5dASJlJqj8Wr RXogH7/OLP0qEhmxFXh9Nrl2/nBQxq3oozS5H5ckRBFle0fKClQ7PGIHI/FDBPBD 7WoxQAUYMcBT8D1yrYtkidBrEWC9ZJSnc6pRw19c69c5fTxXHBoIwNmmUKSFnao= =+gML -----END PGP SIGNATURE----- From nobody Mon Jun 15 06:48:03 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1381A1A2F for ; Mon, 15 Jun 2015 06:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmZmbpiKlHgp for ; Mon, 15 Jun 2015 06:47:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C621A1A11 for ; Mon, 15 Jun 2015 06:47:58 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 239478E502; Mon, 15 Jun 2015 13:47:58 +0000 (UTC) Received: from [10.3.113.97] (ovpn-113-97.phx2.redhat.com [10.3.113.97]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5FDlvBl012188; Mon, 15 Jun 2015 09:47:57 -0400 Message-ID: <1434376077.22266.10.camel@willson.usersys.redhat.com> From: Simo Sorce To: Greg Hudson Date: Mon, 15 Jun 2015 09:47:57 -0400 In-Reply-To: References: Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: deriving RFC3961 encryption keys 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, 15 Jun 2015 13:48:02 -0000 On Fri, 2015-06-12 at 13:06 -0400, Greg Hudson wrote: > In the current design of the SPAKE preauth mechanism, once the client > generates its public value, the client and KDC need to derive a series > of RFC 3961 encryption keys K'[n]. Keys in this series are used for > confirmation in the SPAKEResponse, to encrypt any subsequent > second-factor challenges and responses, and finally for the reply key. > The basic inputs for this derivation are the computed shared value K, > the transcript checksum, and the encoded KDC-REQ-BODY for the request > being sent or processed. The initial reply key (typically the client > principal long-term key) can also be used as an input, although it was > already used as an input to the SPAKE negotiation. > > The current draft in github [1] specifies, basically, that K'[n] is > random-to-key(PRF+(initial-reply-key, "SPAKEKey"||K||cksum||body||n)). > This method is convenient in that it uses only RFC 3961 operations. But > it relies on the security properties of the PRF in a weird way; the > assumed high-entropy information (K) is in the PRF input string, while > the PRF key is assumed to be low-entropy. Why don't we just swap them, then ? > Let's call that alternative 1. Here are two other alternatives: > > 2. Each group profile [2] designates an unkeyed hash function H (e.g. > SHA-256). Following a similar method to RFC 4556, we derive K'[n] as > follows: > > H+(x, k) = k-truncate(H(1||x) || H(2||x) || ...) > K'[n] = random-to-key(H+(n||"SPAKEKey"||K||cksum||body), seedlen) > > 3. As in (2), with the additional step of combining the result with the > additional reply key using KRB-FX-CF2: > > H+(x, k) = k-truncate(H(1||x) || H(2||x) || ...) > Ki[n] = random-to-key(H+(n||"SPAKEKey"||K||cksum||body), seedlen) > K'[n] = KRB-FX-CF2(initial-reply-key, Ki[n], "pepper1", "pepper2") > > I don't believe this additional step is necessary, because K is already > derived from the initial reply key via the SPAKE algorithm. But > depending on how one reads the language of RFC 6113 section 3.2, that > step might be required in order to say that we implement the > "strengthening reply key" facility. That section begins: > > Particularly when dealing with keys based on passwords, it is > desirable to increase the strength of the key by adding additional > secrets to it. Examples of sources of additional secrets include the > results of a Diffie-Hellman key exchange or key bits from the output > of a smart card [KRB-WG.SAM]. Typically, these additional secrets > can be first combined with the existing reply key and then converted > to a protocol key using tools defined in Section 5.1. Doesn't this confirm that additional step are not required ? It seem that adding more computational requirements without a clear need is not desirable, given the SPAKE algorithm is already computationally heavier than current pre-auth mechanisms. > Section 5.1 defines KRB-FX-CF1() (which combines two passphrases), > KRB-FX-CF2(), and PRF+ as an intermediate step of defining > KRB-FX-CF2(). > > Do people have opinions on which option is best? Have I missed anything > else? I would like to understand better why we should add more work here, is it necessary, or is it just abundance of caution due to the definition in 6113 not perfectly matching this new, unforeseen at the time, mechanism ? Simo. > [1] https://github.com/npmccallum/ietf > > [2] Group profiles don't exist in the current draft, but we are planning > to shift to numbered, registered group profiles in order to avoid > interop issues with calculating M and N, representing points and > producing scalars, etc. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- Simo Sorce * Red Hat, Inc * New York From nobody Mon Jun 15 12:24:15 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5041A88A0 for ; Mon, 15 Jun 2015 12:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKqaS1Fl3jbU for ; Mon, 15 Jun 2015 12:24:03 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3B91A88C2 for ; Mon, 15 Jun 2015 12:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1361; q=dns/txt; s=iport; t=1434396244; x=1435605844; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=SDP0Sr9jKJlEQQqx2yRq7Geiv9jPov5kaae2ASXC68U=; b=BDCyBi9tOEs4Ww7HFVFa2e2y5tH0S9hAihz8EubXxr0grJOjvVa/Dy8C kg8ygRM8hX9fIi7Ujcwz2lVIpINfLkoCAU5nOFwGIqmTx4cyuruwo/K5u IJpYmnibT/Z8wcOOfUL3uMOmVnKFN85ptEbWESCN6k5RqXdJiFn7N6SAI Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BKBAAyJX9V/4YNJK1bgxBUXwaDGLYihCsJgVmHPzgUAQEBAQEBAYEKhEwPAUUaHAIFFgsCCwMCAQIBNRYNCAEBF4gUmD6NOo9fljoBAQEHAQEBAQEZBIEhkhiBRQWMaIZzhFCGcoEzhASCZIwag1smY4EnHYFxUIFGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,620,1427760000"; d="scan'208";a="159709164" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jun 2015 19:24:03 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5FJO2V9030830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Jun 2015 19:24:02 GMT Received: from [10.89.15.72] (10.89.15.72) by xhc-rcd-x10.cisco.com (173.37.183.84) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 15 Jun 2015 14:24:01 -0500 Message-ID: <557F2650.4070404@cisco.com> Date: Mon, 15 Jun 2015 13:24:00 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.89.15.72] Archived-At: Subject: [kitten] Scheduling Issues for IETF 93 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, 15 Jun 2015 19:24:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, The next IETF meeting currently has more requests to meet than there are slots available. All Working Group chairs have been asked to try and find solutions to this meeting's scheduling issues. The Kitten chairs asked for a 1 hour slot, and we currently have agenda items to fill about 20 minutes of that. It appears that DANE is in a similar situation. My questions to the Working Group are: 1) Is a physical meeting in Prague necessary? If not, the chairs will relinquish our slot for Prague. 2) If a physical meeting in Prague is necessary, are there any objections to co-locating with DANE? Please provide a response as soon as you are able. Thank you, - -- your kitten chairs |\_/| '°.°' =(_ _)= U -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVfyZQAAoJEDWi+S0W7cO1KKgH/3v4Bg6AYtQadAa50UDPmTxd JZpE4Z23UkPTDksmkcxG3MN7NbUh9ogVB5HI6RdaZnyFAnQoIrw2IQtONLSoLpkb FHtKrcEu2A/ld2LiTFXkzloqOlixfnLtdgJ9UA9yOe1Rg4a0qdzmuZ0JKCxdX1h5 Z3pjeKgHfUNbvOGu5uu9MEBGfOuyuemtENtuJn0feoip91Rq4k9l0yZhg+UPl3Oz +TFHa5BTSbnkILvygyLdLfzPJAiLef5TeIKottSABDMIXi/rxToQSVHpo/jzyjRj oqS6xiFAwe7d9GSYpxOqjIX8j8q5KruSncFCzs0kBvsvLzVMFUmYfY2VNhHIqzM= =LoKz -----END PGP SIGNATURE----- From nobody Mon Jun 15 13:07:26 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066EF1A8A04 for ; Mon, 15 Jun 2015 13:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbNCMih2wkUQ for ; Mon, 15 Jun 2015 13:07:24 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777921A8A0C for ; Mon, 15 Jun 2015 13:06:56 -0700 (PDT) X-AuditID: 12074425-f799a6d000007db3-30-557f305f44e8 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 81.64.32179.F503F755; Mon, 15 Jun 2015 16:06:55 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t5FK6s3G004637; Mon, 15 Jun 2015 16:06:54 -0400 Received: from [18.101.8.66] (vpn-18-101-8-66.mit.edu [18.101.8.66]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5FK6qm6006428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Jun 2015 16:06:53 -0400 Message-ID: <557F305C.8020804@mit.edu> Date: Mon, 15 Jun 2015 16:06:52 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simo Sorce References: <1434376077.22266.10.camel@willson.usersys.redhat.com> In-Reply-To: <1434376077.22266.10.camel@willson.usersys.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrBtvUB9q8P+CsMXRzatYLH7MXcTq wOSxZMlPJo/3+66yBTBFcdmkpOZklqUW6dslcGXs+r+VreCrcMWHrj6WBsZv/F2MnBwSAiYS S39fZoSwxSQu3FvP1sXIxSEksJhJ4uCLd+wQzkZGic8PzzFCOAeZJO7cPsgO0sIroCaxZ+Mi MJtFQFXifOcDsFFsAsoS6/dvZeli5OAQFQiT2LNHFaJcUOLkzCcsILaIgILEgv47YDazgLDE he17WUHKhQVcJZZ95wUJCwlkSHx4e5cVxOYUcJbo+v2LDaJcXeLPvEvMELa8RPPW2cwTGAVn IdkwC0nZLCRlCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFula6OVmluilppRuYgSFL7uL6g7G CYeUDjEKcDAq8fBu+FIbKsSaWFZcmXuIUZKDSUmU95xefagQX1J+SmVGYnFGfFFpTmrxIUYJ DmYlEd6n6kA53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJXg19oEbB otT01Iq0zJwShDQTByfIcB6g4ZYgNbzFBYm5xZnpEPlTjIpS4rx2IAkBkERGaR5cLyy9vGIU B3pFmPcIyN08wNQE1/0KaDAT0OCUxjqQwSWJCCmpBsYem8Mvrl/ludB6c/96yY3+B41lMm7P 5g3Wffsv+1PwrqyfKu13V02TflNzs+ji19ULrS4/fxgRfmB7nbLUqZPvLrtoxOTd89Tk53vH 5bRDS6q0xUb64m1xnaC+E2YsjXVK772k/1nPWmsgp7zbWsk9jT0z+4jG2oDrExlvVC/kza7h 4VnS7KnEUpyRaKjFXFScCAD+TfTECgMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: deriving RFC3961 encryption keys 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, 15 Jun 2015 20:07:26 -0000 On 06/15/2015 09:47 AM, Simo Sorce wrote: >> The current draft in github [1] specifies, basically, that K'[n] is >> random-to-key(PRF+(initial-reply-key, "SPAKEKey"||K||cksum||body||n)). >> This method is convenient in that it uses only RFC 3961 operations. But >> it relies on the security properties of the PRF in a weird way; the >> assumed high-entropy information (K) is in the PRF input string, while >> the PRF key is assumed to be low-entropy. > > Why don't we just swap them, then ? We can't, because K is not an RFC 3961 key. It is the octet string representation of a group element. >> 2. Each group profile [2] designates an unkeyed hash function H (e.g. >> SHA-256). Following a similar method to RFC 4556, we derive K'[n] as >> follows: >> >> H+(x, k) = k-truncate(H(1||x) || H(2||x) || ...) >> K'[n] = random-to-key(H+(n||"SPAKEKey"||K||cksum||body), seedlen) This was a braino on my part; it would be SPAKE1 rather than SPAKE2. We would need to hash in some form of the w value (probably the un-preprocessed PRF+ result). >> Particularly when dealing with keys based on passwords, it is >> desirable to increase the strength of the key by adding additional >> secrets to it. Examples of sources of additional secrets include the >> results of a Diffie-Hellman key exchange or key bits from the output >> of a smart card [KRB-WG.SAM]. Typically, these additional secrets >> can be first combined with the existing reply key and then converted >> to a protocol key using tools defined in Section 5.1. > > Doesn't this confirm that additional step are not required ? > It seem that adding more computational requirements without a clear need > is not desirable, given the SPAKE algorithm is already computationally > heavier than current pre-auth mechanisms. I don't know what the precise intent of the RFC 6113 language is, so I'm asking. It may be safe to assume that any cryptographically secure derivative of the initial reply key can be termed strengthening. > I would like to understand better why we should add more work here, is > it necessary, or is it just abundance of caution due to the definition > in 6113 not perfectly matching this new, unforeseen at the time, > mechanism ? I am primarily asking whether people think it is okay to use the existing PRF+ method with a low-entropy key and a high-entropy input string, or whether we need to add an unkeyed hash function to the profile and use H+(n||"SPAKEKey"||K||w||cksum||body). From nobody Tue Jun 16 13:02:42 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD691B2D10 for ; Tue, 16 Jun 2015 13:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfSEY9B9U02l for ; Tue, 16 Jun 2015 13:02:41 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 372901A8997 for ; Tue, 16 Jun 2015 13:02:41 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 80B9659405E; Tue, 16 Jun 2015 13:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=N18S/LLDnl+EED L3z205X3xba/U=; b=CC9v64Mj2zyX+FQ7Kw0AcQt0tN0cQSFGqdZAflt6q8X8bB gKEBtJjMNYq0B4getZzCNLXGqW7T3xAtfE/6WTfCP2R2me8U4z5fZR1j3ndap1Kh ivv0qEgbxx6AH11DOqrw7FVIa9rZ0p5DarTI2MZZxgHDV7A56h7z9cmmDuwBs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id 6CCC4594059; Tue, 16 Jun 2015 13:02:39 -0700 (PDT) Date: Tue, 16 Jun 2015 15:02:37 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20150616200236.GC6117@localhost> References: <1434376077.22266.10.camel@willson.usersys.redhat.com> <557F305C.8020804@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <557F305C.8020804@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org, Simo Sorce Subject: Re: [kitten] SPAKE preauth: deriving RFC3961 encryption keys 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, 16 Jun 2015 20:02:42 -0000 On Mon, Jun 15, 2015 at 04:06:52PM -0400, Greg Hudson wrote: > I am primarily asking whether people think it is okay to use the > existing PRF+ method with a low-entropy key and a high-entropy input > string, or whether we need to add an unkeyed hash function to the > profile and use H+(n||"SPAKEKey"||K||w||cksum||body). Thanks for summarizing it so well. The PRF+() comes from RFC6113, and relies on the RFC3961 pseudo-random(). The latter has specific requirements. The requirements for pseudo-random() do not make it entirely clear that using a low-entropy ("public") key and high-entropy (confidential) input is safe. But for the simplified profile it's clear that it can only be safe to use pseudo-random() with low-entropy keys / high-entropy inputs when the output of pseudo-random() is kept confidential. For the particular purpose of generating confidential keys, then, I think PRF+() with low-entropy key and high-entropy input seems OK. Asking a cryptographer seems like a good idea though! Nico -- From nobody Thu Jun 18 08:10:22 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF1F1B329D for ; Thu, 18 Jun 2015 08:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBI9LHKfdjHz for ; Thu, 18 Jun 2015 08:10:14 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6841B329C for ; Thu, 18 Jun 2015 08:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1791; q=dns/txt; s=iport; t=1434640214; x=1435849814; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=TqFv//b2OhNff064wxfcxOCN5JSrDCDEDRaciyS74bQ=; b=NeJMxpII6M50MB2FZFgScNzW9qHU8PJlzFYNESB5OYGWscg2mKWcyT3m fRNJiKEdz4l+p96pt3kGSQ1l5ejKROnLBY62khdaBSf7JpbQEH/rX9pA9 tIrU946Ao4e9hEVW2xhKHj/LmrJM6qInyp9CII2vAy0QcMx/0Y8RpEH5I Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CWBADo3oJV/4cNJK1cgxBUXwaDGLYthCsJgV2GAAKBNzgUAQEBAQEBAYEKhCMBAQQjDwFFEQsYAgIFFgsCAgkDAgECATUQBg0GAgEBF4gUrxeWKwEBAQEBAQEDAQEBAQEBAQEWBIEhiiSEUzqCaIFDBYxzhn2EU4Z2gTWECoJqj3wmY4EnHYFxUIEDBD+BAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,638,1427760000"; d="scan'208";a="160722745" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP; 18 Jun 2015 15:10:10 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5IFAAru008689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Jun 2015 15:10:10 GMT Received: from [10.129.24.94] (10.129.24.94) by xhc-aln-x10.cisco.com (173.36.12.84) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 18 Jun 2015 10:10:09 -0500 Message-ID: <5582DF53.3000703@cisco.com> Date: Thu, 18 Jun 2015 09:10:11 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "kitten@ietf.org" References: <557F2650.4070404@cisco.com> In-Reply-To: <557F2650.4070404@cisco.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.94] Archived-At: Subject: Re: [kitten] Scheduling Issues for IETF 93 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, 18 Jun 2015 15:10:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 6/15/15 1:24 PM, ⌘ Matt Miller wrote: > Hello all, > > The next IETF meeting currently has more requests to meet than > there are slots available. All Working Group chairs have been > asked to try and find solutions to this meeting's scheduling > issues. > > The Kitten chairs asked for a 1 hour slot, and we currently have > agenda items to fill about 20 minutes of that. It appears that > DANE is in a similar situation. > > My questions to the Working Group are: > > 1) Is a physical meeting in Prague necessary? If not, the chairs > will relinquish our slot for Prague. > > 2) If a physical meeting in Prague is necessary, are there any > objections to co-locating with DANE? > > Please provide a response as soon as you are able. > There have been no responses to this message, nor have there been requests for time than the one topic received. I interpret this to mean a physical meeting in Prague is unnecessary. I will ask that our request be canceled. If the WG feels a session is necessary for any particular topic, we can schedule an interim meeting. Thank you, - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVgt9TAAoJEDWi+S0W7cO1uOgIAIhMxcnR+1cRkIZBpJFjiXFG AOyaE70mDcUcpIJJ5vngdlk3D/YUSJ2iil85bjFlqwXHCRZ/B9pNJxk9+Q4tYWtR r3YRfwXh2fVZPrBkG/n6pX09qU4FRsboFkyENBsv1wpA8OMzxj0BIMC8F/YFvEgR cvUTe0/iPPRlWlzW4v1CVt/rYNpZ/6wJwn7UoWNJHnht3kuBg39M9/etpqXcE2p5 2HfkvnxV72UVNe98TdOazH+MkqZsvwHdB6rw/pa1eu1DhP9x5sCw7npbXn0fxBuK VTt8Vce7jnwB6eO1pbNBZ7gtL/q3N/IdwCq3KRfg8j3BFMiFU/9y1IvJHQH3EQU= =rxMY -----END PGP SIGNATURE----- From nobody Thu Jun 18 10:18:53 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7023F1B2A2D for ; Thu, 18 Jun 2015 10:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, 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 20rZl0lw8pQ4 for ; Thu, 18 Jun 2015 10:18:50 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BA9881B29ED for ; Thu, 18 Jun 2015 10:18:50 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 4516867C07D; Thu, 18 Jun 2015 10:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=YD3eSAObfCNlXnIluU9qluvjws4=; b=YYSWArsgKNg 60rnKZJ6BRFcI35bt0h2UVwi3llLLmloSaD/j2co7C7CznCz319gH4R5PJk8XJed Z/EtqXQwD4ryOspXY6Zm3CdVGxItbEysalH88Hhjoc0Mp0WmDbtOO8hyR7MZ4UXD 3mWzdQJMou72FU2YDsiRUCvipEjVaaBY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPA id B128067C09F; Thu, 18 Jun 2015 10:18:49 -0700 (PDT) Date: Thu, 18 Jun 2015 12:18:48 -0500 From: Nico Williams To: =?utf-8?B?4oyY?= Matt Miller Message-ID: <20150618171847.GO6117@localhost> References: <557F2650.4070404@cisco.com> <5582DF53.3000703@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5582DF53.3000703@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Scheduling Issues for IETF 93 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, 18 Jun 2015 17:18:51 -0000 On Thu, Jun 18, 2015 at 09:10:11AM -0600, =E2=8C=98 Matt Miller wrote: > On 6/15/15 1:24 PM, =E2=8C=98 Matt Miller wrote: > > My questions to the Working Group are: > >=20 > > 1) Is a physical meeting in Prague necessary? If not, the chairs > > will relinquish our slot for Prague. > >=20 > > 2) If a physical meeting in Prague is necessary, are there any=20 > > objections to co-locating with DANE? >=20 > There have been no responses to this message, nor have there been > requests for time than the one topic received. I interpret this to > mean a physical meeting in Prague is unnecessary. Agreed. From nobody Fri Jun 19 08:05:55 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222D91A89FF for ; Fri, 19 Jun 2015 08:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZyWTy5JNqs1 for ; Fri, 19 Jun 2015 08:05:51 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1BE1A8A4E for ; Fri, 19 Jun 2015 08:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1508; q=dns/txt; s=iport; t=1434726348; x=1435935948; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UI3OmevNlpIkpPLmU5cOPqryMstybSGheU5IvRAG5pc=; b=V5f4z+KtetcBMc3Gk7Fpfm37Kk0FgMmFU7SM5bU36jqITp31s8lIstnA 9x99i1uWHXmeQ9Cpj6krwcdZ1Qw+/ljjUjehfA2gS+77RlrPfPzdjCiH9 dEqCTcqWUW1eyaLdky3WRjp9Dd5YdOw3MIRKn0T5NvtQGRpI9n4KU6ocI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A/BADBLoRV/4QNJK1cgxBUXwaDGLY4hCsJgV6GAAKBPDgUAQEBAQEBAYEKhCMBAQQjDwFFARALGAICBRYLAgIJAwIBAgE1EAYNAQcBAYgrrx2WTQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGKJIRTMweCaIFDAQSMe4cBhFaGeIE6hnaMI4NbJmOBJx2BcVCBRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,644,1427760000"; d="scan'208";a="160938338" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 19 Jun 2015 15:05:47 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5JF5ljN012290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jun 2015 15:05:47 GMT Received: from [10.129.24.94] (10.129.24.94) by xhc-aln-x10.cisco.com (173.36.12.84) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 19 Jun 2015 10:05:46 -0500 Message-ID: <55842FCB.5030500@cisco.com> Date: Fri, 19 Jun 2015 09:05:47 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nico Williams References: <557F2650.4070404@cisco.com> <5582DF53.3000703@cisco.com> <20150618171847.GO6117@localhost> In-Reply-To: <20150618171847.GO6117@localhost> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.94] Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Scheduling Issues for IETF 93 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, 19 Jun 2015 15:05:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 6/18/15 11:18 AM, Nico Williams wrote: > On Thu, Jun 18, 2015 at 09:10:11AM -0600, ⌘ Matt Miller wrote: >> On 6/15/15 1:24 PM, ⌘ Matt Miller wrote: >>> My questions to the Working Group are: >>> >>> 1) Is a physical meeting in Prague necessary? If not, the >>> chairs will relinquish our slot for Prague. >>> >>> 2) If a physical meeting in Prague is necessary, are there any >>> objections to co-locating with DANE? >> >> There have been no responses to this message, nor have there >> been requests for time than the one topic received. I interpret >> this to mean a physical meeting in Prague is unnecessary. > > Agreed. > The Kitten Working Group will have a session at IETF 93. If the WG feels a meeting to discuss some specific topic(s) is necessary, we can schedule an interim meeting. Thanks everyone, - -- Your Kitten Chairs \ /\ ) ( ') ( / ) \(__)| -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVhC/LAAoJEDWi+S0W7cO1I7AH/RzZB197g3kdE3pvbmtKgXyH HfYG+n0CiZI878fhCyRG0+nKDFXhUoDOKBGtIftAizsfwJUXo7cIfde2w2zerls2 IXNQ5d9gWIum2LHUaej1uhVAoc7gFeabUNX5k2e2YBtiAyuqp6KQqjrSR1tKdCvk 3UTArYW+LI7DGISzB9BvYkm6t4MKJRF2o7Np3QauUJl5XnRrf8l9AAJL3UxvPh9r GiurpRvWCAQkpesev9qmqWmyVz31TpP1P0vhZdzGEmR5SNxCvZmNZf9P9pDksS4j +Bu7wvPCorkEU9S2bJJDbvU2yQOiGxiJMe5s1P5mLTBeGKMpe6cMiQA8AOgwsng= =WSg2 -----END PGP SIGNATURE----- From nobody Fri Jun 19 08:07:50 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E201A8A03 for ; Fri, 19 Jun 2015 08:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvuMnMSZ5sH9 for ; Fri, 19 Jun 2015 08:07:47 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7881A897A for ; Fri, 19 Jun 2015 08:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1570; q=dns/txt; s=iport; t=1434726467; x=1435936067; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Ztv6WQA5TB84opSGpepB7NYkSBuIkPJWwIZhEsUCRZM=; b=ZY2fNhhMcvD9LXd5hmcY50iEXUqNYbN6/CjLX34DktPlyXqGrg59ALJk fdhJvi8vYfZUBWJDsZBOV4D2YkrcTeEoGzoeUTDUjg7elCrqCNjy2xoFa q8GttWgjERcx+uRNeplNxkFX0SfFAFY41/E5dMOfPMtaMSaNwXwjV8WnA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A/BACxL4RV/4ENJK1cgxBUXwaDGLY4hCsJgV6GAAKBPDgUAQEBAQEBAYEKhCMBAQQjDwFFARALGAICBRYLAgIJAwIBAgE1EAYNAQUCAQGIK68llk0BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhiiSEUzMHgmiBQwEEjHuHAYRWhniIMI9+JmOBJx2BcVCBRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,644,1427760000"; d="scan'208";a="161083917" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP; 19 Jun 2015 15:07:47 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5JF7kTw006863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jun 2015 15:07:47 GMT Received: from [10.129.24.94] (10.129.24.94) by xhc-aln-x10.cisco.com (173.36.12.84) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 19 Jun 2015 10:07:46 -0500 Message-ID: <55843044.8050405@cisco.com> Date: Fri, 19 Jun 2015 09:07:48 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nico Williams References: <557F2650.4070404@cisco.com> <5582DF53.3000703@cisco.com> <20150618171847.GO6117@localhost> <55842FCB.5030500@cisco.com> In-Reply-To: <55842FCB.5030500@cisco.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.94] Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Scheduling Issues for IETF 93 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, 19 Jun 2015 15:07:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 6/19/15 9:05 AM, ⌘ Matt Miller wrote: > On 6/18/15 11:18 AM, Nico Williams wrote: >> On Thu, Jun 18, 2015 at 09:10:11AM -0600, ⌘ Matt Miller wrote: >>> On 6/15/15 1:24 PM, ⌘ Matt Miller wrote: >>>> My questions to the Working Group are: >>>> >>>> 1) Is a physical meeting in Prague necessary? If not, the >>>> chairs will relinquish our slot for Prague. >>>> >>>> 2) If a physical meeting in Prague is necessary, are there >>>> any objections to co-locating with DANE? >>> >>> There have been no responses to this message, nor have there >>> been requests for time than the one topic received. I >>> interpret this to mean a physical meeting in Prague is >>> unnecessary. > >> Agreed. > > > The Kitten Working Group will have a session at IETF 93. Arrgh!!! That should be "will not". The Kitten Working Group will *not* have a session. Sorry for the confusion. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVhDBEAAoJEDWi+S0W7cO1BVEH/3rED0lagyMwNaEtrPmc2DMb QoMPtLOe+cAM4oRVt93dPYQOSDy06leH9/ktl6qEpRMBXN6TsGAK5Q6E/u5g0p8r 8NHQpmEUxnOA6fWQ4ki8iuEGlcnksn/6RDAha+k3sVeVKlDNViuKZMNl7gqdCVFq Mqh7luOgKeUcKIake36EUHclh3dD6f6A5CdR+4ofcEcNQ5l74YVId2TOjAfg719w NrJnnFYNZ8ZqoQgKcP9eJ7kXztW5ZSp8yZ+RoxYErA0jAG8sZF2yiBVetCkELN2d SILc0i0n4C7srvcRFmlQVoDwtmo2/A/6P83HmjlJtGbYbhymRDcTScfmcQStrUk= =4Rur -----END PGP SIGNATURE----- From nobody Fri Jun 19 12:57:52 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197EB1AD375 for ; Fri, 19 Jun 2015 12:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 PlH8AjVFjPrJ for ; Fri, 19 Jun 2015 12:57:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511391AD47E for ; Fri, 19 Jun 2015 12:57:50 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) with Microsoft SMTP Server (TLS) id 15.1.195.6; Fri, 19 Jun 2015 19:57:45 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.103]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.103]) with mapi id 15.01.0195.005; Fri, 19 Jun 2015 19:57:45 +0000 From: Michiko Short To: "kitten@ietf.org" , Benjamin Kaduk Thread-Topic: draft-ietf-kitten-pkinit-freshness-01.txt Thread-Index: AdCqycf8CTWMbKMGSLe5aGfFVJT4ng== Date: Fri, 19 Jun 2015 19:57:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-exchange-diagnostics: 1; BL2PR03MB210; 5:BrwHNIL8+/utaxJQHLR2jxbulHPExQpI06EDYGrX38aCn4gp015R9o23KtBOheu0V7RmUdN+PMJqNNSapHt+Mrf3itqFscqBl0ATuXOj/vyPwbH1RzKG2f4DMo9HWoxlh8YWASbgWa1rQJhKkPjqPQ==; 24:OT5/ar9VcKpSM+HzFh8l1NH7zSsLncuZMHndFICJIGdDlsePWrCu/v97EDIqOaWveiOohRQEb2mdTWKSKi/mL45EcvdJEW/W0mizwdNriJQ=; 20:xekPfw9klnR9mJ8csnokpLsHir5PmOjHixFnL5yuyQu30mFejllS5CAf/29R3PxvW/5xS2Wv1vP+9illMUAb7Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB210; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB210; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB210; x-forefront-prvs: 0612E553B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(87936001)(189998001)(54356999)(86362001)(19300405004)(99286002)(2656002)(2171001)(86612001)(74316001)(107886002)(558084003)(5002640100001)(110136002)(5001960100002)(229853001)(19580395003)(230783001)(5001770100001)(102836002)(15975445007)(77156002)(76576001)(62966003)(92566002)(2900100001)(16236675004)(5003600100002)(50986999)(2501003)(33656002)(122556002)(46102003)(40100003)(19625215002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB210; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BL2PR03MB212C650A42B863B9891422CD0A40BL2PR03MB212namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2015 19:57:45.7375 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB210 Archived-At: Subject: [kitten] draft-ietf-kitten-pkinit-freshness-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 19:57:52 -0000 --_000_BL2PR03MB212C650A42B863B9891422CD0A40BL2PR03MB212namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe we have answered Ben's question about client requesting the new f= eature. Ben, can you confirm? If so, then I would like to see if we can put this in the queue for WGLC. Thanks, Michiko Short Program Manager | Authentication Protocols Operating Systems Group: OS Security --_000_BL2PR03MB212C650A42B863B9891422CD0A40BL2PR03MB212namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe we have answered Ben’s question abou= t client requesting the new feature. Ben, can you confirm?

 

If so, then I would like to see if we can put this i= n the queue for WGLC.

 

 

Thanks,

Michiko Short

Program Manager | Authentication Protocols

Operating Systems Group: OS Security

 

--_000_BL2PR03MB212C650A42B863B9891422CD0A40BL2PR03MB212namprd_-- From nobody Mon Jun 22 09:12:08 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678C11A8772 for ; Mon, 22 Jun 2015 09:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xhhhnUkleoI for ; Mon, 22 Jun 2015 09:12:04 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8DB1A874C for ; Mon, 22 Jun 2015 09:12:03 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-2e-558833d24c50 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 24.04.21268.2D338855; Mon, 22 Jun 2015 12:12:02 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t5MGC15I019507; Mon, 22 Jun 2015 12:12:01 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5MGBvI9012779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 12:11:58 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t5MGBusP007441; Mon, 22 Jun 2015 12:11:56 -0400 (EDT) Date: Mon, 22 Jun 2015 12:11:56 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20150616200236.GC6117@localhost> Message-ID: References: <1434376077.22266.10.camel@willson.usersys.redhat.com> <557F305C.8020804@mit.edu> <20150616200236.GC6117@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6nrnvJuCPUoOuMgMXRzatYLE5dO8Jm 8WPuIlYHZo+Xp84xeixZ8pPJ4/2+q2wBzFFcNimpOZllqUX6dglcGZsa17IXzBatWHVkB2MD 43+BLkZODgkBE4kN+7+wQdhiEhfurQezhQQWM0mcXJzaxcgFZG9klFi9Yio7hHOISeLTvQnM EE4Do8S/qSfAWlgEtCUmrethAbHZBFQkZr7ZCBYXEdCUuD5vKZjNLBApMXFrC9AkDg5hAVeJ Zd95QcKcAnoS//svgpXwCjhK3LgwiRFi/lJGiQPbO9lBEqICOhKr909hgSgSlDg58wkLxEwt ieXTt7FMYBSchSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0jvdzMEr3UlNJNjKDw 5ZTk3cH47qDSIUYBDkYlHt4Z9u2hQqyJZcWVuYcYJTmYlER5S406QoX4kvJTKjMSizPii0pz UosPMUpwMCuJ8LacBSrnTUmsrEotyodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLg nQIyVLAoNT21Ii0zpwQhzcTBCTKcB2j4F5Aa3uKCxNzizHSI/ClGRSlx3mUgCQGQREZpHlwv LL28YhQHekWYdx5IFQ8wNcF1vwIazAQyOLcNZHBJIkJKqoExg0P1of3yuneqtWe3P1Pb/3pN semGxtNmU27Yvdn/9w6Dc5PaCuUzZjeYOQsavrr+cuBf9FDOP2vFsQ3OB1d8mPN0f9Xzvww7 9sZfeS2a8aV106TFdzfe2e/x1fLvi6AmB8HH/7LelpW/6bhzit1eaYnxRMH05U0iGYyLD0u3 5TG9DbrP2uB4T4mlOCPRUIu5qDgRANyzJxQKAwAA Archived-At: Cc: kitten@ietf.org, Simo Sorce Subject: Re: [kitten] SPAKE preauth: deriving RFC3961 encryption keys 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, 22 Jun 2015 16:12:06 -0000 On Tue, 16 Jun 2015, Nico Williams wrote: > On Mon, Jun 15, 2015 at 04:06:52PM -0400, Greg Hudson wrote: > > I am primarily asking whether people think it is okay to use the > > existing PRF+ method with a low-entropy key and a high-entropy input > > string, or whether we need to add an unkeyed hash function to the > > profile and use H+(n||"SPAKEKey"||K||w||cksum||body). > > Thanks for summarizing it so well. > > The PRF+() comes from RFC6113, and relies on the RFC3961 pseudo-random(). > The latter has specific requirements. > > The requirements for pseudo-random() do not make it entirely clear that > using a low-entropy ("public") key and high-entropy (confidential) input > is safe. But for the simplified profile it's clear that it can only be > safe to use pseudo-random() with low-entropy keys / high-entropy inputs > when the output of pseudo-random() is kept confidential. > > For the particular purpose of generating confidential keys, then, I > think PRF+() with low-entropy key and high-entropy input seems OK. > Asking a cryptographer seems like a good idea though! The problem is that we cannot assume the use of the simplified profile (indeed, the pending aes-sha2 enctype does not use the simplified profile), and the requirements in 3961 for the pseudo-random function are not worded in a particularly stringent way: % pseudo-random (protocol-key, octet-string)->(octet-string) % This pseudo-random function should generate an octet string of % some size that is independent of the octet string input. The PRF % output string should be suitable for use in key generation, even % if the octet string input is public. It should not reveal the % input key, even if the output is made public. While it should certainly be the case that the output string is useful for key generation when the input string is private, there is not really anything there to indicate how much of the input must be "mixed" into the output, or to indicate that the output when a low-entropy input key can have more entropy when such is present in the input octet string. Thus, while I believe proposal #1 is safe with all exisiting public enctypes (and proposed enctypes that are WG documents), I do not feel comfortable claiming that it will always be safe, in a formal manner. That said, introducing an unkeyed hash as for proposals #2 and #3 seems like overkill. I think I'd be more inclined to make this document update 3961 and provide more clarity for the pseudo-random function requirements. -Ben P.S. for completeness, I don't think the additional combining in #3 is needed; #2 seems to comply with the spirit of 6113. From nobody Wed Jun 24 14:45:11 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE5F1B2E5E for ; Wed, 24 Jun 2015 14:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_gYAGj6NozC for ; Wed, 24 Jun 2015 14:45:08 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519FF1B2E51 for ; Wed, 24 Jun 2015 14:45:08 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-49-558b24e2f2f6 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 22.DC.21268.2E42B855; Wed, 24 Jun 2015 17:45:06 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t5OLj5pl008842; Wed, 24 Jun 2015 17:45:06 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5OLj3AV010887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Jun 2015 17:45:05 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t5OLj3oe023324; Wed, 24 Jun 2015 17:45:03 -0400 (EDT) Date: Wed, 24 Jun 2015 17:45:03 -0400 (EDT) From: Benjamin Kaduk To: Michiko Short In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6novtIpTvU4MQxXYujm1exWPzr5nNg 8liy5CeTR+uOv+wBTFFcNimpOZllqUX6dglcGY3NX9kKmnkr+mZNY2xgvMvVxcjJISFgItF8 cTEbhC0mceHeeiCbi0NIYDGTxINHrawQzkZGicvzXjFCOIeYJPb//80C4TQwSrR9eAfUw8HB IqAtsf1cMsgoNgEViZlvNoKNFRHQkvhw4TQLiM0soC7x7cwbRhBbWMBM4u7990wgrZwC0RKT ZiqDmLwCjhJ/HvqDVAgJREl8WrENrFNUQEdi9f4pYDavgKDEyZlPoCZqSSyfvo1lAqPgLCSp WUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuka6eVmluilppRuYgQFKack7w7GdweVDjEK cDAq8fCu+NAZKsSaWFZcmXuIUZKDSUmUV1CpO1SILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG+r IlCONyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCV0EZqFGwKDU9tSIt M6cEIc3EwQkynAdo+HeQxbzFBYm5xZnpEPlTjIpS4ryhIM0CIImM0jy4XlgSecUoDvSKMO8G kCoeYAKC634FNJgJaPDb+C6QwSWJCCmpBsaySZee3Zk96f7Gx+0sE5qYd088cSIvUCSr8sah +xfOTTzMpvBEWKSEYemeE7qn+998q1ApZ3L/49l8P6PZ8I6KQ5Rm8hHV3seZQW84ixkWrV2/ c9nfJI3iNZ80P+1MNX39oKTZLVcx9vEpmUMsk5NqSz4fEb129oLmRJHeaZyup3aG5C0rzdZW YinOSDTUYi4qTgQAsrjslP0CAAA= Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-ietf-kitten-pkinit-freshness-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 21:45:10 -0000 On Fri, 19 Jun 2015, Michiko Short wrote: > I believe we have answered Ben's question about client requesting the > new feature. Ben, can you confirm? Sorry for the delay; it took me longer than I expected to reconstruct the history of the discussion. For the curious: I raised the question in http://www.ietf.org/mail-archive/web/kitten/current/msg05630.html of whether we are okay requiring all clients implementing freshness token support to implement the behavior of sending an empty PA_AS_FRESHNESS padata in order to request a freshness token. Michiko acknowledged this in http://www.ietf.org/mail-archive/web/kitten/current/msg05645.html and also mentioned two other options for ways for clients to get freshness tokens, though I don't think either got much discussion. (As described, neither seems particularly appealing, so that seems fine.) There was some follow-up discussion starting at http://www.ietf.org/mail-archive/web/kitten/current/msg05665.html , where Sam and Greg seem to agree that the proposed behavior (requiring the clients to explicitly request a freshness token) is acceptable, with varying degrees of enthusiasm. There is still disagreement about whether this sort of negotiation is required, but it seems clear that it is permitted, and no one is raising blocking objections. > If so, then I would like to see if we can put this in the queue for WGLC. I agree. I was hoping to get out a poll on what potential new work the WG is interested in undertaking (and in what order) before starting the next WGLC, but that seems to be taking much longer than I expected. Stay tuned for more... -Ben From nobody Thu Jun 25 11:44:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16B81A8AD7; Thu, 25 Jun 2015 11:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4w_oXzH6AVJ; Thu, 25 Jun 2015 11:44:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B26701A8AC9; Thu, 25 Jun 2015 11:44:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150625184429.1312.27540.idtracker@ietfa.amsl.com> Date: Thu, 25 Jun 2015 11:44:29 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-cammac-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: Thu, 25 Jun 2015 18:44:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Kerberos Authorization Data Container Authenticated by Multiple MACs Authors : Simo Sorce Tom Yu Thomas Hardjono Filename : draft-ietf-kitten-cammac-03.txt Pages : 10 Date : 2015-06-25 Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-cammac-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-cammac-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/