Andrew,
I wanted to follow up on your request to add the sentence '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' to the MS-PAC documentation.
We feel that the addition of your suggested sentence is not accurate for the
Microsoft implementation of MS-PAC. As per the documentation there must be 2
signatures included in the PAC_INFO_BUFFER structure. This is defined in
sections 2.4 and 2.8 with respect to the ulType field. There must be both type
0x0006 and type 0x0007 signatures present for PAC structure validation
to succeed.
Please let us know if you have further questions.
Richard Guthrie
Open Protocols Support Team
Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
Tel: +1 (469) 775-7794
E-mail: [EMAIL PROTECTED]
-Original Message-
From: Andrew Bartlett [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 04, 2008 4:46 PM
To: Richard Guthrie
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: How to validate the PAC in NETLOGON
On Thu, 2008-09-04 at 06:54 -0700, Richard Guthrie wrote:
Andrew,
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 parameter.
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
structure.
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 2.2.2.1) 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.
Thanks,
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba
