Initial import of OPIE v2.3 fromvendor/opie/2.3

	ftp://ftp.nrl.navy.mil/pub/security/opie/

1 files changed, 391 insertions, 0 deletions

diff --git a/contrib/opie/README b/contrib/opie/README
new file mode 100644
index 000000000000..63b4d8cc4948
--- /dev/null
+++ b/contrib/opie/README
@@ -0,0 +1,391 @@
+OPIE Software Distribution, Release 2.3                   Important Information
+=======================================                   =====================
+
+Introduction
+============
+
+	"One-time Passwords In Everything" (OPIE) is a freely distributable
+software package originally developed at and for the US Naval Research
+Laboratory (NRL). Recent versions are the result of a cooperative effort
+between of NRL, several of the original NRL authors, The Inner Net, and many
+other contributors from the Internet community.
+
+	OPIE is an implementation of the One-Time Password (OTP) System that
+is being considered for the Internet standards-track. OPIE provides a one-time
+password system. The system should be secure against the passive attacks
+now commonplace on the Internet (see RFC 1704 for more details). The system
+is vulnerable to active dictionary attacks, though these are not widespread
+at present and can be detected through proper use of system audit
+software. 
+
+	OPIE is primarily written for UNIX-like operating systems, but
+we are working to make applicable portions portable to other operating systems.
+The OPIE software is derived in part from and is fully interoperable with the
+Bell Communications Research (Bellcore) S/Key Release 1 software. Because
+Bellcore claims "S/Key" as a trademark for their software, NRL was forced to
+use a different name (we picked "OPIE") for this software distribution.
+
+	OPIE includes the following additions/modifications to the
+original Bellcore S/Key(tm) Version 1 software:
+
+* Just about three command installation (unpack the software, run the
+  configure script, and run make install). While we still recommend that you
+  follow instructions and test things by hand, the more adventurous can
+  install OPIE quickly.
+
+* A modified BSD FTP daemon that does OTP.
+
+* A version of su that uses OTP by default. 
+
+* MD5 support. MD5 is now the default algorithm, though MD4 is still supported
+  by changing a parameter in the Makefile. This change was made because MD5 is
+  widely believed to be cryptographically stronger than MD4 (see RFC 1321).
+
+* A more portable version of MD4 has been substituted for the original MD4. 
+  This should solve the endian problems that were in S/Key.
+
+* Most of the system-dependencies have been moved to a new file "opie_cfg.h".
+
+* Configuration options have been moved to the Makefile.
+
+* Isolated system dependencies (e.g. BSDisms) with appropriate #ifdefs.
+
+* Revised the opiekey(1) program to simultaneously support MD4 and MD5, with
+  the default algorithm being tunable using the MDX symbol in the Makefile.
+
+* More operating systems are supported by recent versions of OPIE, but older
+  BSD systems that aren't close to being compliant with the POSIX standard are
+  no longer supported.
+
+* Transition mechanisms are optional to prevent potential back doors.
+
+* On systems using the /etc/opieaccess transition mechanism, users can choose
+  to require the use of OPIE to login to their accounts when it would 
+  otherwise be optional.
+
+* Bug fixes
+
+* Cosmetic changes
+
+* Prompts (optionally) identify specifically what kind of entry (system
+  password, secret pass phrase, or OTP response) is allowed.
+
+* Changes to mostly conform with the draft Internet OTP standard.
+
+A Glance at What's New
+======================
+
+	2.3 September 22, 1996
+
+	Autoconf is now the only supported configuration method.
+
+	Lots of internal functions got re-written in ways that will make some
+planned future changes easier.
+
+	OTP extended responses, such as automatic re-initialization.
+
+	Support for a supplemental key file that stores information that was
+not in the original /etc/skeykeys file. This allows OPIE to store extra data
+needed for things like the OTP re-initialization extended response without
+breaking interoperability with other S/Key derived programs. This file is
+named "/etc/opiekeys.ext" by default. Unlike the standard key file, it MUST
+NOT be world readable.
+
+	OPIE should better support some of the native "features" of drain
+bamaged OSs such as AIX, HP-UX, and Solaris.
+
+	OPIE's utmp/wtmp handling has been completely re-written. This should
+solve many of the utmp/wtmp problems people have been having.
+
+	Lots of cleanups.
+
+	Bug fixes.
+
+	2.22 May 3, 1996.
+
+	More minor bug fixes. OPIE once again works on Solaris 2.x.
+
+	2.21 April 27, 1996.
+
+	Minor bug fixes.
+
+        2.2 April 11, 1996.
+
+        opiesubr.c, opiesubr2.c, and a few other functions moved into
+a subdirectory and split into files with fine granularity. Ditto with
+missing function replacements. This subdirectory structure changes a lot
+of things around and more splitting like this should be expected in the
+near future.
+
+        Added opiegenerator() library function that should make it very easy
+to create OTP clients using the OPIE library (this function is subject to
+change: there are a few problems remaining to be solved). Just about re-write
+opiegetpass() to use raw I/O and got most of the OPIE programs actually using
+that function. Autoconf build fixes. Lots of bug fixes. Lots of portability
+fixes. Function declarations should be ANSI style for ANSI compilers. Several
+fixes to bring OPIE in line with the latest OTP spec. MJR DES key crunch 
+de-implemented.
+
+	Added sample programs: opiegen (client) and opieserv (server).
+
+	Probably broke non-autoconf support along the way :(. I've tried to
+bring this back in sync, but it may still be broken.
+
+        2.11 December 27, 1995.
+
+        Minor bug fixes.
+
+	2.10 December 26, 1995.
+
+	Optional autoconf support. opieinfo is now a normal program.
+Bugs fixed -- should work much better on SunOS, HP-UX, and AIX.
+
+System Requirements
+===================
+
+        In order to build and run properly, OPIE requires:
+
+        * A UNIX-like operating system
+        * An ANSI C compiler and run-time library
+        * POSIX.1- and X/Open XPG-compliance (including termios)
+        * The BSD sockets API
+        * Approximately five megabytes of free disk space
+
+        In practice, we believe that many systems who are close to meeting
+these requirements but aren't completely there (for example, SunOS with the
+native compiler) will also work. Systems who aren't anywhere near close
+(for example, DOS) are not likely to work without major adjustments to the
+OPIE code.
+
+If OPIE Doesn't Work
+====================
+
+	First and foremost, make sure you have the latest version of OPIE. The
+latest version is available by anonymous FTP at:
+
+	ftp://ftp.nrl.navy.mil/pub/security/opie
+		and
+	ftp://ftp.inner.net/pub/opie
+
+	If you have installed the OPIE software (either through "make test"
+in (7) above or "make install" in (14)), you can run "make uninstall" from the
+OPIE software distribution directory. This should remove the OPIE software and
+restore the original system programs, but it will not work properly (and can
+even result in the total loss of the old system programs -- beware!) if the
+installation procedure itself did not work properly.
+
+	OPIE is NOT supported software. We don't promise to support you or
+even to acknowledge your mail, but we are interested in bug reports and are
+reasonable folks. We also have an interest in seeing OPIE work on as many
+systems as we can. However, if your system doesn't meet the basic requirements
+for OPIE, this will probably require an unreasonable amount of effort.
+
+	The best bug reports include a diagnosis of the problem and a fix. 
+Your bug report can still be valuable if you can at least diagnose what the 
+problem is. If you just tell us "it doesn't work," then we won't be able to
+do anything to help you.
+
+	We've received a number of bug reports from people that look
+interesting, only to find when we try to follow up on them that the user
+either has an invalid return address or never bothered to respond to our
+followup. Please make sure that bug reports you send us have an electronic
+mail address that we can reply to somewhere in them (if necessary, just
+put it in the message body). If we send you a response and you are unable
+to invest the time to work with us to solve the problem, please tell us --
+few things are more irritating than when someone sends us information
+about a bug that we'd like to fix and then is never heard from again.
+
+	We try to respond to all properly submitted bug reports. Improperly
+submitted bug reports will be responded to only if we have time left after
+responding to properly submitted bug reports. We deliberately ignore bug
+"reports" sent to mailing lists or USENET news groups instead of or before
+our bug report address. At the least, the latter practice is lacking in
+courtesy.
+
+	The file BUG-REPORT contains our bug reporting form. Please use it
+and follow the submission instructions in that file. We are going to switch
+to machine-parsed bug report processing sometime in the near future to make
+it easier to coordinate bug hunting.
+
+Gotchas
+=======
+
+	While an almost universal "feature", most people remain unaware that
+an intruder can log into a system, then log in again by running the "login"
+command from a shell. Because the second login is from the local host, the
+utmp entry will not show a remote login host anymore. The OPIE replacement
+for /bin/login currently carries on this behavior for compatibility reasons.
+If you would like to prevent this from happening, you should change the
+permissions of /bin/login to 0100, thus preventing unprivileged users from
+executing it. This fix should work on non-OPIE /bin/login programs as well.
+
+	On 4.3BSDish systems, the supplied /bin/login replacement obtains
+the terminal type for the console comes from the console line in the /etc/ttys
+file. Several systems contain a default entry in this file that specifies the
+console terminal type as "unknown". This is probably not what you want.
+
+	The OPIE FTP daemon responds with two 530 error messages if you have 
+not yet logged in and execute a command that will also do a PORT request. This 
+is a feature, not a bug, as the FTP client is really sending the server two 
+commands (for instance, a PORT and a LIST if you tell your BSD FTP client to do
+a DIR command) and the server is responding to each of them with an error. The
+stock BSD FTP daemon doesn't check the PORT commands to see if you are logged 
+in, so you would only get one error message. This change should not break any
+standards-compliant FTP client, but there are a number of brain-damaged GUI
+clients that have a track record for not dealing gracefully with any server
+other than the stock BSD one.
+
+	The /etc/opieaccess transition mechanism is, by definition, a security
+hole in the OPIE software because an attacker could use it to circumvent the
+requirement for OPIE authentication. You should compile the software with
+support for this file disabled unless you absolutely cannot use the software
+without it because of your environment. If you do use this support for
+transition purposes, you should move people to OTP authentication as quickly
+as possible and rebuild and reinstall OPIE with this transition support
+disabled so that you won't have a lurking security hole.
+
+        If this wasn't already clear, do not let your sequence number fall
+below about ten. If your sequence number reaches zero, your OTP sequence
+can only be reset by the superuser. System administrators should make this
+caveat known to their users.
+
+	On Solaris 2.x systems (and possibly others) running NIS+, users
+should run keylogin(1) manually after login because opielogin(1) does not
+do that automatically like the system login(1) program.
+
+	There are reports that some versions of GNU C Compiler (GCC)
+(when installed on some systems) use their own termios(4) instead of
+the system's termios(4).  This can cause problems.  If you are having
+compilation problems that seem to relate to termios and you are using
+GCC, you should probably verify that it is using the system's
+termios(4) and not some internal-to-GCC termios(4).  One report
+indicates that Sun's C compiler works fine with SunOS 4.1.3/4.1.4 on
+SPARC, but that some version of GCC on the same system has this
+termios(4) problem.  We haven't reproduced these problems ourselves
+and hence aren't sure what is happening, but we pass this along for
+your information. (This may have something to do with the use of GNU
+libc)
+
+	If a user has a valid entry in the opiekeys database but has an
+asterisk in their traditional password entry, they will not be able to
+log in via opielogin, but opielogin will decrement their sequence number
+if a valid response is received.
+
+        On some systems, the OPIE login program does not always display
+a "login:" prompt the first time. We think that this has something to do
+with the telnet daemon on those systems. (This is common on SunOS) You should
+be able to fix this by upgrading to the latest version of telnetd.
+
+	The standard HPUX compiler is severely drain bamaged. One of the
+worst parts is that it sometimes won't grok a symbol definition with forward
+slashes in them properly and can choke badly on the definition of the key
+file's location. If this happens to you, install and use GCC. (This problem
+may or may not also come up with the optional HP ANSI C compiler -- we don't
+know for sure what compilers have this problem).
+
+	As of OPIE 2.2, the seed is converted to lower case and its length is
+checked in order to comply with the OTP specification. If any of your users
+have seeds that use capital letters or are too long, they need to run the OPIE
+2.2 opiepasswd program to re-initialize their sequence to one with a different
+seed.
+
+	opielogin is a replacement for /bin/login. It is NOT an OPIE "shell."
+You can use it as one, but don't be surprised if it doesn't behave the way
+you expect. An OPIE "shell" is on the TODO list.
+
+	Clients that use opiegen() will automatically send a re-initialization
+extended response if the sequence number falls below ten. If the server does
+not support this, the user will need to log in using opiekey and reset his
+sequence manually (using opiepasswd).
+
+Gripes
+======
+
+	Is it too much to ask that certain OS vendors just do the right thing
+and not fix what isn't broken? (Look at all the ifdefs in the OPIE code and
+the answer is clear)
+
+Credits
+=======
+
+	First and foremost credit goes to Phil Karn, Neil M. Haller, and John
+S. Walden of Bellcore for creating the S/Key Version 1 software distribution
+and for making its source code freely available to the public. Without their
+work, OPIE would not exist. Neil has also invested a good amount of his time 
+in the development of a standard for One-Time Passwords so that packages like
+OPIE can interoperate.
+
+	The first NRL OPIE distribution included modifications made primarily 
+by Dan McDonald of the U.S. Naval Research Laboratory (NRL) during March 1994.
+The 2nd NRL OPIE distribution, which has a number of improvements in areas
+such as portability of software and ease of installation, is primarily the
+work of Ran Atkinson and Craig Metz. Other NRL contributors include Brian 
+Adamson, Steve Batsell, Preston Mullen, Bao Phan, Jim Ramsey, and Georg Thomas.
+
+	Some of version 2.2 was developed at NRL and released as a work in
+progress. Most of the release version was developed by Craig Metz (also of
+NRL), others at The Inner Net, and contributors from the Internet community.
+Versions beyond 2.2 were developed outside NRL, so don't blame them if they
+don't work (But please credit them when it does. Without the NRL effort, there
+wouldn't be an OPIE).
+
+	We would like to also thank everyone who helped us by by beta testing,
+reporting bugs, suggesting improvements, and/or sending us patches. We
+appreciate your contributions -- they have helped to make OPIE more of a
+community effort. These contributors include:
+
+	Mowgli Assor
+	Lawrie Brown
+	Axel Grewe
+	"Hobbit"
+	Darren Hosking
+	Martijn Koster
+	Osamu Kurati
+	Ayamura Kikuchi
+	Ikuo Nakagawa
+	Angelo Neri
+	D. Jason Penney
+	John Perkins
+	Jim Simmons
+	Werner Wiethege
+	Wietse Venema
+
+	OPIE development at NRL was sponsored by the Information Security
+Program Office (PD 71E), U.S. Space and Naval Warfare Systems Command, Crystal
+City, Virginia.
+
+	If you have problems with OPIE, please follow the instructions under
+"If OPIE Doesn't Work." Under NO circumstances should you send trouble
+reports directly to the authors or contributors.
+
+Trademarks
+==========
+S/Key is a trademark of Bell Communications Research (Bellcore).
+UNIX is a trademark of X/Open.
+NRL is a trademark of the U. S. Naval Research Laboratory.
+
+All other trademarks are trademarks of their respective owners.
+
+The term "OPIE" is in the public domain and hence cannot be legally 
+trademarked by anyone.
+
+Copyrights
+==========
+%%% portions-copyright-cmetz
+Portions of this software are Copyright 1996 by Craig Metz, All Rights
+Reserved. The Inner Net License Version 2 applies to these portions of
+the software.
+You should have received a copy of the license with this software. If
+you didn't get a copy, you may request one from <license@inner.net>.
+
+Portions of this software are Copyright 1995 by Randall Atkinson and Dan
+McDonald, All Rights Reserved. All Rights under this copyright are assigned
+to the U.S. Naval Research Laboratory (NRL). The NRL Copyright Notice and
+License Agreement applies to this software.
+
+Portions of this software are copyright 1980-1990 Regents of the
+University of California, all rights reserved. The Berkeley Software
+License Agreement specifies the terms and conditions for redistribution.
+
+Portions of this software are copyright 1990 Bell Communications Research
+(Bellcore), all rights reserved.