Openid Connect Based Authentication for Host Remote Access

Masaryk University Faculty of Informatics

OpenID Connect Based Authentication for Host Remote Access

Master’s Thesis

Bc. Ondřej Velíšek

Brno, Fall 2018

Masaryk University Faculty of Informatics

OpenID Connect Based Authentication for Host Remote Access

Master’s Thesis

Bc. Ondřej Velíšek

Brno, Fall 2018

This is where a copy of the official signed thesis assignment and a copy ofthe Statement of an Author is located in the printed version of the document.

Declaration

Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Bc. Ondřej Velíšek

Advisor: RNDr. Michal Procházka, Ph.D.

Acknowledgements

I would first like to thank my thesis advisor RNDr. Michal Procházka, Ph.D. for his leadership, provided motivation and steering me in the right direction whenever he thought I needed it. Thank you. I would also like to thank the colleagues and backers who supported me. Namely, Anna Schneiderová, Ing. Jaroslav Rozman, Ph.D., Klára Ajašová, Kryštof Michal and Milan Kramárik. I am gratefully indebted to them for their valuable comments on this thesis. Finally, I must express my very profound gratitude to my par- ents for providing me with unfailing support and continuous encour- agement throughout my years of study and through the process of researching and writing this thesis.

iii Abstract

This thesis proposes three authentication architecture designs using OpenID Connect identity provider in a distributed environment. It focuses on the secure authorization delegation use-case which is demon- strated on the SSH protocol. Each of the architecture designs is evaluated regarding security, interoperability, easy adoption and usability and compared with existing authentication methods. Prototypes of each architecture were implemented and tested to verify theoretic statements and feasibility of the proposed designs.

iv Keywords

OpenID Connect, OAuth 2.0, authentication, authorization, delegation, remote access, ssh, secure shell

Contents

Introduction 1 Research Objectives ...... 1 Text Structure ...... 2

1 OAuth 2.0 Framework 3 1.1 OAuth 2.0 ...... 3 1.1.1 Authorization Code Flow ...... 4 1.1.2 Device Code Flow ...... 6 1.1.3 Best Current Practice for Native Apps ...... 7 1.1.4 Client Identification ...... 9 1.1.5 Dynamic Client Registration ...... 9 1.2 OpenID Connect 1.0 ...... 10

2 Secure Shell 11 2.1 Pluggable Authentication Interfaces ...... 11 2.1.1 Keyboard Interactive ...... 11 2.1.2 Generic Security Services API ...... 12 2.2 SSH Agent ...... 14 2.2.1 Agent Forwarding ...... 15

3 Definition of Model Environment 17 3.1 Administrative Units ...... 17 3.2 Hardware Components ...... 17 3.3 Software Components ...... 18 3.4 Components Responsibility ...... 19

4 Existing Authentication Methods 21 4.1 Resource owner password flow ...... 21 4.2 Copy-paste method ...... 21 4.3 OIDC Agent ...... 22 4.4 Kerberos ...... 22 4.5 Cyclone PAM ...... 24 4.6 Guardian Agent ...... 25 4.7 Conclusion ...... 26

5 Authorization Code Agent Extension 27

vii 5.1 Motivation ...... 27 5.2 Environment Setup ...... 28 5.3 Authorization Process ...... 29 5.4 Prototype Implementation ...... 30 5.5 Easy Adoption and Interoperability Consideration ...... 30 5.6 Security Consideration ...... 31 5.6.1 Access Gained by Intermediate Client ...... 31 5.6.2 Centralized Credentials in Agent ...... 32 5.7 Usability Consideration ...... 32 5.7.1 Initial Setup ...... 32 5.7.2 Authorization Process ...... 33 5.8 Conclusion ...... 33

6 Authentication Architecture Proposals 35 6.1 OAuth2 GSS-API mechanism ...... 35 6.1.1 Environment Setup ...... 35 6.1.2 Authentication Process ...... 36 6.1.3 Separated Resource Server Modification . . . . . 38 6.1.4 Prototype Implementation ...... 40 6.1.5 Easy Adoption and Interoperability Consideration 40 6.2 OIDC GSS-API mechanism ...... 41 6.2.1 Environment Setup ...... 41 6.2.2 Authentication Process ...... 42 6.2.3 Prototype Implementation ...... 44 6.2.4 Easy Adoption and Interoperability Consideration 44 6.3 Device Code PAM ...... 44 6.3.1 Environment Setup ...... 45 6.3.2 Authentication Process ...... 46 6.3.3 Prototype Implementation ...... 47 6.3.4 Easy Adoption and Interoperability Consideration 48

7 Quality Attribute Comparison 49 7.1 Security Consideration ...... 49 7.1.1 Access Gained by Intermediate Client ...... 49 7.1.2 Access Gained by Remote Server ...... 51 7.1.3 Conclusion ...... 53 7.2 Usability Consideration ...... 53 7.2.1 Initial Setup ...... 54 viii 7.2.2 Authentication Process ...... 55 7.2.3 Conclusion ...... 58

8 Conclusion 59 8.1 Research Contributions ...... 59 8.2 Future Work ...... 60

Bibliography 61

A Content of Attached Archive 67

B Authentication Process Illustration 69 B.1 OAuth2 GSS-API Mechanism ...... 69 B.2 OIDC GSS-API Mechanism ...... 72 B.3 Device Code PAM ...... 75

List of Figures

1.1 Sequence diagram of OAuth2 abstract flow 4 1.2 Sequence diagram of OAuth2 authorization code flow 5 1.3 Sequence diagram of OAuth2 device code flow 6 1.4 Sequence diagram of authorization code flow for native apps 8 2.1 Sequence diagram of PAM authentication method in SSH context 12 2.2 Sequence diagram of simplified GSS-API authentication method in SSH context 13 2.3 Sequence diagram of SSH agent protocol 14 2.4 Component diagram of SSH agent forwarding 15 3.1 Deployment diagram of model architecture 18 3.2 Diagram illustrating relation between OAuth2 roles and software components of model architecture 19 4.1 Sequence diagram of simplified Kerberos authentication process in SSH environment 23 4.2 Sequence diagram of Cyclone PAM authentication process 24 4.3 Sequence diagram of simplified SSH authentication process with Guardian agent 25 5.1 Deployment diagram of OAuth2 agent in model environment 28 5.2 Sequence diagram of OAuth2 agent authorization process 29 6.1 Deployment diagram of OAuth2 GSS-API mechanism in model environment 36 6.2 Sequence diagram of authentication process with OAuth2 GSS-API mechanism 37 6.3 Sequence diagram of authentication process with OAuth2 GSS-API mechanism with separated resource server modification 39 6.4 Deployment diagram of OpenID Connect GSS-API mechanism in model environment 42

xi 6.5 Sequence diagram of authentication process with OpenID Connect GSS-API mechanism 43 6.6 Deployment diagram of Device code PAM in model environment 45 6.7 Sequence diagram of authorization process with Device code PAM 46 B.1 Initial state in authentication process with OAuth2 GSS-API mechanism 69 B.2 IdP selection in authentication process with OAuth2 GSS-API mechanism 70 B.3 Authentication to Google in authentication process with OAuth2 GSS-API mechanism 70 B.4 Consent screen in authentication process with OAuth2 GSS-API mechanism 71 B.5 Successful access to remote machine in authentication process with OAuth2 GSS-API mechanism 71 B.6 Initial state in authentication process with OIDC GSS-API mechanism 72 B.7 IdP selection in authentication process with OIDC GSS-API mechanism 73 B.8 Authentication to Google in authentication process with OIDC GSS-API mechanism 73 B.9 Authorization consent in authentication process with OIDC GSS-API mechanism 74 B.10 Successful access to remote machine in authentication process with OIDC GSS-API mechanism 74 B.11 Initial state in authentication process with Device code PAM 75 B.12 Verification prompt in authentication process with Device code PAM 76 B.13 IdP selection in authentication process with Device code PAM 76 B.14 Authentication to Google state in authentication process with Device code PAM 77 B.15 Authorization consent in authentication process with Device code PAM 77 xii B.16 Successful client authorization in authentication process with Device code PAM 78 B.17 Successful access to remote machine in authentication process with Device code PAM 78

xiii

Introduction

The Internet has become a standard way how users consume services nowadays. There are many service providers, and users often consume multiple services across various of them. Since many of them were developed independently, they use their own identity management systems. It became a usability and security issue because users had to manage credentials for each provider. Therefore centralized identity providers with a single sign-on1 mechanism were used to mitigate this issue [1]. One of the provided services is a cloud computing [2, 3] which enables a user to instantiate virtual machines and access other services from them. It becomes a challenge to provide a single sign-on mechanism in such a distributed environment [4]. For example, he/she wants to access storage supplied by one provider from the virtual machine provided by the second one. In this case, the intermediate machine and therefore the cloud infrastructure receives credentials authorizing it to access the final service. Depending on the credential it might be a security issue [5]. I refer to this use-case further as an authorization delegation use-case. Some of the existing authentication methods used in a cloud environment have already satisfied this use-case. As an example, consider Kerberos [6] and SSH public key method [7]. However, they have some disadvantages regarding security [8, 9]. Moreover, many service con- sumers are not IT experts nowadays, and introduced methods require non-trivial configuration which is considerably inconvenient.

Research Objectives

One way to achieve single sign-on is to use an OpenID Connect protocol. The essential goal of this research is to design an authentication architecture of distributed environment which satisfies the delegation use-case using OpenID Connect. Moreover, the design should be interoperable and easily adoptable by cloud infrastructures.

1. Ability for a user to authenticate once to a single authentication authority and then access other protected resources without re-authenticating

1 The additional goal is to discuss security and usability quality attributes of the proposed design and compare them with existing authentication methods. The final goal is to verify theoretical results and test feasibility ofthe proposed authentication architecture by a prototype implementation. The implementation is not meant for production, and the thesis is not intended to find a definitive solution but rather to present possible options and produce material for discussion in a related community.

Text Structure

The text is structured into eight parts. The first two give an overview of technologies which are used for proposed designs. The third chapter defines a model environment which is used to help present authentication architectures and evaluate them. The next part reviews existing authentication methods which are used in a cloud environment. The fifth chapter proposes a tool which is used to achieve delegation by actual architecture designs described in the next chapter. The seventh one focuses on an evaluation of proposals regarding security and usability and compares them with existing methods. The last part summarizes and concludes the outcomes.

2 1 OAuth 2.0 Framework

Proposed authentication architectures are based on the OpenID Con- nect 1.0 protocol, which is a simple identity layer on top of the OAuth 2.0 protocol [10, 11]. Further referred to as OIDC and OAuth2. In the following text, I expect the knowledge of both protocols. I describe them briefly and use unmentioned simplifications. The full definition of the protocols can be found in the specification where I considerably draw further presented information. Note that OAuth 1.0 and OpenID 1.0, 1.1 and 2.0 are non-compatible predecessors of presented protocols and this thesis is not related to them.

1.1 OAuth 2.0

OAuth2 enables an application to obtain limited access to a service on behalf of a user. Therefore, it enables the user to delegate access to the application securely. OAuth2 defines four roles.

Resource owner is an entity which mentally owns a protected resource and, therefore, is capable of granting access to it. In our case, it is always an end-user and therefore, I refer to it so.

Resource server is a server hosting protected resources capable of responding to a resource access request.

OAuth2 client is an application making resource access request on behalf of the end-user with his/her authorization.

Authorization server is a server capable of authenticating the end- user and managing authorizations granted to OAuth2 clients.

The OAuth2 defines several flows that can be used to delegate access to a user’s protected resource however the flows follow a common abstract framework. The figure 1.1 shows a sequence diagram of OAuth2 abstract flow. First, an OAuth2 client requests access tothe protected resource and user grants consent to the client. Next, the OAuth2 client obtains an access token from an authorization server based on the authorization it obtained in the previous step. The access

3 1. OAuth 2.0 Framework

Authorization Resource OAuth2 client User server server

1. Authorization req.

2. authorization grant 3. Token request

4. access token 5. Resource request

6. resource

Figure 1.1: Sequence diagram of OAuth2 abstract flow token is time, and scope limited opaque credential which enables the client to access the protected resource. Finally, the OAuth2 client sends the resource access request together with the obtained access token. Note that clients must be registered beforehand with the authorization server. The OAuth2 defines two types of clients, public and confidential. Public clients are those not capable of keeping client credentials a secret. A consequence is that the authorization server cannot authenticate the public client and therefore typically show authorization consent screen each time a client requests an authorization.

1.1.1 Authorization Code Flow

One of the flows I use in the following designs is the authorization code flow. Figure 1.2 shows a sequence diagram of the communication between OAuth2 roles.

1-2. Client accesses a browser instance and sends a request to the authorization server. The request includes, among other things, client id, redirection URI and scope.

4 1. OAuth 2.0 Framework

Authorization User OAuth2 client Browser server

1. Code request 2. Code request

4. Authentication 3. Authentication

6. Consent prompt 5. Consent prompt

8. code 7. code

9. Token request

Figure 1.2: Sequence diagram of OAuth2 authorization code flow

3-4. Authorization server authenticates the user via any web available protocol. For example via Basic authentication, X.509 cer- tificate [12], YubiKey [13] or SAML2 [14]

5-6. Authorization server asks a user for a consent to authorize the client to access a protected resource within the provided scope.

7-8. Authorization server generates a short-lived, one-time code which represents granted authorization and redirects browser to the provided redirection URI. The client catches the request and extracts the code from it.

9. Client sends a token request to the authorization server. The request includes, among other things, obtained code, client ID and client credentials in case of the confidential client. The server validates the code, possibly authenticates the client, issues access token and sends it back to the client.

Note that the client needs to be able to access the browser during this flow. In the following text, I refer to steps 3-6 as an authorization dialogue and the information necessary to complete the flow as OAuth2 configuration.

5 1. OAuth 2.0 Framework

Authorization OAuth2 client Browser User server

1. Device request 2. Verification prompt 3. Token request 5. Verification request 4. Open verification URL 6. Authentication 7. Authentication 8. Code prompt 9. Code prompt 10. Consent prompt 11. Consent prompt 12. verified 13. verified 14. Token request

Figure 1.3: Sequence diagram of OAuth2 device code flow

1.1.2 Device Code Flow The second flow I use in the following designs is device code flow.At the time of the publication of this thesis, the device code flow is not standardized. Therefore I follow the existing internet draft [15]. Even though the flow is supported by some implementations1, an interoperability impact should be considered. Figure 1.3 shows a sequence diagram of the device code flow.

1. Client sends a device request to the authorization server. It includes, among other things, client ID and scope. The server issues a user code and a device code and sends them back to the client together with the verification URI.

2. Client provides the user code to the user and instructs him/her to open given verification URI in his browser.

3. Client starts to poll authorization server token endpoint with given device code.

4-5. User opens a browser at provided verification URI.

1. Google, Microsoft, ELIXIR, MitreID Connect

6 1. OAuth 2.0 Framework

6-7. Authorization server authenticates the user. Note this step is identical to the step 3-4 described in authorization flow.

8-9. Authorization server prompts the user for the user code.

10-11. Authorization server asks the user for a consent to authorize the client. Note this step is identical to the step 5-6 described in authorization flow.

12-13. Authorization server instructs the user to close the browser and return to the client application.

14. Client polls authorization server token endpoint. The server checks the device code validity and authorization of the as- sociated client. The server responses with a successful token response because the user has authorized the client.

In the following text, I refer to steps 5-13 as a verification dialogue. An important feature of this flow is that the client does not need to have access to the browser. However, the user has to open it manually. Therefore a usability impact should be considered.

1.1.3 Best Current Practice for Native Apps The following architecture proposals are aimed for Linux native applications. For native applications, it is recommended to use authorization code flow with the user’s default browser as the best current practice (BCP) [16]. The BCP presents three possible methods of catching authorization code response redirection by native applications. I chose the loopback interface, mainly because Google advices it for Linux OS2. Figure 1.4 shows a sequence diagram of authorization code flow for native apps using a loopback interface for catching code response redirection.

1. Client runs a local web server on available arbitrary chosen port.

2. https://developers.google.com/identity/protocols/ OAuth2InstalledApp

7 1. OAuth 2.0 Framework

Authorization OAuth2 client Browser server

1. Run ser. Web server

2. Code request 3. Auth. dialog 5. code 4. code

6. Token request

Figure 1.4: Sequence diagram of authorization code flow for native apps

2. Client opens a browser on an authorization request URL with redirection URI set to loopback address with web server port. The opening of a browser page is done in a platform-specific way. On Linux OS it might be via xdg-open3 command.

3-4. Authorization server performs a regular authorization dialogue and redirects browser to the provided loopback address.

5. Web server catches a redirection, extracts a code and provides it to the client.

6. Client makes a standard token request with obtained code.

BCP for native apps force OAuth2 public clients to use PKCE4 protocol [17]. It is a protocol which ensures only the entity who requests for an authorization code will be able to exchange it for an access token. It is especially useful when OAuth2 public client uses an intermediate entity to request authorization code.

3. https://portland.freedesktop.org/doc/xdg-open.html 4. Proof Key for Code Exchange

8 1. OAuth 2.0 Framework

1.1.4 Client Identification

Authorization server enables a user to grant authorization to the clients by agreeing of authorization consent. The consent typically informs the user that given client requests access to the given scope of resources. The client is typically presented to the user with a client name and a logo. I refer to those attributes as client identification. It is important that the user correctly interprets the client identity. It is especially important with native applications. A native application is considered as a public client since any secret included in a client’s executable code can be reverse-engineered. Therefore malicious installed application can identify itself as any native legal client. It might be a security issue.

1.1.5 Dynamic Client Registration

Dynamic client registration is a mechanism to register clients with authorization server without human interaction [18, 19]. It is especially useful in the case of native applications. With dynamic registration, the client credentials are generated by an authorization server so the application can register a client upon installation and therefore the credentials are not included in the executable. However, as discussed in the previous section, it might be a security issue to allow to register an arbitrary name. To mitigate this issue the specification defines possibilities to restrict access to dynamic registration endpoint. One of them is a software statement. It is an assertion issued and signed by the authorization server which contains clients metadata such as name and redirection URI. If the authorization server supports it, only clients with specified metadata can be dynamically registered. Therefore the application will not be able to register an arbitrary client name. Moreover, it can restrict redirection URI, which restricts the client location. In the case of native application, a loopback URI restricts localhost location. Another advantage of dynamic client registration is the fact that each program instance is authorized separately and therefore machine identification can be included in the client’s name. It helps a userto

9 1. OAuth 2.0 Framework distinguish clients and in case of an incident makes each instance revocable separately.

1.2 OpenID Connect 1.0

OIDC is a protocol which enables an application to verify the identity of the user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the user [10]. The application represents OAuth2 client, and an authorization server serves as an identity provider (IdP). OIDC specifies OAuth2 scopes regarding profile information. In the following text, I use openid scope, which authorizes the client to access user’s ID. The ID can be fetched from provided userinfo resource server endpoint or placed in an ID token. An ID token is a signed JWT token [20, 21] containing, among other things, an ID of IdP, client and a user. It is signed by the authorization server and therefore serves as an identity assertion for the client. Since application authenticates a user, it often provides access to some resources. Even though the OIDC is based on OAuth2, those resources may be unrelated to OAuth2 protected resources, and the application often provides its way to authorize a user to access those resources based on authentication provided by OIDC. It is because some IdPs do not allow to register a custom resource server.

10 2 Secure Shell

The machine access is presented on an example of Secure shell protocol (SSH) since it is a common way to access Linux remote machines in cloud infrastructures. It is a protocol for secure network services over an insecure network [22, 23, 24]. It is based on a client-server architecture. To distinguish OAuth2 and SSH terms, I use OAuth2 and SSH prefixes, respectively. Note that I expect basic knowledge ofthe protocol, especially of the authentication protocol architecture [7].

2.1 Pluggable Authentication Interfaces

The SSH server needs to authenticate the user to make an authorization decision. Several standardized authentication methods exist. I focus on keyboard-interactive and Generic Security Services API (GSS-API) authentication methods because they are general pluggable interfaces and its implementation can be reused by any compliant software. Moreover, they are supported by OpenSSH and Dropbear SSH server implementations which are widely used over the internet [25]. The following architecture proposals make use of them since it fits the defined goal of easily adoptable and interoperable design. Note thatI completely omit the public key authentication method and expect its concept knowledge entirely.

2.1.1 Keyboard Interactive The keyboard-interactive authentication method is a general authentication method that does not need any special software support on the client side [26]. The common way to use this method on Linux OS is via pluggable authentication modules (PAM) [27] and therefore I refer to this method as PAM. Figure 2.1 shows sequence diagram of PAM authentication process in SSH context.

1. SSH client sends an authentication request to SSH server indicating usage of a PAM method together with the desired account name.

11 2. Secure Shell

Local machine Remote machine

User SSH client SSH server PAM

1. Authentication req. 2. Auth. PAM req.

5. Message/Prompt 4. Message/Prompt 3. Message/Prompt

7. authenticated 6. authenticated

Figure 2.1: Sequence diagram of PAM authentication method in SSH context

2. SSH server runs configured PAM authentication routine and passes the provided account name to it.

3-5. PAM authenticates the user. It can use either provided SSH channel to interactively communicate with the user or any other channel such as the Internet.

6. PAM returns a successful response to the SSH server, and the server informs the SSH client.

2.1.2 Generic Security Services API

GSS-API is a general interface which, among other services, allows a caller to authenticate a user [28]. The essential difference with PAM is that extra software is installed and configured at the local machine. Concluded, it is a more flexible option. However, the usability impact should be considered. Figure 2.2 shows sequence diagram of GSS-API authentication process in SSH context. For brevity and to distinguish components I refer GSS-API mechanism on the local machine as a GSS client and GSS-API mechanism on the remote machine as GSS server even though client-server naming might be misleading in particular contexts. Note the presented process is considerably simplified.

12 2. Secure Shell

Local machine Remote machine

GSS client SSH client SSH server GSS server

1. Authentication req. 3. Initialization req. 2. mechanism 4. Initialization 5. Initialization 6. Initialization 8. authenticated 7. initialized

Figure 2.2: Sequence diagram of simplified GSS-API authentication method in SSH context

1. SSH client sends an authentication request to SSH server indicating usage of GSS-API method together with the desired account name and list of supported GSS-API mechanisms.

2. SSH server choose a supported mechanism and sends the choice back to the user.

3. SSH client calls context initialization routine of GSS client.

4-6. GSS client starts initialization of security context. It communicates with the GSS server via provided SSH channel. GSS mechanism authenticates the user during the initialization.

7-8. When a security context is established GSS server provides the initialized context to the SSH server. The SSH server checks if the user is authorized based on the context and informs the SSH client.

I refer to steps 1-2 as a mechanism negotiation. Also note that the SSH server must understand the security context. SSH server implementation must be aware of mechanism implementation because the context shape depends on a particular mechanism [29]. In the following text, I assume such functionality is provided, however, potential fluent adoption issues should be considered.

13 2. Secure Shell

Local machine

User SSH client SSH agent

1. Signature challenge 2. Passphrase prompt 3. Decrypts private key Signs challenge 4. signed response

Figure 2.3: Sequence diagram of SSH agent protocol

2.2 SSH Agent

The SSH agent is a service that holds SSH private keys and provides cryptographic operations. The specification draft has expired [30] despite that, OpenSSH, Putty, and Dropbear SSH client implementations follow this document. Therefore I use it as a reference. This section describes the protocol briefly and focuses on forwarding mechanism since it is used later. The agent is typically a daemonized process with user privileges and is run at the beginning of an X-session or login session. When run it opens a socket and sets its address into environment variable SSH_AUTH_SOCK. Then it is daemonized. Note the environment variable is provided to all processes in the session so any process can access it. Figure 2.3 shows a sequence diagram of SSH agent protocol. Note the sequence begins after the SSH server sends a signature challenge to the client.

1. SSH client checks if SSH_AUTH_SOCK variable is provided. If so, it sends a request to the SSH agent including signature challenge obtained from the server. 2. Since private keys are typically encrypted the agent prompts a user for a passphrase. Alternatively, the agent might retrieve a decrypted private key from memory on repeated requests. 3. SSH agent decrypts the private key and signs obtained challenge.

14 2. Secure Shell

Remote machine Local machine

SSH client SSH server SSH client SSH agent socket socket

Figure 2.4: Component diagram of SSH agent forwarding

4. SSH agent sends a response back to the SSH client, including the signed challenge.

Note the described process is used with the public key authentication method. However, the specification draft defines an extension mechanism so a custom request can be served by the agent. Despite the name, the agent is not dependent on SSH and can be used by an arbitrary process.

2.2.1 Agent Forwarding Agent forwarding is a mechanism which enables processes on a remote machine to communicate with the local session agent [31]. Figure 2.4 shows component diagram of a forwarded agent. When a connection between SSH client and server is established, a new logical channel is created for the agent communication. The SSH server opens a socket at a remote machine and sets the address as a SSH_AUTH_SOCK environment variable. Then it opens a remote session so all the session processes can access the socket. SSH server redirects all its communication to the SSH client, and the client redirects it to the local agent socket. Concluded, a secure tunnel is established (yellow color), and the communication appears transparent for the remote processes. It is important to point out that any remote session process has access to the agent and therefore can access all the resources protected by the public key authentication method. Therefore typically SSH implementations require a user’s explicit consent to forward the agent — for example, an extra command option. Semantically it means that the user expresses his/her trusts to the remote session.

3 Definition of Model Environment

This chapter defines a simplified model environment which is used to unify terminology, more understandable description and for evaluation of architecture proposals. I describe hardware and software components with its administrative units together with relations between them. I define several assumptions for simplification purposes. Still, the later architecture designs apply to a wide range of real environments. Deployment diagram in figure 3.1 shows the assumed environment architecture. There are three types of entities present in the diagram. Software components are drawn with a solid line, hardware components (even virtual) with a dashed line and administrative units with a dotted line.

3.1 Administrative Units

There are two cloud infrastructures: one situated in the Czech Republic and one in Spain. Both of the infrastructures trust one Identity Provider. The user, Alice, trusts both infrastructures and Identity Provider but in general, do not trust other infrastructure users such as Mallory. I assume that Alice and Mallory have registered an account at the Identity Provider. It is important to consider if IdP allows infrastructures to register OAuth2 resource server with custom scopes and let them introspect access tokens. Following text does not assume such trust relationship unless explicitly said otherwise.

3.2 Hardware Components

Alice owns a local machine (e.g., laptop) and has instantiated one virtual machine in Czech Infrastructure and one storage in Spanish infrastructure. Mallory instantiated one virtual machine in Czech infrastructure.

17 3. Definition of Model Environment

Czech infrastructure

Spanish infrastructure Malicious mach.

SSH server Storage machine Mallory SSH server Identity provider

IdP machine Local machine Virtual machine Storage Authorization Browser SSH server server Alice SSH client SSH client Userinfo server

Figure 3.1: Deployment diagram of model architecture

All machines run Linux-based OS. Despite that, designs do not use any Linux exclusive features, and therefore all designs apply to other distributions and OS if not stated otherwise. In the environment, I distinguish two types of remote machines provided by cloud infrastructure. The former, machine with restricted access means that cloud infrastructure can store a secret on the machine without exposing it to user and user is unable to modify access uncontrollably. The reference example of such machine is a storage machine. The latter, machine with unrestricted access applies in all other cases. A reference example is a virtual machine where cloud infrastructure provides full superuser access to end-user. I refer to both of them as remote machines.

3.3 Software Components

Each of the infrastructures manages a cloud platform software (e.g., OpenNebula or OpenStack) which provides an ability to manage virtual and storage machines. I assume that cloud infrastructure can run arbitrary contextualization scripts after machine deployment. Both types of machines are accessible by SSH. A file system on storage machines can be mounted with SSHFS [32]. Still, the later designs

18 3. Definition of Model Environment

OIDC responsibility structure OAuth2 responsibility structure

OAuth2 client Authorization server Resource server Authorization server Authorization Authorization SSH server SSH server server server

Resource server OAuth2 client

Userinfo Userinfo SSH client SSH client server server

Figure 3.2: Diagram illustrating relation between OAuth2 roles and software components of model architecture

could be applied to other protocols. Note the SSH server runs with superuser privileges. IdP provides OAuth 2.0 and OpenID Connect standard endpoints at authorization and userinfo servers. The authorization server can keep a web session with a user’s browser, so a user does not have to re-authenticate when accessing the server repeatedly with the same browser. Note it is a common practice to do so. Local machine has installed an SSH client and a default browser. The machine is potentially multi-user, and the SSH client is executed with Alice’s privileges. I assume that Alice trusts a local machine. It especially includes all session processes, including SSH client, browser and OS. The malicious virtual machine has installed an SSH server which can be arbitrarily modified by Mallory.

3.4 Components Responsibility

I use two different approaches on how to assign OAuth2 roles to defined software components. Further referred as OIDC responsibility and OAuth2 responsibility structure. Later authentication architecture designs are based on them. Figure 3.2 illustrates those responsibility structures.

19 3. Definition of Model Environment

OIDC responsibility structure Former assumes that the SSH server needs to authenticate a user to access a remote session. Therefore the server represents an OAuth2 client which requests access to the user information such as user id and authorizes the user based on it. Note that this conforms an OpenID Connect protocol.

OAuth2 responsibility structure Latter assumes the SSH server provides protected resources — namely access to virtual machine or storage. Therefore it represents a resource server which accepts access tokens from OAuth2 clients. One of such clients is an SSH client. Note that it conforms an OAuth2 protocol. Also note that this requires that IdP allows infrastructures to register an OAuth2 resource server. Therefore, when referencing this responsibility structure, I assume previously discussed trust relationship between IdP and cloud infrastructure.

Note that both structures are suitable for delegation use-case. How- ever, have different quality attributes. Since the attributes depend on a specific design, I discuss them individually later.

20 4 Existing Authentication Methods

This chapter presents some of the existing authentication methods used to access remote machines. I describe them briefly with a focus on single sign-on and authorization delegation use-case. A subset of them is chosen to be compared with later proposed architecture designs.

4.1 Resource owner password flow

OAuth2 standardizes a flow which enables to get access token with username and password. OAuth2 client sends requests to token endpoint including the password and authorization server validates it. PAM implementation of such flow exists1 and therefore can be used by SSH. However, it does not provide a secure delegation method because password-based authentication has considerable security disadvantages [33]. Therefore I do not include it in comparison.

4.2 Copy-paste method

One option to delegate access is to let a user manually copy the access token with a clipboard and manually paste it to the SSH client. In such case, the token must be presented to the user. It can be done either by an authorization server with special option2 or by a third-party public web server which catches redirection and prints it. Several PAM implementation exists 3,4 which might be used by SSH. Since it is neither a standard nor well-usable option, I do not include it in comparison.

1. https://github.com/shimt/pam-exec-oauth2 2. Google provides redirection URI value urn:ietf:wg:oauth:2.0:oob 3. pam-oauth2, https://github.com/CyberDem0n/pam-oauth2 4. pamoidc-python, https://bitbucket.org/PEOFIAMP/pamoidc-python/

21 4. Existing Authentication Methods 4.3 OIDC Agent

OIDC agent is a tool to manage OAuth2 configuration and tokens and make them available from the command line [34]. It allows a user to add an OAuth2 configuration and let applications which are aware of OIDC agent to obtain an access token. However, it does not support SSH without further modification. Therefore SSH client is not able to obtain the access tokens and the agent can’t be forwarded to the remote session. Still, the delegation might be achieved by installing the agent on the remote machine and use a device code flow. I propose a similar concept which might be used in SSH context later in section 6.3 and therefore will not include this design to the comparison.

4.4 Kerberos

Kerberos is a distributed single sign-on authentication service that allows a client, running on behalf of a user, to securely prove its identity to a server [6, 35]. Single sign-on is achieved by a central identity provider, Key distribution center (KDC). I refer to services protected by Kerberos as kerberized. Figure 4.1 shows a sequence diagram of simplified authentication process.

1. User executes program Kinit to initialize Kerberos authentication.

2. Kinit prompts a user for a password.

3. Kinit exchanges password for a ticket-granting ticket (TGT). It is a time-limited credential used to obtain service tickets.

4. Kinit stores the TGT at the local machine.

5. Kinit informs the user about success and terminates.

6. User executes SSH client with the desired hostname.

7. SSH client retrieves TGT stored in step 4.

8. SSH client requests for service ticket including TGT and the desired service identifier. The service identifier is derived from

22 4. Existing Authentication Methods

Local machine IdP machine Remote machine

User Kinit SSH client KDC SSH server

1. Init. Kerberos 2. Pass. prompt 3. TGT request

4. Stores TGT 5. success 6. Host access request

7. Retrieves TGT 8. Service request

9. Authentication request

Figure 4.1: Sequence diagram of simplified Kerberos authentication process in SSH environment

a given hostname. KDC checks TGT validity and issues a service ticket. A service ticket is a time-limited credential which authorizes the client to access a particular service.

9. SSH client sends an authentication request to the SSH server including a service ticket. SSH server validates the ticket and sends a response indicating successful authentication.

Note that the user has to be aware of an extra program Kinit and configure it to cooperate with particular KDC. It is important thata TGT is a credential enabling access to any kerberized service. Since SSH client does a TGT lookup before it prompts a user for a password, single sign-on can be achieved. To achieve delegation SSH client includes TGT into service request (step 7) and SSH server provides it to all processes in the remote session. If a remote process wishes to access a kerberized service, it gets a provided TGT and requests for service ticket (step 5). Besides, a Kerberos is widely used and therefore, it belongs to the comparison.

23 4. Existing Authentication Methods

Remote machine Local machine IdP machine

Authorization Cyclone PAM User Browser server

1. Run ser. Web server

2. Authorization prompt 3. Open Auth. URL 4. Auth. request 5. Conﬁguration

7. Auth. dialog 6. Auth. dialog

9. code 8. code

10. Token request

11. Identity check

Figure 4.2: Sequence diagram of Cyclone PAM authentication process

4.5 Cyclone PAM

Cyclone PAM is a PAM which allows the Linux OS to authenticate users using their federated identities without the need for a modified an SSH client or server [36, 37]. Figure 4.2 shows sequential diagram of an authentication process. Note the shown process begins after SSH server obtained authentication request and called PAM authentication routine with the desired account name. Since it uses authorization code flow and the process is similar to the authentication processof BCP for native apps described in section 1.1.3 I omit equivalent steps.

2. Cyclone PAM instructs a user to open a browser at a public address of a remote machine served by a web server.

3. User opens the browser window at the given address.

4. Browser sends a request to the local web server.

5. Web server obtains OAuth2 configuration with redirection URL set to the public address and constructs an authorization code request and redirects the browser to an authorization server.

24 4. Existing Authentication Methods

Local machine Remote machine

Guardian Guardian User SSH server agent SSH client

1. host + command 2. Auth. prompt 3. Authentication request

4. Execute command 5. Connection handoff 6. data

Figure 4.3: Sequence diagram of simplified SSH authentication process with Guardian agent

11. Cyclone PAM checks if obtained ID token contains identity which corresponds to the desired account name. It is done with a local configuration which maps account names to authorized identities.

It is important that the user has to open the browser manually and the remote machine must have a public address to be able to catch redirection in step 8. Authorization delegation is achieved by repeating the same process so the user has to open a browser for each SSH connection manually.

4.6 Guardian Agent

Guardian agent is an authentication architecture which allows a user to securely delegate access to the remote SSH client. This section strongly simplifies the architecture, and a full explanation can be found inre- lated paper [31]. It consists of a custom SSH client and agent. Figure 4.3 shows a simplified sequence diagram of SSH authentication process with the guardian agent. I omit a description of an agent forwarding since it is done the same way as described in section 2.2.1.

1. Guardian SSH client sends a request to guardian agent including desired host and command he wishes to execute.

25 4. Existing Authentication Methods

2. The agent prompts a user for consent with a delegation including information about the desired host, port and command. Note the agent prompts the user only when the desired command was not approved yet.

3. Guardian agent establishes TCP connection with the SSH server on given host and port and authenticates with a local private key.

4. The agent sends desired command to the server and instructs the server not to execute further commands with this connection.

5. The agent handoff TCP connection to the SSH client.

6. Guardian SSH client use obtained connection to communicate with the SSH server.

Delegation is achieved with the agent forwarding mechanism. Note the agent is applicable only in SSH context because it communicates directly with the SSH server. Furthermore, disabling execution of further commands (step 4) is provided by OpenSSH implementation exclusively. Since it improves security with negligible usability impact over a standard public key authentication method I chose this method to be compared instead of the public key. However, its interoperability issues should be kept in mind.

4.7 Conclusion

I presented several existing authentication methods which might be used to accomplish authorization delegation use-case. I choose Ker- beros, Cyclone PAM and Guardian agent to be compared with further proposed authentication architectures.

26 5 Authorization Code Agent Extension

This chapter describes a designed SSH agent extension which provides a service for obtaining an OAuth2 authorization code. Further described authentication architecture designs use it. I explain the motivation for such a tool, present how the agent is set up in the model environment, describe the authorization process, discuss its quality attributes and lastly, I conclude the outcomes.

5.1 Motivation

The section 1.1.3 presented best current practice for native apps which endorses a usage of authorization code grant with a recommendation to use user’s default browser. To complete the authorization, OAuth2 client needs to open the browser. In Linux OS environment, the requesting process must run on the local machine to access the user’s default browser. Therefore to be able to open the browser during the SSH authentication process some capable software must be run on the local machine. In case of an SSH client executed on a local machine it can be done directly by the client. However, in delegation use-case, user runs SSH client at the intermediate machine. So the SSH client is not able to access the local browser. One way to solve it is to use Agent forwarding mechanism described in section 2.2.1. SSH client sends a request to the forwarded agent, and the request is passed to the agent at the local machine via SSH channel. Finally, the local agent makes an authorization request and sends the code response back. There are two design options of the agent extension interface. It can either provide authorization code or token response. Both are suitable for the needs of defined use-cases. I decided to return authorization code. It is because in general requesting entity is not necessarily authorized to obtain neither OAuth2 client credentials nor token response. It is in cases where such entity acts as a communication bridge between OAuth2 client and Authorization code agent. I present such case later. The disadvantage of this design option is that the agent is limited to use authorization code grant. However, it is the best current practice.

27 5. Authorization Code Agent Extension

Local machine

User SSH client OAuth2 conﬁg

OAuth2 agent IdP machine Authorization Browser server

Figure 5.1: Deployment diagram of OAuth2 agent in model environment

Neither it can provide some additional features like token caching on a local machine to improve usability.

5.2 Environment Setup

This section describes preconditions of an environment and necessary configuration of the components to be able to run the authorization process. It is used later in the process description and in consideration sections. In the following text, I use term Authorization code agent for SSH agent which supports Authorization code agent extension. This section omits the agent setup with forwarding since it is done the same way as described in section 2.2.1. Figure 5.1 shows a deployment diagram of the Authorization code agent set up in the model environment.

• OAuth2 agent is installed and running on a local machine and listening on an open socket. the SSH client has read and write privileges to access the socket.

• SSH_AUTH_SOCK environment variable is provided to the SSH client and the value contains the agent socket address.

• OAuth2 agent is able to run a local web server.

• SSH client has access to OAuth2 configuration. Note the client credentials are not included.

28 5. Authorization Code Agent Extension

Local machine IdP machine

SSH client OAuth2 agent Browser Authorization server

1. Code request 2. Run ser. Web server

3. Code request 4. Auth. dialog 7. code 6. code 5. code

Figure 5.2: Sequence diagram of OAuth2 agent authorization process

• Authorization server allows registering the OAuth2 client with a loopback redirection URI.

5.3 Authorization Process

This section describes an actual communication between components set above. Figure 5.2 shows a sequence diagram of the authorization process. Note the process is based on SSH agent described in section 2.2 and best current practice for OAuth2 native apps flow described in section 1.1.3. This section omits the agent forwarding process since it is done the same way as with SSH agent.

1. SSH client requests the token by sending code request to a socket defined by the SSH_AUTH_SOCK environment variable. The request contains provided OAuth2 configuration.

2-6. Authorization code agent does the authorization code flow as described in section 1.1.3.

7. The agent pass the obtained authorization code response to the SSH client.

29 5. Authorization Code Agent Extension 5.4 Prototype Implementation

A prototype implementation is included as an attachment to this thesis. It is written in C language and uses parts of Dropbear SSH implementation mainly for socket communication. Part of a provided functionality overlaps with OIDC agent presented in section 4.3. So I considered basing the agent on it. However, I chose to implement the agent from scratch due to the flexibility of prototyping. The prototype was tested on stable versions of Debian1, Ubuntu2, CentOS3 and macOS4. An IdP interoperability was verified with Google and ELIXIR5 which conforms to OpenID Connect specification [38, 39]. I’ve tested it with OpenSSH and Dropbear clients and was able to forward the agent to the remote machine successfully. During the implementation, I found one portability issue. A standard way to access a default browser in Linux OS is a command xdg-open6. However, it does not support some necessary features like opening the page in a new window, closing the window or running in headless mode, which has usability consequences described later. For this reason, a prototype does not provide those features in a portable way. Solving this issue is beyond the scope of this thesis.

5.5 Easy Adoption and Interoperability Consideration

In this section, I discuss adoptability by a user, cloud infrastructure and IdP with focus on each defined component. Then I consider interoperability regarding each relation between the Authorization code agent and components defined in the environment setup section.

1. One of the oldest Linux distributions, https://www.debian.org 2. Linux distribution based on Debian, https://www.ubuntu.com 3. Linux distribution based on Red Hat Linux, https://www.centos.org 4. Proprietar operating system based on Linux OS, https://www.apple.com/cz/ macos/what-is/ 5. An intergovernmental organisation that brings together life science resources from across Europe, https://www.elixir-europe.org 6. https://portland.freedesktop.org/doc/xdg-open.html

30 5. Authorization Code Agent Extension

Authorization Code Agent It is worth mentioning that SSH forwards only one socket and the user might want to use both SSH public key and Authorization code agent services. Therefore the agent must support them. Either directly by implementing both services or indirectly by implementing one and redirecting unknown requests to the other. In this way, the agent can be adopted fluently.

SSH Client This design defined the concept of a new agent extension interface. This interface is formed by a socket which is not a pluggable way to authenticate the user. Therefore no currently developed applications can use it without further modification. It is neither very interoperable nor fluent adoptable approach. However, the socket interface canbe wrapped in a pluggable authentication interface such as PAM or GSS- API. Then the agent can be used by any client which supports them. I use this approach in the following chapter.

Authorization Server Since regular authorization code flow is used, any OAuth2 compliant authorization server can be used with OAuth2 agent.

5.6 Security Consideration

This design is highly based on standard solutions such as SSH protocol, SSH Agent protocol, OAuth2 framework and it follows Best current practices for native apps. Therefore it inherits all their security properties. This section discusses potential security issues regarding incorporated components and focuses on an authorization code since it is the only credential used in the process. Note it is not intended to be proof of security.

5.6.1 Access Gained by Intermediate Client OAuth2 agent provides it’s service to all processes running in user’s local session. Since the OAuth2 configuration is not considered asa

31 5. Authorization Code Agent Extension secret (the agent does not obtain client credentials), any locally running process can access authorization code. It might be an issue in case of OAuth2 public clients. However, we assumed user trusts all processes running in his session. Despite that, dynamic client registration might be used to register a confidential client to mitigate security risk. Another possibility is a use of PKCE. The authorization delegation to a remote machine is done by agent forwarding mechanism. In such case, all processes running in user’s remote session gains access to the code. It might be an issue in case of OAuth2 public clients. However, most of SSH client implementations require user explicit expression to forward the agent. Still, it is a security risk. The same techniques described in the previous section might be used to mitigate this risk.

5.6.2 Centralized Credentials in Agent

All the authorization codes from either local or remote sessions are exposed to the agent during the process. It is considered a security anti-pattern because if the agent is compromised, an attacker might gain access to all of those credentials. Therefore OAuth2 agent should be treated cautiously.

5.7 Usability Consideration

This section discusses usability regarding two phases. Former consists of users effort needed to fulfill assumptions defined in the environment setup section. Latter consists of user’s effort needed to complete the authorization process.

5.7.1 Initial Setup

The initial setup consists of agent installation and execution. Therefore the agent can be set up easily. Note I discuss the impact of configuring OAuth2 client later.

32 5. Authorization Code Agent Extension

5.7.2 Authorization Process The repeated authentication is by design effortless because I assume IdP keeps a session with user’s browser. Moreover, with OAuth2 confidential clients, IdP does not prompt a consent and immediately redirects the browser back to the agent. Then the agent can close the window. In such a case, the user might see an empty browser window for a while. It can be mitigated with a headless browser window. In case of OAuth2 public clients, authorization server usually prompts a user for authorization consent each time. A prototype implementation demonstrates portability and interoperability issues with browser communication on Linux OS. For that reason, the feasibility of effortless authorization was not verified.

5.8 Conclusion

Authorization code agent extension is an SSH agent extension intended to be used by native applications to obtain an authorization code. It is especially useful for native apps on remote machines which are not able to access a user’s default browser. For this purpose, the SSH agent forwarding mechanism is used. This chapter described an architecture and protocol concept designs. If correctly implemented it can be more secure delegation option than Public key and Kerberos authentication methods. This design can be easily adopted and is interoperable since it can be wrapped within a standard pluggable interface. Therefore this agent can be used by a wide range of clients. In general, the authentication process is well-usable especially with the use of OAuth2 confidential client. This design has several advantages over delegation options in existing methods. First, it can delegate access independently on the used authentication method. Among other things, It means a user can use existing authentication methods to access an intermediate machine and still delegate access with this agent. Moreover, the user can access the intermediate machine with one identity provider and delegate access with another one. Note it is not possible with Kerberos. Some of those statements were verified by implementing a prototype of Authorization code agent and integrated successfully with SSH Client and two IdPs, Google and ELIXIR. The authentication pro-

33 5. Authorization Code Agent Extension cess is illustrated in appendix B. During the implementation, I found out portability issues mainly because of insufficient Linux OS API for accessing the default browser. However, solving them is beyond the scope of this thesis.

34 6 Authentication Architecture Proposals

In this chapter, I propose authentication architecture designs. At the beginning of each proposal section, I describe the motivation and design choices I made. For each design, I present how it is setup in the model environment, the actual authentication process, prototype implementation details and easy adoption and interoperability considerations. Note that each design originated from the previous one and should be read in a row.

6.1 OAuth2 GSS-API mechanism

In the previous chapter, I presented an Authorization code agent which follows the best current practice for OAuth2 native apps. To be able to utilize an Authorization code agent, SSH client needs to communicate with the agent’s socket during the authentication process. One of the authentication methods which allows to extends SSH client in such a way is GSS-API mechanism. This section proposes an architecture which follows OAuth2 responsibility structure defined in section 3.4 and use Authorization code agent via GSS-API mechanism interface.

6.1.1 Environment Setup This section describes how is the GSS-API mechanism setup in the model environment. It presents environment preconditions and necessary configuration to be able to run the authentication process. Pre- sented information are used in an evaluation of quality attributes. For brevity in the following text I use terms OAuth2 GSS client and OAuth2 GSS server for OAuth2 GSS-API mechanism used by SSH client and SSH server, respectively. Figure 6.1 shows deployment diagram of OAuth2 GSS-API mechanism in model architecture. Since OAuth2 agent is involved all assumptions in section 5.2 applies. List of additional assumptions follows.

• OAuth2 GSS client is installed at the local machine, and OAuth2 GSS server is installed at the remote machine. SSH client and server are configured to use them.

35 6. Authentication Architecture Proposals

Local machine Remote machine

User SSH client SSH server

OAuth2 conﬁg OAuth2 GSS OAuth2 GSS IdP machine

Authorization OAuth2 agent Server Identity mapping

Figure 6.1: Deployment diagram of OAuth2 GSS-API mechanism in model environment

• Authorization server allows OAuth2 GSS server to get meta information about access tokens. Namely, validity, scope and user id. For example by providing introspection endpoint [40].

• OAuth2 GSS server has access to a mapping between remote machine account name and external IdP identity of a user. For example directly as a configuration file or provided as a userinfo claim. If mapping between machine account and IdP identity exists it semantically means that the account is owned by the user with the identity.

6.1.2 Authentication Process This section presents communication between incorporated components defined in the previous section. Presented information is used later in an evaluation of quality attributes. Figure 6.2 shows sequence diagram of authentication process with OAuth2 GSS-API mechanism. For brevity, I omit communication between SSH and OAuth2 GSS-API.

1. OAuth2 GSS client requests a code from OAuth2 agent. It includes the OAuth2 configuration. Note it does not include client credentials.

2. Authorization code agent runs the authorization process defined in section 5.3 and returns a token response containing the code.

36 6. Authentication Architecture Proposals

Local machine IdP machine Remote machine

Authorization OAuth2 GSS OAuth2 agent OAuth2 GSS server

1. Code request 2. Auth. dialog

3. Token request

4. Access request

5. Introspection 6. Identity 7. authorized check

Figure 6.2: Sequence diagram of authentication process with OAuth2 GSS-API mechanism

3. OAuth2 GSS client makes a token request with the code and obtains an access token.

4. OAuth2 GSS client sends the access token to OAuth2 GSS server.

5. OAuth2 GSS server checks the validity and scope of the token. For example by introspecting it at Authorization server. Besides, it gets the user ID.

6. OAuth2 GSS server checks if the user ID is authorized to access the remote account by checking provided mapping. For example directly as a configuration file or provided as a userinfo claim.I describe the impact of this decision below.

7. OAuth2 GSS server sends a response indicating successful authentication.

To obtain identity mapping, GSS server can either expect it in a local configuration file or obtain it from a userinfo endpoint. Both options are suitable, moreover can be combined. The first requires cloud infrastructure to fill the file during contextualization. Note it means an owner can change it in the future which can be the desired feature on virtual machines. The second allows centralized access

37 6. Authentication Architecture Proposals management. IdP has to have access to a list of machines owned by the particular user which requires tighter coordination between IdP and cloud infrastructures. Note both options can be used as authorization mechanism to allow multiple users have access to the one remote account. However such discussion is beyond the scope of this thesis. Also, note that an authorization code and all OAuth2 tokens are exposed to the SSH client.

6.1.3 Separated Resource Server Modification It is important to note that SSH server receives an access token. It might be a security issue when the remote machine is with unrestricted access and is not owned by the user. In themodel environment, if Mallory persuades Alice to connect to Malicious machine Mallory can get access to access token and therefore to protected resources. Note since Mallory was not authorized by Alice it is not specification compliant [10]. It is especially a problem with OAuth2 clients which uses access tokens with a broad scope. One way to mitigate this issue is to separate the resource server from the remote machine. Instead, cloud infrastructure or identity provider provides extra resource server endpoint. The idea is that separated resource server issues new token intended exclusively for the particular remote machine access. Note the similar concept is used in Kerberos. Figure 6.3 shows sequence diagram of modified authentication process. It is equal to the unmodified process except the following steps.

4. OAuth2 GSS client sends a request to the separated resource server. It includes access token, desired account name, and remote machine identification. The identification can be ahost- name or arbitrary string identification provided in advance by the remote machine. I discuss the impact of this decision below.

5. Resource server introspects the token so obtains the scope of access and a user ID.

6. Resource server checks if the access token is valid and is authorized to access the remote machine by checking it’s scope and

38 6. Authentication Architecture Proposals

Local machine IdP machine Remote machine

Authorization Resource OAuth2 GSS OAuth2 agent OAuth2 GSS server server

1. Code request 2. Auth. dialog

3. Token request

4. Resource access request

5. Introspection 6. Identity 7. resource access assertion check 8. Access request 9. Introspection 10. authorized

Figure 6.3: Sequence diagram of authentication process with OAuth2 GSS-API mechanism with separated resource server modification

user ID authorization to access the desired account. Besides, it means it needs to have provided identity mapping.

7. Resource server issues new token representing a relation between account name and remote machine ID. It sets expiration to expiration of an access token and sends it to the OAuth2 GSS client.

8. OAuth2 GSS client sends a request to the remote machine including obtained token.

9. OAuth2 GSS server checks the authenticity of the token. Either by introspection or by signature and checks obtained machine ID and account name.

The resource server needs the identification of the machine. It can be a hostname. However, there can be problems with machines with multiple domain names, proxies or NAT. Another option is that cloud infrastructure assigns artificial identification to the machine. In such case, resource server must be able to check the authenticity of such identifier, e.g., with signature.

39 6. Authentication Architecture Proposals

The behavior of presented endpoint is similar to authorization server token endpoint especially with assertion framework [41]. There- fore the protocols specification and token endpoint implementation might be partly reused. Concluded, it improves security by mitigating the problem of providing access token to remote machines for the price of adoptability. Because extra server endpoint must be maintained together with token and key management.

6.1.4 Prototype Implementation A prototype implementation is included as an attachment to this thesis. It shares the same codebase as Authorization code agent prototype implementation. I’ve tested authorization delegation successfully in ELIXIR infrastructure for SSH access to virtual machines running Linux OS. I’ve used Dropbear client a server SSH implementations mainly because of its modern codebase so I was able to quickly and flexible prototype considered designs. The implementation does not use GSS-API interface mainly because of its complexity and the fact Dropbear does not support it. Therefore the prototype does not verify interoperability between SSH client and server and OAuth2 GSS-API mechanism.

6.1.5 Easy Adoption and Interoperability Consideration In this chapter, I discuss consideration regarding easy adoption and interoperability. I omit those already mentioned in the Authorization code agent consideration section. The potential obstacle to fluently adopt this design is separated resource server modification. It adds an extra server endpoint which must be maintained. However, it can reuse some parts of authorization server implementation. Despite that, it should be considered. Otherwise, this design can be easily adopted by cloud infrastructures because the setup can be achieved by contextualization scripts solely. It installs the mechanism and configures an identity mapping. The mapping can be provided by cloud infrastructure since the platform software is aware of a user identity who instantiated the machine. SSH client and server can adopt new GSS-API mechanism in

40 6. Authentication Architecture Proposals

a standard way. Note the mechanism can be used simultaneously with existing GSS-API mechanisms by standard GSS-API mechanism negotiation [29]. Identity provider does not need to divert from the specification. The main interoperability issue might be that Authorization server must allow cloud infrastructures act as a resource server. However, it is a design choice of OAuth2 responsibility structure. I present second OpenID Connect structure in the following chapters. Interoperability with SSH implementation is achieved by GSS- API interface. Therefore any GSS-API compliant software can use this method. Namely, all SASL1 aware protocols such as IMAP, POP3, LDAP or Subversion. However, GSS-API binding was not implemented, and therefore interoperability and feasibility of integration with named protocols were not verified.

6.2 OIDC GSS-API mechanism

In the previous section I described authentication architecture design which follows OAuth2 responsibility structure. One of the disadvantages of the design is that initial configuration must be provided at local machine and the remote session obtains unauthorized access to protected resources. This section describes an authentication architecture design which tries to mitigate described issues by following OpenID Connect responsibility structure. The architecture and process are similar to the previous architecture however it has very different quality attributes, mainly because user grants access to different entity.

6.2.1 Environment Setup In this section, I describe environment preconditions and necessary configuration which has to be done in order to run the authentication process. Figure 6.4 shows deployment diagram of such environment. Since the environment is similar to OAuth2 GSS-API mechanism environment, I describe the difference only.

1. Simple Authentication and Security Layer, https://www.rfc-editor.org/rfc/ rfc4422.txt

41 6. Authentication Architecture Proposals

Local machine Remote machine

User SSH client SSH server

OIDC GSS OIDC GSS IdP machine

Authorization OAuth2 agent Server OAuth2 conﬁg Identity mapping

Figure 6.4: Deployment diagram of OpenID Connect GSS-API mechanism in model environment

• OAuth2 GSS mechanism is substituted by OIDC GSS mechanism.

• OIDC GSS server has access to OAuth2 configuration instead of the client.

• Authorization server does not need to allow OIDC GSS server to act as a resource server. It is because it does follow the OpenID Connect responsibility structure.

6.2.2 Authentication Process In this section, I present communication between defined components. Figure 6.5 shows sequence diagram of such process. It is similar to the authentication process of OAuth2 GSS-API mechanism, therefore I present differences only. Again I omit communication between SSH and GSS-API.

1. OIDC GSS client requests OAuth2 configuration from the OIDC GSS server. OIDC GSS server sends the OAuth2 configuration, including required access scope. In case of OIDC it is openid. Note it does not include client credentials.

4. OIDC GSS client sends an access request to the OIDC GSS server. Including obtained code instead of an access token.

42 6. Authentication Architecture Proposals

Local machine Remote machine IdP machine

Authorization OIDC GSS OAuth2 agent OIDC GSS server

1. Metadata request

2. Code request 3. Authorization dialog

4. Access request 5. Token request

6. Identity 7. authorized check

Figure 6.5: Sequence diagram of authentication process with OpenID Connect GSS-API mechanism

5. OIDC GSS server sends a token request to the authorization server and receives access and ID token. It obtains user ID from either userinfo server or ID token. I discuss the impact of this decision below.

6. OIDC GSS server checks if IdP identity is authorized to access the remote account by checking provided mapping. It can be statically configured, obtained from ID token or provided bya userinfo endpoint.

In order to get IdP identity of a user, OIDC GSS-API mechanism can either validate ID token and extract user’s identity, or it can request userinfo from IdP userinfo endpoint. Both options are suitable. To accomplish ID token validation, the mechanism needs to have access to a public key of IdP. In order to accomplish a userinfo request, the mechanism needs to have access to userinfo endpoint URI. Both public key and userinfo endpoint URI can be present directly as configuration option or indirectly trough discovery endpoint. Since the second option requires extra request I recommend the use of ID token validation.

43 6. Authentication Architecture Proposals

6.2.3 Prototype Implementation

A prototype implementation shares the same codebase as Authoriza- tion code agent and OAuth2 GSS-API mechanism and is included as an attachment. It was successfully tested in the same environment and again does not use GSS-API interface for the same reason.

6.2.4 Easy Adoption and Interoperability Consideration

This design can be adopted fluently by cloud infrastructures because they can prepare the architecture with contextualization scripts. It installs GSS-API mechanism with OAuth2 configuration for example provided from dynamic registration and configures SSH Server to use it. Finally, it configures identity mapping. IdP adopts this design effortlessly since only standard authorization code flow isused. Interoperability is achieved by GSS-API interface. Therefore any GSS-API compliant software can use this method. For example SASL aware protocols. However GSS-API binding was not implemented and therefore interoperability and feasibility of integration were not verified. The main issue with interoperability is that particular OAuth2 client is used. Therefore the only restricted set of SSH clients can access the server. It is because authorization server restricts application location by redirection URL and allowed grants of OAuth2 client. For example, a web-based application can’t be authorized to access files at Alice’s storage machine.

6.3 Device Code PAM

In the previous section I presented GSS-API mechanism which follows OpenID Connect responsibility structure. It tried to simplify initial setup for the user however user still needs to install an agent and a GSS-API mechanism. PAM interface can be used to achieve effortless initial setup. However, since it does not run at the client, it can’t access neither browser nor agent. Therefore authorization code flow cannot be used and an alternative must be chosen. One of such alternatives is device code flow.

44 6. Authentication Architecture Proposals

Local machine Remote machine

SSH Device OAuth2 conﬁg SSH client server PAM Identity mapping

User Personal device IdP machine Authorization Browser server

Figure 6.6: Deployment diagram of Device code PAM in model environment

Device code PAM is a PAM which implements authentication routine. When the routine is called, it performs device code flow and obtains a trustable identity of a user. Then it checks if obtained identity is authorized to access given local account. This chapter describes the architecture setup in a defined environment, an authentication process, it presents prototype implementation details and lastly, it evaluates the architecture regarding adoption and interoperability.

6.3.1 Environment Setup This section describes the preconditions of the environment and the necessary configuration of the components to be able to run theau- thentication process. That information is used later for evaluation of this design. For better understanding figure 6.6 shows a deployment diagram of such architecture.

• Identity provider must support Device code flow.

• Device code PAM is installed on the remote machine, and SSH server is configured to use the PAM.

• Device flow PAM has access to OAuth2 configuration.

• Device flow PAM has access to a mapping between machine account name and external identity of an authorized user. For

45 6. Authentication Architecture Proposals

Local machine Remote machine IdP machine

User SSH server Authorization SSH client server Browser PAM

1. Authentication request 2. Authentication PAM request 4. Verification prompt 3. Device request 6. Token request 5. Verification prompt 7. Open verif. URL 8. Verification dialog

9. Token request

10. Identity 11. authorized check

Figure 6.7: Sequence diagram of authorization process with Device code PAM

example directly as a configuration file or provided by a userinfo claim.

• SSH client is configured to use PAM authentication method. Note it is often default option.

• User has access to a personal device with the browser with internet connection. E.g., his mobile phone or laptop. Note the local machine and personal device could be the same hardware.

6.3.2 Authentication Process In this section, I describe actual communication between incorporated components set above. Figure 6.7 shows sequence diagram of such communication. Note the process is based on the PAM authentication process and Device code flow.

1. SSH client sends an authentication request to the SSH server together with flag instructing SSH server to use PAM.In includes cloud machine account name which user wants to access.

46 6. Authentication Architecture Proposals

2. SSH server calls Device code PAM authentication routine. It is configured beforehand to use specific PAM.

3. Device code PAM makes a request to Authorization server and receives device code, user code and verification URI.

4. Device code PAM sends a prompt message to the SSH client. The message instructs a user to verify the SSH server at given verification URI with given user code.

5. SSH client shows given prompt message to the user.

6. Meanwhile Device code PAM starts polling Authorization server with given device code.

7. User opens the browser on his personal device and visits given verification URI.

8. Verification URI is served by the Authorization server. It realizes verification dialog with the user.

9. Device code PAM polls Authorization server token endpoint and receives a successful token response. It contains ID token and access token. It can either validates ID token and extract users identity or it can request userinfo from a userinfo endpoint. It has the same impact as described in section 6.2.2.

10. Device code PAM checks if IdP identity is authorized to access the local account by checking configured mapping with given cloud machine account name from step 1.

11. SSH server responses to SSH client indicating success.

6.3.3 Prototype Implementation A prototype implementation is included in the attached archive. It is written in python and uses package python_pam2 to integrate it into PAM system. The prototype was tested successfully in the same environment as previously presented designs. Further, I integrated

2. http://pam-python.sourceforge.net/

47 6. Authentication Architecture Proposals it into OpenSSH server successfully. Since it was implemented using PAM interface I was able to verify interoperability with various PAM- aware applications such as X-session Desktop login, VNC3 or as extra authentication for superuser access. During the implementation, I found unexpected behavior of PAM implementation in OpenSSH. When PAM sends a non-prompting message to the OpenSSH server, the server does not send the message to the client until following prompt message is received or the PAM module ends. Since Device code PAM does neither prompts user nor ends the message is not shown to the user. I solved it by introducing unnecessary prompt for any key between instruction message and starts of polling. It is considered as another user inconvenience. The issue was analyzed and reported to the OpenSSH developers.

6.3.4 Easy Adoption and Interoperability Consideration It can be adopted very easily since user does need to neither install any new packages nor configure them. Moreover, SSH Server can be configured to enable other authentication methods besides PAM. Therefore the transition can be fluent. Cloud infrastructures need to configure each new machine. It can be done with contextualization scripts. It installs Device code PAM with OAuth2 configuration for example provided from dynamic registration and configures SSH Server to use the PAM. Finally, it provides user identity mapping for example as a configuration file. This architecture design is interoperable with any PAM compliant software. Since we did not use any SSH exclusive features, this architecture can be reused in any client-server environment. The PAM module can be reused standardly in many services such as FTP, Desk- top login, VNC4 or as extra authentication for superuser access. At the time of the publication of this thesis the Device code flow is being standardized so IdP interoperability should be considered.

3. Virtual Network Computing 4. Virtual Network Computing

48 7 Quality Attribute Comparison

This chapter compares proposed authentication architecture designs with existing authentication methods. It considers security and usability quality attributes with focus on delegation use-case. All proposed designs are highly based on standards such as SSH protocol, SSH Agent protocol, OAuth2 framework, GSS-API, PAM and it follows best current practices for native apps. Therefore it inherits all their security and usability properties. Since some of them use Authorization code agent, all its considerations apply respectively.

7.1 Security Consideration

This section discusses potential security issues regarding incorporated components of architecture with a focus on credentials and access they gain. For simplicity, I do not distinguish between PAM or GSS-API and SSH components. Security of each component is considered regarding proposed and existing authentication methods. At the end, I conclude the comparison and outcomes. Note it is not intended to be proof of security.

7.1.1 Access Gained by Intermediate Client This section discusses security considerations regarding authorization delegation with focus on situations where intermediate SSH client is malicious. As a model example, Alice is about to connect to Mallory’s machine and access her storage or virtual machine with an SSH client at the malicious machine. Mallory wants to access the data on Alice’s storage machine.

OAuth2 GSS-API mechanism In this architecture, authorization code and all OAuth2 tokens are exposed to the SSH client. However, a user must explicitly allow the agent forwarding to the intermediate session and must explicitly gives consent to the SSH client to receive such access during authorization dialog. Therefore it is important to correctly inform the user about

49 7. Quality Attribute Comparison the identity of the client during the authorization process. It might be a problem with OAuth2 public clients since they can’t address specific processes in a session. Dynamic client registration can beused to enhance awareness of a user. However, it should be done with a software statement. Otherwise, malicious SSH client would be able to register OAuth2 client with arbitrary identification. The tokens are scope restricted which disallows SSH client to access the storage machine as long as they do not share the same scope. Therefore access scopes should be granular enough. Moreover, tokens are time-limited and revocable which restricts the impact of an attack.

OIDC GSS-API mechanism In OIDC GSS-API architecture, authorization code is exposed to the intermediate client. It might be an issue since a user does not authorize the client. To mitigate this issue, PKCE can be used. Note it is not an issue with OAuth2 confidential clients since to get access tokens client authentication is required. The client is confidential if the remote machine is with restricted access or if registered with dynamic client registration. However, it is a problem with OAuth2 public clients. The SSH client can get access token. It is important to note that the access token represents access to openid scope and therefore no machines can be accessed by it. The access to the machine can be gained only with an authorization code which is client specific so an attacker can access only those machines which share an OAuth2 client. Moreover, it is a short-lived one-time credential, and therefore its unauthorized usage is detectable so that appropriate steps can be performed.

Device Code PAM The only credentials SSH client receives is a usercode. However, usercode is a short-lived one-time credential which can’t be used to get access token without a device code. Therefore an attacker has to com- promise SSH server to access protected resources. Moreover, SSH server does not accept any credentials from SSH client at the intermediate machine directly. All token credentials are directly transferred from IdP to the remote machine. Regardless public or confidential OAuth2 client it is a secure approach.

50 7. Quality Attribute Comparison

Public Key with Guardian Agent In this method, no credentials are exposed to the client, but cryptographic operations are provided to the SSH client. As a consequence, access is restricted strictly for a lifetime of a session. The access scope is restricted to a specific machine and command. Therefore is more granular than all previous methods in case of a non-interactive session. The other considerations depend on the agent implementation. But it can support time restriction. Security disadvantage of this method is that attack is not detectable, and that authorization is gained by the whole intermediate session which is less granular than proposed methods with a confidential client.

Kerberos Authorization delegation in Kerberos is done by forwarding TGT. The delegation has to be explicitly allowed by the user. A TGT is time restricted credential which provides access to scope unlimited resources. It is non-revocable and its unauthorized use is not detectable. More- over, the TGT is exposed to all processes in the intermediate session. It is considered less secure than all previous approaches.

Cyclone PAM The delegation with Cyclone PAM is done in the very same way as in Device code PAM and therefore all its considerations apply.

7.1.2 Access Gained by Remote Server This section discusses security considerations regarding authorization delegation with focus on situations where the final SSH server is malicious. As a model example, Alice has connected to her virtual machine and is about to access Mallory’s malicious machine with SSH. It is worth mentioning it is not an issue in situations when the remote machines are with restricted access or in environments where the act of connecting to the host is considered as sufficient expression of trust to the remote machine. Therefore I consider situations different from that.

51 7. Quality Attribute Comparison

OAuth2 GSS-API mechanism In this design, remote server gains access to the access token and therefore to protected resources. I already described this issue previously in separation of the resource server modification section 6.1.3 which mitigates this issue.

OIDC GSS-API mechanism The SSH server gains access to all OAuth2 tokens. Moreover, it might requests access to any scope. However, a user has to authorize the SSH server to access those resource explicitly. Therefore it is important to inform the user about SSH server identity properly. To prevent an owner of the remote machine to change Client metadata dynamic client registration should be restricted. For example by software statement. Since openid access scope is enough for the described case, SSH client can incorporate mechanisms to disable other scopes. Further- more, the authorization server may restrict token lifetime since the SSH server uses the token response only once and immediately. More- over, authorization server may disable refreshing of an access token.

Device Code PAM SSH server with Device code flow PAM receives the same set of credentials as with OIDC GSS-API mechanism and therefore follows the same security considerations. Except that SSH client is not able to restrict requested scopes since it can’t access OAuth2 client configuration.

Public Key with Guardian Agent In this method, SSH server sends a signature challenge to SSH client which is propagated to the local machine and signed. Therefore it gains access to cryptographic operations at local machine and can act as a MITM1. It gains access to scope unlimited protected resource. Moreover, the attack is non-detectable.

1. Man In The Middle

52 7. Quality Attribute Comparison

Kerberos

The SSH server obtains a service ticket. Since service ticket is credential issued for the machine itself the SSH server gains no additional resources. It is an approach similar to the separated resource server.

Cyclone PAM

The remote machine receives the same set of credentials as Device code PAM and therefore all its considerations apply.

7.1.3 Conclusion

The only proposed architecture which provides access to protected resources to an unauthorized party is OAuth2 GSS-API mechanism with machines with unrestricted access. It provides access token to the remote server. Still, it is more secure than a public key with Guardian agent method due to scope restricted tokens. Importantly, I propose modification similar to Kerberos approach which mitigates it. All the other methods are considered secure since they do not allow an unauthorized party to access a protected resource. One common minor issue was found. A user might be fooled with fake client identification while authorizing the client. Therefore he can uninten- tionally give access to the process within the active session. However, it can be mitigated with dynamic client registration restricted with software assertion. Concluded, proposed architectures are comparatively same or better than existing authentication methods mainly owing to the possibility to revoke and limit the scope of delegated access.

7.2 Usability Consideration

This section discusses usability regarding initial setup and authentication process phase. Usability of each phase is considered regarding proposed and existing authentication methods. At the end, I conclude the comparison and outcomes.

53 7. Quality Attribute Comparison

7.2.1 Initial Setup

This section presents a user’s initial effort which the user has to make to be able to run an authentication process. Note I discuss setup on the local machine only since a remote machine installation can be pre-configured by cloud infrastructure with contextualization scripts.

OAuth2 GSS-API mechanism

The initial setup consists of an Authorization code agent initial setup, GSS-API mechanism installation, SSH client configuration, and OAuth2 configuration. The last one can be a problem for non-technical users. It can be mitigated by using discovery endpoint [42] if authorization server supports it. Then user configures only one URL to provide IdP configuration. It can be further mitigated by allowing dynamic client registration, so the user would not need to provide OAuth2 client configuration. Furthermore, the metadata can be generated from a local account and a machine name or provided in a software statement. Finally, it can be mitigated by modifying the authentication process in a way that an SSH server advises access scopes which are required to access the remote account. Therefore a user does not have to provide it as a static configuration. However, it increases security risk of issue that SSH server receives an access token. In this case, it gains access to an arbitrary protected resource. Therefore I recommend to use it with Separated resource server modification. If all of those features are supported user setup the agent, install GSS-API mechanism, enable GSS-API in SSH client configuration and configures IdP discovery endpoint. If it is still an issue IdP might provide IdP specific pre-configured installation package.

OIDC GSS-API mechanism

This design requires a user to set up agent, install OIDC GSS-API mechanism and enable GSS-API in SSH client configuration.

54 7. Quality Attribute Comparison

Device Code PAM Because PAM runs on a remote server user does not need to set up anything. SSH client needs to be configured to try keyboard-interactive. However, it is commonly enabled by default, so the initial setup is effortless.

Public Key with Guardian Agent Initial setup of the public key with Guardian agent consists of Guardian agent installation, key-pair generation, public key distribution and configuring agent to use a private key. User uses special programs for key generation and agent configuration. Moreover, he/she often provides keys to the cloud infrastructure manually.

Kerberos Kerberos initial setup consists of Kerberos installation, KDC configuration, SSH configuration. KDC configuration consists mainly of providing a location address of KDC. To configure SSH, user must enable GSS-API in configuration.

Cyclone PAM Initial setup of Cyclone PAM is the same as for Device Code PAM, so it is effortless.

7.2.2 Authentication Process This section presents a user’s effort to make a successful authentication process with a focus on the first and repeated authentication because it typically differs. Also, I focus on a possibility to authenticate to multiple machines. Consider use-case when Alice wants to access data stored on tens of machines across various cloud infrastructures.

OAuth2 GSS-API mechanism OAuth2 GSS-API design is well-usable especially in repeated requests since an IdP keeps a browser session. To mitigate repeated authoriza-

55 7. Quality Attribute Comparison tion consent, dynamic registration might be used to make OAuth2 client confidential. The client can request an access token with wider appropriate scopes within one authorization code flow. So the design scales well for access to multiple machines in various infrastructures. For usability purposes, token responses might be stored by the SSH client. When the client is executed repeatedly, it does a lookup before it opens the browser. Tokens should be categorized by an IdP and an OAuth2 client and might be categorized by scopes. The storage can be persistent or in-memory only. Concluded, it improves usability at the cost of security. Note stored tokens might be encrypted by user- provided passphrase however it is in contradiction with the primary usability goal.

OIDC GSS-API mechanism

It is important to note that SSH client does not gain access to an access token. It is a security advantage however neither token response can be cached, nor access token can be refreshed. Authorization code flow will be performed each time a user tries to connect to the machine. It might be a usability issue when the user requires to access multiple machines. It can be mitigated by using OAuth2 confidential client configuration shared across multiple machines with restricted access. In such case authorization code will be performed for each machine but will be invisible for the user.

Device Code PAM

Device code PAM is not well-usable neither during repeated requests nor with requests to multiple machines. SSH client receives just one time credentials (usercode) and there is no way to persist session from plain PAM. The user is prompted each time he/she accesses the SSH server. Moreover, if some program needs access to multiple remote machines user needs to open the browser repeatedly for each remote machine manually. Five adjustments can improve it. First, URL can be shortened to be easier rewritten. Secondly, by using X-terminal which parses output URLs and makes them clickable links. Thirdly, by incorporating in-

56 7. Quality Attribute Comparison

terminal QR code2 so user can scan the QR code on his mobile device instead of rewriting the whole URL. Moreover, QR reader can be configured to open the browser automatically. However, not all terminals support coloring and required Unicode3 characters. Fourthly, the specification draft defines a way how to integrate usercode into verification URL, so when the user clicks the URL or scans the QR code, he/she does not need to rewrite the usercode. Fifthly, with dynamic client registration or at machines with restricted access the OAuth2 clients can be considered confidential. Therefore, a user does not have to give consent each time he accesses the authorization endpoint. Assuming that IdP keeps session, repeated QR scanning will result in an opening a browser and directly showing a page with successful authorization and instructions to close the browser.

Public Key with Guardian Agent With this method, a user does authenticate effortlessly either with initial or repeated requests. The authorization delegation requires specific one-time consent for each command and host. Therefore it might be a usability issue with access to multiple machines. But in general, I consider public key with Guardian agent as well-usable.

Kerberos Initial authentication requires obtaining a TGT by running kinit command with user’s username. The user is prompted for a password. Since authorization does not require any consent, repeated requests are effortless and can be easily used to access multiple machines. The main disadvantage is that user must be aware of a new command.

Cyclone PAM The authentication process is similar from the user point of view and can be improved in a similar way as Device code PAM. However, Cyclone PAM has one disadvantage. Unlike Device code PAM, The

2. Quick Response Code, https://en.wikipedia.org/wiki/QR_code 3. https://unicode.org/

57 7. Quality Attribute Comparison displayed address is pointing to the local machine. It might be a problem since users are often not aware of it. Compared with Device code, the address is pointing to the IdP. On the other hand, the user does not have to rewrite the usercode.

7.2.3 Conclusion All proposed architectures are considerably usable in particular situations and do not stay behind existing authentication methods. The OAuth2 GSS-API mechanism requires the comparatively same amount of effort as Kerberos for initial setup and overcomes Kerberos in authentication process since no extra command is used. It can be used with advantage in situations where a user requires to access to many machines. For example in computational or storage grid environment. I consider OAuth2 GSS-API mechanism as comparatively better than Public key and Kerberos since it requires neither complex initial setup nor extra effort during authentication. The disadvantage isan inability to delegate access to multiple machines at once so I can recommend it for use where only one machine is accessed. For example for access to a virtual machine. The most easily adoptable proposal for users is a Device code PAM because its initial setup is effortless. It overcomes Cyclone PAM ina particular situation. Moreover, it can be used inside private networks. On the other hand authentication requires repetitive manual user interaction and its usage to access multiple machines is inconvenient. Therefore I recommend it as a backup solution if the OAuth2 GSS-API mechanism is not set up by the user. It is important that even though Device PAM does not make use of Authorization code agent, still, it can forward it for proposed GSS-API mechanisms. Concluded, all of the proposed architectures are comparably same or better than existing authentication methods in particular situations. They can benefit from dynamic registration since IdP typically does not require consent with the repeated authorization request. Note they can coexist in the same environment and can complement each other.

58 8 Conclusion

This thesis proposed three authentication architecture designs which use OpenID Connect identity provider in distributed environment. Each design was evaluated regarding security and usability quality attributes with a special focus on authorization delegation. SSH protocol was used as a model method to access remote machines. The outcomes are compared with existing single sign-on authentication methods. A prototype of each proposed architecture was implemented to verify its quality attributes and feasibility. They were tested on OpenSSH and Dropbear SSH client and server with ELIXIR identity provider in Linux OS environment. All proposed authentication architecture designs are secure and often overcomes existing authentication methods mainly owing to the possibility to revoke and limit the scope of delegated access. Each of them has different properties regarding usability and serves best in different situations. The key differences are an ability to delegate access to multiple remote machines at once, and a various user effort spent with the initial configuration and repeated delegation. It is worth mentioning they can coexist in the same environment and complement each other. As a side effect, the use of OpenID Connect allows arbitrary web-based authentication method to be used in a distributed environment. All of the designs are implementable as general pluggable interfaces and therefore can be fluently adopted by various software. All communication follows standardized protocols, and the design conforms to AARC’s blueprint architecture [43] and therefore is interoperable with a wide range of real-world environments.

8.1 Research Contributions

As a side effect, a list and comparison regarding security and usability of single sign-on authentication methods capable of delegating authorization was created.

59 8. Conclusion

I was working with a recent not widely adopted specification drafts. In order to support them by a prototyping environment, I committed to a reference OpenID Connect Java implementation1. At the time of publication of this thesis ELIXIR has already started to implement and test Device code PAM architecture to access cloud virtual machines.

8.2 Future Work

As mentioned, implementations are not ready for production use, and several issues were found regarding browser interoperability or adoption of GSS-API mechanism by SSH implementations. Solving those issues are beyond the scope of this thesis and may be seen as future challenges for design implementers. The thesis presented many possible options for a single use-case rather than tried to choose a one. It is intentional, so it could serve as a reference for future discussion in a related community rather than a standard proposal since I did not even try to discover all possible use-cases of OpenID Connect Based Authentication for Host Remote Access.

1. MitreID Connect https://github.com/mitreid-connect/OpenID-Connect- Java-Spring-Server

60 Bibliography

1. DE CLERCQ, Jan. Single Sign-On Architectures. In: DAVIDA, George; FRANKEL, Yair; REES, Owen (eds.). Infrastructure Security. Springer Berlin Heidelberg, 2002, pp. 40–58. ISBN 978-3-540-45831-9. Avail- able from DOI: 10.1007/3-540-45831-X_4. 2. DIKAIAKOS, Marios D; KATSAROS, Dimitrios; MEHRA, Pankaj; PAL- LIS, George; VAKALI, Athena. Cloud computing: Distributed internet computing for IT and scientific research. IEEE Internet computing. 2009, vol. 13, no. 5, pp. 10–13. Available from DOI: 10.1109/MIC. 2009.103. 3. MELL, Peter; GRANCE, Timothy, et al. The NIST definition of cloud computing. National institute of standards and technology. 2009, vol. 53, no. 6, pp. 50. Available also from: http://faculty.winthrop.edu/ domanm/csci411/Handouts/NIST.pdf. 4. COULOURIS, George F; DOLLIMORE, Jean; KINDBERG, Tim. Dis- tributed Systems: Concepts and Design. Pearson Education, 2005. In- ternational computer science series. ISBN 9780321263544. 5. GASSER, Morrie; MCDERMOTT, Ellen. An architecture for practi- cal delegation in a distributed system. In: Proceedings. 1990 IEEE Computer Society Symposium on Research in Security and Privacy. 1990, pp. 20–30. Available from DOI: 10.1109/RISP.1990.63835. 6. NEUMAN, B. C.; TS’O, T. Kerberos: an authentication service for computer networks. IEEE Communications Magazine. 1994, vol. 32, no. 9, pp. 33–38. ISSN 0163-6804. Available from DOI: 10.1109/35. 312841. 7. YLONEN, T.; LONVICK, C. The Secure Shell (SSH) Authentication Pro- tocol [Internet Requests for Comments]. RFC Editor, 2006. ISSN 2070-1721. Available also from: http://www.rfc-editor.org/rfc/ rfc4252.txt. RFC. 8. KOGAN, Dmitry; STERN, Henri; TOLBERT, Ashley; MAZIÈRES, David; WINSTEIN, Keith. The Case For Secure Delegation. In: Proceedings of the 16th ACM Workshop on Hot Topics in Networks. Palo Alto, CA, USA: ACM, 2017, pp. 15–21. HotNets-XVI. ISBN 978-1-4503-5569-8. Available from DOI: 10.1145/3152434.3152444.

61 BIBLIOGRAPHY

9. BELLOVIN, S. M.; MERRITT, M. Limitations of the Kerberos Authenti- cation System. SIGCOMM Comput. Commun. Rev. 1990, vol. 20, no. 5, pp. 119–132. ISSN 0146-4833. Available from DOI: 10.1145/381906. 381946. 10. SAKIMURA, Nat; BRADLEY, John; JONES, Mike; MEDEIROS, Breno de; MORTIMORE, Chuck. OpenID Connect Core 1.0. The OpenID Foundation, specification. 2014. Available also from: https://openid. net/specs/openid-connect-core-1_0.html. 11. HARDT, Dick. The OAuth 2.0 Authorization Framework [Internet Re- quests for Comments]. RFC Editor, 2012. ISSN 2070-1721. Available also from: http://www.rfc-editor.org/rfc/rfc6749.txt. RFC. RFC 6749. 12. SANTESSON, S.; MYERS, M.; ANKNEY, R.; MALPANI,A.; GALPERIN, S.; ADAMS, C. X.509 Internet Public Key Infrastructure Online Certifi- cate Status Protocol - OCSP [Internet Requests for Comments]. RFC Editor, 2013. ISSN 2070-1721. Available also from: http://www.rfc- editor.org/rfc/rfc6960.txt. RFC. 13. REYNOLDS, J.; SMITH, T.; REESE, K.; DICKINSON, L.; RUOTI, S.; SEAMONS, K. A Tale of Two Studies: The Best and Worst of YubiKey Usability. In: 2018 IEEE Symposium on Security and Privacy (SP). 2018, pp. 872–888. ISSN 2375-1207. Available from DOI: 10.1109/SP.2018. 00067. 14. CANTOR, Scott; KEMP, John; PHILPOTT, Rob; MALER, Eve. Asser- tions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 [OASIS Standard]. OASIS, 2005. Available also from: http://docs.oasis-open.org/security/saml/v2.0/saml-core- 2.0-os.pdf. OASIS Standard. 15. DENNISS, William; BRADLEY, John; JONES, Michael; TSCHOFENIG, Hannes. OAuth 2.0 Device Flow for Browserless and Input Constrained Devices [Working Draft]. 2018. Available also from: http://www. ietf.org/internet-drafts/draft-ietf-oauth-device-flow- 13.txt. Internet-Draft. IETF Secretariat. 16. DENNISS, William; BRADLEY, John. OAuth 2.0 for Native Apps [In- ternet Requests for Comments]. RFC Editor, 2017. ISSN 2070-1721. Available also from: http://www.rfc-editor.org/rfc/rfc8252. txt. BCP. RFC 8252.

62 BIBLIOGRAPHY

17. SAKIMURA, Nat; BRADLEY, John; AGARWAL, Naveen. Proof Key for Code Exchange by OAuth Public Clients [Internet Requests for Com- ments]. RFC Editor, 2015. ISSN 2070-1721. Available also from: http: //www.rfc-editor.org/rfc/rfc7636.txt. RFC. 18. RICHER, Justin; JONES, Michael B.; BRADLEY, John; MACHULAK, Maciej; HUNT, Phil. OAuth 2.0 Dynamic Client Registration Protocol [Internet Requests for Comments]. RFC Editor, 2015. ISSN 2070- 1721. Available also from: http://www.rfc- editor.org/rfc/ rfc7591.txt. RFC. 19. SAKIMURA, Nat; BRADLEY, John; JONES, Mike. OpenID Connect Dynamic Client Registration 1.0. The OpenID Foundation, specification. 2014. Available also from: https://openid.net/specs/ openid-connect-registration-1_0.html. 20. JONES, M.; BRADLEY, J.; SAKIMURA, N. JSON Web Token (JWT) [Internet Requests for Comments]. RFC Editor, 2015. ISSN 2070- 1721. Available also from: http://www.rfc- editor.org/rfc/ rfc7519.txt. RFC. 21. JONES, M.; BRADLEY, J.; SAKIMURA, N. JSON Web Signature (JWS) [Internet Requests for Comments]. RFC Editor, 2015. ISSN 2070- 1721. Available also from: http://www.rfc- editor.org/rfc/ rfc7515.txt. RFC. 22. YLONEN, Tatu. SSH–secure login connections over the Internet. In: Proceedings of the 6th USENIX Security Symposium. 1996, vol. 37. Avail- able also from: http://static.usenix.org/publications/library/ proceedings/sec96/full_papers/ylonen/ylonen.ps. 23. BARRETT, Daniel J; SILVERMAN, Richard E; BYRNES, Robert G. SSH, The Secure Shell: The Definitive Guide. O’Reilly Media, Inc., 2005. ISBN 1449324819. 24. YLONEN, T.; LONVICK, C. The Secure Shell (SSH) Protocol Architecture [Internet Requests for Comments]. RFC Editor, 2006. ISSN 2070-1721. Available also from: http://www.rfc-editor.org/rfc/rfc4251. txt. RFC.

63 BIBLIOGRAPHY

25. GASSER, O.; HOLZ, R.; CARLE, G. A deeper understanding of SSH: Results from Internet-wide scans. In: 2014 IEEE Network Operations and Management Symposium (NOMS). 2014, pp. 1–9. ISSN 1542-1201. Available from DOI: 10.1109/NOMS.2014.6838249. 26. CUSACK, F.; FORSSEN, M. Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) [Internet Requests for Comments]. RFC Editor, 2006. ISSN 2070-1721. Available also from: http://www. rfc-editor.org/rfc/rfc4256.txt. RFC. 27. SAMAR, Vipin. Unified Login with Pluggable Authentication Modules (PAM). In: Proceedings of the 3rd ACM Conference on Computer and Communications Security. ACM, 1996, pp. 1–10. CCS ’96. ISBN 0- 89791-829-0. Available from DOI: 10.1145/238168.238177. 28. LINN, J. Generic Security Service Application Program Interface Version 2, Update 1 [Internet Requests for Comments]. RFC Editor, 2000. ISSN 2070-1721. Available also from: http://www.rfc-editor.org/rfc/ rfc2743.txt. RFC. 29. HUTZELMAN, J.; SALOWEY, J.; GALBRAITH, J.; WELCH, V. Generic Security Service Application Program Interface (GSS-API) Authentica- tion and Key Exchange for the Secure Shell (SSH) Protocol [Internet Re- quests for Comments]. RFC Editor, 2006. ISSN 2070-1721. Available also from: http://www.rfc-editor.org/rfc/rfc4462.txt. RFC. 30. MILLER, Damien. SSH Agent Protocol [Working Draft]. 2017. Avail- able also from: http://www.ietf.org/internet-drafts/draft- miller-ssh-agent-02.txt. Internet-Draft. IETF Secretariat. 31. FRIEDL, Steve. An Illustrated Guide to SSH Agent Forwarding. Ed. by TIPS, Steve Friedl’s Unixwiz.net Tech. 2006. Available also from: http://www.unixwiz.net/techtips/ssh- agent- forwarding. html. 32. HOSKINS, Matthew E. SSHFS: Super Easy File Access over SSH. Linux J. 2006, vol. 2006, no. 146, pp. 4–. ISSN 1075-3583. Available also from: http://dl.acm.org/citation.cfm?id=1134782.1134786. 33. ZVIRAN, Moshe; HAGA, William J. Password Security: An Empiri- cal Study. Journal of Management Information Systems. 1999, vol. 15, no. 4, pp. 161–185. Available from DOI: 10.1080/07421222.1999. 11518226.

64 BIBLIOGRAPHY

34. oidc-agent [online]. GitBook [visited on 2018-12-10]. Available from: https://indigo-dc.gitbooks.io/oidc-agent/. 35. KOHL, J.; NEUMAN, C. The Kerberos Network Authentication Service (V5) [Internet Requests for Comments]. RFC Editor, 1993. ISSN 2070-1721. Available also from: http://www.rfc-editor.org/rfc/ rfc1510.txt. RFC. 36. BONELO, Erik B. OpenID Connect Client Registration API for Feder- ated Cloud Platforms. 2017. Available also from: https://aaltodoc. aalto.fi/handle/123456789/26775. 37. SLAWIK, Mathias. Managing cloud ecosystems: Brokering, Deployment, and Consumption. 2018. Available from DOI: 10.14279/depositonce- 7328. 38. LI, Wanpeng; MITCHELL, Chris J. Analysing the Security of Google’s Implementation of OpenID Connect. In: CABALLERO, Juan; ZURU- TUZA, Urko; RODRÍGUEZ, Ricardo J. (eds.). Detection of Intrusions and Malware, and Vulnerability Assessment. Cham: Springer Interna- tional Publishing, 2016, pp. 357–376. ISBN 978-3-319-40667-1. Avail- able from DOI: 10.1007/978-3-319-40667-1_18. 39. LINDEN, M et al. Common ELIXIR Service for Researcher Authen- tication and Authorisation. F1000Research. 2018, vol. 7, no. 1199. Available from DOI: 10.12688/f1000research.15161.1. 40. RICHER, J. OAuth 2.0 Token Introspection [Internet Requests for Com- ments]. RFC Editor, 2015. ISSN 2070-1721. Available also from: http: //www.rfc-editor.org/rfc/rfc7662.txt. RFC. 41. CAMPBELL, B.; MORTIMORE, C.; JONES, M.; GOLAND, Y. Asser- tion Framework for OAuth 2.0 Client Authentication and Authorization Grants [Internet Requests for Comments]. RFC Editor, 2015. ISSN 2070-1721. Available also from: http://www.rfc-editor.org/rfc/ rfc7521.txt. RFC. 42. SAKIMURA, Nat; BRADLEY, John; JONES, Mike; JAY, Edmund. OpenID Connect Discovery 1.0. The OpenID Foundation, specification. 2014. Available also from: https://openid.net/specs/openid-connect- discovery-1_0.html. 43. AARC Blueprint Architecture [online]. 2017 [visited on 2018-12-08]. Avail- able from: https://aarc-project.eu/architecture/.

A Content of Attached Archive

A part of this thesis is an electronic archive containing prototype implementation of proposed designs. All included directories contains a file README.md which contains installation and usage instructions. The archive consists of two records.

device_code_pam contains a prototype implementation of Device code PAM authentication architecture design.

oauth2_dropbear contains prototype implementations of both OAuth2 and OIDC GSS-API authentication architecture designs and a prototype of Authorization code agent.

B Authentication Process Illustration

B.1 OAuth2 GSS-API Mechanism

Figure B.1: Initial state in authentication process with OAuth2 GSS-API mechanism

69 B. Authentication Process Illustration

Figure B.2: IdP selection in authentication process with OAuth2 GSS- API mechanism

Figure B.3: Authentication to Google in authentication process with OAuth2 GSS-API mechanism

70 B. Authentication Process Illustration

Figure B.4: Consent screen in authentication process with OAuth2 GSS-API mechanism

Figure B.5: Successful access to remote machine in authentication process with OAuth2 GSS-API mechanism

71 B. Authentication Process Illustration B.2 OIDC GSS-API Mechanism

Figure B.6: Initial state in authentication process with OIDC GSS-API mechanism

72 B. Authentication Process Illustration

Figure B.7: IdP selection in authentication process with OIDC GSS-API mechanism

Figure B.8: Authentication to Google in authentication process with OIDC GSS-API mechanism

73 B. Authentication Process Illustration

Figure B.9: Authorization consent in authentication process with OIDC GSS-API mechanism

Figure B.10: Successful access to remote machine in authentication process with OIDC GSS-API mechanism

74 B. Authentication Process Illustration B.3 Device Code PAM

Figure B.11: Initial state in authentication process with Device code PAM

75 B. Authentication Process Illustration

Figure B.12: Verification prompt in authentication process with Device code PAM

Figure B.13: IdP selection in authentication process with Device code PAM

76 B. Authentication Process Illustration

Figure B.14: Authentication to Google state in authentication process with Device code PAM

Figure B.15: Authorization consent in authentication process with Device code PAM

77 B. Authentication Process Illustration

Figure B.16: Successful client authorization in authentication process with Device code PAM

Figure B.17: Successful access to remote machine in authentication process with Device code PAM