# Evaluation and Improvement of Internet Printing Protocol Based on HCPN Model Detection Method
## 3 Establishment of HCPN Model for IPP Authentication Process
### 0-RTT Authentication Model
#### 3.2.2 Color Set Definition  
After a comprehensive analysis of the protocol certification process, we extracted key steps to define and explain the color set in an easy-to-understand manner without changing the behavior of the original protocol. (When reading it for the first time, it is recommended to browse the general concepts. After reviewing the client model and server model, returning to this section for in-depth reading is suggested).  
First, in the parameter exchange phase, the client and the server needed to exchange parameters, which provided conditions for an efficient ECDHE key-exchange process. For this purpose, the identity ID, random number NONCE, and elliptic curve group GroupList were defined. The random number increased the entropy value, which was used to increase the randomness of the later session key. The list of the elliptic curve groups contained some cryptographic options for both negotiating parties. After the session key was generated, the client and server used symmetric encryption to encrypt data, and Encryption List provided the AEAD encryption methods supported by the protocol. Similarly, HashList provided two hashing schemes for both parties to choose. The client encapsulated the curves, encryption schemes, and hash methods it supported into the parameter OFFER. According to its parameters, the server selected a group of collocations from OFFER and encapsulated them into the parameter MODE. Both parties sent MSG1 and MSG2, respectively, to complete the parameter exchange.  
Secondly, in the identity authentication phase, both parties in communication generated an ephemeral symmetric key TempKey to encrypt the handshake communication data. The server sent CR (CertReq), Cert, Sign, and MAC handshake messages to complete the following functions: request the client certificate, send its own certificate, sign, and ensure the integrity of the handshake message. These 4 messages were processed with the server hash key \(k_{sh}\), encrypted as \(c_{1},c_{2},c_{3},c_{4}\). Finally, they were packaged into MSG3 and sent to the client. Similarly, the client encapsulated its own certificate, signature, and message authentication code for all current handshake messages into MSG4 and sent it to the server. After the two parties successfully verified each other's identities, they generated the initial session key. In PSK mode, the server generated a session resumption credential (ticket) bound to the current session, the client, and the PSK value, and encapsulated them as MSG5 and then transmitted it to the client in an encrypted channel.  
Finally, in the session resumption phase, the client processed the session resumption ticket MSG5, generated a binding value (binder) associated with its own identity and PSK, and then encapsulated it with early data into MSG6 and sent it to the server to restore the session. Both MSG7 and MSG8 ensured the integrity of the handshake message.  
As described, the color sets are defined in Table 1:  
Figure 2: Top-level abstraction.