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

[Mario Loffredo]

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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Thomas Corte (TANGO support)]

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: supp...@tango-rs.com
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] draft-ietf-regext-epp-eai-07.txt - IPR

[Dmitry Belyavsky]

Dear colleagues,

Sorry, I missed the original letter to the ML.

I'm not aware of any IPR from my side.
If it matters, in this area I consider myself as an independent
software developer, with no relationship to any company.

-- 
SY, Dmitry Belyavsky

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Document Shepard Review of draft-ietf-regext-epp-eai-07

[Jody Kolker]

Hello Everyone,


I have completed the shepard review of the draft for Use of Internationalized 
Email Addresses in the Extensible Provisioning Protocol (EPP) 
(https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-eai-07) and 
reviewed with the Authors the following items:



1.   Adding an implementation section.  Does anyone know of any 
implementations?

2.   Adding an acknowledgement section.

3.   Nit - Removing RFC 7451 from the Normative References to the 
Informative References.



Besides those, just waiting on answers to the IP questions.





Once the draft is updated to address the items above, I'll submit the Shepard 
Document.



Please let me know if you have any questions.



Thanks Everyone!

Jody Kolker

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Document Shepard Review of draft-ietf-regext-epp-eai-07

[Gould, James]

Jody,

Thank you for doing the document shepherd review of draft-ietf-regext-epp-eai.  
I include my responses to your feedback embedded below.

--

JG

[cid:image001.png@01D845E4.58A55580]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: regext  on behalf of Jody Kolker 

Date: Friday, April 1, 2022 at 12:58 PM
To: regext 
Subject: [EXTERNAL] [regext] Document Shepard Review of 
draft-ietf-regext-epp-eai-07



Hello Everyone,


I have completed the shepard review of the draft for Use of Internationalized 
Email Addresses in the Extensible Provisioning Protocol (EPP) 
(https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-eai-07)
 and reviewed with the Authors the following items:



1.   Adding an implementation section.  Does anyone know of any 
implementations?



Yes, I have implemented draft-ietf-regext-epp-eai in the Verisign EPP SDK.  An 
implementation status section can be added.



2.   Adding an acknowledgement section.



Yes, we can add an Acknowledgements section



3.   Nit – Removing RFC 7451 from the Normative References to the 
Informative References.



Agreed, RFC 7451 needs to be moved to the Informative References.



Besides those, just waiting on answers to the IP questions.



The IPR question will be answered shortly.



Once the draft is updated to address the items above, I’ll submit the Shepard 
Document.



Please let me know if you have any questions.



Thanks Everyone!

Jody Kolker

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext