Commit 18c8f0fb authored by Paul Fiterau Brostean's avatar Paul Fiterau Brostean

updates

parent 97388517
......@@ -2,13 +2,11 @@
The SSH protocol is used interact securely with remote machines. Alongside TLS and IPSec, SSH is amongst the most frequently used security suites~\cite{Albrecht2009Plaintext}. Due to its significant user base and sensitive nature, flaws in the protocol or its implementation could have major impact. It therefore comes as no surprise that SSH has attracted scrutiny from the security community. Problems with information leakage via unencrypted MACs were identified~\cite{Bellare2004Breaking}, as well as possibilities for plain text recovery when a block cipher in cipher block chaining mode was used~\cite{Albrecht2009Plaintext}. Other analysis found no serious issues~\cite{Williams2011Analysis}\cite{Paterson2010PlaintextDependent}. Academic researchers have so far focused more on the theoretical aspects than on implementations of the protocol.
In this work, we use classical active automata learning, which we refer to as model learning, to infer state machines of 2 SSH implementations. Model learning has previously been applied to infer state machines of EMV bank cards~\cite{Aarts2013Formal}, electronic passports~\cite{Aarts2010Inference} and hand-held readers for online banking~\cite{Chalupar2014Automated}. More recently, it was used to learn implementations of TCP~\cite{Janssen2015Learning} and TLS~\cite{RuiterProtocol}. Model learning's goal is obtaining a state model of a black-box system by providing inputs and observing outputs. The learned state model corresponds to the observed behavior, and can be used in system analysis. Since model learning builds from a finite number of observations, we can never be sure that the learned model is correct. To that end, advanced conformance algorithms are employed, which yield some confidence that the system inferred is in fact correct. In the context of testing protocols, model learning can be seen as a form of protocol state fuzzing, whereby unexpected inputs are sent to a system under test in the hope of exposing hidden anomalies. In model learning, inputs are sent with no regard to the order imposed by the protocol.
Inputs can therefore be sent disorderly. Any anomalies are then exposed in the learned model.
In this work, we use classical active automata learning, which we refer to as model learning, to infer state machines of 2 SSH implementations. Model learning has previously been applied to infer state machines of EMV bank cards~\cite{Aarts2013Formal}, electronic passports~\cite{Aarts2010Inference} and hand-held readers for online banking~\cite{Chalupar2014Automated}. More recently, it was used to learn implementations of TCP~\cite{Janssen2015Learning} and TLS~\cite{RuiterProtocol}. Model learning's goal is obtaining a state model of a black-box system by providing inputs and observing outputs. The learned state model corresponds to the observed behavior, and can be used in system analysis. Since model learning builds from a finite number of observations, we can never be sure that the learned model is correct. To that end, advanced conformance algorithms are employed, which yield some confidence that the system inferred is in fact correct. In the context of testing protocols, model learning can be seen as a form of protocol state fuzzing, whereby unexpected inputs are sent to a system under test in the hope of exposing hidden anomalies. In model learning, inputs are sent with no regard to the order imposed by the protocol. Inputs can therefore be sent disorderly. Any anomalies are then exposed in the learned model.
Having obtained models, we use model checkers to automatically verify their conformance to security properties. Such verification would be difficult manually, as the learned models are large. Moreover, the very satisfaction of properties can be used to refine the learned model. In cases where the learned model does not satisfy a security property, the proving sequence of inputs can either signal non-conformance of the system, or can be used to further refine the learned model.
Having obtained models, we use model checking to automatically verify their conformance to security properties. Such verification would be difficult manually, as the learned models are large. Moreover, the very satisfaction of properties can be used to refine the learned model. In cases where the learned model does not satisfy a security property, the proving sequence of inputs can either signal non-conformance of the system, or can be used to further refine the learned model. The security properties are drawn out of the RFC specifications\cite{rfc4251}\cite{rfc4252}\cite{rfc4253}\cite{rfc4254} and formalized in LTL. They are then checked for truth on the learned model using NuSMV~\cite{NuSMV}.
Our work is borne out of 3 recent theses. It most closely resembles work on TCP~\cite{Janssen2015Learning}, where they also combine classical learning and model checking to analyze
various TCP implementations, with our work being more focused on security properties. Other case studies rely on
Our work is borne out of 2 recent theses \cite{Verleg2016}, \cite{Toon2016}. It most closely resembles work on TCP~\cite{Janssen2015Learning}, where they also combine classical learning and model checking to analyze various TCP implementations, with our work being more focused on security properties. Other case studies rely on
manual analysis of the learned models ~\cite{Aarts2013Formal},\cite{Chalupar2014Automated}, \cite{RuiterProtocol}. Our work differs,
since we use a model checker to automatically check specifications. Moreover, the model checker is also used as means of testing the learned model.
Inference of protocols has also been done from observing network traffic ~\cite{Wang2011Inferring}. Such inference is limited to the traces that
......
\section{Learning setup} \label{sec:setup}
\section{The learning setup} \label{sec:setup}
%This chapter will cover the setup used to infer the state machines. We provide a general setup outline in Section~\ref{components}. The tested SSH servers are described in Section~\ref{suts}, which were queried with the alphabet described in Section~\ref{alphabet}. Section~\ref{setup-handling} will cover the challenging SUT behaviour faced when implementing the mapper, and the adaptations that were made to overcome these challenges. Section~\ref{layers-individual} will discuss the relation between state machines for individual layers and the state machine of the complete SSH protocol. The conventions on visualisation of the inferred state machines are described in Section~\ref{visualisation}.
%Throughout this chapter, an individual SSH message to a SUT is denoted as a \textit{query}. A \textit{trace} is a sequence of multiple queries, starting from a SUT's initial state. Message names in this chapter are usually self-explanatory, but a mapping to the official RFC names is provided in Appendix~\ref{appendixa}.
......@@ -12,7 +12,7 @@ The learner uses LearnLib ~\cite{LearnLib2009}, a Java library implementing $L^{
\begin{figure}
\centering
\includegraphics[scale=0.35]{example-components.pdf}
\caption{The setup consists of a learner, mapper and SUT.}
\caption{The SSH learning setup.}
\label{fig:components}
\end{figure}
......@@ -82,15 +82,30 @@ The connection protocol allows the client to request different processes over a
\label{conn-alphabet}
\end{table}
%The learning alphabet comprises of input/output messages by which the {\dlearner} interfaces with the {\dmapper}. Section~\ref{sec:ssh} outlines essential inputs, while Table X provides a summary
%of all messages available at each layer.
%of all messages available at each layer. \textit{\textit{}}
%table
\subsection{The mapper}
The {\dmapper} must provide translation between abstract message representations and well-formed SSH messages. A special case is for when no output is received from the {\dsut}, in which case the {\dmapper} gives back to the learner a {\dtimeout} message, concluding a timeout occurred. The sheer complexity of the {\dmapper}, meant that it was easier to adapt an existing SSH implementation, rather than construct the {\dmapper} from scratch. Paramiko had already provided routines for sending the different types of packets, and for receiving them. These routines were called by control logic dictated by Paramiko's own state machine. The {\dmapper} was constructed by replacing this control logic with one dictated by messages received from the {\dlearner}. %over a socket connection
The {\dmapper} must provide translation between abstract message representations and well-formed SSH messages. A special case is for when no output is received from the {\dsut}, in which case the {\dmapper} gives back to the learner a {\dtimeout} message, concluding a timeout occurred. The sheer complexity of the {\dmapper}, meant that it was easier to adapt an existing SSH implementation, rather than construct the {\dmapper} from scratch. Paramiko already provides routines for sending the different types of packets, and for receiving them. These routines are called by control logic dictated by Paramiko's own state machine. The {\dmapper} was constructed by replacing this control logic with one dictated by messages received from the {\dlearner}. %over a socket connection
The {\dmapper} mapper maintains a set of state variables which are used in this abstract to concrete translation. It most notably, (1) saves the parameter preferences, (2)
it uses to craft concrete messages corresponding the learning abstractions.
%textbf{Message} & \textbf{Influence on mapper state} \\
%\textsc{kexinit} & Saves SUT's parameter preferences\tablefootnote{The parameters that must be supported according to the RFCs to ensure interoperability are used if no \textsc{kexinit} has been received.}. \\
%\textsc{kex31} & Saves the exchange hash resulting from key exchange. \\
%\textsc{newkeys} & Takes in use new keys for all outgoing messages\tablefootnote{Silently ignored when key exchange has not yet been completed.}. \\
%\textsc{ch\_accept} & Saves the channel identifier, used in some queries\tablefootnote{Zero is used if no \textsc{ch\_accept} has been received.}. \\
%\textit{any} & Saves the sequence number, used for the \textsc{unimpl} query\tablefootnote{Zero is used if no message has been received.}. \\
%\end{tabular}
%\caption{State-changing responses implemented by the mapper. These combinedly result in the mapper's state.}
%\label{table:state}
%\end{table}
These are updated
The {\dmapper} updates its state with information from concrete messages. This enables it to craft concrete messages corresponding to the learner abstractions.
Table~\ref{table:state} shows how the mapper is updated.
%As and thus to interact with the {\dsut}, at times similar to how an SSH client would.
......@@ -107,13 +122,13 @@ timeout values accordingly, so that enough time was allowed for the response to
%For example, a trace in which a valid user authentication is performed within five milliseconds after an authentication request on DropBear can cause the authentication to (wrongly) fail.
\end{enumerate}
To detect non-determinism, we cache all new observations in an SqlLite database and we verify observations against this cache. The cache also enables us to answer to queries answered before
To detect non-determinism, we cache all new observations in an SqlLite database and verify observations against this cache. The cache also enables us to answer to queries answered before
without running inputs on the {\dsut}. A subsequent identical learning run can quickly resume from where the previous one was ended, as the cache from the previous run is used to quickly respond to all queries up to the point the previous run ended.
Aside from non-determinism, SSH implementations can also produce a sequence of outputs in response to an input, whereas Mealy machines allow for only one output. To that end, the {\dmapper}
concatenates all outputs into one, delivering a single output to the {\dlearner}.
Another challenge is presented by buffering, leading to an explosion of states, as buffers cannot be described succintly by Mealy Machines.
We have encountered buffers in two occasions. Firstly, some implementations buffer certain responses when in re-key exchange. As soon as re-keying completes, these queued messages are released all at once. This leads to a \textsc{newkeys} response (indicating re-keying has completed), directly followed by all buffered responses. This combined with concatenation of the multiple output response would lead to non-termination of the learning algorithm, as for every variant of the response queue there would be a different output. To counter this, we replace by concatenation of queued output responses by the single word \textsc{buffered}, thus forming \textsc{newkeys\_buffered}.
We have encountered buffers in two occasions. Firstly, some implementations buffer certain responses when in re-key exchange. As soon as re-keying completes, these queued messages are released all at once. This leads to a \textsc{newkeys} response (indicating re-keying has completed), directly followed by all buffered responses. This, combined with concatenation of the multiple output responses would lead to non-termination of the learning algorithm, as for every variant of the response queue there would be a different output. To counter this, we replace the concatenation of queued output responses by the single string \textsc{buffered}, thus forming \textsc{newkeys\_buffered}.
Buffer behaviour can also be observed when opening and closing channels, since a SUT can close only as many channels as have previously been opened. For this reason, we restricted the number of simultaneously open channels to one. The {\dmapper} returns a custom response \textsc{ch\_max} to a \textsc{ch\_open} message whenever this limit is reached.
\ No newline at end of file
......@@ -2,7 +2,12 @@
\usepackage{booktabs} % For formal tables
\usepackage{amssymb} % math stuff
\usepackage{amsmath} % more math stuff
\usepackage{mathtools} % for \coloneqq (defines-symbol := )
\usepackage{graphicx} % for graphics
\usepackage{listings}
\usepackage{float}
% Copyright
%\setcopyright{none}
%\setcopyright{acmcopyright}
......@@ -30,7 +35,9 @@
\begin{document}
\title{Inference and verification of SSH state machines by state fuzzing and model checking}
\graphicspath{{images/}}
\include{macros}
\title{Leveraging Model Learning and Model Checking to Infer and Verify SSH Implementations}
\author{Ben Trovato}
......@@ -102,12 +109,12 @@
\begin{abstract}
We apply protocol state fuzzing on three SSH implementations to infer state machines, which
We apply protocol state fuzzing on two SSH implementations to infer state machines, which
are then verified by a model checker for basic security properties. Our results show that
all tested SSH servers adhere to these properties. That said, their corresponding state machines differ significantly.
These variances allow anyone to effectively fingerprint the tested servers.
Various shortcomings with regards to the RFCs were found. Opening multiple channels is not properly implemented on CiscoSSH and PowerShell. OpenSSH contains a bug which can result in connection closure after rekeying in some circumstances. Both Tectia and OpenSSH implement a liberal message acceptance policy in the first phase of the protocol. Such a liberal policy is unwise in this error-prone stage.
%Various shortcomings with regards to the RFCs were found. Opening multiple channels is not properly implemented on CiscoSSH and PowerShell. OpenSSH contains a bug which can result in connection closure after rekeying in some circumstances. Both Tectia and OpenSSH implement a liberal message acceptance policy in the first phase of the protocol. Such a liberal policy is unwise in this error-prone stage.
\end{abstract}
......@@ -155,11 +162,12 @@ Various shortcomings with regards to the RFCs were found. Opening multiple chann
\maketitle
\input{introduction}
\input{3-ssh}
\input{4-preliminaries}
\input{5-setup}
\input{6-results}
\input{7-conclusions}
\input{preliminaries}
\input{the_sut}
\input{learning_setup}
%\input{learning_results}
\input{security_definitions}
%\input{conclusions}
\bibliographystyle{ACM-Reference-Format}
\bibliography{sigproc}
......
......@@ -27,7 +27,7 @@ input enabled and deterministic.
\subsection{MAT Framework} \label{ssec:mat}
The most efficient algorithms for model learning all follow
the pattern of a \emph{minimally adequate teacher (MAT)} as proposed by Angluin~\cite{Ang87}.
the pattern of a \emph{minimally adequate teacher (MAT)} as proposed by Angluin~\cite{Angluin1987Learning}.
In the MAT framework, learning is viewed as a game in which a learner has to infer an unknown automaton by asking queries to a teacher. The teacher knows the automaton, which in our setting is a deterministic Mealy machine $\M$.
Initially, the learner only knows the inputs $I$ and outputs $O$ of $\M$.
The task of the learner is to learn $\M$ through two types of queries:
......
\section{Checking security specifications} \label{sec:specs}
We use the NuSMV model checker to verify security properties. NuSMV is a model checker where a state of a model is specified as a set of finite variables, and a transition-function, which can then be defined to change these variables. Specifications in temporal logic, such as CTL and LTL, can be checked for truth on specified models. NuSMV provides a counterexample if a certain specification is not true. NuSMV models are generated automatically from the learned models. Generation proceeds by first defining in an empty NuSMV file three variables, corresponding to inputs, outputs and states. The transition-function is then extracted from the learned model and appended to the file. This function updates the output and state variable for given valuations of the input variable. Below we give an example of a Mealy machine and it's associated NuSMV model.
\newfloat{property}{thp}{lop}
\floatname{property}{Property}
The properties we verify are primarily drawn from Verleg's security definitions. To these, we add properties on re-keying, as well as other properties outlined in the RFC specification.
We use the NuSMV model checker to verify security properties. NuSMV is a model checker where a state of a model is specified as a set of finite variables, and a transition-function, which can then be defined to change these variables. Specifications in temporal logic, such as CTL and LTL, can be checked for truth on specified models. NuSMV provides a counterexample if a certain specification is not true. NuSMV models are generated automatically from the learned models. Generation proceeds by first defining in an empty NuSMV file three variables, corresponding to inputs, outputs and states. The transition-function is then extracted from the learned model and appended to the file. This function updates the output and state variable for given valuations of the input variable. Below we give an example of a Mealy machine and it's associated NuSMV model.
In this section, we define the properties that we formalized and verified with the NuSMV model checker. We group these properties into three categories:
\begin{enumerate}
\item \textit{general security properties}, that is properties which must hold if the implementation is to be deemed secure
\item \textit{key exchange properties}, that is properties regarding the key exchange operation
\item \textit{other functional properties}, which are extracted from the SHOULD's and the MUST's of the RFC specifications
\end{enumerate}
\subsection{General security properties}
Verleg defined three security properties, one for each layer. We formalized and checked two, leaving out the one defined for the Connection layer, as it implied manually checking the model for problems.
\subsection{General security properties}
Both the Transport and the Authentication Layers can be said to provide notions of security, which secure access to services of the Connection Layer. For each of these layers, we define general security properties that reflect successful implementation of these notions.
%Each upper SSH layer assumes a notion of security is provided by the layer bellow. The Authentication Layer assumes integrity and confidentiality is provided by the Transport Layer, the Connection Layer the same assumptions, plus it also assumes authentication was successful. We define a general property for each upper layer on the basis of successful implementation of these security notions.
The security property for the Transport layer is defined as follows: ``We consider a transport layer state machine secure if there is no path from the initial state to the point where the authentication service is invoked without exchanging and employing cryptographic keys.'' In other words, authentication request cannot succeed if key exchange wasn't performed successfully. Key exchange implies performing three steps (*give steps*). These steps have to be performed in order but can be interleaved by other actions. Successful authentication request should necessarily imply successful execution of the key exchange steps. We can tell a authentication request or a key exchange step was successful from the values of the input and output variables. For example, an authentication request is successful
if for the input SERVICE\_REQUEST\_AUTH, the output SERVICE\_ACCEPT was received. Following these principles, we define the LTL specification in Figure~\ref{fig:prop1}. O stands for the Once-operator, a past time LTL operator, which is true if its argument is true in a past time instant.
The security property for the Transport layer is defined as follows: ``We consider a transport layer state machine secure if there is no path from the initial state to the point where the authentication service is invoked without exchanging and employing cryptographic keys.''\cite{Verleg2016} In other words, authentication request cannot succeed if key exchange wasn't performed successfully. Key exchange implies performing three steps. These steps have to be performed in order but may be interleaved by other actions. A successful authentication request should necessarily imply successful execution of the key exchange steps. We can tell a authentication request or a key exchange step was successful from the values of the input and output variables. For example, an authentication request is successful if for the input SERVICE\_REQUEST\_AUTH, the output SERVICE\_ACCEPT was received. Following these principles, we define the LTL specification in Property~\ref{prop:prop1}. O stands for the Once-operator, a past time LTL operator, which is true if its argument is true in a past time instant.
\begin{figure}[h]
\begin{property}[h]
\begin{lstlisting}[basicstyle=\footnotesize]
G (
(input=SERVICE_REQUEST_AUTH & output=SERVICE_ACCEPT)
->
G ( (input=SERVICE_REQUEST_AUTH & output=SERVICE_ACCEPT) ->
O ( (input=NEWKEYS & output= NO_RESP) &
O ( (input=KEX30 & output=KEX31_NEWKEYS) &
O (output=KEXINIT)
)
)
)
O (output=KEXINIT) ) ) )
\end{lstlisting}
\label{fig:prop1}
\caption{Transport layer security property.}
\end{figure}
\label{prop:prop1}
\end{property}
For the authentication layer, Verleg defined the authentication layer secure ``if there is no path from the unauthenticated state to the authenticated state without providing the correct credentials.''
In a similar way, we say that the Authentication Layer is secure ``if there is no path from the unauthenticated state to the authenticated state without providing the correct credentials.''\cite{Verleg2016}
Since we have no method to directly determine if the model is in an authenticated state, we consider the authenticated state to be a state where opening a channel can be done successfully.
Since opening a channel should only be possible after user authentication, this should show if we are in an authenticated state. The specification then is rather simple: Always, if a channel is opened successfully, has there not been a failure in user authentication since a successful user authentication. Opening a channel successfully in the model is straightforward, a request to open a channel is sent to the server, and a success message is received back. Checking whether there has been a success or failure in user authentication is done by checking if the server ever sends the UA\_FAILURE or UA\_SUCCESS packets. Additional checks if the user actually made a user authentication request could potentially be added. The resulting LTL is shown in Figure~\ref{fig:prop2}. This LTL uses the Since-operator (S) which holds if its first argument holds for every state since its second argument holds. Note that the second argument has to hold somewhere in the path for the Since operator to hold.
Since opening a channel should only be possible after user authentication, this should show if we are in an authenticated state. The specification then is rather simple: Always, if a channel is opened successfully, has there not been a failure in user authentication since a successful user authentication. Opening a channel successfully in the model is straightforward, a request to open a channel is sent to the server, and a success message is received back. Checking whether there has been a success or failure in user authentication is done by checking if the server ever sends the UA\_FAILURE or UA\_SUCCESS packets. Additional checks if the user actually made a user authentication request could potentially be added. The resulting LTL is shown in Property~\ref{prop:prop2}. This LTL uses the Since-operator (S) which holds if its first argument holds for every state since its second argument holds. Note that the second argument has to hold somewhere in the path for the Since operator to hold.
\begin{figure}[h]
\begin{property}[h]
\begin{lstlisting}[basicstyle=\footnotesize]
G ( (input= CH_OPEN & output= CH_OPEN_SUCCESS)
-> (!(output=UA_FAILURE) S output= UA_SUCCESS) )
G ( (input= CH_OPEN & output= CH_OPEN_SUCCESS) ->
(!(output=UA_FAILURE) S output= UA_SUCCESS) )
\end{lstlisting}
\label{fig:prop2}
\caption{User Authentication layer LTL in NuSMV syntax.}
\end{figure}
\paragraph{Result:} both systems appear to respect this property.
\caption{Authentication layer security property.}
\label{prop:prop2}
\end{property}
\subsection{Re-key properties}
An important property is that re-exchanging keys can be performed in any state of the protocol, and its successful execution doesn't change the protocol state. We consider 2 general protocol states, pre-authenticated (after a successful authentication request, before authentication) and authenticated. For these, we specify that performing key exchange should always preserve the state, until specific inputs or outputs are encountered that necessarily change it. An example of such inputs or outputs are those corresponding to a disconnect action from either side.
\subsection{Key exchange properties}
Important properties are that (re-)exchanging keys is allowed in all states of the protocol, and its successful execution doesn't change the protocol state. We consider 2 general protocol states, pre-authenticated (after a successful authentication request, before authentication) and authenticated. These map to multiple states in the learned models. For each state, we specify the properties that performing key exchange (1) should always be allowed from that state, and (2) if allowed, should always preserve the state, until specific inputs or outputs are encountered that necessarily change it. An example of such inputs or outputs are those corresponding to a \emph{disconnect} action from either side. These properties are useful in characterizing the various implementations. In~\cite{Verleg2016} we noted great variance on satisfaction of these properties.
\subsection{RFC Properties}
We have also formalized and checked properties drawn from the RFC specifications. A problem was that the specification for each layer seemed to only consider messages specific to that layer. In particular, it didn't consider disconnect messages, that may be sent at any point in the protocol as per (*ref*). For the Transport Layer, the RFC states that after sending a KEXINIT message, a party MUST not send SERVICE\_REQUEST or SERVICE\_ACCEPT messages, until it has sent a NEWKEYS message. This is translated to the LTL.
\subsection{Other functional properties}
We have also formalized and checked properties drawn from the RFC specifications. A problem was that the specification for each layer seemed to only consider messages specific to that layer. In particular, it didn't consider disconnect messages, that may be sent at any point in the protocol. For the Transport Layer, the RFC states that after sending a KEXINIT message, a party MUST not send SERVICE\_REQUEST or SERVICE\_ACCEPT messages, until it has sent a NEWKEYS message. This is translated to the LTL.
The RFC also states that in case the server rejects a service request, it should send an appropriate DISCONNECT message.
The Connection Layer RFC states that upon receiving a CH\_CLOSE message, a side should send back a CH\_CLOSE message, unless it has already sent this message for the channel. This of course, ignores the case when a side disconnects, in which case a CH\_CLOSE would no longer have to be issued.
\subsection{Model checking results}
Table presents the model checking results. Crucially, all general security properties are met, though key exchange is strangely not universally permitted, while some of the functional properties described are not met.
This diff is collapsed.
......@@ -29,7 +29,7 @@ SSH provides end-to-end encryption based on pseudo-random keys which are securel
\end{figure}
\subsection{User authentication layer}\label{ssh-run-auth}
RFC 4252~\cite{rfc4252} defines four authentication methods (password, public-key, host-based and none), which are all sent using the same message number~\cite[p. 8]{rfc4252}. The authentication request includes a user name, service name and authentication data, which includes both the authentication method as well as the data needed to perform the actual authentication, such the password or public key. The happy flow for this layer is defined as the sequence that results in a successful authentication. The messages \textsc{ua\_pw\_ok} and \textsc{ua\_pk\_ok} achieve this for respectively password or public key authentication.
RFC 4252~\cite{rfc4252} defines four authentication methods (password, public-key, host-based and none). The authentication request includes a user name, service name and authentication data, which includes both the authentication method as well as the data needed to perform the actual authentication, such the password or public key. The happy flow for this layer is defined as the sequence that results in a successful authentication. The messages \textsc{ua\_pw\_ok} and \textsc{ua\_pk\_ok} achieve this for respectively password or public key authentication.
%We consider a user authentication layer state machine secure if there is no path from the unauthenticated state to the authenticated state without providing correct credentials.
\begin{figure}[!ht]
......@@ -38,7 +38,9 @@ RFC 4252~\cite{rfc4252} defines four authentication methods (password, public-ke
\label{fig:sshcomponents}
\end{figure}
\subsubsection{Connection protocol}\label{ssh-run-conn}
\subsection{Connection protocol}\label{ssh-run-conn}
The connection protocol's requests may opening and closing channels of different types, with each type providing access to specific services. From the various services available, we focus on the remote terminal over a session channel, a standout feature of SSH. A happy flow would involve opening a session channel, \textsc{ch\_open}, requesting a terminal \textsc{ch\_request\_pty}, sending and managing data via the messages \textsc{ch\_send\_data}, \textsc{ch\_adj\_win}, \textsc{ch\_send\_eof}, and eventually closing the channel via \textsc{ch\_close}.
%Because the connection protocol offers a wide range of functionalities, we it is hard to define a single happy flow. Requesting a terminal is one of the main features of SSH and has therefore been selected as the happy flow. This behaviour is typically triggered by the trace \textsc{ch\_open}; \textsc{ch\_request\_pty}. Other
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment