[cifs-protocol] [EXTERNAL] NEGOEX uninitiated MESSAGE_TYPE_ACCEPTOR_NEGO in SMB2 negprot response - - TrackingID#2609090040010339

[Stefan Metzmacher]

Hi Obaid,

> Product group in working on getting the document updated for the problems you specified below.

Thanks!

> I just want to confirm that the documentation of meta data for Negoex, as mentioned below, is the only issue and there are no other outstanding issues related to authentication on SMB when both client and server are Entra ID joined.

I'm sure there is much more

E.g. in wireshark we need special handling for pku2u in the generic pkinit handler:


static const ber_sequence_t PA_PK_AS_REQ_pku2u_sequence[] = {
   { &hf_pkinit_signedAuthPack, BER_CLASS_CON, 0, 0, dissect_cms_SignedData },
   { &hf_pkinit_trustedCertifiers, BER_CLASS_CON, 1, BER_FLAGS_OPTIONAL, dissect_pkinit_SEQUENCE_OF_ExternalPrincipalIdentifier },
   { &hf_pkinit_kdcPkId      , BER_CLASS_CON, 2, BER_FLAGS_OPTIONAL|BER_FLAGS_IMPLTAG, dissect_pkinit_OCTET_STRING },
   { NULL, 0, 0, 0, NULL }
};

static const ber_sequence_t DHRepInfo_pku2u_sequence[] = {
   { &hf_pkinit_dhSignedData , BER_CLASS_CON, 0, 0, dissect_cms_SignedData },
   { &hf_pkinit_serverDHNonce, BER_CLASS_CON, 1, BER_FLAGS_OPTIONAL, dissect_pkinit_DHNonce },
   { &hf_pkinit_kdf          , BER_CLASS_CON, 2, BER_FLAGS_OPTIONAL, dissect_pkinit_KDFAlgorithmId },
   { NULL, 0, 0, 0, NULL }
};

static const ber_choice_t PA_PK_AS_REP_pku2u_choice[] = {
   {   0, &hf_pkinit_dhInfo       , BER_CLASS_CON, 0, 0, dissect_pkinit_DHRepInfo },
   {   1, &hf_pkinit_encKeyPack   , BER_CLASS_CON, 1, 0, dissect_cms_SignedData },
   { 0, NULL, 0, 0, 0, NULL }
};

While the default is this:

static const ber_sequence_t PA_PK_AS_REQ_sequence[] = {
   { &hf_pkinit_signedAuthPack, BER_CLASS_CON, 0, 0, dissect_cms_ContentInfo },
   { &hf_pkinit_trustedCertifiers, BER_CLASS_CON, 1, BER_FLAGS_OPTIONAL, dissect_pkinit_SEQUENCE_OF_ExternalPrincipalIdentifier },
   { &hf_pkinit_kdcPkId      , BER_CLASS_CON, 2, BER_FLAGS_OPTIONAL|BER_FLAGS_IMPLTAG, dissect_pkinit_OCTET_STRING },
   { NULL, 0, 0, 0, NULL }
};

static const ber_sequence_t DHRepInfo_sequence[] = {
   { &hf_pkinit_dhSignedData , BER_CLASS_CON, 0, 0, dissect_cms_ContentInfo },
   { &hf_pkinit_serverDHNonce, BER_CLASS_CON, 1, BER_FLAGS_OPTIONAL, dissect_pkinit_DHNonce },
   { &hf_pkinit_kdf          , BER_CLASS_CON, 2, BER_FLAGS_OPTIONAL, dissect_pkinit_KDFAlgorithmId },
   { NULL, 0, 0, 0, NULL }
};

static const ber_choice_t PA_PK_AS_REP_choice[] = {
   {   0, &hf_pkinit_dhInfo       , BER_CLASS_CON, 0, 0, dissect_pkinit_DHRepInfo },
   {   1, &hf_pkinit_encKeyPack   , BER_CLASS_CON, 1, 0, dissect_cms_ContentInfo },
   { 0, NULL, 0, 0, 0, NULL }
};

So dissect_cms_ContentInfo needs to be replaced by dissect_cms_SignedData in order to
dissect the pku2u traffic we see between windows.

Wiresharks asn.1 has this:

ContentInfo ::= SEQUENCE {
   contentType ContentType,
   content [0] EXPLICIT ANY DEFINED BY contentType }

ContentType ::= OBJECT IDENTIFIER

SignedData ::= SEQUENCE {
   version CMSVersion,
   digestAlgorithms DigestAlgorithmIdentifiers,
   encapContentInfo EncapsulatedContentInfo,
   certificates [0] IMPLICIT CertificateSet OPTIONAL,
   crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
   signerInfos SignerInfos }

 From pkinit captures I see that the SignedData is placed into the content of ContentInfo with
contentType 1.2.840.113549.1.7.2 (id-SignedData), which also aligns with:
https://datatracker.ietf.org/doc/html/rfc4556#section-3.2.1
Maybe PKU2U uses some draft version of rfc4556?

>> We already cover negTokenInit2 in MS‑SPNG and note that it can include a mech token. The metadata message format is also documented in MS‑NEGOEX.
>> We don’t have a standalone PKU2U spec, but I’ve included the relevant details from the RFCs and drafts in previous email.
> 
> The thing is that https://datatracker.ietf.org/doc/html/draft-zhu-pku2u-09
> 6.1.  Context Token Derived from KRB_AS_REQ talks about InitiatorNameAssertion, which looks similar to what we see in the INITIATOR_META_DATA and ACCEPTOR_META_DATA blobs.
> 
> But the asn.1 definition is completely different in wireshark I used this:
> 
> PKU2UInitiatorName ::= SEQUENCE {
>          issuer SEQUENCE {
>                  rDNSequence [0] SEQUENCE {
>                          rDN SET OF SEQUENCE {
>                                  objectType OBJECT IDENTIFIER,
>                                  objectValue BMPString
>                          }
>                  }
>          }
> }

As far as I understand now, this is just issuer field from the certificate

> PKU2UTargetName ::= SEQUENCE {
>          realm [0] Realm,
>          clientName [1] PrincipalName
> }
> 
> PKU2UInitiatorMetaData ::= SEQUENCE {
>          initiatorName [0] PKU2UInitiatorName OPTIONAL,
>          targetName [1] PKU2UTargetName OPTIONAL }
> 
> And it seems to dissect the captures now.
> 
>>   From my perspective, this gives reasonable coverage.
>> If you think there’s a better place to document this or a gap we should address, I’d be interested in your suggestions.
> 
> I'm not sure, but we need all details where things differ from the draft.
> 
>> Am Fri, May 08, 2026 at 11:31:36PM +0000 schrieb Obaid Farooqi:
>>> MS-SPNG also mention negTokenInit2 message that can optionally
>>> contain a mech token and in this it relates to first choice which is NEGOEX.
>>> This token is a NEGOEX message containing the meta data.
>>> In this mech token (negoex), server is advertising the issuers name
>>> of the certificate issuer that it expects from the client.
>>>
>>> CN = MS-Organization-P2P-Access [2026]
>>>
>>> I believe the proper place for this is a document that would describe
>>> the PKU2U specific meta data.
>>>
>>> PKINIT RFC4556 does mention TD-TRUSTED-CERTIFIERS. PKU2U uses PKINIT.
> 
> While it uses pkinit it seems at least in wireshark we need to use dissect_cms_SignedData where normally dissect_cms_ContentInfo is used.
> 
> We need to know about such differences!

Ok, maybe this will already be covered?

Then we may also need some logic flow description,
like the '3. Protocol Details' section.

Thanks!
metze