> 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].
I do not know. My main point was more around: if we decide to put more energy
into "securing" EPP better, providing more options than just plain text
passwords (as asked by Pieter also I think) would be now a good time to think
about, and if we go towards some "extensibility" in authentication frameworks,
why not just build on existing RFCs?
We can consider alternative authentication options if there is a concrete
proposal and the proposal does provide a security enhancement. Currently, most
EPP registries support multi-factor authentication with the combination of user
name / password and client certificate / client IP address. The RFC 5730 16
character maximum password is a undesirable constraint that is addressed via
draft-gould-regext-login-security. 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. 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.
Thanks,
—
JG
James Gould
Distinguished Engineer
[email protected]
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 6/13/18, 6:48 PM, "regext on behalf of Patrick Mevzek"
<[email protected] on behalf of [email protected]> wrote:
On Mon, Jun 11, 2018, at 21:57, Gould, James wrote:
> 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].
I do not know. My main point was more around: if we decide to put more
energy into "securing" EPP better, providing more options than just plain text
passwords (as asked by Pieter also I think) would be now a good time to think
about, and if we go towards some "extensibility" in authentication frameworks,
why not just build on existing RFCs?
--
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
