Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/90dec/passec-minutes-90dec.txt

Text File | 1993-02-17 | 9KB | 207 lines

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           [e-mail]
Karl Auerbach            [e-mail]
Ronald Broersma          [e-mail]
Philip Budne             [e-mail]
Ken Carlberg             [e-mail]
Vinton Cerf              [e-mail]
George Conant            [e-mail]
Steve Crocker            [e-mail]
James Dray               [e-mail]
Fred Engel
Peter Ford               [e-mail]
Harley Frazee            [e-mail]
James Galvin             [e-mail]
Joel Jacobs              [e-mail]
Philip Karn              [e-mail]
Tom Kessler              [e-mail]
Christopher Kolb         [e-mail]
Walter Lazear            [e-mail]
John Linn                [e-mail]
Carl Malamud             [e-mail]
Jim Reinstedler          [e-mail]
Bill Rust                [e-mail]
Jeffrey Schiller         [e-mail]
Sam Sjogren              [e-mail]
Mark Stein               [e-mail]
Bob Stewart              [e-mail]
Ron Strich               ssds![e-mail]
Kannan Varadhan          [e-mail]
Jesse Walker             [e-mail]@decpa.dec.com
Peter Wiedemann          wiedemann@dockmaster
C. Philip Wood           [e-mail]
Robert Woodburn          [e-mail]



                                   4