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

[Mario Loffredo <[e-mail]>]

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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo