Security Handshake Phases

The secure handshake is a four phase process. This is necessary to prevent attack by a third party, able to capture and re-use tokens. The four phases are:

Phase    Description                                                                                                   

                                                                                                                       

                                                                                                                       

i        INITIATE secure handshake request The caller requests access by sending an XID frame negotiating the use of   

         the Hayes/Practical Access Security protocol.                                                                  

                                                                                                                       

                                                                                                                       

ii       CHALLENGE caller The answering system responds with an XID accepting the use of the Access Security protocol  

         and appending a random number.                                                                                 

                                                                                                                       

                                                                                                                       

iii      RESPONSE to authenticate caller The caller responds by transmitting a token containing a user ID and password 

         in encrypted form. The encryption process uses the random number sent in the Challenge to ensure that the token 

         is unique to the handshake and not replayed.                                                                   

                                                                                                                       

                                                                                                                       

iv       CONFIRM authentication successful The answering system verifies the user ID and password in the encrypted     

         token and then responds with a CONFIRM token to indicate that the authentication process was successful. If the 

         received token was invalid the answering system may respond with a REJECT token indicating the reason for not  

         accepting the call or may simply disconnect.

The CONFIRM token may contain a Session Number, and a field is reserved for this purpose. This supports multiple-line systems with security management, in which a Session Number is needed to manage, track and log calls.

Callback operation requires an additional two steps. Once stage (iv) has been successfully reached the connection is broken by the caller, and the answering system then calls back. Once the physical connection is established the following two phases are:

Phase    Description                                                                                                   

                                                                                                                       

                                                                                                                       

v        CALLBACK The (previous answering) central site / host system sends an XID frame containing a CALLBACK token   

         that contains the User ID from phase (iii) above. This provides both verification of the call and some means of 

         collision detection to prevent other calls being mistaken for the callback process.                            

                                                                                                                       

                                                                                                                       

vi       ACCEPT The (previous calling) remote system checks the received CALLBACK token and then responds with an      

         ACCEPT token prior to moving into data transfer mode.

Note: These procedures are only defined for use with V.42 LAPM error correction.

Click here to return to the Contents page.