Authentications on CSE mail services

Summary

Plain-text passwords used by various CSE mail services for authentication are currently vulnerable to network eavesdroping and the captured passwords can be used later to intrude other CSE network services. To prevent such activities, this summer all CSE mail servers will have stronger methods of authentication implemented (they should be available by the beginning of August 2001 if not already available), and have the plain-text password authentication in the clear disabled.

A summary of access methods for various mail services after August 23, 2001 is shown in the table below:

Table 1: Authentication methods available on CSE mail services
Service port Local Access Remote Access
IMAP 143 rsh, GSSAPI, Plain-text password over TLS/SSL, GSSAPI over TLS/SSL GSSAPI, Plain-text password over TLS/SSL, GSSAPI over TLS/SSL
POP 110 rpop (being phased out), Plain-text password over TLS/SSL Plain-text password over TLS/SSL
SMTP 25 No authentication, TLS/SSL not needed Service being opened
NNTP 119 No authentication Single password but likely to use user's password over TLS/SSL
ACAP 674 Service not available Service not available
LDAP 389 No authentication Service not available

Note:

  1. Users should maintain ~/.rhosts file, Kerberos ticket, and certificates for the use of rsh/rpop, GSSAPI, and TLS/SSL mechanism respectively.
  2. Some clients have Alternate Ports for imap (port 993) and for pop (port 995) where client must use TLS/SSL on the ports. The use of these ports is discouraged. If possible, use the normal port (143 or 110) for the service with option STARTTLS or equivalent for TLS/SSL.
  3. If you use PINE or MH on CSE-supported hosts, there is no need to make changes to its configuration unless you want to encrypt your mail content.
  4. Users, who are still using any of the services via plain-text password, will receive mails urging to have the authentication method changed before the cut-off date.

There are many mail clients with different methods of setup. Some of mail clients, which have known to work with CSE services, are covered below.

CSE Unix Pine

Pine can use all local IMAP access methods listed in Table 1 above.

A simple method you can use is via rsh. All you need is to put the name of host running Pine in your ~/.rhosts file. The host name must be fully qualified, i.e., its suffix must be .cs.washington.edu. If your host's IP address is dynamically assigned, you can not use this method.

When a user logs on to a CSE host, the system would typically authenticate the user, and if successful, create a Kerberos ticket for the user to access network services. You can check whether you have a kerberos ticket by running Kerberos klist command. The command could live under /usr/local/krb5/bin or /usr/kerberos/bin directory on your host. If you don't have a ticket or it is expired, you need to run kinit from the same directory to create a new ticket. The command will ask you for a password. Please be sure the password is protected by using an encrypted session if you connect to the machine through the network. If rsh method fails and the Kerberos ticket is available, Pine will try to use GSSAPI.

If for some reasons you want to encrypt your email session, you will need to use TLS/SSL. With CSE Pine starting from version 4.33, TLS/SSL is used automatically if rsh mechanism is not used.

You can also use TLS/SSL with CSE Pine version 4.21 or with rsh on version 4.33 by forcing it. In your ~/.pinerc file, you need to replace your inbox-path line with the following line:

inbox-path={myaccount.mail.cs.washington.edu/ssl}inbox

The myaccount string above should be your account name. If it complains about certificate, you need to add a string /novalidate-cert after the /ssl striong as follow:

inbox-path={myaccount.mail.cs.washington.edu/ssl/novalidate-cert}inbox

However, the use of string /novalidate-cert is discouraged since it may not warn your if a server presents you with a bogus certificate. If you need to use it, it should be removed when it is no longer needed such as after a Pine upgrade.

Please note the CSE Unix Pine may not behave the same as other installations due to its being built locally and possibly relinked with differing libraries and/or having different patches applied.

Outlook Express 5.x (IMAP/POP)

If Outlook is being started for the first time, an account for mail need to be set up. Follow instructions below. If you already have either an IMAP or POP account set up, right click on your account, click on Properties, and then follow instructions starting from step 5 below.

  1. Under the Tools drop menu, click on Accounts.... You should now in Internet Accounts page and see All, Mail, News and Directory Service tabs.

  2. Click on Mail, click on Add and then click on Mail.

  3. Fill in information on your mail account. For example, Luke Skywalker (luke@cs.washington.edu) would have his information filled in as follows:
    E-mail address: luke@cs.washington.edu
    My incoming mail server is a IMAP server
    Incoming mail server: luke.mail.cs.washington.edu
    Outgoing mail server: luke.mail.cs.washington.edu

    Note: You may not be able to set Outgoing mail server as above. See SMTP service section for details.

    On the Internet Mail Logon page, please do not check Remember password, and do not check Log on using Password Authentication (SPA). For Luke, he would have his page as below.

  4. After you are done, click finish. You are now back to Internet Account page. Do not close it yet.

  5. Click properties and then go to Servers tab. Make sure the Remember password and Log on using Secure Password Authentication checkboxes are not checked.

    If you use a CSE server for your outgoing mail, you can leave the My server requires authentication checkbox in Outgoing Mail server section alone. Even though a CSE server can do authentication, checking the box does not seem to make the Outlook do it.

  6. Go to Advanced tab. Click the SSL checkbox on Incoming mail. If you want your mail to be encrypted and your outgoing mail server can do it, you might want to click the SSL checkbox on Outgoing mail as well and it will look like below.

  7. If you set up IMAP for the first time, you will want to go to IMAP tab and set the Root folder path: to be a subdirectory name where you want your mail folders to live in your home directory. If you do not have it set, the Outlook will ask the IMAP server to load all subdirectories in your home directory!!, and that could take a while for a large home directory.

  8. You might want to review other property tabs. Click OK and then Close when you are done. The Outlook will ask you to load or refresh your folders. Click Yes.

Windows Eudora 5.1 Setup (IMAP/POP)

This is a sample of how to set up Eudora 5.1 to use POP with plain-text password authentication over TLS/SSL. The IMAP setup is similar to the setup.

Start Eudora. Go to the Tools dropdown menu, click on Options and select Incoming Mail. Select POP for the Server configuration and you should see the following page:

Select Passwords for Authentication style and click on other options as appropriate. Now change option to Checking Mail. You should get a page like below:

Enter your Mail Server and Login Name, and set appropriate values to other entries. For Secure Sockets when Receiving at the end of the page, select Required, STARTTLS.

Try retrieving your mail. You will get an error message similar to the following:

    Logging into POP server, USER chucky [current time]
    SSL Negotiation failed: Certificate Error: Cert Chain not trusted.
    Try adding this certificate to your certificate database for SSL to
    succeed.  Cause: [-6995]

Go to the Tools dropdown menu, click on Options and select Checking Mail. Click on Last SSL info button in the Secure Sockets when Receiving window.

Now, click on Certificate Information Manager. You should see a Server Certificate with a bone head. Select that certificate and click on View Certificate Details button and make sure it is *.mail.cs.washington.edu certificate issued by postmaster@cs.washington.edu.

Once you are done with viewing the certificate, click on OK button to go back to Certificate Information Manager. If the certificate looks okay to you, click on Add To Trusted. You should now have the certificate as a User Trusted Certificate. You can now exit from the Options tools and start getting your mails.

Netscape 4.7 Setup (IMAP)

Under Edit menu, go to Preferences and select Mail Servers. On Incoming Mail Servers dialogue window, select a server host you want to change and click Edit....

Now you should see the General tab of Mail Server Properties. The Server Type should be IMAP Server. Click on IMAP tab. Make sure the Use secure connection (SSL) is checked as in the picture below. Then click OK.

If your mail server is on a research host, you might want to set up your Outgoing mail Server as below; otherwise, click OK and start getting your mails.

The Outgoing mail Server and user name should be the same as your Incoming Mail Server setup and with SSL/TLS set to Always as in the picture above.

Windows Netscape 6 Setup (IMAP)

Windows Netscape 6 does not appear to have TLS/SSL with POP. The only way to use TLS/SSL is via IMAP. If you have not had IMAP server setup, you need to create a new IMAP account by selecting Mail/News account Settings from Edit drop-down menu. A Account Settings dialog box appears, and then click on New Account button and enter values as appropriate.

Once you have an IMAP account, from the Account Settings dialog box click on the Server. You should see a Server Settings dialog box like below where you can select to use SSL. Once it is selected, you should be able to authenticate with a CSE IMAP server afterward.

IMAP service

CSE IMAP server as installed verifies its user using the following 4 methods:

  1. Using rsh command to run rimapd on the server host.

    A user using this method need to have an official name of the client host in ~/.rhosts file. This method of starting up rimapd is used by PINE, and it is based on a trust on the client host.

    The program rsh, which has suid bit set, on the client host is trusted to make sure the account on the client host is the same account accessing an imap maildrop. This works from the fact that certain client network ports on Unix can be opened only by superuser of which rsh has the privilege -- This is not true on systems running Windows and on some Unix systems superuser may not be trusted.

    Due to a policy on security measures (OpNotes #1), the hostname in ~/.rhosts file can only be cs.washington.edu hosts and it is being enforced. However, CSE has a high turn-over rate of machines changing between Windows and Unix and between being trusted and non-trusted. With potentially out-of-date entries in ~/.rhosts, this verification method posed some risks.

    PINE will try to use rsh method first. However if there is a kerberos ticket present whether it is valid or not, PINE will use Kerberos Version 5 GSS-API Mechanism instead.

  2. Using Kerberos Version 5 GSS-API Mechanism (AUTH GSSAPI) to authenticate.

    At the present time, the GSSAPI method with the CSE installation can only use Kerberos Version 5 technology.

    Kerberos converts account name and password into a credential or a ticket which can be used to access kerberized services where the ticket owner is entitled to without a need of retyping in password. The ticket has a time limit around 8-10 hours. Most services need kerberos ticket at the startup time for authentication and authorization verification only, and users can continue using the services after their tickets have expired.

    When a user logs on a Unix CSE host using a password, the system automatically creates a kerberos ticket for the user (it is destroyed after the user logging out). If the ticket expires or is not available, the user need to issue Kerberos kinit command (from /usr/local/krb5/bin or from /usr/kerberos) to have a ticket. All Kerberos transactions are encrypted. With Kerberos technology, the original password is never stored and is never sent in plain-text or in encrypted form over the network.

    Kerberos technology is used with recent versions of Windows. Unfortunately, Kerberos may not be obviously accessible or compatible, and it is common for Windows email clients not to have GSSAPI implemented.

    For Unix, PINE uses GSSAPI if it finds a Kerberos ticket. However, if the ticket is invalid, it will fall back to use a clear-text login prompting users for a login name and password.

  3. Using IMAP4 login mechanism.

    This is part of standard IMAP4 (Internet Message Access Protocol - Version 4) protocol. Most email clients implement this. A user simply types in an account name and password, and the client program sends them in the clear on the network to the IMAP server to authenticate.

    This method of authentication will be turned off by August 23, 2001.

  4. Encrypting a session before an authentication (Using TLS with IMAP, POP3 and ACAP).

    Within this method, before a client authenticates with the server it can request the IMAP server to start using encryption with TLS (The TLS Protocol Version 1.0) and then authenticates using either GSSAPI or a simple login. This makes the unsafe IMAP4 login mechanism safe over the network. Unlike the other authentication methods above, the email data contents are also encrypted.

    At CSE, a self-signed certificate is used for email services, and there is no root certificate authority (root CA) involved. At the very first TLS/SSL session, the server sends a public key to the client. Rather than accepting the certificate quietly, a good client prompts the user and ask for an acceptance of that certificate. If the certificate is accepted, the certificate will be used to encrypt/decrypt the current session, and the future sessions if the certificate is permanently accepted.

    A user need to be wary in accepting a certificate. It is possible to fake a host and a user might be given a certificate to accept from a fake IMAP server. If the certificate is unknownly accepted and a password is sent to make a connection, the password can be captured. More details on certificate are below.

Users, who do not exclusively have an exchange mailbox nor a private mailbox, have all 4 methods available on their mail servers at the address user.mail.cs.washington.edu, where user is the account name. By the end of August 2001, only 3 methods are available, i.e., rsh, GSSAPI, and TLS/SSL with login and GSSAPI authentication methods.

POP service

The CSE POP3 service, similar to IMAP service, has RPOP (like rsh method), simple login (USER/PASS commads in Post Office Protocol - Version 3), and simple login over TLS/SSL channel (Using TLS with IMAP, POP3 and ACAP). There is no GSSAPI implemented in CSE POP3 service; however, it is being considered. The use of the 3 authentication methods are as follows:

  1. RPOP method.

    The only software using this method is MH's inc command which has a suid bit set as with rsh. The command, like rsh, requires a maintenance of ~/.rhosts file. However, there is a security risk with a suid program especially for inc which is not actively maintained. A replacement for RPOP is being sought for inc.

  2. USER/PASS method.

    This method sends the user name via USER command followed by PASS command with unencrypted password. This method of authentication is implemented by all POP3 clients. Due to security risk, it will be turned off by August 23, 2001.

  3. Encrypting a session before an authentication (Using TLS with IMAP, POP3 and ACAP).

    This is the same as the IMAP service above.

There is also an APOP authentication method as explained in Post Office Protocol - Version 3 which is implemented by some mail clients. The APOP protocol does not send plain-text password in the clear so it is safe; however, the protocol requires the server to store shared secret or password in plain-text. This is not possible to implement on CSE servers since no shared secret in its original form is stored or can be derived on CSE hosts.

SMTP service

When a client need to send mail out using an Outgoing Mail Server, it will normally do so via SMTP (Simple Mail Transfer Protocol). Over the recent years, the CSE SMTP service has been restricted in receiving mail from non-cse client hosts. Mails from a non-cse client host are not allowed to go to another non-cse host via CSE server, to prevent the server from being used as a mail relay by spammers. Mail from a non-cs client host can be delivered only to local CS addresses. There is no restriction if mail is originated from a local CSE host.

Users have been advised to use an SMTP service from his/her ISP for outgoing mails. Unfortunately, some users experienced unacceptable delays with ISP mail servers for mails destined to CSE users.

To broaden the service to our users on external hosts, the SMTP service is being reopened by the following methods:

  1. A host, after connecting to IMAP/POP service and authenticated, is allowed to relay mail in a period of 30 minutes (Dynamic Relay Authorization Control). That means a user need to log on via IMAP or POP service within 30-minute period before sending a mail.
  2. A user can log on directly to the SMTP service. This can be done by setting up an outgoing mail connection to use TLS/SSL (RFC2487, SMTP Service Extension for Secure SMTP over TLS) and then log on by using the user's account and plain-text password (AUTH PLAIN, RFC2554, SMTP Service Extension for Authentication). Since this method is based on user and is more reliable, it is preferred.

The SMTP service has been opened on all main research Unix mail servers since the middle of August 2001, and the service is expected to be opened to instructional users by the beginning of fall quarter.

If you are using mail interface on a CSE host and you have no need to protect your mail on the network, there is no need to set up the client to do authentication in order to send mail since a mailer on CS hosts can send mail out already without any authentication.

NNTP service

The CSE NNTP (Network News Transfer Protocol) server has an authentication for external non-cse hosts implemented as in RFC 2980, Common NNTP Extensions. A single password as advertised on news service is used over an uncrypted channel for authentication. The password is sent in the clear and is supposed to be changed periodically. No authentication is needed for users on cse hosts.

Since it has been implemented, no password has been changed. The password requires a maintenance by system personnel and the change of password can cause some interruptions to users. It is likely the single password method will be abandoned in favor of using NNTP session over TLS/SSL with user's own login password. No date has been set for this change yet.

ACAP service

An ACAP (Application Configuration Access Protocol) server allows a user and/or a system administrator to store information without the needs of entering user and server information on the local client. CSE has no support for ACAP at this time.

Eudora PC Version 5.1 has a ACAP feature available in Auto Configure option. A preliminary test of the feature with Cyrus SML acapd did not yield a good result. This service need to be revisited when there are more ACAP capable clients.

Directory service

A LDAP (Lightweight Directory Access Protocol (v3)) directory service for looking up CSE addresses is being set up at CSE. The LDAP Server is directory.cs.washington.edu and search root is ou=Computer Science & Engineering,o=University of Washington,c=US.

A new version of PINE and EXMH programs, which will be installed on CSE hosts, will have the LDAP lookup in their address database configured by default. The service is currently accessible by any cs.washington.edu hosts without authentication.

Server Certificates

A server's public X.509 certificate and its private key are used to encrypt and decrypt transmission between client and server. It is expected that users know how to manage their (server) certificates to ensure that they have the right server connected before accepting a certificate, and to remove a certificate if it becomes expired or compromised.

One single wildcard self-signed certificate with CN of *.mail.cs.washington.edu is used on the server in order for SSL/TLS to work across all servers . The expiration date on the certificate is set to expire by the end of the summer quarter of each year. This is so that the certificate is reissued in the summer quarter.

Each year, a certificate is created from the original private key. The new certificate will have a different expiration date and a new serial number -- this is for user interface to recognize the change and to notify the user. The new public certificate is advertised as below for users to compare with their certificate.

If the private key has been compromised, a new private key and a new certificate must be reissued, and users should be told to remove the old compromised certificate. If the compromised certificate is not removed, some mail interfaces in particular a Windows version of netscape6 may not notify user of a new certificate, and keep on using the bad certificate ending up in SSL error.

Below is the current certificate of *.mail.cs.washington.edu:

 Certificate:
     Data:
 	Version: 1 (0x0)
 	Serial Number: 1 (0x1)
 	Signature Algorithm: sha1WithRSAEncryption
 	Issuer: C=US, ST=Washington, L=Seattle, O=University of Washington,
 	    OU=Computer Science & Engineering, 
 	    CN=*.mail.cs.washington.edu/Email=postmaster@cs.washington.edu
 	Validity
 	    Not Before: Jun 19 07:25:33 2001 GMT
 	    Not After : Oct  1 07:25:33 2002 GMT
 	Subject: C=US, ST=Washington, L=Seattle, O=University of Washington,
 	    OU=Computer Science & Engineering,
 	    CN=*.mail.cs.washington.edu/Email=postmaster@cs.washington.edu
 	Subject Public Key Info:
 	    Public Key Algorithm: rsaEncryption
 	    RSA Public Key: (1024 bit)
 		Modulus (1024 bit):
 		    00:c8:27:7a:fd:2d:8a:bc:88:0a:59:3f:d9:2a:fe:
 		    b9:58:07:e7:65:81:e2:6b:fc:71:40:33:9b:ad:73:
 		    fd:e9:97:0a:6d:a7:39:23:f8:4c:8e:5f:53:0d:66:
 		    31:b2:87:13:91:ad:2c:e8:a8:7e:4d:f7:b5:6c:0e:
 		    90:c6:24:37:a7:3a:55:b5:f9:d8:85:94:b4:c0:5c:
 		    71:71:45:d9:17:9d:0b:b3:78:80:75:02:37:b4:1b:
 		    ba:05:14:05:1d:ad:f0:c8:37:e5:92:21:47:e6:20:
 		    17:e8:0f:d4:b2:5d:e4:75:37:03:88:1c:31:b0:88:
 		    8e:e9:2f:4b:1c:91:7d:c3:db
 		Exponent: 65537 (0x10001)
     Signature Algorithm: sha1WithRSAEncryption
 	5a:b9:d6:2d:3d:52:5c:ca:e2:95:5c:59:f7:08:f7:b2:da:9b:
 	98:36:df:95:91:c6:db:a0:fc:b0:12:ef:23:bd:76:c4:d5:6c:
 	43:96:c4:90:d9:7d:0f:cc:31:46:d5:d6:11:79:b7:83:26:91:
 	8b:9e:21:82:c6:bc:e1:76:40:88:45:73:dd:8b:cd:e9:8b:ef:
 	3a:00:a9:23:fa:ed:01:e5:7b:24:1b:bb:84:cb:77:91:92:31:
 	33:b5:d5:95:e9:49:2c:26:92:fa:58:ba:75:86:50:08:0f:94:
 	9c:ae:71:e5:bd:ef:45:3b:6e:5c:ab:62:e0:8f:37:fe:84:bf:
 	78:f0

$Revision: 1.3 $ $Date: 2005/09/22 20:27:35 $