From nobody Fri Apr 3 09:29:52 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EBC3A1A3A for ; Fri, 3 Apr 2020 09:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=josefsson.org 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 3y183r4E18-J for ; Fri, 3 Apr 2020 09:29:47 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b1:8633::105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526023A1B15 for ; Fri, 3 Apr 2020 09:29:45 -0700 (PDT) Received: from latte (31-208-42-58.cust.bredband2.com [31.208.42.58]) (authenticated bits=0) by duva.sjd.se (8.15.2/8.15.2/Debian-8) with ESMTPSA id 033GTVhY014436 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 3 Apr 2020 16:29:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=josefsson.org; s=default; t=1585931373; bh=S5uH/LN/0rwVGEOkTI3q72pGvgHxhx+e/X6SaGbraRo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=j65k+6SIDzCX66Oh0mc5M5Wzsc38c2xSdvElJTOhtl0Ro6XrMZ5B2F+SCaVZo2iyz lKoZz9yXXJeciHCne9AU+amZQNa5vvD12Q3dvVMWTT6TNPARQhypXS1li583WogI+I bTW7l0/PZ9MggBBeucYMKH1pESRo2F0mz7bWzaAzKT1Gt5GpaDE3W1P76nCyFhTokA H8doPBmu+ldyO/1rDNwze21LA6CJVLUe+mTXZaoFgT7hcJMROxWZFoPePZE+XtocTW LQz0JSPCA/0t8hRnR1NN6a332B9/vH7C2dGzhxODZ5hjMZag8cghfgDfG28JSeMX1j sIw6E1Zlge0dQ== From: Simon Josefsson To: Alexey Melnikov Cc: kitten@ietf.org References: <158462386052.13384.7911173297625270492@ietfa.amsl.com> <1330abb0-f0ae-3399-0486-4d7f7ff63267@isode.com> OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt X-Hashcash: 1:22:200403:kitten@ietf.org::XRvFloVYmRfwnIHC:N0uh X-Hashcash: 1:22:200403:alexey.melnikov@isode.com::0IvHvXOMYVtMcrHD:vG3o Date: Fri, 03 Apr 2020 18:29:30 +0200 In-Reply-To: <1330abb0-f0ae-3399-0486-4d7f7ff63267@isode.com> (Alexey Melnikov's message of "Thu, 19 Mar 2020 13:25:58 +0000") Message-ID: <87tv20bkid.fsf@latte.josefsson.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.102.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: Re: [kitten] Fwd: I-D Action: draft-melnikov-scram-2fa-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 16:29:50 -0000 --=-=-= Content-Type: text/plain Thanks for working on this. What we discovered with the OpenID/SAML SASL mechanisms was that a major challenge was to resolve how to resume sessions in a SASLy way. To be more specific, the challenge is that a lot of client applications (IMAP in particlar) expect to be able to open several sessions to the server. Having a user perform manual steps per session won't work, and from a quick look at your document, it looks like this problem isn't resolve here either. What is needed is some way to perform the 2FA authentication once, and then be able to refer to that authentication in a new SASL authentication step. With re-newed energy and interest in this, I beliece we can do better now though. Some ideas: 1) Specify how TLS resumption of a SASL authenticated session should assume the same SASL authentication/authorization identity. 2) Specify how EXTERNAL (or some new mechanism) is to be used to "resume" an earlier 2FA authenticated SASL session. 3) Describe how OAUTH could be used to achieve this. 4) Extend your proposal to generate a magic cookie after successful authentication that can be provided instead of the 2FA code next time. The problem is not exactly how to do it: it is to describe one well-agreed on method that all application implementers can follow, to get interoperability. I believe it is a bad idea to implement a generic 2FA mechanism on top of SCRAM, it will be too flexible with bad interop as a result. Instead, implement specific 2FA methods so things become easily implementable. Your document could be a SCRAM-OATH-TOTP rather than SCRAM-2FA. OATH-HOTP/TOTP, U2F, FIDO2, etc each have different behaviours that make it difficult to support in a generic protocol. /Simon Alexey Melnikov writes: > Hi all, > > As I had various conversations with people saying that SASL doesn't > support 2 factor authentication, I posted a short draft which shows > how to add 2 factor authentication to SCRAM. This is mostly a proof of > concept and I am planning to work on another draft explaining how to > do the same for SASL OAUTH. > > (If I remember correctly I also talked to Dave Cridland about doing a > more generic extension to the SASL framework itself by allowing > protocols to invoke multiple SASL mechanism in a sequence and > achieving 2FA that way. I would be interested in developing this > concept as well, but it would take longer than just extending some > existing SASL mechanisms.) > > If people can have a look and provide feedback, that would be much > appreciated. > > Best Regards, > Alexey > -------- Forwarded Message -------- > Subject: I-D Action: draft-melnikov-scram-2fa-00.txt > Date: Thu, 19 Mar 2020 06:17:40 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Extensions to Salted Challenge Response (SCRAM) for 2 factor > authentication > Author : Alexey Melnikov > Filename : draft-melnikov-scram-2fa-00.txt > Pages : 5 > Date : 2020-03-19 > > Abstract: > This specification describes an extension to family of Simple > Authentication and Security Layer (SASL; RFC 4422) authentication > mechanisms called the Salted Challenge Response Authentication > Mechanism (SCRAM), which provides support for 2 factor > authentication. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-melnikov-scram-2fa/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-melnikov-scram-2fa-00 > https://datatracker.ietf.org/doc/html/draft-melnikov-scram-2fa-00 > > > 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/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSjzJyHC50xCrrUzy9RcisI/kdFogUCXodkagAKCRBRcisI/kdF ojdtAP4x73g8lD1DUJCcNMuEDzBZghlzHoSKdpfQ26CpBb7k/QD/QrZFc6am8dcw F0wgigsgVUeEOrzqx6VN1pp1ZT9gLwo= =Pp2g -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Apr 4 04:19:09 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E894F3A09F7 for ; Sat, 4 Apr 2020 04:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=josefsson.org 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 SpciGxRYOznW for ; Sat, 4 Apr 2020 04:19:03 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b1:8633::105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868C83A09F9 for ; Sat, 4 Apr 2020 04:19:03 -0700 (PDT) Received: from latte (31-208-42-58.cust.bredband2.com [31.208.42.58]) (authenticated bits=0) by duva.sjd.se (8.15.2/8.15.2/Debian-8) with ESMTPSA id 034BIie5018676 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 4 Apr 2020 11:18:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=josefsson.org; s=default; t=1585999126; bh=uL+u1E7Mj4T+gJj2QotKDHrzyX7Zmf+yL+7dl27nrpY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=ez3qocKzEXXmy3erDb+b4axm/lxWcF3jKO+5f0OqTgNt6FJtMg8ysC28Fca2SdNvE h/5cXSp6xem8b28+DLMxPimh0+zvhGQIYpRrib00Y1tp9Q2mlIDVi3lvu9HGl6c06/ HEYKuV13jPc0o8mQK2QDGQB1RNbAaEf9faAumnS36Vd6XkBjVxtquMj4MC7uelCKp4 0P3ddjt+sy26j5puFIPRFz/MExrnPQrRngJ+lVFo/V/zRbanIxZRMJMNPIR+e9QpdA L2VjCcxzPSVcuponCnyLBbVZ9/bxLJeYwWKhUYIwxrJa0HbAYMXSHNhRXauLhEIf6N iKRvQ2yblZkNg== From: Simon Josefsson To: Luke Howard Cc: "kitten\@ietf.org" References: <158562149038.11496.7234948048087895644@ietfa.amsl.com> <03F73286-C983-44C6-B10D-7E826AE2C609@padl.com> OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt X-Hashcash: 1:22:200404:kitten@ietf.org::kqPTXWcv3Tw1ChLP:MQP X-Hashcash: 1:22:200404:lukeh=40padl.com@dmarc.ietf.org::+XwmZndVecDzDnsK:O8Sa Date: Sat, 04 Apr 2020 13:18:44 +0200 In-Reply-To: <03F73286-C983-44C6-B10D-7E826AE2C609@padl.com> (Luke Howard's message of "Tue, 31 Mar 2020 13:28:11 +1100") Message-ID: <87pncnbisr.fsf@latte.josefsson.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.102.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: Re: [kitten] Fwd: New Version Notification for draft-howard-gss-sanon-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2020 11:19:07 -0000 --=-=-= Content-Type: text/plain Luke Howard writes: > Hi everybody, > > Below is a specification for a simple anonymous mechanism based on > curve25519 that does not authenticate either initiator or acceptor. Interesting! When would this be useful in SASL? GS2 requires that the mechanism supports mutual authentication, so while I definitely see value in having this as a GSS-API mechanism I don't understand when it would provide value for a SASL application, and how it would actually work in GS2. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSjzJyHC50xCrrUzy9RcisI/kdFogUCXohtFAAKCRBRcisI/kdF ovJSAP9fvZZRQuZj0SXd35V1grlqgvheBFXd0bqy8xzvMllu/wD/f+fURPx5sg7F +k/MwEEWvYmHM+CZ8+SMvURULT3Ufwo= =C14W -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Apr 4 04:23:21 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7153A0A0F for ; Sat, 4 Apr 2020 04:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYh22kutf5dN for ; Sat, 4 Apr 2020 04:23:19 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3776B3A0A0E for ; Sat, 4 Apr 2020 04:23:19 -0700 (PDT) Received: by us.padl.com with ESMTP id 034BN9bx024191; Sat, 4 Apr 2020 11:23:13 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 034BN9bx024191 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1585999394; bh=71CcTMFE3A+x511wQ429NbUeaiz7wLnva6iGlnSJfR8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=NBApT1bNUF/UdD+i+oEoJVdSOxepdYGUNoHUbG6ORl/739TAwXVTlakX1hWrK9s0A TOP85i5QCbUG76YxFkhyD6XGGHIErP4PEToah9QYdAl2nyV/f9unRvJcPzHj3CgEhR dQl7l+5VNFrEeZiUTWKGX4FHmtMWNsXTNL1fMf0kOgauAsSjoPNRZWsOlT7V+s9E2c Jx14dIDkgrVga/AtE8u1kWVatoknASHlMn4SEGRHes9aEqMoruVXpq6YJ1zet4k03h SKMoiqICuS5bvk+oxS1f/waKuEdDiWaUgn+xrapUMKlCZpwisLOGYD/Fowyhar8WuA gtKGWQerUZ/eg== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Luke Howard In-Reply-To: <87pncnbisr.fsf@latte.josefsson.org> Date: Sat, 4 Apr 2020 22:23:08 +1100 Cc: Luke Howard , "kitten@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <158562149038.11496.7234948048087895644@ietfa.amsl.com> <03F73286-C983-44C6-B10D-7E826AE2C609@padl.com> <87pncnbisr.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2020 11:23:20 -0000 >> Below is a specification for a simple anonymous mechanism based on >> curve25519 that does not authenticate either initiator or acceptor. >=20 > Interesting! When would this be useful in SASL? GS2 requires that = the > mechanism supports mutual authentication, so while I definitely see > value in having this as a GSS-API mechanism I don't understand when it > would provide value for a SASL application, and how it would actually > work in GS2. I hadn=E2=80=99t really thought through the GS2 use case, to be honest. = Remind me (sorry if it=E2=80=99s a dumb question) why GS2 requires = mutual? It does support channel bindings because the key derivation includes the = channel binding application data.= From nobody Sat Apr 4 04:26:23 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039B93A0A46 for ; Sat, 4 Apr 2020 04:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xumVEgRWscCt for ; Sat, 4 Apr 2020 04:26:21 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2197B3A0A45 for ; Sat, 4 Apr 2020 04:26:21 -0700 (PDT) Received: by us.padl.com with ESMTP id 034BQDmc024393; Sat, 4 Apr 2020 11:26:18 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 034BQDmc024393 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1585999579; bh=K2wpjFuHG/DTEGSgXZ5iP7QRWtucssYBg90tEhL/Z04=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=dneJme4X0066aRJjj/9rpF/1xMaFaAAyMY7ROODvKCokDM0vXx9+rgmRVpL0vu30q TbtL4UFUNh0t25v/Sqmccapc4+9fVjRdJNDITRhlc4WYTgvTZIXuqPGXJAQ2mqf5yR HxvGfWBWKIRoLE+fnEflPVf86M4Bj0krVvXR93p3x0ULPzyB4bIF6u25JwfmSLWhgc ty4FyTBy7MX9mjBDMm5JhryYo3Yh5NRcEnQWtU7P5ZKI/ytnGiRMNBye7owrSlQHvI i5jqMIA1llSTBFOzCUO3UJgOPeS5Kj+tVz83Cjwb27j8KyynWIa8ytBQQCMpR00Y0G UnnwooQDoDxUw== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Luke Howard In-Reply-To: Date: Sat, 4 Apr 2020 22:26:13 +1100 Cc: Luke Howard , "kitten@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <158562149038.11496.7234948048087895644@ietfa.amsl.com> <03F73286-C983-44C6-B10D-7E826AE2C609@padl.com> <87pncnbisr.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2020 11:26:22 -0000 >> Interesting! When would this be useful in SASL? GS2 requires that = the >> mechanism supports mutual authentication, so while I definitely see >> value in having this as a GSS-API mechanism I don't understand when = it >> would provide value for a SASL application, and how it would actually >> work in GS2. >=20 > I hadn=E2=80=99t really thought through the GS2 use case, to be = honest. Remind me (sorry if it=E2=80=99s a dumb question) why GS2 = requires mutual? >=20 > It does support channel bindings because the key derivation includes = the channel binding application data. Ah yes, SASL GS2 doesn=E2=80=99t give you message protection does it. So = you can=E2=80=99t actually do anything much useful with the resulting = context.= From nobody Sat Apr 4 04:36:50 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298BB3A0A74 for ; Sat, 4 Apr 2020 04:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgL8cDkQ1MBY for ; Sat, 4 Apr 2020 04:36:48 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124EF3A0A6C for ; Sat, 4 Apr 2020 04:36:47 -0700 (PDT) Received: by us.padl.com with ESMTP id 034BadET025065; Sat, 4 Apr 2020 11:36:43 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 034BadET025065 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586000205; bh=sVovwxzGI2lJ+pgCvsuafqCJNVB4Mvdr5mYkP9bIohQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=tBXHCi4f3hjkkxzAIrbXYSnYw5w6tZfZkHf8/UH9TBXvdJIqTpH84VAoO6A0m6Vew vQabhauvccJFtiXqnUvtNw91U/QZQZ3kvUNLaCzJQKkzlO4nS2kabYFFy5LT3Pu04q okFVipBZXjzAj6NJjkew6jJH9MHjOZeH+iQ+CU9sKxUplFrFh6tKnMFliRAzRsbsiN /+0geGlebQffPHQIomKUPwLrblkq8FQ+soWXcgo4L5nVUeNHUWIbICTCfEmbH94JiB 8ofeqaNUGH0Mc9aPUnytA5jxjt/zTmGdqMuBPQBs/Pq725lDRabh9IYjpHmZD43VB2 UUqgshtD8fn+g== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Luke Howard In-Reply-To: Date: Sat, 4 Apr 2020 22:36:38 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <3AC48B31-9A84-41E1-8849-670BE4BD01F3@padl.com> References: <158562149038.11496.7234948048087895644@ietfa.amsl.com> <03F73286-C983-44C6-B10D-7E826AE2C609@padl.com> <87pncnbisr.fsf@latte.josefsson.org> To: "kitten@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2020 11:36:49 -0000 Another question: should GSS_C_MA_AUTH_INIT_ANON/GSS_C_MA_AUTH_TARG_ANON = be set? Is a mechanism valid if it sets neither of these attributes? = (Nico?) > On 4 Apr 2020, at 10:26 pm, Luke Howard wrote: >=20 >=20 >>> Interesting! When would this be useful in SASL? GS2 requires that = the >>> mechanism supports mutual authentication, so while I definitely see >>> value in having this as a GSS-API mechanism I don't understand when = it >>> would provide value for a SASL application, and how it would = actually >>> work in GS2. >>=20 >> I hadn=E2=80=99t really thought through the GS2 use case, to be = honest. Remind me (sorry if it=E2=80=99s a dumb question) why GS2 = requires mutual? >>=20 >> It does support channel bindings because the key derivation includes = the channel binding application data. >=20 > Ah yes, SASL GS2 doesn=E2=80=99t give you message protection does it. = So you can=E2=80=99t actually do anything much useful with the resulting = context. From nobody Sat Apr 4 17:03:12 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED583A0F11 for ; Sat, 4 Apr 2020 17:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m75HodxDkLA0 for ; Sat, 4 Apr 2020 17:03:10 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174583A0F10 for ; Sat, 4 Apr 2020 17:03:09 -0700 (PDT) Received: by us.padl.com with ESMTP id 03502VHd008510; Sun, 5 Apr 2020 00:02:35 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 03502VHd008510 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586044957; bh=klorx4uzrBeyix/QXnhjwOHz7/RMo4w98GOdlLssRvg=; h=From:Subject:Date:References:Cc:To:From; b=P6Kx5zUcoNHAW2rnzgJllxGzht1v04vcwUCTflKu0hWfCGZ/wRvXb5QVhrMAh7ZfR XPYb9iZfkIqqfJ+Opu9favRCwEUmZMvUEgQlcdOKTBh4vohYGYVFPD8snunzUsMNIa 8Yty6jTCjUtg91S8YkhR3/6BfDVwxOL4f4t/yvTqtd7339K2oW/dAhOYaQXOv5SWBV mttK0hRsk/gTPbrBrJYymLWiWIPAnSgqHnOWLeocG4RJryZnjVeRdcriTB/6u8Dqjl Ec+OV/OHyIm3uy+L3lzxZffxFS8RU2MyZiAAMLn4fl9b/MNxUWtiCrm8eQxfEmkarM kAATmf2udbRYw== From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_9BEBF76C-1A1B-411A-8A33-AE50AA8980E6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 5 Apr 2020 10:02:30 +1000 References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> Cc: Nicolas Williams , Jeffrey Altman , Greg Hudson To: "kitten@ietf.org" Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [kitten] Fwd: New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 00:03:12 -0000 --Apple-Mail=_9BEBF76C-1A1B-411A-8A33-AE50AA8980E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Changes: Remove references to SASL GS2 (thanks Simon) Explanation of initiator name-based anonymous authentication selection, = and compromises it entails Remove GSS_C_MA_AUTH_INIT/TARG mechanism attributes Fix IANA considerations to ask for OID General cleanups > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-howard-gss-sanon-01.txt > Date: 5 April 2020 at 9:58:41 am AEST > To: "Luke Howard" >=20 >=20 > A new version of I-D, draft-howard-gss-sanon-01.txt > has been successfully submitted by Luke Howard and posted to the > IETF repository. >=20 > Name: draft-howard-gss-sanon > Revision: 01 > Title: A Simple Anonymous GSS-API Mechanism > Document date: 2020-04-05 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-01.txt > Status: = https://datatracker.ietf.org/doc/draft-howard-gss-sanon/ > Htmlized: https://tools.ietf.org/html/draft-howard-gss-sanon-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-01 >=20 > Abstract: > This document defines protocols, procedures and conventions for a > Generic Security Service Application Program Interface (GSS-API) > security mechanism that provides key agreement without = authentication > of either party. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_9BEBF76C-1A1B-411A-8A33-AE50AA8980E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Changes:

  • Remove references to = SASL GS2 (thanks Simon)
  • Explanation of initiator = name-based anonymous authentication selection, and compromises it = entails
  • Remove GSS_C_MA_AUTH_INIT/TARG mechanism = attributes
  • Fix IANA considerations to ask for = OID
  • General cleanups

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-howard-gss-sanon-01.txt
Date: = 5 April 2020 at 9:58:41 am = AEST
To: = "Luke Howard" <lukeh@padl.com>

A new version of I-D, draft-howard-gss-sanon-01.txt
has been successfully submitted by Luke Howard and posted to = the
IETF repository.

Name: = draft-howard-gss-sanon
Revision: 01
Title:= = A Simple Anonymous GSS-API Mechanism
Document = date: = 2020-04-05
Group: Individual Submission
Pages:= = 10
URL: =            https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-01.= txt
Status: =         https://datatracker.ietf.org/doc/draft-howard-gss-sanon/Htmlized:       https://tools.ietf.org/html/draft-howard-gss-sanon-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-01

Abstract:
=   This document defines protocols, procedures and conventions = for a
  Generic Security Service Application = Program Interface (GSS-API)
  security = mechanism that provides key agreement without authentication
  of either party.




Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



= --Apple-Mail=_9BEBF76C-1A1B-411A-8A33-AE50AA8980E6-- From nobody Sun Apr 5 16:49:43 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF323A08E5 for ; Sun, 5 Apr 2020 16:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ehc6aPiXhsH9 for ; Sun, 5 Apr 2020 16:49:39 -0700 (PDT) Received: from camel.birch.relay.mailchannels.net (camel.birch.relay.mailchannels.net [23.83.209.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00843A08E3 for ; Sun, 5 Apr 2020 16:49:38 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2993E4007F2; Sun, 5 Apr 2020 23:49:38 +0000 (UTC) Received: from pdx1-sub0-mail-a32.g.dreamhost.com (100-96-22-19.trex.outbound.svc.cluster.local [100.96.22.19]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A3EFA400AF5; Sun, 5 Apr 2020 23:49:37 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a32.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Sun, 05 Apr 2020 23:49:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Supply-Whimsical: 7494a13754765018_1586130577940_2653758652 X-MC-Loop-Signature: 1586130577940:3598760176 X-MC-Ingress-Time: 1586130577940 Received: from pdx1-sub0-mail-a32.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a32.g.dreamhost.com (Postfix) with ESMTP id 5CAA57F5E6; Sun, 5 Apr 2020 16:49:37 -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=560XJ+hZ90cQB6 YIcfaymq6Ov2c=; b=obshkszPu+FBPNV95as6SACCRXkd3kXaZGi6To5h0c5XUV jzlXUikY+/u/2Zgyfz8ThGCS+7WwNTNKBdpaAeCg1sOQi/1upGb46XO9baK8y7yn PUHQaXzfKcOupz05GC/UN8TXJz1dcjll+KF7LzJzEncgLgL12pWmjUA00q5Yo= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a32.g.dreamhost.com (Postfix) with ESMTPSA id DBDC67F5DD; Sun, 5 Apr 2020 16:49:33 -0700 (PDT) Date: Sun, 5 Apr 2020 18:49:31 -0500 X-DH-BACKEND: pdx1-sub0-mail-a32 From: Nico Williams To: Luke Howard Cc: "kitten@ietf.org" , Jeffrey Altman , Greg Hudson Message-ID: <20200405234929.GD18021@localhost> References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedruddvgddviecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [kitten] Fwd: New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 23:49:41 -0000 - Section 1 Another potential use of SAnon would be as a substrate for constructing other mechanisms. (Recall discussion of "stackable" mechanisms... what, 15 years ago?) - Section 3, regarding NegoEx... | The means of discovering GSS-API peers and their supported mechanisms | is out of this specification's scope. However, when the Simple and | Protected Negotiation mechanism (SPNEGO) defined in [RFC4178] is | used, the mechanism MUST be negotiated under [I-D.zhu-negoex]. [...] Hmm, well, can this MUST be relaxed to apply only when the initiator supports [I-D.zhu-negoex]? Alternatively, maybe remove it. After all, [I-D.zhu-negoex] imposes the requirement, not this document. I see you're aiming to publish this on the Experimental Track. If you want to eventually get on the Standards Track (why not now?), [I-D.zhu-negoex] not being an RFC (let alone a Standards-Track RFC) would block this document's progress. Phrasing this as a requirement imposed by [I-D.zhu-negoex], or not mentioning it at all, would cure that problem. - Section 3 | The selection of SAnon is subject to local policy. [...] Did you mean, its selection via SPNEGO/NegoEx? But apps can use GSS_Set_neg_mechs(), so I'd say that selection is not a matter of local policy, except in any case where multiple mechanisms are supported by both the initiator and the acceptor, and no preference can be gleaned from the applications (is that possible?) In any case, I think you might want to say that when using the default credential and a non-anonymous target name, and when GSS_Set_neg_mechs() was not used (or was used and did not list SAnon), then SAnon MUST NOT be negotiated. | [...]. If anonymity is | not desired, mechanisms that provide authentication SHOULD be | preferred. [...] Hmm, I'd say that if "anonymity is not desired" then SAnon MUST NOT be used. Also, phrasing it as "mechanisms that .... SHOULD be preferred" sounds like an update to SPNEGO/NegoEx. Indeed, the need to understand that SAnon cannot authenticate the acceptor to the initiator imposes on SPNEGO/NegoEx, so an update might be unavoidable. Another option would be to say that SPNEGO/NegoEx can only negotiate SAnon when it is explicitly a credential element in the initiator's non-default credential or it is referenced in GSS_Set_neg_mechs(). This approach imposes no need to update SPNEGO/NegoEx. | [...]. Initiators use GSS_C_ANON_FLAG or the well known | anonymous credential to indicate that anonymous authentication is | desired. Either party can test for the presence of GSS_C_ANON_FLAG | to check if anonymous authentication was performed. Or the default credential and a GSS_C_NT_ANONYMOUS name for the target acceptor! It may be useful to enumerate the ways to end up using SAnon. - Section 4.1.1 The SHOULD in this section should be a MUST. - Section 4.1.2 Huh! Works for me. - Section 4.1.3 Perhaps we could say this for all name-types on the acceptor side. - Section 4 It's important to state that the name as observed by the peer is always GSS_C_NT_ANONYMOUS. This should probably be its own sub-session inserted before 4.1. - Section 4.1.4 The name string displayed should either be a constant OR, better yet, a base64-encoded hash of the peer's DH key! The latter especially after context establishment. - GSS_Display_name(GSS_Canonicalize_name( mech=SAnon, name=GSS_Import_name(GSS_C_NT_ANONYMOUS, "whatever"))) -> "whatever" - GSS_Display_name(GSS_Inquire_context_peer_name(context)) -> base64_encode(hash(dh_pubkey)) More later, Nico -- From nobody Sun Apr 5 17:45:42 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB453A0A1B for ; Sun, 5 Apr 2020 17:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGiz-xcWP7mV for ; Sun, 5 Apr 2020 17:44:51 -0700 (PDT) Received: from chocolate.birch.relay.mailchannels.net (chocolate.birch.relay.mailchannels.net [23.83.209.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61BB13A0A0B for ; Sun, 5 Apr 2020 17:44:51 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8AEA43409C4; Mon, 6 Apr 2020 00:44:50 +0000 (UTC) Received: from pdx1-sub0-mail-a32.g.dreamhost.com (100-96-23-11.trex.outbound.svc.cluster.local [100.96.23.11]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 10AA63403AD; Mon, 6 Apr 2020 00:44:50 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a32.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 06 Apr 2020 00:44:50 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Chemical-Bored: 010866c131e99e93_1586133890345_1318853072 X-MC-Loop-Signature: 1586133890345:488020027 X-MC-Ingress-Time: 1586133890345 Received: from pdx1-sub0-mail-a32.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a32.g.dreamhost.com (Postfix) with ESMTP id B604D7FF0B; Sun, 5 Apr 2020 17:44:49 -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=RxNL6T/uwuDL8I uhXWc7vCMfEFI=; b=wbgtapQ0qifY0XS7eeAlRSbWBOrox5lcV4xa4JW8xylpCQ oVs2ITq7ZRQTckFRmZHar3v48tv1s8xb0j5/M3lFTAlVKCHcG+KV3oAvZLl6H605 lnO4yvEiWCBABcPcclx92hqpmEGq6WbxJl0y4cB/hUquBE2dufhRWA6rk4vPk= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 03E967FF00; Sun, 5 Apr 2020 17:44:47 -0700 (PDT) Date: Sun, 5 Apr 2020 19:44:45 -0500 X-DH-BACKEND: pdx1-sub0-mail-a32 From: Nico Williams To: Luke Howard Cc: "kitten@ietf.org" , Jeffrey Altman , Greg Hudson Message-ID: <20200406004444.GE18021@localhost> References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200405234929.GD18021@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedruddvgdefkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [kitten] Fwd: New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 00:45:01 -0000 On Sun, Apr 05, 2020 at 06:49:31PM -0500, Nico Williams wrote: > - Section 4.1.4 > > The name string displayed should either be a constant OR, better yet, > a base64-encoded hash of the peer's DH key! The latter especially > after context establishment. > > - GSS_Display_name(GSS_Canonicalize_name( > mech=SAnon, > name=GSS_Import_name(GSS_C_NT_ANONYMOUS, "whatever"))) > -> "whatever" > > - GSS_Display_name(GSS_Inquire_context_peer_name(context)) > -> base64_encode(hash(dh_pubkey)) Even better: base64(dh_pubkey). And even better too if that can be used as a target name. Then we'd have the building blocks of a modern mech_dh. - Section 6.1.2 The acceptor should also send a MIC along with the key, thus proving it has possession of the shared secret. This is important, otherwise reply tokens could be replayed, and though it wouldn't be much of an attack, it's worth doing. - Section 6 There should be a requirement that new DH keys be generated every time, no? Especially on the initiator side, and especially if you don't add the use of a MIC in the response token (see previous comment). - If you allow a target name to be imported as an anonymous name whose value is the base64 encoding of a raw public key, then the initial context token should send two public keys, and the response token should be just a MIC. I->A: {PK_i, PK_a} A->I: MIC(SK, {PK_i, PK_a}) || (ahh, you'd have to define an error message, but it could just be a 1-byte code) Note that to reuse keys really does require nonces. So those would have to be added: I->A: {PK_i, PK_a, nonce} A->I: MIC(SK, {PK_i, PK_a}) || You could even have a half round-trip variant where the initiator sends {PK_i, PK_a, nonce, MIC} and the acceptor sends nothing. The length of the initiator context token would say all that's needed -- no ASN.1/DER or whatever would be needed. - Section 7 | context the concatenation of the initiator and acceptor public | keys, along with the channel binding application data | (if present) Add "in that order"? - Section 7 | The session key K1 is used as the base key for the generation of per- | message tokens and the GSS-API PRF. The encryption type of K1 is | aes128-cts-hmac-sha256-128 as defined in [RFC8009]. There should be a reference here to RFC4121. Also, RFC4121 doesn't mention a K1. I suspect you need to state how to derive a key of the enctype (aes128-cts-hmac-sha256-128) that would be equivalent to the AcceptorSubkey. You might want to mention that four keys are to be derived from that per RFC4121 section 2, plus the GSS_Pseudo_random() key (GSS_C_PRF_KEY_FULL) [RFC8009]. - Test vectors? - Section 10 This section should repeat something about the importance of SAnon not being negotiated when it's not appropriate. Done. Nico -- From nobody Sun Apr 5 17:51:46 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3356A3A0A47 for ; Sun, 5 Apr 2020 17:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juQLKSKS4lld for ; Sun, 5 Apr 2020 17:51:42 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F693A0A1D for ; Sun, 5 Apr 2020 17:51:41 -0700 (PDT) Received: by us.padl.com with ESMTP id 0360p3bV025599; Mon, 6 Apr 2020 00:51:08 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 0360p3bV025599 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586134269; bh=6Vg6RLJcRoJXCd2jswuz2nGx6F37ZGzTsAXplDOCy1I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=wqU70IlY9Fjrsh7dXS6OeHHNIQcwQSy8MoGeJxqFgX2ya73uxGARlGDZ7Ur37sxzs L/p25t1yvIX9/YFSwF2+v1CVjUCIMpK7na7fKB+rc83W+0pX8+PwGATb7ZUNLVNclE MP3oP6Cjw79Ct1NbLdTcUOys6EA9ES2C6B8/EmHfIw8ZYQcDUmiKbt0mXw6kxwStQ5 1DJjapB4qrasO29JBrzJuc85KHtUzJdMHjZ7RmRtwb/VL6nVth0gcrHE64qlNkkB6T JyrBT/Y/OWLzaMXHj986fD1wBw3oWAUMUdAvShuFdEUMtAGo7nAhjsZLu6xXTdynM+ hiMNoPbZMq7Nw== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Luke Howard In-Reply-To: <20200405234929.GD18021@localhost> Date: Mon, 6 Apr 2020 10:51:01 +1000 Cc: "kitten@ietf.org" , Jeffrey Altman , Greg Hudson Content-Transfer-Encoding: quoted-printable Message-Id: <38ED72E1-3361-4242-9923-C3BE61698BE0@padl.com> References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> To: Nicolas Williams X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 00:51:44 -0000 Hi Nico, Thanks for your feedback as usual! > | The means of discovering GSS-API peers and their supported = mechanisms > | is out of this specification's scope. However, when the Simple and > | Protected Negotiation mechanism (SPNEGO) defined in [RFC4178] is > | used, the mechanism MUST be negotiated under [I-D.zhu-negoex]. = [...] >=20 > Hmm, well, can this MUST be relaxed to apply only when the initiator > supports [I-D.zhu-negoex]? Alternatively, maybe remove it. After > all, [I-D.zhu-negoex] imposes the requirement, not this document. If we wish to support interoperability with SSPI for both initiators and = acceptors, then to me it makes sense to require NegoEx. We could make = the mechanism negotiable under both SPNEGO directly and NegoEx but it = seems that we should avoid that if possible in the interests of = simplicity. Although SAnon could be deployed as a pluggable mechanism, = in reality I imagine it will arrive after shipping NegoEx (both MIT and = Heimdal have it). > | The selection of SAnon is subject to local policy. [...] >=20 > Did you mean, its selection via SPNEGO/NegoEx? But apps can use > GSS_Set_neg_mechs(), so I'd say that selection is not a matter of > local policy, except in any case where multiple mechanisms are > supported by both the initiator and the acceptor, and no preference > can be gleaned from the applications (is that possible?) We could say may be subject to application and/or local policy but = simpler to remove the sentence, which I have done. > In any case, I think you might want to say that when using the > default credential and a non-anonymous target name, and when > GSS_Set_neg_mechs() was not used (or was used and did not list > SAnon), then SAnon MUST NOT be negotiated. Suggest the following text (the third case is new): On the first call to GSS_Init_sec_context(), the mechanism checks for one of the following: The caller set anon_req_flag (GSS_C_ANON_FLAG); or The claimant_cred_handle identity is the well known anonymous name; or The claimant_cred_handle is the default credential and targ_name is the well known anonymous name If neither of the above are the case, the call MUST fail with GSS_S_UNAVAILABLE. I don=E2=80=99t think it=E2=80=99s necessary to point out that = GSS_Set_neg_mechs() can be used to exclude SAnon, because this is not = specific to this mechanism. Using GSS_Set_neg_mechs() to force SAnon when it would otherwise not be = used would be an abstraction violation (at lease implementation-wise). = Applications can use GSS_C_ANON_FLAG. > | [...]. If anonymity is > | not desired, mechanisms that provide authentication SHOULD be > | preferred. [...] >=20 > Hmm, I'd say that if "anonymity is not desired" then SAnon MUST NOT > be used. Fixed. > Also, phrasing it as "mechanisms that .... SHOULD be preferred" > sounds like an update to SPNEGO/NegoEx. Indeed, the need to > understand that SAnon cannot authenticate the acceptor to the > initiator imposes on SPNEGO/NegoEx, so an update might be > unavoidable. I suppose I was looking for some text to reflect that in our = implementation, SAnon is at the very end of the list of preferred = mechanisms (even after runtime loaded ones). > - Section 4 >=20 > It's important to state that the name as observed by the peer is > always GSS_C_NT_ANONYMOUS. I=E2=80=99ll put this text in the GSS_C_NT_ANONYMOUS description (not = sure if it needs its own section?) and also move the text directly under = Section 4 re: names as a mechanism selection hint, to a new section. > - Section 4.1.4 >=20 > The name string displayed should either be a constant OR, better = yet, > a base64-encoded hash of the peer's DH key! The latter especially > after context establishment. >=20 > - GSS_Display_name(GSS_Canonicalize_name( > mech=3DSAnon, > name=3DGSS_Import_name(GSS_C_NT_ANONYMOUS, = "whatever"))) > -> "whatever" >=20 > - GSS_Display_name(GSS_Inquire_context_peer_name(context)) > -> base64_encode(hash(dh_pubkey)) This makes sense for a mechanism that supports non-ephemeral keys but I = believe this is out of scope for SAnon. ;) Cheers, Luke= From nobody Sun Apr 5 17:57:53 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BA43A0A6A for ; Sun, 5 Apr 2020 17:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIduVYsDbhrV for ; Sun, 5 Apr 2020 17:57:48 -0700 (PDT) Received: from caracal.birch.relay.mailchannels.net (caracal.birch.relay.mailchannels.net [23.83.209.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8ED13A0A68 for ; Sun, 5 Apr 2020 17:57:47 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id AAD081E0E18; Mon, 6 Apr 2020 00:57:46 +0000 (UTC) Received: from pdx1-sub0-mail-a32.g.dreamhost.com (100-96-12-20.trex.outbound.svc.cluster.local [100.96.12.20]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E1D0A1E0835; Mon, 6 Apr 2020 00:57:45 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a32.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 06 Apr 2020 00:57:46 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Whispering-Hook: 26bc4e4f56045050_1586134666354_4111020548 X-MC-Loop-Signature: 1586134666353:204886046 X-MC-Ingress-Time: 1586134666353 Received: from pdx1-sub0-mail-a32.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a32.g.dreamhost.com (Postfix) with ESMTP id 823EE7FF10; Sun, 5 Apr 2020 17:57:45 -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=3LzWLKRORAeLkC gi2KicTzmjcxw=; b=sfCZ+ZUYRQV0tICYCZYyDoyTT1gcuXPcBTsC8rNfiLEiFb I24xWTh5SkgA4HZoQDhlSpuOLqztH2Lm83sSEXWq64f2vqdgzv50PuKQhemArfS/ Ui9dOlyVH1yj0EvbNzjldKmsZePRBeemVm/DzvLf2PQZvijIiO28RWlDlz4pA= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 00D467FF0E; Sun, 5 Apr 2020 17:57:42 -0700 (PDT) Date: Sun, 5 Apr 2020 19:57:40 -0500 X-DH-BACKEND: pdx1-sub0-mail-a32 From: Nico Williams To: Simon Josefsson Cc: Luke Howard , "kitten@ietf.org" Message-ID: <20200406005739.GF18021@localhost> References: <158562149038.11496.7234948048087895644@ietfa.amsl.com> <03F73286-C983-44C6-B10D-7E826AE2C609@padl.com> <87pncnbisr.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pncnbisr.fsf@latte.josefsson.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedruddvgdegudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [kitten] Fwd: New Version Notification for draft-howard-gss-sanon-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 00:57:51 -0000 On Sat, Apr 04, 2020 at 01:18:44PM +0200, Simon Josefsson wrote: > Luke Howard writes: > > Below is a specification for a simple anonymous mechanism based on > > curve25519 that does not authenticate either initiator or acceptor. > > Interesting! When would this be useful in SASL? GS2 requires that the > mechanism supports mutual authentication, so while I definitely see > value in having this as a GSS-API mechanism I don't understand when it > would provide value for a SASL application, and how it would actually > work in GS2. Add an option to use previously-agreed peer PKs and you have authentication. Add a way to lookup a peer's PK by name and you have a modern version of mech_dh. For those who don't know or don't remember, mech_dh is a GSS version of AUTH_DH, and both are premised on using long-term DH keys for key agreement and authentication, with a directory mapping "netnames" (principal names) to public keys. The directory had a files backend (/etc/publickey) as well as a NIS+ and LDAP backends -- today we'd use DNSSEC as well, naturally. (For human principals, their mech_dh private keys could be stored in the directory encrypted in their passwords, which then allows the equivalent of "kinit" -- this, however, is a very bad idea, as it allows anyone to mount off-line dictionary attacks. Instead, a login protocol should be required to obtain user private keys.) Mech_dh even has a half round-trip variant, naturally. It's remarkably similar to Kerberos while having nothing like a KDC/AS/TGS -- just a passive directory instead. This was the original way that DH was intended to be used by its inventors! SAnon can trivially be extended to be the new mech_dh: just allow the use of raw public keys as desired_names for credential acquisition and for acceptor target_names. The initial context token has to more than double in length: so the desired acceptor can be identified and a nonce be conveyed. A nonce is important in this construction, as otherwise we'd have key reuse, though in the Kerberos cryptosystem, that's not so important given that we use confounders, but still, it would be essential for GSS_Pseudo_random(). Nico -- From nobody Sun Apr 5 18:10:55 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576BA3A0ABB for ; Sun, 5 Apr 2020 18:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtY47Dd6sKSV for ; Sun, 5 Apr 2020 18:10:35 -0700 (PDT) Received: from cadetblue.birch.relay.mailchannels.net (cadetblue.birch.relay.mailchannels.net [23.83.209.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEACC3A0A74 for ; Sun, 5 Apr 2020 18:10:34 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 56FAC21100; Mon, 6 Apr 2020 01:10:34 +0000 (UTC) Received: from pdx1-sub0-mail-a32.g.dreamhost.com (100-96-23-11.trex.outbound.svc.cluster.local [100.96.23.11]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D4D2620C72; Mon, 6 Apr 2020 01:10:33 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a32.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 06 Apr 2020 01:10:34 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Industry-Lonely: 590ebf0006de6f63_1586135434156_3278481640 X-MC-Loop-Signature: 1586135434156:425629812 X-MC-Ingress-Time: 1586135434156 Received: from pdx1-sub0-mail-a32.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a32.g.dreamhost.com (Postfix) with ESMTP id 915087FF11; Sun, 5 Apr 2020 18:10:33 -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=gJVPmCOGKXOEwtgIA+oEnLxHIqs=; b=VahNqkh9UWI D9XpWeMabEPiWz9dHrTBh1yFyfzcVUTqt/u5avBAr2jT21yN8fDVOAiojM2eF55x CLv28jFWhp9Oy8B8BZ51MyAsA3X8DGRDxp9ww2rKRk+XDm5x2nu/2KxCgVkxxLT/ 4JJU2N0hLHgz7+Ecc34NS/Nz4yrUdehc= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 838457FF02; Sun, 5 Apr 2020 18:10:30 -0700 (PDT) Date: Sun, 5 Apr 2020 20:10:27 -0500 X-DH-BACKEND: pdx1-sub0-mail-a32 From: Nico Williams To: Luke Howard Cc: "kitten@ietf.org" , Jeffrey Altman , Greg Hudson Message-ID: <20200406011026.GG18021@localhost> References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> <38ED72E1-3361-4242-9923-C3BE61698BE0@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <38ED72E1-3361-4242-9923-C3BE61698BE0@padl.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedruddvgdeggecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 01:10:47 -0000 On Mon, Apr 06, 2020 at 10:51:01AM +1000, Luke Howard wrote: > > | The means of discovering GSS-API peers and their supported mechani= sms > > | is out of this specification's scope. However, when the Simple an= d > > | Protected Negotiation mechanism (SPNEGO) defined in [RFC4178] is > > | used, the mechanism MUST be negotiated under [I-D.zhu-negoex]. [.= ..] > >=20 > > Hmm, well, can this MUST be relaxed to apply only when the initiato= r > > supports [I-D.zhu-negoex]? Alternatively, maybe remove it. After > > all, [I-D.zhu-negoex] imposes the requirement, not this document. >=20 > If we wish to support interoperability with SSPI for both initiators > and acceptors, then to me it makes sense to require NegoEx. We could > make the mechanism negotiable under both SPNEGO directly and NegoEx > but it seems that we should avoid that if possible in the interests of > simplicity. Although SAnon could be deployed as a pluggable mechanism, > in reality I imagine it will arrive after shipping NegoEx (both MIT > and Heimdal have it). All I'm saying is that where a GSS implementation doesn't support NegoEx there should not be a requirement that NegoEx be used. Relaxing the requirement this way will make it possible for SAnon to progress without having to also progress NegoEx. > > | The selection of SAnon is subject to local policy. [...] > >=20 > > Did you mean, its selection via SPNEGO/NegoEx? But apps can use > > GSS_Set_neg_mechs(), so I'd say that selection is not a matter of > > local policy, except in any case where multiple mechanisms are > > supported by both the initiator and the acceptor, and no preference > > can be gleaned from the applications (is that possible?) >=20 > We could say may be subject to application and/or local policy but > simpler to remove the sentence, which I have done. +1 > > In any case, I think you might want to say that when using the > > default credential and a non-anonymous target name, and when > > GSS_Set_neg_mechs() was not used (or was used and did not list > > SAnon), then SAnon MUST NOT be negotiated. >=20 > Suggest the following text (the third case is new): >=20 > On the first call to GSS_Init_sec_context(), the mechanism checks > for one of the following: >=20 > The caller set anon_req_flag (GSS_C_ANON_FLAG); or >=20 > The claimant_cred_handle identity is the well known anonymous > name; or >=20 > The claimant_cred_handle is the default credential and targ_name > is the well known anonymous name I'd change the last item to: The claimant_cred_handle is the default credential and targ_name is an anonymous name. There's no need to say "well known anonymous name". > If neither of the above are the case, the call MUST fail with > GSS_S_UNAVAILABLE. That's three conditions, s/neither/none/ :) > I don=E2=80=99t think it=E2=80=99s necessary to point out that GSS_Set_= neg_mechs() can > be used to exclude SAnon, because this is not specific to this > mechanism. Well, if GSS_Set_neg_mechs() is used to exclude SAnon then SAnon's init_sec_context() can't be invoked, so, indeed, there's no need to point that out. > Using GSS_Set_neg_mechs() to force SAnon when it would otherwise not > be used would be an abstraction violation (at lease > implementation-wise). Applications can use GSS_C_ANON_FLAG. Fair point. > > Also, phrasing it as "mechanisms that .... SHOULD be preferred" > > sounds like an update to SPNEGO/NegoEx. Indeed, the need to > > understand that SAnon cannot authenticate the acceptor to the > > initiator imposes on SPNEGO/NegoEx, so an update might be > > unavoidable. (Actually, the mech attrs mean that SPNEGO/NegoEx can know that SAnon doesn't authenticate the target.) > I suppose I was looking for some text to reflect that in our > implementation, SAnon is at the very end of the list of preferred > mechanisms (even after runtime loaded ones). Sure, so make that clear and downcase that SHOULD? > > - Section 4 > >=20 > > It's important to state that the name as observed by the peer is > > always GSS_C_NT_ANONYMOUS. >=20 > I=E2=80=99ll put this text in the GSS_C_NT_ANONYMOUS description (not s= ure if > it needs its own section?) and also move the text directly under > Section 4 re: names as a mechanism selection hint, to a new section. Sure. > > - Section 4.1.4 > >=20 > > The name string displayed should either be a constant OR, better ye= t, > > a base64-encoded hash of the peer's DH key! The latter especially > > after context establishment. > >=20 > > - GSS_Display_name(GSS_Canonicalize_name( > > mech=3DSAnon, > > name=3DGSS_Import_name(GSS_C_NT_ANONYMOUS, "w= hatever"))) > > -> "whatever" > >=20 > > - GSS_Display_name(GSS_Inquire_context_peer_name(context)) > > -> base64_encode(hash(dh_pubkey)) >=20 > This makes sense for a mechanism that supports non-ephemeral keys but > I believe this is out of scope for SAnon. ;) I've a feeling that even for SAnon these could be useful. Nico --=20 From nobody Sun Apr 5 18:25:15 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357173A0AB3 for ; Sun, 5 Apr 2020 18:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_D1tZzyX93N for ; Sun, 5 Apr 2020 18:25:12 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9123A0AB0 for ; Sun, 5 Apr 2020 18:25:11 -0700 (PDT) Received: by us.padl.com with ESMTP id 0361OWdP027781; Mon, 6 Apr 2020 01:24:36 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 0361OWdP027781 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586136278; bh=bBIVwVA86l4EqgDBg+/PPafsybKaIgfGULlDr4HnBMw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=yDNKEx6zbG0lvGveO2WBUQSCwjgxcfk1KvYtxbvb+mO/H8nI7ybMdCKBlH9o4/Pjo Kw/zi+Rg3TKNVdiSN6YnclO1+2wyWbAKbfkkE7xxFALk90SX417IOE+9FeNIFOd+y9 fuHJ1QW9mqZo76BhMf8YXqZcBzeQsz5eG1gu4g55TzhXC4/4qbbbWBdi6GyLGgL+e/ Nwif1/2J89HZeDxTclqFmxmvEMQjVgKSweq2NEdwH0H3iyqInpgOEq0a456uplXiJh QOYVXq1XBBjMop5galor3l7hJIqaHzZwCSFvsYbVl2Va8B21oygZ7gXfzfIIwEGboI hC7k0maJd8PAA== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Luke Howard In-Reply-To: <20200406004444.GE18021@localhost> Date: Mon, 6 Apr 2020 11:24:31 +1000 Cc: "kitten@ietf.org" , Jeffrey Altman , Greg Hudson Content-Transfer-Encoding: quoted-printable Message-Id: References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> <20200406004444.GE18021@localhost> To: Nicolas Williams X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 01:25:14 -0000 Hi Nico, > Even better: base64(dh_pubkey). >=20 > And even better too if that can be used as a target name. >=20 > Then we'd have the building blocks of a modern mech_dh. Agreed. I would like to implement mech_ecdh. :) But I would also like to = avoid scope creep for SAnon due to time and funding constraints. > - Section 6.1.2 >=20 > The acceptor should also send a MIC along with the key, thus proving > it has possession of the shared secret. This is important, = otherwise > reply tokens could be replayed, and though it wouldn't be much of an > attack, it's worth doing. Happy to add this, but is it much of an attack? Both parties are = anonymous, so (as we discovered with GS2) this mechanism is completely = superfluous unless you intend to use a message protection service (or = PRF), which will fail in a replay attack. Having said that: is there value in the putative MIC being of the public = keys (as opposed to a constant) given the public keys are already input = to the KDF? > - Section 6 >=20 > There should be a requirement that new DH keys be generated every > time, no? Especially on the initiator side, and especially if you > don't add the use of a MIC in the response token (see previous > comment). I will clarify the text to say that it must be a fresh key pair. > - If you allow a target name to be imported as an anonymous name whose > value is the base64 encoding of a raw public key, then the initial > context token should send two public keys, and the response token > should be just a MIC. >=20 > I->A: {PK_i, PK_a} > A->I: MIC(SK, {PK_i, PK_a}) || >=20 > (ahh, you'd have to define an error message, but it could just > be a 1-byte code) >=20 > Note that to reuse keys really does require nonces. So those would > have to be added: >=20 > I->A: {PK_i, PK_a, nonce} > A->I: MIC(SK, {PK_i, PK_a}) || >=20 > You could even have a half round-trip variant where the initiator > sends {PK_i, PK_a, nonce, MIC} and the acceptor sends nothing. How does the initiator learn of the acceptor=E2=80=99s public key? It = seems to me this is useful for mech_ecdh but not SAnon? > - Section 7 >=20 > | context the concatenation of the initiator and acceptor = public > | keys, along with the channel binding application data > | (if present) >=20 > Add "in that order=E2=80=9D? Fixed. > - Section 7 >=20 > | The session key K1 is used as the base key for the generation of = per- > | message tokens and the GSS-API PRF. The encryption type of K1 is > | aes128-cts-hmac-sha256-128 as defined in [RFC8009]. >=20 > There should be a reference here to RFC4121. Also, RFC4121 doesn't > mention a K1. I suspect you need to state how to derive a key of = the > enctype (aes128-cts-hmac-sha256-128) that would be equivalent to the > AcceptorSubkey. You might want to mention that four keys are to be > derived from that per RFC4121 section 2, plus the = GSS_Pseudo_random() > key (GSS_C_PRF_KEY_FULL) [RFC8009]. How about: This session key is equivalent to the acceptor-asserted subkey defined in [RFC4121] Section 2 and is used as the base key for generating keys for per-message tokens and the GSS-API PRF. The session key encryption type is aes128-cts-hmac-sha256-128 as defined in [RFC8009]. The [RFC3961] algorithm protocol parameters are as given in [RFC8009] Section 5. I=E2=80=99ll also add a note in 6.2 that AcceptorSubkey MUST be set. > - Test vectors? I will add. > - Section 10 >=20 > This section should repeat something about the importance of SAnon > not being negotiated when it's not appropriate. =E2=80=9CIt MUST not be selected if either party requires identification = of its peer.=E2=80=9D =E2=80=93 is that OK? I would prefer not to use = the word negotiated, as SAnon can be explicitly selected outside of = SPNEGO/NegoEx. Cheers, Luke= From nobody Sun Apr 5 18:28:56 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E2A3A0A90 for ; Sun, 5 Apr 2020 18:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgEraaQG0M33 for ; Sun, 5 Apr 2020 18:28:52 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D303A0A8E for ; Sun, 5 Apr 2020 18:28:52 -0700 (PDT) Received: by us.padl.com with ESMTP id 0361SDEa028020; Mon, 6 Apr 2020 01:28:17 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 0361SDEa028020 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586136498; bh=8hOQoAiQb7griftlkDTWVBiNddJa5DTFs8qMU4pXfEI=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=dg7AmlWhgeuk7W39QVHlxa81ZtRGaLvMPBQ6uCB2U67CBmJDMglwSkUaefPczESIR oQnQb/z4k2Uc/iJ+oFw8Vli7dex6kuueHrQw4zwfGW8OkkU8QSqO1poRjbZMc2neTZ AkfwyEWfJurebXzBIdLgzRe7266OdUc5OsEqQYABPprpNJ/spqZK9JSOPRl2dUWtWd 7y5vS9Ivw9qrEt3q4aG2tMMQEum0EmQ6kDQrJ5JWJOnVLLoKGjEXbO+omv0WPJIt6c nF4YHNqEEge+JoBsNXQl6Fz94/8WkC4c5QrhV2nnyfDZWM1TX+rAodnxLCfPlCynly VTlzTz85QBuxg== From: Luke Howard Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C3A961BD-4A28-4DA6-8ED5-22A3007DF88F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 6 Apr 2020 11:28:12 +1000 In-Reply-To: <20200406011026.GG18021@localhost> Cc: "kitten@ietf.org" , Jeffrey Altman , Greg Hudson To: Nicolas Williams References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> <38ED72E1-3361-4242-9923-C3BE61698BE0@padl.com> <20200406011026.GG18021@localhost> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 01:28:55 -0000 --Apple-Mail=_C3A961BD-4A28-4DA6-8ED5-22A3007DF88F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > All I'm saying is that where a GSS implementation doesn't support = NegoEx > there should not be a requirement that NegoEx be used. Relaxing the > requirement this way will make it possible for SAnon to progress = without > having to also progress NegoEx. We can do this but, then we have an interoperability problem (unless we = say it=E2=80=99s always negotiable directly under SPNEGO as well as = NegoEx if available?). > I'd change the last item to: >=20 > The claimant_cred_handle is the default credential and targ_name is > an anonymous name. >=20 > There's no need to say "well known anonymous name=E2=80=9D. Fixed. >> If neither of the above are the case, the call MUST fail with >> GSS_S_UNAVAILABLE. >=20 > That's three conditions, s/neither/none/ :) Hah, got me. Fixed. =E2=80=94 Luke= --Apple-Mail=_C3A961BD-4A28-4DA6-8ED5-22A3007DF88F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
All I'm saying is that where a GSS implementation doesn't = support NegoEx
there should not be a requirement that = NegoEx be used.  Relaxing the
requirement this way = will make it possible for SAnon to progress without
having = to also progress NegoEx.

We can do this but, then we have an = interoperability problem (unless we say it=E2=80=99s always negotiable = directly under SPNEGO as well as NegoEx if = available?).

I'd change the last item = to:

  The claimant_cred_handle = is the default credential and targ_name is
  an = anonymous name.

There's no need to say = "well known anonymous name=E2=80=9D.

Fixed.

  If neither of the above are the = case, the call MUST fail with
=   GSS_S_UNAVAILABLE.

That's three conditions, s/neither/none/ :)

Hah, got = me. Fixed.

=E2=80=94 = Luke
= --Apple-Mail=_C3A961BD-4A28-4DA6-8ED5-22A3007DF88F-- From nobody Sun Apr 5 20:53:43 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687473A0D89 for ; Sun, 5 Apr 2020 20:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBHwc1wLzb-h for ; Sun, 5 Apr 2020 20:53:34 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2683A0D88 for ; Sun, 5 Apr 2020 20:53:33 -0700 (PDT) Received: by us.padl.com with ESMTP id 0363r8aW005160; Mon, 6 Apr 2020 03:53:12 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 0363r8aW005160 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586145194; bh=qTMT3E1JFKr1wm9NBXLpxAoifRhZrO+Qd0e9y12nVKM=; h=From:Subject:Date:References:Cc:To:From; b=tmt6rQsyp787Uu83JGN00W5j+5duOoCfOx7L+ZSlR2f0MN3GYFk+dB0jWHGMXxUon Fd4xQ23nhek+POqlECAEcSjRGtIWyj0Q7NZCInMNM1apWZ+B2kU3RAazOWu+esj3G0 he+LkdbcUgKrQSc1goMhh8SjAfAAdDW2w7Pj4hKUfgYhAqYSo3xsLrf1gzag5i9WyJ 439iqyBZMkqd3H5bw/GDSH3ZcnMj1dqjt8CU8+v5y3VuyprEO+l58Yzwls0Lm+FD/Q gRHmtOi/R+bnGDU3qQwYx014x3LD1VgTmR9K44eguNxVEyIOEV+K4JSW3xOXYjTV45 WSvmYA2tb86LQ== From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_0AFDBD78-045C-464F-85C0-B099F4D58109" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 6 Apr 2020 13:53:07 +1000 References: <158614488624.15048.6526756399736405169@ietfa.amsl.com> To: "kitten@ietf.org" Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [kitten] Fwd: New Version Notification for draft-howard-gss-sanon-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 03:53:40 -0000 --Apple-Mail=_0AFDBD78-045C-464F-85C0-B099F4D58109 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This addresses Nico=E2=80=99s review comments, except for those that = belong in an authenticated ECDH mechanism. I found one mistake after = submitting (GSS_VerifyMIC() usage) which I will correct in the next = version. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-howard-gss-sanon-02.txt > Date: 6 April 2020 at 1:48:06 pm AEST > To: "Luke Howard" >=20 >=20 > A new version of I-D, draft-howard-gss-sanon-02.txt > has been successfully submitted by Luke Howard and posted to the > IETF repository. >=20 > Name: draft-howard-gss-sanon > Revision: 02 > Title: A Simple Anonymous GSS-API Mechanism > Document date: 2020-04-06 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-02.txt > Status: = https://datatracker.ietf.org/doc/draft-howard-gss-sanon/ > Htmlized: https://tools.ietf.org/html/draft-howard-gss-sanon-02 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-02 >=20 > Abstract: > This document defines protocols, procedures and conventions for a > Generic Security Service Application Program Interface (GSS-API) > security mechanism that provides key agreement without = authentication > of either party. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_0AFDBD78-045C-464F-85C0-B099F4D58109 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = addresses Nico=E2=80=99s review comments, except for those that belong = in an authenticated ECDH mechanism. I found one mistake after submitting = (GSS_VerifyMIC() usage) which I will correct in the next version.

Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-howard-gss-sanon-02.txt
Date: = 6 April 2020 at 1:48:06 pm = AEST
To: = "Luke Howard" <lukeh@padl.com>

A new version of I-D, draft-howard-gss-sanon-02.txt
has been successfully submitted by Luke Howard and posted to = the
IETF repository.

Name: = draft-howard-gss-sanon
Revision: 02
Title:= = A Simple Anonymous GSS-API Mechanism
Document = date: = 2020-04-06
Group: Individual Submission
Pages:= = 11
URL: =            https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-02.= txt
Status: =         https://datatracker.ietf.org/doc/draft-howard-gss-sanon/Htmlized:       https://tools.ietf.org/html/draft-howard-gss-sanon-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-02

Abstract:
=   This document defines protocols, procedures and conventions = for a
  Generic Security Service Application = Program Interface (GSS-API)
  security = mechanism that provides key agreement without authentication
  of either party.




Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



= --Apple-Mail=_0AFDBD78-045C-464F-85C0-B099F4D58109-- From nobody Mon Apr 6 08:29:17 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20DA3A0A31 for ; Mon, 6 Apr 2020 08:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he1bF7aJ48Xc for ; Mon, 6 Apr 2020 08:28:56 -0700 (PDT) Received: from blue.elm.relay.mailchannels.net (blue.elm.relay.mailchannels.net [23.83.212.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30FD3A0A5F for ; Mon, 6 Apr 2020 08:28:37 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 9A8E3481C0D; Mon, 6 Apr 2020 15:28:36 +0000 (UTC) Received: from pdx1-sub0-mail-a94.g.dreamhost.com (100-96-12-20.trex.outbound.svc.cluster.local [100.96.12.20]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 31436481C09; Mon, 6 Apr 2020 15:28:36 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a94.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 06 Apr 2020 15:28:36 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Abaft-Reaction: 1092d91b7573cc3e_1586186916457_2123493787 X-MC-Loop-Signature: 1586186916457:4179838468 X-MC-Ingress-Time: 1586186916457 Received: from pdx1-sub0-mail-a94.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTP id D3CC0B1A06; Mon, 6 Apr 2020 08:28:34 -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=xsJp+v3ulyzR4u sVvETbwQ4mwyw=; b=OBHwIa3N35npR5oCYeaubTBLF5JqlZroOkErPfHEFE7KFR ollwsbSZTDprWakQrsqBoQ4Kjj6m1w9nR8KlaggRpKM9TWv7bmMOHRPT4FXiEnlc ctYFW+v89qRwEyBQlXeIWJKYJE763dmBoO6TOeCyYyzPr+ef6tGYd+VggnxxQ= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTPSA id 22B63B1A02; Mon, 6 Apr 2020 08:28:32 -0700 (PDT) Date: Mon, 6 Apr 2020 10:28:30 -0500 X-DH-BACKEND: pdx1-sub0-mail-a94 From: Nico Williams To: Luke Howard Cc: "kitten@ietf.org" , Jeffrey Altman Message-ID: <20200406152828.GK18021@localhost> References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> <38ED72E1-3361-4242-9923-C3BE61698BE0@padl.com> <20200406011026.GG18021@localhost> <4E7EFAC6-3E51-4FC7-B0F1-2F886BBC1F56@lukehoward.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7EFAC6-3E51-4FC7-B0F1-2F886BBC1F56@lukehoward.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudefgdekudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 15:28:58 -0000 On Mon, Apr 06, 2020 at 11:35:37AM +1000, Luke Howard wrote: > The progressing requirement is not an issue if SAnon is experimental > track, though? It's not, but there's no reason for SAnon not to make it to the Standards Track either... The simplest thing to do is to say that the requirement about NegoEx is only for initiators that implement NegoEx. Heck, you might not even need to say anything: NegoEx itself already imposes that requirement, does it not? If so, why restate it here? Nico -- From nobody Mon Apr 6 08:43:56 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A913A0AEC for ; Mon, 6 Apr 2020 08:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BXX3c58S0GA for ; Mon, 6 Apr 2020 08:43:34 -0700 (PDT) Received: from blue.elm.relay.mailchannels.net (blue.elm.relay.mailchannels.net [23.83.212.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1053A0B1F for ; Mon, 6 Apr 2020 08:43:34 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 74F033405F5; Mon, 6 Apr 2020 15:43:33 +0000 (UTC) Received: from pdx1-sub0-mail-a94.g.dreamhost.com (100-96-14-17.trex.outbound.svc.cluster.local [100.96.14.17]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E68B4341107; Mon, 6 Apr 2020 15:43:32 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a94.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 06 Apr 2020 15:43:33 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-White-Shade: 1bcbcb99221152f3_1586187813245_3301995541 X-MC-Loop-Signature: 1586187813245:1089538907 X-MC-Ingress-Time: 1586187813245 Received: from pdx1-sub0-mail-a94.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTP id 9E55BB1A06; Mon, 6 Apr 2020 08:43:32 -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=FX3+63wCrIJUxDMEc67tPzgwgng=; b=BislKzSVvFv pOAim0RYSJpeEIW+lAo4AqGuTESqhTVVYdtXYBrDv8rppg0GxDRP8N1ms9jFidj4 ursrdw9QN1CCQEzAXNzueWF00MDys4wMVingpmUoAeKWY4gE6Z1qv/g3xEBg8JTk ypg2Lq0bD2vmvFzpRbQO7qfYggv+GO+0= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTPSA id A27FEB19F5; Mon, 6 Apr 2020 08:43:30 -0700 (PDT) Date: Mon, 6 Apr 2020 10:43:27 -0500 X-DH-BACKEND: pdx1-sub0-mail-a94 From: Nico Williams To: Luke Howard Cc: "kitten@ietf.org" , Jeffrey Altman , Greg Hudson Message-ID: <20200406154326.GL18021@localhost> References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> <20200406004444.GE18021@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudefgdekhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 15:43:36 -0000 On Mon, Apr 06, 2020 at 11:24:31AM +1000, Luke Howard wrote: > Agreed. I would like to implement mech_ecdh. :) But I would also like > to avoid scope creep for SAnon due to time and funding constraints. Understood. SAnon will be a trivial base for a new mech_dh. > > - Section 6.1.2 > >=20 > > The acceptor should also send a MIC along with the key, thus provin= g > > it has possession of the shared secret. This is important, otherwi= se > > reply tokens could be replayed, and though it wouldn't be much of a= n > > attack, it's worth doing. >=20 > Happy to add this, but is it much of an attack? Both parties are > anonymous, so (as we discovered with GS2) this mechanism is completely > superfluous unless you intend to use a message protection service (or > PRF), which will fail in a replay attack. For pure GSS/SAnon apps it probably makes no difference, but it might for future stacks combining SAnon with other things. > Having said that: is there value in the putative MIC being of the > public keys (as opposed to a constant) given the public keys are > already input to the KDF? It can be a MIC over the empty string. > > - If you allow a target name to be imported as an anonymous name whos= e > > value is the base64 encoding of a raw public key, then the initial > > context token should send two public keys, and the response token > > should be just a MIC. > >=20 > > [...] >=20 > How does the initiator learn of the acceptor=E2=80=99s public key? It s= eems to > me this is useful for mech_ecdh but not SAnon? There's two options: the mech_dh method (add a directory) and leap-of-faith (learn the keys once, keep reusing them. You wanted to leave the mech_dh thing out of scope, so let's do that. In Sun's mech_dh there were pluggable name service switch modules for the "publickey" DB, with files, nisplus, and ldap shipping in Solaris. That was... a long time ago. Today we'd use DNS w/ DNSSEC (DANE). The leap-of-faith thing would work like this: the initiator uses well-known anon names to set up a security context with some acceptor, then inquires the resulting initiator and acceptor names, and later sets up new contexts using the same keys (which might not work if the private keys are gone). To make this work at all we'd need a bit on the wire for indicating that you want the keys to be less-ephemeral. Anyways, forget the leap-of-faith case for now too. > > - Section 7 > >=20 > > | The session key K1 is used as the base key for the generation of p= er- > > | message tokens and the GSS-API PRF. The encryption type of K1 is > > | aes128-cts-hmac-sha256-128 as defined in [RFC8009]. > >=20 > > There should be a reference here to RFC4121. Also, RFC4121 doesn't > > mention a K1. I suspect you need to state how to derive a key of t= he > > enctype (aes128-cts-hmac-sha256-128) that would be equivalent to th= e > > AcceptorSubkey. You might want to mention that four keys are to be > > derived from that per RFC4121 section 2, plus the GSS_Pseudo_random= () > > key (GSS_C_PRF_KEY_FULL) [RFC8009]. >=20 > How about: >=20 > This session key is equivalent to the acceptor-asserted subkey > defined in [RFC4121] Section 2 and is used as the base key for > generating keys for per-message tokens and the GSS-API PRF. >=20 > The session key encryption type is aes128-cts-hmac-sha256-128 as > defined in [RFC8009]. The [RFC3961] algorithm protocol parameters > are as given in [RFC8009] Section 5. >=20 > I=E2=80=99ll also add a note in 6.2 that AcceptorSubkey MUST be set. Works for me! > > - Test vectors? >=20 > I will add. >=20 > > - Section 10 > >=20 > > This section should repeat something about the importance of SAnon > > not being negotiated when it's not appropriate. >=20 > =E2=80=9CIt MUST not be selected if either party requires identificatio= n of > its peer.=E2=80=9D =E2=80=93 is that OK? I would prefer not to use the = word > negotiated, as SAnon can be explicitly selected outside of > SPNEGO/NegoEx. Works for me! Nico --=20 From nobody Mon Apr 6 12:52:29 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E473A0DE7 for ; Mon, 6 Apr 2020 12:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfRQ77tB8L69 for ; Mon, 6 Apr 2020 12:52:26 -0700 (PDT) Received: from chocolate.birch.relay.mailchannels.net (chocolate.birch.relay.mailchannels.net [23.83.209.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11EAE3A0DE4 for ; Mon, 6 Apr 2020 12:52:21 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 547FF20CA0; Mon, 6 Apr 2020 19:52:21 +0000 (UTC) Received: from pdx1-sub0-mail-a81.g.dreamhost.com (100-96-21-20.trex.outbound.svc.cluster.local [100.96.21.20]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A53BA206F1; Mon, 6 Apr 2020 19:52:20 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a81.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 06 Apr 2020 19:52:21 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Macabre-Daffy: 6e28f7e5656eaa16_1586202740964_2045485487 X-MC-Loop-Signature: 1586202740964:1528216827 X-MC-Ingress-Time: 1586202740963 Received: from pdx1-sub0-mail-a81.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a81.g.dreamhost.com (Postfix) with ESMTP id 59E867E5E7; Mon, 6 Apr 2020 12:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=cVEcz1+eb04XMn 6AVZq/LGic4gI=; b=RsJuEeZUTTSKdRwN/YmvVg5MHdhB94Jbx8rRBIaq2dhzO0 YHHlEPa6uQpjkvSI184NbtDJ+ZKK5UtUBXFxiMk1X7zj+05T1aaKdeddsbPedOAp 8vMYcj/d5W/fqOTUuAD8iFO8iDOvOPeg6YrRxZgvJzqgeUoB+6ySScV5Smgzk= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a81.g.dreamhost.com (Postfix) with ESMTPSA id 8CE767F0C4; Mon, 6 Apr 2020 12:52:18 -0700 (PDT) Date: Mon, 6 Apr 2020 14:52:16 -0500 X-DH-BACKEND: pdx1-sub0-mail-a81 From: Nico Williams To: Luke Howard Cc: "kitten@ietf.org" , Jeffrey Altman , Greg Hudson Message-ID: <20200406195214.GP18021@localhost> References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> <20200406004444.GE18021@localhost> <20200406154326.GL18021@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200406154326.GL18021@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudefgddufeehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 19:52:28 -0000 On Mon, Apr 06, 2020 at 10:43:27AM -0500, Nico Williams wrote: > On Mon, Apr 06, 2020 at 11:24:31AM +1000, Luke Howard wrote: > > > - Section 6.1.2 > > > > > > The acceptor should also send a MIC along with the key, thus proving > > > it has possession of the shared secret. This is important, otherwise > > > reply tokens could be replayed, and though it wouldn't be much of an > > > attack, it's worth doing. > > > > Happy to add this, but is it much of an attack? Both parties are > > anonymous, so (as we discovered with GS2) this mechanism is completely > > superfluous unless you intend to use a message protection service (or > > PRF), which will fail in a replay attack. > > For pure GSS/SAnon apps it probably makes no difference, but it might > for future stacks combining SAnon with other things. Well, one nice thing about the MIC is that it allows the initiator to detect CB failure earlier. Heck, if the application protocol were to only have per-message tokens flowing from the initiator to the acceptor, then the initiator would never find out about CB failures. So we want the MIC. (Not that CB is terribly useful in a mechanism that provides no authentication, but let's ignore that for this purpose.) From nobody Mon Apr 6 16:00:03 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393793A0E7B for ; Mon, 6 Apr 2020 16:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpPr1-pe4v8z for ; Mon, 6 Apr 2020 15:59:59 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8388E3A0E70 for ; Mon, 6 Apr 2020 15:59:59 -0700 (PDT) Received: by us.padl.com with ESMTP id 036MxFjQ014881; Mon, 6 Apr 2020 22:59:19 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 036MxFjQ014881 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586213961; bh=vMfYtQGM3SyKcP+fA7934UlokXPjL3+6dft9/sNsBn4=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=ZhuCEcTo1irR2okEgBYrJApMZf8oOmWV+waSTPa2FbgE0SI1NVViEnlg+AG8Piznx V2X461E2x15tqlrtB8xhc9IMlO/lhlTyXT9ioLeL50wjoPTynJSMp5SPqJIq+Tw0k5 fZP7bk5q+JH2BGWX0gr3v+Yf78A7a5cT6GK2Kv0FlFNRv/8g3ORegbUE4n6WmcecLD PmLvcjVv/g8YXsuBP0/oeGropv+e81PEYaRZLIu7KGIjF8RUgQ8dwleoUvuESoaaFJ hyHXKPzidQJwMdb8bZwue0x5axUb/AiAFy1kcAHu0Jg9z/JER+0G/7ZXigIkTxgsEp edg0YBbODUaDQ== From: Luke Howard Message-Id: <47052E79-71C9-482E-AF42-D46C44F9AA47@padl.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4436CCBF-F18A-4585-ABFE-20DA6D463D43" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 7 Apr 2020 08:59:14 +1000 In-Reply-To: <20200406152828.GK18021@localhost> Cc: "kitten@ietf.org" , Jeffrey Altman To: Nicolas Williams References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> <38ED72E1-3361-4242-9923-C3BE61698BE0@padl.com> <20200406011026.GG18021@localhost> <4E7EFAC6-3E51-4FC7-B0F1-2F886BBC1F56@lukehoward.com> <20200406152828.GK18021@localhost> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 23:00:01 -0000 --Apple-Mail=_4436CCBF-F18A-4585-ABFE-20DA6D463D43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jeff suggests informational track. I=E2=80=99ve fixed the NegoEx thing anyway in the most recent draft. The NegoEx authors did not envisage a mechanism being negotiated under = both SPNEGO and NegoEx, so it doesn=E2=80=99t say anything about the = preference order of such a mechanism. (It was possible to build such a = mechanism up to Windows 8, but this was an accident that was then = corrected.) MIT and Heimdal support mechanisms being negotiable under both and = always preference negotiating it under NegoEx. Luke Howard web / facebook = / instagram = / spotify = > On 7 Apr 2020, at 1:28 am, Nico Williams = wrote: >=20 > On Mon, Apr 06, 2020 at 11:35:37AM +1000, Luke Howard wrote: >> The progressing requirement is not an issue if SAnon is experimental >> track, though? >=20 > It's not, but there's no reason for SAnon not to make it to the > Standards Track either... >=20 > The simplest thing to do is to say that the requirement about NegoEx = is > only for initiators that implement NegoEx. Heck, you might not even > need to say anything: NegoEx itself already imposes that requirement, > does it not? If so, why restate it here? >=20 > Nico > --=20 --Apple-Mail=_4436CCBF-F18A-4585-ABFE-20DA6D463D43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Jeff = suggests informational track.

I=E2=80=99ve fixed the NegoEx thing anyway in the most recent = draft.

The = NegoEx authors did not envisage a mechanism being negotiated under both = SPNEGO and NegoEx, so it doesn=E2=80=99t say anything about the = preference order of such a mechanism. (It was possible to build such a = mechanism up to Windows 8, but this was an accident that was then = corrected.)

MIT = and Heimdal support mechanisms being negotiable under both and always = preference negotiating it under NegoEx.

Luke = Howard
web / facebook / instagram / spotify

On 7 Apr 2020, at 1:28 am, Nico Williams <nico@cryptonector.com> wrote:

On = Mon, Apr 06, 2020 at 11:35:37AM +1000, Luke Howard wrote:
The progressing = requirement is not an issue if SAnon is experimental
track, = though?

It's not, but there's = no reason for SAnon not to make it to the
Standards Track = either...

The simplest thing to do is to = say that the requirement about NegoEx is
only for = initiators that implement NegoEx.  Heck, you might not even
need to say anything: NegoEx itself already imposes that = requirement,
does it not?  If so, why restate it = here?

Nico
--

= --Apple-Mail=_4436CCBF-F18A-4585-ABFE-20DA6D463D43-- From nobody Mon Apr 6 16:03:15 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F1A3A0E89 for ; Mon, 6 Apr 2020 16:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5sTJDy803HP for ; Mon, 6 Apr 2020 16:03:12 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D94D3A0E84 for ; Mon, 6 Apr 2020 16:03:12 -0700 (PDT) Received: by us.padl.com with ESMTP id 036N2WL5015128; Mon, 6 Apr 2020 23:02:37 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 036N2WL5015128 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586214158; bh=ElXPyBjSGj4Wx4yJUYziO61hQgyBRmqcl9Tz2MwtLUs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=uU8PBZE3id2WFq7MRzIxyuxZtuORAnMB857w1myx28LHYF+r+tDP3MgjZXVLuYJhV DV4pj1HwrRSodQzgHmlLxvoBIShc14EJfklnZX9OJzPjuRJrhlgLGuEBKqu5rTYSJC FUEBqzgalfJMoVBGx8S9emZGci4kGwqnV9NqbHnulT8j1CqbZV/NrkccHp94OCt7IT XaK155Wu9L+pkb8ZAVLpua4/I23pYoISoTKHPFzn+/BzCyDEjGly7yuf2pfIT8oEcv aK/QnD9qijYFVY6vdbYs45udJTFhdCYp9XTrwCqC3RviWcIqNisAwy8s5Wj40DS00O IPhmBfIn+zCpw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Luke Howard In-Reply-To: <20200406154326.GL18021@localhost> Date: Tue, 7 Apr 2020 09:02:32 +1000 Cc: "kitten@ietf.org" , Jeffrey Altman , Greg Hudson Content-Transfer-Encoding: quoted-printable Message-Id: References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> <20200406004444.GE18021@localhost> <20200406154326.GL18021@localhost> To: Nicolas Williams X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 23:03:14 -0000 >> Happy to add this, but is it much of an attack? Both parties are >> anonymous, so (as we discovered with GS2) this mechanism is = completely >> superfluous unless you intend to use a message protection service (or >> PRF), which will fail in a replay attack. >=20 > For pure GSS/SAnon apps it probably makes no difference, but it might > for future stacks combining SAnon with other things. Fixed in draft and implementation. It is (as we discussed off-list) a = MIC of the empty string. > There's two options: the mech_dh method (add a directory) and > leap-of-faith (learn the keys once, keep reusing them. >=20 > You wanted to leave the mech_dh thing out of scope, so let's do that. >=20 > In Sun's mech_dh there were pluggable name service switch modules for > the "publickey" DB, with files, nisplus, and ldap shipping in Solaris. > That was... a long time ago. Today we'd use DNS w/ DNSSEC (DANE). >=20 > The leap-of-faith thing would work like this: the initiator uses > well-known anon names to set up a security context with some acceptor, > then inquires the resulting initiator and acceptor names, and later = sets > up new contexts using the same keys (which might not work if the = private > keys are gone). To make this work at all we'd need a bit on the wire > for indicating that you want the keys to be less-ephemeral. Given mech_ecdh will be a new mechanism with a new OID (and GUID!), then = we can change the wire format to include a flags field. Thanks again for the input! Cheers, Luke= From nobody Mon Apr 6 19:00:40 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8EB3A0AA5 for ; Mon, 6 Apr 2020 19:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lnrx5J52hCHr for ; Mon, 6 Apr 2020 19:00:37 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F153A0AA4 for ; Mon, 6 Apr 2020 19:00:37 -0700 (PDT) Received: by us.padl.com with ESMTP id 0371xxqR026535; Tue, 7 Apr 2020 02:00:04 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 0371xxqR026535 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586224805; bh=XYD93Gq5Po7kAr+h60AtZIqtetjwE6E+yBEEq5o2/40=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=K1+yydgkdyy67s9dxDFOPWE3ek+8Wa9RF35N6KbUO1W+kwZMv1nds3rp/8drmQMzZ u0ZatHlrekw2R27bvkhp4G6LK39i74FZerPhAiprOIwSe34HL7RGps/xiI7vxPnro3 ms6/w9kUm3R3IQbbXfrkBoR/UkQ1913DE3bZqCGljKJbdSgXi/h69B2Uc1JaEojJH+ /DgTl3ejUHWuTNe4iytrTCXRKxQFzu1GxJrJ1beSUS2htZvPOSsU+HQYBe1j9rSizO wJNNmmzWaE3M/+l2xEOCoMuSBdEutKOKjaH6y5j6xjBJXTsxW7kQWvmmguAyjnw4hA vCVQ8BkbjpnCA== From: Luke Howard Message-Id: <472D27C4-7DFA-4BE5-8BE6-23D42C8E0E55@padl.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1ED7B8B4-2BD4-4C0C-8B6D-5DF6468BB2F5" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 7 Apr 2020 11:59:59 +1000 In-Reply-To: Cc: Nicolas Williams , "kitten@ietf.org" To: Jeffrey Altman References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> <38ED72E1-3361-4242-9923-C3BE61698BE0@padl.com> <20200406011026.GG18021@localhost> <4E7EFAC6-3E51-4FC7-B0F1-2F886BBC1F56@lukehoward.com> <20200406152828.GK18021@localhost> <47052E79-71C9-482E-AF42-D46C44F9AA47@padl.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 02:00:39 -0000 --Apple-Mail=_1ED7B8B4-2BD4-4C0C-8B6D-5DF6468BB2F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Apr 2020, at 11:51 am, Jeffrey E Altman = wrote: >=20 >> The NegoEx authors did not envisage a mechanism being negotiated = under >> both SPNEGO and NegoEx, so it doesn=E2=80=99t say anything about the = preference >> order of such a mechanism. (It was possible to build such a mechanism = up >> to Windows 8, but this was an accident that was then corrected.) >=20 > I don't believe that SAnon is a good choice for SPNEGO. One reason I > want to negotiate it under NegoEx is to prefer krb5-anon if its > configured and only use SAnon for the case where krb5-anon is = unavailable. That should be fine anyway, as long as Kerberos is ordered before SAnon = (which is in our implementation, SAnon is ordered after not only the = built-in mechanisms, but dynamically loaded ones as well). We seem to have one vote for NegoEx-only, one against; I=E2=80=99m = neutral (slight preference towards NegoEx-only). What to do? =E2=80=94 Luke= --Apple-Mail=_1ED7B8B4-2BD4-4C0C-8B6D-5DF6468BB2F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 7 Apr 2020, at 11:51 am, Jeffrey E Altman <jaltman@auristor.com> wrote:

The = NegoEx authors did not envisage a mechanism being negotiated under
both SPNEGO and NegoEx, so it doesn=E2=80=99t say anything = about the preference
order of such a mechanism. (It was = possible to build such a mechanism up
to Windows 8, but = this was an accident that was then corrected.)

I don't believe that SAnon is a good choice for SPNEGO. =  One reason I
want to negotiate it under NegoEx is to prefer krb5-anon if = its
configured = and only use SAnon for the case where krb5-anon is = unavailable.

That should be fine anyway, as long as Kerberos is ordered = before SAnon (which is in our implementation, SAnon is ordered after not = only the built-in mechanisms, but dynamically loaded ones as = well).

We seem = to have one vote for NegoEx-only, one against; I=E2=80=99m neutral = (slight preference towards NegoEx-only). What to do?

=E2=80=94 = Luke
= --Apple-Mail=_1ED7B8B4-2BD4-4C0C-8B6D-5DF6468BB2F5-- From nobody Mon Apr 6 19:37:36 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6013A138A for ; Mon, 6 Apr 2020 19:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuC7KpZcbeXA for ; Mon, 6 Apr 2020 19:37:32 -0700 (PDT) Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB343A1389 for ; Mon, 6 Apr 2020 19:37:32 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id CA8AA180FFB; Tue, 7 Apr 2020 02:37:31 +0000 (UTC) Received: from pdx1-sub0-mail-a56.g.dreamhost.com (100-96-14-12.trex.outbound.svc.cluster.local [100.96.14.12]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6833A180F77; Tue, 7 Apr 2020 02:37:31 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a56.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Tue, 07 Apr 2020 02:37:31 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Trouble-Cooing: 42a2ab724668af13_1586227051682_3946716706 X-MC-Loop-Signature: 1586227051682:3870010139 X-MC-Ingress-Time: 1586227051682 Received: from pdx1-sub0-mail-a56.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a56.g.dreamhost.com (Postfix) with ESMTP id 271CA8487F; Mon, 6 Apr 2020 19:37:31 -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=I7kvVCsWFXUcQo 4bFymC/m35xY0=; b=AXqZsOx293Heco7Vx64wRMEXVDofiRqqjL0nXA7Cf4LTh7 sQM6XCzC2hkJaDSPsB/H12PtflWlD73OuoPxcj7feA/VfuNZzFG/NPg0fPesh1Vx dR1oAvoi/c6shqT4FtV5jYhzxApI22RghuZh4kJp2fZfs+Wf6D4OtYXzRTxNE= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a56.g.dreamhost.com (Postfix) with ESMTPSA id DC44C8487E; Mon, 6 Apr 2020 19:37:28 -0700 (PDT) Date: Mon, 6 Apr 2020 21:37:25 -0500 X-DH-BACKEND: pdx1-sub0-mail-a56 From: Nico Williams To: Jeffrey E Altman Cc: Luke Howard , "kitten@ietf.org" Message-ID: <20200407023724.GR18021@localhost> References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> <38ED72E1-3361-4242-9923-C3BE61698BE0@padl.com> <20200406011026.GG18021@localhost> <4E7EFAC6-3E51-4FC7-B0F1-2F886BBC1F56@lukehoward.com> <20200406152828.GK18021@localhost> <47052E79-71C9-482E-AF42-D46C44F9AA47@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudeggdehjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 02:37:34 -0000 On Mon, Apr 06, 2020 at 09:51:40PM -0400, Jeffrey E Altman wrote: > On 4/6/2020 6:59 PM, Luke Howard wrote: > > Jeff suggests informational track. > > In my opinion getting something shipped quickly requires a private > organization oid and informational track. We should publish NegoEx as > informational as well since we are going to depend on it. I don't think anything prevents quick publication, whether on the Experimental or Informational tracks. > I don't think there is any benefit to experimental since NegoEx is > unpublished. I suspect that all of the original Microsoft editors have > moved on. I don't see how NegoEx not being an RFC has anything to do with which of Experimental or Informational this I-D goes onto. > I don't believe that SAnon is a good choice for SPNEGO. One reason I > want to negotiate it under NegoEx is to prefer krb5-anon if its > configured and only use SAnon for the case where krb5-anon is unavailable. Apps can set preference. Otherwise local configuration can set preference. NegoEx or no NegoEx makes no difference to this. The only reason to discuss NegoEx at all is that Windows apparently insists on it for new mechanisms, but as we have NegoEx widely implemented now, it almost doesn't matter. From nobody Mon Apr 6 19:39:34 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1BD3A1392 for ; Mon, 6 Apr 2020 19:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42yNS_nFKVyV for ; Mon, 6 Apr 2020 19:39:31 -0700 (PDT) Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44573A1390 for ; Mon, 6 Apr 2020 19:39:30 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 241A3100ED0; Tue, 7 Apr 2020 02:39:30 +0000 (UTC) Received: from pdx1-sub0-mail-a56.g.dreamhost.com (100-96-6-13.trex.outbound.svc.cluster.local [100.96.6.13]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 9EB67100EE7; Tue, 7 Apr 2020 02:39:29 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a56.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Tue, 07 Apr 2020 02:39:30 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Blushing-Drop: 2a34d5c13bd7a956_1586227169968_204533893 X-MC-Loop-Signature: 1586227169967:1786095233 X-MC-Ingress-Time: 1586227169967 Received: from pdx1-sub0-mail-a56.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a56.g.dreamhost.com (Postfix) with ESMTP id 60C8D8487F; Mon, 6 Apr 2020 19:39:29 -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=FRg30OrsAEURIP5wwOKIoO14LtA=; b=StdNcSDW09y ujOoPCY+2UBoeve2UEATz1r2Bq0NnbX3pAcoKrdORU3Yh0PQ7BoTSBI9E0JRbpor YDhEzhSWPPXQHxoY/UymvSMvFNX+l9Oqj+UUSu0NuK2HcmRUtDLt+KIcHdkRny8F +kkKaM2Yh2gdMGEnKbf2KqzULQ8NGn+Q= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a56.g.dreamhost.com (Postfix) with ESMTPSA id 7076C84871; Mon, 6 Apr 2020 19:39:25 -0700 (PDT) Date: Mon, 6 Apr 2020 21:39:23 -0500 X-DH-BACKEND: pdx1-sub0-mail-a56 From: Nico Williams To: Luke Howard Cc: Jeffrey Altman , "kitten@ietf.org" Message-ID: <20200407023922.GS18021@localhost> References: <20200405234929.GD18021@localhost> <38ED72E1-3361-4242-9923-C3BE61698BE0@padl.com> <20200406011026.GG18021@localhost> <4E7EFAC6-3E51-4FC7-B0F1-2F886BBC1F56@lukehoward.com> <20200406152828.GK18021@localhost> <47052E79-71C9-482E-AF42-D46C44F9AA47@padl.com> <472D27C4-7DFA-4BE5-8BE6-23D42C8E0E55@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <472D27C4-7DFA-4BE5-8BE6-23D42C8E0E55@padl.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudeggdehjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 02:39:33 -0000 On Tue, Apr 07, 2020 at 11:59:59AM +1000, Luke Howard wrote: > We seem to have one vote for NegoEx-only, one against; I=E2=80=99m neut= ral > (slight preference towards NegoEx-only). What to do? IMO you can simply not even mention it. If you must say anything about negotiation, you can speak of it generically -- after all, GSS envisions arbitrary mechanism-negotiation pseudo-mechanisms, not just SPNEGO, or SPNEGO+NegoEx. Nico --=20 From nobody Mon Apr 6 21:29:23 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA433A1551 for ; Mon, 6 Apr 2020 21:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-oxz-Y3p52I for ; Mon, 6 Apr 2020 21:29:19 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8579D3A1550 for ; Mon, 6 Apr 2020 21:29:19 -0700 (PDT) Received: by us.padl.com with ESMTP id 0374TCdQ003815; Tue, 7 Apr 2020 04:29:16 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 0374TCdQ003815 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586233757; bh=nYIBpe2ZgY6+S2f/YUJiguIgpzS20Av1ULCXN4Tw/go=; h=From:Subject:References:To:Date:From; b=C+rhWc29+SXxi816lWhsDwHP3JXizlofTGGiYd0a8Rw73XUvjpNtzK/IXp7zJKFi4 DfkxM6GJ1XHzrdQK8ZVRjgeUTti8ZHZihXRzsEK4VmdofNrtBSfNdCnKYCvJQz+8jf nX+0HLyILCSz1E20YgzAoqeL+PCkm1Zgi5RDKv43ZMTzrP6fP6N4S9qdWZDyqFjbmf Hv1rcGilNt9M5/rKNVjPiiIcjWnzvVyiB+hrhtCSLl0lIRNtnk+t1f1CqS0AljKjdq RCxT4aGmF6AImOjQ/2D+uIscmQTRMxPUzO1RsuQffy6fP4fSFx12SJOOW9wSSOraJQ Xoo1n4sL27mtQ== From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_BBFFB503-B342-4001-B443-F204D099EB15" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: References: <158623361969.31769.6586120656183044671@ietfa.amsl.com> To: "kitten@ietf.org" Date: Tue, 7 Apr 2020 14:29:11 +1000 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [kitten] draft-howard-gss-sanon-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 04:29:21 -0000 --Apple-Mail=_BBFFB503-B342-4001-B443-F204D099EB15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fixes some mistakes, etc. Have changed to Informational track and will = use an enterprise OID rather than requesting IANA assignment. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-howard-gss-sanon-03.txt > Date: 7 April 2020 at 2:26:59 pm AEST > To: "Luke Howard" >=20 >=20 > A new version of I-D, draft-howard-gss-sanon-03.txt > has been successfully submitted by Luke Howard and posted to the > IETF repository. >=20 > Name: draft-howard-gss-sanon > Revision: 03 > Title: A Simple Anonymous GSS-API Mechanism > Document date: 2020-04-07 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-03.txt > Status: = https://datatracker.ietf.org/doc/draft-howard-gss-sanon/ > Htmlized: https://tools.ietf.org/html/draft-howard-gss-sanon-03 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-03 >=20 > Abstract: > This document defines protocols, procedures and conventions for a > Generic Security Service Application Program Interface (GSS-API) > security mechanism that provides key agreement without = authentication > of either party. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_BBFFB503-B342-4001-B443-F204D099EB15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Fixes= some mistakes, etc. Have changed to Informational track and will use an = enterprise OID rather than requesting IANA assignment.

Begin= forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-howard-gss-sanon-03.txt
Date: = 7 April 2020 at 2:26:59 pm = AEST
To: = "Luke Howard" <lukeh@padl.com>

A new version of I-D, draft-howard-gss-sanon-03.txt
has been successfully submitted by Luke Howard and posted to = the
IETF repository.

Name: = draft-howard-gss-sanon
Revision: 03
Title:= = A Simple Anonymous GSS-API Mechanism
Document = date: = 2020-04-07
Group: Individual Submission
Pages:= = 11
URL: =            https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-03.= txt
Status: =         https://datatracker.ietf.org/doc/draft-howard-gss-sanon/Htmlized:       https://tools.ietf.org/html/draft-howard-gss-sanon-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-03

Abstract:
=   This document defines protocols, procedures and conventions = for a
  Generic Security Service Application = Program Interface (GSS-API)
  security = mechanism that provides key agreement without authentication
  of either party.




Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



= --Apple-Mail=_BBFFB503-B342-4001-B443-F204D099EB15-- From prvs=1366f3357a=jaltman@auristor.com Mon Apr 6 18:52:19 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71033A12F6 for ; Mon, 6 Apr 2020 18:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=auristor.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99glKruc589w for ; Mon, 6 Apr 2020 18:52:18 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB443A12F3 for ; Mon, 6 Apr 2020 18:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=auristor.com; s=MDaemon; t=1586224336; x=1586829136; i=jaltman@auristor.com; q=dns/txt; h=VBR-Info:Subject:To:Cc: References:From:Organization:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; bh=mUNl3J8YnE9WfINMdowLEA Lf89vJws9KJuFZQA2nJJ4=; b=qwG+qFKZjDq2okdr3ISiFXe7cV5GCgwUaluWT4 bIrjgnFSoDXv4w0j47S/zNmUpNxGT02MB2dvPJ/Tw6ocq6Um5sZ7Gms2W2MHeUtA s7YWxiw0jeffihF3SUXglHws+aYYN8xPobCdc2teQQq5xgM2FEQiAR2ETgSkk4it kKaFc= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Mon, 06 Apr 2020 21:52:16 -0400 Received: by auristor.com (208.125.0.235) (MDaemon PRO v20.0.0rc1) with ESMTPSA id md5001002398729.msg; Mon, 06 Apr 2020 21:52:15 -0400 VBR-Info: md=auristor.com; mc=all; mv=vbr.emailcertification.org; X-Spam-Processed: sequoia-grove.secure-endpoints.com, Mon, 06 Apr 2020 21:52:15 -0400 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 66.108.226.6 X-MDArrival-Date: Mon, 06 Apr 2020 21:52:15 -0400 X-MDOrigin-Country: United States, North America X-Authenticated-Sender: jaltman@auristor.com X-Return-Path: prvs=1366f3357a=jaltman@auristor.com X-Envelope-From: jaltman@auristor.com X-MDaemon-Deliver-To: kitten@ietf.org To: Luke Howard , Nicolas Williams Cc: "kitten@ietf.org" References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <20200405234929.GD18021@localhost> <38ED72E1-3361-4242-9923-C3BE61698BE0@padl.com> <20200406011026.GG18021@localhost> <4E7EFAC6-3E51-4FC7-B0F1-2F886BBC1F56@lukehoward.com> <20200406152828.GK18021@localhost> <47052E79-71C9-482E-AF42-D46C44F9AA47@padl.com> From: Jeffrey E Altman Organization: AuriStor, Inc. Message-ID: Date: Mon, 6 Apr 2020 21:51:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <47052E79-71C9-482E-AF42-D46C44F9AA47@padl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040801090306080006000007" X-MDCFSigsAdded: auristor.com Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2020 07:56:12 -0700 Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 14:19:50 -0000 This is a cryptographically signed message in MIME format. --------------ms040801090306080006000007 Content-Type: multipart/mixed; boundary="------------809E2359A399BAF6612F2346" Content-Language: en-US This is a multi-part message in MIME format. --------------809E2359A399BAF6612F2346 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/6/2020 6:59 PM, Luke Howard wrote: > Jeff suggests informational track. In my opinion getting something shipped quickly requires a private organization oid and informational track. We should publish NegoEx as informational as well since we are going to depend on it. I don't think there is any benefit to experimental since NegoEx is unpublished. I suspect that all of the original Microsoft editors have moved on. > I=E2=80=99ve fixed the NegoEx thing anyway in the most recent draft. >=20 > The NegoEx authors did not envisage a mechanism being negotiated under > both SPNEGO and NegoEx, so it doesn=E2=80=99t say anything about the pr= eference > order of such a mechanism. (It was possible to build such a mechanism u= p > to Windows 8, but this was an accident that was then corrected.) I don't believe that SAnon is a good choice for SPNEGO. One reason I want to negotiate it under NegoEx is to prefer krb5-anon if its configured and only use SAnon for the case where krb5-anon is unavailable= =2E Jeffrey Altman --------------809E2359A399BAF6612F2346 Content-Type: text/x-vcard; charset=utf-8; name="jaltman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jaltman.vcf" begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:;;255 W 94TH ST STE 6B;New York;NY;10025-6985;United States email;internet:jaltman@auristor.com title:CEO tel;work:+1-212-769-9018 url:https://www.linkedin.com/in/jeffreyaltman/ version:2.1 end:vcard --------------809E2359A399BAF6612F2346-- --------------ms040801090306080006000007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGswggXSMIIEuqADAgECAhBAAW0B1qVVQ32wvx2EXYU6MA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE5MDkwNTE0MzE0N1oXDTIyMTEwMTE0MzE0N1owcDEvMC0GCgmSJomT8ixkAQETH0Ew MTQxMEMwMDAwMDE2RDAxRDZBNTQwMDAwMDQ0NDcxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCY1TC9QeWnUgEoJ81FcAVnhGn/AWuzvkYRUG5/ZyXDdaM212e8 ybCklgSmZweqNdrfaaHXk9vwjpvpD4YWgb07nJ1QBwlvRV/VPAaDdneIygJJWBCzaMVLttKO 0VimH/I/HUwFBQT2mrktucCEf2qogdi2P+p5nuhnhIUiyZ71Fo43gF6cuXIMV/1rBNIJDuwM Q3H8zi6GL0p4mZFZDDKtbYq2l8+MNxFvMrYcLaJqejQNQRBuZVfv0Fq9pOGwNLAk19baIw3U xdwx+bGpTtS63Py1/57MQ0W/ZXE/Ocnt1qoDLpJeZIuEBKgMcn5/iN9+Ro5zAuOBEKg34wBS 8QCTAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx Mi5wN2MwHwYDVR0jBBgwFoAUpHPa72k1inXMoBl7CDL4a4nkQuwwCQYDVR0TBAIwADCCASsG A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTIuY3JsMB8GA1UdEQQY MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBR7pHsvL4H5GdzNToI9e5BuzV19 bzAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAFlm JYk4Ff1v/n0foZkv661W4LCRtroBaVykOXetrDDOQNK2N6JdTa146uIZVgBeU+S/0DLvJBKY tkUHQ9ovjXJTsuCBmhIIw3YlHoFxbku0wHEpXMdFUHV3tUodFJJKF3MbC8j7dOMkag59/Mdz Sjszdvit0av9nTxWs/tRKKtSQQlxtH34TouIke2UgP/Nn901QLOrJYJmtjzVz8DW3IYVxfci SBHhbhJTdley5cuEzphELo5NR4gFjBNlxH7G57Hno9+EWILpx302FJMwTgodIBJbXLbPMHou xQbOL2anOTUMKO8oH0QdQHCtC7hpgoQa7UJYJxDBI+PRaQ/HObkwggaRMIIEeaADAgECAhEA +d5Wf8lNDHdw+WAbUtoVOzANBgkqhkiG9w0BAQsFADBKMQswCQYDVQQGEwJVUzESMBAGA1UE ChMJSWRlblRydXN0MScwJQYDVQQDEx5JZGVuVHJ1c3QgQ29tbWVyY2lhbCBSb290IENBIDEw HhcNMTUwMjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5WjA6MQswCQYDVQQGEwJVUzESMBAGA1UE ChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMjCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANGRTTzPCic0kq5L6ZrUJWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJ JDqGqDYymaAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5zgiMNnAFVD9PyrsuF+poqmlxhlQ06sFY2 hbhQkVVQ00KCNgUzKcBUIvjv04w+fhNPkwGW5M7Ae5K5OGFGwOoRck9GG6MUVKvTNkBw2/vN MOd29VGVTtR0tjH5PS5yDXss48Yl1P4hDStO2L4wTsW2P37QGD27//XGN8K6amWB6F2XOgff /PmlQjQOORT95PmLkwwvma5nj0AS0CVp8kv0K2RHV7GonllKpFDMT0CkxMQKwoj+tWEWJTiD KSsCAwEAAaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9j b21tZXJjaWFsLm9jc3AuaWRlbnRydXN0LmNvbTBHBggrBgEFBQcwAoY7aHR0cDovL3ZhbGlk YXRpb24uaWRlbnRydXN0LmNvbS9yb290cy9jb21tZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0j BBgwFoAU7UQZwNPwBovupHu+QucmVMiONnYwDwYDVR0TAQH/BAUwAwEB/zCCASAGA1UdIASC ARcwggETMIIBDwYEVR0gADCCAQUwggEBBggrBgEFBQcCAjCB9DBFFj5odHRwczovL3NlY3Vy ZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDADAgEB GoGqVGhpcyBUcnVzdElEIENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRh bmNlIHdpdGggSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQg YXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3Rz L2luZGV4Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRy dXN0LmNvbS9jcmwvY29tbWVyY2lhbHJvb3RjYTEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ 5ELsMA0GCSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv062MZfg+xMSNUXYKvHwvZIk+6H1pUmivy DI4I6A3wWzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPo VJKgpnzp/7cECXkX8R4NyPtEn8KecbNdGBdEaG4a7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36 /mAFeCEq0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8xLcuYX3RWlirRyH6RPfeAi5kySOEhG1qu NHe06QIwpigjyFT6v/vRqoIBr7WpDOSt1VzXPVbSj1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wH SDbL+L2he8hNN54doy1e1wJHKmnfb0uBAeISoxRbJnMMWvgAlH5FVrQWlgajeH/6NbYbBSRx ALuEOqEQepmJM6qz4oD2sxdq4GMN5adAdYEswkY/o0bRKyFXTD3mdqeRXce0jYQbWm7oapqS ZBccFvUgYOrB78tB6c1bxIgaQKRShtWR1zMM0JfqUfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcb TfqF2eAgprpyzLWmdr0mou3bv1Sq4OuBhmTQCnqxAXr4yVTRYHkp5lCvRgeJAme1OTVpVPth /O7HJ7VuEP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcSSSt9hliALnExTEjii20B2nSDojGCAxQw ggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMO VHJ1c3RJRCBDQSBBMTICEEABbQHWpVVDfbC/HYRdhTowDQYJYIZIAWUDBAIBBQCgggGXMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDQwNzAxNTE0MVow LwYJKoZIhvcNAQkEMSIEIHmhFX7Nn0f8MS401BExjghvXkFi0w7+JMCp66sa1pfKMF0GCSsG AQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UE AxMOVHJ1c3RJRCBDQSBBMTICEEABbQHWpVVDfbC/HYRdhTowXwYLKoZIhvcNAQkQAgsxUKBO MDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQg Q0EgQTEyAhBAAW0B1qVVQ32wvx2EXYU6MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAe66baMSBc7BE 9hTiON8ziG3Fl/Ouv1nNkz8nEZVhuU0IFh+Dsc7P2wRMHQd5rPy7sVAo9nV3PMP/qBle7NSg 0MfGaL+XJOooMaGx8PoRoIcK3Rgk626ST8w6pk8d8XfAj1jm5SgINWQ8rmK3B2bMSo10XyBN EiTIq4rn+dxrEzelWVnVrFavqUor3SPhf7rfL/AbEnF8YKi5PkqbaV9sAUzCsxOXwjDZhAfS p7FIcG+5CvNz/KjjdrJqLAzYOIuaO51cigLI9yvlLgRoTy52dWxbFtjZNYqFfYZjcVYTNUBv klksZilec9DE4BV6Rj1SibH07FMCFjM6AsJ6yXOVigAAAAAAAA== --------------ms040801090306080006000007-- From nobody Thu Apr 9 06:11:14 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820953A0AF5 for ; Thu, 9 Apr 2020 06:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.592 X-Spam-Level: X-Spam-Status: No, score=0.592 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl 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 ExFx_tTYTuqB for ; Thu, 9 Apr 2020 06:10:55 -0700 (PDT) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726B73A0959 for ; Thu, 9 Apr 2020 06:10:54 -0700 (PDT) Received: from popmini.vanrein.org ([IPv6:2001:980:93a5:1::7]) by smtp-cloud9.xs4all.net with ESMTP id MWxGjGFFCZJ1DMWxHjuzQ5; Thu, 09 Apr 2020 15:10:52 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1586437850; h=message-id : date : from : mime-version : to : subject : content-type : content-transfer-encoding : date : from : subject; bh=8Ue4RZvOTMxgrJ+mYFXR2YNO9N972A4PFwQevGEidxc=; b=S7kLRyKjzT3Cxb5/1CzyVCAOBdb81n9Nb7U84q99w9doB4A2Yu354+bl OAOvHQ5N/icsfcWndyRKe2C5vz0yk7k0cSpnbKPK1aLlh4Y4JBeDcPqtlt aqXKbVJBllGGekiHSZzyyZzt9EbjMVJkVs3os/fgLJz3oESx3D7cqTRh8= Received: by fame.vanrein.org (Postfix, from userid 1006) id B3AB339199; Thu, 9 Apr 2020 13:10:50 +0000 (UTC) X-Original-To: kitten@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 98BDB39187; Thu, 9 Apr 2020 13:10:50 +0000 (UTC) Message-ID: <5E8F1ED9.1020108@openfortress.nl> Date: Thu, 09 Apr 2020 15:10:49 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "kitten@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfMkicGmcd/8F031p036fesCSBGaOXCPkZk1fZow70R++FIQ8abE20gNZVDFRb/yauxyqQxAYQs43LMcf8GMWw/IVCKVk40cFgWgyLclh1l2jYvvVDG+y Utmlw6JJSN3DmHZmebL3ZXULjQLKuZPCYas47FebciGE6rSuSbof85x9z668BBMjqfJQxFm1JJtIbA== Archived-At: Subject: [kitten] SASL, how to choose the type of channel binding? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 13:11:03 -0000 Hello, I can see that the GS2 negotiates *whether* to use channel binding, but how can a client and server agree on *which* form to use? Thanks, -Rick From nobody Thu Apr 9 06:30:51 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A7B3A09E3 for ; Thu, 9 Apr 2020 06:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl 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 Sd0iqXH0sZLu for ; Thu, 9 Apr 2020 06:30:47 -0700 (PDT) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA473A098C for ; Thu, 9 Apr 2020 06:30:46 -0700 (PDT) Received: from popmini.vanrein.org ([IPv6:2001:980:93a5:1::7]) by smtp-cloud9.xs4all.net with ESMTP id MXGVjGLrOZJ1DMXGWjv3r1; Thu, 09 Apr 2020 15:30:44 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1586439043; h=message-id : date : from : mime-version : to : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=MhMDWMJCMyFuq0BuhJVq+0TAiZcy6N06AgVVPOx/G4E=; b=PQyApO/mDkL04gvR3dntmrF/FzURdMipqlWBE9x/lD538NdS3ImykMgN +LEY7XftnpWllFPrX1rwD3KjCf/HgJwl4I7fXu0nHUPPgttvvaJ3ZpC3ml zXqbKZKJaltq2l4iVYVxERxe6BuUnG8+B3vAZZoeZDw9Dcbfmy4iwYTrg= Received: by fame.vanrein.org (Postfix, from userid 1006) id 7F1BF3959B; Thu, 9 Apr 2020 13:30:43 +0000 (UTC) X-Original-To: kitten@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 5DDED39597; Thu, 9 Apr 2020 13:30:43 +0000 (UTC) Message-ID: <5E8F2382.2070804@openfortress.nl> Date: Thu, 09 Apr 2020 15:30:42 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "kitten@ietf.org" References: <5E8F1ED9.1020108@openfortress.nl> In-Reply-To: <5E8F1ED9.1020108@openfortress.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfLbnthS5ckQR0UhCScyS+N8Q46qOyxeorOJFkTarsSkQxaZmacErxqouCx3qCVTaALI9Vqw15ogsVjxtgxaieTaH+6ubSJnR/N/L1bvaWo3CEweOnsoP PyI6Rx6SXbIXQPOwV8vzzfyQkUHXEycMo+JvRzJCIt/DRs8a5NS8Rcu7+NUbFPoh8Wy6gTXzfHemBQ== Archived-At: Subject: Re: [kitten] SASL, how to choose the type of channel binding? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 13:30:49 -0000 Oops, I was blinded... have been focussing on the three forms, overlooking that there is a value after "p". gs2-cb-flag = ("p=" cb-name) / "n" / "y" ;; GS2 channel binding (CB) flag ;; "p" -> client supports and used CB ;; "n" -> client does not support CB ;; "y" -> client supports CB, thinks the server ;; does not Sorry :) -Rick From nobody Thu Apr 9 06:46:27 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346383A0B71 for ; Thu, 9 Apr 2020 06:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfd5fmWC4e_H for ; Thu, 9 Apr 2020 06:46:22 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C611F3A0B6E for ; Thu, 9 Apr 2020 06:46:21 -0700 (PDT) Received: by us.padl.com with ESMTP id 039DkEfU003473; Thu, 9 Apr 2020 13:46:19 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 039DkEfU003473 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586439980; bh=Sx4ZCLpFO+vzOlsyB3hubcyxMV7zhpbDdxLJrSwsI04=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=EaM/4yFVEmRJ3Aw1/cfSrl27rg7KnrYe/dN0cYENsrCnM+HOkEmDzDSNu3Wwh0Dp9 emO2w10Sw2BMl6oJN5+nxXGzC6efnnJMWiBY7BTLYY4q+1JdK2PQ7MoV4zhsvqFqcf hdLotd/KiKQeyXfNBTKw/VotSRF/cSdB8pnWS/2eSk9DponWXdsQekAozM+YQEzem/ vHVQxNHmiJeSpeNs2FdrF1zRhiSJwtY5AX/cs6EqotJXCgF3u63pLxzDpQmgsT/HVr QSYscdaX+JfqvBPabwuOWZUu9ZENIz6b1ylgy4VcPRfMb28f8noJqNjwmClz3ViYEc G5TcEdKpjO4hA== From: Luke Howard Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B4985CB7-2314-41BB-B608-37E0E1518DB1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 9 Apr 2020 23:46:13 +1000 In-Reply-To: <5E8F2382.2070804@openfortress.nl> Cc: "kitten@ietf.org" To: Rick van Rein References: <5E8F1ED9.1020108@openfortress.nl> <5E8F2382.2070804@openfortress.nl> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [kitten] SASL, how to choose the type of channel binding? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 13:46:25 -0000 --Apple-Mail=_B4985CB7-2314-41BB-B608-37E0E1518DB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (Once more from correct email address =E2=80=93) There=E2=80=99s an implementation of GS2 in Cyrus SASL if it helps. Luke Howard web / facebook = / instagram = / spotify = > On 9 Apr 2020, at 11:30 pm, Rick van Rein = wrote: >=20 > Oops, >=20 > I was blinded... have been focussing on the three forms, overlooking = that there is a value after "p". >=20 > gs2-cb-flag =3D ("p=3D" cb-name) / "n" / "y" > ;; GS2 channel binding (CB) flag > ;; "p" -> client supports and used CB > ;; "n" -> client does not support CB > ;; "y" -> client supports CB, thinks the server > ;; does not >=20 > Sorry :) > -Rick >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail=_B4985CB7-2314-41BB-B608-37E0E1518DB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 (Once= more from correct email address =E2=80=93)

There=E2=80=99s an implementation = of GS2 in Cyrus SASL if it helps.

Luke = Howard
web / facebook / instagram / spotify

On 9 Apr 2020, at 11:30 pm, Rick van Rein <rick@openfortress.nl> wrote:

Oops,

I was blinded... have been = focussing on the three forms, overlooking that there is a value after = "p".

   gs2-cb-flag =     =3D ("p=3D" cb-name) / "n" / "y"
=             &n= bsp;        ;; GS2 channel = binding (CB) flag
=             &n= bsp;        ;; "p" -> client = supports and used CB
=             &n= bsp;        ;; "n" -> client = does not support CB
=             &n= bsp;        ;; "y" -> client = supports CB, thinks the server
=             &n= bsp;        ;; =           does not

Sorry :)
-Rick

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

= --Apple-Mail=_B4985CB7-2314-41BB-B608-37E0E1518DB1-- From nobody Thu Apr 9 15:51:42 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DD53A11B4 for ; Thu, 9 Apr 2020 15:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCFf6FHJ2jnn for ; Thu, 9 Apr 2020 15:51:39 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F283D3A11A2 for ; Thu, 9 Apr 2020 15:51:38 -0700 (PDT) Received: by us.padl.com with ESMTP id 039MpVkW006234; Thu, 9 Apr 2020 22:51:36 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 039MpVkW006234 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586472697; bh=OZic4+IcQjAEY8ZIYe2IJ+pg1Gb7oUQp8kfJ1tKp/Bs=; h=From:Subject:References:To:Date:From; b=yDfuG6vwr9VIwuFz2nKEVafXb5mvjQw3ggua63xS+7AoYqZXwm9Rhj5ryADXKAyH+ 3EAijt2jIcQ48HwmNtmzhYbQ7F1to4qUf8RPBKi6eYrQcBvXvi0QGuYKLf61pEOzdB 7VTALhqYb0cchIaLLFLMjonMQE6UCuQDUMMksZ0KJTnJbWjp/4Ug3ibQ9UWRS43U6M J7ViAZkeYNO+nakoYccQlPW9RJuUtWbhdWHd9pKqbVNcClotDF/PLlYKz5Pym8NnHF 9IecRik0qCW17ZjPM3syyWTv/Qwtum5m0brR0J56kWhANCui8OgaGHXtaeBKM4AAFa hEAa07BU73EXQ== From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_8D2335ED-C801-4126-AC5C-4D41F576533F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <5EB96138-6181-4B21-858A-CBA264805190@padl.com> References: <158647258834.1722.15976776270941798800@ietfa.amsl.com> To: "kitten@ietf.org" Date: Fri, 10 Apr 2020 08:51:27 +1000 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [kitten] Fwd: New Version Notification for draft-howard-gss-sanon-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 22:51:41 -0000 --Apple-Mail=_8D2335ED-C801-4126-AC5C-4D41F576533F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii More cleanups. Fixed a bug in the KDF spec. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-howard-gss-sanon-05.txt > Date: 10 April 2020 at 8:49:48 am AEST > To: "Luke Howard" >=20 >=20 > A new version of I-D, draft-howard-gss-sanon-05.txt > has been successfully submitted by Luke Howard and posted to the > IETF repository. >=20 > Name: draft-howard-gss-sanon > Revision: 05 > Title: A Simple Anonymous GSS-API Mechanism > Document date: 2020-04-10 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-05.txt > Status: = https://datatracker.ietf.org/doc/draft-howard-gss-sanon/ > Htmlized: https://tools.ietf.org/html/draft-howard-gss-sanon-05 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-05 >=20 > Abstract: > This document defines protocols, procedures and conventions for a > Generic Security Service Application Program Interface (GSS-API) > security mechanism that provides key agreement without = authentication > of either party. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_8D2335ED-C801-4126-AC5C-4D41F576533F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
More cleanups. Fixed a bug in the KDF spec.

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-howard-gss-sanon-05.txt
Date: = 10 April 2020 at 8:49:48 am = AEST
To: = "Luke Howard" <lukeh@padl.com>

A new version of I-D, draft-howard-gss-sanon-05.txt
has been successfully submitted by Luke Howard and posted to = the
IETF repository.

Name: = draft-howard-gss-sanon
Revision: 05
Title:= = A Simple Anonymous GSS-API Mechanism
Document = date: = 2020-04-10
Group: Individual Submission
Pages:= = 11
URL: =            https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-05.= txt
Status: =         https://datatracker.ietf.org/doc/draft-howard-gss-sanon/Htmlized:       https://tools.ietf.org/html/draft-howard-gss-sanon-05
Htmlized:       https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-05

Abstract:
=   This document defines protocols, procedures and conventions = for a
  Generic Security Service Application = Program Interface (GSS-API)
  security = mechanism that provides key agreement without authentication
  of either party.




Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



= --Apple-Mail=_8D2335ED-C801-4126-AC5C-4D41F576533F-- From nobody Fri Apr 10 16:37:26 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA5F3A11A2 for ; Fri, 10 Apr 2020 16:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahldFQDtJ2cM for ; Fri, 10 Apr 2020 16:37:23 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57E83A11B4 for ; Fri, 10 Apr 2020 16:37:22 -0700 (PDT) Received: by us.padl.com with ESMTP id 03ANbFC9001256; Fri, 10 Apr 2020 23:37:20 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 03ANbFC9001256 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586561840; bh=/+maIpwV3CpGYgUxH+9TJmK10hWD+ct+3F4GWWDD1do=; h=From:Subject:References:To:Date:From; b=VodFQZOFE2QAziiI2rznPSwWPHES8YLEbC11t5s0cfVomsx7Is4OwAt/Fz8GbRqqM cNvhH/sXSytxzrrOu9J7tA2irGEipl6s3kENtKqkE3N0021V9/1PJScq7Hlsuzy34I cXpM6UtZvWmzxaQwGo7dONzSaFXg2o0jXbyLvHxGUQcbSGwAW7wiAUE3poOerg5BYk 2+7FbCG03ygZwMxQNDvqjMEcVoyQcJEpxdRnt6MiSIXa7W8Sq8GF7T7LD1MA2MGyUs zsJh56Ra1nFHFHYJmXNOeoGXqG12pnKlrAIwxoGgsUWceJoM2jGFl7eZgxh3OSvTeG z1DgS3yYx5F1Q== From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_C06D0BCA-B0C3-4983-B63E-2E70E49F25B7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: References: <158656162400.32095.4840745906393120812@ietfa.amsl.com> To: "kitten@ietf.org" Date: Sat, 11 Apr 2020 09:37:15 +1000 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [kitten] Fwd: New Version Notification for draft-howard-gss-sanon-06.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 23:37:25 -0000 --Apple-Mail=_C06D0BCA-B0C3-4983-B63E-2E70E49F25B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cleaned up, separated out non-normative references into appendices. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-howard-gss-sanon-06.txt > Date: 11 April 2020 at 9:33:44 am AEST > To: "Luke Howard" >=20 >=20 > A new version of I-D, draft-howard-gss-sanon-06.txt > has been successfully submitted by Luke Howard and posted to the > IETF repository. >=20 > Name: draft-howard-gss-sanon > Revision: 06 > Title: A Simple Anonymous GSS-API Mechanism > Document date: 2020-04-11 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-06.txt > Status: = https://datatracker.ietf.org/doc/draft-howard-gss-sanon/ > Htmlized: https://tools.ietf.org/html/draft-howard-gss-sanon-06 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-06 >=20 > Abstract: > This document defines protocols, procedures and conventions for a > Generic Security Service Application Program Interface (GSS-API) > security mechanism that provides key agreement without = authentication > of either party. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_C06D0BCA-B0C3-4983-B63E-2E70E49F25B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Cleaned up, separated out non-normative references into = appendices.

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-howard-gss-sanon-06.txt
Date: = 11 April 2020 at 9:33:44 am = AEST
To: = "Luke Howard" <lukeh@padl.com>

A new version of I-D, draft-howard-gss-sanon-06.txt
has been successfully submitted by Luke Howard and posted to = the
IETF repository.

Name: = draft-howard-gss-sanon
Revision: 06
Title:= = A Simple Anonymous GSS-API Mechanism
Document = date: = 2020-04-11
Group: Individual Submission
Pages:= = 11
URL: =            https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-06.= txt
Status: =         https://datatracker.ietf.org/doc/draft-howard-gss-sanon/Htmlized:       https://tools.ietf.org/html/draft-howard-gss-sanon-06
Htmlized:       https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-06

Abstract:
=   This document defines protocols, procedures and conventions = for a
  Generic Security Service Application = Program Interface (GSS-API)
  security = mechanism that provides key agreement without authentication
  of either party.




Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



= --Apple-Mail=_C06D0BCA-B0C3-4983-B63E-2E70E49F25B7-- From nobody Sun Apr 12 23:17:03 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D52C3A0FDD for ; Sun, 12 Apr 2020 23:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiL5iBRE4lxW for ; Sun, 12 Apr 2020 23:16:54 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619CD3A0FEB for ; Sun, 12 Apr 2020 23:16:52 -0700 (PDT) Received: by us.padl.com with ESMTP id 03D6GkJr001336; Mon, 13 Apr 2020 06:16:51 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 03D6GkJr001336 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586758611; bh=ZtmrkZ+bIO6TzVqFOlrppp4N7o5LpxxkgwarsIw3a6c=; h=From:Subject:References:To:Date:From; b=p+3q8YfrxKD3Iis//dMt+KNLhV/1A0ptbLso1xyAoj4PsdqjGSQlMHOh2Z471PjXN I94yiVxjeFcogqPpiA5IUUb3s9V4FMLXRmnm/PM+LnceJQhuI+Ga+tYv2aE0load4U o01G/XUtGv/UiZd1Y3mx3flJXp/Vsj5XgwJytYHm1cVwhTZLbl/TOd3MBwigCO1xgw GkUAqS7qx5tg38d5yHBgFiOE6D/Tznl+Eh2zObAQyJjgxfL32xUhKHX9RE+DoP4cAC lC5R+wcuqj1PJx0ZWjCesYAHPsoFunpJqvQdYXb1Xa0F5qaVTmIbI74poFEQ7Hwdr7 9+5cSrG8gLXcQ== From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_A8D21BB0-058B-4F20-854E-885EA1EEA1F6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <414C8059-CC12-4262-8236-9BE37647C6BC@padl.com> References: <158675829680.23735.16489059823500058143@ietfa.amsl.com> To: "kitten@ietf.org" Date: Mon, 13 Apr 2020 16:16:43 +1000 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [kitten] Fwd: New Version Notification for draft-howard-gss-sanon-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 06:17:02 -0000 --Apple-Mail=_A8D21BB0-058B-4F20-854E-885EA1EEA1F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The significant change in this version is simplifying and handling = GSS-API name types. Now, all standard name types can be imported and = preserved for round-tripping through = GSS_Export_name()/GSS_Import_name(). SAnon is however concerned only with names that represent the anonymous = identity (see Section 4.1). SAnon GSS_Init_sec_context() will succeed when one of the following is = true: the caller specified GSS_C_ANON_FLAG; the initiator credential = identity is an anonymous name; the target is an anonymous name. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-howard-gss-sanon-07.txt > Date: 13 April 2020 at 4:11:36 pm AEST > To: "Luke Howard" >=20 >=20 > A new version of I-D, draft-howard-gss-sanon-07.txt > has been successfully submitted by Luke Howard and posted to the > IETF repository. >=20 > Name: draft-howard-gss-sanon > Revision: 07 > Title: A Simple Anonymous GSS-API Mechanism > Document date: 2020-04-13 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-07.txt > Status: = https://datatracker.ietf.org/doc/draft-howard-gss-sanon/ > Htmlized: https://tools.ietf.org/html/draft-howard-gss-sanon-07 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-07 >=20 > Abstract: > This document defines protocols, procedures and conventions for a > Generic Security Service Application Program Interface (GSS-API) > security mechanism that provides key agreement without = authentication > of either party. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_A8D21BB0-058B-4F20-854E-885EA1EEA1F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = significant change in this version is simplifying and handling GSS-API = name types. Now, all standard name types can be imported and preserved = for round-tripping through GSS_Export_name()/GSS_Import_name().

SAnon is however = concerned only with names that represent the anonymous identity (see = Section 4.1).

SAnon GSS_Init_sec_context() will succeed when one of the = following is true: the caller specified GSS_C_ANON_FLAG; the initiator = credential identity is an anonymous name; the target is an anonymous = name.

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-howard-gss-sanon-07.txt
Date: = 13 April 2020 at 4:11:36 pm = AEST
To: = "Luke Howard" <lukeh@padl.com>

A new version of I-D, draft-howard-gss-sanon-07.txt
has been successfully submitted by Luke Howard and posted to = the
IETF repository.

Name: = draft-howard-gss-sanon
Revision: 07
Title:= = A Simple Anonymous GSS-API Mechanism
Document = date: = 2020-04-13
Group: Individual Submission
Pages:= = 12
URL: =            https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-07.= txt
Status: =         https://datatracker.ietf.org/doc/draft-howard-gss-sanon/Htmlized:       https://tools.ietf.org/html/draft-howard-gss-sanon-07
Htmlized:       https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-07

Abstract:
=   This document defines protocols, procedures and conventions = for a
  Generic Security Service Application = Program Interface (GSS-API)
  security = mechanism that provides key agreement without authentication
  of either party.




Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



= --Apple-Mail=_A8D21BB0-058B-4F20-854E-885EA1EEA1F6-- From nobody Tue Apr 14 17:52:35 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D6E3A13BA for ; Tue, 14 Apr 2020 17:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lu5z6NZEKBn for ; Tue, 14 Apr 2020 17:52:33 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EAEE3A1383 for ; Tue, 14 Apr 2020 17:52:33 -0700 (PDT) Received: by us.padl.com with ESMTP id 03F0qQ8a017997; Wed, 15 Apr 2020 00:52:31 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 03F0qQ8a017997 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586911951; bh=Lq9T4P2lRtB7JX6Sx7gQTJu/O401NEWkmKhMQLviyB0=; h=From:Subject:References:To:Date:From; b=wEvNbixFPK+fjhPTEIsDBQP3wUKuvgsrZBbAdCwOJfEko31a2HhqEzVVI7LNKaVIR 8m1KP5Exn1YM5i6NsdvKQ+etLf3w57n2KXilGrIS8qkAgnsDnx6sICGCsSfPR1gqDL xhDZzQHfSVhTtKOd76x0BTn4UxI6qdPaKEyEWdlq+VBmMCFTxibmzFuO5wDFeYdVOZ 3diu3kb4fQf6V/o7ynOerF+NO7+pYMyufbSSx9Lg7VcPKdt+GH3vW996KFsX95YZy9 nc9vQ3a7lv6i3IEuQe6BM61VCz3486VFoHV2iSuF3WtlRXec4Fq9DWdSRENfCGyJY4 mqXgsNvrVJLbA== From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_789302BC-0C7B-4D5F-A7B8-5F1872747666" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: References: <158691170598.14943.12779993393980210533@ietfa.amsl.com> To: "kitten@ietf.org" Date: Wed, 15 Apr 2020 10:52:24 +1000 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [kitten] Fwd: New Version Notification for draft-howard-gss-sanon-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 00:52:35 -0000 --Apple-Mail=_789302BC-0C7B-4D5F-A7B8-5F1872747666 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Changes in this version: * The SAnon mechanism name is now described as a boolean indicating = whether the name represents the anonymous identity or not. * Only names representing anonymous identities can be exported. * Added a bit of a hack for Windows interoperability where we need to = convey RFC4757 extended GSS flags =E2=80=93 these are done in NegoEx = metadata so as not to complicate the base protocol.=20 Luke Howard web / facebook = / instagram = / spotify = > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-howard-gss-sanon-10.txt > Date: 15 April 2020 at 10:48:26 am AEST > To: "Luke Howard" >=20 >=20 > A new version of I-D, draft-howard-gss-sanon-10.txt > has been successfully submitted by Luke Howard and posted to the > IETF repository. >=20 > Name: draft-howard-gss-sanon > Revision: 10 > Title: A Simple Anonymous GSS-API Mechanism > Document date: 2020-04-15 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-10.txt > Status: = https://datatracker.ietf.org/doc/draft-howard-gss-sanon/ > Htmlized: https://tools.ietf.org/html/draft-howard-gss-sanon-10 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-10 >=20 > Abstract: > This document defines protocols, procedures and conventions for a > Generic Security Service Application Program Interface (GSS-API) > security mechanism that provides key agreement without = authentication > of either party. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_789302BC-0C7B-4D5F-A7B8-5F1872747666 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Changes in this version:

* The SAnon mechanism name is now = described as a boolean indicating whether the name represents the = anonymous identity or not.
* Only names = representing anonymous identities can be exported.
* = Added a bit of a hack for Windows interoperability where we need to = convey RFC4757 extended GSS flags =E2=80=93 these are done in NegoEx = metadata so as not to complicate the base protocol. 

Luke = Howard
web / facebook / instagram / spotify

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-howard-gss-sanon-10.txt
Date: = 15 April 2020 at 10:48:26 am = AEST
To: = "Luke Howard" <lukeh@padl.com>

A new version of I-D, draft-howard-gss-sanon-10.txt
has been successfully submitted by Luke Howard and posted to = the
IETF repository.

Name: = draft-howard-gss-sanon
Revision: 10
Title:= = A Simple Anonymous GSS-API Mechanism
Document = date: = 2020-04-15
Group: Individual Submission
Pages:= = 11
URL: =            https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-10.= txt
Status: =         https://datatracker.ietf.org/doc/draft-howard-gss-sanon/Htmlized:       https://tools.ietf.org/html/draft-howard-gss-sanon-10
Htmlized:       https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-10

Abstract:
=   This document defines protocols, procedures and conventions = for a
  Generic Security Service Application = Program Interface (GSS-API)
  security = mechanism that provides key agreement without authentication
  of either party.




Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



= --Apple-Mail=_789302BC-0C7B-4D5F-A7B8-5F1872747666-- From nobody Sun Apr 19 18:38:16 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05133A0BC4 for ; Sun, 19 Apr 2020 18:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1L2IU69pOYR for ; Sun, 19 Apr 2020 18:38:12 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2703D3A0BC9 for ; Sun, 19 Apr 2020 18:38:03 -0700 (PDT) Received: by us.padl.com with ESMTP id 03K1buJW017166; Mon, 20 Apr 2020 01:38:01 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 03K1buJW017166 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1587346682; bh=EP6XFv+c3lnjLvPfE6Jp+YEsL7GT0nlUZjbnbrhfMSY=; h=From:Subject:References:To:Date:From; b=Ef4Q9F4p8s7jSBe/sRee+7ZijD5Mz+znVf/8Av0qGx5UStR8eT5P/CbjvH+yfF5wb QDU82wJLETTfPOcZQrAhAZpDjAxTiHjFntfTAqRniPIf/k8MN6eC1omYr2NfZdKVJK qRqqTsCSNPf0fExK36pkHhCRsk0zc/TMZd0Bao0gFMDrxj9Q6qeaWIrgb0lcvs3mNH F9eiq1yXS1WA38YQeEexnLQVfyjSrrpIbPwc6QkAimOzvnQbzVSRYoyVguB321Ae3f AyXVGN0+p5DJ4lW9L999bmJ8ubSWhKYZf1gKKVSbsMtrNFdGnzIZukhTDSFHxUMiyU 7psMwpXlgsV8w== From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_6FA07B01-04AC-4395-B397-E3487E1E9BE6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: References: <158734662573.23649.14049542460915736319@ietfa.amsl.com> To: "kitten@ietf.org" Date: Mon, 20 Apr 2020 11:37:55 +1000 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [kitten] Fwd: New Version Notification for draft-howard-gss-sanon-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 01:38:15 -0000 --Apple-Mail=_6FA07B01-04AC-4395-B397-E3487E1E9BE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii More cleanups. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-howard-gss-sanon-11.txt > Date: 20 April 2020 at 11:37:05 am AEST > To: "Luke Howard" >=20 >=20 > A new version of I-D, draft-howard-gss-sanon-11.txt > has been successfully submitted by Luke Howard and posted to the > IETF repository. >=20 > Name: draft-howard-gss-sanon > Revision: 11 > Title: A Simple Anonymous GSS-API Mechanism > Document date: 2020-04-20 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-11.txt > Status: = https://datatracker.ietf.org/doc/draft-howard-gss-sanon/ > Htmlized: https://tools.ietf.org/html/draft-howard-gss-sanon-11 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-11 >=20 > Abstract: > This document defines protocols, procedures and conventions for a > Generic Security Service Application Program Interface (GSS-API) > security mechanism that provides key agreement without = authentication > of either party. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_6FA07B01-04AC-4395-B397-E3487E1E9BE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii More = cleanups.

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-howard-gss-sanon-11.txt
Date: = 20 April 2020 at 11:37:05 am = AEST
To: = "Luke Howard" <lukeh@padl.com>

A new version of I-D, draft-howard-gss-sanon-11.txt
has been successfully submitted by Luke Howard and posted to = the
IETF repository.

Name: = draft-howard-gss-sanon
Revision: 11
Title:= = A Simple Anonymous GSS-API Mechanism
Document = date: = 2020-04-20
Group: Individual Submission
Pages:= = 11
URL: =            https://www.ietf.org/internet-drafts/draft-howard-gss-sanon-11.= txt
Status: =         https://datatracker.ietf.org/doc/draft-howard-gss-sanon/Htmlized:       https://tools.ietf.org/html/draft-howard-gss-sanon-11
Htmlized:       https://datatracker.ietf.org/doc/html/draft-howard-gss-sanon
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-howard-gss-sanon-11

Abstract:
=   This document defines protocols, procedures and conventions = for a
  Generic Security Service Application = Program Interface (GSS-API)
  security = mechanism that provides key agreement without authentication
  of either party.




Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



= --Apple-Mail=_6FA07B01-04AC-4395-B397-E3487E1E9BE6-- From nobody Tue Apr 21 14:33:23 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0283A0A84 for ; Tue, 21 Apr 2020 14:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=josefsson.org 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 lIf9exFCA-qD for ; Tue, 21 Apr 2020 14:33:17 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b1:8633::105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE2D3A0AB7 for ; Tue, 21 Apr 2020 14:33:16 -0700 (PDT) Received: from latte (31-208-42-58.cust.bredband2.com [31.208.42.58]) (authenticated bits=0) by duva.sjd.se (8.15.2/8.15.2/Debian-8) with ESMTPSA id 03LLX0ww023952 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Apr 2020 21:33:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=josefsson.org; s=default; t=1587504784; bh=2BZVtNAexVL88Fk9xb8PkOszJQOEraK8prBFBt8xTNs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Gb/PLsnIN3xdo7gAF/LakNfOalsHvRhTdKVGwkwAO9q2kDAcG+C/lR/Fs3eFJ218F 7mSfBFvXvhuJlc9PeAXMoe+17e+2NoHZIqfwoIgxop7Ev8ll+WTnybW0pBcegQyGCW bfSPhyyLTu29tJ9cG9lW1i6vcj7S5CaohaXlEFNYHC4orrB5ZIZNTAyZfeTkceAjsI 6h6o2qB9O2vu38zRvj6rRF6kxI1JStsMn3boXW4hU7dhbFOVYMDZhguQp2QU0/kq3y 6x555MYo1YZ/E1hE2RhAs+v/Ibg4IdAP+aucJsWRRqj3M6mO9kdIPXqaAd9CYvJB3x qhqrYFw2IH9Tw== From: Simon Josefsson To: Rick van Rein Cc: "kitten\@ietf.org" References: <5E8F1ED9.1020108@openfortress.nl> OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt X-Hashcash: 1:22:200421:rick@openfortress.nl::q8vdhlbfvCNiC5e5:980z X-Hashcash: 1:22:200421:kitten@ietf.org::+njj1wvlI6GHKKyn:Ta14 Date: Tue, 21 Apr 2020 23:33:00 +0200 In-Reply-To: <5E8F1ED9.1020108@openfortress.nl> (Rick van Rein's message of "Thu, 09 Apr 2020 15:10:49 +0200") Message-ID: <87zhb4jzhv.fsf@latte.josefsson.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.102.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: Re: [kitten] SASL, how to choose the type of channel binding? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 21:33:22 -0000 --=-=-= Content-Type: text/plain Rick van Rein writes: > Hello, > > I can see that the GS2 negotiates *whether* to use channel binding, but > how can a client and server agree on *which* form to use? Practically it is hard-coded to 'tls-unique' that, alas, has security issues. See RFC 7627. GS2 does not provide any facility to (reliably) negotiate which channel binding type to use, that negotiation has to come from the SASL application protocol or out-of-band. See section 5.2 of the document. I don't recall any SASL application protocols that provide this feature -- does anyone know of any example? I believe this is one of the serious problems with GS2, that some day could warrant an update of it. The problem can be resolved in the same way as RFC 7677 did for SCRAM's use of insecure tls-unique. Another solution is to hard code a channel binding that has better secure properties -- perhaps a revised version of https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 /Simon 5.2. Default Channel Binding A default channel binding type agreement process for all SASL application protocols that do not provide their own channel binding type agreement is provided as follows. 'tls-unique' is the default channel binding type for any application that doesn't specify one. Servers MUST implement the "tls-unique" [RFC5929] channel binding type, if they implement any channel binding. Clients SHOULD implement the "tls-unique" channel binding type, if they implement any channel binding. Clients and servers SHOULD choose the highest- layer/innermost end-to-end TLS channel as the channel to which to bind. Servers MUST choose the channel binding type indicated by the client, or fail authentication if they don't support it. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSjzJyHC50xCrrUzy9RcisI/kdFogUCXp9mjAAKCRBRcisI/kdF onhiAP4os8aOeOz+W+kDxzsGX7ffSanjP5XW+3p+ZZC/Xwx6jQEAy6+n+9zJ2pDW uUzpifxqaKAWw2gSaXt3JAsVNIKcIwA= =do3z -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 21 15:13:16 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B553A0C35 for ; Tue, 21 Apr 2020 15:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 mhuy8BvBsETv for ; Tue, 21 Apr 2020 15:13:10 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1A43A0C40 for ; Tue, 21 Apr 2020 15:13:01 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id f13so45617wrm.13 for ; Tue, 21 Apr 2020 15:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wTH/rw7oTTg3BVKKDpcbJF2jnHJYHuxiyXGNrY0subg=; b=Mmx7/fBcuJ0j/33yChYM9fcTh95la1oqVaoaYUGLmNVrtirenE5dwrCRaccVT5l4aQ J3DTJBv6rDWUK4MMuAIsuCaonZdZIkGhM5i018XyEZtkYJ9GWxw5EgaK0IbyvrjVTUe/ Tx7mQClZCngLYYO2JVEMnadbqjqtra+gB+6Vc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wTH/rw7oTTg3BVKKDpcbJF2jnHJYHuxiyXGNrY0subg=; b=DbucIofDNmJB5EPvZGWssdJQf/VxxpoNjEqhnRniwO9z1qtoFyX52FSwsZesmOoPku VZmNXh5W5vrx88slhl5DGkscD82lFMSjt01fOd2qs4X2t4VgKJ7RReT/e2iA9U5vhb8R oNY8XvT5mK0JFS2EJyzRlG8EhBCRtMRMkNVIMk72dVtm5dOtPyiIOM2BEdEOpSdpzxfZ 8JwdzAtjInfQAYx8n1kiZnwZjgdXxXa/XRMVBdIS/nvcvMIRW8juHcuMV0rv7Igqk/0E fhfP1yfyhuh4U4FrSkN2TYaW9vCPQfk17Mfhv0Qr2RWyynMNEx4r6aBiWo3Hq28lrXOx hvCA== X-Gm-Message-State: AGi0PuafvDgE0jpvnBf9zLwX9hzikVAYCqFGPUmnCPY0LruKtjJTjCMF k8+IXKqDJB9+hM5qAW/paVn/EOLdxrvnMP9AS+awbjdvgXc= X-Google-Smtp-Source: APiQypIrw//I5sRDPz9x+o4hko2aK9Zi4qDhsnJx6v3qWD0bssmzZj/OJM1hlzj+p53L8qCSx5ha06DE0aNRIeYoxxg= X-Received: by 2002:a5d:4b04:: with SMTP id v4mr27698643wrq.358.1587507179694; Tue, 21 Apr 2020 15:12:59 -0700 (PDT) MIME-Version: 1.0 References: <5E8F1ED9.1020108@openfortress.nl> <87zhb4jzhv.fsf@latte.josefsson.org> In-Reply-To: <87zhb4jzhv.fsf@latte.josefsson.org> From: Dave Cridland Date: Tue, 21 Apr 2020 23:12:48 +0100 Message-ID: To: Simon Josefsson Cc: Rick van Rein , "kitten@ietf.org" Content-Type: multipart/alternative; boundary="00000000000086478a05a3d45132" Archived-At: Subject: Re: [kitten] SASL, how to choose the type of channel binding? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 22:13:14 -0000 --00000000000086478a05a3d45132 Content-Type: text/plain; charset="UTF-8" On Tue, 21 Apr 2020 at 22:33, Simon Josefsson wrote: > Rick van Rein writes: > > > Hello, > > > > I can see that the GS2 negotiates *whether* to use channel binding, but > > how can a client and server agree on *which* form to use? > > Practically it is hard-coded to 'tls-unique' that, alas, has security > issues. See RFC 7627. GS2 does not provide any facility to (reliably) > negotiate which channel binding type to use, that negotiation has to > come from the SASL application protocol or out-of-band. See section 5.2 > of the document. I don't recall any SASL application protocols that > provide this feature -- does anyone know of any example? > No, but the XMPP community uses channel bindings quite heavily (or at least, more so than anywhere else I've noticed). If you feel like throwing a XEP (or an I-D) toward the XSF on negotiation of channel bindings (should be a simple stream feature), you might find some interest there. Dave. --00000000000086478a05a3d45132 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 21 Apr 2020 at 22:33, Simon J= osefsson <simon=3D40jo= sefsson.org@dmarc.ietf.org> wrote:
Rick van Rein <rick@openfortress.nl> writes:

> Hello,
>
> I can see that the GS2 negotiates *whether* to use channel binding, bu= t
> how can a client and server agree on *which* form to use?

Practically it is hard-coded to 'tls-unique' that, alas, has securi= ty
issues.=C2=A0 See RFC 7627.=C2=A0 GS2 does not provide any facility to (rel= iably)
negotiate which channel binding type to use, that negotiation has to
come from the SASL application protocol or out-of-band.=C2=A0 See section 5= .2
of the document.=C2=A0 I don't recall any SASL application protocols th= at
provide this feature -- does anyone know of any example?

No, but the XMPP community uses channel bindings quite he= avily (or at least, more so than anywhere else I've noticed).

If you feel like throwing a XEP (or an I-D) toward the XSF = on negotiation of channel bindings (should be a simple stream feature), you= might find some interest there.

Dave.
= --00000000000086478a05a3d45132-- From nobody Wed Apr 22 03:30:11 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBC13A0772 for ; Wed, 22 Apr 2020 03:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl 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 FCa7wPxZPMPy for ; Wed, 22 Apr 2020 03:30:05 -0700 (PDT) Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C1A3A0768 for ; Wed, 22 Apr 2020 03:30:04 -0700 (PDT) Received: from popmini.vanrein.org ([IPv6:2001:980:93a5:1::7]) by smtp-cloud8.xs4all.net with ESMTP id RCdjju0DWlKa1RCdkj7RA3; Wed, 22 Apr 2020 12:30:00 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1587551399; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=KKBEMsxdBvYfWQcM8lm0B8bd8RkfVs30AkRoqFG1gzQ=; b=M8rSRxPK04eBDe5e7PraF/5WyH9WrPvX40ZY0wfUW+g6PVMwQXPpg/kR Wu4HP37QxYLHyDINw151unJr97gTmm4HD4Ja5w3kczcytqLqUUisa4pmzX aAl6YTH2tYiprWlxB3j7Tx/cXXizH1/u8DgcruPi8E8AVeszu2TOSCutE= Received: by fame.vanrein.org (Postfix, from userid 1006) id 5081C3A468; Wed, 22 Apr 2020 10:29:59 +0000 (UTC) X-Original-To: kitten@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id E677B3A464; Wed, 22 Apr 2020 10:29:55 +0000 (UTC) Message-ID: <5EA01CA2.2020702@openfortress.nl> Date: Wed, 22 Apr 2020 12:29:54 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Simon Josefsson CC: "kitten@ietf.org" References: <5E8F1ED9.1020108@openfortress.nl> <87zhb4jzhv.fsf@latte.josefsson.org> In-Reply-To: <87zhb4jzhv.fsf@latte.josefsson.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfBuDsx8j14WmszX09TIlFyWve7IUt1jLue5DtoMBbH6azjrfkCwaKEmadtZUiQqMe2krxVoZSmPUK8hvirzBZeeXyiTkizBAdeT0xOYJz4bS5x8TKsc9 By7iV1Uzj9PhqmwzxKjEPexosHeVbtz8QEg8ncfEE/C4OrwxzCwsBlgSB12PJJ6ccXJAsJO/XU5fZQ== Archived-At: Subject: Re: [kitten] SASL, how to choose the type of channel binding? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 10:30:10 -0000 Hello, > Practically it is hard-coded to 'tls-unique' that, alas, has security > issues. See RFC 7627. You mean that it requires extended master secrets to be reliable, right? AFAIK that has been fixed most everywhere? > GS2 does not provide any facility to (reliably) > negotiate which channel binding type to use, that negotiation has to > come from the SASL application protocol or out-of-band. Yes, that is the sort of thing I was also thinking of. It's resolved in the place where I want to use it --an encrypting wrapper around a SASL exchange to support forwarding it-- by incorporating the GS2 header into the key computions. (Current spec does not do this yet.) > See section 5.2 > of the document. I don't recall any SASL application protocols that > provide this feature -- does anyone know of any example? Coming up :-) I need it to support realm crossover, which I am developing in draft-vanrein-diameter-sasl which we have working, though not stable enough to demo. > I believe this is one of the serious problems with GS2, that some day > could warrant an update of it. The problem can be resolved in the same > way as RFC 7677 did for SCRAM's use of insecure tls-unique. Another > solution is to hard code a channel binding that has better secure > properties -- perhaps a revised version of > https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 Well, with channel binding modifying the computation there would at least be a detection if the SASL client and server don't agree. And with the server aware of offering a non-PLUS mechanism, it should be prepared to see clients not requesting channel binding. Intermediates could only cause degredation if both client and server are willing to adopt the level of security without channel binding. Thanks, -Rick From nobody Thu Apr 23 10:33:13 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7A43A09DF; Thu, 23 Apr 2020 10:33:10 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVIhY1W3RhjL; Thu, 23 Apr 2020 10:33:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B613A09C4; Thu, 23 Apr 2020 10:33:03 -0700 (PDT) Received: from [18.30.10.110] ([18.30.10.110]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03NHWq9w001785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 23 Apr 2020 13:33:02 -0400 To: Benjamin Kaduk , draft-ietf-kitten-krb-spake-preauth.all@ietf.org Cc: kitten@ietf.org References: <20190404235859.GM54777@kduck.mit.edu> From: Greg Hudson Openpgp: preference=signencrypt Autocrypt: addr=ghudson@mit.edu; keydata= xsFNBFLMQYIBEADZLNv8Jpeo2d4XSLE+k6m1VD2iOyX66wErZKaQpYrGB/leWKfz8l6c3pWd iVUnCoyxKlhRuGVArszdh2wUSRgHnMl86JC/vIdawdOdbnlTVfOJTiP3EfycsMUUDG6GckLY e+xxo7sM/bpXpGkbIWc0Ec/vbQt67eeW2En1AqL+ezJdVN9XL8icH2Hu6HlqxGgleC5H0yAi kM4yvNjo5z2M/Dr/x63bLcIdKkSRPzd0OaBg2g0Yh651eYpPu0e1Gi6785ZBjV4bnv3K5oLo 5XsiHIZ60maHWTEyMO/byw4aS2cCWIovXurvz699KSF83B296+xhsFhhz4+kbQgXvJt4kIoI pdpX6xbIkeVlc+FuUbyE8MUGveA3TFHXZ4+0f2tvTekey/62FOeXnrqc4NsBViir3zGTXAqC 7PQTNnX/86jyW+9SnJo9XbSBB3NV0K5I2o1cDzqRPqy/4fsoq8SxQwRga0CSId1PzE9PUEUY V0FCldo9LvPsUK9YE7AuwC+bcQiVLah5TF+5Kk7yLSaRxzQ3fI5lcqk5UPUqMLa87cRBdnal niuHVg0u3W22RMPkWe2iPIYYdr4TQDzCkD2JXpXNaZ3KipVT5aqowwfPEt7b6ti0vjrOInij YzFmVNMGKYabwh2zxKWQQ8GO5mUVu09CSe33H4EW7pDP+zHr2wARAQABzR1HcmVnIEh1ZHNv biA8Z2h1ZHNvbkBtaXQuZWR1PsLBeAQTAQIAIgUCUsxBggIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AACgkQDLoIV1+Dct8dZBAA1Mtoq1RPuUQg6hL2qFjwTEXeonWq8czkQ1fNNzO9 x8I3VLn5L6CmWeAmxRU1DD0qZ5HL24+Mwnvy/eazp4/CSgiPC52KfbNsnQtg/E+8ruFQVHA/ 3HZXuCT/Nz4s06N3fMZrJLCGNEHRD0S43kb2GGboVY3ykO3FbPJB/DxDqtIMqt6B1SZ87UAR CVsRc296X3TsF9BgoQ/n54XfYAzrACkuIH9biHmH6wB1eykCeuhkCsu5Zf/tlSXJCFiuhvS+ CX2EbNKF+0MLcGAavSzbjTnQw3kv8unSgecbEQ7A8ibGx6Jwgnvy0gzu6w4prhR40pVYDcL+ sKsmQg6jo/uPvGdEqHISFSK8FxGGAonaAwg0014bXLaPo2MckcZ+szcHA/z4vpTdB1vChexL omM5ZTeSJaFfeYsspv8sq6EL1x21c7A+ngCmB70/OZR6dcgf9/ILmcjBiYfJHYukXTIvGT6y QJbok19So8RJKUYjzzHDKBweg8x6HdIrdy7HTcLzsqY9PFGg7/YlbLlGQwYXhK1b4uBmWyE7 I/402+57I1YpMYND7vsTmJuE13Gv5ZGhYn5pSzX9ZTWY13LgGymkWBXPxfefkHKTV9ROCGEL t7SV3Nf7ZsCGLRGmDT6oqLz75/IrhKEcHIfD4ct+QvIm6pvPNvikQMwPWSd52GazILLOwU0E UsxBggEQAKaz/wX8nsSUaivmwW4NVlbmTsErHUt9iNHm9CmieuoDv1o8qUqEV6RiONIs0q5Y +dcooazhHRNpjAST2rbQFBZebfpVRKYAGzHoZEQ6OV8Eao+NjAGazS8RuwIxpeZ36r3AyVhe TAIvIzwpQFDNKTIUNbXctHrZ157TlxDuKwZ3+Yw/bhQE5YGrSLm17wIMcY3UHiE1mO5X0ohR dDeTf93PignUUvWvRRQLyxRGsBLz/CCwmCJZeu/FjnDk8HkEbAlmFAJ+YZu9rQ40vU6Z40KY L5U9PIn0FdSxviK7mys+VbFYV6mXWXZN8dOkHuG6zSdmobE90G6ZzAPcI4cyql63N+kUOb3b hGI/Wvn6tUbWeIc8UvQGpYb0+eOKHQBNKUOq5RV98hZorZRCu2W2RzZSxiufyONvtonbUtYs BMdw+gqUpK0ir782lc3cKbj+X5iiyg3ZGvBmTU6FN/MiX6MnTyEwOScFboKe6vB8ZgwII85K n9qlSI3xH56JBXamMP0yqJf57q0WfP8V7lFtm8SmhU2NQyP3wRYDm2+bLTNCmRPJN2ZUgkTx c/Qjov8TeeiTfX9S3ea/GJOdgA1mQfSkmUoOWROnwDBbKGBXNzkkoJna8j/zWgo/mQ5gNdIu HXcIdDKbyyhVH3+DwxXYWyYP/pnIk3AVCss75dXcdStfABEBAAHCwV8EGAECAAkFAlLMQYIC GwwACgkQDLoIV1+Dct+oSA/9HyTkr+UQbaucXE9pP87yasObKCBxYhoeRjzBhgtYUtSDuH2o xl5M3wmTNOooQSa8R1ljhax9v02pqspIA9hyGjGjvZ6jPydDsANNcohdbMjCzXNdrCF5149w gbGQ07rkc5JNyajzxH4GE/BXclTzwTYAaHvYM5PEQLDhmubK3M/kBvjWpZxLAJAobMi/jVwQ cmai+N56X9Ht/FVIQlmCuXoMAE9ScVWFaq8JnCo9VZ0G045NcxdEoQXVUXb3E5cmZ0Ld9sUm SKSJKjYWjfE4c/8oylZuo9LDTwozBEp/jsASjL0g8F3QJsQUkFkKROd45xHcIkFulshS3xkG gMu6UduV2ypPz987f+0wdVwx+KYnmnUB83gxqVucFRxfZZXiUHUml4rJ7Ww2+//H9FFPfw9f aPMg7nLFm2T0to3pwgyisLH/aThzW3TY7CZ7gkvMDtbo9EHrN4Nl3onuOtOKQpIMbFVqX4YZ m6znSLuUiWDUd8rvQfz+4ndZKIFOG1YIKwQBV8tN1RYBGY9bhv2Wtt5X6SKIzkUhDdgeyzci MC1M3N0Pqoqrms7FdBKAd0BE7puhQ24U42APss+Ur6WyRZMQTKc41SZWfrWV30agytUVdtRu gxERw74qeGAz6o3if42vI6u30SR6OCLMMSobqKc7HQvJ2qv3Z6j9kt1zXiE= Message-ID: <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu> Date: Thu, 23 Apr 2020 13:32:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20190404235859.GM54777@kduck.mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 17:33:11 -0000 Ben sent feedback on the SPAKE preauth draft a little over a year ago. I deferred acting on the smaller feedback items at the time, while observing the CFRG's progress on PAKE algorithms. The CFRG has selected CPace over SPAKE2 for a balanced PAKE. As such I doubt there will be a need for a CFRG SPAKE2 document. At this time I don't think there would be sufficient interest in retooling the Kerberos preauth mechanism for CPace, or making breaking changes. I have prepared changes to draft-ietf-kitten-krb-spake-preauth to drop its dependency on draft-irtf-cfrg-spake2, instead referring informatively to the Abdalla/Pointcheval paper and describing the group operations explicitly. These changes, as well as updates addressing the smaller feedback items, are at https://github.com/greghudson/ietf/commit/6ecf1b9dfacc804692d858c726888855a512b8b7 . I will update the draft unless it seems like there isn't WG consensus on this direction. Some responses to a few of the smaller feedback items: On 4/4/19 7:58 PM, Benjamin Kaduk wrote: > The client and KDC will update the transcript hash with the pubkey > value, and use the resulting hash for all encryption key derivations. > > Isn't it the whole message and not just the pubkey value? It's just the pubkey value. The rest of the message is an encrypted field, and we need to finalize the transcript hash before deriving a key to encrypt with. > 1. Determine the length of the multiplier octet string as defined in > the IANA "Kerberos SPAKE Groups" registry created by this > document. > > If this multiplier length ended up being smaller than the key width for > the initial reply key, it seems like we'd end up losing security > strength. Key derivation does a KRB-FX-CF2 with the initial reply key, for exactly this reason. I don't think we need to call it out. > First, the hash function associated with the selected group is > computed over the concatenation of the following values: > > Do we want to include the client/server principal names here as well, as > suggested by draft-irtf-cfrg-spake2-08? Client and server principal names are included in the KDC-REQ-BODY, which is one of the hashed elements. > o The SPAKE result K, converted to an octet string as specified in > Section 5. > > I failed to convince myself that I saw where this conversion was > specified in Section 5. Could you help me out? First paragraph. Admittedly it's just subcontracting out to the registry. > The KDC-REQ-BODY contents are also incorporated > into key derivation, ensuring their integrity. The unauthenticated > plaintext in the KDC-REP message is not protected by this mechanism. > > Do we want to have a short note about how this is not expected to cause > problems (as it's the default state for all KDC exchanges)? I think it would be hard to say anything correct without descending into a rathole. There are some problems with unauthenticated plaintext in KDC-REP, which are addressed by implementations in kind of a patchwork way, and this preauth mechanism does not improve on that situation. > Subsequent factor data, including the data in the response, are > encrypted in a derivative of the shared secret K. Therefore, it is > not possible to exploit the untrustworthiness of the challenge to > turn the client into an encryption or signing oracle, unless the > attacker knows the client's long-term key. > > I'd consider adding a note "in which case the attacker does not need an > external oracle to encrypt or sign using that key". That would be incorrect; as this section is talking about the factor challenge, it is talking about an encryption or signing oracle for the factor credentials, not for the long-term key. > We discuss replay of cookie values by attackers, but don't really talk > about the related possibility of splicing cookie values across SPAKE > exchanges. E.g., if an attacker observes two simultaneous requests and > swaps the cookies between the two before forwarding to the KDC. It does talk about that ("SHOULD prevent cookie values from being applied to other pre-authentication mechanisms or other client principals"), but I made it a little more explicit. > Although this pre-authentication mechanism is designed to prevent an > offline dictionary attack by an active attacker posing as the KDC, > such an attacker can attempt to downgrade the client to encrypted > timestamp. [...] > > Maybe "or similar preauthentication mechanisms"? There isn't a big unknown supply of Kerberos preauth mechanisms. This is specifically about encrypted timestamp. > Section 10.6 > > Is there much that a KDC can do in the face of such an attack? Will > forcing fallback to the full SPAKE exchange help at all (e.g., with > proof of return routability)? We can't really suggest reusing ephemeral > key shares to reduce that part of the load. draft-irtf-cfrg-spake explicitly forbade all reuse of ephemeral values, but I think it is actually safe to reuse a public key for a client. (That is, reusing the private multiplier x across clients is bad, but reusing T=xP+wM for a specific client is okay.) I didnt change this section, but with the CFRG draft out of the picture, we could perhaps suggest public key reuse as a load mitigation strategy. > In addition to potentially allocating a new value for the RFC version of > this spec, we probably also want to say a bit more about the > registration procedures. Should requestors send the request directly to > the list, or to IANA first and IANA sends to the list? Is the list > publicly archived (and can anyone sign up as a member)? I'm a little lost here. The mailing list was Nathaniel's idea and I am not attached to it. There are hundreds of IANA registries; it seems like we should be picking from a few best practices for update procedures rather than breaking ground. > o Serialization: [SEC1] section 2.3.3 (compressed). > > I'd use a couple more words, e.g., "this specification uses the > 'compressed' point format". (multiple occurrences) Is there really any ambiguity in just saying "compressed"? Terseness is of value here. [Regarding test vectors:] > We use lowercase 'w' for both the PRF+ output and the reduced > multiplier; could we maybe use the majuscule form for one to > disambiguate? We use uppercase letters for group elements, so that would be confusing. The PRF+ output is an intermediate value that I thought would be useful to implementors. I think the test vectors are pretty clear in their current form. From nobody Sat Apr 25 20:46:18 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085143A0A8F for ; Sat, 25 Apr 2020 20:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjVtTlFndoiR for ; Sat, 25 Apr 2020 20:46:12 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4803A0A83 for ; Sat, 25 Apr 2020 20:46:12 -0700 (PDT) Received: by us.padl.com with ESMTP id 03Q3k2YH018524; Sun, 26 Apr 2020 03:46:08 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 03Q3k2YH018524 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1587872769; bh=sQ1oPSsJo96qJpz85vGrmlf4/gF/z32wfJ5MzC5ySoI=; h=From:Subject:Date:To:From; b=vI3JEKYxpUgYrgLmNc0TcriMxxDh5DW+iaIyg2cav3XKQxYj7buq7DugB37AAfiUV sHLWtjdsbXvk6+JkflUDc8sJ8n9WbVuOibPqSwuMsEe6KJtBdQCOIIGTsUmrdLL/2b SZWfDSMM2pMHrITJlQrUezdcbsbizfTr0AqnddbQyYz2bVB6nc6MQ7/1Pxjmf9B4aB 9kRXVAlWrk6Cv9nxl2s+VyrZIlG0wOBn+TqqKvEuwK0o64k36lnvzreHWDYcfLBRL1 Rojs1dN7J5ItEfK+BZeXAuTuofNz4vpFRV3bgAtAl1zzH4i+k20OU5aVHnR3zDIp1s NBUYH3bi556bw== From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_246BE9B2-8B96-4BB8-A4EB-C46621655D3C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <5822327E-C113-447B-AAB8-34902F585566@padl.com> Date: Sun, 26 Apr 2020 13:46:01 +1000 To: "kitten@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [kitten] SAnon kitten adoption X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 03:46:16 -0000 --Apple-Mail=_246BE9B2-8B96-4BB8-A4EB-C46621655D3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, Have addressed a few things in the most recent SAnon draft =E2=80=93 https://tools.ietf.org/html/draft-howard-gss-sanon-12 = Is there any interest in seeing this adopted by Kitten? Cheers, Luke Luke Howard web / facebook = / instagram = / spotify = = --Apple-Mail=_246BE9B2-8B96-4BB8-A4EB-C46621655D3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = everyone,

Have = addressed a few things in the most recent SAnon draft =E2=80=93

https://tools.ietf.org/html/draft-howard-gss-sanon-12
=

Is there any = interest in seeing this adopted by Kitten?

Cheers,
Luke

Luke = Howard
web / facebook / instagram / spotify
= --Apple-Mail=_246BE9B2-8B96-4BB8-A4EB-C46621655D3C-- From nobody Sat Apr 25 21:02:25 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD3E3A0B14 for ; Sat, 25 Apr 2020 21:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secure-endpoints.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVi9cZxRSVpT for ; Sat, 25 Apr 2020 21:02:21 -0700 (PDT) Received: from secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60FB73A08EC for ; Sat, 25 Apr 2020 21:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=secure-endpoints.com; s=MDaemon; t=1587873740; x=1588478540; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Organization:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; bh=0UUQC/j2jWG66oj62vP9BE 2NPminqLuHdIgwqCdYvYs=; b=bAV+6L7yQeYYnRrvXQlmls1YYjoIBymtDf+5+H IgDObGuEL8XiR3H6YbfFi1kIkvpjNSCdkJ+uPHn4NIwps8ufDclAfaLwPk8nL9Oj UnBHCgYE2269XMM0hxBbRal6ORg7/cFEMp3O+iJsOuz2qlK3Uje46UYHSpGR0HKL KYllI= X-MDAV-Result: clean X-MDAV-Processed: secure-endpoints.com, Sun, 26 Apr 2020 00:02:20 -0400 Received: from [IPv6:2604:2000:1741:a0c7:8c96:1d23:7aca:ca58] by secure-endpoints.com (IPv6:2001:470:1f07:f77:28d9:68fb:855d:c2a5) (MDaemon PRO v20.0.0gm2) with ESMTPSA id md5001002434524.msg; Sun, 26 Apr 2020 00:02:19 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-Spam-Processed: secure-endpoints.com, Sun, 26 Apr 2020 00:02:19 -0400 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 2604:2000:1741:a0c7:8c96:1d23:7aca:ca58 X-MDHelo: [IPv6:2604:2000:1741:a0c7:8c96:1d23:7aca:ca58] X-MDArrival-Date: Sun, 26 Apr 2020 00:02:19 -0400 X-MDOrigin-Country: United States, North America X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1385d683c1=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: kitten@ietf.org References: <5822327E-C113-447B-AAB8-34902F585566@padl.com> From: Jeffrey Altman Organization: Secure Endpoints Inc. Message-ID: <0674f16b-742c-8e4b-ee56-7112242684ed@secure-endpoints.com> Date: Sun, 26 Apr 2020 00:02:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <5822327E-C113-447B-AAB8-34902F585566@padl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010300050303070908080408" X-MDCFSigsAdded: secure-endpoints.com Archived-At: Subject: Re: [kitten] SAnon kitten adoption X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 04:02:24 -0000 This is a cryptographically signed message in MIME format. --------------ms010300050303070908080408 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable SAnon will be implemented in Heimdal. I would be interested in seeing it adaopted by Kitten as a standards track document. Jeffrey Altman On 4/25/2020 11:46 PM, Luke Howard wrote: > Hi everyone, >=20 > Have addressed a few things in the most recent SAnon draft =E2=80=93 >=20 > https://tools.ietf.org/html/draft-howard-gss-sanon-12 >=20 > Is there any interest in seeing this adopted by Kitten? >=20 > Cheers, > Luke >=20 > Luke Howard > web =C2=A0/=C2=A0facebook > =C2=A0/=C2=A0instagram > =C2=A0/=C2=A0spotify > >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 --------------ms010300050303070908080408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJowggYBMIIE6aADAgECAhBAAWz+KYD2VMyFQOAs831nMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE5MDkwNDIxMjM0OFoXDTIyMTEwMjIxMjM0OFowgZUxNTAzBgNVBAsMLFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMSswKQYJKoZIhvcNAQkBFhxq YWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMS8wLQYKCZImiZPyLGQBARMfQTAxNDEwRDAw MDAwMTZDRkUyOTgwRTQwMDAwMzlFQjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALRdw150e8iZjFFewsrI/Q5nQtYINFrVpOdYR5RnrrNUvwRrBkkYcFwNWP/wzHOPiaFgthaX ydoQXKqFH0gZ6EaipfJ1L/r8NKAELVf1mTY7Yw+M6EuApsT9X8Ix6DPyhRc9D/rZ4KuBaszA gdpqdBYkkNlcogKPuM6jCzCHfOW3l9Hj1P98GjLmvhK7bDV56kz5NP13rFYe8dln9dvAKY/a MS1Ghrmvuu2VudoYgPPMXYWnhtrLhxuvLiGUXrKissrBuh3JedDdmSAPNrKxpgVP2m7TrH3u 4FY+MFO+Vv8Z9aGtz5FRdLObgQpq1IyQfoMBJtgqBeqaCkuQGCSJo/UCAwEAAaOCAqUwggKh MA4GA1UdDwEB/wQEAwIFoDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8v Y29tbWVyY2lhbC5vY3NwLmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxp ZGF0aW9uLmlkZW50cnVzdC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAW gBSkc9rvaTWKdcygGXsIMvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEb BgtghkgBhvkvAAYLATCCAQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVz dC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCB rgyBq1RoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3Jk YW5jZSB3aXRoIApJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3Vu ZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kv dHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVu dHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTIuY3JsMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2Vj dXJlLWVuZHBvaW50cy5jb20wHQYDVR0OBBYEFM/QuJwMCA6dvJZmfEpnpbYkoY3iMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAuAcupiA1Vgby jH7ldWXvQAHFyI3a2WUfHyPlPkVnFdyRKv8Fo4qwZ6xkHq49lnV6kRKVn88CCFCYb4XOpzUl Q0JXqzD+PYpM90MEixEpFZTVhRnnA9ypB87K16Pq2zEGmC6dyKYFQTS6lWiO5g5/xOPnO6mm mz3lRGXMuLKNSwThnR4fQcFJjV/yuJ0wCdFSHPRflxf3dZ44fkd/AFnA/99w+HpONT94ZR6k foemXuAHnYE9FmOotguxzAIcldwrR795fHTDDyRkiRqwVE7lh5YSkX1kImPMYuDTUw21D7HI mEJsb/+b3HGUpRrnrVOl9UXadEunddldgOp7UB2wUzCCBpEwggR5oAMCAQICEQD53lZ/yU0M d3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAy MTgyMjI1MTlaFw0yMzAyMTgyMjI1MTlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQla3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZ oCx3wef1kwC4pQQV2XHk+AKR+7uMvnOCIw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDT QoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO 1HS2Mfk9LnINeyzjxiXU/iENK07YvjBOxbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45 FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdXsaieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQAB o4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNp YWwub2NzcC5pZGVudHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5p ZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTt RBnA0/AGi+6ke75C5yZUyI42djAPBgNVHRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMw ggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUFBwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50 cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlz IFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0 aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRw czovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXgu aHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L2NybC9jb21tZXJjaWFscm9vdGNhMS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJ KoZIhvcNAQELBQADggIBAA3hgq7S+/TrYxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBb PGWvzdkmbSgYgXo8GxuAon9+HLIjNv68BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/ twQJeRfxHg3I+0Sfwp5xs10YF0RobhrsCRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrT A6045zQTKGzb370whliPLFo+hNL6XzEty5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCm KCPIVPq/+9GqggGvtakM5K3VXNc9VtKPU9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7 yE03nh2jLV7XAkcqad9vS4EB4hKjFFsmcwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6 mYkzqrPigPazF2rgYw3lp0B1gSzCRj+jRtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg 6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCm unLMtaZ2vSai7du/VKrg64GGZNAKerEBevjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q /0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJK32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEw TjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMgIQQAFs/imA9lTMhUDgLPN9ZzANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNDI2MDQwMjE3WjAvBgkqhkiG 9w0BCQQxIgQgdow5/nSUS/QqigXqEpVDqEjuqMMOTmfJe9y46UCthdYwXQYJKwYBBAGCNxAE MVAwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVz dElEIENBIEExMgIQQAFs/imA9lTMhUDgLPN9ZzBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkG A1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTIC EEABbP4pgPZUzIVA4CzzfWcwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCVRwxTgncJ0dEqMpuyoit5 +zt+dzt3Jw9WRxMOILorRC3sQ19TljeHUYzLdZr1bG6trhXZzANVfWln5pG768fxYy2lV40k GEsqVL7C/adAmcoatiKY252wddIY8rgjAoZ7cX4nSyXdVaECwzlpFYs+uBbNCl7ZMkXLGKPY aum6ijOf4wcZrlzspaFBlgbTj8iecsxGjtn9FUrMSW09fP7jDlY8ZnUMbNmSzJwYehGq1FGt D9xAvhgQUm6kxq1mlvZClK99kBvvLKQUKQ4zRwi7qNgNjwXtzHIX3f0+XAYGZqu/nWvjAu7y hf+Dd4u3JXxAUuF5s8/OY/RXsdtYc3JDAAAAAAAA --------------ms010300050303070908080408-- From nobody Sat Apr 25 21:41:33 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1109F3A0BEB for ; Sat, 25 Apr 2020 21:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dmGfOQU9U8n for ; Sat, 25 Apr 2020 21:41:29 -0700 (PDT) Received: from caracal.birch.relay.mailchannels.net (caracal.birch.relay.mailchannels.net [23.83.209.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74D73A0BDC for ; Sat, 25 Apr 2020 21:41:28 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 3F72F1E0A6C; Sun, 26 Apr 2020 04:41:28 +0000 (UTC) Received: from pdx1-sub0-mail-a15.g.dreamhost.com (100-96-12-30.trex.outbound.svc.cluster.local [100.96.12.30]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5A2A71E0B2F; Sun, 26 Apr 2020 04:41:27 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a15.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Sun, 26 Apr 2020 04:41:28 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Whistle-Hook: 15d7fd2a78f53c5a_1587876087925_2871634195 X-MC-Loop-Signature: 1587876087925:590612442 X-MC-Ingress-Time: 1587876087924 Received: from pdx1-sub0-mail-a15.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTP id 07E177F0D6; Sat, 25 Apr 2020 21:41:27 -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=E8xMWfX9W/nSq0 LswtrurkkTMac=; b=qlgS+VaOqrJWM4TGqKbO+BpjQwmPhu07PXXTXImgwOqHZQ 59LNF6xkQywQfZfzoq5oLpiwYaEF2nBmw9Oskyqd+jS7SMqIrn/ZiqG3v7EgHzjs f77+4ND4Or8xLIo5HCN3Kyk/piP/02L1zn8nFP9zzk4hXXhYwAxd0AOYUjhas= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 34DB97F0CA; Sat, 25 Apr 2020 21:41:24 -0700 (PDT) Date: Sat, 25 Apr 2020 23:41:22 -0500 X-DH-BACKEND: pdx1-sub0-mail-a15 From: Nico Williams To: Jeffrey Altman Cc: kitten@ietf.org Message-ID: <20200426044120.GD18021@localhost> References: <5822327E-C113-447B-AAB8-34902F585566@padl.com> <0674f16b-742c-8e4b-ee56-7112242684ed@secure-endpoints.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0674f16b-742c-8e4b-ee56-7112242684ed@secure-endpoints.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrheehgdekgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [kitten] SAnon kitten adoption X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 04:41:31 -0000 On Sun, Apr 26, 2020 at 12:02:16AM -0400, Jeffrey Altman wrote: > SAnon will be implemented in Heimdal. I would be interested in seeing > it adaopted by Kitten as a standards track document. Me too. Nico -- From nobody Sun Apr 26 14:14:45 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F5B3A1252; Sun, 26 Apr 2020 14:14:43 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfJePlHgv_Za; Sun, 26 Apr 2020 14:14:41 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C843A1254; Sun, 26 Apr 2020 14:14:40 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03QLEaXa008921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Apr 2020 17:14:38 -0400 Date: Sun, 26 Apr 2020 14:14:35 -0700 From: Benjamin Kaduk To: Greg Hudson Cc: draft-ietf-kitten-krb-spake-preauth.all@ietf.org, kitten@ietf.org Message-ID: <20200426211435.GP27494@kduck.mit.edu> References: <20190404235859.GM54777@kduck.mit.edu> <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 21:14:44 -0000 Hi Greg, On Thu, Apr 23, 2020 at 01:32:52PM -0400, Greg Hudson wrote: > Ben sent feedback on the SPAKE preauth draft a little over a year ago. > I deferred acting on the smaller feedback items at the time, while > observing the CFRG's progress on PAKE algorithms. And that seemed wise at time time. Sadly, I was not able to put much energy into the CFRG SPAKE2 draft over the intervening period... > The CFRG has selected CPace over SPAKE2 for a balanced PAKE. As such I > doubt there will be a need for a CFRG SPAKE2 document. At this time I This remains unclear to me -- at the CFRG interim session last week it was mentioned that since Kenny had stepped down as chair, there was a need to find a new shepherd for the CFRG SPAKE2 document. That at least implies that there is still an intent to publish it. That said, given the delays that have already been incurred on that document, it is seeming pretty reasonable to move ahead with the krb-spake-preauth document without waiting for the CFRG one. > don't think there would be sufficient interest in retooling the Kerberos > preauth mechanism for CPace, or making breaking changes. I have > prepared changes to draft-ietf-kitten-krb-spake-preauth to drop its > dependency on draft-irtf-cfrg-spake2, instead referring informatively to > the Abdalla/Pointcheval paper and describing the group operations > explicitly. > > These changes, as well as updates addressing the smaller feedback items, > are at > https://github.com/greghudson/ietf/commit/6ecf1b9dfacc804692d858c726888855a512b8b7 > . I will update the draft unless it seems like there isn't WG consensus > on this direction. > > Some responses to a few of the smaller feedback items: Not too much left to say here (so skip almost to the end...) > On 4/4/19 7:58 PM, Benjamin Kaduk wrote: > > The client and KDC will update the transcript hash with the pubkey > > value, and use the resulting hash for all encryption key derivations. > > > > Isn't it the whole message and not just the pubkey value? > > It's just the pubkey value. The rest of the message is an encrypted > field, and we need to finalize the transcript hash before deriving a key > to encrypt with. > > 1. Determine the length of the multiplier octet string as defined in > > the IANA "Kerberos SPAKE Groups" registry created by this > > document. > > > > If this multiplier length ended up being smaller than the key width for > > the initial reply key, it seems like we'd end up losing security > > strength. > > Key derivation does a KRB-FX-CF2 with the initial reply key, for exactly > this reason. I don't think we need to call it out. > > > First, the hash function associated with the selected group is > > computed over the concatenation of the following values: > > > > Do we want to include the client/server principal names here as well, as > > suggested by draft-irtf-cfrg-spake2-08? > > Client and server principal names are included in the KDC-REQ-BODY, > which is one of the hashed elements. > > > o The SPAKE result K, converted to an octet string as specified in > > Section 5. > > > > I failed to convince myself that I saw where this conversion was > > specified in Section 5. Could you help me out? > > First paragraph. Admittedly it's just subcontracting out to the registry. > > > The KDC-REQ-BODY contents are also incorporated > > into key derivation, ensuring their integrity. The unauthenticated > > plaintext in the KDC-REP message is not protected by this mechanism. > > > > Do we want to have a short note about how this is not expected to cause > > problems (as it's the default state for all KDC exchanges)? > > I think it would be hard to say anything correct without descending into > a rathole. There are some problems with unauthenticated plaintext in > KDC-REP, which are addressed by implementations in kind of a patchwork > way, and this preauth mechanism does not improve on that situation. > > > Subsequent factor data, including the data in the response, are > > encrypted in a derivative of the shared secret K. Therefore, it is > > not possible to exploit the untrustworthiness of the challenge to > > turn the client into an encryption or signing oracle, unless the > > attacker knows the client's long-term key. > > > > I'd consider adding a note "in which case the attacker does not need an > > external oracle to encrypt or sign using that key". > > That would be incorrect; as this section is talking about the factor > challenge, it is talking about an encryption or signing oracle for the > factor credentials, not for the long-term key. > > > We discuss replay of cookie values by attackers, but don't really talk > > about the related possibility of splicing cookie values across SPAKE > > exchanges. E.g., if an attacker observes two simultaneous requests and > > swaps the cookies between the two before forwarding to the KDC. > > It does talk about that ("SHOULD prevent cookie values from being > applied to other pre-authentication mechanisms or other client > principals"), but I made it a little more explicit. > > > Although this pre-authentication mechanism is designed to prevent an > > offline dictionary attack by an active attacker posing as the KDC, > > such an attacker can attempt to downgrade the client to encrypted > > timestamp. [...] > > > > Maybe "or similar preauthentication mechanisms"? > > There isn't a big unknown supply of Kerberos preauth mechanisms. This > is specifically about encrypted timestamp. > > > Section 10.6 > > > > Is there much that a KDC can do in the face of such an attack? Will > > forcing fallback to the full SPAKE exchange help at all (e.g., with > > proof of return routability)? We can't really suggest reusing ephemeral > > key shares to reduce that part of the load. > > draft-irtf-cfrg-spake explicitly forbade all reuse of ephemeral values, > but I think it is actually safe to reuse a public key for a client. > (That is, reusing the private multiplier x across clients is bad, but > reusing T=xP+wM for a specific client is okay.) I didnt change this > section, but with the CFRG draft out of the picture, we could perhaps > suggest public key reuse as a load mitigation strategy. > > > In addition to potentially allocating a new value for the RFC version of > > this spec, we probably also want to say a bit more about the > > registration procedures. Should requestors send the request directly to > > the list, or to IANA first and IANA sends to the list? Is the list > > publicly archived (and can anyone sign up as a member)? > > I'm a little lost here. The mailing list was Nathaniel's idea and I am > not attached to it. There are hundreds of IANA registries; it seems > like we should be picking from a few best practices for update > procedures rather than breaking ground. Unfortunately (from my vantage) the current field is pretty fragmented and does not have a clear best practice to pick from. E.g., the TLS and JWT registries generally operate on a "requestor sends mail to the designated list without involving IANA", but for things like ports and media-types there's a request form that goes through IANA and then generates discussion on the experts' mailing list. I've been through the creation process for a few registries now where we had to go back and forth with IANA several times after the RFC was approved in order to figure out how the registry was actually supposed to operate, and was hoping to have more of it written down from the start, this time. > > o Serialization: [SEC1] section 2.3.3 (compressed). > > > > I'd use a couple more words, e.g., "this specification uses the > > 'compressed' point format". (multiple occurrences) > > Is there really any ambiguity in just saying "compressed"? Terseness is > of value here. Maybe "compressed format"? I don't want a reader to have to pull the reference to know that the parenthetical is clarifying the section reference as opposed to being a verb indicating some additional procedure applied after the referenced one. That said, I'm not tied to anything specific here and don't insist on a change. > [Regarding test vectors:] > > We use lowercase 'w' for both the PRF+ output and the reduced > > multiplier; could we maybe use the majuscule form for one to > > disambiguate? > > We use uppercase letters for group elements, so that would be confusing. > The PRF+ output is an intermediate value that I thought would be useful > to implementors. I think the test vectors are pretty clear in their > current form. Okay. Thanks for picking this up again, Ben From nobody Mon Apr 27 06:32:17 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5BC3A0A63 for ; Mon, 27 Apr 2020 06:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=pmhjBQPN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YgxSDYsX 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 YUfCt88sUmWS for ; Mon, 27 Apr 2020 06:32:14 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBD13A0A7D for ; Mon, 27 Apr 2020 06:32:14 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5A5BA5C00F7 for ; Mon, 27 Apr 2020 09:32:13 -0400 (EDT) Received: from imap34 ([10.202.2.84]) by compute7.internal (MEProxy); Mon, 27 Apr 2020 09:32:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=mime-version:message-id:date:from:to:subject:content-type :content-transfer-encoding; s=fm2; bh=lJXfgAnG1XdokhB53jvYf9YcWQ VCNyAn3vWB2iYk2xc=; b=pmhjBQPNn5+xPlh5EU1ubWNdgdRdDB3ZFVZ/CcDL5u gUsAvojcLtp4mXMtpdhwe23NZQ+d02J1N9967x3HZGm87M3HVpt1L7Nd+fVTUy9F b9omILTEJg/HBOpJutwoXeGbdZpNwpqXgGIDjCSvlIpX6qNOwCuzCYAHHm/Vc27u 8o/czTg13pkc/7uLKtBGo4/t1ybLUnMphRZkag7agKFF7cRhUqVJrl+nR9ekXOXK Z1L9tICCvpO/ztrK3DF16QvTnqTF57LoTlkE8RAXb8vcrRECTbJB8HCFpaZjcveM FQiLtnYLAKLLOuwy6Gs991cXhxdKdKr25KLTSC5P+EMg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=lJXfgA nG1XdokhB53jvYf9YcWQVCNyAn3vWB2iYk2xc=; b=YgxSDYsXyFvg4hSSqWw0+Y v5X1S7v5tjWFI/Mxqqe/gnC4HFBLykMNeyxqmxl0wQvrvGTJd4Bt9TP27u9ySkpj fS34SI1TcuNS5dW+MF/l6QNhlc362ICgR6JXedAHembQ/3S0DZApqYYdXhDsTYnq Mw7WVt7ERx4UEpEQJ43cURZ8F3dOyyOwYEQgcNK1VkfFylI9lBabez+qGhSBgmi/ je8DTwQbsotdcTJO7rXqbOq0CPPxYi5EDyuEi7GY16WFYLPHnxtiyJSeygYi0qdM fiBz25prPrAySarslPztnLwcJA8nIvalS7/1F20ulOqCQDcj94EYjd5Z/wmrC37g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheelgdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfurghmucgh hhhithgvugdfuceoshgrmhesshgrmhifhhhithgvugdrtghomheqnecuffhomhgrihhnpe hivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CDE7C1460061; Mon, 27 Apr 2020 09:32:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: Date: Mon, 27 Apr 2020 09:31:52 -0400 From: "Sam Whited" To: "KITTEN Working Group" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [kitten] I-D: Best practices for password hashing and storage X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 13:32:16 -0000 Hi all, I've been working on a document making recommendations for password hashing and storage (possibly with a focus on SASL). I was encouraged to= turn it into an I-D and ask if it was something the KITTEN WG would be interested in? If so, what would the process look like going forward? The initial draft has been uploaded here: https://datatracker.ietf.org/doc/draft-whited-kitten-password-storage/ As an I-D the scope of the document is potentially much broader than the= one I was originally writing, so suggestions for anything else that might be useful to include would be welcome. For example, adding a section on how to properly tune KDFs for your service might be a good future addition. =E2=80=94Sam --=20 Sam Whited From nobody Tue Apr 28 15:43:41 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D683B3A0764 for ; Tue, 28 Apr 2020 15:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=josefsson.org 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 ZuZvHtGBcPEh for ; Tue, 28 Apr 2020 15:43:36 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b1:8633::105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB833A0762 for ; Tue, 28 Apr 2020 15:43:35 -0700 (PDT) Received: from latte (31-208-42-58.cust.bredband2.com [31.208.42.58]) (authenticated bits=0) by duva.sjd.se (8.15.2/8.15.2/Debian-8) with ESMTPSA id 03SMhKOc000472 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Apr 2020 22:43:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=josefsson.org; s=default; t=1588113801; bh=2PabogFWLE3qkmoeEa/s8wx5Ha4SFJE8xWSrZ0WIorY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Un4zDy7CKjzjI6WMFu1DuSzp4BFQQssKYqdT8MKdKEkLp0ZHcBVso4k4iOzJQ3unm y8wHIOPOH5N8yWmFpNjTE1VsqxOuUv9ObRXrNhKDCoTcBmX7h0Dlhg0SaFU5aRBXkO BWfxYTf66lw9AY+fExbaFo1JxUKtVWZyy5XCq9JAe+HMvPL/zQmPlTXx2W6HUECVTA XtWHgPB6gqHW8c5cFVRomjIMJ7gSoI1e5GlNOpHLZZ/45anoYC4kk5HcDSZBMQ9DOk a3jm5WquoEVHBSBVB5YH/XxLE/qwHEKiF4SQKGGsVltuovFc9mmmCt6PjvO4JVLinM 8mRIb6pQNqsGw== From: Simon Josefsson To: "Sam Whited" Cc: "KITTEN Working Group" References: OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt X-Hashcash: 1:22:200428:kitten@ietf.org::9ok0REy99C+ZUIn3:vme X-Hashcash: 1:22:200428:sam@samwhited.com::X5m5nD1YDBEyNWsr:9tso Date: Wed, 29 Apr 2020 00:43:20 +0200 In-Reply-To: (Sam Whited's message of "Mon, 27 Apr 2020 09:31:52 -0400") Message-ID: <87lfmfkz93.fsf@latte.josefsson.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.102.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: Re: [kitten] I-D: Best practices for password hashing and storage X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 22:43:39 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Nice work! Some minor comments: 1) I consider PLAIN worse than DIGEST/CRAM-MD5. Maybe it will help the reader understand better if you explain the criteria for sorting. 2) By describing how implementations should handle credentials for PLAIN, it encourages continued use of PLAIN. PLAIN is a bad idea from many perspectives. I believe that it is better to say that if any work to improve security is done on a client or server that uses PLAIN, it should be to move to SCRAM-SHA-256, not to implement various mitigations. Mitigations prolongs the transition pain and deter focus from the process of moving away from PLAIN. /Simon "Sam Whited" writes: > Hi all, > > I've been working on a document making recommendations for password > hashing and storage (possibly with a focus on SASL). I was encouraged to > turn it into an I-D and ask if it was something the KITTEN WG would be > interested in? If so, what would the process look like going forward? > > The initial draft has been uploaded here: > https://datatracker.ietf.org/doc/draft-whited-kitten-password-storage/ > > As an I-D the scope of the document is potentially much broader than the > one I was originally writing, so suggestions for anything else that > might be useful to include would be welcome. For example, adding a > section on how to properly tune KDFs for your service might be a good > future addition. > > =E2=80=94Sam --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSjzJyHC50xCrrUzy9RcisI/kdFogUCXqixiAAKCRBRcisI/kdF oodmAP9zCR32RLUAbNS45N6DCs+pPsS67aawNSaW79Nn32WOnAD5AQNPaHwg1QOq XFZ1KQxP7f9tC+/MhaaSysC/lwiU7A8= =6v7Z -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 28 15:50:27 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1498B3A07A9 for ; Tue, 28 Apr 2020 15:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=josefsson.org 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 s9qNsqtAw3Kz for ; Tue, 28 Apr 2020 15:50:21 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b1:8633::105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5C33A079E for ; Tue, 28 Apr 2020 15:50:20 -0700 (PDT) Received: from latte (31-208-42-58.cust.bredband2.com [31.208.42.58]) (authenticated bits=0) by duva.sjd.se (8.15.2/8.15.2/Debian-8) with ESMTPSA id 03SMo5oV004516 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Apr 2020 22:50:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=josefsson.org; s=default; t=1588114207; bh=th9NB2rkZFxY8NhH7VrF0M2w+0asubGUfas0qMu/i4c=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=KdeI/3BIOcBz9b9eDd9VIIFHCXSrmMNoMCbbRRvE3WWifcG7MIrqPDDeCmS1h+gEW DZCodfsSKl0tg9/FWX5s7m/uiEntICMPdp6QteO38S8wBPbl1n78hU2WgfzkJwAIor EXW5AhbawsQdphVHvzxSpBR/EIiGdN0OQiPdvAvy5t1R7yMlntsEPXxCLyoZ4YK3UB Ev4KA1c7FoUt08vzIWgZDrNVPeVMIsFekTqV4A4PuQIT3i3aHNBlAv6YoH/1Seiqx1 7rdVd7gQiwxOAEX4vOlTEIotxea+DMn6Z7pkvq4T9ZmI5A9DK3BcsnIt53XZExWwhb HjppREISTOCIg== From: Simon Josefsson To: Dave Cridland Cc: "kitten\@ietf.org" References: <5E8F1ED9.1020108@openfortress.nl> <87zhb4jzhv.fsf@latte.josefsson.org> OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt X-Hashcash: 1:22:200428:simon=40josefsson.org@dmarc.ietf.org::kU3CY34YBm+R2JUU:63hK X-Hashcash: 1:22:200428:dave@cridland.net::HU1lMlOtD1j5DeYX:I80o X-Hashcash: 1:22:200428:kitten@ietf.org::4xSIpDfhkSODdH8E:HhLF Date: Wed, 29 Apr 2020 00:50:05 +0200 In-Reply-To: (Dave Cridland's message of "Tue, 21 Apr 2020 23:12:48 +0100") Message-ID: <87h7x3kyxu.fsf@latte.josefsson.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.102.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: Re: [kitten] SASL, how to choose the type of channel binding? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 22:50:25 -0000 --=-=-= Content-Type: text/plain Dave Cridland writes: > On Tue, 21 Apr 2020 at 22:33, Simon Josefsson 40josefsson.org@dmarc.ietf.org> wrote: > >> Rick van Rein writes: >> >> > Hello, >> > >> > I can see that the GS2 negotiates *whether* to use channel binding, but >> > how can a client and server agree on *which* form to use? >> >> Practically it is hard-coded to 'tls-unique' that, alas, has security >> issues. See RFC 7627. GS2 does not provide any facility to (reliably) >> negotiate which channel binding type to use, that negotiation has to >> come from the SASL application protocol or out-of-band. See section 5.2 >> of the document. I don't recall any SASL application protocols that >> provide this feature -- does anyone know of any example? >> > > No, but the XMPP community uses channel bindings quite heavily (or at > least, more so than anywhere else I've noticed). > > If you feel like throwing a XEP (or an I-D) toward the XSF on negotiation > of channel bindings (should be a simple stream feature), you might find > some interest there. I have started to think that this complexity of SCRAM/GS2 was a bad idea. Providing a half-baked negotiation mechanisms for a security critical component invites problems. I would be happier if this feature was removed, and that the channel binding type negotiation happens implicitly at SASL mechanism negotiation time. This is what happens in practice today when SCRAM/GS2 always means tls-unique. If nobody knows examples of, or intend to use, this feature, I think we should discourage it before someone uses it. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSjzJyHC50xCrrUzy9RcisI/kdFogUCXqizHQAKCRBRcisI/kdF oqbjAPwI/4lPEhvWTk+89G6s3p/osb/dpehWl3tFuxwGkvJNzwEA2rHA3y3fAxwW OEZkcsh7ebS48w/lTWbw+8qh9vwAzwQ= =Slm7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 28 16:53:48 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31FE3A0AE4 for ; Tue, 28 Apr 2020 16:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDIgRE-qyHPr for ; Tue, 28 Apr 2020 16:53:44 -0700 (PDT) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7943A085A for ; Tue, 28 Apr 2020 16:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588118022; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dZwgdwFqtJOPX164Fm8gycRf55mqp739IZLxerUkYm8=; b=cAX9rBswHqfeSwiXTxWdIamzPPdlbbppMsKbzMDWoFgghqeh2XYJi5I6s0VspsXk4gUIEe lEzdoukrtizZfiNkBt55T19/2Ufa2uvsN9g3A64baYxiNNotRmMOUU3m0qaGV/sNufbOEx QXtbYh2Yap9jIlvTfQD14afYjBQBs+4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-289-yqI8SQy-MVOIFt34lsVaig-1; Tue, 28 Apr 2020 19:53:38 -0400 X-MC-Unique: yqI8SQy-MVOIFt34lsVaig-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A640D835B44; Tue, 28 Apr 2020 23:53:37 +0000 (UTC) Received: from localhost (unknown [10.10.110.58]) by smtp.corp.redhat.com (Postfix) with ESMTP id B5A3519C4F; Tue, 28 Apr 2020 23:53:34 +0000 (UTC) From: Robbie Harwood To: Greg Hudson , Benjamin Kaduk , draft-ietf-kitten-krb-spake-preauth.all@ietf.org, Nathaniel McCallum Cc: kitten@ietf.org In-Reply-To: <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu> References: <20190404235859.GM54777@kduck.mit.edu> <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu> Date: Tue, 28 Apr 2020 19:53:31 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 23:53:46 -0000 --=-=-= Content-Type: text/plain Greg Hudson writes: > Ben sent feedback on the SPAKE preauth draft a little over a year ago. > I deferred acting on the smaller feedback items at the time, while > observing the CFRG's progress on PAKE algorithms. > > The CFRG has selected CPace over SPAKE2 for a balanced PAKE. As such > I doubt there will be a need for a CFRG SPAKE2 document. At this time > I don't think there would be sufficient interest in retooling the > Kerberos preauth mechanism for CPace, or making breaking changes. I > have prepared changes to draft-ietf-kitten-krb-spake-preauth to drop > its dependency on draft-irtf-cfrg-spake2, instead referring > informatively to the Abdalla/Pointcheval paper and describing the > group operations explicitly. > > These changes, as well as updates addressing the smaller feedback > items, are at > https://github.com/greghudson/ietf/commit/6ecf1b9dfacc804692d858c726888855a512b8b7 > . I will update the draft unless it seems like there isn't WG > consensus on this direction. Appreciate you being proactive about picking up work on SPAKE again. > Some responses to a few of the smaller feedback items: > > On 4/4/19 7:58 PM, Benjamin Kaduk wrote: >> >> In addition to potentially allocating a new value for the RFC version >> of this spec, we probably also want to say a bit more about the >> registration procedures. Should requestors send the request directly >> to the list, or to IANA first and IANA sends to the list? Is the >> list publicly archived (and can anyone sign up as a member)? > > I'm a little lost here. The mailing list was Nathaniel's idea and I am > not attached to it. There are hundreds of IANA registries; it seems > like we should be picking from a few best practices for update > procedures rather than breaking ground. CCing Nathaniel - anything to add? I accept some of the blame for this - I think I wrote the language - but the mailing list was Nathaniel's request. I believe I modeled what it specifies after RFC 7517 (there's no particular reason for that one, just what we happened to be working on at the time). Is it normal for requests to be sent to IANA at all when Designated Experts are used? Is the mailing list registration normally specified in this fashion? I can't find anything in RFC 8126 about it, but I'm happy to make changes / accept changes to this document regardless. Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAl6owfsACgkQJTL5F2qV pELS9xAAojPue0pTY7LkdYUsFoi8kBTB+dq7N2cdz8g2pfhxpQWXbTYGydU4Dee6 cySqaqzzEFe73z6Sc2UMFvHH7BhAD1VlhO07bY5qaMaURCt3EW6vi8Xj5WpQ92d7 8lmMPm3bmzx3uGDbCpk+LvR8qYnhl8/PWHYKkH2u+d+4/whYiN6X1FQNvzufN5Hg OMOqYqcpqP6CTKo/bEVc0gfr6pGgUqDA6FcChHdaBZVx5RN8iH9cH76T7zS+/y4F 5kOfnARQAtKW0alG/O1W6Fx2I8FBjyARBJMh3hYagJyzdOCd2npML2osocJq2rid 8Dr+5rbDsMAtFzHvOhG5yXhlnW4Go8QxSNglJeGYifUyZ2ucZ9My7WKD8vTu8TZT rT7ITx+zHYFGbp01tcXqP5+ph61cNv4eDZmUNkaogFmaXLh+Oi/+CUr4+QwaxUTm kUgxopiJNsgAsr3S2AvLPo6uGH00iRcJWXRNNYKcl4ZA6kVa0TAxs+V2pHQ/h6ST F57E/xnIwNRQe8qFMHShEbt/mfkFnfhGhlk8A/8vhL1No9vh9DduIhkdm+SaWnYW 6aMvUAnRSEzrKV1fW0txQiJA8ugvw6bwpKW2ZybXscKUjGgSNs/l/QX2Tc7jXn5N AKzN0w5ROENHQ7866szF9+XDRIoev102CY3tuwTVp0UOH2uWOEw= =//nF -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 28 18:23:43 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCC43A099F; Tue, 28 Apr 2020 18:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRIDe2jICJ3f; Tue, 28 Apr 2020 18:23:38 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FA13A0998; Tue, 28 Apr 2020 18:23:38 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03T1NXfl018654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Apr 2020 21:23:36 -0400 Date: Tue, 28 Apr 2020 18:23:33 -0700 From: Benjamin Kaduk To: Robbie Harwood Cc: Greg Hudson , draft-ietf-kitten-krb-spake-preauth.all@ietf.org, Nathaniel McCallum , kitten@ietf.org Message-ID: <20200429012333.GD27494@kduck.mit.edu> References: <20190404235859.GM54777@kduck.mit.edu> <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 01:23:41 -0000 On Tue, Apr 28, 2020 at 07:53:31PM -0400, Robbie Harwood wrote: > Greg Hudson writes: > > > Ben sent feedback on the SPAKE preauth draft a little over a year ago. > > I deferred acting on the smaller feedback items at the time, while > > observing the CFRG's progress on PAKE algorithms. > > > > The CFRG has selected CPace over SPAKE2 for a balanced PAKE. As such > > I doubt there will be a need for a CFRG SPAKE2 document. At this time > > I don't think there would be sufficient interest in retooling the > > Kerberos preauth mechanism for CPace, or making breaking changes. I > > have prepared changes to draft-ietf-kitten-krb-spake-preauth to drop > > its dependency on draft-irtf-cfrg-spake2, instead referring > > informatively to the Abdalla/Pointcheval paper and describing the > > group operations explicitly. > > > > These changes, as well as updates addressing the smaller feedback > > items, are at > > https://github.com/greghudson/ietf/commit/6ecf1b9dfacc804692d858c726888855a512b8b7 > > . I will update the draft unless it seems like there isn't WG > > consensus on this direction. > > Appreciate you being proactive about picking up work on SPAKE again. > > > Some responses to a few of the smaller feedback items: > > > > On 4/4/19 7:58 PM, Benjamin Kaduk wrote: > >> > >> In addition to potentially allocating a new value for the RFC version > >> of this spec, we probably also want to say a bit more about the > >> registration procedures. Should requestors send the request directly > >> to the list, or to IANA first and IANA sends to the list? Is the > >> list publicly archived (and can anyone sign up as a member)? > > > > I'm a little lost here. The mailing list was Nathaniel's idea and I am > > not attached to it. There are hundreds of IANA registries; it seems > > like we should be picking from a few best practices for update > > procedures rather than breaking ground. > > CCing Nathaniel - anything to add? > > I accept some of the blame for this - I think I wrote the language - but > the mailing list was Nathaniel's request. I believe I modeled what it > specifies after RFC 7517 (there's no particular reason for that one, > just what we happened to be working on at the time). > > Is it normal for requests to be sent to IANA at all when Designated > Experts are used? Is the mailing list registration normally specified > in this fashion? I can't find anything in RFC 8126 about it, but I'm > happy to make changes / accept changes to this document regardless. I think that the mailing list thing gained traction with a group of folks in the OAuth community and expanded through to JOSE+JWT and then the IoT analogues (COSE+CWT), at which point it was large enough that other unrelated groups started picking up on it (including TLS). There's nothing that requires having a mailing list, though it does give the community some visibility into the workings of the DE review process (as well as, depending on list permissions, a way to get notified about pending allocations). That said, the default behavior you get for a registry if you don't say otherwise, is that IANA is the first point of contact. That is, you ask IANA to allocate a value (usually via a webform), and behind the scenes IANA goes off and talks to the Experts, before acting on the decision of the Experts. Sometimes IANA has to relay questions and answers back and forth and it feels a bit silly, but that's the way it's historically been done. As a couple examples, RFC 7519 (JWT) creates jwt-reg-review@ietf.org, and https://datatracker.ietf.org/list/nonwg lists a few more. I don't think there is a perfect example yet of what text to use in the RFC when using this sort of review process, though -- the examples that come to mind still leave some ambiguity about what requestors and IANA are supposed to do. -Ben From nobody Tue Apr 28 20:20:56 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07F23A0D82 for ; Tue, 28 Apr 2020 20:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=aCor5eZK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QnVPnPZN 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 W7mOMNtIgLSp for ; Tue, 28 Apr 2020 20:20:52 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1333A0D81 for ; Tue, 28 Apr 2020 20:20:51 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 33E63BF9; Tue, 28 Apr 2020 23:20:51 -0400 (EDT) Received: from imap34 ([10.202.2.84]) by compute7.internal (MEProxy); Tue, 28 Apr 2020 23:20:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm2; bh=4e E22HsPD3jodpCjTSsbJdahPgDzQ5mDG+1Amn3Jgkk=; b=aCor5eZKFq93b8EC44 uQAVzVQkTpxj43p7SLbrRyW6Zg3OK389rXLWAb4fzRho2DLXS37UTg8mKpDENtoK 1H+FYSQDy760ikzszT6yZrSCX2kz6uTXbadNkxchj/ESimKP/ttxDVmjKk9SS4se o/PTl5OSh+vT5NCFCyZQa4keHiY8TeRNMV18o4hqXX5wkL0v2hBBflqn+8TKUyRj SI10cPBYRa+7IYy2bItH1Hb4sGVLXtuK1vWz2lw8XzZ1giJDEnkeYeUexOdFX3cy nVHmEmCIyNj4zseh9n/Ru4iHlkbZyOfJTjzIyS1Sido/nO1+kscdXZ5uXV2rZwub eQKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=4eE22HsPD3jodpCjTSsbJdahPgDzQ5mDG+1Amn3Jg kk=; b=QnVPnPZN/qkow73jEqmnrSR+J0YnJZO3/tbH7E21PSRmZggmYB2hQqZ+4 1GHOdf7iPyT2Mo1FpTGqfzIXeiFNowAGsImXRVwWAAyWo5G7NETyKwrcFQeaMoL2 je00no6IX5cD2ocYHsvQJ4OK/kEa8oqGsxqOEL498lgPHqod24ty40j7gbPoIfQA dbXqHHgBaR2uSf3RHzdZ0W6pYHUoJHf8OOT973b/0hVL59/YPbZDDskOn3ggVaCx UF6N3NZd1FTGQINvA+bvN+dLF1o+LWzqbiZuH4eLAdrJIyeKTVAYqrPrDBg4NyHj ewLP3PGPIwdxdGiyHsvuHRFYknHiQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedriedvgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfurghm ucghhhhithgvugdfuceoshgrmhesshgrmhifhhhithgvugdrtghomheqnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshgrmhesshgrmhifhhhi thgvugdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DCE331460061; Tue, 28 Apr 2020 23:20:49 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <5c901419-ce12-42df-8718-2a6e624159c7@www.fastmail.com> In-Reply-To: <87lfmfkz93.fsf@latte.josefsson.org> References: <87lfmfkz93.fsf@latte.josefsson.org> Date: Tue, 28 Apr 2020 23:20:28 -0400 From: "Sam Whited" To: "Simon Josefsson" Cc: "KITTEN Working Group" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] I-D: Best practices for password hashing and storage X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 03:20:54 -0000 On Tue, Apr 28, 2020, at 18:43, Simon Josefsson wrote: > 1) I consider PLAIN worse than DIGEST/CRAM-MD5. Maybe it will help > the reader understand better if you explain the criteria for > sorting. Good idea, thank you. I've submitted a new draft explaining why I ordered them the way I did, and some caveats about each individual mechanism. In the case of PLAIN vs DIGEST auth I've given PLAIN a higher perceived strength because DIGEST-MD5 forces you to store the password on the server using a weak hash. With PLAIN it may not have any protection over= the wire (not that DIGEST-MD5 really gives you any at this point either), but on the back end you can hash it however you want. Also note that DIGEST-MD5 is forbidden by this document and the example that mentions it specifically says that it's not endorsing using it, just giving an example of how it would be ranked so I think it's okay. That being said, maybe it's worth not mentioning DIGEST/CRAM-= MD5 at all. > 2) By describing how implementations should handle credentials for > PLAIN, it encourages continued use of PLAIN. PLAIN is a bad idea= > from many perspectives. I believe that it is better to say that > if any work to improve security is done on a client or server > that uses PLAIN, it should be to move to SCRAM-SHA-256, not to > implement various mitigations. Mitigations prolongs the > transition pain and deter focus from the process of moving away > from PLAIN. PLAIN makes the hash used to store the passwords more agile, which is the main weakness of SCRAM (in my very amateur opinion that should likely be taken with a grain of salt until this has all had expert review). If I'm using SCRAM-SHA-1 and a preimage attack is found for SHA= 1, for example and I want my users to upgrade to SCRAM-SHA- 2, I may have to convince both clients and servers to support the new mechanism. This is fine in proprietary systems where the client and servers are under the control of the same entity, but isn't fine for systems like XMPP, for example, where changing SCRAM versions could cause incompatibilities between some clients and servers. Of course, a SHA1 preimage attack may not be likely, but it's just an extreme example of what can go wrong when you don't have hash agility. Also, when integrating with other systems (eg. an existing HTTP system that uses bcrypt to hash passwords) you're stuck using something like PLAIN since with SCRAM you'd have to store two separate hashes (your applications legacy bcrypt one and the PBKDF2 hashed one). I'm also for encouraging SCRAM usage, I just think it's worth proceeding= with caution because PLAIN may actually be a better fit for some systems= depending on your compatibility and security requirements. If people are= already using it (and they are), it might be more beneficial to tell them how to do it as safely as possible instead of leaving them hanging.= =E2=80=94Sam --=20 Sam Whited From nobody Wed Apr 29 01:17:29 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAF43A053E for ; Wed, 29 Apr 2020 01:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 MHPjbmf12tzt for ; Wed, 29 Apr 2020 01:17:23 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363463A0524 for ; Wed, 29 Apr 2020 01:17:23 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id g13so1355744wrb.8 for ; Wed, 29 Apr 2020 01:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/WL/aEHoCMwvymj15dXIHFOXXF6ZrSNRvO3Pc9D1cqA=; b=Q616FgR4XVL66KlE1fUFVPt5wwwg41OdsqjxabnmmSaPmcI37giuvIBQIY9dvBHM6H XmQpe3IiUwDzhICUrhSz50flM9jbJ1IRRE57B3bPZKTPfyDMin3K8lVFpEvtRA+49LBd TkKK4yCyT0KbLaUayWl5wVmr/lUtmi2xl9HK8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/WL/aEHoCMwvymj15dXIHFOXXF6ZrSNRvO3Pc9D1cqA=; b=KbIt9ptuGaboQMuqU8LS09x388z9tXJp9lkm415+7GHQtKg6we7qrgy3kajLbQM4Cx KZcck09WtWD3bot1K8DKm4Qwo0FOo4zWL22Gquf1R5HsQdCJqQMoPHqH5R02lGH/hcEJ smFgsgtE1aLINJPcCYDcOCWC0f2HvK9csvw47SRbDG2FymUevD+spDZCMTnQl6XfAr+b VVSnXeq09uNSCsyVkEGWf6zoMiv5Yo7DLY559omlSCrHSKRVnPJRFhdojiSC/7LbohqG xqQ7z9AyrgDBfzh8CfofCsnOmC7Ckyj44nYc5s25yxKHh6q1ddT/C+qz71XLnPD6tqXN KqMA== X-Gm-Message-State: AGi0PubdjCXao0dAVY1ARr1FUdrHH00KEFG+2NK6gog333chNInu1Meb IBuVyMpb7L/rd9+4+MUxNBYkLdavswDFK3xKFpNn9afDVOkGRw== X-Google-Smtp-Source: APiQypKvQz2zf9lw+ausHTqa2gv4KC/BRlZpFE55rUp0UmJAWH71pZr3tAXwFm1/twgKXoaoMCfcEITdkEVrbtzem5k= X-Received: by 2002:adf:e403:: with SMTP id g3mr38196524wrm.121.1588148241362; Wed, 29 Apr 2020 01:17:21 -0700 (PDT) MIME-Version: 1.0 References: <5E8F1ED9.1020108@openfortress.nl> <87zhb4jzhv.fsf@latte.josefsson.org> <87h7x3kyxu.fsf@latte.josefsson.org> In-Reply-To: <87h7x3kyxu.fsf@latte.josefsson.org> From: Dave Cridland Date: Wed, 29 Apr 2020 09:17:10 +0100 Message-ID: To: Simon Josefsson Cc: "kitten@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c708cb05a4699355" Archived-At: Subject: Re: [kitten] SASL, how to choose the type of channel binding? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 08:17:27 -0000 --000000000000c708cb05a4699355 Content-Type: text/plain; charset="UTF-8" On Tue, 28 Apr 2020 at 23:50, Simon Josefsson wrote: > Dave Cridland writes: > > > On Tue, 21 Apr 2020 at 22:33, Simon Josefsson > 40josefsson.org@dmarc.ietf.org> wrote: > > > >> Rick van Rein writes: > >> > >> > Hello, > >> > > >> > I can see that the GS2 negotiates *whether* to use channel binding, > but > >> > how can a client and server agree on *which* form to use? > >> > >> Practically it is hard-coded to 'tls-unique' that, alas, has security > >> issues. See RFC 7627. GS2 does not provide any facility to (reliably) > >> negotiate which channel binding type to use, that negotiation has to > >> come from the SASL application protocol or out-of-band. See section 5.2 > >> of the document. I don't recall any SASL application protocols that > >> provide this feature -- does anyone know of any example? > >> > > > > No, but the XMPP community uses channel bindings quite heavily (or at > > least, more so than anywhere else I've noticed). > > > > If you feel like throwing a XEP (or an I-D) toward the XSF on negotiation > > of channel bindings (should be a simple stream feature), you might find > > some interest there. > > I have started to think that this complexity of SCRAM/GS2 was a bad > idea. Providing a half-baked negotiation mechanisms for a security > critical component invites problems. I would be happier if this feature > was removed, and that the channel binding type negotiation happens > implicitly at SASL mechanism negotiation time. This is what happens in > practice today when SCRAM/GS2 always means tls-unique. If nobody knows > examples of, or intend to use, this feature, I think we should > discourage it before someone uses it. I'm actually not entirely sure what you mean by `this` in several cases here (in my defence, I've been doing a lot of JavaScript recently), so please forgive me if you think I've misunderstood you - I probably have. Within the XMPP world, SCRAM-SHA1 and SCRAM-SHA1-PLUS are MTI mechanisms. There are existing examples of libraries which cannot support tls-unique due to underlying access to the binding information being unavailable. These sometimes do not do channel binding at all, and sometimes use the tls-endpoint binding instead. The lack of explicit negotiation makes for entertaining cases here. Example: https://github.com/igniterealtime/Smack/commit/1f1bc236fd6650fba2f9e59e2aa03969b0700402 So this horse has left the station - it would be more beneficial to have a way that the server could advertise what channel bindings it supports, in my opinion, even if this mandates it would have to accept those binding types across any advertised mechanisms. That in turn isn't too bad, since the design of GS2 means that channel binding data is explicitly passed to the server, which is then trusted to verify it (rather than synthesize it anew). This means that an unknown channel binding can be accepted blind, in extremis. I don't like this design, I have to say, but it does have the advantage here. Without explicit advertising, though, a client is forced to assume (or just guess, or even make up a channel binding type on the spot). Dave. --000000000000c708cb05a4699355 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 28 Apr 2020 at 23:50, Simon J= osefsson <simon@josefsson.org= > wrote:
Dave= Cridland <dave@c= ridland.net> writes:

> On Tue, 21 Apr 2020 at 22:33, Simon Josefsson <simon=3D
> 40= josefsson.org@dmarc.ietf.org> wrote:
>
>> Rick van Rein <rick@openfortress.nl> writes:
>>
>> > Hello,
>> >
>> > I can see that the GS2 negotiates *whether* to use channel bi= nding, but
>> > how can a client and server agree on *which* form to use?
>>
>> Practically it is hard-coded to 'tls-unique' that, alas, h= as security
>> issues.=C2=A0 See RFC 7627.=C2=A0 GS2 does not provide any facilit= y to (reliably)
>> negotiate which channel binding type to use, that negotiation has = to
>> come from the SASL application protocol or out-of-band.=C2=A0 See = section 5.2
>> of the document.=C2=A0 I don't recall any SASL application pro= tocols that
>> provide this feature -- does anyone know of any example?
>>
>
> No, but the XMPP community uses channel bindings quite heavily (or at<= br> > least, more so than anywhere else I've noticed).
>
> If you feel like throwing a XEP (or an I-D) toward the XSF on negotiat= ion
> of channel bindings (should be a simple stream feature), you might fin= d
> some interest there.

I have started to think that this complexity of SCRAM/GS2 was a bad
idea.=C2=A0 Providing a half-baked negotiation mechanisms for a security critical component invites problems.=C2=A0 I would be happier if this featu= re
was removed, and that the channel binding type negotiation happens
implicitly at SASL mechanism negotiation time.=C2=A0 This is what happens i= n
practice today when SCRAM/GS2 always means tls-unique.=C2=A0 If nobody know= s
examples of, or intend to use, this feature, I think we should
discourage it before someone uses it.

I'= ;m actually not entirely sure what you mean by `this` in several cases here= (in my defence, I've been doing a lot of JavaScript recently), so plea= se forgive me if you think I've misunderstood you - I probably have.

Within the XMPP world, SCRAM-SHA1 and SCRAM-SHA1-PLU= S are MTI mechanisms. There are existing examples of libraries which cannot= support tls-unique due to underlying access to the binding information bei= ng unavailable. These sometimes do not do channel binding at all, and somet= imes use the tls-endpoint binding instead. The lack of explicit negotiation= makes for entertaining cases here.


So this = horse has left the station - it would be more beneficial to have a way that= the server could advertise what channel bindings it supports, in my opinio= n, even if this mandates it would have to accept those binding types across= any advertised mechanisms.

That in turn isn't= too bad, since the design of GS2 means that channel binding data is explic= itly passed to the server, which is then trusted to verify it (rather than = synthesize it anew). This means that an unknown channel binding can be acce= pted blind, in extremis. I don't like this design, I have to say, but i= t does have the advantage here.

Without explicit a= dvertising, though, a client is forced to assume (or just guess, or even ma= ke up a channel binding type on the spot).

Dave.
--000000000000c708cb05a4699355-- From nobody Wed Apr 29 07:27:15 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7A33A11A9 for ; Wed, 29 Apr 2020 07:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imgIXYLo784Q for ; Wed, 29 Apr 2020 07:27:11 -0700 (PDT) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E992B3A11AA for ; Wed, 29 Apr 2020 07:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588170430; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+e3ElkodTegjk3ds054Mk7UkJHH2wjxQ0tqsGfpOupY=; b=LuZ+GSkzHLDEewH2RQiTUZUWKjuCmAJIfSvK77iSiUIhWeF/LOQ0EX0b+yoMi0WSrwK9tT QAjuIXypKFNzgHDzZTxF0paH10Jm8+fSN6u0xOEIS90YeEDIoRxoav/EhI9YAgmNjnqCe5 q/37JtLdTwd5W+mfwejRfXnayrhvVd4= Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-165-680W4YR4MXuvzy9m8_ybyQ-1; Wed, 29 Apr 2020 10:27:06 -0400 X-MC-Unique: 680W4YR4MXuvzy9m8_ybyQ-1 Received: by mail-il1-f197.google.com with SMTP id y2so2681533ilm.8 for ; Wed, 29 Apr 2020 07:27:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=40E/Ioe13e9ct2jt5cO3SsN0w+Idp8Jrbkox1x8lH4k=; b=dwtw8pgMrF+kj/FgC9OddkU6d2w+2170mTduQXJWmOwvYGRwQSR1TbXVWYmLLdeDtH L3Zek86yDw26H9GsdE3apvSnPXc2LjWh79JzgeP6hZByDPDuIZBfY4G+AMK2lq/Y24Wb jgYLKNScGg1kiK482YTJS6Q2r231jC9orbcrlnUVbf8x3K0OZAf/WhgHfDrIXSb3NVRo +I8yEp62tsilmFbMUWnED1Ckcw5vda/D+YAGA5HoWHTC9Nw2JJmMmwTxaxQeDn8I7kTf TkuxpvI38q5cKnLYy0lUPOQz9d0G9MFwuKuW44wwdtDMznvt7JT2P1YxN0sdlHwHEBRI oaVQ== X-Gm-Message-State: AGi0Pua3NjcMp8b85Z/KvrU5qYxM8fhtwJrrmra02O2OvbxRTTOGI18n 4cDMwoGZWSWt2kIF5LRMcvFRiccBMKW3RZUFUcXYNIK6oYY+3szdTNIytynJIgkNUTe4WXVVjKE udtmTsXyop2E7vGLhjtBypro= X-Received: by 2002:a92:84c1:: with SMTP id y62mr19209970ilk.116.1588170422581; Wed, 29 Apr 2020 07:27:02 -0700 (PDT) X-Google-Smtp-Source: APiQypIBw+IY9UJRCfaGk4sRoC/VDyP/YBfHyZVAb13yxLlXXRbqQ3KHDDwPTRhgJBdK/46VLUzdsbFIOLjK3JLz9CQ= X-Received: by 2002:a92:84c1:: with SMTP id y62mr19209938ilk.116.1588170422252; Wed, 29 Apr 2020 07:27:02 -0700 (PDT) MIME-Version: 1.0 References: <20190404235859.GM54777@kduck.mit.edu> <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu> In-Reply-To: From: Nathaniel McCallum Date: Wed, 29 Apr 2020 10:26:49 -0400 Message-ID: To: Robbie Harwood Cc: Greg Hudson , Benjamin Kaduk , draft-ietf-kitten-krb-spake-preauth.all@ietf.org, kitten@ietf.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 14:27:14 -0000 On Tue, Apr 28, 2020 at 7:53 PM Robbie Harwood wrote: > > Greg Hudson writes: > > > Ben sent feedback on the SPAKE preauth draft a little over a year ago. > > I deferred acting on the smaller feedback items at the time, while > > observing the CFRG's progress on PAKE algorithms. > > > > The CFRG has selected CPace over SPAKE2 for a balanced PAKE. As such > > I doubt there will be a need for a CFRG SPAKE2 document. At this time > > I don't think there would be sufficient interest in retooling the > > Kerberos preauth mechanism for CPace, or making breaking changes. I > > have prepared changes to draft-ietf-kitten-krb-spake-preauth to drop > > its dependency on draft-irtf-cfrg-spake2, instead referring > > informatively to the Abdalla/Pointcheval paper and describing the > > group operations explicitly. > > > > These changes, as well as updates addressing the smaller feedback > > items, are at > > https://github.com/greghudson/ietf/commit/6ecf1b9dfacc804692d858c726888= 855a512b8b7 > > . I will update the draft unless it seems like there isn't WG > > consensus on this direction. > > Appreciate you being proactive about picking up work on SPAKE again. > > > Some responses to a few of the smaller feedback items: > > > > On 4/4/19 7:58 PM, Benjamin Kaduk wrote: > >> > >> In addition to potentially allocating a new value for the RFC version > >> of this spec, we probably also want to say a bit more about the > >> registration procedures. Should requestors send the request directly > >> to the list, or to IANA first and IANA sends to the list? Is the > >> list publicly archived (and can anyone sign up as a member)? > > > > I'm a little lost here. The mailing list was Nathaniel's idea and I am > > not attached to it. There are hundreds of IANA registries; it seems > > like we should be picking from a few best practices for update > > procedures rather than breaking ground. > > CCing Nathaniel - anything to add? > > I accept some of the blame for this - I think I wrote the language - but > the mailing list was Nathaniel's request. I believe I modeled what it > specifies after RFC 7517 (there's no particular reason for that one, > just what we happened to be working on at the time). > > Is it normal for requests to be sent to IANA at all when Designated > Experts are used? Is the mailing list registration normally specified > in this fashion? I can't find anything in RFC 8126 about it, but I'm > happy to make changes / accept changes to this document regardless. I have no strong preference. I'd rather see movement on the document than be held up in debates about this. From nobody Wed Apr 29 08:58:19 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382653A132A for ; Wed, 29 Apr 2020 08:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjFOIxNp8GFe for ; Wed, 29 Apr 2020 08:58:14 -0700 (PDT) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D985B3A148F for ; Wed, 29 Apr 2020 08:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588175862; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Vz+WXUZlsQ7ZEopCX6WglP5+3No153R+l2xKfueMhUs=; b=HNGaPuCBqRwJ1uXsgOpuU6nqxUvLkNloF2SiySu5iBAWADp2LrFGexmIUSpFTsHtpZ0/r+ oLLDSdMPBHcy38TPWJq21wdy8xrzKIW6vFDVy0Z/OjEIiCiqRApu4o0eOsoBZRaZdaIP+O JIaDZttr+Npu+vjLLoC+0Wrtbz2qQUU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-288-fFpKUPUPNcybkYkuZY14YQ-1; Wed, 29 Apr 2020 11:57:34 -0400 X-MC-Unique: fFpKUPUPNcybkYkuZY14YQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C10C11800D4A; Wed, 29 Apr 2020 15:57:33 +0000 (UTC) Received: from localhost (unknown [10.10.110.74]) by smtp.corp.redhat.com (Postfix) with ESMTP id 809675798D; Wed, 29 Apr 2020 15:57:33 +0000 (UTC) From: Robbie Harwood To: Luke Howard , "kitten\@ietf.org" In-Reply-To: <5822327E-C113-447B-AAB8-34902F585566@padl.com> References: <5822327E-C113-447B-AAB8-34902F585566@padl.com> Date: Wed, 29 Apr 2020 11:57:32 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [kitten] SAnon kitten adoption X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 15:58:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Luke Howard writes: > Hi everyone, > > Have addressed a few things in the most recent SAnon draft =E2=80=93 > > https://tools.ietf.org/html/draft-howard-gss-sanon-12 > > Is there any interest in seeing this adopted by Kitten? I hear three voices in favor and none against. So if you've objections, please voice them; otherwise I think we have consensus to adopt. (I'll wait a couple days then start that process.) We don't need to settle this now, but at some point this document will need a shepherd to advance. Just something to keep in mind if anyone's interested in doing that. Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAl6po+wACgkQJTL5F2qV pEKtQw//Q25PhpmAo2S1BzlyLrNYo728lW9rr5D51V9qPBpzY7kf6JObMxDiybSr v55miHMk/kBPgwFS663qi+7vf99QECaZmRMQ2PZNeDzEfBvyRKK2WmUTRsG+1lQB SLH/ZeWvhVVAw35Vo9b10+4KJpd8LmOGj2Yc09Box5OTXYlEzwB/ywfnYRzPnJ9Q WeT/hlOWQFjLO8D53FTcyf5IRrq1hei1L8lJ8iwQe8XayF2YMR7/gY1GAtqgEvHx D6/tiLcHUlNE5OPDP0goHlRm19DprLS3jPHVfetuw/dnmFF6rW15O+kUvIwo+anQ FRZD3rncgJlU9QrBF63RICr/qhUbXBBf/5OGOjIofyn8GXfIA9sqCFl806ZhanxV SLCaBTIgikfn1ZCT67gCOdi9OZyRBNY+420BrikUW4kK9wYTSjvT+KpLUwCx+m0o CpS/BxIF6Z2m27NkEgiI5YNXNA4wN0BYfQsGozHH5kGBr+kkaLg7dK9rT/v95chp qK9U1txDFaAryp7WwJIKRzviFuPYe7/soLR7LIUPVklXbhgmPhnEdN7fdiHRdwsj nbo+lxhjNhMmMJFxBFdf9uyxguVfyKPeBTkPJ91JICrUmom4HMGSvLf/t1y1pbSi cA2Wc4wCUB4l9D0nWvy87Zm7ogKQzXtOoRx7uBesaZSf7So97Gw= =/ar0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 29 09:15:56 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9210E3A1376 for ; Wed, 29 Apr 2020 09:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnqzEDeUXOPq for ; Wed, 29 Apr 2020 09:15:51 -0700 (PDT) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409AF3A136F for ; Wed, 29 Apr 2020 09:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588176950; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TaVLMPwjuWF/EhLgv46a/CmxXJw8xy+GBQ1jwkPOGws=; b=XvMlTiEh088bs0Va2j0ZAdN8YkYKX7+ASqyk5OekZoIm4ckaJEM5YOsqpR3XWdHfs5Jp4p DHH4UjrmgafH2vA1ywxOkh0xuj1Fic8wl7KMDWIXBuCguZeXuj1Exq3G9mRAjO/LWUxNvm vFKIO4CSCuYE6rRVThT/AuoKek1aUoo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-234-Q-n18nV_PNWWatJscxJyQA-1; Wed, 29 Apr 2020 12:15:42 -0400 X-MC-Unique: Q-n18nV_PNWWatJscxJyQA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0B11945F; Wed, 29 Apr 2020 16:15:42 +0000 (UTC) Received: from localhost (unknown [10.10.110.74]) by smtp.corp.redhat.com (Postfix) with ESMTP id BBDE060C84; Wed, 29 Apr 2020 16:15:41 +0000 (UTC) From: Robbie Harwood To: Sam Whited , KITTEN Working Group In-Reply-To: References: Date: Wed, 29 Apr 2020 12:15:38 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [kitten] I-D: Best practices for password hashing and storage X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 16:15:54 -0000 --=-=-= Content-Type: text/plain "Sam Whited" writes: > Hi all, > > I've been working on a document making recommendations for password > hashing and storage (possibly with a focus on SASL). I was encouraged > to turn it into an I-D and ask if it was something the KITTEN WG would > be interested in? If so, what would the process look like going > forward? > > The initial draft has been uploaded here: > https://datatracker.ietf.org/doc/draft-whited-kitten-password-storage/ > > As an I-D the scope of the document is potentially much broader than > the one I was originally writing, so suggestions for anything else > that might be useful to include would be welcome. For example, adding > a section on how to properly tune KDFs for your service might be a > good future addition. Hi Sam, with my chair hat on: In order for adoption to occur, I'd like to see expressed interest from multiple folks in the WG (and a formal call for adoption). This may mean it sits a bit longer / has more revisions as an individual I-D, which is fine. I don't think we're over capacity, so taking on more work here should be possible if we have consensus to do so. Happy to answer other process questions as best I can. Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAl6pqCoACgkQJTL5F2qV pEKbQQ/9ETcPxjWexJWF53DjBnFOyFLd+6xboLzlFidN99VVFJJ2nDvoaptykDTV epheNbsjJxHp2W86eW3GzdLXPqXbWBSwkELJtae1QtGY6lOZIE/ZdaXIcvIrXrgH Oxr0LPehc6gFbPzj+asHJpzb28j89W+x9cnRGQuGO+4dFscn5iqk2uXh+ZMbxMH9 zU8Eq+k0skq0v81SrZ17hD7KNeSjspjb0xvoQ57BbawqbtFKFR7q8TCdg+M0fsMs 4e6tfddjtTxPjSTK9B+dwAMPsZQ0IUIZ4LVoQm2r1/owurxffzEGE06Us/w/PC8b No9djUN++OZ+Bq5VT3NCRjIDRRaJeH0p/KU8eni8V0+BzM4dxYMLA8U4fSbHrgli pTdl95q89+6+KjGQBwuOu3lpgrVST+MpreK8+/O1WPhdif6AK71S3M6jurjTiPoy RkIABEMe0+3M4KVq9zVthQrAHyF5cKPRyow/moj65PnDbyt4cJQ4JgFZ4+5Q9ZGu hhF22LCAbJtJoWBN18gTUO11u5ChEGm6jEdC6HLGCGSr4RgpeIVJBzvJuTfapZCM WwpbSVdiNHHsAhURxpdyEpnyochD+q3f9066GoVE5b3DUfHIAz3BWhq3CpX5ub5f LswlnrWdl750romC/h91xJ95HFhsdcZQGRzDOW90DuTtiD1qRFM= =nFCM -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 29 10:51:20 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F39A3A14F0 for ; Wed, 29 Apr 2020 10:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PayB3fhA-Qpg for ; Wed, 29 Apr 2020 10:51:10 -0700 (PDT) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6D93A14F8 for ; Wed, 29 Apr 2020 10:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588182669; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=B89TlvPuOhi37OqISBbnqf3B9+60Q+l0iuQdPNkUocg=; b=H37llvrgAKEqTXJnG/H6TESV5bCxRGO4olEfQJbxvSzxJXecOXt8y9kdAi4tD9SM4f628a RqzK3OyCMaET4rXshrSBXeqpkLBiXrM5G5oPU3znU7W4xGe/NyCaAnHE2Yj6GMzz4mgi62 teaionoQeD/yIRdYEaDsV3bvtbI6BXE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-19-wFEgWHqjP1qsezbV23b2lA-1; Wed, 29 Apr 2020 13:50:55 -0400 X-MC-Unique: wFEgWHqjP1qsezbV23b2lA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 68A48462; Wed, 29 Apr 2020 17:50:54 +0000 (UTC) Received: from localhost (unknown [10.10.110.74]) by smtp.corp.redhat.com (Postfix) with ESMTP id 53E805D9E5; Wed, 29 Apr 2020 17:50:51 +0000 (UTC) From: Robbie Harwood To: Benjamin Kaduk Cc: Greg Hudson , draft-ietf-kitten-krb-spake-preauth.all@ietf.org, Nathaniel McCallum , kitten@ietf.org In-Reply-To: <20200429012333.GD27494@kduck.mit.edu> References: <20190404235859.GM54777@kduck.mit.edu> <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu> <20200429012333.GD27494@kduck.mit.edu> Date: Wed, 29 Apr 2020 13:50:47 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 17:51:13 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Benjamin Kaduk writes: > On Tue, Apr 28, 2020 at 07:53:31PM -0400, Robbie Harwood wrote: >> Greg Hudson writes: >>=20 >>> Ben sent feedback on the SPAKE preauth draft a little over a year >>> ago. I deferred acting on the smaller feedback items at the time, >>> while observing the CFRG's progress on PAKE algorithms. >>> >>> The CFRG has selected CPace over SPAKE2 for a balanced PAKE. As >>> such I doubt there will be a need for a CFRG SPAKE2 document. At >>> this time I don't think there would be sufficient interest in >>> retooling the Kerberos preauth mechanism for CPace, or making >>> breaking changes. I have prepared changes to >>> draft-ietf-kitten-krb-spake-preauth to drop its dependency on >>> draft-irtf-cfrg-spake2, instead referring informatively to the >>> Abdalla/Pointcheval paper and describing the group operations >>> explicitly. >>> >>> These changes, as well as updates addressing the smaller feedback >>> items, are at >>> https://github.com/greghudson/ietf/commit/6ecf1b9dfacc804692d858c726888= 855a512b8b7 >>> . I will update the draft unless it seems like there isn't WG >>> consensus on this direction. >>=20 >> Appreciate you being proactive about picking up work on SPAKE again. >>=20 >>> Some responses to a few of the smaller feedback items: >>> >>> On 4/4/19 7:58 PM, Benjamin Kaduk wrote: >>>> >>>> In addition to potentially allocating a new value for the RFC >>>> version of this spec, we probably also want to say a bit more about >>>> the registration procedures. Should requestors send the request >>>> directly to the list, or to IANA first and IANA sends to the list? >>>> Is the list publicly archived (and can anyone sign up as a member)? >>> >>> I'm a little lost here. The mailing list was Nathaniel's idea and I >>> am not attached to it. There are hundreds of IANA registries; it >>> seems like we should be picking from a few best practices for update >>> procedures rather than breaking ground. >>=20 >> CCing Nathaniel - anything to add? >>=20 >> I accept some of the blame for this - I think I wrote the language - >> but the mailing list was Nathaniel's request. I believe I modeled >> what it specifies after RFC 7517 (there's no particular reason for >> that one, just what we happened to be working on at the time). >>=20 >> Is it normal for requests to be sent to IANA at all when Designated >> Experts are used? Is the mailing list registration normally >> specified in this fashion? I can't find anything in RFC 8126 about >> it, but I'm happy to make changes / accept changes to this document >> regardless. > > I think that the mailing list thing gained traction with a group of > folks in the OAuth community and expanded through to JOSE+JWT and then > the IoT analogues (COSE+CWT), at which point it was large enough that > other unrelated groups started picking up on it (including TLS). > There's nothing that requires having a mailing list, though it does > give the community some visibility into the workings of the DE review > process (as well as, depending on list permissions, a way to get > notified about pending allocations). > > That said, the default behavior you get for a registry if you don't > say otherwise, is that IANA is the first point of contact. That is, > you ask IANA to allocate a value (usually via a webform), and behind > the scenes IANA goes off and talks to the Experts, before acting on > the decision of the Experts. Sometimes IANA has to relay questions > and answers back and forth and it feels a bit silly, but that's the > way it's historically been done. > > As a couple examples, RFC 7519 (JWT) creates jwt-reg-review@ietf.org, > and https://datatracker.ietf.org/list/nonwg lists a few more. I don't > think there is a perfect example yet of what text to use in the RFC > when using this sort of review process, though -- the examples that > come to mind still leave some ambiguity about what requestors and IANA > are supposed to do. Thanks, that's helpful background. Ben, how would you feel about changing the language to read something like: Registry entries are to be evaluated using the Specification Required method. All specifications must be be published prior to entry inclusion in the registry. Once published, they can be submitted directly to the krb5-spake-review@ietf.org mailing list, where there will be a three-week long review period by Designated Experts. Prior to the end of the review period, the Designated Experts must approve or deny the request. This decision is conveyed to both IANA and the submitter. Since the mailing list archives are not public, it should include both a reasonably detailed explanation in the case of a denial as well as whether the request can be resubmitted. (I'm not particularly attached to the mechanics of this. My concerns are first requiring that a specification exists, and second that it be checked for reasonableness without being too arduous for submitters.) Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAl6pvncACgkQJTL5F2qV pEIG5BAAq9K+RP9th7BU8chR03pndJ8P2OqOoA9xttvAjdAOnOz0r/CXSds0E4kD md+vMBAIcty1AQOHiGcM7y9tVNDr/sHuk4QQt/jnLmi18121xUZXfthzUIBYWh41 RIfwZIkAYSsyuFmncex2V0NAAV7Ucbg1LfqSNf7BWvIyGl89s/f5WgA+x2sCPC0V eufjfaO7Q/foiFhRJIZb/hQA+cjZ0FlwMZKoEuO7Jo21rBx+XywODehXlQ59enkU yof48fxL3utlsXPgd2j71C6WzfJ9DwK04poypCvheTHT2RVj80LXMqWjQk2Lb4u+ xOuSslYKp8WmNBWS+OcqOz/gIPMBF+TdywfEts8rGH8Jx9Ac4fCFv+Jn1gmXYZV9 WzZUP+k5+pziVWqeqvk5OMJ7HSi6UcgPDxxYyB0bBm3c8ufQGllh8rKC56hKxzMP yKktCHYhyyTI8kQVn/zXvq2Is2Gpw+h2l5JutnPylhII/VOMNFMNkWsoJbklBagx yFss4cxleuocfwUBOhNKocitC5QeqZkSrkZfXj/ogUEKq1zGwKX958TG8sFVo0nk AVLBazA1iGePPkE6ZPxIxd1dZGLGCMD5WmAPF+jd7XHv3ZQxHEyng1nje9mVAFGk TGinqgl596kCYWyjLMK12LKo7BlaVZvkFWEQrT/DozDO5FZwul4= =hECD -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 29 13:32:20 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CF33A16DD; Wed, 29 Apr 2020 13:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xf1nRMqGJIrY; Wed, 29 Apr 2020 13:32:13 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF75B3A1766; Wed, 29 Apr 2020 13:32:10 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03TKW6wf011791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Apr 2020 16:32:08 -0400 Date: Wed, 29 Apr 2020 13:32:05 -0700 From: Benjamin Kaduk To: Robbie Harwood Cc: Greg Hudson , draft-ietf-kitten-krb-spake-preauth.all@ietf.org, Nathaniel McCallum , kitten@ietf.org Message-ID: <20200429203205.GH27494@kduck.mit.edu> References: <20190404235859.GM54777@kduck.mit.edu> <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu> <20200429012333.GD27494@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 20:32:18 -0000 On Wed, Apr 29, 2020 at 01:50:47PM -0400, Robbie Harwood wrote: > Benjamin Kaduk writes: > > > On Tue, Apr 28, 2020 at 07:53:31PM -0400, Robbie Harwood wrote: > >> Greg Hudson writes: > >> > >>> Ben sent feedback on the SPAKE preauth draft a little over a year > >>> ago. I deferred acting on the smaller feedback items at the time, > >>> while observing the CFRG's progress on PAKE algorithms. > >>> > >>> The CFRG has selected CPace over SPAKE2 for a balanced PAKE. As > >>> such I doubt there will be a need for a CFRG SPAKE2 document. At > >>> this time I don't think there would be sufficient interest in > >>> retooling the Kerberos preauth mechanism for CPace, or making > >>> breaking changes. I have prepared changes to > >>> draft-ietf-kitten-krb-spake-preauth to drop its dependency on > >>> draft-irtf-cfrg-spake2, instead referring informatively to the > >>> Abdalla/Pointcheval paper and describing the group operations > >>> explicitly. > >>> > >>> These changes, as well as updates addressing the smaller feedback > >>> items, are at > >>> https://github.com/greghudson/ietf/commit/6ecf1b9dfacc804692d858c726888855a512b8b7 > >>> . I will update the draft unless it seems like there isn't WG > >>> consensus on this direction. > >> > >> Appreciate you being proactive about picking up work on SPAKE again. > >> > >>> Some responses to a few of the smaller feedback items: > >>> > >>> On 4/4/19 7:58 PM, Benjamin Kaduk wrote: > >>>> > >>>> In addition to potentially allocating a new value for the RFC > >>>> version of this spec, we probably also want to say a bit more about > >>>> the registration procedures. Should requestors send the request > >>>> directly to the list, or to IANA first and IANA sends to the list? > >>>> Is the list publicly archived (and can anyone sign up as a member)? > >>> > >>> I'm a little lost here. The mailing list was Nathaniel's idea and I > >>> am not attached to it. There are hundreds of IANA registries; it > >>> seems like we should be picking from a few best practices for update > >>> procedures rather than breaking ground. > >> > >> CCing Nathaniel - anything to add? > >> > >> I accept some of the blame for this - I think I wrote the language - > >> but the mailing list was Nathaniel's request. I believe I modeled > >> what it specifies after RFC 7517 (there's no particular reason for > >> that one, just what we happened to be working on at the time). > >> > >> Is it normal for requests to be sent to IANA at all when Designated > >> Experts are used? Is the mailing list registration normally > >> specified in this fashion? I can't find anything in RFC 8126 about > >> it, but I'm happy to make changes / accept changes to this document > >> regardless. > > > > I think that the mailing list thing gained traction with a group of > > folks in the OAuth community and expanded through to JOSE+JWT and then > > the IoT analogues (COSE+CWT), at which point it was large enough that > > other unrelated groups started picking up on it (including TLS). > > There's nothing that requires having a mailing list, though it does > > give the community some visibility into the workings of the DE review > > process (as well as, depending on list permissions, a way to get > > notified about pending allocations). > > > > That said, the default behavior you get for a registry if you don't > > say otherwise, is that IANA is the first point of contact. That is, > > you ask IANA to allocate a value (usually via a webform), and behind > > the scenes IANA goes off and talks to the Experts, before acting on > > the decision of the Experts. Sometimes IANA has to relay questions > > and answers back and forth and it feels a bit silly, but that's the > > way it's historically been done. > > > > As a couple examples, RFC 7519 (JWT) creates jwt-reg-review@ietf.org, > > and https://datatracker.ietf.org/list/nonwg lists a few more. I don't > > think there is a perfect example yet of what text to use in the RFC > > when using this sort of review process, though -- the examples that > > come to mind still leave some ambiguity about what requestors and IANA > > are supposed to do. > > Thanks, that's helpful background. > > Ben, how would you feel about changing the language to read something > like: That seems fine to me. I care approximately zero about the details of the procedure, and just want it to be clear to everyone (especially the experts and IANA) what the procedure is. -Ben > Registry entries are to be evaluated using the Specification > Required method. All specifications must be be published prior to > entry inclusion in the registry. Once published, they can be > submitted directly to the krb5-spake-review@ietf.org mailing list, > where there will be a three-week long review period by Designated > Experts. > > Prior to the end of the review period, the Designated Experts must > approve or deny the request. This decision is conveyed to both IANA > and the submitter. Since the mailing list archives are not public, > it should include both a reasonably detailed explanation in the case > of a denial as well as whether the request can be resubmitted. > > (I'm not particularly attached to the mechanics of this. My concerns > are first requiring that a specification exists, and second that it be > checked for reasonableness without being too arduous for submitters.) > > Thanks, > --Robbie From nobody Wed Apr 29 14:38:17 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F2F3A18AB for ; Wed, 29 Apr 2020 14:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=gg1gDKMp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HSkPsHDS 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 o92TRjQq9xm3 for ; Wed, 29 Apr 2020 14:38:14 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6971D3A18BB for ; Wed, 29 Apr 2020 14:37:28 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AF6715C04BD; Wed, 29 Apr 2020 17:37:27 -0400 (EDT) Received: from imap34 ([10.202.2.84]) by compute7.internal (MEProxy); Wed, 29 Apr 2020 17:37:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm2; bh=BX ejSlO5EkponqijK94Bw9Ku4z/W7cnaewtrX2P7Ijc=; b=gg1gDKMpbEYHbu2ojt BVm6ZVuOACM/iTr56tfXlG/AupAy2dlLibYu2Gi4e2qxmmxR88igA3T6+XRyjMie owKtrC4sonptMwigh+BVu/2usP9n7fXIndMD3Cw9nOxT1sIlrJR6EIkyHk5Q/+zA TBXfcytJHvD2pyEOgRYb/BaqV+2fIduB5lskOo7RaB0cO91Hvvm5e3aR8Lys3Plo a5b+IelRTPRKN0JJflwPzg5kNQYxZ5x7Rsg/Ict/lM4JhUm7ZTfbatgopx65NNZR SjHm/J339MRXAIJDY6BNcS/oZeZHfaD9GG9Tz53fO2zlQDlQsinxUkCSDlaOrJyk j+zg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=BXejSlO5EkponqijK94Bw9Ku4z/W7cnaewtrX2P7I jc=; b=HSkPsHDSJkMatJPdgQ93DGsc7O4k5BtgseW16jZgmzZcjKb3gDQMRfTpN yi0/MOvw14mzz5iGucKjeKCYRmf6VVvybfZJOJ6deaWgNqanK6+FzVIEeqXE5NL6 sLjHe7ZDf3vkgK/EAwuE0rgWqUKA+/VxsfuAIIuFDE6nMwzr5G0xmBquxF3ERQ7L gwJRodOO/hvKRbPs27BUDb7Pc3LLt/5Ce2kQzGTOnrWefXvdcrUaHnHqWOhGjj1o dfdRmOcYtalXLSjqkoaS7UkZdSSAZuXxS70Km8yACEMTXT7R/41x4J880a74GDky GqvrnpWE7XEmYBYQdjP+hUlff87WA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieefgdduieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufgr mhcuhghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrg htthgvrhhnpedvffeuvdduhfefvdeiheeukeffhfekjeevgffggedtlefhhffhieevkedu vefhjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 10E3B1460061; Wed, 29 Apr 2020 17:37:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <23661358-b62e-40ed-b209-0551edf4ac8f@www.fastmail.com> In-Reply-To: References: Date: Wed, 29 Apr 2020 17:37:06 -0400 From: "Sam Whited" To: "Robbie Harwood" , "KITTEN Working Group" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] I-D: Best practices for password hashing and storage X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 21:38:16 -0000 On Wed, Apr 29, 2020, at 12:15, Robbie Harwood wrote: > In order for adoption to occur, I'd like to see expressed interest > from multiple folks in the WG (and a formal call for adoption). That sounds good; how does that normally happen? Should I start hounding= people, or is this email sufficient? (/cc Dave Cridland who I think is involved and who encouraged me to submit this I-D). Many thanks. =E2=80=94Sam --=20 Sam Whited From nobody Wed Apr 29 20:14:36 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78523A0EBD for ; Wed, 29 Apr 2020 20:14:22 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdF7M1QKc-pm for ; Wed, 29 Apr 2020 20:14:21 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6523A0EE8 for ; Wed, 29 Apr 2020 20:14:19 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03U3EFBQ030187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Apr 2020 23:14:18 -0400 Date: Wed, 29 Apr 2020 20:14:15 -0700 From: Benjamin Kaduk To: Sam Whited Cc: Robbie Harwood , KITTEN Working Group Message-ID: <20200430031415.GJ27494@kduck.mit.edu> References: <23661358-b62e-40ed-b209-0551edf4ac8f@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23661358-b62e-40ed-b209-0551edf4ac8f@www.fastmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [kitten] I-D: Best practices for password hashing and storage X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 03:14:24 -0000 On Wed, Apr 29, 2020 at 05:37:06PM -0400, Sam Whited wrote: > On Wed, Apr 29, 2020, at 12:15, Robbie Harwood wrote: > > In order for adoption to occur, I'd like to see expressed interest > > from multiple folks in the WG (and a formal call for adoption). > > That sounds good; how does that normally happen? Should I start hounding > people, or is this email sufficient? (/cc Dave Cridland who I think is > involved and who encouraged me to submit this I-D). I would probably give the original mail a week or so bake time and see what response it elicits before going out of your way to get further review. That said, if you know of people who would be interested but are not on this list, by all means invite them to comment here. -Ben From nobody Thu Apr 30 03:51:49 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D993A0934 for ; Thu, 30 Apr 2020 03:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 mYoOSWK3h49g for ; Thu, 30 Apr 2020 03:51:43 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E6C3A0930 for ; Thu, 30 Apr 2020 03:51:43 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id i10so6278540wrv.10 for ; Thu, 30 Apr 2020 03:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OwMNtZ4kVJ5izLNCZoEimVAS93C5JeVmV45Z8uADJaQ=; b=exWP2RRrS9R2q7ytNHLMB6QXeyg0jtKb+Fog5o2DrZvOKSex8yqr4FCSK6/uDbTlm2 oFr0/funl0YoyG2/GONfm/7DiAT7T/9ypmEk2pzzGqSdr8YOghJvmqHafCbqOYS9umuf ywYp24unME4gvG3hGHv8uN8HfOI0I2QShPffE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OwMNtZ4kVJ5izLNCZoEimVAS93C5JeVmV45Z8uADJaQ=; b=oLJI7LsNNSzOi0oGhU9GNHGAjnMFgE2IewS1zLIAZi1Y5VcyOcUG8+Cygx4wu/j6CL LDM/y/glmJO+K+9Y8dsMhG2oJg1UgQ8aHcXa4X3mdcFy5wV+S0ZcnpAblUJ9Z0YWqZG9 9QDoq9NQN+ez1ETXzxQLj/zAq10HnCXlPiIDzVMTySYo+hOxkgU/zPLhH8bD/xGNRJMZ FZeH02kSNRo3a8ytYcEByWzt9RZUbAHcbPkGa+I0/USPfSdXcP3U5eUX57qHk4ro23fO lFzpYDFnc8oaVd68zFJhNIrXljZpeeiDxaA8sPjjYN9/KqlQ9XEQFvrH8yziti9mXo6A cJhw== X-Gm-Message-State: AGi0PuZ+w5to1cIaOfJpGu+JMbSq/AFGjHwRem0QSEpzKjgmWLzZ+M2j WSU6bmFVUVq6bjY3sXl5rlU9zp7TqmueAPd19SOOrw== X-Google-Smtp-Source: APiQypL82Eeh8dFpQekBxFw80KqGai+XEfQS1ur3kO8YX2/JAggs+X4XrgrQg3wXiT0Ywj4FNWl1wUJ1s0VWQB4Nye4= X-Received: by 2002:a5d:54d0:: with SMTP id x16mr3301642wrv.86.1588243901487; Thu, 30 Apr 2020 03:51:41 -0700 (PDT) MIME-Version: 1.0 References: <23661358-b62e-40ed-b209-0551edf4ac8f@www.fastmail.com> <20200430031415.GJ27494@kduck.mit.edu> In-Reply-To: <20200430031415.GJ27494@kduck.mit.edu> From: Dave Cridland Date: Thu, 30 Apr 2020 11:51:30 +0100 Message-ID: To: Benjamin Kaduk Cc: Sam Whited , KITTEN Working Group Content-Type: multipart/alternative; boundary="00000000000090b24a05a47fd990" Archived-At: Subject: Re: [kitten] I-D: Best practices for password hashing and storage X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 10:51:46 -0000 --00000000000090b24a05a47fd990 Content-Type: text/plain; charset="UTF-8" A tiny bit of background: https://xmpp.org/extensions/inbox/password-storage.html was submitted to the XMPP Standards Foundation [think somewhere between an I-D publication and a WG adoption request], and while the Council [WG chair/IESG] is happy to accept it, pretty much everyone seems to agree that if this can go through IETF/KITTEN instead, it'll be a better document for it. But everything else that's taken this route has sunk without trace, so we're likely to publish the XEP (as Experimental - akin to WG I-D) anyway, and then we can retract it if it actually does take root here. At least on my part, this is an intentional policy change to ensure that the document is reviewed and published *somewhere*. Previously I have tended to block these kinds of documents and force them to the IETF (and KITTEN). As a result we have (for example) multiple SASL mechanism proposals effectively dead in the water, and so expediency somewhat forces this dual-publication approach. There are a number of people interested in this document in the XSF, but previous attempts having failed, we will have to spend some effort to encourage people from the XSF to come here and participate. I personally think that would be effort well-spent. Thanks, Dave. On Thu, 30 Apr 2020 at 04:14, Benjamin Kaduk wrote: > On Wed, Apr 29, 2020 at 05:37:06PM -0400, Sam Whited wrote: > > On Wed, Apr 29, 2020, at 12:15, Robbie Harwood wrote: > > > In order for adoption to occur, I'd like to see expressed interest > > > from multiple folks in the WG (and a formal call for adoption). > > > > That sounds good; how does that normally happen? Should I start hounding > > people, or is this email sufficient? (/cc Dave Cridland who I think is > > involved and who encouraged me to submit this I-D). > > I would probably give the original mail a week or so bake time and see what > response it elicits before going out of your way to get further review. > That said, if you know of people who would be interested but are not on > this list, by all means invite them to comment here. > > -Ben > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --00000000000090b24a05a47fd990 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A tiny bit of background:

https://xmpp.org/ext= ensions/inbox/password-storage.html=C2=A0was submitted to the XMPP Stan= dards Foundation [think somewhere between an I-D publication and a WG adopt= ion request], and while the Council [WG chair/IESG] is happy to accept it, = pretty much everyone seems to agree that if this can go through IETF/KITTEN= instead, it'll be a better document for it.

But everything else that's taken this route has sunk without trace, = so we're likely to publish the XEP (as Experimental - akin to WG I-D) a= nyway, and then we can retract it if it actually does take root here. At le= ast on my part, this is an intentional policy change to ensure that the doc= ument is reviewed and published *somewhere*. Previously I have tended to bl= ock these kinds of documents and force them to the IETF (and KITTEN). As a = result we have (for example) multiple SASL mechanism proposals effectively= =C2=A0dead in the water, and so expediency somewhat forces this dual-public= ation approach.

There are a number of people inter= ested in this document in the XSF, but previous attempts having failed, we = will have to spend some effort to encourage people from the XSF to come her= e and participate. I personally think that would be effort well-spent.

Thanks,

Dave.

=
On Thu, 30= Apr 2020 at 04:14, Benjamin Kaduk <kad= uk@mit.edu> wrote:
On Wed, Apr 29, 2020 at 05:37:06PM -0400, Sam Whited wrote:
> On Wed, Apr 29, 2020, at 12:15, Robbie Harwood wrote:
> > In order for adoption to occur, I'd like to see expressed int= erest
> > from multiple folks in the WG (and a formal call for adoption). >
> That sounds good; how does that normally happen? Should I start houndi= ng
> people, or is this email sufficient? (/cc Dave Cridland who I think is=
> involved and who encouraged me to submit this I-D).

I would probably give the original mail a week or so bake time and see what=
response it elicits before going out of your way to get further review.
That said, if you know of people who would be interested but are not on
this list, by all means invite them to comment here.

-Ben

_______________________________________________
Kitten mailing list
Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten
--00000000000090b24a05a47fd990-- From nobody Thu Apr 30 13:02:44 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF77F3A1225 for ; Thu, 30 Apr 2020 13:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=KGDrIC/m; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dRBVG7EA 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 t4q4gu0jRkpf for ; Thu, 30 Apr 2020 13:02:39 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA8B3A1220 for ; Thu, 30 Apr 2020 13:02:39 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CB9B15C0085 for ; Thu, 30 Apr 2020 16:02:37 -0400 (EDT) Received: from imap34 ([10.202.2.84]) by compute7.internal (MEProxy); Thu, 30 Apr 2020 16:02:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=mime-version:message-id:date:from:to:subject:content-type :content-transfer-encoding; s=fm2; bh=0SSGiKHtFOznRGtmR+2mBss0WH F0wdbbLCslICLCTSE=; b=KGDrIC/mHB7c9dVNZ6COJEiQZoIR2UNKIR/AY0aHol WK7TYSCWzrW/fWXZSU29dKT5YzFYyha5Yzr3aIGg9Rz5+Lp2XlGktXY7HLhNb5aq YSEj3Al8tqpK4LWVh8yuUsqRJPLmSmw8ADAhd43ezBB+H8qGMM/wjWKIZyPw4dmu 214qoUg90lcauY5TcgRVZcFowb59zFURmkTOyhu97dCyV9G4ttSYGN1CTuS6saNc 6r5lldtK87f/qQGj9nMCvgB7JUBg9p9dXhhK12yckLagEbLne8NMMdKBAmyb3Jl6 jcokWMRTAu8eUjAZ4HhqVVISmEn2cY5RFDKbyPxkPmaA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0SSGiK HtFOznRGtmR+2mBss0WHF0wdbbLCslICLCTSE=; b=dRBVG7EATSUpFOFgaPGX96 ApgaV0O8wuAIUk3k+TwLgixZBtueie2OcmAUYPA+dUYtG3sH/nduq23bGZ6bEgrX iGT2a6XQZY5/bcykTQuxNBB2RpieUdt7WhwzXcrw3CWhwh2yFy1YJncVYGVWLSYi 8A7+8ov5qRx8euxPH7k8n078eR+Kj9bbtH9dE9L4mx3sXtlHLmgG3fQqlquHVjVF 16LM828BsUxB+FCOf6L/B7ceJfpJcPxIOAE610KQmRrgxTRz1r7iaYy7N8glez2H wwrWr3+SkcRskqWe32ogLuDQoMRm9zYN7KdcU+Y44OVyMO+vB4Y3VY7en/BnQmzg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieehgddugedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufgrmhcu hghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrghtth gvrhhnpeeitdejkedtffekheejkeeiueeludfhtdfhveduuddvieeffeevheehudefjeet heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsrg hmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5652A1460061; Thu, 30 Apr 2020 16:02:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: Date: Thu, 30 Apr 2020 16:02:17 -0400 From: "Sam Whited" To: "KITTEN Working Group" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [kitten] TLS export for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 20:02:42 -0000 Hi all, I'm in need of a channel binding mechanism that works for TLS 1.3, but as far as I can tell there isn't one. I was thinking about defining a mechanism using RFC 5705 (which is updated by RFC 8446 so it should work= on both TLS 1.2 with appropriate cipher suites and 1.3 in general). Is anyone aware of work already being done in this area, and if I were to define a mechanism would it be a better fit for this working group or= for the tls WG? I know that exporters have some caveats around how to ensure uniqueness across different sessions, so this would likely require a great deal of expert review if it's a feasible mechanism at all and I wasn't sure where the best place to get that review would be. =E2=80=94Sam Thanks, Sam From nobody Thu Apr 30 19:17:36 2020 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A67B3A08E9; Thu, 30 Apr 2020 19:17:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: kitten@ietf.org Message-ID: <158829945413.28044.6822166056627459153@ietfa.amsl.com> Date: Thu, 30 Apr 2020 19:17:34 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-krb-spake-preauth-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 02:17:34 -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 WG of the IETF. Title : SPAKE Pre-Authentication Authors : Nathaniel McCallum Simo Sorce Robbie Harwood Greg Hudson Filename : draft-ietf-kitten-krb-spake-preauth-07.txt Pages : 37 Date : 2020-04-30 Abstract: This document defines a new pre-authentication mechanism for the Kerberos protocol that uses a password authenticated key exchange. This document has three goals. First, increase the security of Kerberos pre-authentication exchanges by making offline brute-force attacks infeasible. Second, enable the use of second factor authentication without relying on FAST. This is achieved using the existing trust relationship established by the shared first factor. Third, make Kerberos pre-authentication more resilient against time synchronization errors by removing the need to transfer an encrypted timestamp from the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-07 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-krb-spake-preauth-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-spake-preauth-07 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/