Hi Pawel,
again my comments inline.
Il 17/03/2026 16:10, Pawel Kowalik ha scritto:
Hi Mario,
On 17.03.26 15:20, Mario Loffredo wrote:
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.
[PK] My point was not about proving which one is better. Just the
statement was not correct about usage of JWTs, that's all. I agree
with all you say and the operator of RPP server would have to make
some choices and take trade-offs. I think only non-negotiable factor
written down in requirements is that RPP must remain stateless.
[ML] I agree with you. As I wrote, I have no prejudice against the use
of JWTs and tokens in general. Like you, I supported the proposal to use
them in RDAP authentication, and at .it, we currently use them for
authentication to some REST services.
I try to objectively weigh the pros and cons of their use.
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.
[PK] ok, if this is all embedded in the cookie (+ some client
identification) and the cookie does not change during the session then
server may not need to keep track of open sessions.
But, same time would it be the client who assures order of request
processing? The "HTTP transport" cannot assure that any more, because
parallel requests with the same cookie will be still legit.
[ML] EoH draft specifies that the cookie contains the session
Identifier, not the entire session.
Regarding the order, James, in reply to Maarten, has already proposed a
solution to your question.
In any case, in normal operation, a client sends a new request after
checking the response of the previous one, stating with the EPP Login
and ending with the EPP Logout.
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]
