Stateless One-time Authenticated Session Resumption in TLS Handshake Using Paired Token

Transport Layer Security (TLS) is a cryptographic protocol that provides communications 1 security between two peers and it is widely used in many applications. To reduce the latency 2 in TLS handshake session resumption using pre-shared key (PSK) had been used. But current 3 methods in PSK mode handshake uses a fixed session key multiple times for the lifetime of session 4 ticket. Reuse of fixed session key should be very careful in the point of communications security. 5 It is vulnerable to replay attacks and there is a possibility of tracking users. Paired token (PT) is a 6 new secondary credential scheme that provides pre-shared key in stateless way in client-server 7 environment. Server issues paired token (public token and secret token) to authenticated client. 8 Public token represents signed identity of client and secret token is a kind of shared secret between 9 client and server. Once client is equipped with PT, it can be used for many symmetric key based 10 cryptographic applications such as authentication, authorization, key establishment, etc. It was 11 also shown that it can be used for one-time authenticated key establishment using the time-based 12 one-time password (TOTP) approach. In this paper we apply the PT and TOTP approach to TLS 13 to achieve stateless one-time authenticated session resumption. Server executes full handshake 14 of TLS 1.3 and issues PT to authenticated client. Then client and server can execute one-time 15 authenticated session resumption using PT in stateless way in server side. In every runs of session 16 resumption distinct session keys are established that the same PT can be used safely for longer 17 lifetime. If anonymous PT is used with renewal issuing, user privacy, untraceability and forward 18 security can be achieved easily. It will provide a huge performance gain in large-scale distributed 19


23
Transport layer security (TLS) [1] is a cryptographic protocol that provides end-24 to-end communications security and it is widely used in many applications in the real password (TOTP) approach. PT can provide identification of client (with public token), 66 time-based one-time authentication of client and key establishment (with secret token) 67 in a single logical step. This feature was applied to achieve stateless re-association in 68 WPA3 [17,18]. 69 In this paper we apply the PT-based one-time authenticated key establishment to 70 TLS 1.3 to achieve stateless one-time authenticated session resumption. In our approach 71 server issues PT to authenticated client after the full handshake is finished successfully, 72 and then in subsequent connection requests client uses PT for session resumption. 73 The resulting session resumption protocol establishes distinct session keys for every 74 connections that the same PT can be used multiple times for longer period of lifetime. 75 We show that the proposed session resumption protocol can improve the performance 76 of TLS a lot. The proposed scheme has the following distinguished features. 77 1.
It provides time-based one-time authenticated key establishment in session resump-78 tion in stateless way. 79

2.
The same PT can be used multiple times for session resumption for longer period traffic. TLS provides authentication, confidentiality, and integrity in end-to-end com-95 munications. It consists of two sub-protocols; handshake protocol and record protocol. 96 In handshake protocol client and server authenticate each other and establish a secure 97 session key, and then in record protocol all end-to-end communications are encrypted 98 with the secure session key. There are two handshake protocols; full handshake protocol 99 for the first time connection and session resumption protocol for the efficient handshake 100 with revisiting clients.

101
The full handshake protocol of TLS is computationally expensive due to certificate-102 based authentication and Diffie-Hellman key exchange. In recently released TLS 1.3 103 (RFC8446) [1] reducing latency in handshake protocol was a hot issue. Main approaches 104 for reducing latency in handshake were reducing round trip time (RTT) and using 105 session resumption with pre-shared key (PSK) [2].
106 Figure 1 shows the full handshake protocol in TLS 1. If PSK mode is enabled in TLS 1.3, efficient session resumption can be used. Figure   118 2 shows the session resumption protocol using PSK. In figure 1  security. It is also vulnerable to replay attacks [3] and denial of service (DOS) attack.

138
There is a possibility of tracking users [13].

145
So it is subject to eavesdropping and replay attack that the whole web service should be 146 protected with secure communication channel such as https [7].

147
Paired token (PT) [15,16,19] was originally proposed to solve the static nature 148 of bearer token authentication and secure channel requirement in web environment.

149
PT is a new secondary credential scheme that provides stateless pre-shared key (PSK)   Let's consider a simplified authentication model between client and server. Client 163 is registered to the server and has some primary credential for initial authentication.

164
Assume that server has a master secret key K which is used for issuing tokens. It is used 165 only inside the server and never exposed outside.
In initial authentication client logs into the server using primary credential, for 167 example, using ID and password. If initial authentication is successful, server computes 168 two tokens as follows.

2.
Secret token T s = G JWT (K, T p ) : a recursive JWT on the above public token T p .

