SASL: CVS Proposal
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.
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:firstname.lastname@example.org:/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:email@example.com:/cvs setpass Password for firstname.lastname@example.org: Password saved.
ANONYMOUS KERBEROS_V4 SCRAM-MD5 /passwd.scram DIGEST-MD5 /passwd.digestPaths 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.
BEGIN SASL REQUEST\n <REPOSITORY>\n <USERNAME>\n END SASL REQUEST\nThe 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\nThe client then suggests an authentication mechanism
SASL: ANONYMOUS\nThe 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.
[ 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
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.
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.
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 <email@example.com>.