Cisco Networking: OSI Model Layer 5 – Session
The session layer of the Open System Interconnection (OSI) model defines how the data is formatted between the devices on either side of the link. This is effectively the manner in which they maintain an open channel between the two devices. However, at lower levels of the OSI model, there is no permanent connection but rather a series of short bursts of data being sent back and forth.
The session layer maintains a conversation over many of these bursts of data; in fact, it can take several bursts of data going back and forth just to establish the structure that will be followed for that session.
A real-world example of the session layer might be a pair of spies exchanging messages. They would have to establish an order of operations that would be used to pass encoded messages back and forth. This process for passing the messages could be considered a session layer operation and may include steps such as using an agreed upon cipher to encode the message.
Windows file sharing has a session layer component when establishing sessions, as shown in the following figure.
The goal of the client computer in the figure below is to get a list of shares on the server, but it must follow a session setup process in order to get the desired data. The server in this process is in a constant state of listening for connection requests; as the client starts the process off, the session setup process runs like this:
The client sends a session request to the server.
The server acknowledges the request and includes in the acknowledgement a list of all supported session protocol.
In the case of the Windows server, the list includes older, less secure options such as LANMAN, as well as the newer and more secure NT LANMAN version 2 (NT LM 2).
The client reviews the list of supported protocols and chooses the most secure session protocol that it also supports.
At this point, it sends the server the chosen session protocol that they will be using and requests to conduct an authentication. In this case, the authentication will verify a username and password from the server’s user account database.
The server creates a random string of characters that is included in the password challenge and sends it to the client.
The client takes the password challenge string and uses its own password as an encryption key to encrypt the random string.
The now encrypted string is then sent back to the server in an authentication credentials package that also includes the user’s username.
The server retrieves the user’s password from its user account database, and uses the password as the encryption key to encrypt the random character string that it sent to the client in the challenge step (Step 4).
The server compares the result it calculated to the result listed in the authentication credential package.
If the results match, as they do in the illustration, then an acknowledgement (ACK) is sent to the client and the session is now active; but if they do not match, then the server sends a negative acknowledgement (NACK).
If the client receives a NACK, then it would go back to Step 3 and issue a new authentication request.
At this point the session is set up, and the client can perform the request for the list of shares that are on the server, which would likely lead into a request of a list of files, and then the contents of a specific file.
All of these future operations would be conducted though this single session that has just been created.
Step 10 in the preceding list shows the change from the session layer and the presentation layer. At the session layer, the communication channel to the Windows server components was established, but as the actual request was submitted for the list of shares available on the server, the request used the session layer communication channel, but was actually delivered through to the presentation layer and ultimately the application layer Windows Server service.