# DOSS Protocol for Data Caching and Sharing Security in a 5G Network
## 1 Introduction  
Fifth Generation mobile networks (5G) promise to push services to the edge; mobile subscribers will be able to access these with their User Equipment (UE) ubiquitously. After accessing services such as content data, the UE will be able to request other processes such as caching and sharing of the accessed data. 5G also promises to enable seamless connectivity, secure access to the network and services, security will be provided by authentication methods such as those specified in [1]. The initial security will be provided locally in the Home Network (HN) using primary authentication protocols to authenticate the UE to access the network [2, 3]. The next security stage will be provided by the HN and external data networks (DN) using a variety of security mechanisms that are interoperable in the HN and Service Providers (SP) network via DN function of the 5G architecture [1, 4, 5]. With 5G supporting numerous shareholders including end-users, Mobile Network Operators (MNO), and SPs, accessing and provisioning of services will require security mechanisms that protect the shareholders and the services [4]. There is also a need for permission delegation propagation and sharing between users to allow SPs to offer specific services beyond their security domain and still have some control over the accessed data by the user. Services will be provisioned at the edge, close to the user by multiple SPs from different security domains, hence being exposed to various security threats. Therefore, this will require unified, interoperable, robust, and multi-purpose security solutions such as federated authentication and authorization mechanisms [4]. The use of FederatedIdentity (FId) in multi-tenant network infrastructure with security procedures from trusted and semi-trusted third-parties can provide access to the right delegation, flexible security management, and precise tracking of critical UE data [2]. The MNO and SP will be able to transfer their security management to a third-party and allow permission delegation to end-users [6; 7]. As users in 5G will be able to cache and share data supported by Information-Centric Networking (ICN) [8; 9; 10] to improve access and caching, security measures should be in place to authorize what the end-users can do with the accessed data. This can be facilitated by service authorization mechanisms that apply access controls and encryption techniques that restrict the caching and sharing of data by the UE. The use of federated authorization procedures that use the use of a single digital Identity (ID) of a user in different domains' scenarios, MNOs will be able to provide security and seamless session continuity as users move from one network to another [7]. However, there is a lack of security mechanisms that can provide efficient data caching and sharing authorization in 5G. Therefore, we propose a Data Caching and Sharing Security (DCSS) protocol to provide service authorization to the UE for secure caching, sharing of data, and access rights delegation. To the best of our knowledge, no protocol in 5G provides data caching and sharing with permission delegation, facilitated using federated authorization, and no formal analysis on data caching and sharing security protocol. Our contributions in this paper are summarized as follows. We explore how federated identity, access controls, and permission delegation can be used to provide service authorization in 5G. We propose a DCSS protocol that enables the UE to cache and share data securely with access rights delegation in 5G. Furthermore, we use a formal method approach with ProVerif and applied pi-calculus to formally verify the proposed DCSS protocol. We also conduct a comprehensive security analysis on the protocol's security properties based on two taxonomies. The rest of the paper is structured as follows. The related work on data security in 5G is presented in Section 2. The problem definition and concepts on federated security, access controls, delegation are discussed in Section 3.