Test Case

Test Case Definition: it is a software testing document, which consists of event, action, input, output, expected result, and actual result. Clinically defined (IEEE 829-1998) a test case is an input and an expected result. 1. We can restrict some of the clients from possessing the ticket for the server and check its extension; the extension is expected to be empty. 2. During Handshake, before sending the NewSessionTicket to the client we must check for the client message status, i.e. whether it’s verified or not, the expected status is the finished message of the client to be verified. 3. When the ticket is received by the client, we must check for the opacity of the message. 4. When the server sends the new ticket to a client, we must test for the presence of Master Secret and other parameters which are required for the current session. 5. After the completion of the Handshake, test conditions should be put of the flow of the messages between the server and the client; this should obey the conventional flow as expected 6. On the rejection of the ticket, the full handshake should take place and test conditions should be applied to check whether the expected new ticket has been issued to the client (if it lies in the respective case) 7. If the client is prepared for receiving and sending ticket, we must check that it posses at least a Zero length ticket in the Session ticket extension. 8. In the ticket verification phase, if the server fails then a test case for the full handshake to have failed should be expected and checked. 9. If the full handshake fails, a test case on it acceptance should be applied and checked for the ticket deletion by the client. 10.Validity of the ticket in the client- this test condition should be applied to check that the client has verified the servers finished message. 11. Since the updated ticket is issued before the handshake completes, it is possible that the client may not put the new ticket into use before it initiates new connections, so the test condition should be applied to check the start of the new ticket issued to the client. 12.Ticket should be encrypted in such a way that it should not be visible 2 any eavesdropper nor the client, while sending the

ticket to the client, a check on the parameters passed and the secret key withheld with the server must be checked. 13. TICKET LIFETIME- it is indicated in the ticket lifetime field from the server and it indicates the life time in seconds, if the value is zero then it means the expiry is unspecified; a test condition should be applied to check whether the client which used the ticket DELETES it after its usage/expiry. 14. Ticket should be structure in such a way that it is not examinable by the clients. struct { opaque key_name[16]; opaque iv[16]; opaque encrypted_state<0..2^16-1>; opaque mac[20]; } ticket; 15. Fragment length test case: TLS specifies a fixed maximum plaintext fragment length of 2^14 bytes. It may be desirable for constrained clients to negotiate a smaller maximum fragment length due to memory limitations or bandwidth limitations, it should also be checked that nothing exceeds the maximum limit as specified. 16.If the fragment length value is other than the allowed value, an alert must be generated stating “illegal parameter” and the handshake must be aborted. 17.Session ID- if the server wants to issue a session ticket to the client that does not present one, it should include an empty session ID in the message. 18. A check on the assignment of TLS session ticket extension number to be in coherence with IANA consideration. Eg. 35 to session ticket and 4 to handshake type. 19.A check of the server not relying on the session ID while validating the ticket should be performed. 20. Client authentication: a test on the presence of the client’s certificates or the certificate URL’s during handshake when client authentication is performed. 21.As it’s the connection between client and server, there are possibilities of eavesdropping or modification of the ticket which is being transferred between server and client- test cases for security consideration must be applied, mainly regarding- stolen tickets, forged tickets and invalidation of sessions, ticket lifetime etc.

22. Validity of server certificates, a reference must be provided to the clients to save the bandwidth and roundtrips/resources. 23.Providing alerts for certain cases and testing for its generation for certain faults. Alerts for – unsupported extension, unrecognized name or certificate can be a remedy.