220.127.116.11 Session-Key Negotiation
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, respectively).
The client computes a session key, as specified in section 18.104.22.168, Session-Key Computation. The client specifies an initial set of capabilities by providing an initial set of values in the NegotiateFlags.
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 particular method called by the client is specified in section 22.214.171.124.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 126.96.36.199, 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.
The server computes its server Netlogon credential by using the server challenge as input to the credential computation algorithm, as specified in section 188.8.131.52. 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.<85>
The server returns the negotiated flags for the current exchange.<86>
The client compares the received ServerCapabilities (section 184.108.40.206.10) with the negotiated NegotiateFlags (section 220.127.116.11.2), and if there is a difference, the session key negotiation is aborted.<87>
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 described in section 18.104.22.168. 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.