Validation Server Algorithm
This document describes how a validation server should be implemented,
and the required steps it needs to perform in order to be secure.
The client-to-server protocol is described in
Validation Protocol V2.0
and the
server-to-server protocol is described in
lnk:Server_Replication_Protocol.adoc[Server Replication Protocol].
Normal validation with Sync
Val X receives an OTP verify request and needs to update the other
validation servers on the last seen counter values. The procedure is
as follows
Val X parses validation request, retrieves the client key for the client id from local database and checks the request signature.
Val X waits for a sync response (up until timeout, or when sufficient number of sync responses indicating valid OTP and no sync response indicating invalid OTP) from the other validation servers to which it sent a sync request. For each response that arrives the corresponding entry in the sync queue is removed and the following is checked
Any remaining sync requests in the sync queue are from now on handled
by a background daemon which re-sends them at regular intervals
(described below).
Verification algorithm
Input:
otp - the otp
nonce - the nonce from the request
yk:counter - the session counter
yk:use - the session use counter
yk:high - the high timestamp
yk:low - the low timestamp
modified - when the counters were last modified
Output:
Error code.
Val X requires that SL % of the sent sync requests gives a response
marking the OTP as valid, and that none of the responses indicate the
OTP is invalid, in order to consider the OTP to be valid.
If internal database counters are equal to otp counters AND nonce is identical, then return REPLAYED_REQUEST.
Update validation server that has been offline
Val X has been out of function and its internal database needs to be
updated.
This case is handled automatically since the sync requests which did
not succeed immediately in the previous point are queued.
When val X is accessible again, all the sync requests in queue are
re-sent and val X database is updated.
Responses which would have caused the sender of the sync request to
consider the OTP as invalid will give raise to a warning on the sender
validation server.
Sync queue daemon
There is one queue daemon that is responsible for sending all the
queued requests.
The sync queue will loop the following algorithm.
Get a list of all remote server from the database; S1, S2, …
Non-queued Sync response logging
We compare reponse parameters against validation parameters since we
are interested in if the server is in sync at the moment when the
validation request arrives.
response.counters = validation.counters and response.modified != validation.modified
Notice
Servers out of sync. Modified differs.
response.counters > otp.counters
Warning
OTP marked as invalid
OTP is replayed. Sync response counters higher than OTP counters
response.counter = otp.counters and response.nonce != otp.nonce
Warning
OTP marked as invalid
OTP is replayed. Sync response counters equal to OTP counters and nonce differs.
Sync request logging
Both an original sync and a queued sync looks the same so we can not
determine if the sync is original or queued. Therefore the logging is
the same in both cases.
request.counters = local.counters and request.modified = local.modifed and request.nonce = local.nonce
Notice
Sync request has been unnecessarily resent.
This could happen frequently whenever a syncentry is queued but the syncprocess terminates before the resonse to the syncentry arrives (since SL level was already achived).
request.counters = local.counters and request.modified != local.modified and request.nonce = local.nonce
Warning
We might have a replay. 2 events at different times have generated the same counters. The time difference is X seconds
request.counters = local.counters and request.nonce != local.nonce
Warning
Remote server has received a request to validate an already validated OTP
