[cifs-protocol] [REG:115012312316449] Re: Protocol changes in KB2992611 [115012312316449]

[Andrew Bartlett]

On Fri, 2015-03-13 at 22:00 +0000, Edgar Olougouna wrote:
> I am concerned whether you observed any different behavior that this WBN. Are you saying that ClientWrap and ServerWrap appear to you as mandatory? 

Yes.

> 3.2.4.1 Performing Client-Side Wrapping of Secrets
> 
> <18> Section 3.2.4.1: Windows XP, Windows Server 2003, Windows Vista,
> Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8,
> Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 fall back
> to server-side wrapping using BACKUPKEY_BACKUP_GUID when they fail to
> retrieve the server's public key using
> BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID.
> In addition, as noted earlier, Windows clients always retry failing
> operations once. The resulting process is as follows: The client first
> tries the BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID operation and, if it
> fails, performs DC rediscovery and retries the same operation. If the
> retry fails, the client tries a BACKUPKEY_BACKUP_GUID operation. If
> this fails, the client performs DC rediscovery again and retries the
> BACKUPKEY_BACKUP_GUID operation. If this also fails, an error is
> returned to the caller.
> 
> <19> Section 3.2.4.1: Windows 2000, Windows XP, Windows Server 2003,
> Windows Vista, and Windows Server 2008 always use version 2. Windows
> 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows
> 8.1, and Windows Server 2012 R2 use version 2 by default but can be
> configured to use version 3 by setting the DWORD registry value "HKLM
> \Software\Microsoft\Cryptography\Protect\Providers
> \df9d8cd0-1501-11d1-8c7a-00c04fc297eb\Recovery Version" to 3.

This largely matches what we see, except that we don't understand what
changed in this KB.  Before that KB the client did, as described, try
both ClientWrap and ServerWrap calls, but credentials manager still
worked if ServerWrap failed, after the KB it tries both and needs both
calls. 

This brings us back to the 'how do we tell if the ClientWrap call failed
(on the client side)' part of the question, and the trouble that the
call happens once, and once only, during the first domain logon.

Andrew Bartlett

> Thanks,
> Edgar
> 
> 
> -----Original Message-----
> From: Andrew Bartlett [mailto:abartlet at samba.org] 
> Sent: Wednesday, March 11, 2015 10:44 PM
> To: Edgar Olougouna
> Cc: MSSolve Case Email
> Subject: Re: [REG:115012312316449] Re: [cifs-protocol] Protocol changes in KB2992611 [115012312316449]
> 
> On Sat, 2015-03-07 at 22:01 +1300, Andrew Bartlett wrote:
> > On Sat, 2015-03-07 at 05:43 +0000, Edgar Olougouna wrote:
> > > When you review the certificate produced for ClientWrap, can you double check the size of the certificate and the size of its signature, especially in case of X509 ECC or DSA signature?
> > > I wonder whether there is any anomaly during certificate signature verification check.
> > 
> > A part of the history is that we started our effort to fix this by 
> > doing two things:
> >  - We took a patch from Arvid of Univention, who noticed 6 months ago 
> > that another aspect of Windows (IE password save) wouldn't work until 
> > the RSA Key for ClientWrap was corrected to be 2048 bits exactly.
> >  - As that wasn't enough, we started an implementation of ServerWrap.
> > 
> > It certainly could be the key or certificate.  The library we use to 
> > generate the certificate is unusual (Heimdal Kerberos).
> > 
> > We know the private key passes tests against OpenSSL (we had an error 
> > during re-implementation that we had to debug), but I'll go over this 
> > again.
> > 
> > I'll also give you the public and private keys it generates, perhaps 
> > you can poke it at a validation tool in current and pre-patched 
> > Windows and see if it shows errors.
> > 
> > All that said, how can we manually trigger or trace the ClientWrap 
> > calls, and wow can we know if this was the issue?
> 
> I get these in the logs, at startup, and then no other BackupKey
> traffic:
> 
> Client unknown requested certificate for client wrapped secret
> (018FF48A-EABA-40C6-8F6D-72370240E967)
> Client unknown requested a server wrapped secret
> (7F752B10-178E-11D1-AB8F-00805F14DB40)
> 
> I'm presuming this second call is encrypting the local master key on the KDC, as described in the other references, but what I want to know is why does it do this, was the ClientWrap call not enough?
> 
> I checked with an un-patched Windows, and it also calls:
> 
> Client unknown requested certificate for client wrapped secret
> (018FF48A-EABA-40C6-8F6D-72370240E967)
> Client unknown requested a server wrapped secret
> (7F752B10-178E-11D1-AB8F-00805F14DB40)
> 
> during the logon (and no additional calls during open of credentials manager).
> 
> This puts (mostly) to rest the idea that the ClientWrap call fails, but I would love a way to trace that for you, during the logon.  It then raises the question again of why ServerWrap went from optional to mandatory. 
> 
> Finally, can we put this back on cifs-protocol at lists.samba.org and into the public domain?
> 
> Thanks,
> 
> Andrew Bartlett
> 
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team  http://samba.org
> Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba
> 
> 
> 
> 
> 

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba