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