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/
[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>
*Sent:* Thursday, February 22, 2024 1:52 AM
*To:* Hollenbeck, Scott <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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
