From nobody Sun Oct 1 16:53:57 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537101342DB for ; Sun, 1 Oct 2017 16:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 U4FEhQG4CCoo for ; Sun, 1 Oct 2017 16:53:54 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FBE1321A0 for ; Sun, 1 Oct 2017 16:53:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 8BE492B8BA; Sun, 1 Oct 2017 23:53:53 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo02-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKVOeReG5IQF; Sun, 1 Oct 2017 23:53:53 +0000 (UTC) Received: from macbook-air-2.lan (66-215-86-135.dhcp.psdn.ca.charter.com [66.215.86.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 945B22B865; Sun, 1 Oct 2017 23:53:46 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <20170930190208.GS96685@kduck.kaduk.org> Date: Sun, 1 Oct 2017 16:53:46 -0700 Cc: Simo Sorce , kitten@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170919015937.GN96685@kduck.kaduk.org> <1505920169.1143.15.camel@redhat.com> <20170923190527.GU96685@kduck.kaduk.org> <1506358991.3211.1.camel@redhat.com> <20170926022550.GZ96685@kduck.kaduk.org> <20170928022127.GF96685@kduck.kaduk.org> <8CDF104A-0D83-4B46-9016-E8ECA6F581D3@oxy.edu> <20170930190208.GS96685@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 23:53:56 -0000 In my mind, the bigger issue is if we will *ever* want a = non-deterministic checksum again. I=E2=80=99m unable to think of a = reason, but I don=E2=80=99t know what we don=E2=80=99t know that might = make us want such a thing. Not very satisfying.=20 Still, I vote we just prohibit 1DES+SPAKE and move on. > On Sep 30, 2017, at 12:02 PM, Benjamin Kaduk wrote: >=20 > On Sat, Sep 30, 2017 at 02:05:25AM -0700, Henry B (Hank) Hotz, CISSP = wrote: >>=20 >>> On Sep 27, 2017, at 7:21 PM, Benjamin Kaduk wrote: >>>=20 >>> As I understand it, there is not much (any?) modern software that = strictly >>> requires single-DES, but there are also many sites where the effort = to >>> upgrade has not been expended. Even in ATHENA.MIT.EDU, we have = cross-realm >>> keys that are actively used (albeit not for terribly critical = functionality) >>> that remain single-DES because of the logistical challenges involved = in >>> getting both KDC administrators in contact and with a trusted = channel. >>>=20 >>> -Ben >>=20 >> I know that kind of thing can be much harder than it seems it should. = OTOH, do you think that difficulty (as a specific example) should = prevent us from stipulating "no 1des with SPAKE=E2=80=9D? >=20 > No, I don't think examples of that sort should prevent us from placing > that restriction on SPAKE usage. >=20 > -Ben Personal email. hbhotz@oxy.edu From nobody Sun Oct 1 16:58:06 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4421342F1 for ; Sun, 1 Oct 2017 16:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 gn60IRvnTSYs for ; Sun, 1 Oct 2017 16:58:04 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B901321A0 for ; Sun, 1 Oct 2017 16:58:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id A88BC2B8EE; Sun, 1 Oct 2017 23:58:03 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo02-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo2WSM9ZFNln; Sun, 1 Oct 2017 23:58:03 +0000 (UTC) Received: from macbook-air-2.lan (66-215-86-135.dhcp.psdn.ca.charter.com [66.215.86.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 6738D2B8BA; Sun, 1 Oct 2017 23:57:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <20170930171203.GR96685@kduck.kaduk.org> Date: Sun, 1 Oct 2017 16:57:56 -0700 Cc: Greg Hudson , kitten@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <210B20CC-57FE-47CB-8142-57727F5F9CFB@oxy.edu> References: <20170928021534.GE96685@kduck.kaduk.org> <045c369b-491d-07b5-1615-d238e5efde51@mit.edu> <20170930171203.GR96685@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [kitten] Updating RFC 3961 to require deterministic checksums X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 23:58:06 -0000 Generally +1. Will want to proof the next draft of course. > On Sep 30, 2017, at 10:12 AM, Benjamin Kaduk wrote: >=20 > On Fri, Sep 29, 2017 at 05:42:09PM -0400, Greg Hudson wrote: >> On 09/27/2017 10:15 PM, Benjamin Kaduk wrote: >>> 4. Include instructions in the IANA considerations section to update = the >>> registration policy for the checksum type registry that notes the = additional >>> constraint on checksum behavior. >>=20 >> Proposed wording (at the beginning of the IANA considerations = section): >>=20 >> The notes for the "Kerberos Checksum Type Numbers" registry should = be >> updated with the following addition: "If the checksum algorithm is >> non-deterministic, see [this document] Section 4". >>=20 >> (where "Section 4" is an xref to the new "Update to Checksum >> Specifications" section from my previous message in this thread.) >=20 > Sounds good to me. >=20 > -Ben >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten Personal email. hbhotz@oxy.edu From nobody Tue Oct 3 08:16:37 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B3D134DCF for ; Tue, 3 Oct 2017 08:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 M9bLOExL_0O0 for ; Tue, 3 Oct 2017 08:16:28 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC76133341 for ; Tue, 3 Oct 2017 08:10:02 -0700 (PDT) X-AuditID: 12074422-45dff700000024ab-f0-59d3a84a7a05 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id E3.74.09387.A48A3D95; Tue, 3 Oct 2017 11:10:02 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v93FA10C001536 for ; Tue, 3 Oct 2017 11:10:01 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [10.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v93FA0cZ000798 for ; Tue, 3 Oct 2017 11:10:01 -0400 From: Greg Hudson To: kitten@ietf.org Date: Tue, 03 Oct 2017 11:10:00 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUixG6nouu14nKkwcl/zBZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr9XX5kKWqUrbv08wtLA+FG0i5GTQ0LARKLj5yTWLkYuDiGB xUwSH24+YIJwjjFKnFuyjhWkSkignUnizckcEJtNQFli/f6tLCC2iICwxO6t75hBbGEBQ4k7 u54xgdgsAqoSs15OBKvhBYpfal/DBGELSpyc+QQsziwgIXHwxQvmCYzcs5CkZiFJLWBkWsUo m5JbpZubmJlTnJqsW5ycmJeXWqRrqpebWaKXmlK6iREcBC5KOxgn/vM6xCjAwajEw3tjwuVI IdbEsuLK3EOMkhxMSqK8r5cBhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw/l4MlONNSaysSi3K h0lJc7AoifNuC9oVKSSQnliSmp2aWpBaBJOV4eBQkuBdthyoUbAoNT21Ii0zpwQhzcTBCTKc B2g4B0gNb3FBYm5xZjpE/hSjpJQ471OQiwRAEhmleXC9rxjFgV4Q5hUBaeMBRjRc1yuggUxA A+d0XQAZWJKIkJJqYExQ7WO+1PaSseDKNa4ZBhITnz2aKX7lm/qhm5G8LtNC3VIvGu47GnV4 Xt0Si7Tusky1Bekl/smvyq9Nee5/M02oz/b277ddXg6HWR3NVfz5GYOys+eFFt9IrOYN6V+r Jh3fu89Yv7pj7m+h11t7WdnSuJb0sXlVOPT2WLcavr70qJWTS3qhEktxRqKhFnNRcSIA42K/ VqUCAAA= Archived-At: Subject: [kitten] SPAKE preauth behavior on wrong password X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 15:16:36 -0000 In SPAKE preauth, the client sends a key confirmation in the SPAKEResponse message in the form of an encrypted SPAKESecondFacter message, using a derived key. If decryption succeeds, the client used the correct initial reply key. If it fails, the client probably used the wrong initial reply key, which may have resulted from the user entering the wrong password. (Less likely possibilities include parts of the AS exchange being altered in flight, or an interoperability bug.) The SPAKE draft currently says: If decryption is successful, the first factor is successfully validated. The KDC then validates the second factor. If either factor fails to validate, the KDC SHOULD respond with an appropriate KRB-ERROR message. I think "an appropriate KRB-ERROR message" is probably too vague, and we should specify what error code to use. That error code should probably be KDC_ERR_PREAUTH_FAILED, per RFC 4120 section 3.1.3 and RFC 6113 section 2. The draft also doesn't say what should be done in the second pass if the KDC doesn't support any of the client's groups. RFC 6113 section 2 encourages clients to continue trying to pre-authenticate after a PREAUTH_FAILED error, either using METHOD-DATA included in the error or by sending an unauthenticated reques to get METHOD-DATA. In context, the motivation for that recommendation may be optimistic preauth (the client might try to do opstimistic encrypted timestamp using the wrong salt, for instance), but that recommendation is also important if a multi-hop mechanism can fail to negotiate parameters. For instance, a client might send a SPAKESupport message and get back a PREAUTH_FAILED error because the KDC doesn't support any of the groups it offers. Following this recommendation has an unfortunate result when the wrong password is entered: the client will self-downgrade to encrypted timestamp (if the KDC offered it and the client allows it), unless it has specific logic not to try encrypted timestamp after a PREAUTH_FAILED reply to a SPAKEResponse message which used SF-NONE. A passive attacker could then mount an offline dictionary attack against the wrong password; from the incorrect password it might only take a few guesses to find the correct one. I think we just want to make a note of this in the security considerations. I therefore propose the following updates: * In the "Second Pass" subsection, after "... the KDC MAY select another group in hopes that the client might support it", add "Otherwise, the KDC MUST respond with a KDC_ERR_PREAUTH_FAILED error." * Change "SHOULD respond with an appropriate KRB-ERROR message" to "SHOULD respond with a KDC_ERR_PREAUTH_FAILED error". * In security considerations in the "Dictionary Attacks" subsection, add a second paragraph (after the one describing an active downgrade attack): If the user enters the wrong password, the client may fall back to encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error from the KDC, if encrypted timestamp is offered by the KDC and not disabled by client configuration. This fallback will enable a passive attacker to mount an offline dictionary attack against the incorrect password. Client implementations MAY assume that encrypted timestamp is unlikely to succeed if SPAKE pre-authentication fails in the second pass and no second factor was used. From nobody Tue Oct 3 09:53:19 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D32134F56 for ; Tue, 3 Oct 2017 09:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 HTfytZIw-Y_Z for ; Tue, 3 Oct 2017 09:53:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BD7134F2B for ; Tue, 3 Oct 2017 09:53:15 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BEEAC2CE901; Tue, 3 Oct 2017 16:45:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BEEAC2CE901 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=rharwood@redhat.com Received: from localhost (ovpn-116-190.phx2.redhat.com [10.3.116.190]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9456D6017C; Tue, 3 Oct 2017 16:45:18 +0000 (UTC) From: Robbie Harwood To: Greg Hudson , kitten@ietf.org In-Reply-To: References: Date: Tue, 03 Oct 2017 12:45:16 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 03 Oct 2017 16:45:19 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE preauth behavior on wrong password X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 16:53:17 -0000 --=-=-= Content-Type: text/plain Greg Hudson writes: > Following this recommendation has an unfortunate result when the wrong > password is entered: the client will self-downgrade to encrypted > timestamp (if the KDC offered it and the client allows it), unless it > has specific logic not to try encrypted timestamp after a PREAUTH_FAILED > reply to a SPAKEResponse message which used SF-NONE. A passive attacker > could then mount an offline dictionary attack against the wrong > password; from the incorrect password it might only take a few guesses > to find the correct one. I think we just want to make a note of this in > the security considerations. > > * In security considerations in the "Dictionary Attacks" subsection, add > a second paragraph (after the one describing an active downgrade > attack): > > If the user enters the wrong password, the client may fall back to > encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error > from the KDC, if encrypted timestamp is offered by the KDC and not > disabled by client configuration. This fallback will enable a > passive attacker to mount an offline dictionary attack against the > incorrect password. Client implementations MAY assume that encrypted > timestamp is unlikely to succeed if SPAKE pre-authentication fails > in the second pass and no second factor was used. I would be tempted to use "SHOULD" here rather than "MAY", but otherwise I think this is good. (The rest is fine by me as well.) Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlnTvpwACgkQJTL5F2qV pEKoZg//SCt+QC7YrcMJ8xMFuVmq3+jsBPXVmlreBrCuP2GiBvVtRfuY/OsdMXGS efLKQso+lSxQ1F3gYVb4FzLa1jc3B7xX2+bRRaxlOBEdTSWigFWhc0gTTt+aUTXY do1JfOIr0y+KTyLwRWqrrzu8bOe8Pie7oSt9am5ZUsKpzWiT1bW56zHRek21MNbx wmTppBKeCGKZAigzonxynlp7dQfydBrl5ioMMOPr/Ce+kqAKgF34pnPbfrlSkmDi gAUmABFB7zGvNg/5WI9wIPX/7twqTeln5eayxpRORWyzCxbU0t8p5DpLkdWAdgYI UNEXzUA7BXecyNDYPKtAQTu2FR5/X11GjhIDpRYWLaPGiyWXyd7vVxghEieYxBaE TBZd5cmby40IjXwH2X06PN6Mz7FYe9/HSw2/M/3OKxz/KyqK4dcdqsXHDvWcep60 6OK964zYQPNSIbPmf7mSEb9x5ARUQNm0wMaB4rQB5fLKGasx/KxzVeZGakUVglxA poXjuSDT9Mh1Alo9N4ZtDlUYZyXWdGnkNU0XOrT+bBUHAmGBdvq5DEs1gfpaqXwx /kUlYFG3Iqkc4XaKL9RQTpLSrPLF/1ZrJuDxuNI9exoMyP/C3G5vSAvkIMUv1TlO EGMPPB2iEGETPr7pyIlEwJ32e/USlT1D5glWSoYLlhyLesGBFYw= =m5Ul -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 3 11:03:00 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE86134FBA for ; Tue, 3 Oct 2017 11:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 Yp1WjWIjmczT for ; Tue, 3 Oct 2017 11:02:56 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CE7134FA3 for ; Tue, 3 Oct 2017 11:02:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 7573D2BE8F; Tue, 3 Oct 2017 18:02:55 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo02-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNr95P4K8P-7; Tue, 3 Oct 2017 18:02:55 +0000 (UTC) Received: from macbook-air-2.lan (66-215-86-135.dhcp.psdn.ca.charter.com [66.215.86.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 623402BB84; Tue, 3 Oct 2017 18:02:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: Date: Tue, 3 Oct 2017 11:02:48 -0700 Cc: kitten@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Greg Hudson X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [kitten] SPAKE preauth behavior on wrong password X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 18:02:58 -0000 > On Oct 3, 2017, at 8:10 AM, Greg Hudson wrote: >=20 > I therefore propose the following updates: >=20 > * In the "Second Pass" subsection, after "... the KDC MAY select = another > group in hopes that the client might support it", add "Otherwise, the > KDC MUST respond with a KDC_ERR_PREAUTH_FAILED error." >=20 > * Change "SHOULD respond with an appropriate KRB-ERROR message" to > "SHOULD respond with a KDC_ERR_PREAUTH_FAILED error". >=20 > * In security considerations in the "Dictionary Attacks" subsection, = add > a second paragraph (after the one describing an active downgrade > attack): >=20 > If the user enters the wrong password, the client may fall back to > encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error > from the KDC, if encrypted timestamp is offered by the KDC and not > disabled by client configuration. This fallback will enable a > passive attacker to mount an offline dictionary attack against the > incorrect password To be more explicit about the actual security implication, insert: = "which is likely close to the correct password." > . Client implementations MAY Agree with SHOULD instead of MAY.=20 > assume that encrypted > timestamp is unlikely to succeed if SPAKE pre-authentication fails > in the second pass and no second factor was used. Should we say anything about other, e.g. FAST-based alternatives? Personal email. hbhotz@oxy.edu From nobody Tue Oct 3 11:14:49 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC103133080 for ; Tue, 3 Oct 2017 11:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 1wGZZ9PzSozO for ; Tue, 3 Oct 2017 11:14:46 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B77613217D for ; Tue, 3 Oct 2017 11:14:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 78A7E4BA4E for ; Tue, 3 Oct 2017 18:14:45 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo03-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYg83vjmdt_l for ; Tue, 3 Oct 2017 18:14:45 +0000 (UTC) Received: from macbook-air-2.lan (66-215-86-135.dhcp.psdn.ca.charter.com [66.215.86.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 0A0EB4BA4F for ; Tue, 3 Oct 2017 18:14:43 +0000 (UTC) From: "Henry B (Hank) Hotz, CISSP" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 3 Oct 2017 11:14:42 -0700 To: "kitten@ietf.org " Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [kitten] Toward Depreciating Encrypted Timestamp X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 18:14:48 -0000 With SPAKE, on top of the earlier FAST and PKINIT work, we clearly are = headed toward obsoleting encrypted timestamp. Should we be considering = what other steps to take supporting this path? I=E2=80=99m just asking. Personally, I think we need some serious field = experience with SPAKE before we do anything else. It will take a = ridiculous number of years before we can assume the majority of clients = support SPAKE. Personal email. hbhotz@oxy.edu From nobody Tue Oct 3 12:17:23 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3191330AF for ; Tue, 3 Oct 2017 12:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn6d3-qeFKWp for ; Tue, 3 Oct 2017 12:17:21 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D32913239C for ; Tue, 3 Oct 2017 12:17:21 -0700 (PDT) X-AuditID: 1209190c-b45ff700000027a3-45-59d3e2404f2f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 3C.B4.10147.042E3D95; Tue, 3 Oct 2017 15:17:20 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v93JHJTn017356; Tue, 3 Oct 2017 15:17:19 -0400 Received: from [18.101.8.189] (VPN-18-101-8-189.MIT.EDU [18.101.8.189]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v93JHG7F002935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 3 Oct 2017 15:17:18 -0400 To: "Henry B (Hank) Hotz, CISSP" References: Cc: kitten@ietf.org From: Greg Hudson Message-ID: Date: Tue, 3 Oct 2017 15:17:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrevw6HKkQdNTIYuP9xayWBzdvIrF gcljyZKfTB5bm/4yBzBFcdmkpOZklqUW6dslcGUcPLWMveA+e8WKZ9PYGxgnsXUxcnJICJhI 3Nr0krWLkYtDSGAxk8SCmVtYIJwNjBLL/95nh3COMEn0r+tnAmkRFrCTWP+pgRHEFhEwlJi+ ciIriC0kkCSx7c8dZhCbWUBYYvmas2Ar2ASUJdbv38oCYvMKWElMPvgaaCgHB4uAisTPe8kg YVGBCImHnbvYIUoEJU7OfAJWzilgLdH76A8bxEg9iR3Xf7FC2PIS29/OYZ7AKDALScssJGWz kJQtYGRexSibklulm5uYmVOcmqxbnJyYl5dapGuol5tZopeaUrqJERyokjw7GM+88TrEKMDB qMTDe2PC5Ugh1sSy4srcQ4ySHExKorytD4BCfEn5KZUZicUZ8UWlOanFhxglOJiVRHhVLwPl eFMSK6tSi/JhUtIcLErivNuCdkUKCaQnlqRmp6YWpBbBZGU4OJQkePsfAjUKFqWmp1akZeaU IKSZODhBhvMADRcGqeEtLkjMLc5Mh8ifYtTluPHw+h8mIZa8/LxUKXHetyDXCYAUZZTmwc0B J5hUjr2vGMWB3hLmdQEZxQNMTnCTXgEtYQJaMqfrAsiSkkSElFQD4/XJPtuXBx+//7Rab01+ +YKty6ZvyVzzj1ffYl3p6sArKd8+sbdEzvGR/b9ok21k3JO4ruKK+1deLqvbmp7o8S1tYVTp LCfFzFmKHje4Dzw+tUOkfdXqWGaD5YvO3lt7f/cOz4+ChzSyuX+1TVnKyba9o6rkSMz0qacL t5Z6+pTZZ31hWbnNQ1GJpTgj0VCLuag4EQAVXZhpCwMAAA== Archived-At: Subject: Re: [kitten] SPAKE preauth behavior on wrong password X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 19:17:23 -0000 On 10/03/2017 02:02 PM, Henry B (Hank) Hotz, CISSP wrote: > To be more explicit about the actual security implication, insert: "which is likely close to the correct password." [...] > Agree with SHOULD instead of MAY. [...] > Should we say anything about other, e.g. FAST-based alternatives? Revised proposed security considerations text: If the user enters the wrong password, the client may fall back to encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error from the KDC, if encrypted timestamp is offered by the KDC and not disabled by client configuration. This fallback will enable a passive attacker to mount an offline dictionary attack against the incorrect password, which may be similar to the correct password. Client implementations SHOULD assume that encrypted timestamp and encrypted challenge are unlikely to succeed if SPAKE pre-authentication fails in the second pass and no second factor was used. From nobody Tue Oct 3 12:56:10 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB90126B6D for ; Tue, 3 Oct 2017 12:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0YzeYeGObrkv for ; Tue, 3 Oct 2017 12:56:07 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA161321A2 for ; Tue, 3 Oct 2017 12:56:07 -0700 (PDT) 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 mx1.redhat.com (Postfix) with ESMTPS id 8283A7F3E2; Tue, 3 Oct 2017 19:56:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8283A7F3E2 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=rharwood@redhat.com Received: from localhost (ovpn-116-190.phx2.redhat.com [10.3.116.190]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5359860606; Tue, 3 Oct 2017 19:56:07 +0000 (UTC) From: Robbie Harwood To: Greg Hudson , "Henry B \(Hank\) Hotz\, CISSP" Cc: kitten@ietf.org In-Reply-To: References: Date: Tue, 03 Oct 2017 15:56:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 03 Oct 2017 19:56:07 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE preauth behavior on wrong password X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 19:56:09 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Greg Hudson writes: > On 10/03/2017 02:02 PM, Henry B (Hank) Hotz, CISSP wrote: >> To be more explicit about the actual security implication, insert: "whic= h is likely close to the correct password." > [...] >> Agree with SHOULD instead of MAY.=20 > [...] >> Should we say anything about other, e.g. FAST-based alternatives? > > Revised proposed security considerations text: > > If the user enters the wrong password, the client may fall back to > encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error > from the KDC, if encrypted timestamp is offered by the KDC and not > disabled by client configuration. This fallback will enable a > passive attacker to mount an offline dictionary attack against the > incorrect password, which may be similar to the correct password. > Client implementations SHOULD assume that encrypted timestamp and > encrypted challenge are unlikely to succeed if SPAKE > pre-authentication fails in the second pass and no second factor > was used. Happy with this, thanks! =2D-Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlnT61UACgkQJTL5F2qV pELOAw/+Oiqo+ialmUmvBz/GVF9YffqTyazS/jRKA19PXqDKEoc6f98daIeemh47 3LlpKW+yh2I4nfUVGi2+anT4hQzRDwUUA5helhH/IcMJP6JdbKW1r8yYf0QoIcWh R5K2j9XNX6oGjEDySeuovrfB3h2uKM787u9c1m12ZcSlKY+UG5G195e2DaiDaIwQ OLHbfTBQmqByIu4fU7bLZuhYyTJZZhoBm2pjNMccE+Loyo8Qqu70UBCjhrDVN7ZF ZFp9rZ5bkFzKM62Ay8b7iXp6X8PSNqPDbGV+uu6B7tZuaVGCLNj/6ETXFwOF2Z/4 yYpJ8WEuzb50cZr8ezvU5CJutVJGyQBpV0D2Dw6loXGIkVvDqx1EcNCEnMNFo7ta rXf3UrF50r273jifgXeUSZQNwOgS+SLOo9oqX8HPncCTFf2jpJ2i9gm4Xv9y2mfe TWdrYHccsBURSiTOZUNWBTnj0bfvGBiUphpdDXSi1p5A8Qi02kQdxJyvK+eoHa3B te3YO3GLhRnhfnfvUTaYwV69o/79wO/ahlVSePtNRynFztmyJx6UWaiBcSpieYfs +OMXGunqMQ2hFExfxfX7Ogq1T1nGN/nWL71D8LmfTnSahQNUpIRFVCZXGCDfvYac KxNlDO3/E2/NAENf+IsWGdD8zI/TMJlmH8mKecSmI68zK3ZwcE8= =zwQs -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 3 18:17:16 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25652133083 for ; Tue, 3 Oct 2017 18:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ivDOY2ZHGkSo for ; Tue, 3 Oct 2017 18:17:14 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036A213232C for ; Tue, 3 Oct 2017 18:17:13 -0700 (PDT) X-AuditID: 12074422-06fff700000009a3-20-59d4369812ef Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id CB.B6.02467.89634D95; Tue, 3 Oct 2017 21:17:12 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v941HB4E029940; Tue, 3 Oct 2017 21:17:11 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v941H7nn001283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Oct 2017 21:17:09 -0400 Date: Tue, 3 Oct 2017 20:17:07 -0500 From: Benjamin Kaduk To: Robbie Harwood Cc: Greg Hudson , "Henry B (Hank) Hotz, CISSP" , kitten@ietf.org Message-ID: <20171004011706.GV96685@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tcC6YSqBgqqkz7Sb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAKsWRmVeSWpSXmKPExsUixCmqrTvD7EqkwcEH+hYf7y1ksTi6eRWL xc6eJlYHZo8lS34yeWxt+svs8X7fVbYA5igum5TUnMyy1CJ9uwSujNcvFzMWvBes+Hr4B1MD Yyd/FyMnh4SAiUTDrwOMILaQwGImibazrl2MXED2BkaJN4+nsUE4V5gk7u88wQJSxSKgItG9 oB+sgw3Ibui+zAxiiwhoSPTtWMUEYjMLZEls3PEIzBYWsJNY/6kBrJ4XaNubvU/ZIYZuYpSY c6iNCSIhKHFy5hMWiOYyibddP4E2cwDZ0hLL/3GAhDkFNCW+/JzGCmKLCihLzNu3im0Co8As JN2zkHTPQuiGCGtJ3Pj3kglDWFti2cLXzBC2rcS6de9ZFjCyr2KUTcmt0s1NzMwpTk3WLU5O zMtLLdI11cvNLNFLTSndxAiKDHYXpR2ME/95HWIU4GBU4uG9MeFypBBrYllxZe4hRkkOJiVR 3ummVyKF+JLyUyozEosz4otKc1KLDzGqAO16tGH1BUYplrz8vFQlEd5z6kB1vCmJlVWpRfkw ZdIcLErivNuCdkUKCaQnlqRmp6YWpBbBZGU4OJQkeDVBFggWpaanVqRl5pQgpJk4OA8xSnDw AA3/YAIyvLggMbc4Mx0if4pRUUqc1wOkWQAkkVGaB9cLSmgS2ftrXjGKA70lzJsJUsUDTIZw 3a+ABjMBDZ7TdQFkcEkiQkqqgdFEvi9Lct6Deo6j0/dKn1fQO/h76u2Ij7IzRa4fsYh+KmW5 sGHz8uyNAhyGzyT/uQUZSq/ukhbcned64VTO4YJPyx7oOq7SPMKdPmFS3km3yOzK32c/CRxe sX7CXuXzKyamn5eOPSayLyhFy2d5Z7r7YW/nN4lpkvk7T52Ysp5nya49a8tf5i5RYinOSDTU Yi4qTgQAq7Og+UMDAAA= Archived-At: Subject: Re: [kitten] SPAKE preauth behavior on wrong password X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 01:17:15 -0000 --tcC6YSqBgqqkz7Sb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 03, 2017 at 03:56:04PM -0400, Robbie Harwood wrote: > Greg Hudson writes: >=20 > > On 10/03/2017 02:02 PM, Henry B (Hank) Hotz, CISSP wrote: > >> To be more explicit about the actual security implication, insert: "wh= ich is likely close to the correct password." > > [...] > >> Agree with SHOULD instead of MAY.=20 > > [...] > >> Should we say anything about other, e.g. FAST-based alternatives? > > > > Revised proposed security considerations text: > > > > If the user enters the wrong password, the client may fall back to > > encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error > > from the KDC, if encrypted timestamp is offered by the KDC and not > > disabled by client configuration. This fallback will enable a > > passive attacker to mount an offline dictionary attack against the > > incorrect password, which may be similar to the correct password. > > Client implementations SHOULD assume that encrypted timestamp and > > encrypted challenge are unlikely to succeed if SPAKE > > pre-authentication fails in the second pass and no second factor > > was used. >=20 > Happy with this, thanks! Me, too. Though I would consider s/may/might/ in the first line, to appease people who dislike non-capitalized RFC 2119 terms. -Ben --tcC6YSqBgqqkz7Sb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlnUNowACgkQKNmm82Tr dRLWIAwfWm7OEPpvxPm8yEc0kNJp7sWuntXVoyBDyKOt8O2+psuHRcXl6bjCTDeN /hEyjpU4TUc7ARluIiNl83+oCCp/m/bQ/YsoH6WV37pgQW30wzGapl9llC3iwDoY +GPdfjdIOFkz3sRsUXXa7+5oQYQts7yfog9WpWMLmXHURWHQTx2xF9KT3ds5j+rd tFgcU9d7gG6LzgfMxmo/vVMOFRoCZz3ZBO1Jq5Hqja/iF+e2Wn0QENFiW+VmH+sD 7Q99UyhvBIyx4eqhuumvKhLMEsSW2r6qDPn5GrO2Om/ObpEYa8FVOGDQn2OEhq4i YNetlKt5f29CKjumYY1G4pGPF+qkQBa7Sx9zAxWjqlAF2c9lAlz79vgkgfZdvcHm t6H40vgLA0XA5jh34eDd28cxCYWLGOF2CwR+FG0EFpqkTkb8w/XW1OSvkWKJzB5e bR2nzWCxWZEJgFueftsd4ic1jRDZaxPrzjd1hDPPL+y3VH2zTCZPcHzq13Nrcyy4 f1tKgRiUT5ROJA== =iDdC -----END PGP SIGNATURE----- --tcC6YSqBgqqkz7Sb-- From nobody Tue Oct 3 19:03:24 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A564913308D for ; Tue, 3 Oct 2017 19:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, 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 SQ9C-5vrLqyE for ; Tue, 3 Oct 2017 19:03:21 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 7FD281201F8 for ; Tue, 3 Oct 2017 19:03:21 -0700 (PDT) X-AuditID: 1209190f-e3dff70000006c68-c3-59d44168d892 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.1A.27752.86144D95; Tue, 3 Oct 2017 22:03:20 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v9423JZt000767; Tue, 3 Oct 2017 22:03:19 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9423GAp014046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Oct 2017 22:03:18 -0400 Date: Tue, 3 Oct 2017 21:03:16 -0500 From: Benjamin Kaduk To: "Henry B (Hank) Hotz, CISSP" Cc: "kitten@ietf.org " Message-ID: <20171004020316.GX96685@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT181wvBJpcOG3tMXHewtZLI5uXsXi wOSxZMlPJo+tTX+ZA5iiuGxSUnMyy1KL9O0SuDJmXJnCXDCNreLJ8eWsDYy/WLoYOTkkBEwk 5vz4w9TFyMUhJLCYSeJ4zwwWCGcDo8SeW4cYIZwrTBKfXq5iAmlhEVCROLD7Plg7G5Dd0H2Z GcQWETCUmL5yImsXIwcHs4ClxKnFmSBhYQFbiY93u5lBwrxA2242R4CEhQSsJFqX32EFsXkF BCVOznwCNpFZQF3iz7xLzBBTpCWW/+OACMtLNG+dDbaIU8BaYu6l5WDHiAooS8zbt4ptAqPg LCSTZiGZNAth0iwkkxYwsqxilE3JrdLNTczMKU5N1i1OTszLSy3SNdHLzSzRS00p3cQICmlO Sf4djHMavA8xCnAwKvHw3phwOVKINbGsuDL3EKMkB5OSKO8X6yuRQnxJ+SmVGYnFGfFFpTmp xYcYJTiYlUR4z6kD5XhTEiurUovyYVLSHCxK4rzbgnZFCgmkJ5akZqemFqQWwWRlODiUJHiL HIAaBYtS01Mr0jJzShDSTBycIMN5gIbz2oMMLy5IzC3OTIfIn2LU5bjx8PofJiGWvPy8VClx XmOQQQIgRRmleXBzQKlIInt/zStGcaC3hHnZQap4gGkMbtIroCVMQEvmdF0AWVKSiJCSamCc Izix2m9ZyW7L2qCVHcnfrh193voxWerA8ju9j5/ujv9/8diShMN6s3/JdH6RLt1huuZT/bUW rat/N/veYWfnash8KiH6s/rw/YaPE94wPZltLezzun1B3+LzC2R63wsac/6OXN4gvjy/3H/R jvDGU9mp393W/3+ptk36blL8SaUn7QmLniZ/UmIpzkg01GIuKk4EAOEszpwgAwAA Archived-At: Subject: Re: [kitten] Toward Depreciating Encrypted Timestamp X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 02:03:23 -0000 On Tue, Oct 03, 2017 at 11:14:42AM -0700, Henry B (Hank) Hotz, CISSP wrote: > With SPAKE, on top of the earlier FAST and PKINIT work, we clearly are headed toward obsoleting encrypted timestamp. Should we be considering what other steps to take supporting this path? We should probably be considering it, yes. > I’m just asking. Personally, I think we need some serious field experience with SPAKE before we do anything else. It will take a ridiculous number of years before we can assume the majority of clients support SPAKE. But I agree that we probably will need more field experience before we can say a whole lot -- we have some experience with FAST and that it's not a whole lot of fun to deploy in large environments. Maybe SPAKE will be better; maybe not. -Ben From nobody Tue Oct 3 20:05:14 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2728813307D for ; Tue, 3 Oct 2017 20:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 4D5pewEFVfc9 for ; Tue, 3 Oct 2017 20:05:11 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD541321A1 for ; Tue, 3 Oct 2017 20:05:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id DEEFCCB1C5; Wed, 4 Oct 2017 03:05:10 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo01-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duZz77H4MstC; Wed, 4 Oct 2017 03:05:10 +0000 (UTC) Received: from macbook-air-2.lan (66-215-86-135.dhcp.psdn.ca.charter.com [66.215.86.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id B3184CB1C2; Wed, 4 Oct 2017 03:05:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <20171004011706.GV96685@kduck.kaduk.org> Date: Tue, 3 Oct 2017 20:05:00 -0700 Cc: Robbie Harwood , Greg Hudson , kitten@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171004011706.GV96685@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [kitten] SPAKE preauth behavior on wrong password X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 03:05:13 -0000 Also happy. Abstain on the /may/might/ issue. > On Oct 3, 2017, at 6:17 PM, Benjamin Kaduk wrote: >=20 > On Tue, Oct 03, 2017 at 03:56:04PM -0400, Robbie Harwood wrote: >> Greg Hudson writes: >>=20 >>> On 10/03/2017 02:02 PM, Henry B (Hank) Hotz, CISSP wrote: >>>> To be more explicit about the actual security implication, insert: = "which is likely close to the correct password." >>> [...] >>>> Agree with SHOULD instead of MAY.=20 >>> [...] >>>> Should we say anything about other, e.g. FAST-based alternatives? >>>=20 >>> Revised proposed security considerations text: >>>=20 >>> If the user enters the wrong password, the client may fall back = to >>> encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED = error >>> from the KDC, if encrypted timestamp is offered by the KDC and = not >>> disabled by client configuration. This fallback will enable a >>> passive attacker to mount an offline dictionary attack against = the >>> incorrect password, which may be similar to the correct password. >>> Client implementations SHOULD assume that encrypted timestamp and >>> encrypted challenge are unlikely to succeed if SPAKE >>> pre-authentication fails in the second pass and no second factor >>> was used. >>=20 >> Happy with this, thanks! >=20 > Me, too. >=20 > Though I would consider s/may/might/ in the first line, to appease = people > who dislike non-capitalized RFC 2119 terms. >=20 > -Ben Personal email. hbhotz@oxy.edu From nobody Wed Oct 4 05:05:34 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E775A1332D4 for ; Wed, 4 Oct 2017 05:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.521 X-Spam-Level: X-Spam-Status: No, score=-5.521 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 NO7Zm5kLWJSX for ; Wed, 4 Oct 2017 05:05:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0160013421F for ; Wed, 4 Oct 2017 05:05:27 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8E988780CE; Wed, 4 Oct 2017 12:05:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8E988780CE Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=simo@redhat.com Received: from ovpn-116-226.phx2.redhat.com (ovpn-116-226.phx2.redhat.com [10.3.116.226]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 292F062664; Wed, 4 Oct 2017 12:05:26 +0000 (UTC) Message-ID: <1507118725.10229.36.camel@redhat.com> From: Simo Sorce To: Benjamin Kaduk , "Henry B (Hank) Hotz, CISSP" Cc: "kitten@ietf.org " Date: Wed, 04 Oct 2017 08:05:25 -0400 In-Reply-To: <20171004020316.GX96685@kduck.kaduk.org> References: <20171004020316.GX96685@kduck.kaduk.org> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 04 Oct 2017 12:05:26 +0000 (UTC) Archived-At: Subject: Re: [kitten] Toward Depreciating Encrypted Timestamp X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 12:05:33 -0000 On Tue, 2017-10-03 at 21:03 -0500, Benjamin Kaduk wrote: > On Tue, Oct 03, 2017 at 11:14:42AM -0700, Henry B (Hank) Hotz, CISSP > wrote: > > With SPAKE, on top of the earlier FAST and PKINIT work, we clearly > > are headed toward obsoleting encrypted timestamp. Should we be > > considering what other steps to take supporting this path? > > We should probably be considering it, yes. Agree, but we'll need a few years of solid SPAKE use first IMHO. > > I’m just asking. Personally, I think we need some serious field > > experience with SPAKE before we do anything else. It will take a > > ridiculous number of years before we can assume the majority of > > clients support SPAKE. > > But I agree that we probably will need more field experience before > we can say a whole lot -- we have some experience with FAST and that > it's not a whole lot of fun to deploy in large environments.  Maybe > SPAKE will be better; maybe not. Well I sure hope it will be better as the reason we came up with it was strongly influenced by the pain of using/deploying FAST and we wanted something that would be more seamless. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Wed Oct 4 11:42:33 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6451330C1 for ; Wed, 4 Oct 2017 11:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=brandenwilliams.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 QWP7rMnGzWu1 for ; Wed, 4 Oct 2017 11:42:30 -0700 (PDT) Received: from mail.kickinit.net (altair.brw.net [64.129.152.237]) by ietfa.amsl.com (Postfix) with ESMTP id B1BA113432B for ; Wed, 4 Oct 2017 11:42:30 -0700 (PDT) Received: from [10.4.1.126] (mpscfw.uboc.com [216.52.215.232]) (Authenticated sender: brw) by mail.kickinit.net (Postfix) with ESMTPSA id 311ED360FE0 for ; Wed, 4 Oct 2017 13:42:30 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=brandenwilliams.com; s=201709; t=1507142550; bh=KeuWW+4rq/qAKH6Ozwoi8PNtfUsT7Y/vMrzN/btXpSI=; h=From:Subject:Date:References:To:In-Reply-To:From; b=zuZGN+KAcALPELoi9+ugJ5X81e1A942N5lwKG1gdBOlXJ/QgiX9T3FeKGvwGWdBOE w8Wij9GYpUmE+czAnx22ay/Daqw/rTAl3c49J/f4Q8OaN41GTqq0l9g3Gk2k5H9BN4 fHqHM8nR8LSgR6Cc8kwLbXm5FZ3/Mq+ECV7eOfUbSyJXAP7FtIFBv6NoHAbsGjTZZf xTk4E2RMkvaQcQgSJvMaMlFR/qxPR+z2OXLS9VwPiMdK98iV5OKe6Wy0VUoEqEfJ1a BWOtD2KS8YDc5k5KH9GmcqSQ15a88ho6sqn6muCsfrwprRaSzT7luzln3csakO9hpm xFtw+hpvux1Ng== From: "Branden R. Williams" Content-Type: multipart/alternative; boundary="Apple-Mail=_0E591CD5-147D-484F-8E6C-466C9FA50D33" X-Mao-Original-Outgoing-Id: 528835349.388194-e08caeec42e4a714483c95b51d6ec0b2 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Message-Id: Date: Wed, 4 Oct 2017 13:42:29 -0500 References: <6671C116-6813-4D0E-A8B1-4D93EB8D2E7A@brandenwilliams.com> To: kitten@ietf.org In-Reply-To: <6671C116-6813-4D0E-A8B1-4D93EB8D2E7A@brandenwilliams.com> X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [kitten] New Draft: Open Password Automation Recipe (OPAR) Protocol X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 18:42:32 -0000 --Apple-Mail=_0E591CD5-147D-484F-8E6C-466C9FA50D33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI, I realized a typo in the draft that includes two examples, both = labeled as example 1. Will fix if this goes through. Regards, Branden R. Williams, DBA, CISSP, CISM brw@brandenwilliams.com Phone: +1 (214) 727-8227 http://www.brandenwilliams.com/ > On Sep 26, 2017, at 11:05 AM, Branden Williams = > wrote: >=20 > Good day! > =20 > I=E2=80=99m happy to announce my first I-D submission here: = https://tools.ietf.org/html/draft-bwilliams-kitten-opar-00 = > =20 > Problem Description: > There is no standard way for a Password Manager (1Password, LastPass, = etc.) to understand what constitutes a compliant password on a site to = site basis. Often times, the format that it suggests does not comply = with the website=E2=80=99s password policy (wrong special characters, = wrong length, wrong count of upper v. lower v. numbers). The attached = proposal attempts to solve this by allowing website owners to embed = their password policy programmatically into a JSON object that a = password manager can read to automatically suggest a strong and = compliant password. This would promote usability of password managers as = well as improve the user experience. (Note: I do not work for any = company that creates a password manager.) > =20 > Success: > Publication of this doc as a Proposed Standard. This would allow = website owners to programmatically describe compliant passwords so = password managers can suggest, transmit, and store the maximum strength = compliant password possible for the website. Ideally, all developers = that build password managers could implement the standard to improve = their user experience. This could potentially also improve user = experience for those with ADA (or non-US equivalent) requirements. > =20 > Discussion: > Please discuss here on kitten@ietf.org ! As = this is my first submission, I am open to any and all comments. > =20 > Regards, > =20 > Branden R. Williams, DBA, CISSP, CISM > brw@brandenwilliams.com > Phone: +1 (214) 727-8227 > =20 > http://www.brandenwilliams.com/ = _________________________________________= ______ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten = --Apple-Mail=_0E591CD5-147D-484F-8E6C-466C9FA50D33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI, = I realized a typo in the draft that includes two examples, both labeled = as example 1. Will fix if this goes through.

Regards,

Branden R. Williams, DBA, CISSP, CISM
brw@brandenwilliams.com
Phone: +1 (214) = 727-8227

http://www.brandenwilliams.com/



On Sep 26, 2017, at 11:05 AM, Branden Williams <brw@brandenwilliams.com> wrote:

Good day!
 
I=E2=80=99m happy = to announce my first I-D submission here: https://tools.ietf.org/html/draft-bwilliams-kitten-opar-00<= o:p class=3D"">
 
Problem = Description:
There is no = standard way for a Password Manager (1Password, LastPass, etc.) to = understand what constitutes a compliant password on a site to site = basis. Often times, the format that it suggests does not comply with the = website=E2=80=99s password policy (wrong special characters, wrong = length, wrong count of upper v. lower v. numbers). The attached proposal = attempts to solve this by allowing website owners to embed their = password policy programmatically into a JSON object that a password = manager can read to automatically suggest a strong and compliant = password. This would promote usability of password managers as well as = improve the user experience. (Note: I do not work for any company that = creates a password manager.)
 
Success:
Publication of this doc as a = Proposed Standard. This would allow website owners to programmatically = describe compliant passwords so password managers can suggest, transmit, = and store the maximum strength compliant password possible for the = website. Ideally, all developers that build password managers could = implement the standard to improve their user experience. This could = potentially also improve user experience for those with ADA (or non-US = equivalent) requirements.
 
Discussion:
Please discuss here on kitten@ietf.org! As this is = my first submission, I am open to any and all comments.
 
Regards,
 
Branden R. = Williams, DBA, CISSP, CISM
brw@brandenwilliams.com
Phone: +1 (214) 727-8227
 
_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

= --Apple-Mail=_0E591CD5-147D-484F-8E6C-466C9FA50D33-- From nobody Thu Oct 5 14:26:39 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA8B1331E4; Thu, 5 Oct 2017 14:26:38 -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.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150723879815.6094.11894643798750827190@ietfa.amsl.com> Date: Thu, 05 Oct 2017 14:26:38 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-channel-bound-flag-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 21:26:38 -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 : Channel Binding Signalling for the Generic Security Services Application Programming Interface Authors : Robbie Harwood Nicolas Williams Filename : draft-ietf-kitten-channel-bound-flag-02.txt Pages : 9 Date : 2017-10-05 Abstract: Channel binding is a technique that allows applications to use a secure channel at a lower layer without having to use authentication at that lower layer. The concept of channel binding comes from the Generic Security Services Application Programming Interface (GSS- API). It turns out that the semantics commonly implemented are different than those specified in the base GSS-API RFC (RFC2743), and that that specification has a serious bug. This document addresses both the inconsistency as-implemented and the specification bug. This Internet-Draft proposes the addition of a "channel bound" return flag for the GSS_Init_sec_context() and GSS_Accept_sec_context() functions. Two behaviors are specified: a default, safe behavior reflecting existing implementation deployments, and a behavior that is only safe when the application specifically tells the GSS-API that it (the application) supports the new behavior. Additional API elements related to this are also added, including a new security context establishment API. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-channel-bound-flag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-flag-02 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-channel-bound-flag-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-channel-bound-flag-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 15 19:51:27 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED96213339D for ; Sun, 15 Oct 2017 19:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 AIVTcQysqQaw for ; Sun, 15 Oct 2017 19:51:24 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF94126BF3 for ; Sun, 15 Oct 2017 19:51:24 -0700 (PDT) X-AuditID: 1209190d-9c7ff70000006482-8e-59e41eaa58c8 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id E0.7C.25730.BAE14E95; Sun, 15 Oct 2017 22:51:23 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v9G2pLlm018024; Sun, 15 Oct 2017 22:51:22 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9G2pHZ7020947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Oct 2017 22:51:19 -0400 Date: Sun, 15 Oct 2017 21:51:17 -0500 From: Benjamin Kaduk To: Florian Schmaus Cc: kitten@ietf.org, Peter Saint-Andre , XMPP Standards , Christoph Egger Message-ID: <20171016025117.GL96685@kduck.kaduk.org> References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9DptZICXTlJ7FQ09" Content-Disposition: inline In-Reply-To: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDKsWRmVeSWpSXmKPExsUixCmqrbta7kmkwZ0DvBaP32tZfNtxk8ni 6OZVLBaPjs9nsTi2p5/ZgdVj5sa3jB6Hri5m81iy5CeTx9w9L5g97ngHsEZx2aSk5mSWpRbp 2yVwZWz6HFFwS7piwq7fzA2MR8S7GDk5JARMJObMvcMOYgsJLGaSmH7fpIuRC8jeyCjxY3s7 K4RzlUnix8EFLCBVLAKqEpdermAFsdkEVCQaui8zg9giAmoSZ5asYANpYBboYZSYvec/WIOw gL3EpPdHGUFsXqB1U6acZ4VYZy/RsquHGSIuKHFy5hOwemaBMomD394B2RxAtrTE8n8cIGFO AQeJ+xt2gJWLCihLzNu3im0Co8AsJN2zkHTPQuiGCGtJ3Pj3kglDWFti2cLXzBC2rcS6de9Z FjCyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI10svNLNFLTSndxAiOHEneHYz/7nodYhTgYFTi 4V1x7nGkEGtiWXFl7iFGSQ4mJVHec60PI4X4kvJTKjMSizPii0pzUosPMaoA7Xq0YfUFRimW vPy8VCUR3r3STyKFeFMSK6tSi/JhyqQ5WJTEebcF7YoUEkhPLEnNTk0tSC2CycpwcChJ8F6U BWoULEpNT61Iy8wpQUgzcXAeYpTg4AEaPgGkhre4IDG3ODMdIn+KUZfj2KbLf5iEwC6QEue1 ASkSACnKKM2DmwNKhBLZ+2teMYoDvSjMOxGkigeYROEmvQJawgS05F3EA5AlJYkIKakGxpI5 Cxca5FjNOyhQuPCg0ptVObf02+wS4s7qnItadNqmml1p8gcet5ZZ39ZMvq6+wvqdhOyzktUR 8wsCj0wNMkz/snCzVreh4Am+Rw0sS/+qx5tdrpzjxqnGGZF6KmBHRr3Y7pS/NTFT1PQto+x7 cn7te8b5Ju7LmjvL55vpdtg2NS00v58dosRSnJFoqMVcVJwIAOw9plBfAwAA Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 02:51:26 -0000 --9DptZICXTlJ7FQ09 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2017 at 11:08:10AM +0200, Florian Schmaus wrote: > I would like to note the existence of draft-schmaus-kitten-sasl-ht-01: >=20 > https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01 Thanks, I just got a chance to look it over. [...] > Thus we initially authenticate an XMPP session using a strong mechanism > like SCRAM, but at resumption-time we want a single round trip > mechanism. The basic idea of such a mechanism is that the client > requests a short-lived, exclusively ephemeral token after being > authenticated, which can be used to authenticate the resumption in an > efficient manner. [...] > The SASL HT-* mechanism outlined is attempting to provide a reasonably > secure authentication based around a token obtained over the application > protocol, in a single round-trip. This single-round-trip is a key > requirement. The proposal uses a single-use token as a shared secret, > provides channel binding and mutual authentication. There does seem to be some value in having a fast "session resumption" SASL mechanism to avoid repeated reauthentication (though presumably there should be some guidance to periodically require a full authentication; various flows elsewhere do this on a month timescale, roughly). It's a little unfortunate that this ends up requiring TLS for confidentiali= ty (as there is some desire to have standalone mechanisms), but that seems to be an acceptable tradeoff for this sort of application. Putting my kitten WG chair hat on for a moment, it does seem like this work would be in scope with our current charter (https://datatracker.ietf.org/doc/charter-ietf-kitten/), which gives us a pretty wide berth for giving "guidance for any new SASL-related submissions". That said, it is not really appropriate for us to accept new work without a critical mass of people willing to participate/review that work. This document seems simple and straightforward enough that it would not take too much work to get it ready, but we would need to find a couple more people who are willing to review it before we could adopt it as a WG document. (Noting the standards@xmpp cc, I'll explictly state that since participation in IETF working groups is entirely open, so there is no requirement of having previously been a WG participant for this purpose.) Without my chair hat, the document is a little rough in some places, but it should be pretty straightforward to clean up. I do appreciate the reference to RFC 6919 in particular, but it should really only be cited by other "April 1st" RFCs. -Ben --9DptZICXTlJ7FQ09 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlnkHpoACgkQKNmm82Tr dRI6YwwcD8UySSrD/5JMLZBpTQD46yGnKmFv3FoaE40HobiaLmtNWpVCydPHty0E JNmQKKw2ZWj1Gt/YYKedsLkGyFhGSrqgnyjdl5S2FBvF6iKGiPGZyvdZvcaGlg80 F+fKB8Ezs5CGtSsZHhSWho4TIM7JT9IQjkvyLq1IRZQ4LLiuehmzJ3H2ClrIj8Pl deoESeMZechEMfQiYhdxDa3Jx+mh8g7FArhkdTMuao1ZZ6aQuNp3ODS9u2vb9DJH BOaEbRmhSPqsmhupSgYW/asVmNMO49aNuWFhFnX+Z9TmE5KxlJgkwNGfyQHzU6Gw cxo7nTKFQy/tuHL9Oo7gnUsQBxI+5o1GCSBZUvMMxOq1P8pUOKGzpXkGfCsHUNaB wveP3iVlkb6GHPj30leOMn/zqXEJtIFGrGXC3Y9KUJXoyz9F3PwV5mTuO1eRtjl7 QHq03t41yr3Bje37RjVdOCIcSVLvYfaEgv+TAJuNChPYLvT1JK0wwKX5bkT8o0G6 ncUrNB2rQ0uiVw== =eAYx -----END PGP SIGNATURE----- --9DptZICXTlJ7FQ09-- From nobody Mon Oct 16 08:21:33 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAEC13303F for ; Mon, 16 Oct 2017 08:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=2uwF5cVI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LJQEI3a2 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 au8cAzvH3NOt for ; Mon, 16 Oct 2017 08:21:31 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3A613234B for ; Mon, 16 Oct 2017 08:21:31 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 96C4620D06 for ; Mon, 16 Oct 2017 11:21:30 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Mon, 16 Oct 2017 11:21:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=BiSXjJOsm+2prvVawdxwKETuClgPw selE1/AUDRc5K8=; b=2uwF5cVIAReqXwo3mjNf7/guqNzHo9weUQLUZyfuZW08+ PnfLWyZMMIr1C8t/ZxUuzBJVIsmVb95XPOrkB1LMQOpIARmqo1xlfD1jBfe7WDOY lB+Kb4dq1r3OXL0QXQ6jlYG8756T9QFJf5mXL9zRTP6baBc7cebvyxHm6I5nzuvQ LbRay946I6gWSARusirpTTAj7KW6xoVHceRdBlo5omw+maN4qaayufaihmirVmVC lYegzcV16quocz+wPArJQlJv9zxBdnb2kupH352BNJKYJAdHt768hxIPcgzBQTTu myCYrL0/9bEzftE8yfYG+LrvGSsGr6Pdx2Ld7Kisw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=BiSXjJ Osm+2prvVawdxwKETuClgPwselE1/AUDRc5K8=; b=LJQEI3a2wZmI3rNYr5Hrst 1H9yvZPaBX01QwtdT91Kx3+eFwDrpcJuqZ7FWkKln+nBoUZM90imiS1SLVC/1/ib UNqfyc5xw2yOgJJJPkO0WiJa/ntww3hQlWAN/E77eNXbxA3NBozArMu+wdCcynh7 /ixuN6iXiDvaXpB8z2YkR1Yq5ijZ8+yDIZsNriS76zit5HRjtDZGcOHVgEI5EVMK XhrKoII1ItCjdAyw3qEaqPhfeX1raMq4v04WuB087LLsxRaZsfRT4svykrOWETgP rPlPyx9TFiyYldNm42X3Nr5PM0eS1ircwa97oAefPh+Jcx+DotKcDo82mFZ7F/QA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 74AB99E303; Mon, 16 Oct 2017 11:21:30 -0400 (EDT) Message-Id: <1508167290.1393178.1140436312.7DF3E796@webmail.messagingengine.com> From: Sam Whited To: kitten@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-26fdae60 In-Reply-To: <20171016025117.GL96685@kduck.kaduk.org> References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <20171016025117.GL96685@kduck.kaduk.org> Date: Mon, 16 Oct 2017 10:21:30 -0500 Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 15:21:32 -0000 On Sun, Oct 15, 2017, at 21:51, Benjamin Kaduk wrote: > That said, it is not really appropriate for us to accept > new work without a critical mass of people willing to participate/review > that work. I have an interest in implementing this and can commit to reviewing this document and providing feedback as new versions are released. =E2=80=94Sam From nobody Tue Oct 17 01:19:07 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733741326FE for ; Tue, 17 Oct 2017 01:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ8BDHIvJsnM for ; Tue, 17 Oct 2017 01:19:05 -0700 (PDT) Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) (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 67451126CB6 for ; Tue, 17 Oct 2017 01:19:05 -0700 (PDT) Received: by mail-wm0-f45.google.com with SMTP id b189so2077403wmd.4 for ; Tue, 17 Oct 2017 01:19:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:cc:message-id:date :user-agent:mime-version:in-reply-to; bh=w163+wK3UmIM8YJYhPxZ6adY7cyQ/m6nPtY8b3iQsvI=; b=hCjl4D7WAhYqftNxjmhOuWyMTKvR3Q1nJDaHpDjA1+5A5p6ylA8dY8tQkT2rS5uypN 4AYkv1AVfFABDIFWe5j049LKN0AXzkgKSb04GCf1WRepDv/TQNRRDGafZEySY6o5s7Sq m2ti+oQAvVn+Va2Yvx/Li4s/kR9sXgtltTfgnCJAj5ztzsYDNa+AIPG95ad53uyXyb20 KCy7yP7r6JoBN1BUThgfgBZmAyivDWVVaOd08jLOwmijW/Fh1vqXsQcsguPnVWY0po2L GPnC1nMM9zI7An/BmkZuPmSHXkVwp9JAsRst0G6uxWDz9xcz+hu7wOFMgoCkoPU0ToZa qDFQ== X-Gm-Message-State: AMCzsaVueGYCshr1AyNW3nxqDOduMX8HpOLQADMA/h555SnHVLYJkMux NTDoohJQqCe0r31/fz3eRpsKrNJl X-Google-Smtp-Source: AOwi7QCtNn0uWU7sUP+AQ1YGMPAIqrWBZo1tPAd9+26OTJs/ZaRRTIHf64DRi5a2is6W7uCjrqTVog== X-Received: by 10.80.132.232 with SMTP id 95mr16142988edq.294.1508228343621; Tue, 17 Oct 2017 01:19:03 -0700 (PDT) Received: from [131.188.34.88] (flowubook.informatik.uni-erlangen.de. [131.188.34.88]) by smtp.googlemail.com with ESMTPSA id o55sm7085142edc.90.2017.10.17.01.19.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 01:19:02 -0700 (PDT) References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <20171016025117.GL96685@kduck.kaduk.org> To: kitten@ietf.org From: Florian Schmaus Cc: Christoph Egger Message-ID: Date: Tue, 17 Oct 2017 10:19:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171016025117.GL96685@kduck.kaduk.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SJsCR2QaMtIlAWJq7LljUdSjupDlupQwO" Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 08:19:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SJsCR2QaMtIlAWJq7LljUdSjupDlupQwO Content-Type: multipart/mixed; boundary="7jawV5mNFW52U8IXH52N3O9eSu75GWKKP"; protected-headers="v1" From: Florian Schmaus To: kitten@ietf.org Cc: Christoph Egger Message-ID: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <20171016025117.GL96685@kduck.kaduk.org> In-Reply-To: <20171016025117.GL96685@kduck.kaduk.org> --7jawV5mNFW52U8IXH52N3O9eSu75GWKKP Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 16.10.2017 04:51, Benjamin Kaduk wrote: > On Fri, Sep 29, 2017 at 11:08:10AM +0200, Florian Schmaus wrote: >> I would like to note the existence of draft-schmaus-kitten-sasl-ht-01:= >> >> https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01 >=20 > Thanks, I just got a chance to look it over. Much appreciated, thank you. :) > [...] >=20 >> Thus we initially authenticate an XMPP session using a strong mechanis= m >> like SCRAM, but at resumption-time we want a single round trip >> mechanism. The basic idea of such a mechanism is that the client >> requests a short-lived, exclusively ephemeral token after being >> authenticated, which can be used to authenticate the resumption in an >> efficient manner. > [...] >> The SASL HT-* mechanism outlined is attempting to provide a reasonably= >> secure authentication based around a token obtained over the applicati= on >> protocol, in a single round-trip. This single-round-trip is a key >> requirement. The proposal uses a single-use token as a shared secret, >> provides channel binding and mutual authentication. >=20 > There does seem to be some value in having a fast "session resumption" > SASL mechanism to avoid repeated reauthentication (though presumably th= ere > should be some guidance to periodically require a full authentication; > various flows elsewhere do this on a month timescale, roughly). Good point. I'll write down some recommendations. > It's a little unfortunate that this ends up requiring TLS for confident= iality > (as there is some desire to have standalone mechanisms), but that seems= > to be an acceptable tradeoff for this sort of application. Yes, I think TLS is a requirement to achieve what HT-* tries to achieve in a secure fashion. > Without my chair hat, the document is a little rough in some places, > but it should be pretty straightforward to clean up. I do appreciate > the reference to RFC 6919 in particular, but it should really only be > cited by other "April 1st" RFCs. I don't remember explicit putting it there, so it is likely a leftover from the I-D template [1] I've used. Err, I mean it put it there to test if someone actually reads it. You have passed. :) I've removed the reference in 02-SNAPSHOT [2]. One important point regarding SASL HT-* I'd like to discuss and hope to get some insights from such a discussion is, if (and how) we should combine it with TLS 1.3 early data. It would be theoretically possible to exploit TLS 1.3 early data for 1 round trip session resumption. The current version of the I-D stays defensive and forbids the usage of TLS 1.3 early data. However if the early data *only* contains the HT-* initiator-msg and potential SASL profile framing of the application protocol, and nothing else, then it should be safe as far as I can tell. If that is the case, then I really feel tempted to make use of it. I'm happy to hear everyone's thoughts on this. - Florian 1: https://github.com/miekg/mmark/blob/master/rfc/rfc7511.md#conventions-and= -terminology 2: http://geekplace.eu/xeps/draft-schmaus-kitten-sasl-ht/draft-schmaus-kitte= n-sasl-ht-02.html --7jawV5mNFW52U8IXH52N3O9eSu75GWKKP-- --SJsCR2QaMtIlAWJq7LljUdSjupDlupQwO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGlBAEBCgCPFiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAlnlvPRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIRHGZsb0BnZWVr cGxhY2UuZXUACgkQIjmn6PWFIFLjtggAshOHr6YUqT4UAW3VPiBBvFTIKgfI4h+D zq8nc83Upqo2PRvqm846Z1WE7ETp/ZPgJoKOqLvfcxQSK2eILr+Jo6H98nTTDE+w aw/ZI/pQtXGmY4TcqONV5lR3YKNS48ywNqcKTXHZdvL/GceOmFzxA6cwakNQCm1V DmRBDcMw8zoa0MMMMmzqvRBagCxZVJLBlnu3lefNWwwB4FLYW87gu1SHVPWt4MTg kGykpXjobG/yJNioOGih9/AVszTa28EyTFUWM9lA1iEKxo0CUaJm7XrxZA9gmD8f Gn1NuAQRFc7OYN3tRFJHYH4F9NTUktaaYN9Mg64Uvu9ph/5E8NsI3g== =scJK -----END PGP SIGNATURE----- --SJsCR2QaMtIlAWJq7LljUdSjupDlupQwO-- From nobody Tue Oct 17 06:02:27 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4A1134213 for ; Tue, 17 Oct 2017 06:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 D5uG5IlFNifr for ; Tue, 17 Oct 2017 06:02:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4120B132FB1 for ; Tue, 17 Oct 2017 06:02:20 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BEAFD276C0A; Tue, 17 Oct 2017 13:02:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BEAFD276C0A Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=simo@redhat.com Received: from ovpn-116-110.phx2.redhat.com (ovpn-116-110.phx2.redhat.com [10.3.116.110]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D18C35E1CD; Tue, 17 Oct 2017 13:02:18 +0000 (UTC) Message-ID: <1508245337.6230.31.camel@redhat.com> From: Simo Sorce To: Benjamin Kaduk , Florian Schmaus Cc: kitten@ietf.org, Christoph Egger , XMPP Standards Date: Tue, 17 Oct 2017 09:02:17 -0400 In-Reply-To: <20171016025117.GL96685@kduck.kaduk.org> References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <20171016025117.GL96685@kduck.kaduk.org> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 17 Oct 2017 13:02:20 +0000 (UTC) Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 13:02:26 -0000 On Sun, 2017-10-15 at 21:51 -0500, Benjamin Kaduk wrote: > On Fri, Sep 29, 2017 at 11:08:10AM +0200, Florian Schmaus wrote: > > I would like to note the existence of draft-schmaus-kitten-sasl-ht- > > 01: > > > > https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01 > > Thanks, I just got a chance to look it over. > > [...] > > > Thus we initially authenticate an XMPP session using a strong > > mechanism > > like SCRAM, but at resumption-time we want a single round trip > > mechanism. The basic idea of such a mechanism is that the client > > requests a short-lived, exclusively ephemeral token after being > > authenticated, which can be used to authenticate the resumption in > > an > > efficient manner. > > [...] > > The SASL HT-* mechanism outlined is attempting to provide a > > reasonably > > secure authentication based around a token obtained over the > > application > > protocol, in a single round-trip. This single-round-trip is a key > > requirement. The proposal uses a single-use token as a shared > > secret, > > provides channel binding and mutual authentication. > > There does seem to be some value in having a fast "session > resumption" SASL mechanism to avoid repeated reauthentication (though > presumably there should be some guidance to periodically require a > full authentication; various flows elsewhere do this on a month > timescale, roughly). > It's a little unfortunate that this ends up requiring TLS for > confidentiality (as there is some desire to have standalone > mechanisms), but that seems to be an acceptable tradeoff for this > sort of application. I think this draft has many goals in common with this one: https://tools.ietf.org/html/draft-wibrown-ldapssotoken-02 I wonder if we can end up having a solution that will work well to cover it all ? The main issue here would be the requirement to bind it to TLS as LDAP (as well as other connection-oriented protocols) can use other means to encrypt the channel (namely GSSAPI, although GSSAPI doe not have a session resumption mechanism ...). Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Tue Oct 17 07:09:04 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F04D134222 for ; Tue, 17 Oct 2017 07:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=r7i+lBrl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PQ5El6+B 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 PzMVyNvrFbq9 for ; Tue, 17 Oct 2017 07:08:57 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEA3132FB1 for ; Tue, 17 Oct 2017 07:08:52 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id CE68C206BB for ; Tue, 17 Oct 2017 10:08:51 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Tue, 17 Oct 2017 10:08:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=mih8o3KrAkNH3+UMpPO8i9W4eYBVn JE5M4eIGbbfi2g=; b=r7i+lBrlN+L0CmPBCM+o9tmtXMZAlPQekjs+GQXhQ9eoV HbnjDG4CA/XslQfnVxXvv+KvnEfm8MsyIkkkLtUJ0lqxGZiWu2aZ5wILHM1OCsf6 v/rdDnaCP+WYPD7Sl6dh/ohqcrnD7H1fXO+Mc5FO7SPcfInVa17CWir2Qovxfl95 i+p5zo6hAIdrJFg+kOK4J5lMaRuvuWqYe3NsYWtPZmmb5Ey2r0bJPYf3eWO+6R2D GIsbrlXm9JswBOi6bnRZDcTRExssKQnAOI3x2cVPiRWWBfCy3RpMvbn2b8WHY5rR kcxhiPuETRXX6pXVRwMFBtmKHlLWwDliNVWP97y5w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=mih8o3 KrAkNH3+UMpPO8i9W4eYBVnJE5M4eIGbbfi2g=; b=PQ5El6+BszY20g6MsVd3Ol uPe169cChvnKPxp1+yrWjLAAUuL0stlfsNIyaC0+gyuSubnk4CmqRDdEfsuKfyaQ 1BRFjCS79ZRsyFxnd1/eq9dVppKF195SLwMGTyrJqYENIZHpNhEDzeboQPTtd/wL Y1LjSEu2GG5HU5XGzPEdmJjYcPzxmKoqJEFuEQBUv/HeSMdM7BUMdNS3MYA+22Zl UlO9yxdsMK3ZyIi9TZWwOYkSxFsTqu0yAY66MwPmZeC4BSFq2xa6GbuYirM14u3N M/fW0HZq+QY3EUqqv/2xXWX+CaT6/7uOfXbh5V46yLqbO1Y6ujo9OpSkqO1AUYLg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A20B79E2F3; Tue, 17 Oct 2017 10:08:51 -0400 (EDT) Message-Id: <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> From: Sam Whited To: kitten@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-26fdae60 References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> In-Reply-To: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> Date: Tue, 17 Oct 2017 09:08:51 -0500 Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 14:09:03 -0000 On Fri, Sep 29, 2017, at 04:08, Florian Schmaus wrote: > I would like to note the existence of draft-schmaus-kitten-sasl-ht-01: >=20 > https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01 After a quick read through of the latest draft, the only thing I found which I wasn't sure about was the following: > Before sending the authentication identity string the initiator SHOULD > prepare the data with the UsernameCaseMapped profile of [RFC7613]. This limits the SASL mechanisms usefulness to Unicode encodings. I'd suggest that normalizing the username is something the application protocol should do, it should not be required by the authentication framework (as far as SASL is concerned these should just be bytes). =E2=80=94Sam P.S. Also note that 7613 was recently replaced by RFC 8265, if this reference is kept it may be good to update it. From nobody Tue Oct 17 09:20:53 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFF213303F for ; Tue, 17 Oct 2017 09:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUOE029lUf3j for ; Tue, 17 Oct 2017 09:20:50 -0700 (PDT) Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2C513303A for ; Tue, 17 Oct 2017 09:20:49 -0700 (PDT) Received: by mail-wm0-f54.google.com with SMTP id l68so5031103wmd.5 for ; Tue, 17 Oct 2017 09:20:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=R17b2cZ5CCMh44Go8LwGt9lwdoliyaIlAuC2OfLL/+Q=; b=DoqkF4GOeq44gN7xBJTqoFHwOcsj0fvFmqS9aZaXPuEMnthUAoL0OdOis39gawTId1 fjRVLQBz77oGaZVCFwdrMXg0PA8put0BCjk3eJBDIkUD/grLbAggFLf8Bvvu0ZsT+IRW sYt4d+0/iReizM+WXMTPXwEcN/81s2kQnGI0z9OjWOdC4qGKtfx7/aWLHjQRionwckD2 gdgBZVCHe1VlVVLQiiXGUOEpyA36l4urBPK7wBqPDbQVTd5RQQh0GmR0bdqnV6NU9/rH UV7roZKYWmPycjFDy0bRf0csR3a2X0Z4b+6oWSaKsq6pVNS/Bd9NSz5sL+vCPgx6SZpb syXg== X-Gm-Message-State: AMCzsaV2D++nvKe3ffZjy4uRgeFJ4tpGLFTgFfs9uB2uJp2aUvffxc4D SVWl55e0IMCDpagLvIFSBZnU4a56 X-Google-Smtp-Source: ABhQp+SSHk1jyMydQpcY0M+X9Wb8O6n8nqb4lrIOYgqksQ0lFmd6DJgPxwi8c9pIoVCywPU62BRukQ== X-Received: by 10.28.213.79 with SMTP id m76mr3983722wmg.44.1508257247747; Tue, 17 Oct 2017 09:20:47 -0700 (PDT) Received: from [131.188.34.88] (flowubook.informatik.uni-erlangen.de. [131.188.34.88]) by smtp.googlemail.com with ESMTPSA id r68sm13225663wmd.4.2017.10.17.09.20.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 09:20:46 -0700 (PDT) To: kitten@ietf.org References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> From: Florian Schmaus Message-ID: <9d5401e4-2068-d8f3-226c-b427be54587c@geekplace.eu> Date: Tue, 17 Oct 2017 18:20:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uBMUA1AW4hqkQgebG7mGa4NxOQSDixHeI" Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:20:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uBMUA1AW4hqkQgebG7mGa4NxOQSDixHeI Content-Type: multipart/mixed; boundary="BSrXu5tQen2MDRKwJD24ghnLRmWbarAAO"; protected-headers="v1" From: Florian Schmaus To: kitten@ietf.org Message-ID: <9d5401e4-2068-d8f3-226c-b427be54587c@geekplace.eu> Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> In-Reply-To: <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> --BSrXu5tQen2MDRKwJD24ghnLRmWbarAAO Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 17.10.2017 16:08, Sam Whited wrote: > On Fri, Sep 29, 2017, at 04:08, Florian Schmaus wrote: >> I would like to note the existence of draft-schmaus-kitten-sasl-ht-01:= >> >> https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01 >=20 > After a quick read through of the latest draft, the only thing I found > which I wasn't sure about was the following: >=20 >> Before sending the authentication identity string the initiator SHOULD= >> prepare the data with the UsernameCaseMapped profile of [RFC7613]. >=20 > This limits the SASL mechanisms usefulness to Unicode encodings. I'd > suggest that normalizing the username is something the application > protocol should do, it should not be required by the authentication > framework (as far as SASL is concerned these should just be bytes). I am not sure about that. SCRAM has the same requirement. > =E2=80=94Sam >=20 > P.S. Also note that 7613 was recently replaced by RFC 8265, if this > reference is kept it may be good to update it. Thanks. Updated in 02-SNAPSHOT. I also note that https://tools.ietf.org/html/rfc7613 does not show a sign that the RFC has been obsoleted. Maybe someone should ping Peter. :) - Florian --BSrXu5tQen2MDRKwJD24ghnLRmWbarAAO-- --uBMUA1AW4hqkQgebG7mGa4NxOQSDixHeI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGlBAEBCgCPFiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAlnmLddfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIRHGZsb0BnZWVr cGxhY2UuZXUACgkQIjmn6PWFIFK4sAgAmbfyRK3aWdmRxB069320Um+TgeNWS7il 6H/JHDfFyha8I7f9QJ2hr1q6wypQmErfXrsOW3/suzreSzDnVgklrSOdjXkR3ksh fqeNT20NSSEhsqvxqp8hJmPCNFkaemrcONxNfQcYi12Dro79FI79NDgO6pwHhThH uJKmqsH8oXCBM3q63xYLlReQbLRQd5ymnACrJrp/qaTQ34A2B0BwxoocO9jSTWqk 4EL4DIxc2d6hA+AOtjO5bi7SFuGxoLPaV0Y8m/BacNEQIxeR1k7zH2hGBUyQ6lAj v3mP4qe/xR+ZC5bqXuD84Nm1v+wDzTZY5sMT6XHJivG83f0smgHE8Q== =lsw2 -----END PGP SIGNATURE----- --uBMUA1AW4hqkQgebG7mGa4NxOQSDixHeI-- From nobody Tue Oct 17 09:23:33 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6006B13303F for ; Tue, 17 Oct 2017 09:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaSh8uoC7YTs for ; Tue, 17 Oct 2017 09:23:30 -0700 (PDT) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) (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 25DD913305E for ; Tue, 17 Oct 2017 09:23:30 -0700 (PDT) Received: by mail-wm0-f52.google.com with SMTP id u138so4984618wmu.5 for ; Tue, 17 Oct 2017 09:23:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=fIkK1ao9HX9tV71HOW9ipCJX4EZqgA81ax6JlB14W0I=; b=cqtLnWN8eMWPUG3Ohw4SFnl9zFzpv4VZ2xisa/D+H5Fv16+HqUK8mItxlgNW7KCrs+ T76YyiK+7dd64WAZXmPIblKdzYwIQSGKDngT6wOZ3H1EPPcMe3wVLZOBikfqnEsC0GEf b1uKO3bdhAmwolnuO0EHxPi2gw317ebuhhgRuenVGaeA1ajvnW+Z1ncoOZ9gv1caVVnt q5+A6GmL7yRifbZ0Y93P7lpAtZ3PItE7OEj2iLInMBh2kv2RAsOCxEofwDuXhn25CrDF 2E+MvpDYmhBOwQrLyCT80z210PN61iwOvBTs1EwI45MX2sSgzhgxph9T5AOlmVtybViA /NEg== X-Gm-Message-State: AMCzsaV7dfU92U5nqTYyBBPRlKa8rgsmjPtZihJRrIOCSDH1Bn+POneN WVT3MVmdtdKDccRD2p22ymf2NO+3 X-Google-Smtp-Source: ABhQp+RcwMowEqavwjup0WAOkTyHy7ePetWFOObGAnuLRA5YgnqWHSuA9mPk9WbPM4Cn1dEUZ8vqnA== X-Received: by 10.28.208.2 with SMTP id h2mr3719621wmg.13.1508257407959; Tue, 17 Oct 2017 09:23:27 -0700 (PDT) Received: from [131.188.34.88] (flowubook.informatik.uni-erlangen.de. [131.188.34.88]) by smtp.googlemail.com with ESMTPSA id u138sm15016666wmd.17.2017.10.17.09.23.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 09:23:26 -0700 (PDT) To: Simo Sorce Cc: kitten@ietf.org References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <20171016025117.GL96685@kduck.kaduk.org> <1508245337.6230.31.camel@redhat.com> From: Florian Schmaus Message-ID: <02770e7f-d0ca-290c-f1b5-dab065cba5e6@geekplace.eu> Date: Tue, 17 Oct 2017 18:23:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1508245337.6230.31.camel@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Lpq583E3wMKFQcdMDe5KJ9cDaoAChSV2H" Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:23:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Lpq583E3wMKFQcdMDe5KJ9cDaoAChSV2H Content-Type: multipart/mixed; boundary="0cLNN6L0HcX8XxKjJqW2duNw3gtPSodVW"; protected-headers="v1" From: Florian Schmaus To: Simo Sorce Cc: kitten@ietf.org Message-ID: <02770e7f-d0ca-290c-f1b5-dab065cba5e6@geekplace.eu> Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <20171016025117.GL96685@kduck.kaduk.org> <1508245337.6230.31.camel@redhat.com> In-Reply-To: <1508245337.6230.31.camel@redhat.com> --0cLNN6L0HcX8XxKjJqW2duNw3gtPSodVW Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 17.10.2017 15:02, Simo Sorce wrote: > On Sun, 2017-10-15 at 21:51 -0500, Benjamin Kaduk wrote: >> On Fri, Sep 29, 2017 at 11:08:10AM +0200, Florian Schmaus wrote: >>> I would like to note the existence of draft-schmaus-kitten-sasl-ht- >>> 01: >>> >>> https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01 >> >> Thanks, I just got a chance to look it over. >> >> [...] >> >>> Thus we initially authenticate an XMPP session using a strong >>> mechanism >>> like SCRAM, but at resumption-time we want a single round trip >>> mechanism. The basic idea of such a mechanism is that the client >>> requests a short-lived, exclusively ephemeral token after being >>> authenticated, which can be used to authenticate the resumption in >>> an >>> efficient manner. >> >> [...] >>> The SASL HT-* mechanism outlined is attempting to provide a >>> reasonably >>> secure authentication based around a token obtained over the >>> application >>> protocol, in a single round-trip. This single-round-trip is a key >>> requirement. The proposal uses a single-use token as a shared >>> secret, >>> provides channel binding and mutual authentication. >> >> There does seem to be some value in having a fast "session >> resumption" SASL mechanism to avoid repeated reauthentication (though >> presumably there should be some guidance to periodically require a >> full authentication; various flows elsewhere do this on a month >> timescale, roughly). >> It's a little unfortunate that this ends up requiring TLS for >> confidentiality (as there is some desire to have standalone >> mechanisms), but that seems to be an acceptable tradeoff for this >> sort of application. >=20 > I think this draft has many goals in common with this one: > https://tools.ietf.org/html/draft-wibrown-ldapssotoken-02 >=20 > I wonder if we can end up having a solution that will work well to > cover it all ? Thanks for point this out. I'll have a look at draft-wibrown-ldapssotoken-02 and get back to you. - Florian --0cLNN6L0HcX8XxKjJqW2duNw3gtPSodVW-- --Lpq583E3wMKFQcdMDe5KJ9cDaoAChSV2H Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGlBAEBCgCPFiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAlnmLn5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIRHGZsb0BnZWVr cGxhY2UuZXUACgkQIjmn6PWFIFJCfQf+NFSv0y8jvuOOL754tcuNoM5tClkrXXSS 0hN3HV8VrtV3ocRZ9rCJlUPPDgJsX/HE5Qf8CoPviRffz0Inda4z4fKtMVAODmCD BZxOu6llg0hvJyFZTlIuJf/iy1pzwDpkXBTbou0TLYrF/xgEBkFgM5esMjs6G+TV tDQNY4Z24q3bwyiHYCF5lhjIhXiOB6UweTG6GAvQPaiJOA86RrzNeJpqZCuIPacC CQ3ajucipOTp2zVldClt7ny9ro0HNWB0DdyqboL8aQq6i/N7qb4qrqcz9Vc0/N2s P89Yqoaz9l0tP2lBaTQyJMsYzhCv0N3r4RZJQi/zBdFcNunNk6LVoA== =4+nE -----END PGP SIGNATURE----- --Lpq583E3wMKFQcdMDe5KJ9cDaoAChSV2H-- From nobody Tue Oct 17 09:28:17 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C8113305E for ; Tue, 17 Oct 2017 09:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=vB735QZD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Yh6tFkIZ 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 TVKGhuJvbbbO for ; Tue, 17 Oct 2017 09:28:14 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C18D13303A for ; Tue, 17 Oct 2017 09:28:14 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C5EF720EA6 for ; Tue, 17 Oct 2017 12:28:13 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Tue, 17 Oct 2017 12:28:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=zZHfCi2tn07F9xojAOLDbnuuerpQg 6hQe1DVVdLxxrw=; b=vB735QZDOwR3XFU4afPq9+xGG4+XxmckuuNlOvXfYVXIo 9ZhoT+rz6Q88/eFsinh42hNUPMwbT1Xhx6qm6rEsFUuO5oRfcLn6gXUSFexYItoW EwuzOvftJxCr1Zb8O3h8Xw6bzZ+9jzOYa2VPWtya1Z0a4jAq2H/+GI4599+Aop/p S6MEMO5WZAjMqCxxKUdqKY5yZakzujmjZDnWyeRUevDMqvFbORNh9mLCYIFlEAYp /CTTnRXRlV4UApRU1hOG1bStD4obNgakVWzWwoHzgs77vN91+6iqWfjnt73DBQGe PuYE2NfuoErCaFjdPMRwkjC+gX6hZhWt9BDldsQew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=zZHfCi 2tn07F9xojAOLDbnuuerpQg6hQe1DVVdLxxrw=; b=Yh6tFkIZb5oJ48WDUhuhfs oN1GJW9d3VN8VQAipjLExoI81UIoJ9T/X7pgDnOJdb/3LX/Z//gKhWOoAWlUC0BV RlY2KEM4wU6A3sFGgHhpOSEVU7oBjwYsympV323gjFeMmM8raUT9HPWD1hYE0wEr YewoCMiy/mtBrgJFJd6zNJTYZvzY712bvrh2ajb9N/JLGZemi1O9PQnH0uXNEWBy d+xSLwN6hdoaMukFO7Cw7V7x8g3rhx1o0NwWb1aMJ9KG5tQIXiNI0dNW8cSswlR/ rLoP6TIgnCZqdMI3qplQ0xiRn21US1JoZ+oklT+XvETwKfka690e6+baTZNjntFw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A109A9E2F6; Tue, 17 Oct 2017 12:28:13 -0400 (EDT) Message-Id: <1508257693.3561021.1141849248.0C392C2B@webmail.messagingengine.com> From: Sam Whited To: kitten@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-26fdae60 References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> <9d5401e4-2068-d8f3-226c-b427be54587c@geekplace.eu> Date: Tue, 17 Oct 2017 11:28:13 -0500 In-Reply-To: <9d5401e4-2068-d8f3-226c-b427be54587c@geekplace.eu> Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:28:16 -0000 On Tue, Oct 17, 2017, at 11:20, Florian Schmaus wrote: > I am not sure about that. SCRAM has the same requirement. I'd forgotten that. That doesn't seem like a good reason to do it here though. I ignore this requirement in my SCRAM implementation as well. What if I have an application protocol that does its normalization using a different system that's incompatible with PRECIS, or doesn't use Unicode (in China I've been told that there's another system that's widely used)? Or what if the username in a particular system is something like an email or JID that may already apply multiple profiles (usernamecasemapped to the localpart, IDNA2008 style normalization to the domainpart), do we really want to apply usernamecasemapped again on top of the existing application applied profiles? =E2=80=94Sam From nobody Tue Oct 17 09:57:07 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715D113207A for ; Tue, 17 Oct 2017 09:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 Xo14gJcIEksk for ; Tue, 17 Oct 2017 09:57:04 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D2814133049 for ; Tue, 17 Oct 2017 09:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1508259423; d=isode.com; s=june2016; i=@isode.com; bh=h1nOUsaB8EySLzdoF4EqWaxxjVRuYW7k/D5F+3TBs64=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gjYSqKgJbxwrrIG2BCoNdLGiLp+TkUtakNTRy+7Fmg7sgQtnw8qQkk6h5g/4jMeN4dLPpx dfWKg4eHGPse6YQ6bWNNnlj9LaRlt5zpf41gyBRlYmGQGJlF0Mcm4feWCynPwJ6PKHlhfD 5oMLIq9HIo1CevcdMXJMlMwJxkJZwe4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 17 Oct 2017 17:57:02 +0100 To: Sam Whited , kitten@ietf.org References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: <7425e2f8-89a4-8a2d-8957-b640b8d97883@isode.com> Date: Tue, 17 Oct 2017 17:57:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:57:05 -0000 Hi Sam, On 17/10/2017 15:08, Sam Whited wrote: > On Fri, Sep 29, 2017, at 04:08, Florian Schmaus wrote: >> I would like to note the existence of draft-schmaus-kitten-sasl-ht-01: >> >> https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01 > After a quick read through of the latest draft, the only thing I found > which I wasn't sure about was the following: > >> Before sending the authentication identity string the initiator SHOULD >> prepare the data with the UsernameCaseMapped profile of [RFC7613]. > This limits the SASL mechanisms usefulness to Unicode encodings. I think use of Unicode, in particular UTF-8 is the right thing. Other=20 character sets can be mapped to UTF-8. Normalization to disallow problematic characters is a good thing, so I=20 think a SHOULD level requirement is appropriate. But I am not sure that=20 case-mapped version of UserName profile is the right thing here. > I'd > suggest that normalizing the username is something the application > protocol should do, it should not be required by the authentication > framework (as far as SASL is concerned these should just be bytes). > > =E2=80=94Sam > > P.S. Also note that 7613 was recently replaced by RFC 8265, if this > reference is kept it may be good to update it. +1. From nobody Tue Oct 17 10:01:29 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED55C133063 for ; Tue, 17 Oct 2017 10:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=GLN+TqV+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HIwMPiFT 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 kVPFHDxCA6xB for ; Tue, 17 Oct 2017 10:01:27 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1991133020 for ; Tue, 17 Oct 2017 10:01:26 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 33AE020AF9; Tue, 17 Oct 2017 13:01:26 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Tue, 17 Oct 2017 13:01:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=0ljX63DgOivs23G3D+1gFJikzKmgy Q/UGPBKfjKloJw=; b=GLN+TqV+9lAIXQ5gE+CwZB6Klg7gjPUVDlm8nbasdWzCI yHf183LR7TjaXhPRMP9HiXmBENWhspj7SBbbNZwGuNYF+2D/a3my0JdUbbKYlKLL z+dM8bFpZWsurUdcOjZJ1ls4g6eJCi5aAjVilHTgrd8L6A5qAsBIFmtko7VyEUag rq++pF/na962eTdvNGFgqHqsNEo5zKZ6MDN9XrLa6Gd4i93KEKRTmfSagM2N0m94 OPVqM3nmAUaIVS75wym4P/QoknGcyaj9qMYkT6GvE0/Ubvm3/hyR4ipHF6ZrkXhv M9j83n94SjnsubMcxkt1EnRD5wl9R+v/AV0AOwm8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=0ljX63 DgOivs23G3D+1gFJikzKmgyQ/UGPBKfjKloJw=; b=HIwMPiFTPRK5PdvqI8rNKJ YJfw0FMAivFtceeHeeI0NapPZ4yg0b2ML7UcYQRX0dbCVPdnu3TR+CNW9jfopgZb ZK7NnN09TqWiuKKQYVUecuhibmzh7f222GYZa9LOO2GFwyBLu+O7Lpe03i5pwe3L GEHfvZqBL4M9z5nH+94p8WFrt8ljRXR5hjMZTd7XH8+3dlTa8HZKyCwql60cUAWb 9vaFSZPjHJrNl4UJtN1zKPyvnQq9YbhZzaEWauqP0Iy+iRWBFA2RcCGvoGk7tOev ficoIjEawJqNAX6kv9aPmW4rFrdYlA1aXx22W1nBvrlac5f56vh3wdAbjhkaqh0g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 027CA9E2F3; Tue, 17 Oct 2017 13:01:25 -0400 (EDT) Message-Id: <1508259685.3569865.1141885272.34280EA0@webmail.messagingengine.com> From: Sam Whited To: Alexey Melnikov , kitten@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-26fdae60 References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> <7425e2f8-89a4-8a2d-8957-b640b8d97883@isode.com> In-Reply-To: <7425e2f8-89a4-8a2d-8957-b640b8d97883@isode.com> Date: Tue, 17 Oct 2017 12:01:25 -0500 Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 17:01:28 -0000 On Tue, Oct 17, 2017, at 11:57, Alexey Melnikov wrote: > Normalization to disallow problematic characters is a good thing, so I=20 > think a SHOULD level requirement is appropriate. But I am not sure that=20 > case-mapped version of UserName profile is the right thing here. I agree, I just don't think this needs to be part of the authentication framework. It should already be handled by the application level protocol. Ex. RFC 7622 already defines how XMPP normalizes usernames, so why should this mandate that we run that step again? Also, what if a system wants to use UsernameCasePreserved but this mechanism uses UsernameCaseMapped (or visa versa), the SASL mechanism would be breaking that profile. Even if we change to username case preserved (which I think is more correct than case mapped in this case, FWIW) what if the application using this profile specifically allows characters in usernames that aren't allowed by the identifier class of PRECIS? We shouldn't be making that decision for people. =E2=80=94Sam From nobody Tue Oct 17 10:43:24 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37919133059 for ; Tue, 17 Oct 2017 10:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 7XYKQe2mWEYJ for ; Tue, 17 Oct 2017 10:43:16 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 3B2E2126B6E for ; Tue, 17 Oct 2017 10:43:16 -0700 (PDT) Received: from localhost.localdomain (imgmt2.lax.icann.org [10.32.11.180]) by smtp01.icann.org (Postfix) with ESMTP id 6DE14E157B for ; Tue, 17 Oct 2017 17:43:15 +0000 (UTC) From: Marilia Hirano To: kitten@ietf.org Message-Id: <20171017174316.3B2E2126B6E@ietfa.amsl.com> Date: Tue, 17 Oct 2017 10:43:16 -0700 (PDT) Archived-At: Subject: [kitten] The 2017 IANA annual survey is coming X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 17:43:17 -0000 Dear valued customer, We strive to continuously improve our delivery of the IANA functions. We have engaged Ebiquity, an independent research firm to run our 2017 customer survey and Judy.Bromley@ebiquity.com will send you an invitation to participate early next week. Ebiquity is committed to protecting the confidentiality of all respondents in line with the Code of Conduct of ESOMAR (a membership organization representing the interests of the data, research and insights profession at an international level). We appreciate your time and helping us improve the delivery of the IANA functions. If you have any questions, please contact me at marilia.hirano@iana.org. Yours faithfully, Marilia Hirano Manager, Continuous Improvement ICANN From nobody Tue Oct 17 15:20:37 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2635613304B for ; Tue, 17 Oct 2017 15:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 z_XgScd134h8 for ; Tue, 17 Oct 2017 15:20:30 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 F386613302A for ; Tue, 17 Oct 2017 15:20:29 -0700 (PDT) X-AuditID: 1209190e-d0fff70000002616-98-59e6822bae22 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 3A.8B.09750.C2286E95; Tue, 17 Oct 2017 18:20:28 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v9HMKOcf021132; Tue, 17 Oct 2017 18:20:26 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9HMKLmi009776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Oct 2017 18:20:23 -0400 Date: Tue, 17 Oct 2017 17:20:21 -0500 From: Benjamin Kaduk To: Florian Schmaus Cc: kitten@ietf.org Message-ID: <20171017222020.GT96685@kduck.kaduk.org> References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> <9d5401e4-2068-d8f3-226c-b427be54587c@geekplace.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <9d5401e4-2068-d8f3-226c-b427be54587c@geekplace.eu> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixG6nrqvT9CzS4Mk5G4tvO24yWRzdvIrF gcnj0NXFbB5LlvxkCmCK4rJJSc3JLEst0rdL4MpomXeQqWAac8XDKfOYGhhPM3UxcnJICJhI vFn6irmLkYtDSGAxk8Tt+9dYIJyNjBI9u08wQjhXmST+3Z/OCtLCIqAqsfdNDzuIzSagItHQ fZkZxBYRUJM4s2QFG4jNLCAssXzNWTBbWMBeYtL7o4wgNi/QugOz57FCDN3DKHF9+yw2iISg xMmZT1ggmrUkbvx7CXQfB5AtLbH8HwdEWFti2cLXYLs4BRwkrvceBbNFBZQl5u1bxTaBUXAW kkmzkEyahTBpFpJJCxhZVjHKpuRW6eYmZuYUpybrFicn5uWlFuka6+VmluilppRuYgQFNqck 3w7GSQ3ehxgFOBiVeHh/KD6LFGJNLCuuzD3EKMnBpCTK62z4JFKILyk/pTIjsTgjvqg0J7X4 EKMEB7OSCK+eLVA5b0piZVVqUT5MSpqDRUmcd1vQrkghgfTEktTs1NSC1CKYrAwHh5IEb2Mj UKNgUWp6akVaZk4JQpqJgxNkOA/Q8G6QGt7igsTc4sx0iPwpRl2OGw+v/2ESYsnLz0uVEudt ACkSACnKKM2DmwNKSBLZ+2teMYoDvSXMewKkigeYzOAmvQJawgS0ZJ3TE5AlJYkIKakGRrfO TWWpbHO0VsTzaaX1VzTkrWFn5Vv676KJ/rnL7KsWHn1WoV72s2mC9sa2jTuPWG26dLP0uvYS jz52kc+r/B9Y7jUryfI0Cej/pH5y75H7a3VaTVdpvHEWD+/IElY88+/b0qqjE/e7PXP64tFS UhZfKHnXP1r90mn1WaHpM2RfxufJXFaoUmIpzkg01GIuKk4EAHX2DHQjAwAA Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 22:20:31 -0000 On Tue, Oct 17, 2017 at 06:20:39PM +0200, Florian Schmaus wrote: >=20 > Thanks. Updated in 02-SNAPSHOT. I also note that > https://tools.ietf.org/html/rfc7613 does not show a sign that the RFC > has been obsoleted. Maybe someone should ping Peter. :) More likely a matter for tools-discuss@ietf.org, with a cached copy of the old document not getting regenerated after its status changed. -Ben From nobody Tue Oct 17 23:55:05 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FBF132026 for ; Tue, 17 Oct 2017 23:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qfrnr1wjPchD for ; Tue, 17 Oct 2017 23:55:02 -0700 (PDT) Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) (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 2DF35127517 for ; Tue, 17 Oct 2017 23:55:02 -0700 (PDT) Received: by mail-wm0-f42.google.com with SMTP id t69so7906195wmt.2 for ; Tue, 17 Oct 2017 23:55:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=+5XRV0EIXnL75NhHVV3zDKEcSnStxbHM2ECvskWUaZA=; b=rRrMjIEqyGNGWM2SwbWtXlXCjvQv8CDbbuVseJkqiwpFb1P3Jqzeow8u7tWT+xiSTB Q7CepNHB1snIq+wgWYUsBpgLmrJc+s1HarYhITmdXTVe6OvDFaHvKB7hr+hfFKSnddW/ FOm0tk/RhYbkRjLn90oKn/wDJtzc4ZILwBcrHuxV8hgigElOmTjyxXhPiFUghTTxmdYB GkrgxA12F93Om56Lk76F9cJiRlgzrzLk6SIec+rBqpf7Zhhs/WxIyozoDl6PS5md8CDn /DlX90W3B1IATIql0OnI3EKavMSe4L594JcTbD9xnM4Riq1D3M0Zpn0ACQMN7IWB6z7P v6YQ== X-Gm-Message-State: AMCzsaW4oRWC4rPBFhjyolMQ9RcjlkIlnLWlOlZqtR8ge20+OtxSCGGt +s2ioUn1IDP570WsQvaUifim9XBI X-Google-Smtp-Source: AOwi7QDkL6iGm8a9vk6glJPZAwb/OSks/pEZze+kZx4KgMxyYmUA/Am95QrSvWeBsiu4UA1q7x2iAQ== X-Received: by 10.80.215.91 with SMTP id i27mr20691731edj.274.1508309700520; Tue, 17 Oct 2017 23:55:00 -0700 (PDT) Received: from [192.168.43.144] (x59cc870d.dyn.telefonica.de. [89.204.135.13]) by smtp.googlemail.com with ESMTPSA id e56sm8608832edb.72.2017.10.17.23.54.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 23:54:58 -0700 (PDT) To: kitten@ietf.org References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> <7425e2f8-89a4-8a2d-8957-b640b8d97883@isode.com> From: Florian Schmaus Message-ID: Date: Wed, 18 Oct 2017 08:54:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7425e2f8-89a4-8a2d-8957-b640b8d97883@isode.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q0VLp1ngBpvKichwIb7fo8bFUCBge10Re" Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 06:55:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q0VLp1ngBpvKichwIb7fo8bFUCBge10Re Content-Type: multipart/mixed; boundary="M6FiWgwUdkcbxdh1sM6bIMhJ9Sh7cjKm0"; protected-headers="v1" From: Florian Schmaus To: kitten@ietf.org Cc: Alexey Melnikov Message-ID: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> <7425e2f8-89a4-8a2d-8957-b640b8d97883@isode.com> In-Reply-To: <7425e2f8-89a4-8a2d-8957-b640b8d97883@isode.com> --M6FiWgwUdkcbxdh1sM6bIMhJ9Sh7cjKm0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 17.10.2017 18:57, Alexey Melnikov wrote: > Hi Sam, >=20 > On 17/10/2017 15:08, Sam Whited wrote: >=20 >> On Fri, Sep 29, 2017, at 04:08, Florian Schmaus wrote: >>> I would like to note the existence of draft-schmaus-kitten-sasl-ht-01= : >>> >>> https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01 >> After a quick read through of the latest draft, the only thing I found= >> which I wasn't sure about was the following: >> >>> Before sending the authentication identity string the initiator SHOUL= D >>> prepare the data with the UsernameCaseMapped profile of [RFC7613]. >> This limits the SASL mechanisms usefulness to Unicode encodings. > I think use of Unicode, in particular UTF-8 is the right thing. Other > character sets can be mapped to UTF-8. >=20 > Normalization to disallow problematic characters is a good thing, so I > think a SHOULD level requirement is appropriate. But I am not sure that= > case-mapped version of UserName profile is the right thing here. Good point. Since SASLprep also preserves the case, I switched to UsernameCasePreserved in 02-SNAPSHOT. - Florian --M6FiWgwUdkcbxdh1sM6bIMhJ9Sh7cjKm0-- --Q0VLp1ngBpvKichwIb7fo8bFUCBge10Re Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGlBAEBCgCPFiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAlnm+rpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIRHGZsb0BnZWVr cGxhY2UuZXUACgkQIjmn6PWFIFKGugf/T/iStR3XLz41m913OYnGvxrIAle64x4p mlX+SnGBS9olRqI5BlbNpOdyoLNj9psDqYyazZgBtuKP9u2/0eB0mAKPUtLUzu2i ejxRvbI0umwKlBh/kXvevJP6DWpdpuXHBsB2uwMknHko5afSdn08YbU4lI8c1t/M vlNmxUg57xSiypurrRDVF5pUhLBZKEtMLEO/+JfvfgxiT1PuN7O5WsF/KBz+CUQ1 8eQm3AMxY2UurP98TO1auY5Zsbsqahxy81/7c4w4hNiIGaVSxj1QVQ+Mvk0Ia0ZQ MzNMicyd3Vw8He9MdMcbALpl4rhOuQtDW8+QvbrSpQPFWYSXkLuJuQ== =r18M -----END PGP SIGNATURE----- --Q0VLp1ngBpvKichwIb7fo8bFUCBge10Re-- From nobody Wed Oct 18 03:13:46 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B4A133200 for ; Wed, 18 Oct 2017 03:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=isode.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 d8Jw8vo7ng-x for ; Wed, 18 Oct 2017 03:13:45 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 301161331C2 for ; Wed, 18 Oct 2017 03:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1508321624; d=isode.com; s=june2016; i=@isode.com; bh=zSF8Ni1bSp5BBwAGDLR9E+lADy8kT0fFGc6iQ6CE3+o=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=DLJTSjjdFEMfRHCOAvI6G/VqvfOU0zclalYmNtZLrJHPTP0MC7nstqwnwdMPLsRlrWYIsv UnNRuE4KYdGhMQ9X+ePIpMZ6O4NvShsCk7SlQXD0r09DSXwDPbI2y646C18gLtJv1wSonF ZeM0NRA2HsdMbwueGdOOSA7G/bE1q6Y=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 18 Oct 2017 11:13:44 +0100 To: Benjamin Kaduk , Florian Schmaus Cc: kitten@ietf.org References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <1508249331.3526135.1141665400.36944376@webmail.messagingengine.com> <9d5401e4-2068-d8f3-226c-b427be54587c@geekplace.eu> <20171017222020.GT96685@kduck.kaduk.org> From: Alexey Melnikov Message-ID: Date: Wed, 18 Oct 2017 11:13:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: <20171017222020.GT96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 10:13:46 -0000 On 17/10/2017 23:20, Benjamin Kaduk wrote: > On Tue, Oct 17, 2017 at 06:20:39PM +0200, Florian Schmaus wrote: >> Thanks. Updated in 02-SNAPSHOT. I also note that >> https://tools.ietf.org/html/rfc7613 does not show a sign that the RFC >> has been obsoleted. Maybe someone should ping Peter. :) > More likely a matter for tools-discuss@ietf.org, with a cached copy > of the old document not getting regenerated after its status changed. You should email Henrik Levkowetz , as tools.ietf.org is the server he maintains. From nobody Fri Oct 20 09:27:44 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C91D612421A; Fri, 20 Oct 2017 09:27:37 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150851685771.15398.9356732868258534239@ietfa.amsl.com> Date: Fri, 20 Oct 2017 09:27:37 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-krb-spake-preauth-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:27:38 -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-02.txt Pages : 31 Date : 2017-10-20 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-krb-spake-preauth-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-spake-preauth-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 24 07:49:58 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3448C13F812; Tue, 24 Oct 2017 07:49:57 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150885659718.25306.17303540942836961560@ietfa.amsl.com> Date: Tue, 24 Oct 2017 07:49:57 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 14:49:57 -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 : SAML Enhanced Client SASL and GSS-API Mechanisms Authors : Scott Cantor Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-ec-16.txt Pages : 34 Date : 2017-10-24 Abstract: Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-16 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-sasl-saml-ec-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-saml-ec-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 28 09:26:12 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ED013FBAD for ; Sat, 28 Oct 2017 09:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 KOfY3rB8j6p9 for ; Sat, 28 Oct 2017 09:26:09 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C2413FBAF for ; Sat, 28 Oct 2017 09:26:06 -0700 (PDT) X-AuditID: 1209190d-b7fff70000001a30-b8-59f4af9a3f32 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 18.91.06704.A9FA4F95; Sat, 28 Oct 2017 12:26:03 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v9SGPxWb025320 for ; Sat, 28 Oct 2017 12:26:00 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [10.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9SGPvnL015472 for ; Sat, 28 Oct 2017 12:25:58 -0400 From: Greg Hudson To: kitten@ietf.org Date: Sat, 28 Oct 2017 12:25:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUixG6nojt7/ZdIg9snGS2Obl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOn9L1kKXvJVdMzewd7A+Ie7i5GTQ0LAROLh2xbWLkYuDiGB xUwSi9s+s0A4xxkl2j6eZgGpEhLoYJLYfVEAxGYTUJZYv38rWFxEQFhi99Z3zCC2sIC5xLRr 29lBbBYBVYlDLWeZQGxeAUOJ589XsUHYghInZz4B62UWkJA4+OIF8wRG7llIUrOQpBYwMq1i lE3JrdLNTczMKU5N1i1OTszLSy3SNdLLzSzRS00p3cQICgJOSd4djP/ueh1iFOBgVOLhlcj9 HCnEmlhWXJl7iFGSg0lJlHff+U+RQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4g8q/RArxpiRW VqUW5cOkpDlYlMR5twXtihQSSE8sSc1OTS1ILYLJynBwKEnwbloH1ChYlJqeWpGWmVOCkGbi 4AQZzgM0vB2khre4IDG3ODMdIn+KUZvj2KbLf5g4ns183cAsxJKXn5cqJc67AKRUAKQ0ozQP btorRnGgp4R5E4BxLMQDjHq4Oa+AVjABrdCQBFtRkoiQkmpgZJlyoUgyVD2lvuZJ4APDC21H zn1+fXCpxp57i89m5uTbb33Je7T7s93di7NvFV29fe7iCmubzLUftjZMOPlt7W7p46lPHkYf iEjQ6hHy36O7iuf6/HQLhcuCu2Y5rplmb/0/hSunQ2n5SilBp7xWqxr74/YcP+71LXWp3vE6 kdF3n4BUm9+UeiWW4oxEQy3mouJEAGOk9YK3AgAA Archived-At: Subject: [kitten] SPAKE edwards25519 M/N values and test vectors X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 16:26:10 -0000 I noticed two problems with the current edwards25519 group definition in the SPAKE preauth draft which I would like to correct: 1. When I created the test vectors, I generated x/y values incorrectly. The IRTF SPAKE draft says "A picks x randomly and uniformly from the integers in [0,ph) divisible by h", but I instead just picked from [0,p], so most of the x and y values aren't divisible by the cofactor. Depending on how an implementation works, this could make testing awkward. 2. The M and N constants aren't in the prime-order subgroup, as is required by the IRTF SPAKE draft. This causes a few low-order bits of w to be leaked, which could be used as a pre-filter before an online password attack. This could be papered over by forcing w to be divisible by the cofactor, but I think providing M/N values in conformance with the IRTF draft is much more elegant. I generated new values with point order checking: M: d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf N: d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab The appendix describing M/N generation needs to be adjusted to match, as it currently says that the M/N values are just hashes of the seed strings. I propose the wording: The M and N constants for the NIST groups are from [I-D.irtf-cfrg-spake2] section 3. The M and N constants for the edwards25519 group were generated using the algorithm from [I-D.irtf-cfrg-spake2] section 3 and the seed strings "edwards25519 point generation seed (M)" and "edwards25519 point generation seed (N)". (I plan to see about adding edwards25519 to the IRTF SPAKE draft, in which case this appendix can be simplified or eliminated. But first I want to fix the kitten draft.) The full document update is at https://github.com/greghudson/ietf/pull/3 but is mostly changes to hex strings. From nobody Sat Oct 28 11:53:17 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DD013FD25 for ; Sat, 28 Oct 2017 11:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nIxXCxNPhvcg for ; Sat, 28 Oct 2017 11:53:14 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 126BC13FD24 for ; Sat, 28 Oct 2017 11:53:13 -0700 (PDT) X-AuditID: 1209190f-257ff700000041e2-38-59f4d21633cc Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 1F.1A.16866.712D4F95; Sat, 28 Oct 2017 14:53:11 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v9SIr6vg007923; Sat, 28 Oct 2017 14:53:08 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9SIr3Dj016405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 28 Oct 2017 14:53:05 -0400 Date: Sat, 28 Oct 2017 13:53:03 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20171028185303.GI96685@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixG6noit+6Uukwf5rlhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtXJDxkLrgtUtE/sYGxgXMjbxcjJISFgIvHu6EKWLkYuDiGB xUwS/3+cZYZwNjJKXDi1mQ3Cucok8XHmGVaQFhYBVYn7O84wgthsAioSDd2XmUFsEQFFiWer 5rKA2MwCwhLL15xlA7GFBVwk/kyZAlbDC7Kuez2QzQE01FBixgF1iLCgxMmZT6BatSRu/HvJ BFLCLCAtsfwfB0iYU8BIYvHvNrApogLKEvP2rWKbwCgwC0n3LCTdsxC6FzAyr2KUTcmt0s1N zMwpTk3WLU5OzMtLLdI10cvNLNFLTSndxAgKSE5J/h2Mcxq8DzEKcDAq8fBK5H6OFGJNLCuu zD3EKMnBpCTKu+/8p0ghvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxlh75ECvGmJFZWpRblw6Sk OViUxHm3Be2KFBJITyxJzU5NLUgtgsnKcHAoSfD+uQDUKFiUmp5akZaZU4KQZuLgBBnOAzRc 7SLI8OKCxNzizHSI/ClGY45jmy7/YeJ4NvN1A7MQS15+XqqUOO80kHECIKUZpXlw00BJRSJ7 f80rRnGg54R5f4BU8QATEty8V0CrmIBWaUiCrSpJREhJNTCKZ//yZ5Eof3Vm/58vfnu066Z+ X2MqKP/4Z5aMiZVU5HaTvk3bb7nPmvN+teGzNf/b+hvruG5+T6vOmHu/kO+xoBX3+9DDFmV/ ZzcysR84dfFh1I5v4mfSoq0XPZwxaV5A8n+BqXpbgh2UCvW/ffub+olxVtAZiXUabGYP415r 5v/MZjaXnPhYiaU4I9FQi7moOBEASL1KmQUDAAA= Archived-At: Subject: Re: [kitten] SPAKE edwards25519 M/N values and test vectors X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 18:53:16 -0000 On Sat, Oct 28, 2017 at 12:25:57PM -0400, Greg Hudson wrote: > I noticed two problems with the current edwards25519 group definition in > the SPAKE preauth draft which I would like to correct: > > 1. When I created the test vectors, I generated x/y values incorrectly. > The IRTF SPAKE draft says "A picks x randomly and uniformly from the > integers in [0,ph) divisible by h", but I instead just picked from > [0,p], so most of the x and y values aren't divisible by the cofactor. > Depending on how an implementation works, this could make testing > awkward. > > 2. The M and N constants aren't in the prime-order subgroup, as is > required by the IRTF SPAKE draft. This causes a few low-order bits of w > to be leaked, which could be used as a pre-filter before an online > password attack. This could be papered over by forcing w to be > divisible by the cofactor, but I think providing M/N values in > conformance with the IRTF draft is much more elegant. I generated new > values with point order checking: > > M: d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf > N: d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab > > The appendix describing M/N generation needs to be adjusted to match, as > it currently says that the M/N values are just hashes of the seed > strings. I propose the wording: > > The M and N constants for the NIST groups are from > [I-D.irtf-cfrg-spake2] section 3. > > The M and N constants for the edwards25519 group were generated using > the algorithm from [I-D.irtf-cfrg-spake2] section 3 and the seed > strings "edwards25519 point generation seed (M)" and "edwards25519 > point generation seed (N)". > > (I plan to see about adding edwards25519 to the IRTF SPAKE draft, in > which case this appendix can be simplified or eliminated. But first I > want to fix the kitten draft.) > > The full document update is at https://github.com/greghudson/ietf/pull/3 > but is mostly changes to hex strings. Thanks for spotting the inconsistency, and preparing the update! It looks good to me. -Ben