The Simple Authentication and Security Layer

  

The Simple Authentication and Security Layer (SASL) is a network protocol for exchanging keys using multiple authentication mechanisms. (For more information, reference the www.ietf.org/rfc/rfc2222.txt site.) Lightweight Directory Access Protocol (LDAP) servers have usually adopted SASL as the authentication mechanism, and when you access LDAP through a naming service such as Java Naming and Directory Interface (JNDI), it typically uses SASL.

Defining SASL

The SASL is a method for adding authentication support to connection-based protocols. A protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating a security layer for subsequent protocol interactions. The first requirement is the argument for identifying the SASL mechanism such as "ANONYMOUS," "CRAM-MD5," "SRP," "DIGEST-MD5," "OTP," or "GSSAPI." These authentication mechanisms are passed in a field that can be no more than 20 characters long and must be registered with the Internet Assigned Numbers Authority (IANA). For more information, take a look at www.iana.org .

The client's authentication mechanism field is done in clear text and may be modified by an attacker. Any new SASL authentication mechanism must be designed with this in mind so that a weaker authentication mechanism cannot be selected instead. After an authentication mechanism is selected, it will provide the data integrity and key exchange information. The SASL defines the request-reply mechanics to the authentication mechanism. The strength of the authentication mechanism is dependent on which authentication mechanism is used.

Tip  

One idea to ensure that attackers cannot change clear text is to implement SASL with a secure transport protocol like SSL and TLS (discussed in Chapter 22). Initializing a secure transport layer can be done by adding commands to SASL, which is supported in the protocol.

If the server supports the SASL mechanism that is being requested , an authentication session is started; otherwise , an abort is returned. An authentication session lasts from when the client initiates the first request till when it has finished communicating with the SASL server. During an authentication session, only one full authentication can take place unless specified by the authentication mechanism's profile. Only one SASL security layer can be in effect at a given instance for authentication. So if multiple authentications are allowed simultaneously , the next authentication that is selected will replace the current security layer. If no security layer is selected, the original security layer remains in effect.

The command requires that you specify the name of the mechanism to use for authentication. An LDAP server such as the Netscape Directory Server might support the use of SASL mechanisms through server plug-ins. Many server plug-ins are extendable and can be written to support more authentication mechanisms as long as they are registered with IANA and the protocol is followed. SASL allows the same interface to support many authentication mechanisms. The authentication mechanism defines how the server will respond and accept responses.

Note  

In Java, pluggable authentication is provided by JAAS, GSS-API, and SASL. Additional support for securing communications across networks is provided by both the GSS and SASL after authentication has been completed. RFC 2222 specifies how GSS-API services can be used for SASL authentication and how they can be used to create a security layer for your application.

Server challenges and responses

A series of server challenges and responses will be executed based on the authentication mechanism. The form of the authentication messages will be in an octet binary token. The command may allow optional parameters for allowing the client to send ahead authentication information to avoid redundant challenges. The authentication mechanism will define whether optional parameters are allowed. If the server doesn't accept the optional principal and credential initially with the protocol, the server can request the authentication, and the client can send an empty response for the server to use the data previously sent.

After the server receives the commands from the client, the server may respond with an authentication challenge from the server, indicate a failure, or indicate that the authentication has completed based on the authentication mechanism.

When the client receives the authentication challenge from the server, the client may respond or abort the reply based on the authentication mechanism. The server and client can continue to issue a series of server challenges and client responses. During the challenges and responses, a "SUCCESS" is returned if the authentication is successful, and an error code such as "INVALID_CREDENTIALS" is returned if the authentication fails.

Tip  

The SASL is a plug-and-play protocol for communicating with authentication mechanisms. A Java implementation of a plug-and-play authentication mechanism is the Java Authentication and Authorization Service (JAAS) mentioned in Chapter 19, or IPSec mentioned in this chapter. It wouldn't be surprising that many SASL implementations are developed in JAAS.

During the authentication protocol exchange, the mechanism performs authentication and sets the principal credentials. The principal is normally set in the form of user identification. The principal and credentials could be set differently during or after authentication than the ones used during authentication to permit proxy server logins. If the authentication completes successfully, the client and server may agree on a security layer to protect the privacy of the session from that point on.

Note  

SASL mechanism registrations will be posted in the anonymous FTP Directory at ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms/ .

  


Java Security Solutions
Java Security Solutions
ISBN: 0764549286
EAN: 2147483647
Year: 2001
Pages: 222

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net