CURRENT_MEETING_REPORT_
Reported by Jeffrey Schiller/MIT
PASSEC Minutes
The Password and Configuration Management Working Group met for the
first time in Boulder.
Agenda
The Working Group has two distinct goals:
o First - To make computer systems more resistant to unauthorized
access by defining and/or improving the management of their user
passwords and configurations.
o Second - To prevent the transmittal of clear-text passwords over
the network by defining a protocol/algorithm that while allowing
use of remote terminal servers would preclude retrieval of any
information which might facilitate unauthorized access.
On Configuration and Password Management:
The group engaged in a lively discussion of the issues related to
password configuration management. Specifically:
o How to get users to choose ``good'' passwords.
o How to get users to configure their systems to make them more
resistant to outside tampering.
o Responsibilities: User vs. Vendor vs. Network Manager
No conclusions were reached by the group. The issues considered have
been more or less discussed in the Site Security Policy Handbook which
is being prepared by another Working Group. This work is probably best
continued within that forum. I recommend that no further meetings of
this group deal with these issues.
On Password Protection:
It was felt that this problem is secondary to the password configuration
1
problem mentioned above. However there is a real concern today that
users of remote terminal servers invariably use them by sending their
clear-text password over the network from remote terminal server to home
system. Given the size of the network and diversity of its management,
it is prudent at this time to develop a method for more secure
authentication from terminal server to host system.
Three proposals were discussed. In general, proposals fall into two
categories. Those that exchange encryption keys as part of the
protocol, and those that do not. The methods that exchange keys are
cryptographically based, typically based on public key cryptography or
on a variant of Needham-Schroeder trusted third party symmetric key
exchange (for example Kerberos). The methods that do not exchange
encryption keys typically involve the use of ``one-time'' passwords. It
is desirable for all methods to not store plain-text information on
hosts that if compromised will permit unauthorized access (i.e., no
plain text passwords should be stored on host systems).
At the meeting three methods were discussed. The first two methods are
one-time passwords schemes. They are:
o A method developed by Phil Karn which involves taking an initial
password and encrypting N times (via the UNIX ``crypt(3)''
function, which is a one-way trap-door function based on DES) and
storing the result. When a user wishes to login, the host system
hands the number N over to the user. The user then takes the
initial password and encrypts it (via crypt(3)) N-1 times (either
on a smart-card, portable PC or with computational resources on the
terminal server) and sends the result over the network. The host
then computes the last round of encryption and compares the result
with the stored value. If they match then access is granted and
the N-1 encryption is stored. When N reaches 0, a new password
needs to be chosen and stored.
o A method developed by Chuck Hedrick uses an algorithm to convert a
password into a DES key. Initially the host system stores two
values, the first is a random number one-way hashed (say via
crypt(3)) and the second is the same random number encrypted in the
DES key describe above. When a user wishes to login, the DES
encrypted version of the random number is sent to the user. Using
a smart-card, portable PC or terminal server software the user
decrypts the number with the DES key and sends the plain text
random number to the host. The host one-way encrypts the supplied
value and compares it with the stored one-way hashed value. If it
is the same, access is granted. Once access is granted a new
random number is chosen by the user (on the smart card or whatever)
and a one-way hash is computed as well as the encrypted value
(encrypted with the DES key). These two values are then sent to
the host to be stored for the next login authentication dialog.
2
Note: In both of the above mechanisms it is possible to
pre-compute the input that the user needs to enter, so as to avoid
the need for specialized terminal server software, smart cards or
the like. The above methods do not perform key exchange, and are
``one-shot'' authentication schemes (i.e., they do not prevent the
hijacking of the already created TCP connection). Nor is data
(both keyboard input and screen displays) protected from disclosure
to unauthorized network eavesdroppers.
The third method mentioned at the meeting, introduced by Jeff Schiller,
is a key exchange protocol based on public key encryption and the
certificates that will be issued for Privacy Enhanced Mail.
o The basic idea is for the user to choose a password which is then
converted, via an algorithm, into an RSA private key/public key
pair. The public key is then digitally signed with the user's
Privacy Enhanced Mail private key and the resulting signed value
stored on the host. To login the user informs the host of his/her
intention to login. The host then chooses a random DES key and
encrypts it with the stored public key of the user. This
information is then forwarded to the user along with a randomly
chosen number. The user (via software in the terminal server,
smart card, etc.) then decrypts the DES key (using their private
RSA key which is derived from a typed password). The DES key is
then used to encrypt the random number provided by the host and
sends the result back to the host. The host (which still knows the
DES key) validates that the value returned is correct (i.e., the
user demonstrated that he/she was able to obtain the DES key which
was provided to them encrypted in their public key) and if it is,
allows access.
The above mechanism provides for secure key exchange (both the user
and the host have exclusive knowledge of a DES key when the
protocol is finished). This key can then be used to encrypt data
on the network, or to answer periodic ``challenges'' from the host
(which would make it harder to hijack a TCP connection, even if
each packet isn't encrypted). The major drawbacks are that it
requires the cooperation of the local terminal server, or a smart
card (or portable PC). Licensing of some variety will be required
as well.
There are other potential mechanisms in addition to those mentioned
above, the list was not meant to be exhaustive. It is what we
discussed.
Attendees
3
Vikas Aggarwal vikas@JVNC.net
Karl Auerbach karl@eng.sun.com
Ronald Broersma ron@nosc.mil
Philip Budne phil@shiva.com
Ken Carlberg carlberg@sparta.com
Vinton Cerf vcerf@NRI.Reston.VA.US
George Conant geconant@eng.zyplex.com
Steve Crocker crocker@tis.com
James Dray dray@st1.ncsl.nist.gov
Fred Engel
Peter Ford peter@lanl.gov
Harley Frazee harley@t3plus.com
James Galvin galvin@tis.com
Joel Jacobs jdj@mitre.org
Philip Karn karn@thumper.bellcore.com
Tom Kessler kessler@sun.com
Christopher Kolb kolb@psi.com
Walter Lazear lazear@gateway.mitre.org
John Linn linn@zendia.enet.dec.com
Carl Malamud carl@malamud.com
Jim Reinstedler jimr@ub.com
Bill Rust wjr@ftp.com
Jeffrey Schiller jis@mit.edu
Sam Sjogren sjogren@tgv.com
Mark Stein marks@eng.sun.com
Bob Stewart rlstewart@eng.xyplex.com
Ron Strich ssds!rons@uunet.uu.net
Kannan Varadhan kannan@oar.net
Jesse Walker walker@eider.enet@decpa.dec.com
Peter Wiedemann wiedemann@dockmaster
C. Philip Wood cpw@lanl.gov
Robert Woodburn woody@sparta.com
4