Copyright 1999 Michael R. Eisler All Rights Reserved The above copyright applies to only to this README file. Introduction ------------ This README file was created November 20, 1999. Last updated November 22, 1999. This is the README file for an implementation of RPC that contains an implementation of RPCSEC_GSS (RFC 2203) as written by Paul Ashley while in the employ of Queensland University of Technology. Michael R. Eisler licensed the code from Mr. Ashley so that a freely available RPCSEC_GSS implementation could be available for any purpose, commercial, or non-commercial. This collection of code was extracted from the CD-ROM on the book Practical Intranet Security, by Paul Ashley and Mark Vandenwauver, ISBN 0-7923-8354-0, and compiles on RedHat UNIX. Since is largely derived from Sun's 1984 distribution of RPC code that ran on 4.2 BSD operating systems, it should not be rocket science to get the RPCSEC_GSS chunk into your existing RPC implementation, particularly since you probably derived your RPC code from the same 1984 RPC distribution. This code does not include the GSS-API library. You can get GSS-API code for Kerberos V5 from MIT at http://web.mit.edu/kerberos/www/. If you are not in the U.S. or Canada, you may have problems getting GSS-API code via the above URL. You can try ftp://ftp.ox.ac.uk/pub/comp/security/software/Kerberos5/ but I don't claim to know if it is legal to download that code or not. License Stuff ------------- This collection of RPC code is copyrighted by several organizations and individuals. The most important ones being the Free Software Foundation, Sun Microsystems, and Paul Ashley. FSF --- The Free Software Foundation copyright covers the following files ./Makefile ./publickey.c ./rpc/auth_des.h ./Makefile.new ./Makefile.orig ./Makefile~ Under the GNU Public license. What is not clear to me is what version of the GNU Public License, and whether it is the GNU Lesser General Public License or the GNU General Public License. See http://www.gnu.org/copyleft/licenses.html to get an idea of what I mean. If this is a concern for you, then do not use those source files. Given that the primary purpose of this collection is to show how to implement RPCSEC_GSS, the aforementioned files are irrelevant. Sun --- The files that are copyrighted by Sun are covered under this license: * Sun RPC is a product of Sun Microsystems, Inc. and is provided for * unrestricted use provided that this legend is included on all tape * media and as a part of the software program in whole or part. Users * may copy or modify Sun RPC without charge, but are not authorized * to license or distribute it to anyone else except as part of a product or * program developed by the user. * * SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING THE * WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR * PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. * * Sun RPC is provided with no support and without any obligation on the * part of Sun Microsystems, Inc. to assist in its use, correction, * modification or enhancement. * * SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE * INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY SUN RPC * OR ANY PART THEREOF. * * In no event will Sun Microsystems, Inc. be liable for any lost revenue * or profits or other special, indirect and consequential damages, even if * Sun has been advised of the possibility of such damages. * * Sun Microsystems, Inc. * 2550 Garcia Avenue * Mountain View, California 94043 Paul Ashley ----------- The files that are copyrighted by Paul Ashley are covered under this license: * Copyright (c) 1999 Paul Ashley * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by Paul Ashley while in * the employ of the Queensland University of Technology. * 4. The name of the author may not be used to endorse or promote products * derived from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. If you are unsure what rights and obligations using this source code entails, I suggest getting professional legal advice. One thing I will point out is that when I licensed the code from Paul, he wanted to make sure that Queensland University and he got credit. So if you use this code, I strongly advise you to include the acknowledgement that above license requires. Questions --------- (1) One question that I'm sure I'll get asked is how good is the RPCSEC_GSS code? As Paul Ashley told me, this is not commercial grade code. I've never compiled or run this code. In examining it, it appears to me that it is close to on the wire compatible with RFC 2203 (which I'm one of the coauthors for). There are some things I noticed though: - The verifier response validate entry point (the AUTH_VALIDATE macro invokes it) does not do anything unless the verifier's flavor is set to AUTH_SHORT. This does not seem right. RFC 2203 does not mention AUTH_SHORT, and it states that the flavor number of verifiers must be set to the value of RPCSEC_GSS or 6. Moreover, the code that deals with the verifier does not look right. According to RFC 2203, the verifier should contain the result of a GSS_GetMIC() call on the sequence number of the original request. It looks like a cut and paste error from auth_unix.c. - The sequence number in the RPCSEC_GSS credential never moves, and the server side of RPCSEC_GSS does not check. This suggests that this client side of this implementation RPCSEC_GSS is not likely to interoperate with other servers that comply with RFC 2203. - Support for the rpc_gss_svc_integrity service does not appear to be on the wire compatible with RFC 2203. The code always calls gss_wrap() on the call arguments and results if the service is not equal to rpc_gss_svc_none. RFC 2203 states that gss_GetMIC() should be used. - The credential on the RPCSEC_GSS requests after the context is established does not appear to get set to anything resembling an RFC 2203 credential. It is suppose to include a header checksum and I did not see how that was happening. Nonetheless, if you are adding RPCSEC_GSS to your RPC framework, I think this code is a useful basis that beats starting from scratch. The context establishment code looks correct, and adding the the per data RPC request/response credential and verifier handling is a useful exercise for the reader. (2) Will you be doing anything to this code? Someday, but not for the foreseeable future. I've a day job right now. Do not wait for me to make any improvements. (3) Is this code legal to export? Yes. It does not contain any encryption code. Of course, if you combine it with a GSS-API library that does encryption, then it will likely be subject to export control and any domestic use laws in your country. That is your problem.