Subject: Re: [regext] Comments to the feedback about epp-over-http

From: Mario Loffredo <[email-masked]>
Date: Fri, 1 Apr 2022 09:00:51 +0200

Hi Francisco,

Il 31/03/2022 22:19, Francisco Obispo ha scritto:
>
> Hi Mario,
>
> Response inline.
>
> On 31 Mar 2022, at 13:03, Mario Loffredo wrote:
>
>     Hi Francisco,
>
>     appreciated but:
>
>     1) The ssl variables in NGINX are different.
>
> Yes, they usually are :-)
>
>     2) Even supposing to extract CN or SAN, as it seems one should do
>     in NGINX via a regular expression, it doesn't necessarily
>     correspond to the registrar username to access the EPP server.
>
> Well, whichever method is used, it is important to tie the SSL client 
> to the |clID| otherwise an authorized client could try to login with a 
> separate account, so it serves the purpose of a multi-factor 
> authentication:
>
>   * IP address whitelist
>   * SSL client certificate pinning
>   * clID/password combination
>
Is this a recommendation or is a must?

It seems to me that there is no sentence in the security consideration 
section of RFC5734 stating that the SSL CN MUST be equal to clID ?

Anyway the concept that client certificate may be required is already 
present in the security considerations of epp-over-http:

    As a further measure to enforce the security, servers MAY require
    clients to present a digital certificate.  Clients who possess and
    present a valid X.509 digital certificate, issued by a recognized
    Certification Authority (CA), could be identified and authenticated
    by a server who trusts the corresponding CA.  This certificate-based
    mechanism is supported by HTTPS and can be used with EPP over HTTP.
    The TLS protocol describes the specification of a client certificate
    in Section 7.4.6 of [RFC8446].

I can replace in that sentence the word "MAY" with "SHOULD" and add text 
about client being required to check server certificate.

But the real question is another.

The real question is that every HTTP-based server implementing HTTP 
sessions through session cookies (including the RDAP server!) starts a 
session as a consequence of a successful authentication.

It's unnatural to start an HTTP session after a command that doesn't 
provide the server with any user preference. In RDAP, the user 
preferences are the user claims; in EPP, they are the namespaces that 
should be in force until the Logout.

This should be enough just to follow a consistent designing method 
between two protocols that would be used at the same layer of the stack.

Best,

Mario

>     3) I repeat: why should I complicate a solution to come to another
>     that I consider less efficient?
>
> Those methods described above, happen at different layers in the 
> stack, it is not complicated, this is exactly how we operate today (at 
> least Tucows Registry), SSL certificates are checked to ensure they 
> belong to the clID.
>
> IMO a new transport for EPP should at least offer the same safeguards.
>
>     Thanks again for the example that maybe will be useful in the
>     future :-)
>
>
> N/P, this is very similar to how IP access works at the HTTP level 
> using the |X-Forwarded-For| header or similar approach to signal the 
> application information about the client.
>
> Francisco
>
-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Fri, 1 Apr 2022 14:37:06 +0200

Hello Scott,

On 3/31/22 19:58, Hollenbeck, Scott wrote:

> [SAH] Client certificates ARE required for TCP transport with TLS. See here:
> 
> https://datatracker.ietf.org/doc/html/rfc5734#section-9
> 
> They're not specifically a requirement for EPP, but they are for that particular transport protocol (which just happens to be the only standard transport protocol).

Interesting, it seems that we overlooked that in our own (TANGO) 
implementation. There, we're currently allowing clients to connect 
without presenting a client certificate, but they *may* send one (which 
isn't checked beyond the CA's trustworthiness).

The thing is that many registries' client certificate checks end with 
doing just that, i.e. clients may present ANY certificate, as long as 
it's not expired and issued by a CA trusted by the registry's server. In 
particular, the common name is usually *not* checked, as no properties of 
the client certificates are "negotiated out of band", as RFC 5734 suggests.
To us, this common practice seemed silly, as anybody can easily get a 
trusted certificate like that, but all that does is adding costs and 
effort for the client, while not adding any security. This is why we made 
the client certificate optional, but as it's obviously an RFC violation, 
we'll need to change that.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: [email-masked]
Germany