Re: [regext] Federated Authentication for Machine-to-Machine Interactions in RDAP

Mario Loffredo <> Wed, 10 August 2022 10:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C834C14F734 for <>; Wed, 10 Aug 2022 03:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id axIcD9OXdVPM for <>; Wed, 10 Aug 2022 03:02:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 48DEBC15C516 for <>; Wed, 10 Aug 2022 03:02:46 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9018BB8079A; Wed, 10 Aug 2022 12:02:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hkkTA4gaDh28; Wed, 10 Aug 2022 12:02:40 +0200 (CEST)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 85AC8B80686; Wed, 10 Aug 2022 12:02:40 +0200 (CEST)
Message-ID: <>
Date: Wed, 10 Aug 2022 12:00:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0
To: "Hollenbeck, Scott" <>, "" <>
Cc: "" <>
References: <> <> <> <>
From: Mario Loffredo <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [regext] Federated Authentication for Machine-to-Machine Interactions in RDAP
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Aug 2022 10:02:51 -0000

Hi Scott,

lease find my comments below.

Il 09/08/2022 16:42, Hollenbeck, Scott ha scritto:
>> -----Original Message-----
>> From: Andrew Newton <>
>> Sent: Monday, August 1, 2022 4:31 PM
>> To: Mario Loffredo <>
>> Cc: Hollenbeck, Scott <>;
>> Subject: [EXTERNAL] Re: [regext] Federated Authentication for Machine-to-
>> Machine Interactions in RDAP
>> 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.
>> On Fri, Jul 29, 2022 at 7:59 AM Mario Loffredo <>
>> wrote:
>>> The authentication flows explored so far fit well the use cases where
>>> a human occasionally submits a request. The case of authenticated
>>> software agents submitting a lot of requests routinely doesn't find a
>>> practical solution in this draft. I would like to remind everyone that
>>> EU Parliament and EU Council has recently reached an agreement on core
>>> elements of the e-Evidence proposal. Therefore, I guess that soon we
>>> will have to figure out how to provide regular authenticated access to
>>> registration data to categories of users legitimated for their
>>> purposes such as authorities and cybercrime agencies.
>>> That being said, I see two big drawbacks in using the Client
>>> Credential flow, at least as is:
>>> - Client Credential flow is for trusted clients. Clients need to be
>>> registered by the OP before submitting a request for an access token.
>>> But, RDAP clients are generally untrusted and I don't consider
>>> scalable a solution where several RDAP clients are required to
>>> register by many OPs including the local ones. In the approach
>>> described in this draft, the trusted client is the RDAP server.
>>> - Roles and access grants are generally assigned to users not to
>>> clients. In addition, think there would be a potential risk of
>>> providing access to illegitimate users via legitimate clients.
>>> The Resource Owner Password Credential Flow would have fiited better
>>> but it has been rightly deprecated by OAuth. I'm afraid that a usage
>>> of CC Flow in a manner similar to the ROPC flow wouldn't be welcome by
>>> security experts.
>>> I would suggest to explore another approach where a third-party
>>> authority interconnects clients and servers that are mutually authenticated.
>> As long as one method is not to the exclusion of the others, I think we should
>> consider both types of use cases.
>> I agree that there are internet-wide scalability issues in an OP handing out
>> credentials to specific clients.
>> Yet, we have that today. LACNIC rate limits anonymous RDAP queries, and
>> those rate limits may be exceeded if a client uses a LACNIC authorized
>> credential.
> [SAH] So does it make sense to add support for the "Client Credentials Grant" in the draft? I agree that there are some risks to consider, but we can document those to the best of our ability. Mario, what exactly do you have in mind when you say, "another approach where a third-party authority interconnects clients and servers that are mutually authenticated"?

As per what is written in sections 1.3.4 and 2.1 of RFC6749, I do 
believe that the client credential grant is not appropriate in this 
context. AFAIK, client credential grant is used when the authorization 
server authenticates and authorizes an app (rather than a user) whose 
purpose is very limited and the resource server doesn't make access 
control decisions depending on who has submitted the request.

Just to give everyone an example, at .it we use client credential grant 
to protect internal micro-services with specific purposes accessed by 
public services, such as the EPP server and other web applications, 
exposed outside the internal network. With reference to the above 
scenario, the micro-services act as RSs, the public services are 
registered as trusted clients on our AS and all the communications take 
place within the internal network.

With regard to my proposal, at the beginning I had imagined a thrid 
component storing the relationship between client and user credentials 
and mediating the interaction between the client and the server but then 
I realized that such a component already exists and is the AS.

Therefore, my possible solution is the following: a client registers 
with the the AS (either dynamically or just once) , then asks the AS for 
an access token that finally transmits to the server through the 
"Bearer" authentication scheme.

At present, I can't think of anything else.



> Scott
> _______________________________________________
> regext mailing list

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