3.1.4.1 Session-Key Negotiation
Session-key negotiation between a client and a server is performed over an unprotected RPC channel.
The following diagram illustrates the negotiation flow.
Figure 7: Session-key negotiation
Session-key negotiation works as follows.
The client binds to the remote Netlogon RPC endpoint on the server. The client then generates a nonce, called the client challenge, and sends the client challenge to the server as an input argument to the NetrServerReqChallenge method call.
The server receives the client's NetrServerReqChallenge call. The server generates its own nonce, called the server challenge (SC). In its response to the client's NetrServerReqChallenge method call, the server sends the SC back to the client as an output argument to NetrServerReqChallenge. After the client has received the server's response, both computers have one another's challenge nonce (client challenge and server challenge (SC), respectively).
The client computes a session key, as specified in section 3.1.4.3, Session-Key Computation. The client specifies an initial set of capabilities by providing an initial set of values in the NegotiateFlags.
The client computes its client Netlogon credential by using client challenge as input to the credential computation algorithm, as specified in section 3.1.4.4.
The client exchanges its client Netlogon credential with the server by passing it in the NetrServerAuthenticate, NetrServerAuthenticate2, or NetrServerAuthenticate3 call as the ClientCredential input argument. The selection of the specific method called by the client is specified in section 3.4.5.2.2.
The server receives the NetrServerAuthenticate, NetrServerAuthenticate2, or NetrServerAuthenticate3 call and verifies the client Netlogon credential. It does this by computing a session key, as specified in section 3.1.4.3, duplicating the client Netlogon credential computation, using its stored copy of client challenge, and comparing the result of this recomputation with the client Netlogon credential that was just received from the client. If the comparison fails, the server MUST fail session-key negotiation without further processing of the following steps.
If none of the first 5 bytes of the client challenge is unique, the server MUST fail session-key negotiation without further processing of the following steps.<71>
The server computes its server Netlogon credential by using the server challenge as input to the credential computation algorithm, as specified in section 3.1.4.4. The server returns the server Netlogon credential as the ServerCredential output parameter of the NetrServerAuthenticate, NetrServerAuthenticate2, or NetrServerAuthenticate3 call.
The client verifies the server Netlogon credential. It does this by recomputing the server Netlogon credential, using its stored copy of server challenge, and comparing the result of this recomputation with the server Netlogon credential passed back from the server. If the comparison fails, the client MUST fail session-key negotiation.
Upon mutual verification, the client and server agree to use the computed session key for encrypting and/or signing further communications.
The client calls the NetrLogonGetCapabilities method to get Negotiaged flags by setting QueryLevel to 1 (section 3.4.5.2.11).
The server SHOULD<72> return the negotiated flags for the current exchange.
The client SHOULD<73> compare the received ServerCapabilities (section 3.5.4.4.11) with the negotiated NegotiateFlags (section 3.5.4.4.2), and if there is a difference, the session key negotiation is aborted.
The client calls the NetrLogonGetCapabilities method to get Requested flags by setting QueryLevel to 2 (section 3.4.5.2.11).
The server SHOULD<74> return the client capabilities received during a negotiation request from client.
The client SHOULD<75> compare the received Requested flags (section 3.5.4.4.11) with the flags it has actually sent during negotiation (section 3.5.4.4.2), and if there is a difference, the session key negotiation is aborted.
The client sets the ServerSessionInfo.LastAuthenticationTry (indexed by server name) to the current time. This prevents authentication retries from occurring for 45 seconds unless a new transport notification is received.
In the first phase of session-key negotiation (NetrServerReqChallenge), the client and server exchange nonces. This allows both the client and the server to compute a session key by using the algorithm defined in section 3.1.4.3. To provide mutual authentication, both the client and the server calculate a Netlogon credential based on their own nonce, using the computed session key, and exchange them in the second phase of session-key negotiation (NetrServerAuthenticate or NetrServerAuthenticate2 or NetrServerAuthenticate3). Because nonces are exchanged in the first phase, this allows each side to calculate the other party's Netlogon credential locally, and then compare it with the received one. If the locally computed credential matches the one supplied by the other party, this proves to the client and to the server that the respective party has access to the shared secret.
For more information about the methods involved in session-key negotiation, see client and server details in sections 3.4 and 3.5.