| Internet-Draft | RPCSEC_OIDC | March 2025 |
| Mkrtchyan | Expires 21 September 2025 | [Page] |
This draft considers the problem of using token-based authentication with network attached storage systems, in particular with NFS servers. This problem exist due to wide adoption of token based authentication for majority of services provided by private and public clouds. Due to lack of common security infrastructure between storage and other services, the end users forced either to completely disable authentication and rely on network isolation or introduce a custom, non standard and, probably, faulty, workarounds. This problem has become aggravated in recent years with high adoption of OpenID Connect technology to authenticate and delegate access to various could-based resources for large user communities.¶
Though, Remote Procedure Call (RPC) protocol, which is the underlying transport for NFS support multiple authentication mechanisms supports GSSAPI, that aims to address this issues, the lacks of integration with other cloud services makes it insufficient as a general purpose solution.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Network File System Version 4 Working Group mailing list (nfsv4@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/nfsv4/.¶
Source for this draft and an issue tracker can be found at https://github.com/kofemann/rpc-sec-oidc.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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 as "work in progress."¶
This Internet-Draft will expire on 21 September 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
For over two decades, Remote Procedure Call (RPC) is using Kerberos5 based GSS-API mechanism, called RPCSEC_GSS, to provide in-transit data integrity, privacy and user authentication. With the introduction of RPC-over-TLS the GSS-API is not required any more for data integrity and privacy, however, to ensure user identity in a shared environment, like public and private clouds, the Kerberos principles are still needed.¶
Though the RPCSEC_GSS has proven its maturity the other data access protocols, like HTTPS, rely on a different technology, namely, TLS, which is responsible for in-transit data protection, and bearer tokens, like OAuth2 (RFC 6749 & RFC 6750), OpenID Connect, which is responsible for user authentication and authorization. The adoption of those technologies for RPC protocol will provide direct NFS access to storage servers from token-enabed CPU clusters.¶
The token-based access is rapidly enters into many online services, from simply reading e-mails to starting complex applications in large scientific environments. Moreover, one of the benefits of token-based access is a possibility to delegate authorization decisions to identity provides that are not required to run locally at the sites, thus allows a decentralized access control in a distributed environments. This makes token-based authentication and authorization very attractive to large multisite users communities, like scientist at Large Hadron Collider (LHC) or Square Kilometer Array(SKA) telescope, who typically need to be authorized by their home institutions but get an access to shared resources available at other universities or private/public clouds.¶
Since 2017 the computing specialists at Worldwide LHC Computing Grid (WLCG) has been working towards enabling token based authentication and authorization throughout its entire middleware stack, including storage access through HTTPs protocol, which is used for date exchange between laboratories. However, those efforts doesn't cover data access from CPU clusters to locally available storage services. One on the reasons is the lack of standard access protocols that provide token-based access to storage.¶
OIDC: OpenID Connect, or OIDC, is an authentication protocol built on top of the OAuth 2.0 framework. It provides a standardized way for users to authenticate and authorize themselves to access web applications or APIs.¶
Identity Provider (IdP): The IdP is responsible for authenticating users and issuing identity tokens. Examples of popular IdPs include Google, GitHub, and Keykloak.¶
Identity Token: The identity token is a JSON Web Token (JWT) issued by the IdP. It contains claims about the user's identity, such as their username, email address, and any additional requested information.¶
Access Token: In the context of OIDC, an access token is a security token issued by the identity provider (IdP) after successful authentication and authorization. It represents the user's authorization to access protected resources. The access token is a bearer token, meaning it contains the necessary information to access resources and can be presented directly to the resource server.¶
Resource Server: The resource server is responsible for enforcing access control and verifying the validity and authorization of access tokens presented by clients. It holds the protected resources, such as user data, APIs, or any other restricted information.¶
By combining OIDC with OAuth 2.0, the access token obtained through OIDC can be used to provide both authentication (verifying the user's identity) and authorization (granting access to resources) in a secure and standardized manner.¶
The Identity Token (rfc7519), similar to kerberos principals, carries sufficient information to uniquely identify user, for example, token:¶
json
{
"sub": "2ea41db8-ecd7-47a1-8f86-7ac97ebcc466",
"aud": "https://example.domain/any",
"nbf": 1662472763,
"iss": "https://idp.example.domain/",
"exp": 1662476363,
"iat": 1662472763,
"jti": "88a1f764-8311-4210-a8cd-d5604b942d8c",
}
¶
describes the issuer (iss), issue-wide unique user identity (sub), audience (aud) to the token and the validity time window (nbf, exp).¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