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 p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
