I follow the concerns of Patrick,
I'm neither a fan of the [LOGIN-SECURITY]. Isn't it enough to specify that a
server MUST ignore the value of <pw> if the loginSec extension is used?
I don't know if I overlooked it, but it seems that there's only support for
password based login and provisioning. Do you plan to support other things like
digest authentication?
Kind regards
Pieter
On 05/06/18 07:32, "regext on behalf of Patrick Mevzek"
<regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote:
On Mon, Jun 4, 2018, at 22:30, Gould, James wrote:
> The Login Security Extension (draft-gould-regext-login-security) was
> posted
> (https://datatracker.ietf.org/doc/draft-gould-regext-login-security/)
Thanks James, this is nice.
Some comments before really trying to implement it:
- I am not a huge fan of the [LOGIN-SECURITY] token, but I see no good
alternatives. Specifically, this variant forbids any later revision of the
specification. So I would either argue for the shortname, loginSec-1.0, so that
at least it will be backwards compatible or, to be bolder, use RFCXXXX when
XXXX will be known...
Or to want to avoid collisions at all cost, I would either go towards
something like U+001A (SUBSTITUTE) or U+001B (ESCAPE) repeated 16 times.
Or a completely different route would be to use the XML ID/IDREF mechanism.
I am not 100% sure but maybe the current <pw> could have an xml:IDREF
attribute with a path pointing to the new loginSec:pw node which would have the
corresponding xml:ID attribute?
- for loginSec:pw/loginSec:newPw I am not a fan of specifying minimum
length, because if you remove all maximum length constraint in the schema for
the maximum, by symmetry I would do the same for the minimum, leaving both to
pure policy choices by the server (the "sensible" minimum depends of course on
the number of different characters allowed, it would not be the same value when
accepting only ASCII or when accepting "any" Unicode characters
- I would also not put anything here related to what characters are allowed
or not. I would instead defer to the PRECIS framework (RFC7564) and more
specifically section 4 of RFC8265. At least as a base, using OpaqueString and
then building one more constrained on top of it if it is really deemed important
(passwords here are typically not seen nor managed by humans, so I think
they need less strict rules than when handled by humans, and I see no problems
per se with spaces... I have seen far more trouble when people try to use < or
& in a password and forgetting to encode it as those are specific characters in
an XML streams).
I know that RFC5730 does the same thing, but it was written before PRECIS.
So now I think we should instead build on it.
--
Patrick Mevzek
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
