|
|
|
@@ -22,7 +22,16 @@ Key Negotiation |
|
|
|
Where type is to be: |
|
|
|
shared - shared secret |
|
|
|
ecdh - Results of an ECDH exchange, key = K || K_A || K_B |
|
|
|
ecdhe - Results of an ECDHE exchange, key = TBD |
|
|
|
ecdhe - Ephemeral keys + static keys for PFS |
|
|
|
|
|
|
|
In order to handle a reset and prevent a replay attack, an existing |
|
|
|
session, if any is maintained till the completion of a reset request |
|
|
|
aka new key negotiation completes. Only after that, does the old |
|
|
|
connection key get removed. This does mean that after a reset request, |
|
|
|
it is required that both sides attempt to decode each packet w/ both |
|
|
|
states. This is safe as it is assumed that the initiator will not |
|
|
|
initiate a new key negotiation unless it wants it's previous session |
|
|
|
to be removed. |
|
|
|
|
|
|
|
### shared |
|
|
|
|
|
|
|
@@ -77,13 +86,7 @@ It seems odd to respond to the confirm message, BUT, as using strobe |
|
|
|
requires explicit hand off (similar to a token), in order for the |
|
|
|
initiator to send any commands it needs to be "passed back". |
|
|
|
|
|
|
|
The new key/session does not become active till this point. |
|
|
|
|
|
|
|
In order to handle a reset and prevent a replay attack, the existing |
|
|
|
session, if any is maintained till the completion of a reset request. |
|
|
|
Only after that, does the old connection key get removed. This does |
|
|
|
mean that after a reset request, it is required that both sides attempt |
|
|
|
to decode each packet w/ both states. |
|
|
|
At this point, the new key/session becomes active. |
|
|
|
|
|
|
|
Command Phase |
|
|
|
------------- |
|
|
|
|
