Il 22/02/2024 16:00, Hollenbeck, Scott ha scritto:
Mario, allow me to make a minor adjustment to my suggestion:
“Servers MUST implement at least one method of access control that
limits server connection access to only authorized clients.
Implementation of multiple access control methods is RECOMMENDED.”
[ML] Agreed.
Mario
We need to be clear that unauthorized clients should NOT be allowed to
send ANYTHING to a server that might get processed as part of an EPP
interaction.
Scott
*From:* regext <regext-boun...@ietf.org> *On Behalf Of *Mario Loffredo
*Sent:* Thursday, February 22, 2024 9:30 AM
*To:* Hollenbeck, Scott <shollenbeck=40verisign....@dmarc.ietf.org>;
regext@ietf.org
*Subject:* [EXTERNAL] Re: [regext] Fwd: New Version Notification for
draft-loffredo-regext-epp-over-http-03.txt
*Caution:*This email originated from outside the organization. Do not
click links or open attachments unless you recognize the sender and
know the content is safe.
Hi Scott,
Il 22/02/2024 13:54, Hollenbeck, Scott ha scritto:
I understand that there are options available for client
authentication, and that this isn’t necessarily easy for clients.
However, there are known attacks that can be perpetrated against
servers that allow TCP or TLS connections from unauthorized
clients. One example is described here:
https://hackcompute.com/hacking-epp-servers/
<https://secure-web.cisco.com/1ue8wHGIlyxN-IrXsOyzbTYD2z-ImIVuVvGbKx2t8qM3_V_9oPO2stGT8UYOaw49CYpBUhOaoiyd39bmY4CzNUClJixr7ufI3bKnxp_ociah6fFteJluIGb4rWt7wzCHlOsXKuThrqfwmuQKmJ-uaH2YphL5uivdiSfE1M8WROt3QoulHSHuBbNLLeHnXrF6bODtiboQVTmt2jW4C7YnmY2uHo2B93UgH73WgICFH7tWclRkLp6H3jfdX1hRw7kLsxE3DTl-AIx2d_W83y9Gk-IhrvuLJxh3OlyX3mH0FZWk/https%3A%2F%2Fhackcompute.com%2Fhacking-epp-servers%2F>
[ML] I will look into this.
If there’s something about client certificates that makes them
impossible to use, fine, replace them with another required
mechanism. As such, the draft should say something like this:
Servers MUST implement at least one method of access control that
limits server access to only authorized clients. Implementation of
multiple access control methods is RECOMMENDED.
[ML] Sounds reasonable to me. I'll incorporate this change into the
next version.
Thanks a lot for your feedback.
Best,
Mario
Scott
*From:* Mario Loffredo
<mario.loffredo=40iit.cnr...@dmarc.ietf.org>
<mailto:mario.loffredo=40iit.cnr...@dmarc.ietf.org>
*Sent:* Thursday, February 22, 2024 1:52 AM
*To:* Hollenbeck, Scott <shollenb...@verisign.com>
<mailto:shollenb...@verisign.com>; regext@ietf.org
*Subject:* [EXTERNAL] Re: [regext] Fwd: New Version Notification
for draft-loffredo-regext-epp-over-http-03.txt
*Caution:*This email originated from outside the organization. Do
not click links or open attachments unless you recognize the
sender and know the content is safe.
Hi Scott,
thanks for your quick reply.
Please find my comment below.
Il 21/02/2024 13:47, Hollenbeck, Scott ha scritto:
Tanks for posting the draft, Mario. One quick question: RFC
5734 (Extensible Provisioning Protocol (EPP) Transport over
TCP) states that “Mutual client and server authentication
using the TLS Handshake Protocol is REQUIRED”. Section 8 of
the draft weakens this requirement, stating that “servers
SHOULD require clients to present a digital certificate”.
HTTPS requires both TCP and TLS, so why weaken the requirement?
[ML] There are technical (1-2), ethical (3) and practical (4)
reasons. With regard to reasons 3-4, I can speak on behalf of .it
but I'm pretty sure the situation is quite the same in other ccTLDs.
1) In TLS (RFC 5246), servers must provide clients with a
certificate but clients may provide servers with a certificate if
it is requested by servers. It all depends on the application
protocol built on top of HTTPS. If the purpose of requiring
clients to issue a certificate is implementing a kind of 2FA to
enforce EPP client authentication in addition to client's
credentials, that is not the only way to go. For example, .it
requires that a client ip address could be used by one only
registrar where a registrar can use multiple client ip addresses.
The association between them is created out-of-band, stored in the
underlying db and recorded in the HTTP session, once it is started
. Therefore, at any request, the server (i.e. one of the backend
server cited below) is able to verify that noone is trying to
impersonate someone else. Definitvely, I wouldn't say that using
SHOULD instead of MUST weakens the requirement of enforcing client
authentication as long as alternative measures could be as secure
as client certificates.
2) In an L7 load balancer (LB), clients issue the requests over
HTTPS and the LB forwards the requests to the backend servers
(BSs) over HTTP. This is to speed up the communication between
the LB and the BSs. There is no need to set up an SSL channel
between them because the LB is normally exposed on the border of a
protected network while the BSs are inside that network. A
firewall filters the access by allowing only the communication on
port 443 and only from a selected list of ip addresses. The LB
logic for routing the incoming requests is very simple, hence you
can easily forward a client ip address but it would be much harder
to extract the client identity from a certificate (i.e. either CN
or SAN) and forward it through an ad-hoc HTTP request header field
to let the BS verifies the client identity.
3) Most of .it registrars (~ 1100) are italian SMEs managing only
.it domains. When, in 2009, .it migrated from the old registration
system, based on issuing fax, to the new one, based on issuing EPP
commands over HTTP, the mission of that transition was to reduce
as much as possible the technological effort required to
registrars to comply with the new rules and avoid to discriminate
small players who could not be as technologically powerful as the
big ones. To make that transition as smooth as possible, we
provided some measures to support them in everything. At that
time, we evaluated client certificates could appear a practice
increasing that technological divide. Then we opted for other
fairer and as effective practices.
4) .it domain names market is very dynamic. Companies merge and,
as a result of changing the company names, new registrars are
registered with new credentials and new client certificate would
be needed. Client IP addresses looks more stable. For sure,
updating the set of allowed IP addresses per registrar doesn't
cost a thing.
I'm aware that talking about ethical reasons in a technical forum
like RegExt might seem inappropriate but nonetheless think that
often non-technical aspects have somewhat an influence on making
technical decisions.
My apologizes for the long post. Did my best to answer synthetically.
Best,
Mario
Scott
*From:* regext <regext-boun...@ietf.org>
<mailto:regext-boun...@ietf.org> *On Behalf Of *Mario Loffredo
*Sent:* Wednesday, February 21, 2024 2:15 AM
*To:* regext@ietf.org
*Subject:* [EXTERNAL] [regext] Fwd: New Version Notification
for draft-loffredo-regext-epp-over-http-03.txt
*Caution:*This email originated from outside the organization.
Do not click links or open attachments unless you recognize
the sender and know the content is safe.
Hi all,
just submitted a new version of
draft-loffredo-regext-epp-over-http.
Here in the following the most relevant updates:
1. Has been made fully compliant with RFC 5730
2. Aligns with the structure and makeup of EPP over TCP (EoT)
in RFC 5734
3. Fully pluggable transport for EPP with EoT
4. Verisign added as co-authors
If the agenda of next meeting was not full, I would like to
have a 10-minute slot to present the updates a bit more in detail.
Any feedback is appreciated.
Best,
Mario
-------- Messaggio Inoltrato --------
*Oggetto: *
New Version Notification for
draft-loffredo-regext-epp-over-http-03.txt
*Data: *
Tue, 20 Feb 2024 23:11:09 -0800
*Mittente: *
internet-dra...@ietf.org
*A: *
Dan Keathley <dkeath...@verisign.com>
<mailto:dkeath...@verisign.com>, Daniel Keathley
<dkeath...@verisign.com> <mailto:dkeath...@verisign.com>,
James Gould <jgo...@verisign.com>
<mailto:jgo...@verisign.com>, Lorenzo Luconi Trombacchi
<lorenzo.luc...@iit.cnr.it>
<mailto:lorenzo.luc...@iit.cnr.it>, Lorenzo Trombacchi
<lorenzo.luc...@iit.cnr.it>
<mailto:lorenzo.luc...@iit.cnr.it>, Mario Loffredo
<mario.loffr...@iit.cnr.it>
<mailto:mario.loffr...@iit.cnr.it>, Maurizio Martinelli
<maurizio.martine...@iit.cnr.it>
<mailto:maurizio.martine...@iit.cnr.it>
A new version of Internet-Draft
draft-loffredo-regext-epp-over-http-03.txt has
been successfully submitted by James Gould and posted to the
IETF repository.
Name: draft-loffredo-regext-epp-over-http
Revision: 03
Title: Extensible Provisioning Protocol (EPP) Transport over HTTP
Date: 2024-02-20
Group: Individual Submission
Pages: 10
URL:
https://www.ietf.org/archive/id/draft-loffredo-regext-epp-over-http-03.txt
<https://secure-web.cisco.com/1KC6jFTUqMZOdJ6Po7DLUvEx4bz0ukpJdTEJRZF3dOUg7kFe2kdc4o1QYJSN-A5KRI4ajga3mx9j5Tsu1bi5St5Cx-uNAPP-zwZf_HA62hPwz_9eg00egGGltzTsNNaDizHZCJ8Qfk_M3mODWdby1rFTWL-6XrwRg7jx4CAvpx2iygBoEYzI8nSfyrndF2LS3hCQzMKD9uwb2RWuaAlkMVLJlEApMtxPPTF80K-Epc3S4QwSDz7vCBUTOBc9MwJ9HP1_piTsR_qHHxi4hxILn5bJxyanwkmh2HtYgTGuGrh4/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-loffredo-regext-epp-over-http-03.txt>
Status:
https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/
<https://secure-web.cisco.com/1WgECIVUjOIAsR-iTFVZofRj22KELPh2hR8mXqt4Ah1RMjkgzKWNgiSYSqjhaC9jGxs2cZbo78tWGijeobZgLB-BWiu0HdBadbM28kt_fooT0Q_E4EmZIh5b-HgRmf7cfA2xW3Jcui1LwreE8les4WDgk91q0c1uVcgT4n2MJgRthft2VpOGu1zCSQhc803p20A9z0q9dQS2MRPq9j8VEPAiJ9kgkXdsmP4hGRtbTga0F8_Wd1hHV1gdDQIDMu_txRFAC-fPjrizrYpJwVy50rv9zq5TeoIabT7CQTRAHU68/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-loffredo-regext-epp-over-http%2F>
HTMLized:
https://datatracker.ietf.org/doc/html/draft-loffredo-regext-epp-over-http
<https://secure-web.cisco.com/1myv8wfhgRLMpRy662lU3LEpvfhXhlua4LmjwmAXrUQVz-SCnWY8NRdZrR5_sVzPKSomr0tAgTTlHV8IeplBfyGb4GuUKwmrSVbViybxm3Hs_9FFlnvoaoLt-eKH29bmOk-AuKVN05pZR_25b-GEHyQswHoPuqmPqqDR-0m4hfJBUNziLQkYTcmMvQWYvZP7jTRw2TH9A7mimZVgX-t_YHRknBIo6VIsRoYsnpLQ0pU9-pkSvfbV2ZBi9Z9AtE9nsBoXOXj-tkY3NKf4VlBN9MBPGWuHFuYEcHsifeI3a1WE/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-loffredo-regext-epp-over-http>
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-loffredo-regext-epp-over-http-03
<https://secure-web.cisco.com/12jI5T3lqP1oAgYgBbf_sR7EUAcL6VKmKLkg2ylT0ex8vwIKgjRHZ23Y0CD2WITQBuuLaQ2ksuqC0wswgmdwPrTl3Nh04Ww9tfhzLmUBBIFzgzTCXyQqSJUiSuo02WMuefoj4FvdkPczACJYDVH_FPgB9NSHwsBf3FusBpBfOuRG24bIj-uEGOxnDzLf3hXuChwIWRZrEn69Lkm45r8V_I_kLZaSfpxGhi-eCgCiKByBtLngPzbReNyOuB3Jytgp2e9Nna_6jLwOEwRx1pkntina57RexI6eqTRyG8JvT5h0/https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-loffredo-regext-epp-over-http-03>
Abstract:
This document describes how an Extensible Provisioning
Protocol (EPP)
session is mapped onto a Hypertext Transfer Protocol (HTTP)
connection. EPP over HTTP (EoH) requires the use of Transport
Layer
Security (TLS) to secure EPP information (i.e. HTTPS).
The IETF Secretariat
--
Dott. Mario Loffredo
Senior Technologist
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
<http://secure-web.cisco.com/1o6c2NfEYxxsjKE7HUwmzvM8ny4xX34mbmrT8Rvm6sEhVQyO6-D2WG9MY_Pn8u_iLv2f8wSbItdKvJHo2eI5LEeEXaCG3n8Ue3Vq-bWbF0u0LcDvfg0KqAggaklI3IWf3b8c8PG1o5pxTztoUjDnzOhr3l2QSPDDl6VDYB8o-h3LXz2sOIcAGBY3zVtq3w4le9MLnwy0Re2HbVml2Or8y5Z0gzPzw3kmuQbPuPVvQZyNFvVKsHKQ-FYE2xXyonc9MJKBwn-A_2d5xnLNobAmVOZC8Lc_2uB_1qFVHMmfJGxw/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
--
Dott. Mario Loffredo
Senior Technologist
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
<http://secure-web.cisco.com/1FMArwksz_849iz9FyumjPDji-GzZShIR7_yIpseQkAVRKCGrbxFcJP9EMCESeSGDcy4tz3wf5nAV4N8pa0IbMlQ5uZeSzwCC2SGaUVBkDPJRLfnPIhBHlMPgjNRer-kS-RvZ47Txo0XwDM-oi4zt37Gkvfx21o2g9bFk6_xouo5n-txGgUYxy5gkbj2nyelQiIJ1MUpOae4KSw-QPrqMTlTz3wS6z6If6ji97TZwrPnC_PfDKPvG4HvaXFZo4P85CV_uWMnuC0fYIQNQeFA-w_ubybvBZdHz45Mn4jzhxPk/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
--
Dott. Mario Loffredo
Senior Technologist
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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
