6.5 Perfect Forward Secrecy
6.7 State diagram 107
etc. The server can have multiple parallel negotiations and sessions. Every M-KE negotiation and M-SE session has its own set of values presented with grey background in Figure 6.6.
• A new M-KE negotiation is created when the server receives ClientHello (CH) with new cookie values. The first state of the M-KE negotiation is
“Verify CH”, where CH is abbreviation for ClientHello. The packet structure is verified in this state, thus presence and format of all values. If the check fails, the negotiation is erased and notification may be sent. If the check is successfully passed, then the negotiation goes to “SH Update SAM-DB” (SH is an abbreviation for ServerHello). The values in the SAM-DB are updated and the ServerHello message is sent to the client (generation of DH values, algorithms etc.). The ServerHello can be pending notification or can include all data. The pending notification is sent if the server cannot generate the full message immediately (see 3.5). After successful update of the SAM-DB, the server returns to wait for new packets. There is no need to keep the last state at the server side, since the client message ClientHello or ClientResponse contains sufficient information to handle the packet. The server must only limit the negotiation in time.
• When the server receives packet to existing M-KE negotiation, it goes to verify the content in “Verify CR” or “Verify CH” (CR is abbreviation for ClientResponse). The server updates the SAM-DB and creates a ServerResponse or ServerHello. The message can contain pending notification or response with all information. If there is sufficient information, the M-SE entry can be created. After the M-SE is created, the M-KE negotiation is erased.
• If the received packet is M-SE, then the packet is decrypted according to the M-SE session values in the SAM-DB.
Figure 6.6: Server state diagram M-KE Start Server Wait Packet
do wait Wait Packet
do wait
Stop [ term ]
SH Update SAM-DB Chouse Algs Create M-KE entry
gen.SH SH Update SAM-DB
Chouse Algs Create M-KE entry
gen.SH Verify CH Header/Payloads
Algs supported DH values
Verify CH Header/Payloads
Algs supported DH values
[ recieved ]
[ new M-KE ]
Policy match M-SEP
and M-KE Policy match M-SEP
and M-KE [ existing M-KE ] /find M-KE in SAM-DB
[ existing M-SEP ] [ not matching ]/discard
Use M-SEP to en(de)crypt
[ msg CH ] [ msg CR ]
[ OK ] [ err ]/ info
[ OK ]/ send SH
[ OK ]
[ err ]/ info
M-KE finished Create new
M-KE entry
[ err ]/ info
Verify CR Header/Payloads
encryption Verify CR Header/Payloads
encryption
SR Update SAM-DB Create M-SEP Create M-KE entry
gen.SR SR Update SAM-DB
Create M-SEP Create M-KE entry
gen.SR
[ err ]/ info
[ OK ]/ send SR, create M-SEP
6.7 State diagram 108
• The non M-SE and non M-KE packets are matched against the M-SP, if they must be protected with certain M-SE session
In order to handle multiple negotiations the server must fork to different processes by receiving messages. This is expresses by the first block “Wait Packet” in Figure 6.6.
The Figure 6.7 shows a simplified example of negotiation without any pending and retransmissions. The Server waits for packets (“Wait Packet”). After receiving a ClientHello (“Policy”), the MS verifies it (“Verify CH”) and sends the ServerHello message (“SH Update SAM-DB”). After receiving a ClientResponse, the MS verifies it (“Verify CR”) and generates ServerResponse (“SR Update SAM-DB”).
6.7.2 Client state diagram
The state diagram of client is shown in Figure 6.8. The state diagram is very similar to the server diagram. The main differences to the server state diagram are because the client implements retransmission and pending. The server does not retransmit packets or pending (see 3.5). There can be multiple negotiations and therefore, the client must keep different states for every negotiation. The negotiation state is shown on the grey background in the Figure 6.8.
The client matches a received packet and performs the following actions:
• If the packet is non M-KE and non M-SE, and must be protected, then new M-KE negotiation in created in SAM-DB. In state “CH Update SAM-DB”, the ClientHello is prepared and sent to server. Then the client goes to state
“Wait ServerHello”, where the client may retransmit the packet if no answer is received within certain time. The negotiation may be terminated by timeout too. If ServerHello message is received, the negotiation goes to “Verify SH”, where the message is verified. If the message contains pending notify, the client goes to state “Pending CH”, where after expiring the polling intervals the message is resent (state “CH Update SAM-DB”). If the received ServerHello contains all information, the client goes to state “CH Update SAM-DB”, where the client prepares and sends the ClientResponse message.
After sending the ClientResponse, the node goes in state “Waiting
SH Update SAM-DB Chouse Algs Create M-KE entry
gen.SH SH Update SAM-DB
Chouse Algs Create M-KE entry
gen.SH Verify CH
Header/Payloads Algs supported
DH values Verify CH Header/Payloads
Algs supported DH values [ new M-KE ]
Policy match M-SEP
and M-KE Policy match M-SEP
and M-KE
[ OK ]
M-KE finished Verify CR
Header/Payloads encryption
Verify CR Header/Payloads
encryption
SR Update SAM-DB Create M-SEP Create M-KE entry
gen.SR SR Update SAM-DB
Create M-SEP Create M-KE entry
gen.SR
[ OK ]/ send SH
Policy match M-SEP
and M-KE Policy match M-SEP
and M-KE
Wait Packet do wait Wait Packet
do wait [ received ]
Wait Packet do wait Wait Packet
do wait
[ received ]
Start Server
[ msg CR]
[ OK ]
[ OK ]/ send SR, create M-SEP
Figure 6.7: Example of MS state flow
6.7 State diagram 109
ServerResp”. When the ServerResponse is received, it is verified in state
“Verify SR”. If the message is pending notification, the client waits in
“Pending CR” for resending the message. If the ServerResponse contains all information, the client creates the M-SE session. The packets, which match the M-SP, are encrypted according this entry.
• If the client receives M-KE packet, it goes to the corresponding state of the negotiation.
• The M-SE packets are decrypted according to the M-SE entry.
• The packets matching to M-SP and are non M-SE/M-KE are encrypted with the M-SE entry linked the M-SP.
A simple example is shown in Figure 6.9 without any pending and retransmissions. The MC wait for IP packet to be protected (“Wait Packet”, “Policy”). After receiving the packet, the MC sends ClientHello message (“CH Update SAM-DB”). The MC waits for ServerHello message (“Wait ServerHello”, “Policy”). The received packet is verified (“Verify SH”) and a ClientResponse is generated (“CR Update SAM-DB”). After receiving (“Wait ServerResponse”, “Policy”) and verification of ServerResponse (“Verify SR”) the M-SE session is created.
Figure 6.8: Client state diagram Start Client Wait Packet
do wait Wait Packet
do wait
Stop [ term ]
Pending CH do wait Pending CH
do wait CH Update SAM-DB
Chouse Algs Create M-KE entry
gen.CH CH Update SAM-DB
Chouse Algs Create M-KE entry
gen.CH
Verify SH Header/Payloads
Algs supported DH values Verify SH Header/Payloads
Algs supported DH values Wait ServerHello
do wait Wait ServerHello
do wait
Pending CR do wait Pending CR
do wait CR Update SAM-DB
Chouse Algs Create M-KE entry
gen.CR CR Update SAM-DB
Chouse Algs Create M-KE entry
gen.CR
Verify SR Header/Payloads
Algs supported DH values Verify SR Header/Payloads
Algs supported DH values Wait ServerResp
do wait Wait ServerResp
do wait [ recieved ]
[ need new M-KE ]
Policy match M-SEP
and M-KE Policy match M-SEP
and M-KE [ existing M-SEP ] [ not matching ]/discard
Use M-SEP to en(de)crypt
[ msg SH ] [ msg SR ]
[ OK ]/ send CH [ err ]/ info
[ received SH ]
[ timeout & retries < max ] / resend CH
[ timeout & retries = max ] / fail M-KE
[ pending CH ] [ msg ok ] [ err ]/ notify
[ retr. time riched ] / resend CH
[ OK] /send CR [ err ]/ info
[ timeout & retries = max ] / fail M-KE
[ timeout & retries < max ]
/ resend CH [ received SR ]
[ err ]/ notify
[ pending CR ]
[ retr. time riched ] / resend CH M-KE finished
[ msk ok finished ]
/ creat M-SEP [ msk ok NOT finished ] / creat M-SEP Create new
M-KE entry [ existing M-KE ] /find M-KE in SAM-DB
6.8 Considerations regarding buffer overflows and injection attacks