From nobody Thu Jul 28 05:44:39 2022 Return-Path: X-Original-To: regext@ietfa.amsl.com Delivered-To: regext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10F5C14CF11 for ; Thu, 28 Jul 2022 05:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pirorg.onmicrosoft.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLWIs6_OSE2g for ; Thu, 28 Jul 2022 05:44:35 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2168.outbound.protection.outlook.com [104.47.58.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED334C14F693 for ; Thu, 28 Jul 2022 05:44:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DUwU7hbTknMy0Q0IvO64YMkavr/t38cptFRWnNcE68InPPayfjv6estafqPUuFue9NzExXdURYdjspKN1/W0cE0vvrG/q0kiMJcyNbVXjYhvv3dWwdxSUAzKdam7JpWEJithem9i4mZpfSmC7DMgl75B02U2A3StKZPRue2YPZdb/o6mnoeSai+sVZecR/NadWjrLM6PsmJdgwSdIKHi8etI90XfAG0PEGl0d3QgCRQGlDNFh3FW2/magIz1YI1GryPjKeOSngk7204e+D34Ntwjbqe+lv3sAu5IBt4/4le01Yftb2HtmZ9i7YH5jPsYQWue72FItNtIluJRfwakhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gH4ZNJiVux0ctPobbkjgDwdfvExdvoqCY6uRI9fhTgE=; b=epaW3K19QpmUfUaL39SjZTOFd3jNIK3rJoY21Vvcx8t+i7rBlq42nlzz1KgHHXIKYPTEDYm5jFUfwOXi6jKbSVGaym78BukUyOGIXsv70SfQrVT0N3cxEuj46Amz609dqafbGPPfNqiDXYHSFSCl6mm57hKLc+9Ez2ckOlXvWQPgun+MLZmUI8FuBLM9wavn7uZLR3ArDmbC9909EIDlWXVHWx2rivJ29ATLfXeT/if4/umuCEGtafJaVWBspPBdmwdvd5k7biH2YA9QSusQFNUjF/onmW63rOc6dXy7jie/jgEFGw1SzvuR/3LXDu2A6uXq1nze0/2SJUfLrKikpA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=pir.org; dmarc=pass action=none header.from=pir.org; dkim=pass header.d=pir.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pirorg.onmicrosoft.com; s=selector2-pirorg-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gH4ZNJiVux0ctPobbkjgDwdfvExdvoqCY6uRI9fhTgE=; b=jyuqEMTXlKNBvm9PuLTly1cKZTuwbgyycqxo4mvxJRlTboyiM0gLTp4MyYkwIwUg5mTK18BNhlRAvCawK88eZeXXZ6HmoaZLkRIl7bTtO1JWMPWs6SE8Tjr1wVrf+Djx/3T+zjYQ0kRvFed2OGU+OJCMomPiaR+KisUUltLd6FQ= Received: from BY5PR10MB4179.namprd10.prod.outlook.com (2603:10b6:a03:206::8) by BN6PR10MB1251.namprd10.prod.outlook.com (2603:10b6:405:f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.19; Thu, 28 Jul 2022 12:44:29 +0000 Received: from BY5PR10MB4179.namprd10.prod.outlook.com ([fe80::1521:31a5:949b:8aee]) by BY5PR10MB4179.namprd10.prod.outlook.com ([fe80::1521:31a5:949b:8aee%4]) with mapi id 15.20.5482.006; Thu, 28 Jul 2022 12:44:29 +0000 From: Rick Wilhelm To: "Hollenbeck, Scott" , "regext@ietf.org" Thread-Topic: Federated Authentication for Machine-to-Machine Interactions in RDAP Thread-Index: Adih5DMCEp6v43VfSnSxcjRQLNyVKQAma+LU Date: Thu, 28 Jul 2022 12:44:29 +0000 Message-ID: References: <5a9b171385c5492e8d64492aa8cf6092@verisign.com> In-Reply-To: <5a9b171385c5492e8d64492aa8cf6092@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=PIR.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 550b57f9-b7e0-4f54-fc1f-08da7096e9a9 x-ms-traffictypediagnostic: BN6PR10MB1251:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dhohgzrl+4urU57eiMRSPSNHwa57j2e+mIQNxi5owk0Gvtmol9YsFW0jI7xLand4cWaezxe6lew9yv3uL3wGZkHD11TdxU7rY7NjmIwTxVypIAAnzBjFLcENgIT7J3Mzi4Qb0i5rHh2LETO/KS8Dd1WMq+nxPoYShdM1+awC4GN5En61dxGX6Nssi9utMZK0QmDk28CJjOy83tXg23XRk5brpsXHBaaOOTa1JxC7ovKbs4EQUS3XgZISxhiN/RuifVEqqg5lkRVMrpWe6z2u5K0ARf2WFfA3gt+X6YpLgdDEAEzKMQaN75ovvG7ceAXVDJIYvwAM3BIp3Wk8+oFJLAbMai3ke9osIHNk+NBndgTEo8YfTVElsOrEJpwJh0BNxUmycJgjQ4pV6SSLTau+UQQDlAZ67nHM8WADoGW660bx4TbQjRDSLAv2mLkX3mDJmwkGfeaR5rCCQB80QyAOWCUYb6xMt+H/OOIjMAUymFtzm8eQrR/VpovYMJ4NrNVavjCZTqC450L0rk/v15N2VSXfHtnOzdljk8RXL3GOzhLsEKIO7oASdwksGB1maUCEMyKVE4IziBXuDGUcbPYcunQFkWmLUKu6k91YSV+jCCbMeiRI9VOIKpeQnSBC6D0vyC8yMoM26Gh9sFfvhP01N0414zDEJaOw0nZ+MeW5tG7yvth6FuyzeIuMkEvqVnrR42xE8FpmpZDi6pCePnewywMIaqqlgdGmHbq6rbF+gNbSyfK7EwyLERXgKTVK1KmQF/spXSUNGykiiMIFFkvXAnW5hASYcn6rI8b+qSpGhpTC400fJSuzyQ+wg8oAGMuWNgpOncWzTMGRNDXTWecTXXYIcGI2sH7Oo6f69Y29h3M= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR10MB4179.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(346002)(376002)(136003)(39840400004)(366004)(396003)(478600001)(5660300002)(52536014)(33656002)(2906002)(8936002)(86362001)(41300700001)(53546011)(966005)(6506007)(9686003)(7696005)(55016003)(166002)(122000001)(186003)(38070700005)(83380400001)(38100700002)(71200400001)(8676002)(110136005)(64756008)(66556008)(316002)(76116006)(66946007)(91956017)(66446008)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?rlIVoPGH3VEFo7C8InGrQAQbQZAL/RE8wtUwoa8iMtOic6NlLq2+ozV6?= =?Windows-1252?Q?CAmyDPAz53pZARv/l7e2W0T1J5N2jRCTQL4AsMyehs1//WVgOIpYKwqI?= =?Windows-1252?Q?rOhDXtPSx9ozECJxuqhJedGZbKtGNYYUuId/IhOx9ww4iD5TaOLbi4+N?= =?Windows-1252?Q?I0htiVgsgGMuYkB10/dcMVQpA8No/kiAQF8yLZLrHyXXwk15aDQlotUN?= =?Windows-1252?Q?BvJZUFTY01G8tHT+5xOrOU1PFNJY/ctm50CuwRx3In1GyWI1TpZHerSr?= =?Windows-1252?Q?4lvxvU495lP0LTTPKQR/V/rv7rI4XbYdpBHX6Hwy79XGPF+AMu9bJ6Ex?= =?Windows-1252?Q?e/bu3j279i+YB6EMgmMO90MTXFn1zzHNRZHSRIfwnD4+F5mTm+09s4CZ?= =?Windows-1252?Q?2h/ekVPqx/3/V8ofCkQMCX8xppcW8EOjzNEjHBwO1+RJHELPbD14WCT1?= =?Windows-1252?Q?nrUMKLl2KNKFc0ZSXEMfMkIRCELoxHw78XQb/JeN6DeKV/lyG5xU1+mD?= =?Windows-1252?Q?cWWrFAGIrHHUNbB/y7D858EjRPXSSbqsLtEKWyslILQ4NbeaDEuHBbVB?= =?Windows-1252?Q?u2tuQEQkgFQsg5oQCQ0apn6/kTyVFpPoY2ijFZwQxxNO8Ch0JlY1W7tt?= =?Windows-1252?Q?MzGOlCeKeyW+lR+aJmmEYXfgm9CbXtAoBOQr+dDITLCCmdi6aWgDK4tW?= =?Windows-1252?Q?eDzwL+sjiVO3O90lR95MQfz+Z4zOpbOtcmJVaaim+uXD92EN5PdL4yCi?= =?Windows-1252?Q?IQiXalZFS4fLgKTyyqwzGaj9Le0YB8EGtRRnA10iHyb9PbiCAibp6VdI?= =?Windows-1252?Q?RmjBvDCi3YejZwbnMlpceOdNz0dAC0cyacw/MhavTyisd656M/xjmlSl?= =?Windows-1252?Q?Y57Xk39DOmmfvFZhRJ4DzugF5rTnIRQXYZvSpPds9psR+r9cZOrPHF8p?= =?Windows-1252?Q?LwiIBnY4VwX1cT9PryT5/y7wz/cAeDq3v8h2HBGy7ZP/uVd9EBVAhlVA?= =?Windows-1252?Q?itusaIJJ459vCEe2IJsm/OCpuirWdah70Z+IXB5QKCjw3EVQWc6h7wte?= =?Windows-1252?Q?nVBNX5UMkRck+V2ugkzTq7elXQ4w+0jvU6IfFvwrh4keSBQk04JZRU6n?= =?Windows-1252?Q?h9bScknht0acxDqcKZupUU6Yf9hLuTRErRZdfdwdz3Mr5tiUd3+A2ggR?= =?Windows-1252?Q?H41aP/ELbaiqxcUb+L/XXM27RAMZh/yGsbjS7Z/9ZvvQLhJtu9TY9n35?= =?Windows-1252?Q?1PAS099tuhe1WSJ+vn2RrXJ42ETPnF4vD2FfOkA16cnnetSMn1gRVpVf?= =?Windows-1252?Q?a/8RPgakcrz0Rt5ufc43gmd12vX8xThQSF0vbSQxRJADVduEscU9qcac?= =?Windows-1252?Q?ePbQ5BgAo89Gmogw86qdb3DCiKLRj+xx1TjqMwxxTwg5f+SLfqUb04Pd?= =?Windows-1252?Q?egYOA0dn7jZWOmVugdDk9RJ1FkRWVDY+ujpLJ4M4ySEu392QwetK8YSK?= =?Windows-1252?Q?ml61+4ayXXshtdowLBkplkO0Tlsv99gKcMMxMAYHXQI8eVofTryczPiE?= =?Windows-1252?Q?+YTmFeQuPhDBvMWQ2cBNaV9UyhdeFIPekSOGUTY6Y/n12CIAi/ibNMQ6?= =?Windows-1252?Q?/ik0MwtxeVSyBxWxG/1BNTfdSujpkuytKzjC5BrRtEa0IAxPlMe5Bjjo?= =?Windows-1252?Q?qGAhQwLsLRjThBt6ymD0IRXUnxdtKsH+rWvsJpZfCH/AtDTj4B+dlD/v?= =?Windows-1252?Q?5ojml+Ka6WUQOc4Hwj89tIsmNi4JFeRLOjrNJ48ffXee2X+u33tSdBC5?= =?Windows-1252?Q?cYa4ew=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY5PR10MB4179DDFA5662E13C15B25544C9969BY5PR10MB4179namp_" MIME-Version: 1.0 X-OriginatorOrg: pir.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4179.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 550b57f9-b7e0-4f54-fc1f-08da7096e9a9 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2022 12:44:29.3514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6c8ced78-b98f-4fa4-b6df-38beaa0d935d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OGCbtQ7FGZJyhxTW2+9AGTq97kpBFij7mCuBEqOcl91+CSgXfNiCLglNpjmnxUGhYHbnYl6L2SpqVOqiU4U8JA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1251 Archived-At: Subject: Re: [regext] Federated Authentication for Machine-to-Machine Interactions in RDAP X-BeenThere: regext@ietf.org 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: Thu, 28 Jul 2022 12:44:38 -0000 --_000_BY5PR10MB4179DDFA5662E13C15B25544C9969BY5PR10MB4179namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Scott, et al, Great question. One use case that comes to mind is working with law enforc= ement. In certain situations, authenticated access to RDAP data is require= d to override the default restrictions on disclosure. However, for operati= onal security reasons, the law enforcement agency (LEA) doesn=92t want indi= vidual query sources to be revealed. And so the LEA sends all if it=92s in= ternal queries through an internal source, like an internal web page that t= hen sends the queries on to the RDAP server. (In certain situations, there= may also be restrictions on the RDAP server logging those queries, but tha= t=92s a different issue.) I think that right now, this sort of arrangement could be handled by an IP = passlist. A rather blunt instrument to be sure, which can be challenging t= o implement in certain operational situations. There may be other solution= s that I either don=92t know or am not recalling. Offering this as a possible use-case. Not sure if it=92s worth adding to t= he draft. Thanks Rick From: regext on behalf of Hollenbeck, Scott Date: Wednesday, July 27, 2022 at 5:48 PM To: regext@ietf.org Subject: [EXTERNAL] [regext] Federated Authentication for Machine-to-Machin= e Interactions in RDAP CAUTION: This email came from outside your organization. Don?t trust emails= , links, or attachments from senders that seem suspicious or you are not ex= pecting. OAuth 2.0 includes the ability to authorize a class of clients known as "confidential clients" in a machine-to-machine manner using the "Client Credentials Grant". The grant is described here: https://datatracker.ietf.org/doc/html/rfc6749#section-4.4 A description of confidential and public clients can be found here: https://datatracker.ietf.org/doc/html/rfc6749#section-2.1 Note that this requires some sort of prior arrangement between the client a= nd, in our case, an RDAP server, such that the client can be authenticated by a= n Authorization Server without explicitly identifying, authenticating, and authorizing the specific human users who might be using the client. For example, the client might have a password that's been assigned by the RDAP server operator. The federated authentication draft doesn't currently inclu= de anything to support this type of grant. Should it? Is there an RDAP use cas= e for which this would be useful? Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext --_000_BY5PR10MB4179DDFA5662E13C15B25544C9969BY5PR10MB4179namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Scott, et al,<= /o:p>

 

Great question.&nbs= p; One use case that comes to mind is working with law enforcement.  I= n certain situations, authenticated access to RDAP data is required to over= ride the default restrictions on disclosure.  However, for operational security reasons, the law enforcement agency (LEA= ) doesn=92t want individual query sources to be revealed.  And so the = LEA sends all if it=92s internal queries through an internal source, like a= n internal web page that then sends the queries on to the RDAP server.  (In certain situations, there may also be res= trictions on the RDAP server logging those queries, but that=92s a differen= t issue.)

 

I think that right = now, this sort of arrangement could be handled by an IP passlist.  A r= ather blunt instrument to be sure, which can be challenging to implement in= certain operational situations.  There may be other solutions that I either don=92t know or am not recalling.

 

Offering this as a = possible use-case.  Not sure if it=92s worth adding to the draft.=

 

Thanks

Rick

 

 

From: regext <regext-b= ounces@ietf.org> on behalf of Hollenbeck, Scott <shollenbeck=3D40veri= sign.com@dmarc.ietf.org>
Date: Wednesday, July 27, 2022 at 5:48 PM
To: regext@ietf.org <regext@ietf.org>
Subject: [EXTERNAL] [regext] Federated Authentication for Machine-to= -Machine Interactions in RDAP

CAUTION: This email= came from outside your organization. Don?t trust emails, links, or attachm= ents from senders that seem suspicious or you are not expecting.

OAuth 2.0 includes the ability to authorize a class of clients known as "confidential clients" in a machine-to-machine manner using the &= quot;Client
Credentials Grant". The grant is described here:

https://datatracker.ietf.org/doc/html/rfc6749#sect= ion-4.4

A description of confidential and public clients can be found here:

https://datatracker.ietf.org/doc/html/rfc6749#sect= ion-2.1

Note that this requires some sort of prior arrangement between the client a= nd,
in our case, an RDAP server, such that the client can be authenticated by a= n
Authorization Server without explicitly identifying, authenticating, and authorizing the specific human users who might be using the client. For example, the client might have a password that's been assigned by the RDAP =
server operator. The federated authentication draft doesn't currently inclu= de
anything to support this type of grant. Should it? Is there an RDAP use cas= e
for which this would be useful?



Scott

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

--_000_BY5PR10MB4179DDFA5662E13C15B25544C9969BY5PR10MB4179namp_--