SASL: Simple Authentication and Security Layer

Masthead

SASL: CVS Proposal
SASL Home Project Cyrus ASG Home Search Contact Us

CVS is a prime example of a software package that would benefit from using SASL for authentication. Currently, when a group wishes to use a new authentication mechanism, CVS must be modified to accept a new server method (:kserver:, :gserver:, :pserver:), and all of the code for this new authentication mechanism must be incorporated into it.

By modifying CVS to use SASL for authentication, the incorporation of new authentication mechanisms into CVS would be much, much simpler. New SASL mechanisms would be defined and used, rather than an entire new server method being defined. CVS itself would not need to be modified at all.

Disclaimer

This documents changes that could be made to CVS in order to change the underlying authentication infrastructure to a SASL based negotiation. At this time, we are not able to actually implement these changes. If somebody were to implement these changes (or something like this that accomplishes the same goals), please let us know.

Goals

The changes to CVS we are proposing were conceived with the following goals in mind:

One new connection mechanism would be defined to replace pserver, gserver, and kserver. This mechanism would be used for all future authentication schemes.
The new connection mechanism would be bound to a new port.
Eventually, all older connection mechanisms (pserver, gserver, kserver) could be removed, as the new SASL-based mechanism would provide the same functionality.
Anonymous access would be well defined with the ANONYMOUS SASL mechanism. (There would no longer be a need for custom anonymous accounts, and special passwords.)
A repository must be able to define what mechanisms are allowed to be used to access it. This allows different repositories to be made available via the same CVS server, while each may have different user spaces.
The protocol must not be changed, beyond the opening authentication negotiation. The proposed changes should be able to mirror the existing pserver mechanism, as in many cases, they are identical.
The CVS src must not be changed beyond the authentication addition. Using older versions of CVS with a collection checked out using SASL must fail nicely, and the updated version of CVS must work correctly with collections checked out via older server access methods.
Encryption must be available if the authentication mechanism will support it. For example, ANONYMOUS will not provide this capability, but KERBEROS_V4 will.
For mechanisms that require a password (PLAIN, SCRAM-MD5, etc.), the password may be stored in locally, such as in ~/.cvspass. This should not be required, and if the password is not present for the existing mechanism, the client must prompt for it.

Proposed Changes

The changes we are proposing follow. I've broken them up into different categories, to help visualize what is going on from the client, and server point of views. Then I've listed the new protocol additions.

CVS Client Changes

First, the CVS client would be modified to accept the server access method ":sasl-${MECHANISM}:", where ${MECHANISM} is the name of the SASL mechanism to be used to authenticate to the server. This prefix (sasl-${MECHANISM}) will be stored as part of the CVS repository path, just like ":pserver:" is currently stored.

The server access method ":sasl:" would also be accepted. When used, the default SASL authentication mechanism would be used. The default should be ANONYMOUS, but would be overridable via an entry in .cvsrc. If this access method is specified while checking out a collection, all occurrences of the Root file in the checked out collection must actually contain ":sasl-ANONYMOUS:" as the prefix. This will make sure things don't break if a user changes his or her default mechanism.

The new server access method should use port 2402. (This is an arbitrary choice, and just follows the existing auth port number.)

If the specified mechanism is not advertised by the CVS server, the client must exit with an error message stating that the CVS repository does not support this authentication mechanism. It may also display the available authentication mechanisms. For example:

  % cvs -d :sasl-SCRAM-MD5:ryan@lister.net.cmu.edu:/cvs co cyrus-sasl
  This server does not support the SCRAM-MD5 SASL mechanism.
  Available mechanisms are:  ANONYMOUS KERBEROS_V4 DIGEST-MD5

If the SASL authentication mechanism indicates success, the CVS transaction continues normally.

A new command, setpass, must be created to store the appropriate (hopefully encrypted) form of the credentials locally. This may be stored in ~/.cvspass, but does not have to be. For some mechanisms, nothing will be stored (ANONYMOUS, KERBEROS_V4), but for others, something will be (SCRAM-MD5, DIGEST-MD5)

  % cvs -d :sasl-SCRAM-MD5:ryan@lister.net.cmu.edu:/cvs setpass
  Password for ryan@lister.net.cmu.edu: 
  Password saved.

CVS Server Changes

A new file may be placed in the repository. This file, called SASL_Mechanisms, must contain a list of SASL mechanisms, one per line, that the server will allow to authenticate with the CVS server for this repository. Additional information for the authentication mechanism may appear on the line separated from the mechanism name by a space. For example:

  ANONYMOUS
  KERBEROS_V4
  SCRAM-MD5 /passwd.scram
  DIGEST-MD5 /passwd.digest

