Internet DRAFT - draft-goenka-single-sign-on-arch
draft-goenka-single-sign-on-arch
Vishal Goenka
INTERNET DRAFT Novell, Inc.
Category: Experimental March, 2000
Expires: September, 2000
Architecture for Implementing Network Single Sign-On
<draft-goenka-single-sign-on-arch-00.txt>
1 Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2 Abstract
There are several different single sign-on (SSO) solutions offered
by various software vendors today. All such solutions require
applications to be written to a vendor specific API. In view of a
lack of industry wide standard for SSO APIs, application
developers find it almost impossible to SSO enable their
applications to work with any vendor solution. This document
presents alternative SSO implementation architecture that allows
applications to be transparently enabled for SSO. Further, it
allows different SSO solutions to interoperate with relatively
little effort.
3 Table of Contents
1 Status of this Memo..............................................1
2 Abstract.........................................................1
3 Table of Contents................................................1
Goenka Experimental - Expires September 2000 [Page 1]
Network Single Sign-On Architecture March 2000
4 Conventions used in this document................................2
5 Introduction.....................................................2
6 Overview of SSO Mechanisms.......................................3
6.1 Secret Credential Store.......................................3
6.2 Kerberos......................................................4
6.3 NetWare Authentication........................................4
6.4 DCE Security..................................................4
6.5 X509 Authentication Framework.................................5
6.6 Pluggable Authentication Module (PAM).........................5
7 Architecture Overview............................................5
8 SSO Enabled Transport Interface..................................8
9 Protocol Interceptor Module (PIM)................................9
10 Security Policy Database (SPD)................................10
11 Single Sign-On Mechanism Layer................................10
12 Security Considerations.......................................11
13 Conclusion....................................................12
14 Future Considerations.........................................12
15 References....................................................12
16 Acknowledgments...............................................13
17 Author's Addresses............................................13
4 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC-2119 [2].
5 Introduction
Single sign-on (SSO) is an authentication solution used to
transparently authenticate a security principal (typically, a
user) to various network services in a security domain without
requiring the principal to explicitly supply his or her
credentials for each service, as long as the principal is
authenticated to an authentication server in the domain. Besides
providing a friendly user experience, various SSO technologies
provide additional security characteristics for authentication to
network services in an enterprise. Several SSO technologies are in
deployment today, but unfortunately each of the technologies is
implemented by intrusively changing the client software used to
access the network service and in some cases the service itself.
The next section presents a brief overview of the most popular SSO
mechanisms.
A typical client workstation has several different implementations
of a given application layer protocol from different vendors. For
Goenka Experimental - Expires September 2000 [Page 2]
Network Single Sign-On Architecture March 2000
example, there are often more than one web-browser software suite
installed on a client workstation, and each of these suites
generally have their own protocol stack for HTTP, FTP, LDAP, IMAP,
POP, NNTP, etc. In general, for many protocol stacks, there are
often more than one application installed on the user's machine.
In an SSO environment, it should not matter which FTP client is
used to access a particular FTP server in a security domain, as
long as the user is authenticated to the domain authentication
server. The user should be authenticated to the FTP server
transparently, i.e., without being prompted for password. The same
holds true for other services such as World Wide Web (HTTP), news
(NNTP), email (IMAP, POP), remote access (Telnet), print services
(IPP), file services (NFS, WebDAV), directory services (LDAP),
etc. It is not practical to distribute a special SSO-enabled
client for each application protocol, which unfortunately, is the
current implementation approach for most SSO mechanisms, including
Kerberos, DCE, SSL, etc.
This document doesn't propose a new mechanism or API for SSO, but
suggests an implementation architecture that allows transparently
enabling new and existing services for SSO. An ideal solution
would be to have each application vendor write to a common
authentication API such as GSSAPI or PAM APIs, and implement
specific modules for SSO using different heterogeneous
authentication technologies. In the absence of an industry wide
consensus on such a usage, this document presents alternative
architecture for implementing SSO that can co-exist with both SSO
aware and unaware applications.
6 Overview of SSO Mechanisms
6.1 Secret Credential Store
The simplest SSO technology entails securely storing user's
authentication credentials (such as private keys or passwords) for
different network services for each security domain, in a secure
database that is accessible to the user only after successful
authentication to the corresponding domain's authentication
server. When accessing a network service, the client software
makes invocations to a vendor provided library that securely
retrieves the user's credentials from the secure database, using
which, the client software then authenticates to the network
service. The vendor library provides additional interfaces to seed
the secret credential store with the user's credentials for each
network service for the first time. Synchronization of user's
credentials between the network service and secret credential
store is an issue with this approach, and the user is typically
required to change it in both places. The advantage of this scheme
Goenka Experimental - Expires September 2000 [Page 3]
Network Single Sign-On Architecture March 2000
is that it works with most services and requires no change to the
server component of the service.
6.2 Kerberos
Kerberos [3] is a network authentication protocol based on work by
Needham and Schroeder and developed originally at MIT. Kerberos
provides SSO to any network service that is kerberized and shares
a trust relation with the Kerberos authentication server, known as
the Ticket Granting Server (TGS). The user is required to
authenticate to TGS, which results in a Ticket Granting Ticket
(TGT). The TGT serves as an authentication token that the client
software uses on user's behalf to obtain service tickets from the
TGS. The service ticket identifies and authenticates the user to
the network service. Kerberos provides many other security
services including message protection (integrity,
confidentiality), delegation of credentials, single-point user
account management for various network services, etc. Kerberos
deployment, however, requires both the network client and server
software to make function invocations into a vendor provided
Kerberos library. This requires code changes to existing software
and has impeded its mass deployment.
6.3 NetWare Authentication
NetWare authentication (version 4 and beyond) is tightly
integrated with Novell Directory Service (NDS), which acts as the
authentication server. First, the NetWare client authenticates to
a particular NDS tree based on the user's password using a
challenge-response technique. Upon successful authentication, the
client retrieves the user's RSA private key from NDS, which is
then used to construct a short-term credential consisting of a
Gillou-Quisquater (GQ) key pair. The GQ key pair acts like an
ephemeral SSO credential (much like the TGT in Kerberos), and is
used to subsequently authenticate to various servers that are part
of the same NDS tree. The GQ key-pair is managed on the user's
behalf by the NetWare client library, which exposes specialized
APIs for application developers to write to, in order to make use
of the SSO credentials to access NetWare servers.
6.4 DCE Security
DCE stands for Distributed Computing Environment. It is an OSF
(Open Software Foundation) product and is conceptually similar to
Kerberos. It even uses Kerberos V5 as one of its components. DCE
deployment also requires both the network client and server
software to make function invocations into a vendor provided DCE
security library.
Goenka Experimental - Expires September 2000 [Page 4]
Network Single Sign-On Architecture March 2000
6.5 X509 Authentication Framework
In its simplest form, the user unlocks his or her private key from
a secure storage on the local machine and the authentication
library uses the private key to sign an authentication token. The
signed authentication token is sent to the server along with the
client certificate (and optionally a chain of CA certificates) as
part of authentication exchange. The server uses the client
certificate to validate the authenticator and the chain of CA
certificates to validate the client certificate. It then maps the
client certificate to a valid user in the system. The client
application is often written to an authentication library, which
manages user's private key in coordination with the application.
Some authentication libraries support smart-card support to avoid
storing user's private key locally on disk. Other variants store
the private key on a secure server and use a challenge-response
authenticated mechanism based on a password to securely retrieve
the private key from the server. SSL/TLS use X509 Certificate
based authentication.
6.6 Pluggable Authentication Module (PAM)
PAM provides standard authentication APIs that applications need
to write to in order that different authentication modules
(including Kerberos, DCE, NetWare, X509, etc.) can be
transparently integrated to provide SSO.
7 Architecture Overview
This document presents a high level view of the implementation
architecture.
In order for various independently developed application protocol
stacks to share a common security session, the security session
should be built at a layer lower than the application layer in the
OSI protocol stack. TLS and IPSec follow the same principle, but
they are different in important ways. IPSec provides a node-to-
node level authentication (and message protection) but it doesn't
have a user context associated with it. TLS can be used for user
authentication and SSO, but it cannot associate a user context
without the active participation of the application itself. This
requires the application to be written to the TLS APIs. Besides,
it is just one of the numerous SSO mechanisms and it doesn't
interoperate with non-TLS servers, such as those that use DCE,
OTP, or plain-text passwords for authentication.
Goenka Experimental - Expires September 2000 [Page 5]
Network Single Sign-On Architecture March 2000
The goal of this architecture is to transparently enable SSO for
services without changing the services themselves including a
support for various combinations of authentication mechanisms.
The shared security layer is built between the transport layer and
the application layer by either replacing the implementation of
transport interface (BSD Sockets, WinSock, TLI or equivalent) on
the host operating system, or plugging-in a transport provider, if
the host operating system allows it, e.g., Winsock layered service
provider for Microsoft Windows suite of Operating Systems. The
original APIs are preserved, so that applications using it are not
affected beyond loading a different library. We shall refer to the
new transport layer implementation as the SSO enabled Transport
Interface (SSOTI). In addition to SSOTI, a Protocol Interceptor
Module (PIM) is implemented for each of the application layer
protocols such as FTP, HTTP, NNTP, IMAP, POP, LDAP, etc. The PIM
for a given protocol intercepts the client-server exchanges for
that protocol (based on configured host and port numbers) and
injects authentication and security layer information at
appropriate time during the protocol. This allows authentication
and other security (message protection) semantics to be preserved
for each application protocol. In addition, the user context
information is also available to the PIM since the application
passes it along during an authentication attempt. A security
policy database (SPD) is consulted to lookup the host and port for
which SSO is to be enabled, the SSO mechanism to be used and other
configuration parameters specific to the SSO mechanism. The
initial authentication to the authentication server for each
security domain is carried out during the user login sequence to
the workstation by integrating with the host operating system via
PAM for Solaris, GINA for Windows NT and Windows 2000, etc.
Alternatively, the SSOTI layer can initiate "late" authentication
to the domain authentication server, during an authentication
attempt for a given application within the domain. The security
policy database is retrieved from a secure server using a standard
protocol (such as LDAP) after server authentication.
The following figure illustrates a typical architecture for
implementing SSO where the application makes explicit calls into a
vendor specific SSO library. Each application protocol may
potentially have a different library to call into, and they are
all independent of each other. Most SSO mechanisms including TLS,
Kerberos, DCE and NetWare Authentication use this model.
Goenka Experimental - Expires September 2000 [Page 6]
Network Single Sign-On Architecture March 2000
+-----------------------------------+
| Application Protocol Stack |
| (HTTP, FTP, IMAP, etc.) |
+----------------+-----------+------+
| |
| +-------+--------------+
| | SSO Mechanism Layer |
| +-------+--------------+
| |
+---------------+-----------+-----+
| Transport Interface |
|(BSD Sockets, Winsock, TLI, etc.)|
+---------------+-----------------+
|
+--------+--------+
| Transport Layer |
| (TCP, UDP) |
+--------+--------+
|
+-------+-------+
| Network Layer |
| (IP, IPX) |
+---------------+
The proposed architecture uses protocol interceptor modules and
various SSO mechanism modules underneath the transport interface.
A security policy database is used to map the application protocol
to the SSO mechanism based on configurable selectors, such as
hostname, port number, user identity, etc.
Goenka Experimental - Expires September 2000 [Page 7]
Network Single Sign-On Architecture March 2000
+-----------------------------------+ +--------------+
| Application Protocol Stack | | Initial |
| (HTTP, FTP, IMAP, etc.) | |Authentication+-+
| | | Module | |
+----------------+------------------+ +------+-------+ |
| | |
+---------------+-----------------+ | |
| SSO Enabled Transport Interface | | |
|(BSD Sockets, Winsock, TLI, etc.)+-----+ | |
+---------------+-----------------+ | | |
| | | |
+---------------+--------------+ +----+---+------+ |
|Protocol Interceptor Modules | |Security Policy| |
| (HTTP, FTP, IMAP, etc.) +---+ Database | |
| | +---------------+ |
+---------------+---------+----+ +---------+
| | |
| +------+-----------------+---------+
| |Single Sign-On Mechanism Layer |
| |(Secret Credential Store, Kerberos|
| | TLS, DCE, etc.) |
| +--+-------------------------------+
| |
+--------+-----+--+
| Transport Layer |
| (TCP, UDP) |
+--------+--------+
|
+-------+-------+
| Network Layer |
| (IP, IPX) |
+---------------+
8 SSO Enabled Transport Interface (SSOTI)
The SSOTI is an implementation of the usual transport interface
(BSD Sockets, Winsock, TLI, IPX Socket, etc.) that redirects all
traffic meant for a certain set of host, port and possibly other
selectors, to a PIM as specified by the SPD. For example, all
traffic to hosts in a given subnet on port 143 can be redirected
to an IMAP PIM, and all traffic on port 21 can be redirected to an
FTP PIM. This is transparent to the application on both the client
and the server side. The SPD may indicate that traffic to certain
hosts or ports should be bypassed from any PIM. This is important
if the application uses its own security module such as SSL or
Kerberos. In some cases, like HTTP over SSL or LDAP over SSL, the
Goenka Experimental - Expires September 2000 [Page 8]
Network Single Sign-On Architecture March 2000
application uses different ports for secure and insecure
communication, which makes it easier to differentiate such
traffic. The use of security modules directly by the application
may not take advantage of the SSO capability provided by the
SSOTI, since the security session is not shared. For instance, the
user's private key to be used for SSL client authentication may
not be accessible to the application, if the SSO Mechanism Layer
obtained the user's private key securely from an authentication
server during the initial user login sequence. Such situations can
be managed by tricking the client application to think that it is
communicating over an insecure port, and transparently provide
security below the SSOTI layer.
9 Protocol Interceptor Module (PIM)
A PIM is written for each application protocol and allows
customized handling of the protocol's authentication and security
requirements. For example, an IMAP PIM observes the IMAP exchanges
between the client and the server and maintains the client
authentication state. Any simple authentication attempt by the
client is intercepted and replaced with a policy configured
authentication protocol. If the SPD indicates that Kerberos V5
should be used for authentication as well as message integrity
protection, the IMAP PIM calls into the Kerberos library and
requests a ticket to the IMAP server. Assuming that the client was
authenticated to the Kerberos Authentication Server (the Ticket
Granting Server) during initial login, a service ticket to the
IMAP server is obtained from the TGS and used for authentication.
All future IMAP messages sent by the client application are
integrity protected by the IMAP PIM before sending if off. On the
server side, if the IMAP server is kerberized, the IMAP PIM is
bypassed, so that the client IMAP PIM interacts directly with the
kerberized IMAP server. If the IMAP server was setup to use
username and password for authentication, as indicated by the SPD,
the client IMAP PIM would retrieve user's username and password
from a configured Secure Credential Store, and include them as
part of the Kerberos Authenticator. The IMAP PIM on the server
side would verify the Kerberos Authenticator, extract the username
and password from the authenticator, and pass it up to the IMAP
server. The IMAP server would use the username-password for
authentication, without even being aware of Kerberos happening
underneath.
The PIM approach requires that only one custom module be written
for each application protocol to SSO enable all applications using
that particular protocol. A PIM for FTP, SSO enables all the
various FTP clients on the machine in a transparent manner. Some
application clients may prompt the user for username and password,
Goenka Experimental - Expires September 2000 [Page 9]
Network Single Sign-On Architecture March 2000
even before passing it down to the transport layer. While this is
unnecessary in our model, it doesn't hurt. Even if the user
entered an incorrect password or simply skipped the prompt, a
policy-configured SSO would automatically be done by the PIM.
10 Security Policy Database (SPD)
The Security Policy Database controls configuration information
vital for deciding if a particular communication channel should be
intercepted or bypassed. It indicates the security domain to which
a particular host belongs, and the mapping between ports and
application protocols. The SPD may contain policy rules that
indicate a set of selectors for deciding the security
characteristics to be applied to a particular connection. The
security characteristics may include the SSO mechanism to be used,
associated security parameters such as message protection
preference, security protocol specific settings, etc. The current
architecture makes no assumption about the representation of the
policy rules or their description language. It is desirable to
maintain such security policies centrally for ease of management,
and have the client retrieve the policy from a secure server
during client initialization. The policy server MUST be
authenticated before downloading the policy. Client
implementations MAY poll the policy server for periodic policy
updates. Although LDAP is a reasonable choice for hosting such
policy information, the architecture doesn't mandate it. The
details of policy database are beyond the scope of current
discussion. There are several internet-drafts including [4], [5]
and [6] that discuss various policy constructs, description
language and schema.
11 Single Sign-On Mechanism Layer
This layer may consist of as many authentication mechanisms as
desired. A GSSAPI based interface may be well suited to implement
various authentication mechanisms, including vendor specific
mechanisms for SSO. The SPD indicates which SSO mechanism should
be used when communicating with a particular service on a
particular host. The user's authentication credentials for various
mechanisms in different security domains are maintained at this
layer. This might include the Kerberos credential cache, User's
private key for Certificate based authentication, etc. This layer
allows creating cross-technology authentication bridges, such as
mapping a Kerberos principal to an X509 certificate and
corresponding private key stored in a secure credential store, and
using the certificate for transparent SSL client authentication.
The initial authentication to the domain authentication server
Goenka Experimental - Expires September 2000 [Page 10]
Network Single Sign-On Architecture March 2000
should be carried out during user login to the system, although
"late" authentication can be carried out on demand as well. For
example, if the user chooses to skip authentication to a certain
security domain during initial system login, any attempt to access
a service within that security domain should require the user to
supply the authentication credentials. These credentials can then
be used to authenticate to the domain authentication server first,
and then retrieve SSO credentials required for authenticating to
the required service.
The discussion so far assumes a single user environment, which is
true for most workstation scenarios. In a single user environment,
it is easy to associate the user context with any network request.
Multi-user environments have always posed a challenging
requirement on lower layer security implementations such as TLS or
IPSec, since the user context is not available to them. This is
where the PIM approach has an advantage over others. Application
protocols usually send across the user identification information
in some form. For example, FTP sends a command that looks like
'USER vgoenka', LDAP sends the DN of the object to bind as, IMAP
default authentication sends the username and password in the
clear in a command that looks like 'a001 LOGIN vgoenka password',
and so on. The user context is passed along by the application
during an authentication attempt. By intercepting the default
authentication attempt by the application, the PIM can get useful
user context information, so that multiple user security contexts
can be maintained in the security layer. The SPD can be modifiable
by the user to associate multiple user ids with the same network
principal, if the same user has different identities on different
network services.
12 Security Considerations
The SSO mechanisms used in the SSO mechanism layer may each have
security issues, which are beyond the scope of this document.
The security policy database forms a key security component in
this architecture, and should be stored at a secure central
location for ease of management. Each client and server in the
security domain should authenticate the SPD server before
downloading the SPD. SPDs can be hosted on LDAP servers and
accessed over SSL/TLS. This requires additional management of
trusted root certificates that the client and server machines
should be configured with, in order to authenticate the SPD
server.
Transparent access to user's SSO credentials also implies that
malicious software (e.g., viruses) executing on the user's behalf
Goenka Experimental - Expires September 2000 [Page 11]
Network Single Sign-On Architecture March 2000
can easily access all user's resources on the network. Although
this makes it slightly easier for system crackers to write such
malicious code, it doesn't introduce any additional security
weakness that does not exist in the currently deployed SSO
solutions. However, by concentrating all the SSO mechanisms at a
common layer, this architecture allows for better security
vigilance and policy enforcement. For example, to allow detection
of security compromise attempts, the SSOTI implementations MAY
allow querying for the existing security associations and
configuration of security audit logs. User level tools can then be
invoked to monitor the usage of various SSO-enabled network
services.
13 Conclusion
This document illustrates that popular SSO implementations require
applications to be written to a vendor or mechanism specific API,
which makes it difficult to enable many applications for SSO. An
architecture that can transparently enable applications for SSO
and also make it possible to provide cross-technology SSO bridges
is then presented as a solution.
14 Future Considerations
It is hoped that the architecture will be refined as it is
reviewed by members of the Internet community, and will lead to a
consistent framework for development of network single sign-on
across different OS platforms.
15 References
1 Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 John Kohl and B. Clifford Neuman. "The Kerberos Network
Authentication Service (Version 5)", RFC-1510, September 1993
4 M. Condell, C. Lynn and J. Zao, "Security Policy Specification
Language", Internet draft, draft-ietf-ipsec-spsl-01.txt, July
1, 1999
5 L. A. Sanchez and M. N. Condell, "Security Policy System",
Internet draft, draft-ietf-ipsec-sps-00.txt, November 18, 1998
Goenka Experimental - Expires September 2000 [Page 12]
Network Single Sign-On Architecture March 2000
6 Jamie Jason and Michael Jeronimo, "Ipsec Policy Schema",
Internet draft, draft-ietf-ipsec-policy-schema-00.txt, March
24, 1999
16 Acknowledgments
The author thanks Frederick Zarndt, Jan Nielsen, John Michener and
Robert Wille and for their critical review of this work.
17 Author's Addresses
Vishal Goenka
Novell, Inc.
350 South 200 West #506
Salt Lake City, UT 84101
USA
Phone: 1-801-257 4247
Email: vgoenka@bigfoot.com
Goenka Experimental - Expires September 2000 [Page 13]
Network Single Sign-On Architecture March 2000
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
Goenka Experimental - Expires September 2000 [Page 14]
