Ben,
I believe I found the topic and the proposed text associated with identifying
the nature of the need, which is outlined below. I propose adding the sentence
" EPP [RFC 5730] includes a maximum password length of 16 characters that
inhibits implementing stronger password security policies with higher entropy."
as the second sentence of the introduction. This can be added to
draft-ietf-regext-login-security-10. Do you agree with this change? Are there
any other changes that are needed prior to the posting of
draft-ietf-regext-login-security-10?
Thanks for pointing to the list discussion of potential alternative
authentication approaches, and I'll see if I can make time to write
something down. I'm not opposed to publishing an evolutionary improvement
while revolutionary changes are immature, but I do think that the document
should be more explicit about the nature of the need. Yes, artificial
password-length limitations are bad and I'm happy to see this work to
remove them from EPP, but are there particular security deployment
considerations driving this, such as a desire to support memorable
passphrases that contain sufficent entropy? From a purely
information-theoretic perspective, if we limit ourselves to the ASCII
alphabet from 0x20 to 0x7e, 16 charcters gives roughly 104 bits of entropy
available, which is not catastrophically bad; in combination with the
prerequirement for TLS client-certificate authentication, a server could
block or rate-limit brute-force guessing attacks and achieve a level of
security that is reasonable for many if not most web-available services
today. Even if the perceived need is just "artificial limitations on
password length are detrimental to future evolution in security practice"
(which seems unlikely to me based on my bayesian prior), it seems worth
saying. I suspect that there's more motivation in play, and would like to
better understand it.
JG2 - The only deployment consideration is being able to set passwords beyond
the 16 character limit of RFC 5730 for the critical domain name registry
systems. Yes, there is multi-factor authentication with EPP (user
name/password and client certificate, and optionally client IP address), but
there is the operational need to enhance the security of the passwords with
longer lengths and higher entropy (e.g., at least 128 bits). Are you looking
for a sentence being added to the introduction that identifies the problem more
explicitly, such as:
EPP [RFC 5730] includes a maximum password length of 16 characters that
inhibits implementing stronger password security policies with higher entropy.
--
JG
James Gould
Distinguished Engineer
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 2/24/20, 6:02 PM, "Benjamin Kaduk" <[email protected]> wrote:
This text regarding internationalization/normalization works for me.
Looking at the diff from -07 to -09, we seem in pretty good shape overall;
were we going to add a note to abstract and/or introduction about "this
extension allows for the use of strong passwords with EPP"? (I think Jim
had proposed actual text at some point that's better than my paraphrased
version here.)
-Ben
On Mon, Feb 24, 2020 at 07:43:47AM -0800, Barry Leiba wrote:
> Great; thanks, Jim. Ben, are you OK with this now?
>
> Barry
>
> On Mon, Feb 24, 2020 at 5:28 AM Gould, James <[email protected]> wrote:
> >
> > Barry & Ben,
> >
> > Thanks for the detailed discussion. I will change the "recommended" to
the normative "RECOMMENDED" and change the PRECIS sentence to match Ben's
proposal. The end result will be:
> >
> > It is RECOMMENDED that the plain text password in the <loginSec:pw> and
<loginSec:newPw> elements use printable ASCII characters #x20 (space) - #x7E
(~), with high entropy, such as 128 bits. If non-ASCII characters are supported
with the plain text password, then use a standard for passwords with
international characters; the OpaqueString PRECIS profile in [RFC8265] is
recommended in the absence of other considerations.
> >
> > I'll include this change in the posting of
draft-ietf-regext-login-security-09.
> >
> > Thanks,
> >
> > --
> >
> > JG
> >
> >
> >
> > James Gould
> > Distinguished Engineer
> > [email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
> >
> > 703-948-3271
> > 12061 Bluemont Way
> > Reston, VA 20190
> >
> > Verisign.com <http://verisigninc.com/>
> >
> > On 2/22/20, 6:15 PM, "Barry Leiba" <[email protected]> wrote:
> >
> > Thanks, Ben; this helps a lot.
> >
> > Jim, are you good with Ben's suggestion or a variation of that?
It's
> > just a small update to what you have, and makes it clearer that if
you
> > need I18N, PRECIS is the weay to do it.
> >
> > Barry
> >
> > On Fri, Feb 21, 2020 at 10:08 PM Benjamin Kaduk <[email protected]>
wrote:
> > >
> > > Hi Barry,
> > >
> > > On Sat, Feb 15, 2020 at 12:12:29AM -0500, Barry Leiba wrote:
> > > > Hi, all...
> > > >
> > > > I'm sorry if I'm not completely clear about where the
discussion is,
> > > > but what Jim's mail system does to the quoting is horrendous
(as is
> > > > the case with most HTML-based mail systems), and I can't easily
follow
> > > > the thread.
> > >
> > > I sympathize; I find that with some regularity I end up saving the
> > > text/html component to a file and opening it in a browser in
order to have
> > > a chance of figuring out what's going on.
> > >
> > > > So I'm just picking up this recent bit from Ben:
> > > >
> > > > > I think it would probably be helpful for the responsible AD
to chime in; my
> > > > > understanding is still that the PRECIS profiles are to be
used as part of a
> > > > > protocol as opposed to part of a deployment, and that
allowing for
> > > > > different rules to be used in different sites is risky. I
understand that
> > > > > there's the extra context here of the potential for
preexisting deployments
> > > > > that started using non-ASCII passwords in the absence of any
guidance from
> > > > > the IETF on how to do so, and we have to consider whether
what we do will
> > > > > break them, and so hearing from someone versed in the matter
who has
> > > > > thought about this particular case would help assuage my
concerns. One
> > > > > possible route (given that, as I understand it, a lot of EPP
deployments
> > > > > involve exchange of configuration and deployment information
between peers
> > > > > out of band) would be to say that the PRECIS profile is used
as a default
> > > > > in the absence of other configuration knowledge for a given
deployment,
> > > > > though I acknowledge that this is not without flaws.
> > > >
> > > > I had discussed the PRECIS issue with Jim, which is what
resulted in this text:
> > > >
> > > > It is recommended that the plain text password in the
<loginSec:pw>
> > > > and <loginSec:newPw> elements use printable ASCII characters
#x20
> > > > (space) - #x7E (~), with high entropy, such as 128 bits. If
non-
> > > > ASCII characters are supported with the plain text password,
then use
> > > > a standard for passwords with international characters, such
as the
> > > > OpaqueString PRECIS profile in [RFC8265].
> > > >
> > > > I think that's adequate, given that (1) we really are expecting
that
> > > > almost all passwords out there are ASCII, and we're recommending
> > > > keeping it that way, (2) we need to allow, but discourage,
non-ASCII
> > > > UTF-8 passwords for the (expectedly rare) cases where they
might be
> > > > used, and (3) these are stored passwords that are passed around,
> > > > rather than passwords entered by users and subject to issues
created
> > > > by different input mechanisms and effects on eyeballs.
> > > >
> > > > I can see that we might want to change "recommended" to
"RECOMMENDED",
> > > > and I don't object to that (Jim?). Beyond that, I'm not sure
where
> > > > you're going with "PRECIS profiles are to be used as part of a
> > > > protocol as opposed to part of a deployment." It's really both,
> > > > depending upon the situation. In this case, it's saying that
if your
> > > > server supports non-ASCII passwords, you'd better use the
OpaqueString
> > > > profile to handle them. If your server doesn't (it supports
only
> > >
> > > I'm much happier with your prose description here than the
snippet quoted
> > > from the document -- what's in the document now seems to be
weaker than
> > > what you say ("pick a standard; PRECIS is a standard" vs "you
should use
> > > PRECIS, though here's an out if you can't for some reason").
> > >
> > > My primary concern here is that the client and server need to
know to use
> > > the same standard (whatever it is). Making this RFC say flatly
"use
> > > PRECIS" is IMO the easiest way to do that, though given how much
other
> > > stuff in EPP has to be set by out-of-band configuration I won't
raise a
> > > fuss if this ends up being another one. If it does need to be
known out of
> > > band, though, my preference is always for that need to be stated
in the
> > > RFC.
> > >
> > > > ASCII passwords), we're good. From a PRECIS point of view, I
don't
> > > > see more that needs to be done with this.
> > > >
> > > > I think a large part of the point of the text that Jim added is
an
> > > > acknowledgement that in the common case of ASCII-only
passwords, we
> > > > don't have to worry about normalization/canonicalization of
password
> > > > strings at all, and just doing straight byte-string comparisons
works.
> > > > And the OpaqueString profile is there for cases where it's
needed.
> > > >
> > > > Now, it's certainly true that if a server *supports* non-ASCII
> > > > passwords, then *all* password processing on that server has to
use
> > > > the OpaqueString profile, even if there are not any actual
non-ASCII
> > > > passwords present... just in case one might show up. And I
think the
> > > > text does say that.
> > >
> > > (repeating myself, but I think the text says "all password
processing on
> > > that server has to use the chosen standard for non-ASCII
passwords" [which
> > > is not necessarily the OpaqueString PRECIS profile])
> > >
> > > > Is there something in this discussion that I'm missing that I
need to
> > > > address? Is there specific text you might suggest? Are there
other
> > > > issues beyond this one that are still open? How close are we to
> > > > resolving this?
> > >
> > > I think just adding the extra background and your sense of what
the text is
> > > trying to convey has been a big help. I would suggest rewording
to:
> > >
> > > [...]. If non-
> > > ASCII characters are supported with the plain text password,
then use
> > > a standard for passwords with international characters; the
> > > OpaqueString PRECIS profile in [RFC8265] is recommended in the
absence of
> > > other considerations.
> > >
> > > Your explanation suffices such that I will not require this
change to clear
> > > my Discuss, though.
> > >
> > > -Ben
> >
> >
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
