392 lines
17 KiB
Plaintext
392 lines
17 KiB
Plaintext
|
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.
|