Partager via

3.1.1 Abstract Data Model

  • Article

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.

The SPNEGO Extension makes no extensions to the abstract data model for SPNEGO.

This protocol includes the following ADM elements, which are directly accessed from NLMP as specified in [MS-NLMP] section 3.4.1:

  • ClientHandle

  • ServerHandle

SPNEGO exports a set of abstract parameters that describe the security services that a caller wants to have available for use on the communication session after it has been established. SPNEGO cannot directly act on these parameters because it does not perform the actual authentication. They are passed through to the underlying security protocols as an indication of the caller's eventual plans. These parameters are:

  • Integrity: A Boolean setting that indicates that the caller wants to sign messages so that they cannot be tampered with while in transit.

  • Replay Detect: A Boolean setting that indicates that the caller wants to sign messages so that they cannot be replayed.

  • Sequence Detect: A Boolean setting that indicates that the caller wants to sign messages so that they cannot be sent out of order.

  • Confidentiality: A Boolean setting that indicates that the caller wants to encrypt messages so that they cannot be read while in transit.

  • Delegate: A Boolean setting that indicates that the caller wants to make its own identity available to the server for further identification to other services.

  • Mutual Authentication: A Boolean setting that indicates that the client and server MUST authenticate each other; unidirectional authentication is not permissible.

    These flags correspond to the reqFlags:ContextFlags field in the NegTokenInit structure. As specified in [RFC4178], the reqFlags:ContextFlags field is now only for legacy purposes and SHOULD NOT be filled in. For more information about the reqFlags:ContextFlags field, see section 3.1.5.3.

  • Extended Error: A Boolean setting that indicates that the caller wants the underlying protocol to perform the extended error handling, potentially including retries within the GSS exchange.

  • FragmentToFit: A Boolean setting that indicates that the caller directs the underlying protocol to fragment messages.<7>

  • MaxOutputTokenSize: The maximum size, in bytes, of output_token that can be returned to the caller, as specified in [RFC2478] Section 2.2. This value MUST be at least 5 bytes to contain the entire ASN.1 header, so that the recipient can reconstruct the length of the completed message. Applications that request small buffers can significantly increase the number of round trips. An application can have limitations on the number of round trips allowed, which means that setting the buffers too small can cause failures. Also, authentication protocols can be sensitive to clock skews between the client and server, which can cause failures if the amount of time required to transmit all the messages is too long.

The following temporary variables are used by the fragmenting functions:

  • FragmentInputToken: A Boolean setting that indicates that more fragments of input_token remain, as specified in [RFC2478] section 4.2.

  • ReceivedInputToken: The fragments of input_token received.

  • TokenLength: The length of input_token.

  • FragmentOutputToken: A Boolean setting that indicates that more fragments of output_token remain.

  • RemainingOutputToken: The remaining message to be sent.

The following temporary variable is used to reset the NLMP RC4 handle:

  • OriginalHandle