Subject: [regext] draft-ietf-regexy-login-security

From: "Martin Thomson" <[email-masked]>
Date: Wed, 13 Nov 2019 11:57:11 +1100

In reviewing the IANA registrations for this draft, I noticed a design issue that I think the working group needs to discuss more.

>From a strictly schema perspective, the whitespace normalization requirements for token will likely have implications for usability of passwords that include spaces on the <pw> and <newPW> elements.  That's a problem for manually constructed messages, so it would be a minor comment.

However, that would ignore the fact that use of plaintext passwords is not a good practice.  Even if this is merely revising something from RFC 5730 to extend their length (which is fine in isolation), I think that the working group needs to more fully consider.  Though it remains common, relying on password-based authentication is generally regarded as a failing; though it might be unavoidable, most authentication systems try to avoid it, or only use passwords as a way to step up to something stronger.  Sending passwords in cleartext in protocols is regarded as a serious exposure in most systems.  Even passing hashed and salted passwords has risks that mean that is generally avoided where possible.

For a protocol of this nature, it seems like alternative methods could be developed.  And if passwords are unavoidable for usability reasons I can't see right now, then the CFRG is developing password-based authentication protocols that might be suitable for this.  Or there are protocols like OAuth that might allow for delegation.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 13 Nov 2019 13:37:01 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Martin Thomson
> Sent: Tuesday, November 12, 2019 7:57 PM
> To: [email-masked]
> Subject: [EXTERNAL] [regext] draft-ietf-regexy-login-security
>
> In reviewing the IANA registrations for this draft, I noticed a design issue that
> I think the working group needs to discuss more.
>
> >From a strictly schema perspective, the whitespace normalization
> requirements for token will likely have implications for usability of passwords
> that include spaces on the <pw> and <newPW> elements.  That's a problem
> for manually constructed messages, so it would be a minor comment.
>
> However, that would ignore the fact that use of plaintext passwords is not a
> good practice.  Even if this is merely revising something from RFC 5730 to
> extend their length (which is fine in isolation), I think that the working group
> needs to more fully consider.  Though it remains common, relying on
> password-based authentication is generally regarded as a failing; though it
> might be unavoidable, most authentication systems try to avoid it, or only
> use passwords as a way to step up to something stronger.  Sending
> passwords in cleartext in protocols is regarded as a serious exposure in most
> systems.  Even passing hashed and salted passwords has risks that mean that
> is generally avoided where possible.

TLS protection is specified to avoid sending passwords in plaintext form.

I agree that we should consider login security improvements over time as new options are available to us. It's always best to start a conversation by throwing a proposal out there for people to consider.

Scott

---

From: "Patrick Mevzek" <[email-masked]>
Date: Wed, 13 Nov 2019 14:54:37 -0500

> TLS protection is specified to avoid sending passwords in plaintext form.

Yes but this solves only the security in transit part, not security at rest.

These EPP frames are stored on both side of the connection, logged, added to backups, etc.
This is needed for various troubleshooting needs, as well as disputes and so on.

Without any specific code filtering out the passwords out of the frame before
storage (which comes from its own edge cases because then it means you are troubleshooting things based on data as stored not really as exchanged, even if the difference in theory is well contained to specific parts), you then have the password in clear in many places.
And not all registrars
maintain open persistent connections or some registries shut down active connections
like each hour no matter what, which means a registrar may send dozens or hundreds
or more login request per day.

> I agree that we should consider login security improvements over time 
> as new options are available to us. It's always best to start a 
> conversation by throwing a proposal out there for people to consider.

I am interested to work on this if anyone else is also. I might try to offer
a proposal at some point, not sure.

During discussions of this draft, I pointed to SASL for the extensibility it provides,
but this was apparently not a good fit for this specific extension.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 13 Nov 2019 20:13:20 +0000

> From: regext <[email-masked]> On Behalf Of Patrick Mevzek
> Sent: Wednesday, November 13, 2019 2:55 PM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [regext] draft-ietf-regexy-login-security
> 
> 
> 
> Without any specific code filtering out the passwords out of the frame
> before storage (which comes from its own edge cases because then it means
> you are troubleshooting things based on data as stored not really as
> exchanged, even if the difference in theory is well contained to specific
> parts), you then have the password in clear in many places.
> And not all registrars
> maintain open persistent connections or some registries shut down active
> connections like each hour no matter what, which means a registrar may
> send dozens or hundreds or more login request per day.

I don't think that local storage of sensitive information, such as passwords, is a *protocol* issue per se. It does make sense to note that it's a bad idea to do that in the Security Considerations sections of RFCs where passwords are exchanged as part of a protocol interaction, but it's not an interoperability issue.  An even better idea is to recommend "better" practices in those Security Considerations sections.

Scott

---

From: "Patrick Mevzek" <[email-masked]>
Date: Wed, 13 Nov 2019 15:32:47 -0500

On Wed, Nov 13, 2019, at 15:13, Hollenbeck, Scott wrote:

> I don't think that local storage of sensitive information, such as 
> passwords, is a *protocol* issue per se. It does make sense to note 
> that it's a bad idea to do that in the Security Considerations sections 
> of RFCs where passwords are exchanged as part of a protocol 
> interaction, but it's not an interoperability issue.  An even better 
> idea is to recommend "better" practices in those Security 
> Considerations sections.

It is not a protocol issue per se, but if the protocol is so designed that
they are definitively not exchanged as plain text (even over a transport
protecting them), then it becomes not an issue anymore at all, as there is no
more sensitive information to deal with.
One stone, two birds.

Remember that the first step to secure information is just making sure
you handle as little sensitive information as needed, and then secure the rest.

Having clear text passwords at the protocol level is definitively not
a MUST for the protocol to work correctly, the protocol could work with other ways
to authenticate, eliminating the sensitive part of the information exchanged.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Wed, 13 Nov 2019 15:37:34 -0500

On Wed, Nov 13, 2019, at 15:13, Hollenbeck, Scott wrote:
> passwords, is a *protocol* issue per se.

"Interestingly" on another proposal (to handle transfers) when I said
it is absolutely not a protocol/interoperability issue how the passwords
are chosen or stored by the registry, I was replied that it is definitively a
protocol issue and that the draft should be discussed by the working group!

I do not see how one password (the client one) can be not a protocol issue,
but another one (the domain ones) can be. They are both exchanged in plain text
and hence are sensitive information where the protocol should be so defined that
it could work without having to exchange this sensitive information at all.

None are protocol/interoperability issues in a way, and none should be sent in clear
(no matter what the transport; and do remember that EPP ought to be transport
agnostic, and there were attempts in the past to have it over SMTP for example,
in fact at least one registry has it that way nowadays...)

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 13 Nov 2019 20:43:16 +0000

> Sent: Wednesday, November 13, 2019 3:33 PM
> To: [email-masked]
> > that it's a bad idea to do that in the Security Considerations
> > sections of RFCs where passwords are exchanged as part of a protocol
> It is not a protocol issue per se, but if the protocol is so designed that they
> are definitively not exchanged as plain text (even over a transport protecting
> them), then it becomes not an issue anymore at all, as there is no more
> sensitive information to deal with.
> One stone, two birds.
> 
> Remember that the first step to secure information is just making sure you
> handle as little sensitive information as needed, and then secure the rest.
> 
> Having clear text passwords at the protocol level is definitively not a MUST
> for the protocol to work correctly, the protocol could work with other ways

Agreed! As I said earlier:

"I agree that we should consider login security improvements over time as new options are available to us."

Remember, EPP is now 20 years old. There are almost certainly better ways of addressing this topic than we had at our disposal in 1999. All it takes is an Internet-Draft, or a note to the mailing list, to start exploring alternatives.

Scott

---

From: "Patrick Mevzek" <[email-masked]>
Date: Wed, 13 Nov 2019 15:43:59 -0500

On Tue, Nov 12, 2019, at 19:57, Martin Thomson wrote:
> For a protocol of this nature, it seems like alternative methods could 
> be developed.  And if passwords are unavoidable for usability reasons I 
> can't see right now, then the CFRG is developing password-based 
> authentication protocols that might be suitable for this.  Or there are 
> protocols like OAuth that might allow for delegation.

I agree, there is no reason for this protocol to have clear text passwords
(both login and domain associated ones, I do not know any registry using contact
passwords but it may exist).
For the domain part, there is a separate discussion, as a draft emerged
to handle transfers but still using plain text passwords. I put on the table
an alternate proposal that works without any domain password whatsoever. So I think
"no password" is a reachable goal there, but it is a separate discussion from this draft.

As for the login we are discussing here,
I agree we could/should/may do better/differently.

That may be a topic of discussion for other/later drafts.
I was not a 100% fan of this proposal exactly because I agree with the goal
(improving current state of security) but not with the mean (I think we 
must go further than just allowing longer passwords, just this adds only
marginal extra security by itself).

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Wed, 13 Nov 2019 15:47:16 -0500

On Wed, Nov 13, 2019, at 15:43, Hollenbeck, Scott wrote:
> All 
> it takes is an Internet-Draft, or a note to the mailing list, to start 
> exploring alternatives.

There were already, during discussion of this draft in fact.

Maybe the form was incorrect, or not a good fit for this specific draft, so another
draft might be a better idea, I can agree on that.

But then, working on it and its adoption might be even slowler just because
we just improved security a little, enough for most of the use cases to just not
bother revisiting it again. Which is why I wanted the discussion to happen earlier,
but that is the past behind us.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Thu, 14 Nov 2019 14:58:44 +0000

Patrick,

Other proposals for the passing of authentication credentials for EPP would be interesting and I look forward to any proposal that comes up.  New approaches were not a good fit for this draft, but certainly are for other drafts.  

For the management of the passwords (e.g., password encryption on the client-side, password hashing on the server-side, filtering passwords and other secure credentials like auth-info from the client-side and server-side logs, and ensuring that the password is never mirrored back in an error response) could be defined in a BCP draft.  

-- 
 
JG

James Gould
Distinguished Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 11/13/19, 3:47 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    -- 
      Patrick Mevzek
      [email-masked]
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext