Project.tex

% !TeX root = Fenrir.tex


\part{The project, Fenrir}[standards.png][The good thing about standards is that there are a lot to choose from...]

\chapter{Overview}

\section{Fenrir}

What we are looking for is something that not only can fully handle the various data delivery options, but mainly something that finally has a good support for
both federation and authorization, along authentication.


\begin{figure}[h]
    \centering
    \includegraphics[width=0.5\textwidth]{images/Fenrir_logo.png}
    \caption{Fenrir Logo}
    \label{fig:Fenrir_Logo}
\end{figure}



\section{Federated Authentication}

The main feature is -obviously- the federated authentication. This means that we will need some form of interaction between the server of multiple
independent domains, with each trusting only their users. Therefore, ueach user will be identified by its user and domain, in email-like format.

For this, we use the distinction provided by kerberos for our system, and we divide the players into three (plus one):

\index{Client Manager}\index{Authentication Server}\index{Federation}
\begin{itemize}
\item \textbf{Authentication Server}: in short: \textbf{AS}. Handles authentication and authorization for its domain.
\item \textbf{Service}: the service the client wants to use. Be it the mail service or a web service.
\item \textbf{Client}: the user program that connects to a \textit{Service}
\item \textbf{Client Manager}: the program that manages authentication data for the user.
\end{itemize}

\subsection{Authentication decoupling}\index{Authentication!Decoupling}\index{Decoupling}

The first two distinctions are fairly straightforward: the authentication server will handle authentication, so that the service can be designed without having
access -for example- to the password database or to the user login. This is an important distinction, as the applications are a lot vulnerable to bugs and
have a much higher attack surface. By decoupling the two user and password databases should be better protected, as the only application that has
access to them is the one especially designed to protect them.

The distinction between \textit{Client} and \textit{Client Manager} has the same purpose. Current applications usually save login information in cleartext,
or in a poorly-obfuscated manner (base64 and alike). For the same reasons as before, we want to decouple application authentication from the
application itself. This will permit the system-wide usage of strong authentication methods like security tokens or smart cards, provide better support
for authentication algorithms, instead of having clients rely to old methods like the deprecated SSLv3, and over time will provide better security for
the next legacy applications, as the security of the application will be upgradable regardless of the application itself.

Decoupling authentication from the application will have one more interesting outcome: as the \textit{Client Manager} will handle both authorization and
authentication, it will be able to limit the application scope, so that the user will be able to limit the applications it does not trust, or that only need to
check for the existence of an account.

This means that both the \textit{Authentication Server} and \textit{Client Manager} will be the primary subject of the attacks towards Fenrir, but this also means
that the attack surface will be much lower, and the efforts can be concentrated in a single software.\\
As popular software is migrating towards the web, this situation is increasingly common anyway, as the web browsers need to track each and every user
password, and users do not care about security, which means that the password database will be in clear text; moreover the attack surface of a
browser is huge, especially thanks to its plugin system.

Users have always had a bad connection with security. Forcing them to use and remember hundreds of different passwords will obviously result in
password reuse, weak passwords and general adversity towards security. Collapsing hundreds of password to a single login (thanks to federation)
and hardening the client manager will create a single point of failure, (which is already present in the form of browsers), but will increase the difficulty
level needed for attacks to succeed, therefore increasing overall security.\\

\subsection{The algorithm}

The in-depth algorithm is discussed in chapter \ref{FederationAlgorithm}, only an outline is presented here.

Federated authentication algorithms are nothing new. As per our earlier distinction, we will focus on a kerberos-like infrastructure.\\
Due to the decoupling previously introduced, our protocol needs some way to tell the various interacting players that a user has a certain authentication and
authorization. This is done through the use of a token, so that login and passwords will not reach the \textit{Client} or the \textit{Service}.\\


One characteristic of a lot of authentication algorithms is the usage of timestamps to protect the authorization tokens or general messages.
While this provides safety by putting an expiration time on the usage of said tokens, it also means that applications, servers and authentication servers must
have at least a loosely-synchronized clock.

Although nowadays clock synchronization seems easy and widespread, it is not yet at a state were we can safely assume that the clocks are little discrepancy.
Embedded devices are still produced without a clock source, so each time they are booted the clock is reset to 1970. The most famous clock synchronization
protocol (NTP) is used almost always in clear text, and basing our clock on the attacker's request is not pretty.\\
Requiring all clocks in the world to be synchronized between a couple of minutes from each other, even for devices that do not have stable clock
sources is in our opinion wrong. Therefore Fenrir will \textit{not} use timestamps. This will mean that occasionally additional round trips will be needed
to check the validity of the data, but this also means that tokens can be simplified, as they do not need signatures anymore, and a token revocation will be
effective immediately.

As the figure below describes it, the protocol will relay heavily on the authentication servers, which will act as a trusted third party. The image is only
an outline, and assumes a shared token between client@example.com and the authentication server on example.com


\label{FederationExample}
\begin{figure}[h]
\centering
\begin{framed}

\centering
\begin{tikzpicture}[node distance=4cm,>=stealth]
\node[label=above:{Auth.Srv example.com}] (AS1) {\includegraphics[width=2cm,keepaspectratio]{images/auth_server.png}};
\node[label=above:{Auth.Srv domain.com}, right= 3.5 cm of AS1] (AS2) {\includegraphics[width=2cm,keepaspectratio]{images/auth_server.png}};
\node[below of=AS2,left=2.5cm of AS2, label=below:{Client example.com}] (C) {\includegraphics[width=2cm,keepaspectratio]{images/computer.png}};
\node[below of=AS2,right=1.5cm of AS2, label=below:{Service domain.com}] (S) {\includegraphics[width=2cm,keepaspectratio]{images/server.png}};

\draw[<-,thick] (AS2.180) -- node[below]{$1: auth, use ``service''$} (C.90);
\draw[<->,thick] (AS1.30) -- node[below]{$2: check account$} (AS2.150);
\draw[->,thick] (AS2.340) -- node[right]{$3: new user: id, keys$} (S.60);
\draw[<-,thick] (AS2.300) -- node[below]{$4: user registered$} (S.120);
\draw[->,thick] (AS2.250) -- node[below]{$5: ok: ip, keys$} (C.20);
\draw[<->,thick] (C.340) -- node[below]{$6: communication$} (S.200);
\end{tikzpicture}
\end{framed}
\caption{Fenrir overview: client@example.com connects to ``service'' in domain.com}
\end{figure}

The diagram describes the interaction of different domains as the flow is obviously simplified in the case of single domain logins.

The service will not receive the login data, and in fact will only get a connection id, cryptographic keys and an internal user id. As confirmation, the client
will receive the ip, connection id and keys to connect to the service, so that no other handshakes are needed.

The authentication server will receive a lot of trust from the user, as it needs to control its authentication and authorization data, but it will not be able to
impersonate the user on different domain's services, as the service and the user will also share a secret key. There will still be room for impersonating a
client on the same domain, although that is technically unavoidable with any design due to the service and the authentication server belonging to the same
organization (authentication and logs can always be forged by administrators that control the services). More on this on section \ref{Attacks}




\section{Transport}

\subsection{Layer 4: UDP tunnel}\index{Transport UDP}

The SCTP protocol history tells us that introducing new functionalities while being incompatible with existing network infrastructure is like asking to fail.
However it also tell us that a UDP-based protocol can move up to a standalone one, given enough traction. SCTP evolved maybe too quickly from udp based to standalone, firewalls worldwide did not update, and very few applications ended up using it.

Due to these motivations our protocol will be based on top of IP, but will include a UDP as a lightweight tunnel in its main components so that existing
infrastructure will not have problems using it.

Using UDP as a lightweight tunnel permits us to use a single socket for transmission or reception of every connection, without having the kernel track
for us every connection. Firewalls will permit UDP connections, as the DNS system is based on that, and NATs will continue working as always.\\
Having only one socket for everything permits us to handle everything in user space, and we also avoid the hell of connection tracking of protocols
like FTP, that use multiple TCP connections in an attempt to separate data contexts.

Userspace connection tracking will prove useful for an evolving protocol, as we don't have to wait new kernel releases, patches or other to update or test
variations of the protocol. It will also make it easier to port the project to multiple operative systems, as the kernels do not need to be touched.


\subsection{Layer 4.5: Fenrir}

\subsubsection{Connection}

The very first thing we need is something to identify the connection. older protocols use the tuple of source IP, destination IP, source and destination PORT,
but this is unnecessary and spans multiple protocols which should be independent. The solution is simply to use a single identifier as the connection id.
This alone grants independence from the IP layer, enabling us to support multihoming and mobile clients, and all encryption data will be based on this id.

Once we identified the connection we need to check whether it is a legitimate packet. In order, the first things we will do is check if the packet is corrupted
through an error correction code, then check the packet legitimacy by checking a cryptographic header (HMAC like), then finally decrypting the
packet and access its contents.\\
The last two steps can be condensed into one if we use AEAD ciphers (Authenticaed Encryption -- Additional Data).

The algorithm to used will be decided during handshake: this might make us use one full RTT, but unlike minimaLT, we won't be tied to a single algorithm,
so that if problems are found in the future, we can simply shift to a new algorithm instead of throwing away the whole protocol.

With this setup, all data out of the connection id will be encrypted and authenticated. Regarding the encryption,  4 methods are available:

\begin{itemize}
\item \textbf{MAC then Encrypt} : First authenticate the cleartext data, then encrypt everything. Used in TLS.
\item \textbf{Encrypt AND MAC} : authenticate the cleartext, encrypt the cleartext and transmit both the authenticated and encrypted payload in cleartext.
Used in SSH.
\item \textbf{Encrypt then MAC} : Encrypt the cleartext, then authenticate the encrypted cleartext. Used in IPSEC.
\item \textbf{Authenticated Encryption}: new algorithms can authenticate data while encrypting it, so that no additional headers are required.
\end{itemize}

These various methods were analyzed in 2008\cite{Bellare:2008:AER:1410264.1410269}, and in 2009 even the ISO/IEC committee proposed a
standard\cite{ISOIEC19772} where the recommended mode of encryption is \textbf{Encrypt-then-MAC}. Authenticated encryption algorithms were born later
but are regarded to be as secure as the ISO proposed method.

A short summary of the analysis mentioned earlier:
\begin{itemize}
\item \textbf{MAC then Encrypt} : Only the cleartext is authenticated. If the cipher is malleable, the attacker can change both the MAC and the cleartext.
This is what happened in WEP.
\item \textbf{Encrypt AND MAC} : The MAC is not secret, thus can reveal some information on the cleartext (especially in context were data is mostly static).
It does not grant ciphertext integrity.
\item \textbf{Encrypt then MAC} : ciphertext integrity is granted, so cleartext integrity is granted by composition. Authenticity can be verified before
decryption.
\end{itemize}

Due to these reasons, the only modes available in Fenrir will be AEAD and encrypt-then-MAC. An example of a famous AEAD cipher is OCB3\cite{OCB:Online},
which is now an IETF draft\cite{OCBDraft}.\\
Recently the CAESAR\cite{CAESAR} competition was created to determine a standard from the various AEAD ciphers, the winner is expected to be announced
somewhere towards the end of 2017 / beginning of 2018.

Due to the inclusion of the AEAD ciphers, and the fact that different authentication headers can have different lengths, the actual length (or existence) of
the authentication header is tied to the connection and decided during the handshake, and thus will not be specified in the packet.

To help in debugging and for specific applications, cleartext data transmission should be supported (although always authenticated). While authentication
is always needed, encrypting public data might be a lot of work for resource constraint devices, so it should be possible to explicitly disable it.

\rowcolors{1}{green}{green}
\begin{tabularx}{0.7\textwidth}{| l || X | X | X | X |}
\hline \hline
\hiderowcolors bytes &0&1&2&3\\ \hline \hline
  0-3 & \multicolumn{4}{c|}{Connection id} \\ \hline
  & \multicolumn{4}{c|}{Encrypted data} \\ \hline
    & \multicolumn{4}{c|}{Authentication header} \\ \hline \hline
\end{tabularx}

\subsubsection{Multi Stream}\index{stream}

After granting secrecy and authenticity, we need to provide an easy way to multiplex the user and protocol data.

Not providing a multiplexing service will bring developers to recreate protocols like FTP, using multiple connections, which is hard to track for firewalls and
is more complex to maintain from the programmer point of view. This probably contributed to developers porting all their applications on the web, as all
those details are now handled by the web server. Then to avoid the limitations of the HTTP protocols the websockets and webrtc standards were created, so
that applications could ``downgrade'' the HTTP connection to a raw socket.

SCTP was the first protocol to try to fix these problems, and more recently SPDY(HTTP2) and QUIC implemented its main feature,
which is having \textbf{multiple streams}, so that the programmer can use one stream per resource, thus parallelizing network flow and managing multiple
connection characteristics (e.g.: unreliable vs reliable delivery) for the user.

Fenrir uses the same base idea as SCTP, so while QUIC and other protocols provide only multiplexing, Fenrir can handle both datastream transmission and
datagram with message boundaries, thus relieving the user of the need to parse and handle message lengths or escape sequences to handle the begin and end
of the user messages.

To implement this, we need an header similar to the SCTP one, but it can be much simpler: we only need a stream id, the data length, a counter to be able
to reorder different fragments, and some flags to signal whether this is the first fragment, end of fragment, or a full user message.

Again, in order to provide maximum flexibility and to easier port existing applications to Fenrir, the protocol must not limit itself to ordered, reliable and
datastream delivery, or the programmer will be forced to use -yet again- other protocols in his application, thus decoupling the security provided by Fenrir
from the security of the application (which we want to avoid).

Although the setup is simple, we can now have a multiplexed transfer protocol, where each stream can handle a combination of ordered, unordered, reliable,
unreliable delivery in datastream or datagram mode, with automatic fragmentation between multiple packets.

SCTP has a lot of different headers, each having its own structure and purpose, but that increases the overall parsing complexity. Instead in Fenrir
even the protocol messages will be carried in a normal (reliable) stream, so we can simplify the parsing and waste less bytes on the header.

~\\

\rowcolors{1}{green}{green}
\begin{tabularx}{0.7\textwidth}{| l || X | X | X | X |}
\hline \hline
\hiderowcolors bytes &0&1&2&3\\ \hline \hline
  0-3 & \multicolumn{4}{c|}{Connection id} \\ \hline
  & \multicolumn{4}{c|}{Encryption Header} \\ \hline
\showrowcolors  4-7 & \multicolumn{2}{c|}{Stream id} & \multicolumn{2}{c|}{Data length} \\ \hline
  8-11 & flags & \multicolumn{3}{c|}{Stream counter} \\ \hline
\hiderowcolors    & \multicolumn{4}{c|}{Authentication header} \\ \hline \hline
\end{tabularx}
\begin{center}
The packet so far. Green color highlights the encrypted data
\end{center}

Since we have a full byte for flags, we can allocate the bits as follows:
\begin{itemize}
\item \textbf{0\-1}: start/end of user message. if none are present, it's an intermediate fragment.
\item \textbf{2\-4}: user message counter. Up to $2^{3}$ to easily distinguish messages in case of heavy packet loss and unreliable delivery.
\item \textbf{5\-7}: used as high-order bits of the next ``stream counter'' field, thus bringing the counter up to $2^{27}$ bits. \textbf{TODO: explain why}
\end{itemize}

Having a bigger stream counter will help in the case of high-latency-high-bandwidth links (like satellite links), were the time spent waiting for the ACK of the
first packet might be as much as the time spent filling the sliding window.

Having a message counter will be useful with unreliable, unordered data transfer: the stream counter alone does not tell us whether the lost packets had
a missing start or end flag, so even without rebuilding the data, we might be able to give partial data to the user while distinguishing the association to
different user messages (up to a certain point).

\subsection{Reliability mechanisms}

Since Fenrir is designed to work on top of the IP layer, we need to reimplement retransmission mechanisms and control flow algorithms.

The ACKs are designed based on the SCTP ones, where a single packet can ACK multiple segments of various streams (SACK). This means that
instead of just reporting the last received byte, we report the stream id along with the first and last byte of ack'd data. This allows us to ack even
non-sequential data, so that retransmission is more efficient, just like SCTP.\\

QUIC introduces a \textbf{Forward Error Correction}\index{Forward Error Correction} mechanism for transmitted data, which works a lot like RAID 5:
every two packets a third packet is sent which is the XOR of the previous two packets. This is a novel way to handle error correction in network transmission
protocols, but it is not flexible enough, as the correction does not spawn more than two consecutive packets, and can't be tuned to the average channel error
rate.

To fix this, Fenrir will use the RaptorQ \cite{rfc6330} error correction mechanism, a highly configurable code where an infinite number of error recovery packets
can be generated from a user-defined set of packets. Although the cpu and memory requirements can rise significantly with the set of packets that
we want to protect (quadratic memory, cubic cpu time), applying error correction to a set of a thousand packets is still relatively inexpensive.

Forward error correction will be activated only if requested, and per-stream, so that different reliability statuses can be achieved, depending on what
the programmer needs.



\section{The Handshake}\index{Handshake}

This part is crucial in the protocol design, as it needs to handle connection setup, negotiation of protocol features, cryptography details and more, but in the
less amount of packets possible, to improve efficiency.

Since this is a security protocol, we first need to pay attention to where the trust of the system comes from. The naive choice would be to use the widely
used Authority Certificate model, but this has its own problems. For now, let's just assume we can safely have a public key, somehow, and design the
handshake from that. We will analyze the trust model later in \ref{Trusting trust}.

For now, let's assume we safely obtained a public key and the minimum connection information.

In this critical phase we need to handle user authentication, authorization, can be subject to DDoS or amplification attacks, and needs to be as efficient
as possible.

Current protocol stacks perform poorly against DDoS protection thanks to the lower TCP layer and force the system to perform multiple handshakes
(TCP-TLS-OAuth). Fenrir also needs a flexible handshake, to avoid being tied to a single authentication method or encryption algorithm like minimaLT.

One feature in this area, introduced by both QUIC and minimaLT, is the support for multiple handshake types, depending on the information available
to the client.

The most secure handshakes can take up to 3 full round trips, but minimaLT and QUIC can go down to a 0-round-trip connection. Unfortunately
the handshake length and the overall security of the handshake seem to be inversely correlated, but some concessions can be made in terms of
security if the applications need a very low connection setup time.


The next chapter is dedicated to the security and design of the handshake. for now, we only need a way to quickly distinguish an handshake packet
from an established connection.

For this, we reserve the connection id ``0'' to connection setup, leave the packet completely in clear text. The stream identifier will be random,
and will help us track the different handshakes.

For the in depth details of the handshake, see the next chapter.


\chapter{Security}
\label{Trusting Trust}

We will now analyze in depth the handshake, the security and trust model that are the basis of the Fenrir protocol.

Authentication and authorization are left to chapter \ref{Credentials}

\section{Flexibility}

A lot of attacks on TLS concentrated on its complexity, its interaction with different version handshakes and ciphers. Thanks to this, new experiments
like CurveCP\footnote{\url{http://curvecp.org/}} and its successor, minimaLT\footnote{\url{http://cr.yp.to/tcpip/minimalt-20130522.pdf}} have tried to throw away all flexibility and concentrate on a single encryption algorithm. This made the protocols much more efficient and simple, but a single failure in the
cipher or protocol will mean that these protocols will have to be thrown away.

For this, and since the reason that TLS can still be used today is exactly thanks to its flexibility in both specification and cipher choice, Fenrir will have
multiple handshakes and use multiple ciphers. Moreover, there currently exists no stable, proven algorithm that can withstand quantum computer
attacks, so fixing ourselves on one or on a single set of choices might significantly lower the protocol life.


\section{Trust model}\label{trust_model}\index{Trust Model}

Every cryptographic system is based on the distribution of symmetric or asymmetric encryption keys. Distribution of keys means that we will have to trust
someone, as that someone will be able to forge and distribute keys that will completely undermine any system.

The most widely spread approaches to this are the PGP \textit{web of trust} and the \textit{public key infrastructure}
used with X.509 certificates by TLS and others.

The problem with the web of trust, is that trust is transitive: if I trust one key, then I'm implicitly trusting all the keys signed by that key. This means that
compromising a single key can lead the whole web to crumble. It also means that to know if a key is trusted, we need to traverse the whole web of trust.
This is not efficient, it vastly increases the attack surface and it also means that the validity of a signature depends on the web of trust we are using
(that is: there is no global state).\\
This approach has only been used by relatively small communities who can manually check the validity of the certificates.

The public key infrastructure works by trusting one or more central authorities that have the explicit task of verifying whether a certificate is owned by
it rightful owner. The problem with this approach is the reliability of said certificate authorities. In the past big organizations like COMODO had their
certificates stolen, or had lax security so that anyone could get a certificate even when they were not supposed to get one. Since the common computer
holds more than a hundred different authorities and since these authorities are located all over the word, even in countries with oppressive regimes,
this model is seen as lacking in trust. Still, it's the standard for trust systems nowadays.\\

Whatever the choice, a public key need to be transmitted with a format. Historically this format has been X.509. This is a big standard, dating back to 1988,
that received multiple corrections which made it very difficult to parse, as shown by the sizes of current parsers : the polished and simplified parser of libreSSL is currently more than 10.000 lines of C code, while the openSSL and GnuTLS versions are 25k and 35k lines respectively. This has been a real problem
that has been exploited multiple times in both he basic libraries (*SSL) and the programs that use these libraries.


There does not appear to be a solution for all the technical and political problems behind this, and as such Fenrir tries not to choose any of the two models.\\
The web of trust is hard to keep secure and is slower, while the public key infrastructure based on current certificate authorities is as secure for the
average user, but as good as broken for a lot of governments. The only choice Fenrir tries to enforce thus is to stop using the difficult X.509 certificate format,
and fall back to handling raw public/private keys.

Still, we need a way to get the public keys safely. The public key is the minimum and most important piece of information we need to safeguard, but we
might want to protect other data, such as the IP address resolving to the authentication server. Fenrir will not force a single method to get the necessary
information, as new and more secure systems might come out in the future, or some other trust model might be required.

\subsection{Connection information needed}

To setup a connection with TLS first we need to resolve the ip address of the server, then we connect to a specific port (e.g.:80/tcp for web) on the given
ip, then we get the certificate, check it against out trust model and server fqdn, then we can connect. This flow is very basic, but we can start by noting
a couple of things:
\begin{itemize}
\item the fqdn resolvers almost never use DNSSEC, and in fact the ip address is often intercepted and modified to support transparent proxies. Even if we
used DNSSEC, we would be leaking information such as whom we are connecting to.
\item the 80/tcp port identifies the service we are using. While the web is now ubiquitous, we are still leaking some of the protocol identification.
\item the certificate does not protect ip address(es), ports, and leaks the service fqdn (this is needed in TLS to support different certificates for the same
server).
\end{itemize}

Although difficult to exploit, we are leaking a lot of information, and we have to leak it due to the legacy of the internet development.
Efficiency has also suffered, as adding multiple fqdn-to-ip resolutions to the DNS systems make it necessary for the DNS packets first to increase
from a maxium size of 512 bytes to as much as the packet provides, and then we even had to switch to DNS over TCP to support even bigger records.
Such records are needed for load balancing, failover configurations, and integrating other information such as text, binary, encryption eys or signatures
into the DNS system.

Thanks to a clean design, we can now hide more information and increase flexibility and efficiency.

\subsection{DNSSEC resolution}\index{DNSSEC}

DNSSEC was the solution to requiring a secure fqdn-to-ip resolution, but it grately increase the size of each record, as every record brings cryptographic
signatures. However, we have records for everything we need:
\begin{itemize}
\item ip address(es): A, AAAA records
\item ports, ips, failover support: SRV records
\item public keys: specific formats (IPSEC, SSH...) or TXT records
\end{itemize}

As we are not using a common format, we can encode everything we need in a single TXT message, thus saving bandwidth, packets and round trips.
This will need to be encoded as most of this data is binary, so \textbf{base85} will be used as the encoding standard, as we need a text format, but
base64 is more inefficient.

We want to provide information on the authentication servers and even provide load balancing and fallback features.

The format can this be (in binary):
\begin{itemize}
\item \textbf{2 bytes}: udp port (port 0 mean to use raw IP)
\item \textbf{1 byte}: number of address structures, formed as:
  \begin{itemize}
  \item \textbf{1 byte}: bitfield for type and address priorities
    \begin{itemize}
    \item \textbf{0-1}: 00: ipv4 01: ipv6.
    \item \textbf{2-4}: priority group (for fallback)
    \item \textbf{5.7}: preference priority in the same group
    \end{itemize}
  \item \textbf{X bytes}: ip address. size dependent on previous ip type
  \end{itemize}
\item \textbf{Y * 2 bytes}: bitfield of supported authentication algorithms
\item \textbf{2 bytes}: public key type\label{DNSKEYID}
\item \textbf{2 bytes}: public key id
\item \textbf{Z bytes}: public key. size/format dependent on type.
\end{itemize}

This format is dynamic, has all the information needed, it's encoded from binary so we can't be more efficient than this in the DNS system, and
we have all the features that would otherwise require multiple DNSSEC records and signatures. As the published information regards only the authentication
server, and the services ips will be given from the A.S., a futher round of load balancing and failover can be applied directly inside the A.S., coupled
with geo-ip optimizations or further customizations as needed, without affecting the standards.

To better support the handshake algorithms, we can publish a list of supported asymmetric keys in the DNS (variable $Y$ above), that will hold a bitfield
of supported algorithms. when the last bit is 1, one more 16-bit bitfield is added.

We also have a complete decoupling between service and standard udp ports, and thus both our authentication server and services can be at any
port the administrator wants. This will help in setting up multiple services and domains in the same machine, and avoiding firewall problems.

When using elliptic curve cryptography public keys have a much shorter size than RSA, so a single UDP packet should be able to carry the necessary information.

\subsubsection{Warning}

Efficiently packing all this information still results in an answer packet that is much bigger than the request. As we can not put other restraints on the DNS
system, this will result in the DNS system being used for amplification attacks.

Thanks to the structure of the DNSSEC system, however, this is already happening, and multiple servers are already available\footnote{\href{http://dnscurve.org/amplification.html}{DNSSEC amplification}} that provide an
amplification of even a hundred times the original packet. Therefore this should not further increase any threat (as it is already present) and might even
push for a resolution of the DNSSEC amplification problem.




\section{Perfect Forward Secrecy}
\label{pfs}\index{Perfect Forward Secrecy}

\textbf{PSF} is a property of key exchange handshakes that grants that if a whole connection is intercepted today, and the private keys are leaked
tomorrow, the eavesdropped connection will not suffer in security.

This is usually implemented through the generation and usage of \textbf{ephemeral}\index{Ephemeral keys} asymmetric keys, which are used only for one connection and then are
thrown away. These ephemeral keys are then signed by the main public key, so that the receiving end can be sure of the authenticity.

The actual scope of the ephemeral keys is not strictly a single connection. depending on the trust model and synchronization mechanism,
an ephemeral key can span multiple connection during multiple hours; the important part is that this key is easy to replace and is in fact regenerated
constantly. The actual regeneration timeout is dependent on the amount of security we want to grant to the whole system, as longer timeouts will obviously
increase the attacker decryption window.

PFS is currently supported in SSH, TLS (optional, per-connection), CurveCP and minimaLT (timeout-based, multiple connections) and QUIC. QUIC actually
uses a lighter form of PFS, where the initial key exchange is not covered by forward secrecy, but the client can then request an other key exchange to
force the property. This choice was made to lower the amount of round trip necessary to the connection setup, so it sacrifices security for efficiency.

In Fenrir PFS is regarded as fundamental, and as such it is always used, even when it means losing in terms of efficiency.


\subsection{minimaLT approach}\index{Perfect Forward Secrecy!minimaLT}\index{minimaLT!Perfect Forward Secrecy}

MinimaLT introduces a novel way to handle PFS. Instead of having one long-term public/private key, it only uses ephemeral keys, that must be changed at
specified intervals. Every key will be published directly in some directory service (DNS). As the key is short lived, minimaLT can avoid one full round trip
to setup ephemeral key exchanges. This means that the DNS server and the minimaLT server must synchronize, and probably need coherent clocks to publish
keys at the right time.

The longer we keep the same ephemeral key, the lower the security, but higher efficiency is gained through DNS caching. Theoretically this might put more
work on the DNS servers, but in practice changing ephemeral keys every half a day, or even just once a day could be considered enough for not 
security-critical applications. Even for intensive usage, changing keys every couple of hours would still provide decent security and caching.

The practical problem, however, relies in the DNS registrars. Registrars that provide high configurability are rare, to the point where very few records are
available to the end user (even TXT records can be restricted), some other services allow only a couple of unpaid modifications per day, further limiting the
usability of the system. Interactions with service and user is not standard, so it can hardly be scripted, and minimaLT requires keys change at exactly
the same moment in both server and DNS system, so even clocks must be synchronized and reliable.

All of these problems do not arise the moment we want to setup our own DNS system, but requiring custom modifications to a service (DNS) that is not always
under the direct control of the application owner might be excessive.

The biggest drawback, still, is the need to perfectly synchronize the DNS key publishing and service key rotation.


\section{Handshake}\index{Handshake}

In Fenrir 3 different handshakes will be available:
\begin{itemize}
\item \textbf{Full-Security}: includes syncookie-like handshake and a TLS-like handshake. It requires 3 round trips but takes a lot from the most tested
algorithms.
\item \textbf{Stateful Exchange}: 2 round trips (avoids the syncookie), but needs to store a state and thus should be disabled during DoSes.
\item \textbf{Directory synchronized}: like minimaLT we publish the ephemeral keys on the directory service. Only 1 round trip..
\end{itemize}

Perfect forward secrecy will be forced in all handshakes, Although the scope of the PFS (connection or timeout) can change.

MinimaLT and QUIC both support 0-round-trip connection setup. Although it sounds exiting, this is explicitly avoided in Fenrir as we are not able to grant
that a packet has not been spoofed. Although an attacker that can intercept all network packets can keep a working connection even when spoofing the ip
address, we should not put all devices in the position to exploit ip address spoofing even when they do not have the capability of intercepting all network
packets.
A bigger problem relies in accepting data (aka:service commands) on the first packet: it can create big amplification attacks, for example when requesting a
download for an other ip address, as our service will fill the congestion window for a non-confirmed ip address.

Since we are designing from scratch a protocol, we should learn from the TLS system, and try to hide all information possible, even including the service
type and fqdn that the client is trying to access. This information is always in plaintext in TLS, as the tcp port tells us which service is being accessed, and the
fqdn of the service is in cleartext in the certificate, to let the server and client support SNI (Server Name Identification) which lets servers use multiple certificate
on the same TLS socket.

Thanks t the format specified in \ref{DNSKEYID}, we can support multiple public keys at the same time, and they are only related to the authentication server,
which means that an eavesdropping attacker will not be able to detect which service or domain the client wants to connect to, as multiple domains
can be handled by the same authentication server. The key id specified in the server will also let us handle any delays between publishing the new key
and deleting the old one, as some other clients might not have invalidated their caches yet.\\

We will now look more in-depth to the possible handshakes:


\subsection{Full-Security}\index{Handshake!Full-Security}

This is the most secure handshake, designed for security instead of efficiency.
\begin{itemize}
\item \textbf{RT n.1} :syncookie exchange to avoid DoS, supported algorithms.
\item \textbf{RT n.2}: exchange of supported algorithms, ephemeral keys and key exchange.
\item \textbf{RT n.3}: authentication and authorization
\end{itemize}

This key exchange looks a lot like the classic TLS one, and the client needs a full 3 round trips to complete the authentication. It is also the slowest method,
thus the need for more efficient handshakes.

Perfect forward Secrecy is enforced at round trip n.2.

\textbf{TODO: details}

\subsection{Stateful Exchange}\index{Handshake!Stateful Exchange}

When efficiency is needed, this handshake can be used. Although it takes one less round trip, it still needs to store a state right from the first received
message. Therefore this method should be available only when few connections per second are created, and should be automatically disabled when
under heavy load for concerns of a possible memory DoS.

\begin{itemize}
\item \textbf{RT n.1}: algorithm support, ephemeral key from server.
\item \textbf{RT n.2}: client ephemeral key, authentication.
\end{itemize}

The memory DoS problem arises from the need to store the private key in memory during the handshake. If the private key is generated for
every connection, DoSes are easy to cause. However a solution is to simply keep using the same ephemeral key for more connections,
so that only a few keys need to be kept in memory (due to key rotation). This solution however breaks the one-key-per-connection rule.

It should also be noted that the amount of information carried by each packet is now increased, so there is a risk that multiple packets be needed to
transfer the information. This can be a problem in the case of packet loss, but it does not count as a round trip as both the client and server can send
the packets without waiting for the ack.


\subsection{Directory-Sinchronized}\index{Handshake!Directory-Sinchronized}

This is basically the minimaLT approach, revisited.

THe only round trip required in this case comprehends the client's ephemeral key, and user authentication, and the server only answers with a success
or rejected response.

The problem of this solution remains in the synchronization between the directory service and the authentication server. However the Fenrir approach is
much different from minimaLT, in that we only need to synchronize the authentication server, and not all the services. moreover, each public key
of the authentication server has a random identifier attached, so that multiple keys can coexists, making key rotation much smoother, avoiding
relying too much on timeouts and clocks of other machines.



\section{Attacks}
\label{Attacks}

As we have a detailed view of the interaction of the protocol parts, we should now discuss the overall safety of the proposed protocol.

Part \ref{Formal Verification} of this documents is dedicated to the formal verification of the interaction between handshakes and their correctness,
we will therefore concentrate on the overall trust model, assuming the correctness of said algorithms.

The model on which Fenrir is based on is, of course, that the client, authentication server and services of its domain are trusted sources.
This doesn't mean that other authentication servers are fully trusted, so login information must not be leaked to other domains.

First of all, a malicious authentication server can obviously impersonate all its users into its services. That is because both service and authentication
server are controlled (by definition) by the same organization: logs can be forged, user data can be edited. But this is true for any system, so there
is no point in trying to counter this.

However, we can imagine a scenario were a previously trusted authentication server becomes a \textbf{rogue AS} after an attacker manages to compromise
the operative system of said AS. In this case our model does not prevent the AS to impersonate its user, for both its own services and other domains'
services. While we can not do much to avoid the AS impersonating a client in new services, we can stop the AS from impersonating the client into
services where the client has already registered, thus protecting the user data and privacy. The mechanism for this is better explained in the ``anonymous
authentication''\ref{anonymous authentication} section, but basically consists of the client and the other domains' AS exchanging further authentication data.\\

As the name of the model says, we are relying on a \textit{trusted third party} for authentication and authorization. we have a small window of safety even
in case of the breach of our third party, but since an AS is central to the whole Fenrir model, much like a kerberos or active directory server, extra care
should be taken in securing this component.\\

A second and more troublesome source of attacks that is rarely considered is the compromise of our trust base, the \textbf{directory service}.
In the web of trust model, this can be the compromise of a trusted key, in the public key infrastructure used in X.509 is the compromise of one of the many
certificate authorities. This last scenario has already happened (the COMODO certificate hacking), but it should be noted that there are a lot of countries
that can secretly force the certificate authorities to forge specific valid certificates, and until those certificates are somehow leaked to the public, no one
would be the wiser.

DNSSEC in Fenrir was not chosen only due to its widespread usage (and testing), but also due to inherent publicity of the system. Forging an answer and
changing the publicized keys will affect lots of people and should be easier to check, as you only need a script constantly checking the public
information against the one given by the user.\\
Although results can be forged for specific users, changes will be much easier to spot. Moreover, personal account changes will be easier to spot as
all logging must pass through the AS, which tracks both logins, devices id and can thus apply further heuristics (like country of origin) to all services,
independently from domain or type of service.




\chapter{Credentials and Authorization}\label{FederationAlgorithm}
\label{Credentials}\index{Authentication}

In this chapter we will talk about \textbf{Authentication} and \textbf{Authorization} and their implementation in Fenrir.

\section{Authentication}\index{Authentication}

Even (and especially) here Fenrir must be flexible, and being able to support different authentication mechanisms (passwords, OTPs, certificates or other).

One of the limitations of current protocols is that we are forced to authenticate at the beginning of the connection, during the handshake.
Although this mode must obviously be supported, if we limit the login to the handshake we force the developer to make another connection and drop the
previous one. While this is not terribly complicated, it still is something that is not usually done, and it is the reason why TLS authentication is not used and
multiple protocols stacked on top of it have to reimplement the authentication. To avoid duplication of features and more stacking of protocols, Fenrir
should provide the ability to drop unauthenticated streams and switch to an authenticated connection.

This is especially useful for web sites, were the users visits the homepage while unauthenticated, and then logs in without having to set up a second connection.
\\
\subsection{Application Authentication}

A novelty introduced by OAuth is the authentication of applications. This means that the application binary has to provide a sort of username and password
to the service before being recognized, and before providing user login information. This means that the application credentials are stored statically inside
the application binary. This means that almost all applications will store the data in plaintext, while other will try to obfuscate it, probably unsuccessfully.

Although such an application authentication is inherently flawed and with few use cases (so few that OAuth2 introduced mechanisms where this was
not needed), it does not mean that the concept is useless. We can shift the application authentication to become a \textit{device} authentication.
This means that the user can now control which and how many devices are connected to its account. The main purpose of this device authentication in fact
is not to limit the number of user devices, but only to identify different devices and to give scope to each device. This will let the user know if his credential
have been stolen, as there will be new devices connected to the account, and it will let the user limit the device authorization so that a device that can be
lost easily, like a cellphone, has only a read access to important accounts (like banking accounts).

Moreover, by controlling device authentications, we can easily give scope to each authorization and drop all authorizations given to a single device
without affecting other devices' authorizations.

\subsection{Token}\index{Token}

One of the easiest ways to break into any account is to try to guess commonly used passwords. Thanks to the design of Fenrir, instead of continuously
using weak passwords we can use hard-to-guess \textbf{tokens}. After the initial login, token will be used for everything, from application
authentication to user authorization. This design will drop the reuse of password by the users, which means that they might be willing to use
more difficult passwords, as they need the passwords \textit{only once}.

It should be noted that the connection is either anonymous or tied to an authenticated user. This means that the token will only be used during authentication.
Although this seems obvious, it is a big difference from other protocols like kerberos or OAuth, were the developer is provided a token that represents
its authentication and has to transmit the token at every request.\\
This last approach is more flexible as it can span multiple protocols and scopes, but it decreases security as the developer has to pay attention not to leak
the secret token. Developers would have to pay much more attention to security and information leaks, while the vast majority can barely be trusted with
writing a stable application, so by tying the token to the connection we simplify application security and take it out of the developers' hands.


\subsection{Single sign-on}\index{Single sign-on}

Singe sign on mechanisms provide the user with the ability to login once and be automatically logged into different services of a single vendor.

While it looks like a very useful feature, it is not very flexible, as you also need to log out of every service before loggin in with a different user, and it
requires a global state. As we want to provide the user with the ability to handle multiple accounts, guessing the right account to load in an application
which might have been started in the background (think about smartphones) is neither easy not recommended.

But ease of use is still a requirement, so Fenrir will switch to a one-click login model instead. Th ideal workflow is:

\begin{itemize}
\item the client (e.g. the application) will tell the client manager that it want to login somewhere.
\item the client manager asks the users if it should login at the given location, and with which account.
\item after authentication, the client manager gives only the connection id and keys to the client.
\end{itemize}

This means that the user will always be presented with a familiar and consistent login question, whatever service he might log into, and that the
application will never see passwords nor usernames nor authentication tokens, thus excluding the application from security and user and password
management.

More advanced client managers might learn choices, or provide suggestions for the applications, so flexibility is maintained without nagging the users.


\section{Authorization Lattice}\label{AuthorizationLattice}\index{Authorization!Lattice}\index{Lattice}


Aside from authentication, one feature a lot of protocols try to include is a way to limit the scope of the user authentication, that is: \textbf{authorization}.

The first thing that needs to be done is to somehow list the possible privileges, then during authentication we can tie a token to a specific privilege,
and thus limit the application capabilities.

This by itself is already included in OAuth, but there is no standard way to manage privileges and in some cases the application has to restrain itself,
which is not really safe if we don't trust the application.

Fenrir will therefore include a standard way to list authorizations, and multiple levels of enforcement: by taking advantage of the 3rd-party model,
we can make the authentication server associate a maximum privilege (and no more) to a token, and then that token can be further limited in privilege
by the client manager. As the final application does not interact with tokens or authentication in any way, it is forced to use the limited level of
authentication that it has been provided with, thus ensuring our account safety with untrusted applications.

This model however requires different privileges to be ranked one relative to the other. in mathematical term, we are looking at a \textbf{complete lattice},
as it is the only structure that grants our requirements.

\begin{figure}[h]
\centering
\begin{tikzpicture}[-,>=stealth',auto,node distance=1cm]
  \tikzstyle{every state}=[fill=none,draw=none,text=black]

  \node[state]	(B) {Bottom};
  \node[state]	(R) [above left of=B,node distance=2cm] {Read};
  \node[state]	(M) [above left of=R,node distance=2cm] {Modify};
  \node[state]	(A) [above right of=R, node distance=2cm] {Add};
  \node[state] 	(W) [above of=R, node distance=3cm] {Write};
  \node[state]	(T) [above right of=W, node distance=2cm] {Top};
  \node[state]	(I) [right of=A, node distance=2cm] {Account info};
  
	\path (B) edge node {} (R)
		(R) edge node {} (A)
		(R) edge node {} (M)
		(A) edge node {} (W)
		(M) edge node {} (W)
		(W) edge node {} (T)
		(B) edge node {} (I)
		(I) edge node {} (T);
\end{tikzpicture}
\caption{example of a complete lattice of privileges}
\label{example of a lattice}
\end{figure}

The mathematical definition of a complete lattice is a partially ordered set in which all subsets have both a supremum (top) and an infimum (bottom).\\
Thanks to each pair of privilege having an upper element that has both privileges and a lower level with the least privilege in common it will be easy to quickly
verify whether a token that was tied to a privilege can be used with the privilege that the client manager is asking, or can be further limited if the client
manager decides so.

We now have a hierarchical definition of privileges, which can be enforced independently of the application, which is tied directly into the protocol and
is in complete control of the user. The only downside is that as each lattice of privileges is specific to an application, we will need to transfer the
lattice between the service, the authentication service and the client manager in order to let the user work with lattices of every service.

However this is needed only on the first connection (the lattice can be cached), and is not needed for anonymous connections as there is no user to
authorize.

We should still be wary of rouge services building pointlessly big lattices, so there should be a limit to the size of the lattice to avoid DoSing
authentication servers and client managers.


\section{Side channel}\index{Side channel}


A very good part of the latest attacks on TLS and other protocols are side-channel based, for example on the size of the transmitted data, or on the
amount of time necessary to (de)encrypt data.

Although these attacks are more of an issue for implementations than for protocols, Fenrir should try to limit the amount of information gathered
from such attacks.

To make data-size based attacks more difficult, packets should contain a random amount of data, where the actual amount should be user-dependent, as
we can interfere too much with the application flow.

In the future Fenrir should also be able to have communication channels that are bandwidth restricted in both maximum and minimum used bandwidth,
so that traffic analysis is more difficult.

Fenrir also uses a some header fields (stream id, counter) that can (and should) be randomized in order to increase entropy of the encrypted data and
to give attackers less details on the content of the cleartext, so that known-plaintexts attacks get more difficult.


\section{Advanced Authentication}\index{Authentication!Advanced}

The authentication we provided is still kind of basic, and we can be much more flexible and secure.
By introducing anonymous and direct authentication we will increase the points of failure needed to tie one account to a person, while keeping
verifiability of the account and increasing the points of failure needed to successfully compromise an account.

\subsection{Anonymous Authentication}
\label{anonymous authentication}\index{Authentication!Anonymous}


This contradiction in terms can actually be though more as an authentication with undisclosed information (login included).
This is something that is useful when we don't want to give out our username (which is also our email) to a third service, but we still want to be able
to access the services.

The obvious implementation is the automatic request and creation of temporary accounts, or \textbf{account aliases}\index{Account Aliases}

The only way to use account aliases however is to permanently associate an alias with an account, so any leak which connects the original account
to the temporary one would breach the client's anonymity.

Keeping in mind how the federation works (see \ref{FederationExample}), in an example where \textit{client@example.com} connects to a service in the
\textit{domain.com} domain, the authentication server for `\textit{domain.com} only needs to remember that one of his accounts can be accessed by
the \textit{example.com} domain. The authentication server for \textit{example.com} will then confirm or deny that the account at \textit{domain.com}
can be accessed by the client's account.

This system decouples the client's login from the authentication into other domains, so the client can use temporary usernames that can last for
as little as the authentication process itself.


\subsection{Direct Authentication}\index{Authentication!Direct}

One problem of all the Fenrir system is that we are putting a lot of trust in the authentication server. While this lets us create a lot of interesting new
scenarios, it creates a very big single point of failure. As time passes the authentication server implementations will become more and more resilient
to attacks, but the risk of a compromised authentication server is too great.

To solve this problem we can introduce an automatic, lightweight second layer of authentication that does not require user intervention. We can go one step
further and make it direct between client and service, a form of \textbf{direct authentication}.

The idea is that the clients will share a secret key directly with the service on which the clients logs into (non-anonymously). If we can manage this,
then the compromise of a whole authentication server will let the AS impersonate the client in services where the client has not yet logged in (as it can just
pretend to be a new client), but the existing user accounts an data will be safe, as the hacked authentication server will not be able to guess the shared
key between client and service.

As a further precaution, since the shared key handling is automatic, the shared key should be OTP (hash
based\footnote{\href{http://dl.acm.org/citation.cfm?id=358797}{Leslie Lamport, "Password Authentication with Insecure Communication", Communications of
the ACM 24.11 (November 1981), 770-772}}). This extra step will ensure additional safety and will break the completely reliance on the authentication server.

\subsubsection{Trusting trust with direct authentication}

Once the client and service have a shared key, it should become impossible even for the authentication server to break the encryption between the two,
as even man in the middle attacks by the rogue authentication service will be stopped.

However, when first sharing the key the authentication server can create a phony service, let the client exchange keys with that, and effectively use a
man-in-the-middle attack.

The only solution to avoid this problem is to publicize the public key of the services in a way similar to what we have done with DNSSEC. The service will then
sign the generated data that will be relied to the client via the authentication service, thus assuring the client of the impossibility of man-in-the-middle attacks.
This will however break the previously stated feature that the identity of the accessed service will be kept secret.



\section{Authentication summary}

Thanks to the direct authentication, we have broken away from relying only on the authentication server. Our model is now a hybrid between a
third-party security model and a purely client-server one.

To successfully compromise an account now an attacker needs to compromise both the authentication server and the service it wants to access. Which
means that we have fully removed our single point of failure from our protocol.

A single point of failure still exists in the form of the trust system used by the protocol to publicize the public keys of both the authentication server
and the service. If this system (like DNSSEC) does not grant privacy, the Fenrir protocol will not be able to grant that the accessed service is anonymous.
If the trust system is compromised, the attacker can just point to their own authentication servers and services, thus impersonating the user into \textit{new}
services. It should be noted that even when the attacker compromises the trust system, thanks to our direct authentication it will not be able to
impersonate the client in services where the client was registered earlier, thus granting user data.

At the end, we have created a system where a lot of trust was given to the authentication server, but \textbf{even in the case where the trust system and the
authentication servers are compromised, the user data inside the service remain remain safe}, provided that the user registered to the services
before the authentication server was compromised.\\

\subsection{Putting it all together: an authentication flow example}\index{Authentication!Example}

Until now we have been talkative about the protocol, presenting existing solutions, their defects, and slowly modeling our protocol around the
good and bad choices made by current protocols, while introducing a couple of innovations, like the authorization lattice\ref{AuthorizationLattice}.

A formal, verifiable model will be presented in part \label{Formal Verification}, we now want to look at the big picture, at a working example of all the
features we have introduced so far.

In our examples, we will have a client, \textbf{client@example.com}, connecting to the a service of the domain \textbf{domain.com}

First of all, DNSSEC will be used as the source of our trust. although this system has many problem (no privacy, caching delays, political problems), it is
the only source of trust currently available and largely compatible with today's infrastructure.

The very first thing the client manager will do is connect to its authentication server and login. This connection is persistent and is needed to synchronize
data and tokens between the client manager and the authentication server. As this step is the same of the example below, we will assume this connection
is always present, without going into details.\\

When an application \textit{X} wants to connect to a service in the \textbf{domain.com} domain, it will tell its client manager that it want to connect to
that service in that domain, with an user in the \textit{domain.com} realm.\\
The client manager will now handle the rest, and give back to the application only the encryption keys.

The first thing the client manager does is to inform the user that the application \textit{X} has requested access to the specified service at \textit{domain.com},
and that the application will use the account the application has requested.

If the user accepts, the client manager will now:

\begin{enumerate}
\item ask the AS of \textit{example.com} for a token for the specified service and username at \textit{domain.com}
\item resolv \textit{domain.com} authentication server, and gets its key and info
\item resolv the service the application wants to connect to to get its private key.
\item connect to \textit{domain.com} AS, provide the previous token as proof of authentication
\end{enumerate}

It should be noted that step 1, 2 and 3 can be done in parallel to improve efficiency and that step 1 is only needed the first time the client manager
connect to the service, as the token can be cached.

On the other side, the authentication server for \textit{domain.com} receives a request for an authentication. The contents will be the user in the
\textit{domain.com} realm, the user in the \textit{example.com} (which can be a temporary username), and a token. The AS will now check
the token with the AS for \textit{example.com}, giving it the usernames, token and service id as received by the client manager, and in case of a successful
answer it will inform the right service that a new user has connected.

As this point the service will generate a new connection id, a new key. Two things can happen.\\
If the two have a shared OTP:
\begin{itemize}
\item the service XORs the key with the current OTP hash
\item the service sends the XORed key, hash iteration number, connection id to the authentication server.
\item the AS relays them to the client manager.
\item the client manager computes the key and previous OTP hash iteration, and gives it to the application
\item the application can now connect to the service with a shared key and without MITM from even the ASs
\end{itemize}

But on the first connection, the client does not have any shared secret, so in this case the client  manager will generate a private/public key of the same
type as the service's one. This key will be transmitted during authentication, along with the encrypted, hashed OTP and the number of iterations in the hash.

The service will use the public key to generate the shared secret and decrypt the OTP, and then resume normal flow.

~\\


The XOR between the encryption keys and the user OTP will grant secrecy of the session keys. Due to both the key and the OTP being completely random,
there will be no way of recovering the session keys, even if a Vigenère like XOR is applied, and will thus prevent MITM even from the authentication servers.