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



                                  4

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.