2.1.2.2 Protocol Interactions

The following diagram depicts the protocol interactions of the network logon authentication.

Protocol interactions for network logon authentication

Figure 7: Protocol interactions for network logon authentication

As the preceding diagram shows, to provide this type of authentication, the Authentication Services subsystem includes the following authentication and auxiliary protocols.

Authentication protocols:

  • Digest Protocol Extensions [MS-DPSP]

  • Credential Security Support Provider (CredSSP) Protocol [MS-CSSP]

  • NT LAN Manager (NTLM) Authentication Protocol [MS-NLMP]

  • SSL/TLS Protocol [MS-TLSP]

  • Kerberos Protocol Extensions [MS-KILE] [MS-SFU] [MS-PKCA]

  • Simple and Protected Generic Security Service Application Program Interface Negotiation Mechanism (SPNEGO) Protocol Extensions [MS-SPNG]

  • The Extended GSS-API Negotiation Mechanism (NEGOEX) [NEGOEX-DRAFT]

  • Public Key Cryptography Based User-to-User Authentication - (PKU2U) [PKU2U-DRAFT]

  • Kerberos Proxy Key Distribution Protocol [MS-KKDCP]

Auxiliary Protocols:

Custom Authentication Protocols:

The Authentication Services subsystem provides an extensible network logon authentication architecture, which allows implementers to add custom authentication protocol security support providers (SSPs) to the subsystem architecture.

Authentication protocol selection

Both the client and server application protocols can select any authentication protocol from the list of supported authentication protocols through the GSS-API interface, either directly or indirectly.

The client and server application protocols can directly select any of the following authentication protocols through the GSS-API interface: Digest [MS-DPSP], NTLM [MS-NLMP], CSSP [MS-CSSP], Kerberos [MS-KILE], and SPNEGO [MS-SPNG], whereas application protocols can select indirectly any of the following authentication protocols: NTLM [MS-NLMP], Kerberos [MS-KILE], NEGOEX, PKU2U, and CUSTOM. The difference between direct and indirect selection is the use of the SPNEGO [MS-SPNG] protocol. Application protocols use the SPNEGO protocol when they attempt to select an authentication protocol indirectly; alternatively, application protocols can select the authentication protocol directly without using SPNEGO. Because support for these authentication protocols varies across Windows releases and application environments, the client and server application protocols have to select a mutually supported authentication protocol either directly or indirectly. For example, for a client and server to use the Kerberos authentication protocol, each have to support it.

The selection of an authentication protocol can be handled in one of three ways, each of which is described in more detail:

  • Assertion

  • Application-Level Negotiation

  • Negotiate. This option allows the parties to attempt to find an acceptable authentication protocol. This process is based on the Simple and Protected Generic Security Service Application Programming Interface Negotiation Mechanism (SPNEGO) Protocol [MS-SPNG].

Application-Level Negotiation uses the application-specific method or configuration to select the mutually agreed-on authentication protocol between client and server application protocols, whereas the other two options use the services of the Authentication Services subsystem.

Assertion

As a precondition for specifying a mutually agreed-on authentication protocol by using Assertion when calling GSS-API, both the client and the server have to directly specify a single authentication protocol from the set of Authentication Services subsystem supported authentication protocols.

When the application or server uses one and only one authentication protocol for the exchange, it specifies (asserts) the protocol to be used for the communication when replying to a client request to access a service. If the client does not support that protocol, the communication fails. This method of selection is called Assertion.

Application-Level Negotiation

When a client and a server support multiple authentication protocols, before authentication can take place, applications exchange application-specific messages to select a commonly supported authentication protocol. For example, if a client supports Kerberos and Digest and the server supports NTLM and Digest, the common protocol that they both support is Digest, so the client and the server can negotiate to use the Digest protocol. Similarly, the HTTP protocol uses the WWW-Authenticate and Authorization headers in its negotiation.

Using the Negotiate option

The Negotiate option allows the client and server applications that are engaged in the authentication process to select a mutually agreed-upon authentication protocol from a set of possible authentication protocols by using the SPNEGO protocol.

When the authentication process begins with the option to negotiate for an authentication protocol, the server or client can initiate the negotiation.

The server-initiated SPNEGO exchange takes place as follows:

  1. The client requests access to a service in an application-protocol-specific way.

  2. The server replies with a list of authentication protocols that it can support with its preferred authentication protocol as its first choice in the application protocol message. For example, the server might list Kerberos, NegoEx, and NTLM, and select Kerberos as its preferred authentication protocol.

  3. The client examines the contents of the reply and checks to determine whether it supports any of the specified protocols.

    • If the client supports the preferred authentication protocol, authentication proceeds.

    • If the client does not support the preferred authentication protocol, but does support one of the other protocols that the server lists, the client informs the server as to which authentication protocol it supports, and the authentication process continues.

    • If the client does not support any of the listed protocols, the authentication exchange fails.

The client-initiated SPNEGO takes place as follows:

  1. The client sends a list of authentication protocols and also a preferred authentication protocol to the server.

  2. The server examines the contents of the request message and checks to determine whether it supports any of the specified authentication protocols.

    • If the server supports the preferred authentication protocol, authentication proceeds.

    • If the server does not support the preferred authentication protocol, but does support one of the other protocols that the client lists, the server informs the client as to which authentication protocol it supports, and the authentication process continues.

    • If the server does not support any of the listed protocols, the authentication exchange fails.

As depicted in the preceding diagram, through the negotiation option, the client and server applications can select the NTLM, Kerberos, PKU2U, or Custom authentication protocol as the mutually agreed-on authentication protocol. To select either the PKU2U or the Custom authentication protocol, the application uses the NEGOEX protocol, which extends the SPNEGO protocol and enables the application protocol to choose a mutually agreed-on authentication protocol that is based on policy information.

For example, if the server specifies Kerberos and NTLM and returns Kerberos as its preferred authentication protocol, one client can immediately authenticate by using Kerberos, but another client could negotiate to complete the authentication exchange by using NTLM.

Auxiliary protocols

If the client and server agree on any of the following authentication protocols: Digest [MS-DPSP], NTLM [MS-NLMP], or SSL/TLS [MS-TLSP], an auxiliary protocol carries the credentials information from the server to the Authentication Authority (AA), for example, a Windows DC. This mechanism is called a pass-through mechanism.

When the client and server agree on either the Digest or the NTLM protocol, Authentication Protocol Domain Support [MS-APDS] performs the pass-through; otherwise, if the client and server agree on SSL/TLS, the Remote Certificate Mapping Protocol [MS-RCMP] is used for pass-through.

Show: