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
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
