Compartilhar via

1.3.2 Kerberos Network Authentication Service (V5) Synopsis

  • Artigo

The Kerberos V5 protocol provides a mechanism for mutual authentication between a client and a server before application data is transmitted between them. Kerberos V5 is composed of three exchanges described in detail in [RFC4120] sections 1.1 and 3.

Kerberos V5 Exchanges

Figure 1: Kerberos V5 Exchanges

Note   The terms client, server and Key Distribution Center (KDC), as used in this section, refer to Kerberos V5 implementations of each entity. Unless explicitly noted, use of these terms in the remainder of this specification refers to KILE implementations of each entity.

The Authentication Service (AS) exchange ([RFC4120] section 3.1):<1>

  • Kerberos authentication service request message (KRB_AS_REQ) ([RFC4120] section 5.4.1): The client sends a request to the KDC for a ticket-granting ticket (TGT) ([RFC4120] section 5.3). The client presents its principal name and can present pre-authentication information.

  • Kerberos authentication service response message (KRB_AS_REP) ([RFC4120] section 5.4.2): The KDC returns a TGT and a session key the client can use to encrypt and authenticate communication with the KDC for ticket-granting service (TGS) requests, without reusing the persistent key.

The Ticket-Granting Service (TGS) exchange ([RFC4120] section 3.3):

  • Kerberos ticket-granting service (TGS) request message (KRB_TGS_REQ) ([RFC4120] section 5.4.1): The client sends a request to the KDC for a ticket ([RFC4120]  section 5.3) for the server. The client presents the TGT ([RFC4120] section 5.3), a Kerberos authenticator ([RFC4120] section 5.5.1), and the service principal name (SPN).

  • Kerberos ticket-granting service (TGS) response message (KRB_TGS_REP) ([RFC4120] section 5.4.2): The KDC validates the TGT ([RFC4120]  section 5.3) and the authenticator ([RFC4120] section 5.5.1). If these are valid, the KDC returns a service ticket ([RFC4120] section 5.3) and session key the client can use to encrypt communication with the server.

The Client/Server Authentication Protocol (AP) exchange ([RFC4120] section 3.2):

  • Kerberos application server request message (KRB_AP_REQ) ([RFC4120] section 5.5.1): The client requests access to the server. The client presents the ticket ([RFC4120] section 5.3) and a new authenticator ([RFC4120] section 5.5.1). The server will decrypt the ticket, validate the authenticator, and can use any authorization data ([RFC4120] section 5.2.6) contained in the ticket for access control.

  • Kerberos application server response message (KRB_AP_REP) ([RFC4120] section 5.5.2): Optionally, the client might request that the server verify its own identity. If mutual authentication is requested, the server returns the client's timestamp from the authenticator encrypted with the session key.

The AS exchange and TGS exchange are transported by Kerberos implementations. The AP exchange is passive and relies on an upper-layer application protocol to carry the AP exchange messages. Applications that use AP exchange messages directly are typically called "kerberized" applications. Most applications use the Generic Security Service Application Program Interface (GSS-API) and can even be wrapped by higher-level abstractions such as Simple Authentication and Security Layer (SASL) [RFC2222], which allows for "kerberized" connections to mail servers.