3.3 Get Service Ticket [ITI-3]

This section corresponds to transaction [ITI-3] of the IHE IT Infrastructure Technical Framework. Transaction [ITI-3] is used by the Client Authentication Agent and Kerberos Authentication Server Actors.

3.3.1 Scope

The Client Authentication Agent uses this transaction to obtain the service ticket that will be sent to a Kerberized Server to authenticate this user to a Kerberized Server.

3.3.2 Use Case Roles

Actor: Client Authentication Agent.

Role: Client communicates authentication information to the Kerberos Authentication Server, receives a Service Ticket, and performs internal ticket management.

Actor: Kerberos Authentication Server. In RFC1510 this is called a Key Distribution Center (KDC).

Role: Verifies the authentication information, creates a ticket, and sends it to the Client Authentication Agent.

3.3.3 Referenced Standard

RFC1510   The Kerberos Network Authentication Service (V5)

3.3.4 Messages

3.3.4.1 Get Service Ticket

The Client Authentication Agent requests a service ticket that will be sent to a Kerberized Server to authenticate this user to a Kerberized Server.

3.3.4.1.1 Trigger Events

A service ticket is requested prior to communicating with a Kerberized Server. This ticket will be provided to that service as part of the Kerberized communication process.

3.3.4.1.2 Message Semantics

The Client Authentication Agent requests credentials for a service by sending the Kerberos Authentication Server a Kerberos Ticket-Granting Service Request (KRB_TGS_REQ). This message includes the user’s name, an authenticator encrypted with the user’s logon session key, the TGT obtained in the Get User Authentication Transaction, and the name of the service for which the user wants a ticket.

When the Kerberos Authentication Server receives KRB_TGS_REQ, it decrypts the TGT with its own secret key, extracting the logon session key. It uses the logon session key to decrypt the authenticator and evaluates that. If the authenticator passes the test, the Kerberos Authentication Server extracts the authorization data from the TGT and invents a session key for the client to share with the Kerberized Server that supports the service. The Kerberos Authentication Server encrypts one copy of this session key with the user’s logon session key. It embeds another copy of the session key in a ticket, along with the authorization data, and encrypts this ticket with the service’s long-term key. The Kerberos Authentication Server then sends these credentials back to the client in a Kerberos Ticket-Granting Service Reply (KRB_TGS_REP).

There are no IHE specific extensions or modifications to the Kerberos messaging.

3.3.4.1.3 Expected Actions

When the Client Authentication Agent receives the reply, it uses the logon session key to decrypt the session key to use with the service, and stores the key in its credentials cache. Then it extracts the ticket for the service and stores that in its cache. The client shall maintain the ticket in the credentials cache for later use.

3.3.4.1.4 Service Registration

The Kerberized Communication services supported in an enterprise shall be registered on the Kerberos Authentication Server according to the RFC1510 protocol specification used. The registration of the service on the KDC is outside the scope of this profile.

3.3.5 Security Considerations

The Get Service Ticket [ITI-3] transaction is not required to log an ATNA UserAuthentication event in the case of successful communications. An ATNA UserAuthentication event shall be logged when the communications fails for the purpose of authentication failure.