Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

Patrick Mevzek <pm@dotandco.com> Mon, 16 July 2018 04:34 UTC

Return-Path: <pm@dotandco.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BBC130E6C for <regext@ietfa.amsl.com>; Sun, 15 Jul 2018 21:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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=dotandco.com header.b=H3qaGfYO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mXzaJrqK
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 Dj8iHqr3IYh4 for <regext@ietfa.amsl.com>; Sun, 15 Jul 2018 21:34:07 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19CF9130DC8 for <regext@ietf.org>; Sun, 15 Jul 2018 21:34:07 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 71A5721BF1 for <regext@ietf.org>; Mon, 16 Jul 2018 00:34:06 -0400 (EDT)
Received: from web6 ([10.202.2.216]) by compute3.internal (MEProxy); Mon, 16 Jul 2018 00:34:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.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=fm3; bh=gBBQ8K7BexEkZte7fUGAEYKa/y3t8 NVBcL+J4waMxo8=; b=H3qaGfYOnesqPnwlUOrp7XceqAVUCtizJ80lsAHCJuZJd lT7DYwudTbCW/OHZid+9U8rT1gLIyUc1Nf4wO1XSA/5P0gaiPzr6tE4jMSXUGmep XvLu/xGe7krc8f7j0b+hfOqMOkIFEqgLQRN7+hSjOC0kBATaCQ7RL/xndi/9GJkX UIJF5Gu/+GATp+KlPvT5Q1BJpxQa71HlsUBOxx5d0Bk7fk0MPqBtrfPO5i7WDmRK tiW1xPK/ONOd4YfHW/v9xhcNFKor1lvxjtjipDYZ3FLE4N7Ps8OHqwY7EOTLYj+D Z3TM+RhCiRxl59TWFyEqk3PJPrbSdSTgBpI+fbAmg==
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=fm3; bh=gBBQ8K 7BexEkZte7fUGAEYKa/y3t8NVBcL+J4waMxo8=; b=mXzaJrqK10rjsu3GloSPAx ffSmKmHCxFehmBrQU8p2/xy77SMddesXid3PBNSeMczUPjziTvt4263znWXQ85K+ WmOmnTzqiWMpRiotyTO7J3rfuEUZhZOuAeFXforel2torN2TStLyO622EQqbV1xP fY5pTqGpNFc1Xjl1XTeuwPVTcoXAKyKZwT7MwW4lVMTgLyM33g0bUM7ZVP4gYo4L 89K4DSy+oWsQn0BeWy6efGifzG4dAZltkKGp8g85t/H90MiEbFN5wu5ugSeDa4As G7LnLpxFJGl1b3UWD7Aj5jjuSs4wBF+K4kToESq8CwpBw++13qFAXUaMEAIu2fPQ ==
X-ME-Proxy: <xmx:PiBMW2QA97XIogeGGNEKGVxES4uJ2j3Rjeqkh0xY014BjBgOAgtYBw> <xmx:PiBMWwDP3EoTntzkzaK7xWIYe2HNhuHvi5cSha9W35WcnwdOHDcXpA> <xmx:PiBMWwzb5R9O8Om4BOb6PUDPsllH5mlIaobm6KSQciN8kkt3WNifNQ> <xmx:PiBMWwuNSlITFtEWhbu64fv3aaaB4cFtqfcKZX-zgdwT-5Jdp6e5TQ> <xmx:PiBMW5k6eJ8yTIWCFJmqaeJPIB554ulBOIpSiMSgvUCA4ovBuQLkTg> <xmx:PiBMWxvetYgCX_jMtdIckyKbDcuYKuQ7wsRW65_jKuHgG32qnYpMrg>
X-ME-Sender: <xms:PiBMW0N72vITVVklmSDMwGAZIAHAUi4U5XzoX5I8n7PtnII2iHQMV4g4LGg>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 28D7741AE; Mon, 16 Jul 2018 00:34:06 -0400 (EDT)
Message-Id: <1531715646.3409224.1441802368.7EA77C4F@webmail.messagingengine.com>
From: Patrick Mevzek <pm@dotandco.com>
To: regext@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-957169fa
Date: Mon, 16 Jul 2018 06:34:06 +0200
In-Reply-To: <119F5829-3969-4C19-87DD-8B5A754871DA@verisign.com>
References: <61D9AB58-FF73-4642-9F01-01E1808E08BC@verisign.com> <1528176752.2069319.1396420528.6ABF4D3A@webmail.messagingengine.com> <F51077D3-BBC9-4988-B2CD-7AE239623A2F@verisign.com> <1528268841.3464175.1398071896.2A1506D1@webmail.messagingengine.com> <6D4D1922-DB5B-4ECA-A3C6-4FF5BD7FDC38@verisign.com> <1528525555.892391.1401744920.0ADC2EFC@webmail.messagingengine.com> <4188572A-F2BC-4332-9BDD-5D0DE5AF2A25@verisign.com> <1528930082.2763407.1407286040.5830803A@webmail.messagingengine.com> <119F5829-3969-4C19-87DD-8B5A754871DA@verisign.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/nQKzJF4_7xLmYPheIzS6a8Xqt0o>
Subject: Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2018 04:34:09 -0000

On Thu, Jun 14, 2018, at 15:12, Gould, James wrote:
> We can consider alternative authentication options if there is a 
> concrete proposal and the proposal does provide a security enhancement. 

It has alreay been proposed to be able to use non-plain passwords authentication....

> I 
> reviewed the RFCs that you referenced (SASL and PRECIS) and I don’t see 
> anything in them that defines an alternative authentication mechanism 
> for EPP. 

SASL define a framework to be able to easily handle various authentication meachinism, like plain and hashed password at the same time.
This allows for more extensibility.

PRECIS define a framework to deal with "internationalized" strings in application, and this covers both usernames and passwords. It gives idea on how to define a profile (and I still remain unconvinced of the need to remove space from the passwords accepted for EPP, again because it is not a password that a human will use).

I believe they both could be useful starting block  (as they exist and are IETF standards) if these parts needs to be changed/enhanced in EPP.

Incidently, when they are more and more discussions around the subject of "how could a third party, like a DNS provider, mandated in some way by the registrant be able to do changes on the domain on its behalf without having to rely on the registrar", that SASL also handle OAUTH-types of authentication...

> Creating additional authentication options in EPP may result 
> in less security, so it would be good to understand what security aspect 
> needs to be fixed prior to creating additional options.

You never replied on the case of non-plain password authentication.
Can you share how it results on less security, and why the *possibility* (then it is up to the registry to use it or not) of providing it is not useful to consider?

Case in point for example: having it makes handling logging in a simpler way as password does not need to be specifically searched and obfuscated then for security reasons. People looking at logs in both sides would not be able to gain any knowledge of the password used.

-- 
  Patrick Mevzek
  pm@dotandco.com