by Tigran Mkrtchyan, Deutsches Elektronen-Synchrotron DESY, June 2023.
By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than a "work in progress.
The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2023). All Rights Reserved.
Historically, for strong user authentication ONC RPC protocol protocol uses [RPCSEC_GCC][1], which is
typically based on Kerberos 5. The use of GSS-API provides data integrity, data privacy and user authentication.
Though the RPCSEC_GSS have proven it's maturity over the last two decades the other data access protocols, like
HTTPS, relay on a different technology, namely on [TLS][2], which is responsible for in-transit data protection,
and token based authentication, like OAuth2 (RFC 6749 & RFC 6750), OpenID Connect, which are responsible for
user authentication and authorization. Whitely adoption of HTTPS, TLS and token based access makes them attractive
by wide user communities, including large number of tools around them. For example, large scientific communities,
like Worldwide LHC Computing Grid (WLCG) adopts the OIDC technology for granting access to both CPU and storage resources,
as described in [WLCG Common JWT Profiles][4]. The command line tools make it possible to users to get OIDC tokens
without use of web browsers.
The OIDC token consist out three parts - ID Token, Access Token and signature. The IT Token (sub) indicates the individual or entity this token
was originally issued to. It's unique for a specific issuer (OpenID Provider). The Access Token based on the scope claim includes information about the authorization and rights the bearer is allowed to make use of. Example of such token:
{
"wlcg.ver": "1.0",
"aud": "<https://wlcg.cern.ch/jwt/v1/any>",
"sub": "0444f372-52e7-468d-aae4-911444898dbe",
"nbf": 1682515019,
"scope": "storage.create:/grid/jobsub/jobs storage.create:/home/users/foo compute.create compute.read compute.cancel compute.modify storage.read:/home/users/foo",
"iss": "<https://cilogon.org/>",
"exp": 1682525824,
"iat": 1682515024,
...
}Nevertheless, the OIDC based data access is only possible for protocols that support it - to HTTPS based access (and High Energy Physics specific Xroot data access procotol). This covers the data exchange between multiple research centres and universities, but insufficient for accessing data stored on network attached POSIX compliant storage systems, like NFS servers.
However, with [RPC-over-TLS][4] specification and OIDC token it is possible to provide an alternative solution to RPCSEC_GSS, without compromising the functionality, data privacy and strong authentication. Though OIDC still requires central authentication service, like kerberos, the token based authentication allows to integrate external Identity providers, like Github, to grant users access to local resources.
The way, how users obtains their tokens is outside of scope of this document.
- Make users barer token available to RPC request (by accessing a well defined file in /tmp directory?)
- Introduce a new RPC auth type, RPCSEC_BAERER_TOKEN. The opaque field contains base64 encoded token, just like in HTTP header.
- Server receives the requests, extracts the token, validates (and caches?).
- The
subclaim of the token used for user mapping, similar to kerberos+ldap. - Optionally, server might use access claims to give the access to storage resources.
The last option is useful in distributed environments to delegate data access management to remote authorities, like research principal investigators.
[1] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997. [2] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, https://www.rfc-editor.org/info/rfc5246.
[3] Myklebust, T., Lever, C. "Towards Remote Procedure Call Encryption by Default", RFC 9289, September 2022.
[4] Altunay, Mine, Bockelman, Brian, Ceccanti, Andrea, Cornwall, Linda, Crawford, Matt, Crooks, David, Dack, Thomas, et al. 2019. WLCG Common JWT Profiles (version 1.0). Zenodo. https://doi.org/10.5281/zenodo.3460258.