Zero Trust Federation: Sharing Context under User Control toward Zero Trust in Identity Federation
Authors:
Koudai Hatakeyama,
Daisuke Kotani,
Yasuo Okabe
Abstract:
To securely control access to systems, the concept of Zero Trust has been proposed. Access Control based on Zero Trust concept removes implicit trust and instead focuses on evaluating trustworthiness at every access request by using contexts. Contexts are information about the entity making an access request like the user and the device status. Consider the scenario of Zero Trust in an identity fe…
▽ More
To securely control access to systems, the concept of Zero Trust has been proposed. Access Control based on Zero Trust concept removes implicit trust and instead focuses on evaluating trustworthiness at every access request by using contexts. Contexts are information about the entity making an access request like the user and the device status. Consider the scenario of Zero Trust in an identity federation where the entity (Relying Party; RP) enforces access control based on Zero Trust concept. RPs should continuously evaluate trustworthiness by using collected contexts by themselves, but RPs where users rarely access cannot collect enough contexts on their own. Therefore, we propose a new federation called Zero Trust Federation (ZTF). In ZTF, contexts as well as identity are shared so that RPs can enforce access control based on Zero Trust concept. Federated contexts are managed by a new entity called Context Attribute Provider, which is independent of Identity Providers. We design a mechanism sharing contexts among entities in a ZTF by using the two protocols; context transport protocol based on Continuous Access Evaluation Protocol and user consent protocol based on User Managed Access. We implemented the ZTF prototype and evaluated the capability of ZTF in 4 use-cases.
△ Less
Submitted 22 September, 2022;
originally announced September 2022.
Key Management Based on Ownership of Multiple Authenticators in Public Key Authentication
Authors:
Koudai Hatakeyama,
Daisuke Kotani,
Yasuo Okabe
Abstract:
Public key authentication (PKA) has been deployed in various services to provide stronger authentication to users. In PKA, a user manages private keys on her devices called authenticators, and services bind the corresponding public keys to her account. To protect private keys, a user uses authenticators which never export private keys outside. On the other hand, a user regularly uses multiple auth…
▽ More
Public key authentication (PKA) has been deployed in various services to provide stronger authentication to users. In PKA, a user manages private keys on her devices called authenticators, and services bind the corresponding public keys to her account. To protect private keys, a user uses authenticators which never export private keys outside. On the other hand, a user regularly uses multiple authenticators like PCs and smartphones. She replaces some of her authenticators according to their lifecycle, such as purchasing new devices and losing devices. It is a burden for a user to register, update and revoke public keys in many services every time she registers new accounts with services and replaces some of her authenticators. To ease the burden, we propose a mechanism where users and services manage public keys based on the owner of authenticators and users can access services with PKA using any of their authenticators. We introduce a key pair called an Ownership Verification Key (OVK), which consists of the private key (OVSK) and the corresponding public key (OVPK). All authenticators owned by a user derive the same OVSK from the pre-shared secret called the seed. Services verify the ownership of the authenticators using the corresponding OVPK to determine whether binding the requested public key to her account. To protect user privacy while maintaining convenience, authenticators generate a different OVK for each service from the seed independently. We demonstrate the feasibility through the Proof of Concept implementation, show that our proposed mechanism achieves some security goals, and discuss how the mechanism mitigates threats not completely handled.
△ Less
Submitted 11 April, 2022;
originally announced April 2022.
