Patrick,
> JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 7564
> and 8265.
Please also look at the SASL framework (RFC4422 and RFC4616 for its PLAIN
version which is basically what we have currently) : this allows to decouple
authentication needs to the underlying application/protocol, which also address
Pieter remark about other ways to authenticate.
JG - I don’t believe there is any desire to switch from using the variant of
the PLAIN SASL mechanism [RFC4616] defined in the existing EPP RFC [RFC5730].
SASLprep may still apply in preparing the passwords for setting or comparison.
I believe that we can incorporate similar language in the Security
Considerations of RFC 5730 into the Security Considerations section of
draft-gould-regext-login-security as it relates to the password. We can
reference the Passwords section of RFC 8265 that defines the OpaqueString
PRECIS profile.
Was your concern around the following text in describing the <loginSec:pw> and
<loginSec:newPw> elements in draft-gould-regext-login-security? If so, this is
simply defining what will happen with the element data by the XML Parser by
using of the XML schema “token” type. EPP RFC 5730 uses the “token” type of
the <pw> and <newPw> elements. Is a different XML schema type desired? I
believe removing the leading and trailing whitespace makes sense so the XML
whitespace is insignificant, but should the contiguous whitespace be collapsed
to a single space. The XML schema “normalizedString” and string “types” don’t
remove the leading or trailing whitespace. I don’t believe that we’ve run into
any issues with using the XML schema “token” type in RFC 5730, so my preference
is to use the same type.
All leading and trailing whitespace is removed, and all internal contiguous
whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage return), and
#x20 (space) is replaced with a single #x20 (space).
This would of course imply bigger changes and deeper ones, but for extended
features also.
I note in passing that there was always a way to extend authorization
mechanisms in EPP, for the domain:auth element.
I have never seen however any extension proposing there anything different.
JG - I too have not seen an extension of the authorization mechanism in EPP yet
with the use of <domain:authInfo><domain:ext>…</domain:ext></domain:authInfo>.
—
JG
James Gould
Distinguished Engineer
[email protected]
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 6/9/18, 2:26 AM, "Patrick Mevzek" <[email protected]> wrote:
On Wed, Jun 6, 2018, at 15:02, Gould, James wrote:
> JG - I don't view the 8 minimum as a "sacred cow" that would require the
> next iteration of the extension to increase it.
It was 6 before and apparently we "need" to upgrade to 8 now.
I am quite sure than in 5 years we would want to increase 8 to 10 and so
on, this is purely Moore's law.
So to ease future maintenance I am just saying: remove this arbitrary limit
in the protocol, since it is a policy decision anyway.
> but I don't believe that it makes sense to not
> at least define the minimum to meet the existing security guidelines.
For me defining a minimum has no sense if you do not define the space of
possible passwords (which characers) and even various other constraints you may
place (like no repeating character, or at least one uppercase, etc.)
For the sake of it, imagine the space of allowed characters are digits.
Do you think the security would be increased in any way going from a length
of 6 to a length of 8 digits?
> JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 7564
> and 8265.
Please also look at the SASL framework (RFC4422 and RFC4616 for its PLAIN
version which is basically what we have currently) : this allows to decouple
authentication needs to the underlying application/protocol, which also address
Pieter remark about other ways to authenticate.
This would of course imply bigger changes and deeper ones, but for extended
features also.
I note in passing that there was always a way to extend authorization
mechanisms in EPP, for the domain:auth element.
I have never seen however any extension proposing there anything different.
--
Patrick Mevzek
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
