1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Wed Jan 21 15:19:25 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Wed Jan 21 17:26:18 2009 +0100
     1.3 @@ -93,15 +93,16 @@
     1.4  
     1.5  
     1.6  \paragraph{\RF6: Authentication}
     1.7 -One thing to avoid is being an \name{open relay}. Open relays allow to relay mail from everywhere to everywhere. This is a source of spam. The solution is restricting relay\footnote{Relaying is passing mail, that is not from and not for the own system, through it.} access. It may be also wanted to refuse all connections to the \MTA\ except ones from a specific set of hosts.
     1.8 +\label{requirement-authentication}
     1.9 +One thing to avoid is being an \name{open relay}. Open relays allow to relay mail from everywhere to everywhere. This is a source of spam. The solution is restricting relay\footnote{Relaying is passing mail, that is not from and not for the own system, through it.} access. It may also be wanted to refuse all connections to the \MTA\ except ones from a specific set of hosts.
    1.10  
    1.11 -Several ways to restrict access are available. The most simple one is restriction by the \NAME{IP} address. No extra complexity is added this way, but the \NAME{IP} addresses have to be static or within known ranges. This approach is often used to allow relaying for local nets. The access check can be done by the \MTA\ or by a guard (e.g.\ \NAME{TCP} \name{Wrappers}) before. The main advantage here is the minimal setup and maintenance work needed. This kind of access restriction is important to be implemented.
    1.12 +Several ways to restrict access are available. The most simple one is restriction by the \NAME{IP} address. No extra complexity is added this way but the \NAME{IP} addresses need to be static or within known ranges. This approach is often used to allow relaying for local nets. The access check can be done by the \MTA\ or by a guard (e.g.\ \NAME{TCP} \name{Wrappers}) before. The main advantage here is the minimal setup and maintenance work needed. This kind of access restriction is important to be implemented.
    1.13  
    1.14  This authentication based on \NAME{IP} addresses is impossible in situations where hosts with changing \NAME{IP} addresses, that are not part of a known sub net, need access. Then a authentication mechanism based on some \emph{secret} is required. Three common approaches exist:
    1.15  \begin{enumerate}
    1.16  	\item \SMTP-after-\NAME{POP}: Uses authentication on the \NAME{POP} protocol to permit incoming \SMTP\ connections for a limited time afterwards. The variant \SMTP-after-\NAME{IMAP} exists too.
    1.17  	\item \SMTP\ authentication: An extension to \SMTP. It allows to request authentication before mail is accepted. Here no helper protocols are needed.
    1.18 -	\item Certificates: The identity of a user or a host is confirmed by certificates that are signed by trusted authorities. Certificates are closely related to encryption, they do normally satisfy both needs: \NAME{SSL} tunnels encrypt the data transmission and allow to identify the remote user/host by his certificate.
    1.19 +	\item Certificates: The identity of a user or a host is confirmed by certificates that are signed by trusted authorities. Certificates are closely related to encryption, they do normally satisfy both needs---encrypt the data transmission and allow to identify the remote user/host by his certificate.
    1.20  \end{enumerate}
    1.21  At least one of the secret-based mechanisms should be supported.
    1.22  

     2.1 --- a/thesis/tex/5-Improvements.tex	Wed Jan 21 15:19:25 2009 +0100
     2.2 +++ b/thesis/tex/5-Improvements.tex	Wed Jan 21 17:26:18 2009 +0100
     2.3 @@ -1,10 +1,10 @@
     2.4  \chapter{Improvement plans}
     2.5  
     2.6 -<< what to implement how in future >>
     2.7 +The last chapter came to the result that further development is best done in a double-strategy. First the existing code base should be improved to satisfy the most important needs in order to make it usable for some more time. Then \masqmail\ should get redesigned from scratch and rebuild to gain a secure and modern \MTA\ architecture for the future.
     2.8  
     2.9 -short time goals on current code: first part.
    2.10 +This chapter finally gives concrete suggestions \emph{how} to realize these plans.
    2.11  
    2.12 -long time goal, a new architecture: second part.
    2.13 +The first part covers the short-time goals which base on current code. The second part deals with the long-time goal---the redesign.
    2.14  
    2.15  
    2.16  
    2.17 @@ -17,30 +17,25 @@
    2.18  
    2.19  \subsubsection*{Encryption}
    2.20  
    2.21 -Electronic mail is very weak to sniffing attacks, because all data transfer is unencrypted. This concerns the message's content, as well as the email addresses in header and envelope, but also authentication dialogs that may transfer plain text passwords (\NAME{PLAIN} and \NAME{LOGIN} are examples). Adding encryption is therefor wanted.
    2.22 +Encryption should be the first funtionality to add to the current code. This requirement was already discussed on page \pageref{requirement-encryption}. As explained there, \NAME{STARTTLS} encryption---as defined in \RFC\,2487---should be added to \masqmail.
    2.23  
    2.24 -The common way to encrypt \SMTP\ dialogs is using \name{Transport Layer Security} (short: \TLS, successor of \NAME{SSL}). \TLS\ encrypts the datagrams of the \name{transport layer}. This means it works below the application protocols and can be used by any of them\citeweb{wikipedia:tls}.
    2.25 +Adding encryption requires changes mainly in three source files: \path{smtp_in.c}, \path{smtp_out.c}, and in \path{conf.c}.
    2.26  
    2.27 -\TLS\ allows to create secure tunnels through which arbitrary programs can communicate. Hence one can add secure communication afterwards to programs without changing them. \name{OpenSSL} for example---a free implementation---allows traffic to be piped into a command; a secure tunnel is created and the traffic is forwarded through it. Or a secure tunnel can be set up between a local and a remote port; this tunnel can then be used by any application.
    2.28 +The first file includes the functionality for the \SMTP\ server. It needs to offer \NAME{STARTTLS} support to clients and needs to initiate the encryption when the client requests it. Additionally, the server should be able to insist on encryption before it accepts any message.
    2.29  
    2.30 -The \NAME{POP} protocol, for example, is good suited for such tunneling, but \SMTP\ is is not generally. Outgoing \SMTP\ client connections can be tunneled without problem---\masqmail\ already provides a configure option called \texttt{wrapper} to do so. Tunneling incomming connections to a server leads to problems with \SMTP. As data comes encrypted through the tunnel to the receiving host and gets then decrypted and forwarded on local to the port the application listens on. From the \MTA's view, this makes all connections appear to come from localhost, unfortunately. Figure \ref{fig:stunnel} depicts the data flow.
    2.31 +The second file includes the functionality for the \SMTP\ client. It should start the encryption by issuing the \NAME{STARTTLS} keyword if the server supports it. It should be possible to send messages only if encryption is possible.
    2.32  
    2.33 -For incoming connections, \NAME{STARTTLS}---defined in \RFC2487---is what \mta{}s implement.
    2.34 +The third file controls the configuration files. New configuration option need to be added. The encryption policy for incoming connections needs to be defined. Three choises seem necessary: no encryption, offer encryption, insist on encryption. The encryption policy for outgoing connections should be part of each route setup. The options are the same: never encrypt, encrypt if possible, insist on encryption.
    2.35  
    2.36 -\masqmail\ is already able to encrypt outgoing connections, but encryption of incoming connections, using \NAME{STARTTLS} should be implemented. This only affects the \SMTP\ server module.
    2.37 +\NAME{STARTTLS} uses \NAME{TLS} encryption which is based on certificates. Thus the \MTA\ needs its own certificate. This should be generated during installation. A third party application like \name{openssl} should be taken for this job. The encryption itself should also be done using an available library. Open\NAME{SSL} or a substitute like Gnu\NAME{TLS} does then become a dependency for \masqmail. Gnu\NAME{TLS} seems to be the better choice because the Open\NAME{SSL} license is incompatible to the \NAME{GPL}, under which \masqmail\ and Gnu\NAME{TLS} are covered.
    2.38  
    2.39 -%TLS/SSL prevents attackers to listen on the cable
    2.40 -%but it does not prevent man-in-the-middle attacks
    2.41 -%signed certificates help here
    2.42 -%   or PGP encryption
    2.43 +User definable paths to \masqmail's secret key, \masqmail's certificate, and the public certificates of trusted \name{Certificate Authorities} (short: \NAME{CA}s) are also nice to have.
    2.44  
    2.45  
    2.46 -%do not use stunnel wit SMTP:
    2.47 -%because all incoming mail would be from 127.0.0.1 !!
    2.48 -%use STARTTLS instead
    2.49 +<< TLS patch of qmail >>
    2.50  
    2.51  %postfix: main.cf
    2.52 -%\begin{verbatim}
    2.53 +%
    2.54  %	smtpd_use_tls = yes
    2.55  %	smtpd_tls_received_header = no (does not log in received headers)
    2.56  %
    2.57 @@ -52,45 +47,37 @@
    2.58  %	smtp_tls_key_file = /etc/postfix/key.pem
    2.59  %	smtp_tls_cert_file = /etc/postfix/cert.pem
    2.60  %	smtp_tls_CA_file = /etc/postfix/CAcert.pem
    2.61 -%\end{verbatim}
    2.62  
    2.63  
    2.64  
    2.65  
    2.66  \subsubsection*{Authentication}
    2.67  
    2.68 -Several ways to restrict access are available. The most simple one is restrictiction by the \NAME{IP} address. No extra complexity is added this way, but static \NAME{IP} addresses are mandatory. This kind of restriction may be enabled using the operating system's \path{hosts.allow} and \path{hosts.deny} files. To allow only connections to port 25 from localhost or the local network \texttt{192.168.100.0/24} insert the line ``\texttt{25: ALL}'' into \path{hosts.deny} and ``\texttt{25: 127.0.0.1, 192.168.100.}'' into \path{hosts.allow}.
    2.69 +Authentication is the second function to add; it is important to restrict the access to \masqmail, especially for mail relay. The requirements for authentication where identified on page \pageref{requirement-authentication}.
    2.70  
    2.71 -If static access restriction is not possible, for example if mail from locations with changing \NAME{IP} addresses wants to be accepted, some kind of authentication mechanism is required. Three common kinds exist:
    2.72 +Static access restriction, based on the \NAME{IP} address is already possible by using \name{TCP Wrappers}. This makes it easy to refuse all connections from outside the local net for example, which is a good prevention of being an open relay. More detailed static restrictions, like splitting between mail for the system and mail to relay, should not be added to the current code. This may be a concern for the new design.
    2.73  
    2.74 -\begin{enumerate}
    2.75 -	\item \SMTP-after-\NAME{POP}: uses authenication on the \NAME{POP} protocol to permit incoming \SMTP\ connections for a limited time afterwards.
    2.76 -	\item \SMTP\ authentication: is an extension to \SMTP. Authentication can be requested before mail is accepted.
    2.77 -	\item Certificates: confirm the identity of someone.
    2.78 -\end{enumerate}
    2.79 +Of the dynamic, secret based, authentication methods (\SMTP-after-\NAME{POP}, \SMTP\ authentication, and certificates) the first one drops out as it requires a \NAME{POP} server running on the same or a trusted host. \NAME{POP} servers are rare on workstations and home servers do also not regularly include them. Thus it is no option for \masqmail.
    2.80  
    2.81 -The first mechanism requires a \NAME{POP} (or \NAME{IMAP}) server running on the same host (or a trusted one), to enable the \SMTP\ server to use the login dates on the \NAME{POP} server. This is a common practice used by mail service providers, but is not adequate for the environments \masqmail\ is designed for.
    2.82 +Authentication based on certificates does suffer from the certificate infrastructure that is required. Although certificates are already used for encryption, its management overhead prevented wide spread usage for authentication.
    2.83  
    2.84 -Certificate based authentication, like provided by \NAME{TLS}, suffers from the overhead of certificate management. But \NAME{TLS} provides encryption too, so is useful anyway.
    2.85 -
    2.86 -\SMTP\ authentication (also refered to as \NAME{SMTP-AUTH}) suppoert is easiest received by using a \name{Simple Authentication and Security Layer} implementation. \person{Dent} sees in \NAME{SASL} the best solution for authenticating dynamic users:
    2.87 +\SMTP\ authentication (also refered to as \NAME{SMTP-AUTH}) support is easiest received by using a \name{Simple Authentication and Security Layer} (short: \NAME{SASL}) implementation. \person{Dent} sees in \NAME{SASL} the best solution for dynamic authentication of users:
    2.88  \begin{quote}
    2.89  %None of these add-ons is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of your users' mail pass through your system no matter where they are on the Internet, SASL is probably the solution that offers the most reliable and scalable method to authenticate users.
    2.90  None of these [authentication methods] is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of your users' mail pass through your system no matter where they are on the Internet, \NAME{SASL} is probably the solution that offers the most reliable and scalable method to authenticate users.
    2.91  \hfill\cite[page 44]{dent04}
    2.92  \end{quote}
    2.93  
    2.94 +In the meanwhile is \NAME{SMTP-AUTH} supported by most email clients and if encryption is used then even insecure authentication methods like \NAME{PLAIN} and \NAME{LOGIN} become secure.
    2.95  
    2.96 -Compare static with dynamic authentication: pros and cons; usecases: when to use what; how could this be covered by architecture (e.g. smtp submission).
    2.97 -%either by
    2.98 -%- network/ip address
    2.99 -%	easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
   2.100 -%or
   2.101 -%- some kind of auth (for dynamic remote hosts)
   2.102 -%	adds complexity
   2.103 -%	- SASL
   2.104 -%	- POP/IMAP: pop-before-smtp, DRAC, WHOSON
   2.105 -%	- TLS (certificates)
   2.106 +<< what to do in code (same like for enc?) >>
   2.107 +
   2.108 +<< where to store login data >>
   2.109 +
   2.110 +
   2.111 +<< Compare static with dynamic authentication: pros and cons; usecases: when to use what; >>
   2.112 +
   2.113 +<< how could this be covered by architecture (e.g. smtp submission). >>
   2.114  
   2.115  
   2.116  
   2.117 @@ -107,6 +94,8 @@
   2.118       +--------+     |||||     +--------+
   2.119  \end{verbatim}
   2.120  
   2.121 +<< refer back to enc and auth >>
   2.122 +
   2.123  
   2.124  \subsubsection*{Reliability}
   2.125