# Evaluation and Improvement of Internet Printing Protocol Based on HCPN Model Detection Method
## 3 Establishment of HCPN Model for IPP Authentication Process  
### Authentication Message Flow  
The authentication and encryption module of the IPP protocol was implemented with the underlying TLS, which was divided into two modes: normal handshake and brief handshake. The brief handshake mode was also called PSK mode, and this paper focused on the 0-RTT handshake process in this mode. Because the whole handshake process is complicated, this message model simplified partial details and only showed the key steps. In general, the PSK mode handshake process has two stages: initial handshake and subsequent handshake. In the initial handshake phase, the communication parties exchanged handshake parameters, the server completed the initial authentication, generated an authentication ticket, and sent it to the client; in the subsequent handshake stage, the client presented the ticket to the server to resume the session. On the premise that the PSK mode was enabled, the client could directly carry the early data in the first-stream \"client-hello\" message in the subsequent handshake phase and complete the short handshake authentication; therefore, this process was also called 0-RTT resumption process, as shown in Figure 1 below:  
The specific process was described as below:  
1. Run the initialization algorithm, the client generated DHE handshake parameters and provided various elliptic curve parameters in the key_share extension for the server to choose;  
Figure 1: Message Flow of 0-RTT Authentication in PSK mode. 2. The server also generated DHE handshake parameters and, at the same time, selected the elliptic curve parameters supported by itself in the key_share extension and passes them to the client to complete the elliptic curve Diffie-Hellman ephemeral (ECDHE) key exchange. Then it generated a set of temporary symmetric keys, TempKey, encrypted subsequent messages (marked with curly braces). Sent a certificate-request message to request that the client should send a certificate for identity verification; sent a certificate message to provide a signature verification key; send a certificate-verify message to provide a signature verification key. Finally, performed integrity protection on the above handshake messages by calculating the message authentication code and obtaining a finished message. 3. The client sent a certificate message to provide its own signature verification key, sent a certificate-verify message to provide a signature, and finally calculated the message authentication code with all previous handshake messages to obtain a finished message and send it to the client. 4. After the server had verified the identity of the client, it generated an initial session key based on the TempKey and the handshake messages. The initial handshake phase was nearly complete. However, in order to implement the subsequent short handshake, a session ticket needed to be generated for the client. First, generated a pre-shared key PSK and encrypted it with the server private key S_prk to obtain the tag identity corresponding to the client identity. Then, encrypted with the initial session key (marked with square brackets) to obtain the new-session-ticket message and send it to the client. Thus, the initial handshake phase was complete. 5. Entered the subsequent short handshake process, and the main purpose of this stage was for session resumption. The client calculated the session-binding value (binder) according to a label (identity) in the ticket information, and encapsulated it into the pre_shared_key extension of the client-hello message. At the same time, it used pre-shared-key to derive early data key (EDK) and encrypted (marked with parentheses) early data. This was the so-called 0-RTT mode, that is, the application data were sent during the first handshake. It should be noted that the pre_shared_key extension did not contain the real PSK value. In other words, the PSK value would not be transmitted in the network channel. 6.