Authentication Protocols and Standards

Some of most popular authentication protocols and standards are:

· KERBEROS v5:

Kerberos is an open standard for distributed systems authentication (RFC 1510). It relies on shared secret (or password) authentication by users to an authentication server called a Key Distribution Center (KDC). The KDC grants users access to applications, optional delegation of access from an application service to another service, and optional inter-domain trusts between groups of KDCs. In Windows servers and clients running Microsoft Windows 2000 Server or later, the Kerberos version 5 authentication protocol is the basis of authentication to Active Directory. It has an extension (PKINIT) to support smart card logon. It is also integrated into SMB, HTTP, and RPC, as well as the client and server applications that use these protocols.

· NTLM:

Windows NT Challenge/Response (NTLM) is the authentication protocol used on networks that include systems running the Windows NT operating system and on stand-alone systems. NTLM stands for Windows NT LAN Manager, a name chosen to distinguish this more advanced challenge/response-based protocol from its weaker predecessor LAN Manager (LM). NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user's password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user's password over the wire. Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials.

· X.509:

The X.500 directory standards published by the ITU contain a subsection, X.509, which sets out recommendations for an authentication services framework. X.509, in its third revision, defines both a detailed syntax for certificates and an operational protocol specifying how a certificate is used for authentication. X.509 based authentication (such as Smart Card Logon and SSL/TLS Client Certificate) requires either an internal PKI Infrastructure or an external certificate service.

· Transport Layer Security 1.0/Secure Sockets Layer 3.0:

SSL 3.0 and TLS 1.0 are closely related protocols. SSL 3.0 is a proprietary Netscape Communications protocol, while TLS 1.0 is the Internet Engineering Task Force (IETF) standard. TLS, or RFC 2246, operates at the transport layer of the protocol stack. It’s invoked automatically whenever a user’s workstation connects to a server that requires secure communications. TLS/SSL uses a handshaking procedure to authenticate the server and (optionally) the client through X.509 certificates, to negotiate the algorithms for the session, and to exchange session keys for encryption and message digests.

· EAP-TLS

EAP-TLS uses a TLS handshake as the basis for authentication. TLS authenticates peers by exchanging digital certificates. In EAP-TLS, certificates are used to provide authentication in both directions. The server presents a certificate to the client, and, after validating the server's certificate, the client presents a client certificate. Naturally, the certificate may be protected on the client by a passphrase, PIN, or stored on a smart card, depending on the implementation. One flaw in EAP-TLS protocol noted by many observers is that the identity exchange proceeds in the clear before exchange of certificates, so a passive attack could easily observe user names.

· TTLS and PEAP

The structure of TTLS and PEAP are quite similar. Both are two-stage protocols that establish security in stage one and then exchange authentication in stage two. Stage one of both protocols establishes a TLS tunnel and authenticates the authentication server to the client with a certificate. (TTLS and PEAP still use certificates to authenticate the wireless network to the user, but only a few certificates will be required, so it is much more manageable.) Once that secure channel has been established, client authentication credentials are exchanged in the second stage.

TTLS uses the TLS channel/tunnel to exchange "attribute-value pairs" (AVPs), much like RADIUS. (In fact, the AVP encoding format is very similar to RADIUS.) The general encoding of information allows a TTLS server to validate AVPs against any type of authentication mechanism. TTLS implementations today support all methods defined by EAP, as well as several older methods (CHAP, PAP, MS-CHAP and MS-CHAPv2). TTLS can easily be extended to work with new protocols by defining new attributes to support new protocols.

PEAP uses the TLS channel to protect a second EAP exchange. Authentication must be performed using a protocol that is defined for use with EAP. In practice, the restriction to EAP methods is not a severe drawback because any "important" authentication protocol would be defined for use with EAP in short order so that PEAP could use it. A far greater concern is client software support. PEAP is backed by Microsoft, and clients are beginning to become available for recent professional versions of Windows (XP now, with Windows 2000 support coming shortly). Suppliers of PEAP clients for other operating systems have yet to materialize, which may restrict PEAP to being used only in pure Microsoft networks.

· Remote Access Dial-in User Services:

RADIUS, or RFC 2138, encrypts user ID/password information or challenge/response token information over the network. While initially created to support remote or network access servers, RADIUS has evolved to provide a standard mechanism by which Internet service providers (ISPs) relay authentication requests back to corporate customers.

· Security Assertion Markup Language (SAML):

When combined with XML-based remote procedure calls (RPCs) such as the Simple Object Access Protocol (SOAP), SAML serves as a distributed authentication protocol between authentication and other security services. As such, SAML allows loosely coupled security domains with heterogeneous systems and authentication methods to federate authentication. Liberty Alliance specifications leverage SAML as the underlying protocol while providing extensions such as account linking and global logout.

· Web Service Security (WSS):

Web Services Security (WSS) specifies ways to encode authentication and other security tokens in Simple Object Access Protocol (SOAP) message headers. Web Services Security Language (WS-Security) outlines encoding mechanisms for user IDs/passwords, X.509 certificates, Kerberos tickets, and SAML assertions.

· eXtensible rights Markup Language (XrML):

XrML is an XML-based usage grammar for specifying rights and conditions to control the access to digital content and services. Using XrML, anyone owning or distributing digital resources (such as content, services, or software applications) can identify the parties allowed to use those resources, the rights available to those parties, and the terms and conditions under which those rights may be exercised. These four elements are the Core of the language and determine the full context of the rights that are specified. In other words, it is not sufficient to just specify that the right to view certain content has been granted, but also who can view it and under what conditions.

· Simple Authentication and Security Layer:

SASL, or Request for Comment (RFC 2222), is a generalized negotiation mechanism and authentication abstraction layer for any connection-based protocol, including Simple Mail Transfer Protocol (SMTP), Internet Message Access Protocol 4 (IMAP4), and Lightweight Directory Access Protocol version 3 (LDAPv3).

· Secure Shell:

SSH, now at version 2.0, is a secure protocol and set of tools for secure, remote user authentication and access to servers. SSH can be used to secure any network-based traffic by setting it up as a ”pipe” (i.e., binding it to a certain port at both ends). This makes it useful for functions such as running X-Windows across the Internet. SSH runs on most UNIX systems, Windows servers, and client platforms, and there are open source SSH solutions for these environments. The SSH protocol consists of three major components: the Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy; the User Authentication Protocol authenticates the client to the server; and the Connection Protocol multiplexes the encrypted tunnel into several logical channels.

· BAPI :

The Biometric Application Programming Interface (BAPI) defines a standard software protocol and application programming interface (API) for communication between software applications and biometric devices. BAPI is designed to bring standards and compatibility to the biometric hardware and software markets. In 2000, Microsoft acquired BAPI technology from I/O Software with the intention to integrate the technology into the upcoming versions of Windows. As a direct result of Microsoft's integration, BAPI will be positioned to provide a seamless and consistent plug-and-play experience to Windows, and the vast majority of PC users. Triggered by Microsoft's commitment to the integration of biometrics, a quickly growing number of biometric vendors have adopted the BAPI standard. Microsoft my extend Kerberos in Blackcomb to support domain Biometrics logon (Longhorn local Biometrics logon has been but).

Many other authentication methods are B2C focused and will not be explained here (such as IIS Basic, Digest, Form Based, Passport and InfoCard etc.)