Paths in these arguments should be assumed to be relative to $CVSROOT/CVSROOT, for security reasons.

When a user authenticates via the ANONYMOUS SASL mechanism, the CVS server must provide read-only access, as if the userid "anonymous" was in the readers file.

Once the SASL authentication mechanism indicates a successful authentication, the CVS server must change to the new userid (if applicable), and then the CVS transaction continues normally.

The server must check and make sure that the mechanisms listed in SASL_Mechanisms are actually available via the SASL library.

It is also desirable to have the CVS server log all anonymous transactions, so that statistics may be kept on who (what sites) are actually downloading the collections.

CVS Protocol Additions

The SASL Authentication protocol. Client sends:

  BEGIN SASL REQUEST\n
  <REPOSITORY>\n
  <USERNAME>\n
  END SASL REQUEST\n

The server then responds with the list of available mechanisms, space separated. The server may use the repository and username information to determine what mechanisms are available. However, this username must not be used by CVS to determine anything later. Instead, the userid provided by the authentication mechanism must be used. The username is available here in case a future authentication mechanism (or CVS modification) decides to use the username to limit what mechanisms are available.

  ANONYMOUS KERBEROS_V4 PLAIN SCRAM-MD5 DIGEST-MD5\n

The client then suggests an authentication mechanism

  SASL: ANONYMOUS\n

The client then begins the SASL transaction. Both sides will use base-64 encoded data buffers, preceded with the tag "+ ".

After the negotiation, the server will tell the client whether or not it has access by sending "I LOVE YOU\n" or "I HATE YOU\n".

If the client determines an error occurred, it will close the connection.

If the server determines an error occurred, it will send a number of buffers that begin with "E ", and then close the connection.

When done, the connection falls over to the normal server mechanism.

Examples

[ Server output is preceded by 'S: ', and client output by 'C: ' ]

  C: BEGIN SASL REQUEST\n
  C: /cvs\n
  C: ryan\n
  C: END SASL REQUEST\n
  S: ANONYMOUS KERBEROS_V4 PLAIN\n
  C: SASL: PLAIN\n
  S: + LKASDNASD013NGZO*\n
  C: + ASDBBNZ>WTA)*BS*)\n
  [ ... ] 
  S: I LOVE YOU\n

Encryption

Encryption is possible if the underlying authentication mechanism is strong enough. If a client requests encryption but the authentication mechanism is not strong enough, the client must tell the user and exit.

If encryption is required, and is possible, the encryption mechanism to be used must be based on the authentication mechanism. The Cyrus SASL library provides encryption and decryption routines that will encrypt/decrypt using the underlying authentication mechanism.

Future Enhancements

Other possible enhancements:

Transport Layer Security

A possible future enhancement would be the addition of a "STARTTLS" command to the protocol stream, which would cause CVS to negotiate a TLS connection on top of the existing stream. This could be used in conjunction with, or instead of, any existing encryption on the datastream. This use of TLS would be the equivalent of running the CVS connection over an SSH tunnel.

Enhanced AFS Support

There are two enhancements to CVS that may be made to enhance its performance in AFS.

The first enhancement is available as a patch from the CVS web site. The patch moves write locks away from the repository and into the directories actually being modified. All locks then appear in subdirectories called "#cvs.locks" in each and every directory of the repository. The advantage to doing this in AFS is that the main repository does not have to have write access by everybody, and AFS ACLs may be used to enforce who has access to collections.

The second enhancement would be an extension to the SASL library that would allow the KERBEROS_V4 mechanism to encrypt, pass, and extract a TGT. Once this is done, the cvs server could create a new pag, and then extract a token from the ticket, giving the CVS server full AFS access on behalf of the client. With this extension, CVS clients on any platform (MacOS, Windows, etc.) that use KERBEROS_V4 for authentication would be able to have full access to AFS based repositories.

Contact Information

This document describes the CVS changes that could be done to make CVS use SASL. It is presented here to make others think about it, and to let others see how SASL may be used in an application. No development work is being done by CMU on this at this time. If you would like to implement this, please do so.

If you have any questions or comments about this, or have an implementation that you would like to let us know about, please send mail to the author of this document: Ryan Troll <ryan@andrew.cmu.edu>.

Last modified: Thu Apr 1 00:18:55 EST 1999