次の方法で共有

2.2.1 NegTokenInit2

  • [アーティクル]

The NegTokenInit2 message extends NegTokenInit with a negotiation hints (negHints) field. The NegTokenInit2 message SHOULD<4> be structured as follows.

 NegHints ::= SEQUENCE {
         hintName[0] GeneralString OPTIONAL,
         hintAddress[1] OCTET STRING OPTIONAL
 }
 NegTokenInit2 ::= SEQUENCE {
         mechTypes[0] MechTypeList OPTIONAL,
         reqFlags [1] ContextFlags OPTIONAL,
         mechToken [2] OCTET STRING OPTIONAL,
         negHints [3] NegHints OPTIONAL,
         mechListMIC [4] OCTET STRING OPTIONAL,
         ...
 }

mechTypes: The list of authentication mechanisms that are available, by OID, as specified in [RFC4178] section 4.1.

reqFlags: As specified in [RFC4178] section 4.2.1 This field SHOULD be omitted by the sender.

mechToken: The optimistic mechanism token ([RFC4178] section 4.2.1).<5>

negHints: The server supplies the negotiation hints using a NegHints structure that is assembled as follows.

  • hintName: SHOULD<6> contain the string "not_defined_in_RFC4178@please_ignore".

  • hintAddress: Never present. MUST be omitted by the sender. Note that the encoding rules, as specified in [X690], require that this structure not be present at all, not just be zero.

mechListMIC: The message integrity code (MIC) token ([RFC4178] section 4.2.1).

Note In the preceding ASN.1 description, the NegTokenInit2 message occupies the same context-specific ([X690] section 8.1.2.2) message ID as does NegTokenInit in SPNEGO.