docs: small grammatical and typo corrections; some suggested rewording #7
Conversation
|
|
||
| Consequently, from a replay attack protection perspective, a nonce with a time window in an interactive authentication is functionally equivalent to a monotonic time stamp in a non-interactive authentication but the latter avoids the overhead of the interaction. Both employ a timed cache (timeliness) tied to each requestor and both employ a mechanism that ensures one and only one response is sent for any signed request (uniqueness). | ||
|
|
||
| The typical use case for interactive authentication is not on an asynchronous channel but to use a synchronous channel such that the host can pair each request and response and replay without needing a database. In a sense, a synchronous channel provides a weak form of timeliness given the ordering of messages from the time of the establishment of the synchronous channel. This sort of works if the host enforces that there may be one and only one outstanding request-challenge-response-reply interaction at a time by caching the latest. So a replay must be the one outstanding request and it is assumed that a prior request could not be replayed without re-establishing the connection. This means the channel is blocked until either the interaction times out or succeeds. It does provide replay attack protection since any message must either be part of a the current interaction or start an new interaction with a request never a signed response. | ||
| The typical use case for interactive authentication is not on an asynchronous channel but to use a synchronous channel such that the host can pair each request and response and replay without needing a database. In a sense, a synchronous channel provides a weak form of timeliness given the ordering of messages from the time of the establishment of the synchronous channel. This sort of works if the host enforces that there may be one and only one outstanding request-challenge-response-reply interaction at a time by caching the latest request. So a replay must be the one outstanding request and it is assumed that a prior request could not be replayed without re-establishing the connection. This means the channel is blocked until either the interaction times out or succeeds. It does provide replay attack protection since any message must either be part of the current interaction or start a new interaction with a request, never a signed response. |
There was a problem hiding this comment.
I don't understand the phrase at the end of this paragraph, never a signed response. I added the comma since it felt natural to the flow, yet I don't understand the thought at the end of the sentence and so may have split the thought in an inappropriate place.
There was a problem hiding this comment.
The interactions consists of 4 messages. Original request from requester (client), challenge from requestee (with nonce (host), signed response to challenge with nonce from requester (client), reply with data from requestee (host). So a replay attack is replaying the third message but the host won't accept a replay but forces the client to start a new four message interaction,
There was a problem hiding this comment.
change
can pair each request and response and replay without needing a database
associate each set of request, challenge, response, reply without needing a database. (typo of replay for reply).
There was a problem hiding this comment.
signed response is the third message in the interaction.
There is some terminological ambiguity becuase of the extra two messages that are the nonced challenge and nonced response to that challenge.
So to better remove ambiquity lets not use request but query. This uses KERI parlance.
Querier Replier
------------------------------------------
Query ->
<- Nonced Challenge
Signed Nonced Response ->
<- Reply
A replay attack is the succesfful reuse of a prior Signed Response.
A First-play attack uses Signed Responses out of order.
This approach only works if the channel is synchronous and the Replier caches the current/last interaction (at least the Signed Nonced Response. This means only one interaction per channel is allowed at any time. This does not work on an asynchronous channel unless a database of all interactions is kept which grows without bound unless a monotonic ordering is placed on the interactions so that the database may be pruned of stale intereraction which effectively creates a synchronized set of channels. This means at the least putting time stamps in the Query messages and then keeping the latest Interaction for each Querier and dropping any interactions that are earler.
Given this timed ordered cache all the querier has to do differently is sign the query and now you have exactly KRAM. There is no need anymore for the Nonce challenge response set of messages.
With KRAM you have
Querier Replier
------------------------------------------
Signed Query ->
<- Signed Reply
But the Query MUST have a datetime and should have a SAID
The Signed Reply should include the Query's SAID
The Replier has a sliding timed window cache that enforces that any Query's datetime must be later than any so far previously received query.
KRAM works just as well on asynchronous channels and peer-to-peer exchanges not simply query-reply between client and server. So KRAM can be applied to exchange messages
Peer Initiater Peer Correspondent
------------------------------------------
Signed EXN ->
<- Signed EXN
Both sides keep a timeliness cache of EXNs from the other party to protect from replay attacks.
Given that routes in the exns define an interactive protocol that is a transaction. Then the timed cache can be per transaction type per Peer not just per Peer. The timeout on the timed cache can then be of any size bounded only by the memory of the cache across all simulataneous live transactions of a given type for all peers.
Because eaxch EXN includes the SAID of the prior EXN in the transaction, And the first EXN message in the transaction has a datetime stamp it is not vulnerable to First Play attack.
The transaction itself is ordered and self synchronizing.
There was a problem hiding this comment.
A little bit of historical perspective may help. In the early days of computing, there were no network time servers. Consequently timestamps had no meaning. Each party could just lie about time so time was untrustable. Historically a nonce was just a sequence number. To be a nonce it only had the property of being used once. There are other ways to create a nonce. A datetime can be a nonce. A hash of a datetime or the hash of a sequence number etc. In the early days CSPRNGs (cryptographic strenght pseudo random number generator) were both rare and computationally expensive. So a Salty Nonce was hard. What was common were private networks (the internet did not exist yet). Private networks could have really strong synchronization properties. So given these conditions, using extra messages that do not depend on a time stamp but use a simple nonce (not a Salty Nonce) was reasonable. Moreover, In those days (and for many protocols still used in the wild) signing did not mean digital signatures with asymmetric crypto but merely an HMAC (a hash using a shared secret key). There using an interaction with an extra set of messages i.e. a nonced challenge response for replay attack protection made some sense. Often some CS professor puts a simple mechanism in a text book as an academic exercise to teach a principle and then it gets adopted in the real world by former students not because it was well thought out but because it was familiar.
But today where we assume a KERI context, we can already assume CSPRNGs, assemetric digital signatures tied to keystate of AIDs, cryptographic strength hashes, salty nonces, robust ubiquitous access to network time servers and a requirement to work over asynchronous public networks. The cryptographic operations have gotten relatively cheap given multiple exponential Moore's law increases in computation performance per cost. What has not scaled relatively exponentially is bandwith per cost. Synchronous networks do not scale as well as asynchronous networks and almost all communication now happens over public networks. So refactoring the solution to support asynchronous networks at scale and eliminate 1/2 of the packets is a huge design win.
This includes:
When I review papers I favor adding in Oxford commas and commas in general, which is why I included so many in this PR.