From nobody Mon Dec 4 08:00:51 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 D12E9127843 for ; Mon, 4 Dec 2017 08:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 moQh5OKA-pU9 for ; Mon, 4 Dec 2017 08:00:43 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDEE127005 for ; Mon, 4 Dec 2017 08:00:42 -0800 (PST) X-AuditID: 1209190c-04dff70000005890-39-5a2571288527 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-1.mit.edu (Symantec Messaging Gateway) with SMTP id 03.3A.22672.921752A5; Mon, 4 Dec 2017 11:00:41 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id vB4G0bcm026001 for ; Mon, 4 Dec 2017 11:00:39 -0500 Received: from [18.101.8.222] (VPN-18-101-8-222.MIT.EDU [18.101.8.222]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vB4G0Z1D011608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 4 Dec 2017 11:00:37 -0500 References: <151206485902.25914.16222407249374346828@ietfa.amsl.com> To: kitten@ietf.org From: Greg Hudson Message-ID: <0a04813b-96cf-8b5c-dd4a-d3b86cbf5bfa@mit.edu> Date: Mon, 4 Dec 2017 11:00:35 -0500 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: <151206485902.25914.16222407249374346828@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixG6nrqtZqBpl0LPIyOLo5lUsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuHAvu+AzU8Wr7ZPYGhgPMHUxcnJICJhIvN11mLGLkYtDSGAx k0TPxbtQzjFGial3p7FBOLeYJN5v72YDaREW8JE4eOwZO4gtJOAi8fNpM9goEQFhid1b3zGD 2GwCyhLr929lAbF5Bawkzn/cAVbDIqAi8e/aPDBbVCBC4mHnLnaIGkGJkzOfgNVzCrhKTP77 B2wOs4CexI7rv1ghbHmJ7W/nME9g5J+FpGUWkrJZSMoWMDKvYpRNya3SzU3MzClOTdYtTk7M y0st0jXUy80s0UtNKd3ECAo+TkmeHYxn3ngdYhTgYFTi4b3hqxolxJpYVlyZe4hRkoNJSZSX IR8oxJeUn1KZkVicEV9UmpNafIhRgoNZSYS3Ix0ox5uSWFmVWpQPk5LmYFES57WJBEoJpCeW pGanphakFsFkZTg4lCR42QuAsoJFqempFWmZOSUIaSYOTpDhPEDD9UEW8xYXJOYWZ6ZD5E8x GnPceHj9DxPHs5mvG5iFWPLy81KlxHk/gJQKgJRmlObBTQMnkFSOe68YxYGeE+aVB1nKA0w+ cPNeAa1iAlqVs0YZZFVJIkJKqoFx6/8L05ZO28ZoFxY6i9s07Nhift7d1TYO/+LKmZdWKRmt 3v9L5t7Uw3c9nHb06LYuZk2PMp/5RinYMaIlPlNSz20Gi/5Ssf3LtKMSjn7e3PTw+dNo5eTW 1Udm3hAIPX3cVU7lwMGHnHvj1I6VPrtWx9yam/CNs11l29dVf5eUtT8orcyXitqrxFKckWio xVxUnAgAjl6bePsCAAA= Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-krb-spake-preauth-03.txt 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, 04 Dec 2017 16:00:50 -0000 On 11/30/2017 01:00 PM, internet-drafts@ietf.org wrote: > https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-03 > https://datatracker.ietf.org/doc/html/draft-ietf-kitten-krb-spake-preauth-03 With this update, I (once again) believe we are at a point where it makes sense to assign a padata type number. Ben, can you make a request to IANA for this? From nobody Mon Dec 4 09:38: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 E5DB7127078 for ; Mon, 4 Dec 2017 09:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-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 HJc7OCogMLGx for ; Mon, 4 Dec 2017 09:38:28 -0800 (PST) Received: from mail.kickinit.net (altair.brw.net [64.129.152.237]) by ietfa.amsl.com (Postfix) with ESMTP id 73A1612009C for ; Mon, 4 Dec 2017 09:38:28 -0800 (PST) Received: from marlin.brandoshouse.net (unknown [47.185.156.197]) (Authenticated sender: brw) by mail.kickinit.net (Postfix) with ESMTPSA id 8D86636105D for ; Mon, 4 Dec 2017 11:38:27 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=brandenwilliams.com; s=201712; t=1512409107; bh=l+uBLWhWKFF2i4PFAmhH9SxfQiqsddzmmQS8sX+XYsA=; h=From:Subject:Date:References:To:In-Reply-To:From; b=oO1U2iuJSAuYQWHsHoi8AgS9FcsbdR8aqdYtCiOwuCf2/JSMgTBbwB7tVBnEDtbGU my2yr0QeNS+Kx/NiHNjSUJRG6oC4m2MucC2SI+mLnW8E9nU2L6rfvpkCfizQjgNqnL kIR/+6bpr99un0XmKDWJWdy1zEyiJB4rXJ4IfS+6a4v63yPOmaIHUzaDJoUSrRdNGZ bA0K6cwtNKAHXej4HAKRUsTPWQspFpNQyA//V14hdENGeHAZuj7lc6x5uC+OfYGcif VCit6ILI4UbmsyTVinnWx5S3cnWhUQEeBvLY3G1dxsbFQ9qGsZyi0hmDpixdN08OBA 12SAEs1Lz6Abg== From: "Branden R. Williams" Content-Type: multipart/alternative; boundary="Apple-Mail=_FAC94EFA-D81C-4CAD-BE67-3345F455C0B1" X-Mao-Original-Outgoing-Id: 534101906.845475-b529f16cb5d6f6cd4521363f878c3485 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <9BC54502-9490-4165-9779-79E4E3B0B904@brandenwilliams.com> Date: Mon, 4 Dec 2017 11:38:26 -0600 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.4.7) 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: Mon, 04 Dec 2017 17:38:31 -0000 --Apple-Mail=_FAC94EFA-D81C-4CAD-BE67-3345F455C0B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good Day to you all. Just checking in to see if anyone had any thoughts = here. The status of the draft seems the same since original submission. Thanks! 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=_FAC94EFA-D81C-4CAD-BE67-3345F455C0B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good = Day to you all. Just checking in to see if anyone had any thoughts here. = The status of the draft seems the same since original submission.

Thanks!

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=_FAC94EFA-D81C-4CAD-BE67-3345F455C0B1-- From nobody Mon Dec 4 09:56:18 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 A2D8F12717E for ; Mon, 4 Dec 2017 09:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 I5yxqLLkPrS8 for ; Mon, 4 Dec 2017 09:56:14 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBA4126C2F for ; Mon, 4 Dec 2017 09:56:14 -0800 (PST) X-AuditID: 12074425-d1fff70000007304-86-5a258c3abbe4 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 49.D5.29444.B3C852A5; Mon, 4 Dec 2017 12:56:12 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id vB4Hu7iQ016995; Mon, 4 Dec 2017 12:56:09 -0500 Received: from [18.101.8.222] (VPN-18-101-8-222.MIT.EDU [18.101.8.222]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vB4Hu5LI017986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Dec 2017 12:56:06 -0500 To: "Branden R. Williams" , kitten@ietf.org References: <6671C116-6813-4D0E-A8B1-4D93EB8D2E7A@brandenwilliams.com> <9BC54502-9490-4165-9779-79E4E3B0B904@brandenwilliams.com> From: Greg Hudson Message-ID: <3777ee58-1e80-0f3f-85f4-d7a162c5a648@mit.edu> Date: Mon, 4 Dec 2017 12:56:05 -0500 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: <9BC54502-9490-4165-9779-79E4E3B0B904@brandenwilliams.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixG6nomvToxpl0LZWxWLn0plsFkc3r2Jx YPKYdvAXs8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKWPF3GXHCXq6Lh2SLmBsZPHF2MnBwSAiYS xxsbmLsYuTiEBBYzSZzc9AHK2cAoseXiKiaQKiGBI0wSF1pCQGxhgSCJGzPfMILYIgIuEj9W nmeGqGlmlGjfqQhiswkoS6zfv5UFxOYVsJJYsXAbWD2LgIrEhrttbCC2qECExMPOXewQNYIS J2c+AavnFHCX6DuyByzOLKAnseP6L1YIW15i+9s5zBMY+WchaZmFpGwWkrIFjMyrGGVTcqt0 cxMzc4pTk3WLkxPz8lKLdC30cjNL9FJTSjcxggPSRXUH45y/XocYBTgYlXh4b/iqRgmxJpYV V+YeYpTkYFIS5TWoAQrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4e1IB8rxpiRWVqUW5cOkpDlY lMR5bSOBUgLpiSWp2ampBalFMFkZDg4lCV6JbqCsYFFqempFWmZOCUKaiYMTZDgP0HCjLpDh xQWJucWZ6RD5U4zGHI9u3P3DxPFs5usGZiGWvPy8VClx3i0gpQIgpRmleXDTwEkllePeK0Zx oOeEeaeDLOUBJiS4ea+AVjEBrcpZowyyqiQRISXVwOgoplb/TrSDZdH7qRrvxbeKck+ZNa/O Wds3cMkVn9RLJWWSUit6jjxY4qbVzym7tmR2RZ5fi4SG/Lazn4//2HA5QDqFQd72U/XF8k3O Bjz9FupP97PU+gab7lq7a4HsrD8Vah/0PIOdjHdXvNTTmRp67YLvpkA/XtNUnUVVYQelqrTM /Y/+U2Ipzkg01GIuKk4EADWMvFsFAwAA 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: Mon, 04 Dec 2017 17:56:17 -0000 On 12/04/2017 12:38 PM, Branden R. Williams wrote: > Good Day to you all. Just checking in to see if anyone had any thoughts > here. The problem statement seems legitimate, but I am not sure about the solution. Getting everyone to implement OPAR isn't necessarily easier than getting everyone to accept passwords which meet a specific set of criteria, and perhaps signify that somehow. Most of the criteria described by OPAR are deprecated, at least per recent NIST guidelines[1]. Sites may still require mixed case and special characters in passwords, but encouraging them to formally describe those requirements may be less valuable than encouraging them to drop the requirements altogether. Describing a password policy isn't a closed problem, and describing some policies isn't sufficient for the password manager to be certain it will generate an acceptable password. For instance, one technique seen in practice is to reject every password seen in a past login attempt[2]. A nit about section 3.1.2: a site should ideally allow very long passwords (at least 256 bytes), but a password manager should not necessarily generate passwords that long. [1] https://pages.nist.gov/800-63-3/sp800-63b.html (or search "NIST password recommendations" for summaries) [2] https://www.guildwars2.com/en/news/mike-obrien-on-account-security/ From nobody Mon Dec 4 10:19:39 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F97127B73 for ; Mon, 4 Dec 2017 10:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] 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 VbNrVpcrbVkk for ; Mon, 4 Dec 2017 10:19:35 -0800 (PST) Received: from mail.kickinit.net (altair.brw.net [64.129.152.237]) by ietfa.amsl.com (Postfix) with ESMTP id D5A0A12708C for ; Mon, 4 Dec 2017 10:19:35 -0800 (PST) Received: from marlin.brandoshouse.net (unknown [47.185.156.197]) (Authenticated sender: brw) by mail.kickinit.net (Postfix) with ESMTPSA id 3629B361056; Mon, 4 Dec 2017 12:19:35 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=brandenwilliams.com; s=201712; t=1512411575; bh=X00jd92A0DzzkRKPgmzoXAS0P30IvWJKO7Bqwhcs+Wo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=aLuQkB7o44V7Wxws6a+pFcScCV8LEc+Prayq/7yeiaNRc4DWNYhkFv1h+YcKqPtQy sW3WqYNo3OHMZMP9L6UzV4rG4QrAUG7O1pc61boc2C3yQqZccBVliJ5cHLD+69968B I/jG3mSYdh2cv0YskGowNqZ6lAi4tcsjG4OyvMBqOOms8XMzs01Qq/G7wqb06G31Or p5ozqbqwBfWdDbHdQE0IDTuzRmcAgdqPtseBjrAOq9Pv4tvPQqVp3KkuO0B5iKodNu 2VThUU8n+Ub0XpxiBxAn9pHexQq8Ov0bvM7fY1zw4ofZgJYAopU3kWoWxYiOTQpBk9 90EbxCrf5TSWw== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: "Branden R. Williams" In-Reply-To: <3777ee58-1e80-0f3f-85f4-d7a162c5a648@mit.edu> Date: Mon, 4 Dec 2017 12:19:34 -0600 Cc: kitten@ietf.org X-Mao-Original-Outgoing-Id: 534104374.729848-0e630702fd9edc34a086de61052dbfca Content-Transfer-Encoding: quoted-printable Message-Id: <80318815-0A5F-4F46-9EB5-8CD4699C0AEB@brandenwilliams.com> References: <6671C116-6813-4D0E-A8B1-4D93EB8D2E7A@brandenwilliams.com> <9BC54502-9490-4165-9779-79E4E3B0B904@brandenwilliams.com> <3777ee58-1e80-0f3f-85f4-d7a162c5a648@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.3445.4.7) 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: Mon, 04 Dec 2017 18:19:37 -0000 > On Dec 4, 2017, at 11:56 AM, Greg Hudson wrote: >=20 > Getting everyone to implement OPAR isn't necessarily easier than = getting > everyone to accept passwords which meet a specific set of criteria, = and > perhaps signify that somehow. Fair enough, but given the amount of legacy technology out there, I have little faith in getting everyone who leverages authentication to beef up their standards accordingly.=20 > Most of the criteria described by OPAR are deprecated, at least per > recent NIST guidelines[1]. Sites may still require mixed case and > special characters in passwords, but encouraging them to formally > describe those requirements may be less valuable than encouraging them > to drop the requirements altogether. I just read through that doc and saw the points on composition rules. I = suppose if there are no limits, then that could be an option as well. It would = probably be easier to just say =E2=80=9CNo composition limits=E2=80=9D with the = max characters of Y than to try to include every character in the Special Characters = section. > Describing a password policy isn't a closed problem, and describing = some > policies isn't sufficient for the password manager to be certain it = will > generate an acceptable password. For instance, one technique seen in > practice is to reject every password seen in a past login attempt[2]. I=E2=80=99m willing to roll the dice on that one. If a (good) password = manager=20 generates two identical passwords, it=E2=80=99s time to buy a lottery = ticket. :) > A nit about section 3.1.2: a site should ideally allow very long > passwords (at least 256 bytes), but a password manager should not > necessarily generate passwords that long. Hrm, interesting. Perhaps 3.1.2 should read something like this: Password managers should focus on this value and elect to=20 maximize length and complexity according to its configuraiton. I=E2=80=99m happy to submit and update, but if we are concerned about = being out of sync with NIST (yet in sync with practice), I=E2=80=99m good = dropping it :)=20 Regards, Branden R. Williams, DBA, CISSP, CISM brw@brandenwilliams.com Phone: +1 (214) 727-8227 http://www.brandenwilliams.com/ From nobody Tue Dec 5 19:43:41 2017 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF1C128D6F for ; Tue, 5 Dec 2017 19:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 tJXb-y0v2R54 for ; Tue, 5 Dec 2017 19:43:39 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E674128D69 for ; Tue, 5 Dec 2017 19:43:39 -0800 (PST) X-AuditID: 1209190c-441ff7000000066f-d1-5a276769d439 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 77.28.01647.A67672A5; Tue, 5 Dec 2017 22:43:38 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id vB63ha8q031676; Tue, 5 Dec 2017 22:43:37 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vB63hX13017501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Dec 2017 22:43:36 -0500 Date: Tue, 5 Dec 2017 21:43:34 -0600 From: Benjamin Kaduk To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20171206034333.GL39477@kduck.kaduk.org> References: <151206485902.25914.16222407249374346828@ietfa.amsl.com> <0a04813b-96cf-8b5c-dd4a-d3b86cbf5bfa@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a04813b-96cf-8b5c-dd4a-d3b86cbf5bfa@mit.edu> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixCmqrJuVrh5lcGEvp8XRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfjxH+aC+awV81bfZWpgXMnSxcjBISFgIrHpgUEXIxeHkMBi JomODbPZIJwNjBLXu46wQjhXmCTezbzD2MXIycEioCLx69QpVhCbDchu6L7MDGKLCChKPFs1 lwXEZhYQlli+5iwbiC0s4CNx8NgzdhCbF2jb6W2TwOqFBEolduydwQIRF5Q4OfMJVK+WxI1/ L5lArmMWkJZY/o8DJMwpYC0x7/Q/JhBbVEBZYm/fIfYJjAKzkHTPQtI9C6F7ASPzKkbZlNwq 3dzEzJzi1GTd4uTEvLzUIl1DvdzMEr3UlNJNjOCAlOTZwXjmjdchRgEORiUe3hWz1KKEWBPL iitzDzFKcjApifK+uQsU4kvKT6nMSCzOiC8qzUktPsQowcGsJMKbpK8eJcSbklhZlVqUD5OS 5mBREue1iVSNEhJITyxJzU5NLUgtgsnKcHAoSfC2pQE1ChalpqdWpGXmlCCkmTg4QYbzAA0/ D1LDW1yQmFucmQ6RP8VozHHj4fU/TBzPZr5uYBZiycvPS5US57UDKRUAKc0ozYObBkoqEtn7 a14xigM9J8y7CaSKB5iQ4Oa9AlrFBLQqZ40yyKqSRISUVAPQ/50dTiwvZ741VPv1jWXqTYHk RLu5BjL94ow54dF32Z5YGl4O3Pxo/vRyv1O+eyIZNBm/8wq9Uc4LT2sqUROp4Pz5pOM3X4tY UzbTzbRTLzZNubT8TOoz35atFTe7GTV3pIjZmJ4SKmlUfp2yoOzxqprbfJ7JnLsLHkom/edO az6S/+KCgBJLcUaioRZzUXEiAMjy7RoFAwAA Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-krb-spake-preauth-03.txt 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, 06 Dec 2017 03:43:41 -0000 On Mon, Dec 04, 2017 at 11:00:35AM -0500, Greg Hudson wrote: > On 11/30/2017 01:00 PM, internet-drafts@ietf.org wrote: > > https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-03 > > https://datatracker.ietf.org/doc/html/draft-ietf-kitten-krb-spake-preauth-03 > > With this update, I (once again) believe we are at a point where it > makes sense to assign a padata type number. Ben, can you make a request > to IANA for this? I've asked Ekr to approve the request (it's recommended that I get AD approval before talking to IANA, since they're just going to come back and ask for it), so hopefully the process will get into motion soon. -Ben