Security -- Secure Desktop Access to Remote Resources

Mary R. Thompson^2^ , Gregor von Laszewski^1^, Doug Engert^1^,

Keith Jackson^2^, Srilekha S. Mudumbai^2^ and Thomasz Haupt^3^

Draft: November 1998, comments: gregor@mcs.anl.gov

*^1^*Argonne National Laboratory, Argonne, IL 60439

*^2^*Lawrence Berkeley National Laboratory, Berkeley, CA 94720

^3^Syracuse University, Syracuse, N.Y. 40319

**Abstract**

This document is based on discussions of the security-working group at
the "First Workshop for Desktop Access to Remote Resources" and follow
up meetings The working group concentrated on the issues related to
providing services that enable *secure* desktop access to remote
resources. We identified specific requirements based on the unique
distributed environment. This paper presents the security issues and
requirements that the group identified and presents a brief survey of
existing technology that may help provide solutions.

# Introduction

Today's computing infrastructure encompasses a large variety of
different hardware and software components. The typical user has
difficulties mastering the various interfaces to the heterogeneous
resources. Thus, it is desirable to develop a framework that simplifies
the access to remote resources. Formally, an architecture should be
defined to allow the integration of many different services accessing
these resources. An important step in this direction is to identify base
requirements for secure remote access in order to build a common
extensible API. This API in turn will enable the building of
sophisticated and reusable tools around the services. The workshop
attendees identified a potential list of such services.

## Goals

The ongoing goal of this working group is to specify the services
necessary to provide secure desktop access to remote resources. These
services must support large-scale distributed applications. Such
applications have unique requirements that provide a significant
challenge. The design of the services should be open and expandable to
encompass the diverse security infrastructure in place at different
sites. Security services include authentication, access control, message
integrity and confidentiality.

## Problem Scope

We intend to provide remote access to a large range of resources
including:

-   compute resources (PC's, workstations, networks of workstations,
    supercomputers, and metacomputers),

```{=html}
<!-- -->
```
-   data resources (distributed databases, directories, data services),
    and

```{=html}
<!-- -->
```
-   compute services (specialized problem solving and visualization
    environments).

A *remote* resource is defined as one that is either physically or
logically separated from the user.

Examples of environments using remote resources are large-scale
distributed computing environments, on-line instruments and mass storage
systems. We start the paper by identifying some unique characteristics
and requirements of environments utilizing remote resources with respect
to the security infrastructure.

## Restrictions

Since resource policies are often already in place at many sites, the
security services should be designed to allow easy integration of
various security policies and methods. Attempts to change already
established resource policies are beyond the scope of this effort.
Nevertheless, recommendations to sites that do not have rigid
remote-access policies are available; for example Globus for
authentication and Akenti for access control. We are also not addressing
issues of software or hardware licensing in this research effort.

# Security Aspects

## Common security aspects 

Basic security services, as depicted in Figure 1, must be part of the
infrastructure. The "*Authentication Service*" authenticates a user to
the system. The "*Access Control Service*" compares this authenticated
identity with the set of requirements for the resource, to determine
access to the resource. **"***Data or Message Integrity Services***"**
are used to verify that data has not been changed accidentally or
maliciously during message transmission. This can be accomplished by,
for example, including a message hash with the data. A "*Data or Message
Confidentiality Service*" ensures that no one other than the intended
recipient can read the data. Normally this is accomplished by encrypting
the data.

We have also identified a number of common high level tasks relating to
security, which must be supported within the framework. For the user it
is important to be able to authenticate to the system, hopefully with a
*single sign on service*. The owners of the resources are mainly
concerned with controlling access to their resources. Both user and
resource owners have significant interest in exchanging data between
resources over a secure link. In many cases it is necessary to restrict
the ability of a users program on a remote machine to access a subset of
available services. It must be possible for the resource owner to define
such access restrictions.

![](media/image1.wmf)

Figure 1: Security abstractions for a desktop access to remote
resources.

## Security aspects specific to large-scale distributed computing environments

While the services and requirements listed in the previous section are
also common to traditional compute systems, we would like to focus in
the following sections on the characteristics of a large-scale
distributed environment. These characteristics include:

-   a large and dynamic user population,

-   a large and dynamic pool of resources,

```{=html}
<!-- -->
```
-   a dynamic need for resources by the users,

```{=html}
<!-- -->
```
-   various communication protocols between the communicating processes,

```{=html}
<!-- -->
```
-   various security models on different sites, e.g. Kerberos and public
    key infrastructure (PKI),

```{=html}
<!-- -->
```
-   different security domains within a security mode. E.g. different
    cells for Kerberos, different realms for DCE and different
    Certificate Authorities (CAs) for PKI,

```{=html}
<!-- -->
```
-   different identifications (accounts) for users on different systems,

```{=html}
<!-- -->
```
-   export restrictions on security codes .

During our discussions we identified examples that illustrate some
problems related to security in large-scale distributed computing
environments. These observations/examples influence the design of the
security services.

We noticed that the security policies are often complicated and site or
resource specific. In addition, sites might have strict and inflexible
security policies. At times it is not allowed to transfer data from one
domain to another domain because either the policy does not allow it or
technology does not exist (e.g. no common encryption methods). Secure
sites sometimes let data get in, but not out, thus making it difficult
to return results to the desktop. To define security policies we need a
mechanism to describe who trusts whom and which resources should be
protected.

## Security aspects specific to the user community

The user community must be strongly considered when designing a security
infrastructure. Many users are unwilling to deal with obtrusive security
procedures, but at the same time expect a reasonable level of security.
Hence, it is of utmost importance to present the security mechanisms to
the users in an easy and mostly transparent way. A minimum level of
understanding by users is necessary, so that they can specify their own
security requirements and understand what security guarantees or risks
the resource sites are providing. Thus, it is necessary that part of the
infrastructure for providing a secure desktop access must be an
*educational service* providing the necessary explanations and guidance
to develop and use programs to enable the necessary secure service. Part
of this educational service should be a self-guided help service
allowing the user to obtain information about the security policies and
mechanisms.

An important feature in simplifying the user access is hiding different
security authentication mechanisms behind a uniform interface. An
example of such a service is the previously mentioned *single sign-on*
to a combination of resources.

# Requirements

The security requirements of users and resource providers are, quite
naturally, different from one another. Sometimes these requirements are
motivated by conflicting goals and can oppose each other. Hence, it is
not easy to determine a priori a solution to satisfy the different goals
and requirements.

Thus, we analyze in this section the basic security requirements in more
detail (authentication, access control, message integrity and
administrative requirements).

##  {#section .unnumbered}

## Authentication Requirements

We identified the following issues applying to authentication:

-   The resource provider/server requires that users be authenticated.

```{=html}
<!-- -->
```
-   Users desire easy authentication to servers.

```{=html}
<!-- -->
```
-   Users only want to authenticate once. But it may be necessary to be
    authenticated to several different domains and for a long period of
    time. These problems can be addressed by a delegation of your
    identity to a proxy.

```{=html}
<!-- -->
```
-   Users require that servers be authenticated (the user want to get
    access to a trusted resource).

```{=html}
<!-- -->
```
-   Collaborating users require that their peers be authenticated.

```{=html}
<!-- -->
```
-   Collaborating servers may require the peer servers to be
    authenticated.

## Access Control Requirements

The access control service needs to provide the following services:

-   The resource owners (stakeholders) need to be able to easily define
    the access control requirements (Use conditions).

```{=html}
<!-- -->
```
-   Stakeholders need a service to easily see what constraints are in
    place for a given resource.

```{=html}
<!-- -->
```
-   The resource servers need to be able to enforce the stakeholders use
    conditions, thus if the use conditions are distributed, the server
    must be able to find them reliably.

```{=html}
<!-- -->
```
-   The users need a service that will preview a computation, report
    whether it will succeed or fail, and if it will fail, inform the
    user what credentials he is missing.

## Message integrity and confidentiality (*Datatransfer)* Requirements

Message transfer services need to address the following issues regarding
message integrity and confidentiality:

-   The user needs to specify the level of integrity and confidentiality
    for data transfer.

```{=html}
<!-- -->
```
-   Data stakeholders need to specify the level of integrity and
    confidentiality required for the data to be included in a message.
    In practice this may only be possible by means of restricting data
    access to users that he trusts to be careful of his data.

```{=html}
<!-- -->
```
-   Both users and servers need a service, which can answer the
    questions :

```{=html}
<!-- -->
```
-   Can data transferred from here to there without violating security?

```{=html}
<!-- -->
```
-   Can I send secure messages? (This includes if it is technically or
    politically possible.)

```{=html}
<!-- -->
```
-   Servers need to be able to move processes (=data) from one machine
    to another in secure fashion .

```{=html}
<!-- -->
```
-   Signed code (applets and programs) needs to be supported.

## Administration requirements

We identified the following requirements unique to the administration of
a secure environment:

-   Stakeholders need a simple GUI to create and impose use conditions
    on their remote resources .

```{=html}
<!-- -->
```
-   Stakeholders and resource server administrators need a service,
    which gives a list of users who have access to the resource.

```{=html}
<!-- -->
```
-   A simple interface and policy for adding new users to the
    distributed environment is required.

## Recommendations

The working group came up the following general recommendations for the
security aspects of the API for desktop access to remote resources:

-   Recognize that heterogeneous security environments will have to
    coexist.

```{=html}
<!-- -->
```
-   Suggest that we specify high-level security requirements that can be
    mapped onto existing environments.

```{=html}
<!-- -->
```
-   Develop tools that will allow specification of security policies in
    an easy fashion.

```{=html}
<!-- -->
```
-   Check security requirements as part of resource discovery.

```{=html}
<!-- -->
```
-   Utilize existing technologies (as in section 4) as much as possible.

# Technology Evaluation

## Java

*Java* JDK1.2 defines an extensive API for encryption, digest and
signature of messages. It also defines a key and certificate management
API and an access control policy API. This API is designed to allow for
different implementations of the defined classes (i.e. by different
"providers"). The main purpose of the Java Security model is to allow
the secure and trusted execution of Java applications and applets that
may have been loaded dynamically from remote hosts. JDK 1.2 extended the
restricted execution environment (sandbox) provided by browsers for
applets to Java applications. If a security manager is specified when
running an application, it will intercept a large number of execution
steps, such as file read/write and inter-process communication, and
check against a policy file to see if the action is allowed.

The policy file can be either system wide (from the JavaHome area) or
specific to user who is executing the code. It specifies the allowed
actions, e.g. write to files in a given directory, allowed for code
signed by a specified user and/or loaded from a specified URL. The code
to be executed should be in a signed jar file. Java provides interfaces
for signing files, and managing the certificates and keys on both the
code sending and receiving sites. Since there is considerable
flexibility in the policy files (one per system or one per user), wild
carding allowed for users and originating locations and resources
accessed, it should be possible to conveniently control the execution of
imported Java code. It is harder to apply these mechanisms to the case
where a remote user contacts a server running on the host machine and
requests access to resources. It might be possible for the server to
spawn a child application that appeared to come from the user, just as
server sometimes change their userids to run with the restrictions of
remote user.

Java also lets you write you own Security manager class which might
allow a more resource centric view of access control.

The fact that JDK1.2 has specified a full suite of security interfaces
and that there are several providers of these classes, including the
iSaSiLk package from the University of Graz, makes writing secure code
in Java much easier than it was a few months ago.

## Browsers

The browsers will let a user request a personal certificate, save it in
his browser database and export it as a pk12 standard format file. With
the proper security preferences set, a user need only type a passphrase
once per Netscape session to effect a one-time login to any web-server
that requires an X.509 certificate. Browsers allow a user to manage
several certificates and chose the one to use for each secure
connection.

The browsers recognize signed applets and allow those applets more
privileges than unsigned ones. The browser will tell the user who signed
the applet and ask for permission before executing otherwise forbidden
operations.

Both Netscape and IE browsers provide PKI key management, client
authentication and restricted execution of Java applet code. At the
moment there are incompatibilities between IE and Netscape that can be
overcome with a number of tricks. One serious failing of IE on Windows
is that it puts private keys in the registry by default where any user
of the machine can access them. It is possible for a knowledgeable user
to restrict an identity to just one user.

## SSH - Secure Shell

This is a set of programs available as free-ware on Unix platforms and
as inexpensive (about \$50) software products for Windows and MacOS. Its
primary function is to replace the Unix telnet, rlogin, and rcp commands
with ones in which any data transmitted across the network is encrypted.
Since the current major cause of breakins has been passwords sniffed off
the Internet, this software has been adopted by many sites as the only
way to obtain remote access to their machines. SSH does its own key
generation and management, keeping keys in a \"known\" directory (on
Unix \$HOME/.ssh and/or /etc/ssh\_\_known_hosts. The keys can be
associated with machines or users. The trust relations are between
machines or users. Just like in rlogin, a user must have access to an
account on the remote machine. If a user/machine\'s public key is
installed on a remote machine, the login process becomes more automatic.
But even in the simplest case where the server runs the ssh daemon and
the client just runs the client, the logins are encrypted.

*SSH* provides a simple, effective and platform-independent way for
users to remotely login to server machines in a secure manner. It does
not attempt to interact with other key management systems. It only
provides a single login to multiple machines if the user ids on all the
machines are identical and the machines have been setup to trust the
client\'s machine.

## Globus

Globus provides a limited delegation of identity to proxy mechanism,
which facilitates a single login to be used for authentication to
multiple domains, and over an extended period of time. In addition, it
provides a mapping mechanism to go from a x.509 identity to local
account ids on server machines. Globus defines a Resource Definition
Language (RSL) and a discovery procedure, which may be extensible to
define and test security requirements. A GSS application implemented
over SSLeay is included in the distribution that can be used to
establish authenticated connections between clients and servers.

## Akenti

Akenti provides an access control mechanism based on signed
use-condition certificates and user attribute certificates all of which
may be stored remotely from the resources. It provides a policy engine
that the resource server can call to find and analyze all the remote
certificates. It also includes a GUI for creating the use and attribute
certificates.

## Condor

Provides requirements description language (Class ads) and a matching
engine that may be extensible for use in defining and matching security
requirements.

# Annotated References

## Books that contain introductory material

*Applied Cryptography*, Bruce Schneier, Second Ed. John Wiley & Sons,
Inc.1996

This is the current bible for people trying to implement or understand
implementations of cryptographic algorithms. However, its excellent
organization allows a novice to get a good introduction to the issues
and terms used in secure communications. Contains a section briefly
describing most of the current secure communication implementations,
including Kerberos, PKCS (RSA\'s public-key standards), PEM (Privacy
Enhanced Mail), and PGP (Pretty Good Privacy). It includes a
bibliography of 1653 entries, so whatever you don\'t find here, you will
find a reference to.

**Bruce Schneier Crypto Links**,
[http://www.counterpane.com](http://www.counterpane.com/),

"Collections of Links" contains a list of links to on-line security
sources. The \"Bibliographies\" links to annotated on-line
bibliographies and collections of papers.

*Web Security & Commerce*, Simon Garfinkel with Gene Spafford, O\'Reilly
& Associates, 1997

Contains chapters on Digital Certificates, cryptography basics, SSL and
TLS. A lot of the emphasis is on security and certificate management
through your Web browser and how to secure a Web server.

## Public Key References

**An Overview of the PKCS Standards**
<http://www.rsa.com/rsalabs/pubs/PKCS/>, Under Documents \" Section 2:
\"*Background information*\"

Includes definitions of public-private key cryptography, digital
signatures, message digests and secret key cryptography. Section 3
explains how to do digital signatures, digital enveloping, digital
certification and key exchange.

RSA Data Security, Inc. is the company that developed and patented the
Rivest, Shamir and Adleman public key encryption algorithm.

**IETF working group on Public-Key Infrastructure (X.509) (pkix***)*
<http://www.ietf.org/html.charters/pkix-charter.html>,

**Public Key Infrastructure PKIX Roadmap**

<http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-00.txt>,

This document is an overview of all the standards that this working
group is attempting to define. Section 2 gives an overview of the
terminology and section 3 gives a brief description of how PKI systems
are used to effect authentication, non-repudiation, and confidentiality.

## X.509 Identity Certificate references

X.509 is a standard for Identity Certificates, which are the documents
that a Certificate Authority (CA) issues. They basically contain the
name of the issuer (the CA), the Distinguished Name of the subject, a
validity period, the signature algorithm that is used and the public key
of the subject and the signature of the CA. There can be a bunch of
extensions as defined by version 3 (v3) of the standard. See
http://www-itg.lbl.gov/Akenti/docs/IdentityCert.html for an example of
an Identity Certificate issued by the Netscape CA.

*Internet X.509 Public Key Infrastructure Certificate and CRL Profile*.
R. Housley, W. Ford, W. Polk, D. Solo
<http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-11.txt>

Defines the X.509 v3 certificate and X.509 v2 CRL (Certificate
Revocation List)

## LDAP (Lightweight Directory Access Protocol)

An LDAP server is used as a Registration Agent (RA) by the Netscape CA.
All valid certificates are entered into an associated LDAP server, and
are removed when then are revoked. Thus one can check if a certificate
has been revoked by looking it up in the CA\'s LDAP server. If it is not
found, it is assumed to have been revoked.

*LDAP - Programming Directory-Enabled Application with Lightweight
Directory Access Protocol*, Timothy A. Howes, Mark C. Smith, McMillian
Technical Publishing, Indianapolis, In. 1997

Chapter 3 describes the LDAP models, i.e., what LPAP is used for. Most
of the rest of the book is on how to program to the LDAP API.

**University of Michigan\'s LDAP documentation page**,
<http://www.umich.edu/~dirsvcs/ldap/doc/>:

From here you can link to RFC-1777 Lightweight Directory Access Protocol
<http://www.umich.edu/~dirsvcs/ldap/doc/rfc/rfc1777.txt> along with a
lot of related RFC\'s. There are also links to some papers about the
University of Michigan implementation of the LDAP protocol.

## SSL protocol

Netscape defined the Secure Socket Layer protocol as an open standard.
It has now been submitted to the IETF as an Internet draft. It runs on
top of the TCP protocol and implements a secure handshake protocol which
passes Identity certificates from the server to the client, and
optionally from the client to the server. It uses the public keys to
create a symmetric session key that is used to encrypt subsequent
messages over the TCP socket. It can use a variety of both public and
private key encryption algorithms.

**Netscape version of the protocol**
<http://www.netscape.com/newsref/std/SSL.html>

**The IETF Transport Layer Security working group page**
<http://www.ietf.org/html.charters/tls-charter.html>

(TLS is the IETF name for the SSL protocol

**The IETF Internet draft of the protocol**
<http://www.ietf.org/internet-drafts/draft-ietf-tls-protocol>

SSLeay <http://www.psy.uq.oz.au/~ftp/Crypto>

Download site for the freeware implementation of SSL by Eric Young

## Kerberos

Kerberos is an authentication service developed at MIT for project
Athena. Kerberos is a trusted third party, which will provide an
identity token with a limited lifetime to a user who it knows and who
provides the correct password. This identity token is often used by AFS
or DFS file systems to provide access to files.

*"*Kerberos: An Authentication Service for Computer Networks*"*, B.C.
Neuman and T. Ts'o *IEEE Communications Magazine*, v.32, n.9, Sep 1994,
pp. 33-38. Also available from
<http://nii.isi.edu/publications/kerberos-neuman-tso.html>

According to Bruce Schneier (see ref 1) \"This is the best overview of
Kerberos"

MIT's Kerberos Web page <http://web.mit.edu/kerberos/www/papers.html>

## Security for the Computational Grid

"A Security Architecture for Computational Grids", I. Foster, C.
Kesselman, G. Tsudik, and S. Tuecke. Fifth ACM Conference on Computer
and Communications Security, 1998.

This paper analyses the security requirements of large scale distributed
(grid) computing and develops a security policy and a corresponding
--architecture. It is used within the Globus metacomputing toolkit.