[cifs-protocol] RE: How to validate the PAC in NETLOGON
abartlet at samba.org
Thu Sep 4 21:45:44 GMT 2008
On Thu, 2008-09-04 at 06:54 -0700, Richard Guthrie wrote:
> I am still researching the issue you are getting with
> NT_STATUS_INVALID_PARAMETER however I wanted to send you an update to
> the documentation based on your last feedback regarding computation of
> the KDC signature. Section 2.8.1 will be revised as follows (revised
> text in paragraph 3):
Bugger (sorry). I should have got back to you sooner. I get 'invalid
parameter, because I didn't encrypt the field. The encryption is
correctly specified in the doc, just hard to find. Naturally enough,
the unencrypted values (when 'decrypted' using RC4) presents an invalid
I now have this working (client and server).
> Section 2.8.1 Revision
> Signatures are generated by the issuing KDC and depend on the
> cryptographic algorithms available to the KDC. The checksum type MUST
> be one of the values defined in the table in section 2.8. The key
> usage value MUST be KERB_NON_KERB_CKSUM_SALT (17).
Is there any chance you could change your names to match those in
krb5.h? Heimdal uses this:
KRB5_KU_OTHER_CKSUM = 17,
/* Data which is defined in some specification outside of
Kerberos to be checksummed using an RFC1510 checksum type. */
> A PAC MUST contain two such signatures: one keyed so that the server
> can verify it, and the other keyed so that the KDC can verify it.
> Prior to the signature being generated by the issuing KDC, the entire
> PAC must be constructed. The entire message, including the PACTYPE
> (section 2.3) header and all PAC elements, MUST be constructed into a
> contiguous buffer. The Signature fields of the PAC_SIGNATURE_DATA
> structures MUST all be set to zero.
> To generate the server signature, the keyed hash function selected, as
> specified in [RFC4757], MUST be computed over the entire PAC buffer.
> The key selected for the algorithm MUST be the server's key known to
> the KDC. The resulting hash value is then placed in the Signature
> field of the server's PAC_SIGNATURE_DATA structure.
> Before verifying the server signature, the Signature field values are
> removed from the PAC buffer and MUST be replaced with zeros. Then the
> hash is generated as specified in [RFC4757]. The resulting hash is
> compared with the locally stored version; if they match, the signature
> MUST be considered valid.
> To generate the KDC signature, first the server signature must have
> been constructed according to the previous two paragraphs, then the
> keyed hash function MUST be computed over the signature field value of
> the server's PAC_SIGNATURE_DATA. The key selected for the algorithm
> MUST be the key of the KDC (krbtgt) itself [RFC4120]. The resulting
> hash is placed in the Signature field of the KDC's PAC_SIGNATURE_DATA
> To verify the KDC signature, the keyed hash MUST be generated over the
> version of the server signature received in the
> KERB_VERIFY_PAC_REQUEST structure [MS-APDS] (section 18.104.22.168) using
> the algorithm specified in the SignatureType field in the
> KERB_VERIFY_PAC_REQUEST structure. The resulting hash is compared with
> the KDC signature value in the Signature value field in the
> KERB_VERIFY_PAC_REQUEST structure; if they match, the signature MUST
> be considered valid.
> A PAC with an invalid signature MUST be rejected.
Any chance of adding an additional line of 'because the client has
already validated the server signature over the whole PAC, and because
the kdc signature if calculated over the server signature, it is
sufficient to send only the server signature to the NETLOGON server'?
It does not say anything you don't say above, but would have made me
realise why this works, and therefore led me to the implementation.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20080905/6c1c5487/attachment.bin
More information about the cifs-protocol