What is NSM?

Network Session Multiplexer (NSM in short) is a port multiplexer system, with account managing system and compression/encrypting protocol. But, most of all, it DOES NOT TRUST anybody!

In fact NSM receives access requests on a domain (it can work as provider for more than one machine), check user credentials (IP. MAC-ADDRESS and eventually USERID and PASSWORD) and then it connect the incoming call with the service requires on an eventually encrypted/compressed channel.

A more practical example could be more explaining. Let's se an URLe request:

sql://www.aserver.cmx/DBName?"SELECT * FROM tblUsers;"&"opt=lock"

Allright. First of all, there must be a NSM service on the client machine to whom the applciation will ask to this service to open a channel passing the URLe string.

Then the NSM client service on machine will resolve the address and give to the NSM server service the user credentials. This credentials are exatly the local IP address, the MAC-Address and a binary value rapresenting an authentication token (o if it is the first connection).

The servet itself will give back his own credentials, and, if it is the first connection, a valid ANONYMOUS authentication token. At this point, both server and client will create an user structure in their active user Database. This entry will be used to store various informations (in example all informations that web pages usually saves into cookies, only that those informations will be resident in memory and eventually lost when the machine is resetted or shutted down).

If the anonymous or the current credentials are not enought to access the service, NSM will send an "unavailable service" message. Note that the same message will be sent also if no service with that name are registeres! In that way it is impossible to track all services in a machine if you are not an administrator.

If the access is grant, then there's a negozation between NSM Client service and NSM Server to decide the applicable policies and the compression/encrypting methods and the return values (xml formatted ot plain text for browsers and binary recordsets for dedicated clients). Then the required service is awekened and receives the required parameters, the output format and an object that provides all functionalities for this channel; it has also an interface for all the user data stored on the authentication server (supposingly that the user is registered on it).

The Client application, on its own receive a similar object with access to local user informations. After that the server sends the required data to the client (in the example case, the result of the query) and then close the channel if required (note that normal uses requires that the channel is closed after satisfying the request; only terminal like applications keep the connection alive).

Authentication token

The authentication token formed by tree parts:

  1. User index
  2. Session key
  3. Expiration time (In Universal time)

User counter is used in every transaction as an user identifier, Session key is used for data encrypting and expiration time is used by the client to know when the used data will be deleted from server.

The full token is generated at the login time, and can be renegotiated every time it is necessary by both sides. So, if a user must upgrade his credentials (in example upgrading from ANONYMOUS to a local authenticated user), he/she retains the User index part of the token, but he/she changes the Session key and the Expiration time.

In fact, every time a connection request is sent to NSM, the user identifies himself/herself trought a key made by the (User counter+Expiration time). Server will check the user indexed by the counter and if the Expiration time is correct, then will send a verification message using the Session Key to encrypt it and waiting for a confirmation message encrypted in the same way.

If data don't match the server will assume that the user is invalid both because the index expired and then replaced by another user or an hacking attempt is in progress.

Note that it is possible to use an asymmetric key mechanism; the server/client will hold his own key and give to the other side a different one.

The client side user object

The browser will create a differente connection structure for every server. Note that this structure will retain in memory (or in swap files) all user and server data for every server visited from the reboot of the local client machine. Saved data are: username, User Index, Session Key, Expiration Key, Server Public key, and then an array of accessed services with each a list of session defined properties. Those properties are used to provide a session behaviour even for sessionless connections such as http. You can see them as a new form of cookies, but they aren't saved to disk and are limited to the specific session that created them. In example, in a SQL session those properties will retain cursor data.

The server side user object

It is similar to the client side object list. It retains a list of non expired users' data. Each data has an persistence object for every session used and those objects has properties defined dynamically by the sessions themselves.

That object contains also the access rights granted to the user (for both anonymous and authenticated users).

Connection Object and User Object

When a client application tries to connect to a server application, NSM verifies if a user is already defined in that specific domain. If it is not defined than it calls the login session in order to obtain an ANONYMOUS token and creates the related object.Note that granting login to ANONYMOUS object is a default policy and does little harm to the security itself, because each service can refuse the session afterwards. But some policies can reject also to provide tokens to anonymous users (because can be exploited for d.o.s. attacks).

The Login Session

Whenever a user needs to connect to a service through NSM, he needs a token. If you connect to the "session request port" without a valid token (formed by user index and expiration time the request will be simply ignored.

So, the first step is to obtain a token. Note that you can use the same token for connecting to every service of the domain! You do need to obtain another token only if the old one is expired or the access rights do not grant access to the required service.

The Login Session can be used for four operations only:

  1. Obtaining a token (login)
  2. Revalidating a token (prolong expiration time, if policies permit it)
  3. Upgrading a token (changing the current user)
  4. Invalidating a token (logout)

For each of those operations the service will check also IP address and MAC address to avoid abuses or hacking attempts.

Obtaining a tonek

When you connect to the Login Session it query for a valid token. If you cannot respond with a valid token for that domain, the session assumes you need a new token. Note that the session will also check connection data such as IP address and MAC addess of your PC in order to avoid D.O.S. attacks before granting a new token. Also other policies such as IP/user banning are involved.

If you can obtain the token, then the service will require your authentication data. Here you will have different behaviours: you can ask an ANONYMOUS token (used often by browsers for http access), an USERID/PWD authentication or some more advanced methods such as SSH authentication.

If authentication succeedes than you will receive a valid token. Else you will receive an authentication failure message. The failure message will have one of the following specifications:

codemeaningDescription
0x00000000SuccessEverithing works
0x80000001Authentication failedBoth the userid or the password is incorrect.
0x80000002Invalid Authentication MethodYou cannot authenticate to the server using this methord (ANONYMOUS, USER/PWD, SSH,...); you must try another one.
0x80000003Authentication not allowed(optional) your not allowed to connect to this domain; in short, you have been banned.

Revalidating a token

You can ask a revalidating session to the login manager, but you must possess a valid (non expired) token and your IP, MAC address and Session Key will be checked. if one of the checks fails the token will not be changed.

Possible responses are:

codemeaningDescription
0x00000000SuccessEverithing works
0x80000001Authentication failedYour token, your IP address or MAC address do not macth.
0x80000003Invalid operationThe token ravalidation is not provided (policy setting).

Upgrading a token

First of all you must posses a valid token. If the token itself is not valid or you fail the credential matching, then the operation fails.

If you rightfully own the token, than you can ask for the upgrade. In that case you must input the new userID/password or choose a new Private key for SSH or whatever is required. If authentication is confirmed (do not fail) then your token will be updated (both Session Key and Expiration time) and the server will register your new access rights in his own user image.

Possible responses are:

codemeaningDescription
0x00000000SuccessEverithing works
0x80000001Authentication failedYour token, your IP address or MAC address do not macth or you inputted invalid autheintication data.
0x80000002Invalid Authentication MethodYou cannot authenticate to the

No policy can forbid you to upgrade a token, but the policies checks for invalid methods. So, if ANONYMOUS is not permitted, you cannot reauthenticate as anonymus.

If the operation fails then you will retain the old token with no changes.

The session request call

The session request works on a different port form the Login Service. That is because it performs a different job. Session request service is ment to mediate a connection between a client and a provided service.

First of all, it is required a valid token as long as through the token the service will check the access rights of the user.

If a valid token is provided, the service will ask which service is requested. The request is a case unsensitive string (so SQL is the same of sql). If the service is not provided, a generic access denied message is send. Otherwise, the session request service will check access policies.

Possible restrictions are on user rights, compression/encrypting protocols, IP address or MAC address.

If policies grant access to the client, then a connection port will be negotiated and a connection object linked to this port will be created for the required service. The object will also point to the local image of the user data (user object).


Last modified in 26/01/2006