172
Here G JWT (K, In f o) is an abstract notation of issuing process of a JWT [4][5][6]19]. It represents that server prepares user-specific authorization information In f o and puts it in the Payload, prepares proper Header, and generates a Signature, a HMAC value of the Header and Payload using the server's secret K, Signature = HMAC(K, Header||Payload).
Then Token = [Header.Payload.Signature] is a valid JWT issued to the user by the server. passed, it will be invalidated. T s is computed from T p and it will be computed frequently 177 in the server in later authentication stages. Therefore no time information is included 178 in the computation of T s to make these repeated computations be easy with no lifetime  Public token T p represents a signed identity of the user and will be sent to the server 188 to provide identification of client. Note that its validity can be verified only by the server 189 who has issued it, since the master secret key K is needed in verification. Secret token T s 190 is a kind of shared secret between client and server, and it will never be sent to server 191 directly. Server does not need to save < T p , T s > in DB, since T p will be presented by the 192 client and T s can be computed anytime from T p . Therefore T s is an inherently shared 193 secret with the server in a stateless way. Maybe server can decide to store T p for logging 194 purpose, but it will not be used in later authentication and key establishment stage. 1.
In the full handshake protocol PT is issued to authenticated client in NewSes-222 sionTicket. 223 2.
In the session resumption protocol session key is established using PT.

233
Server encrypts < T p , T s > using the shared session key and sends it to client. Then 234 client decrypts it to recover < T p , T s > and saves it in client system.

235
In public token server can include any client-specific information such as IP address,

236
OS information, browser information, issuing time, lifetime of the token, etc, according 237 to its policy. It is signed by the server with the master secret key K and its validity is 238 verifiable only by the server who knows K. Secret token is generated by recursively 239 signing the public token with no lifetime information. It can be generated only by the 240 server.

241
Since the same PT will be used multiple times for session resumption during the 242 lifetime of PT, this process of issuing PT is executed very infrequently only in full 243 handshake. If client is equipped with a valid PT, session resumption using PT will be 244 used more dominantly.  Client and server already share the same secret token in stateless way, thus they can establish PSK in any pre-agreed manner. For example, client prepares current time t and computes auth = HMAC(T s , t||T p ), PSK = HMAC(T s , t||T p ||"key").
Client sends < T p , t, auth > to server.

255
Upon receiving < T p , t, auth >, server verifies the validity of auth in the following 256 steps.

271
Note that real session keys will be distinct depending on client's request time t. This is a 272 real 0-RTT handshake, since client can send encrypted application level data in the first 273 request message.

274
This is a single message, one-way, deterministic key establishment. It will be very 275 useful for lightweight client and intermittent communications such as IoT applications.
Client sends < T p , t, g x , auth1 > to server.

282
Upon receiving < T p , t, g x , auth1 >, server verifies the validity of auth1 in the 283 following steps. 284 1.
Verifies the validity of T p and identifies who is requesting authentication. 285

2.
Gets his own current time and checks that the time difference from client's request 286 time t is within certain allowed limit (checking liveness to defend against replay 287 attack).

3.
Computes the secret token T s = G JWT (K, T p ) from T p and then verifies the validity auth1 ? = HMAC(T s , t||T p ||g x ).
If all the above verifications are successful, server prepare its ephemeral DH key share g y and computes auth2 = HMAC(T s , t||T p ||g xy ), PSK = HMAC(T s , t||T p ||g xy ||"key").
Server sends < T p , t, g x , g y , auth2 > to client. If client wants to send encrypted application level data in the first request message, it can do it by using a temporal PSK PSK = HMAC(T s , t||T p ||g x ||"key"). (11) Server can compute the same PSK and decrypt it. Thus, it can provide 0-RTT handshake, 295 though the first message does not provide forward security.   Integration with application level authentication. TLS is a transport layer security 365 protocol and it normally provides communications security which is independent from 366 application layer security. In TLS server authentication is mandatory, but client authenti-367 cation is optional. Client authentication using certificate is hard to manage in the real 368 world.

369
In the session ticket-based session resumption, the session key itself is a credential 380 and the same session key is used again in the resumed session. Thus reuse of the fixed 381 session key multiple times in different sessions should be very careful. When client 382 requests session resumption by sending session ticket, there is no explicit authentication 383 mechanism that server cannot distinguish replay attacks or forged requests. Therefore it 384 is subject to replay attack and denial of service (DOS) attack. If the same session key is 385 reused multiple times, attackers can trace the activities of clients and forward security 386 cannot be achieved [13].

387
On the other hand, the proposed PT-based session resumption provides explicit   Now we compare the features of the proposed 3 models of session resumption. and forward security is a prime concern, this is a reasonable session resumption model.

416
Since the same PT is used multiple times, it cannot provide anti-tracing.   token and established session key is never exposed over the communication network.

Secrecy of messages.
In PT-based session resumption protocol, client sends < 460 T p , t, auth > to server in plaintext to start the session resumption. This is the only 461 message exposed to network attackers. All other messages can be sent in encrypted form 462 using the 0-RTT feature of the proposed protocol. If attacker is successful in hacking the system and get the PT itself, then every 474 attacks are possible, such as sniffing or spoofing the attacked clients. Since secret token 475 is a secondary credential that has to be stored and used in the client system, its security 476 will highly depend on the system security, key storage security, and application security.
477 Therefore, client system has to be kept secure using the best practice in the point of 478 system security. This is a common system security argument in which credential is 479 stored and used in the system itself.

495
Paired token is a useful secondary credential scheme that can provide stateless PSK 496 between client and server. It looks like a useful cryptographic ticket that is issued by a 497 server to an authenticated VIP client. In this paper we modified TLS 1.3 protocol such 498 that server issues PT to authenticated client in full handshake protocol, and then stateless 499 time-based one-time authenticated session resumption using PT is used dominantly.