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.