Kerberos: What is the structure for preauthentication with certificate (RFC 4556)

Question

I'm struggling to understand what the structure of a preauthentication request in kerberos should look like. After reading RFC 4556 and the referenced RFCs I'm still confused because of all the different cases.

My usecase is as follows: I want to authenticate on a windows domain with a certificate I retrieved from the CA belonging to the domain. The certificate contains the crl-URL and it's signature-algorithm is sha256RSA. The contained public key is a RSA2048 key. As far as I understand I should send this certificate and sign it. I'm also aware that I have to send a nonce to avoid replay attacks.

I'm unclear what has to be signed, i.e. what has to be in this part of the request.

PA-PK-AS-REQ ::= SEQUENCE {
          signedAuthPack          [0] IMPLICIT OCTET STRING,
                   -- Contains a CMS type ContentInfo encoded
                   -- according to [RFC3852].

RFC 3852 states:

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

Although there's a lot of explanation to all these points, I'm afraid I'm a dummie as I just don't get it. Especially what belongs into version and encapContentInfo (I think the signature should go into the econtent-Field of the EncapsulatedContentInfo, but I'm not sure).

As the spec is a little confusing I just don't get what else has to be in this request and what not.

Can anybody shed a little light on this and clarify how the structure of the complete request should look like?

EDIT

OK, after some research I am even more confused. RFC 4556 states that the structure of PkAuthenticator in the AuthPack should look like this:

PKAuthenticator ::= SEQUENCE {
    cusec                   [0] INTEGER -- (0..999999) --,
    ctime                   [1] KerberosTime,
    nonce                   [2] INTEGER (0..4294967295),
    paChecksum              [3] OCTET STRING OPTIONAL,
    ...
}

Sniffing the smartcard-authentication-traffic with wireshark I got this PKAuthenticator-structure in a microsoft-environment:

SEQUENCE(1 elem)
    [0](1 elem)
        SEQUENCE(5 elem)
            [0](1 elem)
                SEQUENCE(2 elem)
                    [0](1 elem)
                        INTEGER2
                    [1](1 elem)
                        SEQUENCE(2 elem)
                            GeneralString
                            GeneralString
            [1](1 elem)
                GeneralString
            [2](1 elem)
                INTEGER 563793
            [3](1 elem)
                GeneralizedTime 2016-12-01 13:53:08 UTC
            [4](1 elem)
                INTEGER 1051204026

Is this the usual behaviour of microsoft doing their own thing regardless of what the spec says or am I missing something?

Answer 1

I'm addressing the question you added with your edit.

As documented by Microsoft, some Windows versions ("<2> Section 2.2: [RFC4556] message syntax is not supported in Windows 2000, Windows XP, and Windows Server 2003.") are based on an earlier draft of RFC 4556 that defined the following structure for PKAuthenticator (draft version 11 was the last to use this syntax for PKAuthenticator):

--
-- PK-AUTHENTICATOR - Different from [RFC4556]
-- Appendix A, PKAuthenticator.
--
PKAuthenticator::= SEQUENCE {
     kdc-name   [0] PRINCIPAL-NAME,
     kdc-realm  [1] REALM,
 -- name and realm of the KDC issuing the ticket
     cusec      [2] INTEGER,
     ctime      [3] KerberosTime,
     nonce      [4] INTEGER
 }

With the final RFC (draft version 22 actually) the identifier for PA-PK-AS-REP also changed from 15 to 17 to distinguish between the two format specifications (Microsoft mentions that too: "An earlier draft of [RFC4556] supported a different pre-authentication data identifier: PA-PK-AS-REP_OLD 15").