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

[Obaid Farooqi]

Hi Metze:
Product group in working on getting the document updated for the problems you specified below.
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.

Regards,
Obaid Farooqi
Sr. Escalation Engineer | Microsoft

-----Original Message-----
From: Stefan Metzmacher <metze at samba.org>
Sent: Thursday, May 14, 2026 7:05 AM
To: Obaid Farooqi <obaidf at microsoft.com>; Volker.Lendecke at sernet.de
Cc: cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
Subject: Re: [cifs-protocol] [EXTERNAL] NEGOEX uninitiated MESSAGE_TYPE_ACCEPTOR_NEGO in SMB2 negprot response - TrackingID#2604270040005966

Hi Obaid,

> 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
                        }
                }
        }
}

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!

Thanks!
metze