Hi Pawel,
see my comments inline.
Il 17/03/2026 12:25, Pawel Kowalik ha scritto:
Hi Mario,
On 17.03.26 12:06, Mario Loffredo wrote:
However, the risk of managing too many sessions or maintaining unused
sessions is common to all mechanisms based on server-generated
secrets to prevent clients from authenticating on every request. To
be clear, EoH sessions = RPP JWTs.
The mitigation measures are the same: limit the number of
simultaneously active secrets and optimize secret lifetime.
This is only true if the tokens are persisted. This must be true for
opaque tokens, but is not true most of cases for rfc7523 JWT tokens.
These tokens are self-carrying and only resource which can be
exhausted is the token endpoint itself. A sane OAuth2 server will rate
limit token generation per client to prevent that.
[ML] It's true but with two drawbacks. A JWT once created remain valid
until its expiration time, making them vulnerable to misuse if stolen,
even after a user logs out. Security risks persist throughout their
lifespan. Therefore, in order to mitigate these risks, it's crucial to
finda good compromise between the lifetime of a JWT and a sustainable
rate of requests.
Briefly, JWT works well in distributed systems, but it introduces new
risks compared to session-based models, especially around token leakage
and revocation.
Security concerns related to JWT are also mitigated by the nature of the
REST service. This is why I'm in favor of using JWT in RDAP but I see
more disadvantages in using them in a provisioning protocol.
To be clear, I'm not saying JWTs shouldn't be used, but I'm showing the
pros and cons of using them.
The other disadvantage is the additional effort required for clients to
manage tokens in general, compared to HTTP sessions. Clients must
register with the authentication server, access the token endpoint,
obtain the token, and store and refresh it unless they want to request a
new one for each request.
Managing an HTTP session is much less complex than managing a JWT.
For http sessions is different, as usually some server-side resources
are created to manage the session. There are solutions that carry the
same properties as JWT tokens, where cookies are basically encrypted
tokens with full state of the session (and nothing on the server), but
I don't know how applicable it is to EoH. If the session state may
change during the session, then strict ordering of the requests is
required to prevent stale session cookie usage.
[ML] The information stored in the EPP session is basically that
negotiated at the time of EPP Login and remains immutable for the
duration of the session.
- An <options> element that contains the following child elements:
- A <version> element that contains the protocol version to be
used for the command or ongoing server session.
- A <lang> element that contains the text response language to be
used for the command or ongoing server session commands.
The values of the <version> and <lang> elements MUST exactly match
one of the values presented in the EPP greeting.
- A <svcs> element that contains one or more <objURI> elements that
contain namespace URIs representing the objects to be managed
during the session. The <svcs> element MAY contain an OPTIONAL
<svcExtension> element that contains one or more <extURI> elements
that identify object extensions to be used during the session.
Best,
Mario
Kind Regards,
Pawel
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
