Vishal Goenka INTERNET DRAFT Novell, Inc. Category: Experimental March, 2000 Expires: September, 2000 Architecture for Implementing Network Single Sign-On 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]