MS-NRPC: AES Schannel problems

[Stefan (metze) Metzmacher]

Hi,

I'm currently trying to implement the AES based Netlogon Secure Channel
in Samba.

But the documentation is not really clear about the used algorithms.

I have started with the implementation here:
http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel

And here's the actual commit that tries to add aes support:
http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=50dca9ce0f051c863f00cc949db2c19bf247887b

In Section "3.1.4.3 Session-Key Computation" the hmac-sha256 base
computation of the session-key seems to use the plain SharedSecret
and not the NT-HASH of it (MD4(UNICODE(ShareSecret))), is that correct?
I thought the plain text is never stored in AD by default...
Where should the netlogon server get the plain text from?
I just tried the NT-HASH see my netlogon_creds_init_hmac_sha256() function.

In Section "3.1.4.4 Netlogon Credential Computation" there's a
AesEncrypt function used. Can you please document the exact algorithm
that's used there. You say AES128 is used in CFB mode without
initialization vector.

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
says that all modes except ECB require an IV.

It would also be nice if you could add some more example values
in secion 4.2 Cryptographic Values for Session Key Validation.

metze






_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Metze,

   Thanks for your question.  I will be working on this request.  I will let you know as soon as I complete the investigation.

Thanks!

--------------------------------------------------------------------
Hongwei  Sun - Sr. Support Escalation Engineer
DSC Protocol  Team, Microsoft
hongweis@...
Tel:  [phone] x 57027
---------------------------------------------------------------------



-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze@...]
Sent: Tuesday, August 25, 2009 11:13 AM
To: Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...
Subject: MS-NRPC: AES Schannel problems

Hi,

I'm currently trying to implement the AES based Netlogon Secure Channel in Samba.

But the documentation is not really clear about the used algorithms.

I have started with the implementation here:
http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel

And here's the actual commit that tries to add aes support:
http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=50dca9ce0f051c863f00cc949db2c19bf247887b

In Section "3.1.4.3 Session-Key Computation" the hmac-sha256 base computation of the session-key seems to use the plain SharedSecret and not the NT-HASH of it (MD4(UNICODE(ShareSecret))), is that correct?
I thought the plain text is never stored in AD by default...
Where should the netlogon server get the plain text from?
I just tried the NT-HASH see my netlogon_creds_init_hmac_sha256() function.

In Section "3.1.4.4 Netlogon Credential Computation" there's a AesEncrypt function used. Can you please document the exact algorithm that's used there. You say AES128 is used in CFB mode without initialization vector.

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
says that all modes except ECB require an IV.

It would also be nice if you could add some more example values in secion 4.2 Cryptographic Values for Session Key Validation.

metze




_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Metze,

 

    The SharedSecret used for AES session key computation, as described in 3.1.4.3 MS-NRPC , should be the NTOWF (MD4(UNICODE(Passwd))) of the plaintext password.   The section 3.1.1 of MS-NRPC explains what a SharedSecret is used for session key calculation in Windows implementations.  The SharedSecret  is stored in UnicodePwd AD attribute.  Please see section 3.1.1 and Windows Behavior notes <66>,<67> of MS-NRPC for details. 

 

     I will continue working on all questions related to AES encryption.

 

Thanks!

 

--------------------------------------------------------------------

Hongwei  Sun - Sr. Support Escalation Engineer

DSC Protocol  Team, Microsoft

hongweis@...

Tel:  [phone] x 57027

---------------------------------------------------------------------

 

 

 

-----Original Message-----

From: Stefan (metze) Metzmacher [mailto:metze@...]

Sent: Tuesday, August 25, 2009 11:13 AM

To: Interoperability Documentation Help

Cc: pfif@...; cifs-protocol@...

Subject: MS-NRPC: AES Schannel problems

 

Hi,

 

I'm currently trying to implement the AES based Netlogon Secure Channel in Samba.

 

But the documentation is not really clear about the used algorithms.

 

I have started with the implementation here:

http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel

 

And here's the actual commit that tries to add aes support:

http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=50dca9ce0f051c863f00cc949db2c19bf247887b

 

In Section "3.1.4.3 Session-Key Computation" the hmac-sha256 base computation of the session-key seems to use the plain SharedSecret and not the NT-HASH of it (MD4(UNICODE(ShareSecret))), is that correct?

I thought the plain text is never stored in AD by default...

Where should the netlogon server get the plain text from?

I just tried the NT-HASH see my netlogon_creds_init_hmac_sha256() function.

 

In Section "3.1.4.4 Netlogon Credential Computation" there's a AesEncrypt function used. Can you please document the exact algorithm that's used there. You say AES128 is used in CFB mode without initialization vector.

 

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

says that all modes except ECB require an IV.

 

It would also be nice if you could add some more example values in secion 4.2 Cryptographic Values for Session Key Validation.

 

metze

 

 

 

 

 

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Stefan (metze) Metzmacher]

Hongwei,

>     The SharedSecret used for AES session key computation, as described in 3.1.4.3 MS-NRPC , should be the NTOWF (MD4(UNICODE(Passwd))) of the plaintext password.   The section 3.1.1 of MS-NRPC explains what a SharedSecret is used for session key calculation in Windows implementations.  The SharedSecret  is stored in UnicodePwd AD attribute.  Please see section 3.1.1 and Windows Behavior notes <66>,<67> of MS-NRPC for details.

Yes, I saw that and that's why I've also done it like this,
but I was wondering why Section 3.4.1 has
M4SS := MD4(UNICODE(SharedSecret)) explicit for the hmac_md5 session key
and the des session key.

I think it would make sense to also add it to the hmac_sha256 section
in order to remove the confusion I had.

>
>      I will continue working on all questions related to AES encryption.

Thanks, as it seems I compute the session key correct, this is the place
(netlogon_creds_step_crypt()) where I have a bug, because I'm getting
access denied when I try DCERPC_SCHANNEL_AES against a w2k8r2rc server.

metze

>
> -----Original Message-----
>
> From: Stefan (metze) Metzmacher [mailto:metze@...]
>
> Sent: Tuesday, August 25, 2009 11:13 AM
>
> To: Interoperability Documentation Help
>
> Cc: pfif@...; cifs-protocol@...
>
> Subject: MS-NRPC: AES Schannel problems
>
>
>
> Hi,
>
>
>
> I'm currently trying to implement the AES based Netlogon Secure Channel in Samba.
>
>
>
> But the documentation is not really clear about the used algorithms.
>
>
>
> I have started with the implementation here:
>
> http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel
>
>
>
> And here's the actual commit that tries to add aes support:
>
> http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=50dca9ce0f051c863f00cc949db2c19bf247887b
>
>
>
> In Section "3.1.4.3 Session-Key Computation" the hmac-sha256 base computation of the session-key seems to use the plain SharedSecret and not the NT-HASH of it (MD4(UNICODE(ShareSecret))), is that correct?
>
> I thought the plain text is never stored in AD by default...
>
> Where should the netlogon server get the plain text from?
>
> I just tried the NT-HASH see my netlogon_creds_init_hmac_sha256() function.
>
>
>
> In Section "3.1.4.4 Netlogon Credential Computation" there's a AesEncrypt function used. Can you please document the exact algorithm that's used there. You say AES128 is used in CFB mode without initialization vector.
>
>
>
> http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
>
> says that all modes except ECB require an IV.
>
>
>
> It would also be nice if you could add some more example values in secion 4.2 Cryptographic Values for Session Key Validation.
>
>
>
> metze
>
>
>
>
>
>
>
>
>
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Stefan (metze) Metzmacher]

Stefan (metze) Metzmacher schrieb:

> Hongwei,
>
>>     The SharedSecret used for AES session key computation, as described in 3.1.4.3 MS-NRPC , should be the NTOWF (MD4(UNICODE(Passwd))) of the plaintext password.   The section 3.1.1 of MS-NRPC explains what a SharedSecret is used for session key calculation in Windows implementations.  The SharedSecret  is stored in UnicodePwd AD attribute.  Please see section 3.1.1 and Windows Behavior notes <66>,<67> of MS-NRPC for details.
>
> Yes, I saw that and that's why I've also done it like this,
> but I was wondering why Section 3.4.1 has
> M4SS := MD4(UNICODE(SharedSecret)) explicit for the hmac_md5 session key
> and the des session key.
>
> I think it would make sense to also add it to the hmac_sha256 section
> in order to remove the confusion I had.
>
>>      I will continue working on all questions related to AES encryption.
>
> Thanks, as it seems I compute the session key correct, this is the place
> (netlogon_creds_step_crypt()) where I have a bug, because I'm getting
> access denied when I try DCERPC_SCHANNEL_AES against a w2k8r2rc server.
>

Please also provide details about the aes encryption used when schannel
acts as security provider for dcerpc.

I noticed that the documentation on has only the
NETLOGON_NEG_SUPPORTS_AES_SHA2 (0x00400000)
flag, but w2k8r2 used the new flag NETLOGON_NEG_SUPPORTS_AES(0x01000000).

I assume the docs may missing also some crypto details, because of this...

metze



_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Metze,

   A quick clarification for the AES bit in Negotiate Flag, as shown in 3.1.4.2.  The information in the document regarding this bit is wrong.  Bit W NETLOGON_NEG_SUPPORTS_AES_SHA2 (0x00400000) is not supported in Windows 7/Windows Server 2008 R2.   The right bit to negotiate AES support should be NETLOGON_NEG_SUPPORTS_AES(0x01000000), as you already indicated.   If  you use bit 0x00400000 to negotiate the AES support, it might be the source of your problem.

  I will file a request to fix this problem in the document.  Meanwhile, I will work on the AES encryption details for Schannel.

Thanks!

Hongwei



-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze@...]
Sent: Friday, August 28, 2009 12:00 PM
To: Hongwei Sun
Cc: pfif@...; cifs-protocol@...
Subject: Re: [Pfif] MS-NRPC: AES Schannel problems

Stefan (metze) Metzmacher schrieb:

> Hongwei,
>
>>     The SharedSecret used for AES session key computation, as described in 3.1.4.3 MS-NRPC , should be the NTOWF (MD4(UNICODE(Passwd))) of the plaintext password.   The section 3.1.1 of MS-NRPC explains what a SharedSecret is used for session key calculation in Windows implementations.  The SharedSecret  is stored in UnicodePwd AD attribute.  Please see section 3.1.1 and Windows Behavior notes <66>,<67> of MS-NRPC for details.
>
> Yes, I saw that and that's why I've also done it like this, but I was
> wondering why Section 3.4.1 has M4SS := MD4(UNICODE(SharedSecret))
> explicit for the hmac_md5 session key and the des session key.
>
> I think it would make sense to also add it to the hmac_sha256 section
> in order to remove the confusion I had.
>
>>      I will continue working on all questions related to AES encryption.
>
> Thanks, as it seems I compute the session key correct, this is the
> place
> (netlogon_creds_step_crypt()) where I have a bug, because I'm getting
> access denied when I try DCERPC_SCHANNEL_AES against a w2k8r2rc server.
>

Please also provide details about the aes encryption used when schannel acts as security provider for dcerpc.

I noticed that the documentation on has only the
NETLOGON_NEG_SUPPORTS_AES_SHA2 (0x00400000) flag, but w2k8r2 used the new flag NETLOGON_NEG_SUPPORTS_AES(0x01000000).

I assume the docs may missing also some crypto details, because of this...

metze

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Stefan (metze) Metzmacher]

Hongwei,

>    A quick clarification for the AES bit in Negotiate Flag, as shown in 3.1.4.2.  The information in the document regarding this bit is wrong.  Bit W NETLOGON_NEG_SUPPORTS_AES_SHA2 (0x00400000) is not supported in Windows 7/Windows Server 2008 R2.   The right bit to negotiate AES support should be NETLOGON_NEG_SUPPORTS_AES(0x01000000), as you already indicated.   If  you use bit 0x00400000 to negotiate the AES support, it might be the source of your problem.

I was already only using the correct bit.

>   I will file a request to fix this problem in the document.  Meanwhile, I will work on the AES encryption details for Schannel.

Thanks!

metze

> -----Original Message-----
> From: Stefan (metze) Metzmacher [mailto:metze@...]
> Sent: Friday, August 28, 2009 12:00 PM
> To: Hongwei Sun
> Cc: pfif@...; cifs-protocol@...
> Subject: Re: [Pfif] MS-NRPC: AES Schannel problems
>
> Stefan (metze) Metzmacher schrieb:
>> Hongwei,
>>
>>>     The SharedSecret used for AES session key computation, as described in 3.1.4.3 MS-NRPC , should be the NTOWF (MD4(UNICODE(Passwd))) of the plaintext password.   The section 3.1.1 of MS-NRPC explains what a SharedSecret is used for session key calculation in Windows implementations.  The SharedSecret  is stored in UnicodePwd AD attribute.  Please see section 3.1.1 and Windows Behavior notes <66>,<67> of MS-NRPC for details.
>> Yes, I saw that and that's why I've also done it like this, but I was
>> wondering why Section 3.4.1 has M4SS := MD4(UNICODE(SharedSecret))
>> explicit for the hmac_md5 session key and the des session key.
>>
>> I think it would make sense to also add it to the hmac_sha256 section
>> in order to remove the confusion I had.
>>
>>>      I will continue working on all questions related to AES encryption.
>> Thanks, as it seems I compute the session key correct, this is the
>> place
>> (netlogon_creds_step_crypt()) where I have a bug, because I'm getting
>> access denied when I try DCERPC_SCHANNEL_AES against a w2k8r2rc server.
>>
>
> Please also provide details about the aes encryption used when schannel acts as security provider for dcerpc.
>
> I noticed that the documentation on has only the
> NETLOGON_NEG_SUPPORTS_AES_SHA2 (0x00400000) flag, but w2k8r2 used the new flag NETLOGON_NEG_SUPPORTS_AES(0x01000000).
>
> I assume the docs may missing also some crypto details, because of this...
>
> metze
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Metze,

  We confirmed that AesCrypt follows the normative reference of [FIPS197] (http://www.csrc.nist.gov/publications/fips/fips197/fips-197.pdf).   As far as the statement about AES128 encryption CFB mode,  we also confirmed that we do use 0 as Initialize Vector(IV), so in this case all you have to do is set the IV to the 128-bit quantity consisting of all zeros.   The reference we are using for CFB mode is [SP800-38A] ( http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf ) which states that CFB mode requires a valid and unpredictable IV (Section 6.3). Zero is a valid IV, certainly not unpredictable. However, the unpredictability is required only to guard against specific types of attacks, which become possible when a single key is used to encrypt a large number of related plaintexts. Predictable IVs could be used in applications where this is not a concern.  

  We will update the document with the correct references to the related statements in the MS-NRPC document.

Thanks!

Hongwei

-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze@...]
Sent: Wednesday, August 26, 2009 12:15 AM
To: Hongwei Sun
Cc: pfif@...; cifs-protocol@...
Subject: Re: MS-NRPC: AES Schannel problems

Hongwei,

>     The SharedSecret used for AES session key computation, as described in 3.1.4.3 MS-NRPC , should be the NTOWF (MD4(UNICODE(Passwd))) of the plaintext password.   The section 3.1.1 of MS-NRPC explains what a SharedSecret is used for session key calculation in Windows implementations.  The SharedSecret  is stored in UnicodePwd AD attribute.  Please see section 3.1.1 and Windows Behavior notes <66>,<67> of MS-NRPC for details.

Yes, I saw that and that's why I've also done it like this, but I was wondering why Section 3.4.1 has M4SS := MD4(UNICODE(SharedSecret)) explicit for the hmac_md5 session key and the des session key.

I think it would make sense to also add it to the hmac_sha256 section in order to remove the confusion I had.

>
>      I will continue working on all questions related to AES encryption.

Thanks, as it seems I compute the session key correct, this is the place
(netlogon_creds_step_crypt()) where I have a bug, because I'm getting access denied when I try DCERPC_SCHANNEL_AES against a w2k8r2rc server.

metze

>
> -----Original Message-----
>
> From: Stefan (metze) Metzmacher [mailto:metze@...]
>
> Sent: Tuesday, August 25, 2009 11:13 AM
>
> To: Interoperability Documentation Help
>
> Cc: pfif@...; cifs-protocol@...
>
> Subject: MS-NRPC: AES Schannel problems
>
>
>
> Hi,
>
>
>
> I'm currently trying to implement the AES based Netlogon Secure Channel in Samba.
>
>
>
> But the documentation is not really clear about the used algorithms.
>
>
>
> I have started with the implementation here:
>
> http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads
> /master4-schannel
>
>
>
> And here's the actual commit that tries to add aes support:
>
> http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=50dca9ce
> 0f051c863f00cc949db2c19bf247887b
>
>
>
> In Section "3.1.4.3 Session-Key Computation" the hmac-sha256 base computation of the session-key seems to use the plain SharedSecret and not the NT-HASH of it (MD4(UNICODE(ShareSecret))), is that correct?
>
> I thought the plain text is never stored in AD by default...
>
> Where should the netlogon server get the plain text from?
>
> I just tried the NT-HASH see my netlogon_creds_init_hmac_sha256() function.
>
>
>
> In Section "3.1.4.4 Netlogon Credential Computation" there's a AesEncrypt function used. Can you please document the exact algorithm that's used there. You say AES128 is used in CFB mode without initialization vector.
>
>
>
> http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
>
> says that all modes except ECB require an IV.
>
>
>
> It would also be nice if you could add some more example values in secion 4.2 Cryptographic Values for Session Key Validation.
>
>
>
> metze
>
>
>
>
>
>
>
>
>
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Stefan (metze) Metzmacher]

Hongwei,

>   We confirmed that AesCrypt follows the normative reference of [FIPS197] (http://www.csrc.nist.gov/publications/fips/fips197/fips-197.pdf).   As far as the statement about AES128 encryption CFB mode,  we also confirmed that we do use 0 as Initialize Vector(IV), so in this case all you have to do is set the IV to the 128-bit quantity consisting of all zeros.   The reference we are using for CFB mode is [SP800-38A] ( http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf ) which states that CFB mode requires a valid and unpredictable IV (Section 6.3). Zero is a valid IV, certainly not unpredictable. However, the unpredictability is required only to guard against specific types of attacks, which become possible when a single key is used to encrypt a large number of related plaintexts. Predictable IVs could be used in applications where this is not a concern.  

thanks I'll try that.

AES128 is also used in section 3.3.4.2.1 "Generating an Initial Netlogon
Signature Token" under 8., is that the same AesCrypt function (also
using CFB mode) with a just IV being contructed by using the sequence
number twice?

>   We will update the document with the correct references to the related statements in the MS-NRPC document.

It would be really nice if you could also add some more example values
in secion 4.2 Cryptographic Values for Session Key Validation.

metze

> Thanks!
>
> Hongwei
>
> -----Original Message-----
> From: Stefan (metze) Metzmacher [mailto:metze@...]
> Sent: Wednesday, August 26, 2009 12:15 AM
> To: Hongwei Sun
> Cc: pfif@...; cifs-protocol@...
> Subject: Re: MS-NRPC: AES Schannel problems
>
> Hongwei,
>
>>     The SharedSecret used for AES session key computation, as described in 3.1.4.3 MS-NRPC , should be the NTOWF (MD4(UNICODE(Passwd))) of the plaintext password.   The section 3.1.1 of MS-NRPC explains what a SharedSecret is used for session key calculation in Windows implementations.  The SharedSecret  is stored in UnicodePwd AD attribute.  Please see section 3.1.1 and Windows Behavior notes <66>,<67> of MS-NRPC for details.
>
> Yes, I saw that and that's why I've also done it like this, but I was wondering why Section 3.4.1 has M4SS := MD4(UNICODE(SharedSecret)) explicit for the hmac_md5 session key and the des session key.
>
> I think it would make sense to also add it to the hmac_sha256 section in order to remove the confusion I had.
>
>>      I will continue working on all questions related to AES encryption.
>
> Thanks, as it seems I compute the session key correct, this is the place
> (netlogon_creds_step_crypt()) where I have a bug, because I'm getting access denied when I try DCERPC_SCHANNEL_AES against a w2k8r2rc server.
>
> metze
>> -----Original Message-----
>>
>> From: Stefan (metze) Metzmacher [mailto:metze@...]
>>
>> Sent: Tuesday, August 25, 2009 11:13 AM
>>
>> To: Interoperability Documentation Help
>>
>> Cc: pfif@...; cifs-protocol@...
>>
>> Subject: MS-NRPC: AES Schannel problems
>>
>>
>>
>> Hi,
>>
>>
>>
>> I'm currently trying to implement the AES based Netlogon Secure Channel in Samba.
>>
>>
>>
>> But the documentation is not really clear about the used algorithms.
>>
>>
>>
>> I have started with the implementation here:
>>
>> http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads
>> /master4-schannel
>>
>>
>>
>> And here's the actual commit that tries to add aes support:
>>
>> http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=50dca9ce
>> 0f051c863f00cc949db2c19bf247887b
>>
>>
>>
>> In Section "3.1.4.3 Session-Key Computation" the hmac-sha256 base computation of the session-key seems to use the plain SharedSecret and not the NT-HASH of it (MD4(UNICODE(ShareSecret))), is that correct?
>>
>> I thought the plain text is never stored in AD by default...
>>
>> Where should the netlogon server get the plain text from?
>>
>> I just tried the NT-HASH see my netlogon_creds_init_hmac_sha256() function.
>>
>>
>>
>> In Section "3.1.4.4 Netlogon Credential Computation" there's a AesEncrypt function used. Can you please document the exact algorithm that's used there. You say AES128 is used in CFB mode without initialization vector.
>>
>>
>>
>> http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
>>
>> says that all modes except ECB require an IV.
>>
>>
>>
>> It would also be nice if you could add some more example values in secion 4.2 Cryptographic Values for Session Key Validation.
>>
>>
>>
>> metze
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Metze,

   Yes,  AesCrypt function referenced in 3.3.4.2.1 is also the same function as in 3.1.4.4 that is using CFB mode.   You just need to concatenate twice the same SequenceNumber, which is 8 byte number, to make a 16 byte IV.  

   I submitted a request for more example values in Section 4.2 Cryptographic Values for Session Key Validation in MS-NRPC.  I will let you know.

Thanks!

Hongwei

-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze@...]
Sent: Friday, September 11, 2009 3:34 AM
To: Hongwei Sun
Cc: pfif@...; cifs-protocol@...
Subject: Re: MS-NRPC: AES Schannel problems

Hongwei,

>   We confirmed that AesCrypt follows the normative reference of [FIPS197] (http://www.csrc.nist.gov/publications/fips/fips197/fips-197.pdf).   As far as the statement about AES128 encryption CFB mode,  we also confirmed that we do use 0 as Initialize Vector(IV), so in this case all you have to do is set the IV to the 128-bit quantity consisting of all zeros.   The reference we are using for CFB mode is [SP800-38A] ( http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf ) which states that CFB mode requires a valid and unpredictable IV (Section 6.3). Zero is a valid IV, certainly not unpredictable. However, the unpredictability is required only to guard against specific types of attacks, which become possible when a single key is used to encrypt a large number of related plaintexts. Predictable IVs could be used in applications where this is not a concern.  

thanks I'll try that.

AES128 is also used in section 3.3.4.2.1 "Generating an Initial Netlogon Signature Token" under 8., is that the same AesCrypt function (also using CFB mode) with a just IV being contructed by using the sequence number twice?

>   We will update the document with the correct references to the related statements in the MS-NRPC document.

It would be really nice if you could also add some more example values in secion 4.2 Cryptographic Values for Session Key Validation.

metze

> Thanks!
>
> Hongwei
>
> -----Original Message-----
> From: Stefan (metze) Metzmacher [mailto:metze@...]
> Sent: Wednesday, August 26, 2009 12:15 AM
> To: Hongwei Sun
> Cc: pfif@...; cifs-protocol@...
> Subject: Re: MS-NRPC: AES Schannel problems
>
> Hongwei,
>
>>     The SharedSecret used for AES session key computation, as described in 3.1.4.3 MS-NRPC , should be the NTOWF (MD4(UNICODE(Passwd))) of the plaintext password.   The section 3.1.1 of MS-NRPC explains what a SharedSecret is used for session key calculation in Windows implementations.  The SharedSecret  is stored in UnicodePwd AD attribute.  Please see section 3.1.1 and Windows Behavior notes <66>,<67> of MS-NRPC for details.
>
> Yes, I saw that and that's why I've also done it like this, but I was wondering why Section 3.4.1 has M4SS := MD4(UNICODE(SharedSecret)) explicit for the hmac_md5 session key and the des session key.
>
> I think it would make sense to also add it to the hmac_sha256 section in order to remove the confusion I had.
>
>>      I will continue working on all questions related to AES encryption.
>
> Thanks, as it seems I compute the session key correct, this is the
> place
> (netlogon_creds_step_crypt()) where I have a bug, because I'm getting access denied when I try DCERPC_SCHANNEL_AES against a w2k8r2rc server.
>
> metze
>> -----Original Message-----
>>
>> From: Stefan (metze) Metzmacher [mailto:metze@...]
>>
>> Sent: Tuesday, August 25, 2009 11:13 AM
>>
>> To: Interoperability Documentation Help
>>
>> Cc: pfif@...; cifs-protocol@...
>>
>> Subject: MS-NRPC: AES Schannel problems
>>
>>
>>
>> Hi,
>>
>>
>>
>> I'm currently trying to implement the AES based Netlogon Secure Channel in Samba.
>>
>>
>>
>> But the documentation is not really clear about the used algorithms.
>>
>>
>>
>> I have started with the implementation here:
>>
>> http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/head
>> s
>> /master4-schannel
>>
>>
>>
>> And here's the actual commit that tries to add aes support:
>>
>> http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=50dca9c
>> e
>> 0f051c863f00cc949db2c19bf247887b
>>
>>
>>
>> In Section "3.1.4.3 Session-Key Computation" the hmac-sha256 base computation of the session-key seems to use the plain SharedSecret and not the NT-HASH of it (MD4(UNICODE(ShareSecret))), is that correct?
>>
>> I thought the plain text is never stored in AD by default...
>>
>> Where should the netlogon server get the plain text from?
>>
>> I just tried the NT-HASH see my netlogon_creds_init_hmac_sha256() function.
>>
>>
>>
>> In Section "3.1.4.4 Netlogon Credential Computation" there's a AesEncrypt function used. Can you please document the exact algorithm that's used there. You say AES128 is used in CFB mode without initialization vector.
>>
>>
>>
>> http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
>>
>> says that all modes except ECB require an IV.
>>
>>
>>
>> It would also be nice if you could add some more example values in secion 4.2 Cryptographic Values for Session Key Validation.
>>
>>
>>
>> metze
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Stefan (metze) Metzmacher]

Hi,

>>   We confirmed that AesCrypt follows the normative reference of [FIPS197] (http://www.csrc.nist.gov/publications/fips/fips197/fips-197.pdf).   As far as the statement about AES128 encryption CFB mode,  we also confirmed that we do use 0 as Initialize Vector(IV), so in this case all you have to do is set the IV to the 128-bit quantity consisting of all zeros.   The reference we are using for CFB mode is [SP800-38A] ( http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf ) which states that CFB mode requires a valid and unpredictable IV (Section 6.3). Zero is a valid IV, certainly not unpredictable. However, the unpredictability is required only to guard against specific types of attacks, which become possible when a single key is used to encrypt a large number of related plaintexts. Predictable IVs could be used in applications where this is not a concern.  
>
> thanks I'll try that.
>
> AES128 is also used in section 3.3.4.2.1 "Generating an Initial Netlogon
> Signature Token" under 8., is that the same AesCrypt function (also
> using CFB mode) with a just IV being contructed by using the sequence
> number twice?

I've tried to get that working, but it doesn't work:-(

I've setup a trust between two w2k8r2 domains and captured the
ServerReqChallenge and ServerAuthenticate3. And they're using Netlogon
Schannel with AES. (They also use NDR64, wireshark doesn't handle this
yet...)

There're 5 ServerAuthenticate3 exchanges in the capture
and I put the data into a simple standalone crypto challenge
program.

So all we need is to find the algorithm to recalculate the examples,
changing the mxnrpc.c file.

metze

>>   We will update the document with the correct references to the related statements in the MS-NRPC document.
>
> It would be really nice if you could also add some more example values
> in secion 4.2 Cryptographic Values for Session Key Validation.



_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Stefan (metze) Metzmacher]

now with attachment...

>>>   We confirmed that AesCrypt follows the normative reference of [FIPS197] (http://www.csrc.nist.gov/publications/fips/fips197/fips-197.pdf).   As far as the statement about AES128 encryption CFB mode,  we also confirmed that we do use 0 as Initialize Vector(IV), so in this case all you have to do is set the IV to the 128-bit quantity consisting of all zeros.   The reference we are using for CFB mode is [SP800-38A] ( http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf ) which states that CFB mode requires a valid and unpredictable IV (Section 6.3). Zero is a valid IV, certainly not unpredictable. However, the unpredictability is required only to guard against specific types of attacks, which become possible when a single key is used to encrypt a large number of related plaintexts. Predictable IVs could be used in applications where this is not a concern.  
>> thanks I'll try that.
>>
>> AES128 is also used in section 3.3.4.2.1 "Generating an Initial Netlogon
>> Signature Token" under 8., is that the same AesCrypt function (also
>> using CFB mode) with a just IV being contructed by using the sequence
>> number twice?
>
> I've tried to get that working, but it doesn't work:-(
>
> I've setup a trust between two w2k8r2 domains and captured the
> ServerReqChallenge and ServerAuthenticate3. And they're using Netlogon
> Schannel with AES. (They also use NDR64, wireshark doesn't handle this
> yet...)
>
> There're 5 ServerAuthenticate3 exchanges in the capture
> and I put the data into a simple standalone crypto challenge
> program.
>
> So all we need is to find the algorithm to recalculate the examples,
> changing the mxnrpc.c file.
>
> metze
>
>>>   We will update the document with the correct references to the related statements in the MS-NRPC document.
>> It would be really nice if you could also add some more example values
>> in secion 4.2 Cryptographic Values for Session Key Validation.
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Metze,

   I think that Nick already informed you that AES 128 with 8 bit CFB mode has to be used.  I filed a request to add the information into 3.1.4.4 of MS-NRPC.  I also noticed that in  mxnrpc.c you attached , you used AES_cfb128_encrypt() (128 bit CFB mode) for computing server credential.  Please let us know if you have resolved the issue and if we can provide further help.

   Meanwhile, I provide some sample values that I captured from debugger for you to verify your logic.

        OWF Password :

            13 c0 b0 4b 66 25 0d 08-b8 a3 90 4d cc 8b 34 e3

        Client Challenge:

           25 63 e3 5f 69 e1 5a 24

        Server Challenge:

           9C 66 5F 90 D9 83 DF 43

        Session Key calculated:
 
            c9 c7 f7 2f c6 b9 13 e3-67 ae a9 1d 0a e3 a7 70

        Client Credential:

           58 6a df 53 ef 72 78 d9

        Server Credential

           E1 41 62 09 B2 3E 57 51

Thanks!

Hongwei

     

-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze@...]
Sent: Monday, September 14, 2009 7:31 PM
To: Hongwei Sun
Cc: pfif@...; cifs-protocol@...; Nick Meier
Subject: Re: [Pfif] MS-NRPC: AES Schannel problems

now with attachment...

>>>   We confirmed that AesCrypt follows the normative reference of [FIPS197] (http://www.csrc.nist.gov/publications/fips/fips197/fips-197.pdf).   As far as the statement about AES128 encryption CFB mode,  we also confirmed that we do use 0 as Initialize Vector(IV), so in this case all you have to do is set the IV to the 128-bit quantity consisting of all zeros.   The reference we are using for CFB mode is [SP800-38A] ( http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf ) which states that CFB mode requires a valid and unpredictable IV (Section 6.3). Zero is a valid IV, certainly not unpredictable. However, the unpredictability is required only to guard against specific types of attacks, which become possible when a single key is used to encrypt a large number of related plaintexts. Predictable IVs could be used in applications where this is not a concern.  
>> thanks I'll try that.
>>
>> AES128 is also used in section 3.3.4.2.1 "Generating an Initial
>> Netlogon Signature Token" under 8., is that the same AesCrypt
>> function (also using CFB mode) with a just IV being contructed by
>> using the sequence number twice?
>
> I've tried to get that working, but it doesn't work:-(
>
> I've setup a trust between two w2k8r2 domains and captured the
> ServerReqChallenge and ServerAuthenticate3. And they're using Netlogon
> Schannel with AES. (They also use NDR64, wireshark doesn't handle this
> yet...)
>
> There're 5 ServerAuthenticate3 exchanges in the capture and I put the
> data into a simple standalone crypto challenge program.
>
> So all we need is to find the algorithm to recalculate the examples,
> changing the mxnrpc.c file.
>
> metze
>
>>>   We will update the document with the correct references to the related statements in the MS-NRPC document.
>> It would be really nice if you could also add some more example
>> values in secion 4.2 Cryptographic Values for Session Key Validation.
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Stefan (metze) Metzmacher]

Hi Hongwei,

>    I think that Nick already informed you that AES 128 with 8 bit CFB mode has to be used.  I filed a request to add the information into 3.1.4.4 of MS-NRPC.  I also noticed that in  mxnrpc.c you attached , you used AES_cfb128_encrypt() (128 bit CFB mode) for computing server credential.  Please let us know if you have resolved the issue and if we can provide further help.

Yes, he does and we got that part working. Thanks!
using AES_cfb8_encrypt() instead of AES_cfb128_encrypt().

However we have the next challenge, the Netlogon SSPI provider.

I used tried both AES_cfb8_encrypt() and AES_cfb128_encrypt() but both
don't work.

Looking at the frame 308 and the following in
w2k8r2rc-l4-w2k8r2-trust-aes-schannel-01.pcap.

I think there's a bug in w2k8r2 in the docs.

The NL_AUTH_SHA2_SIGNATURE is filled in with very strange values.

It seem that the checksum is still 8 byte and the confounder directly
follows. The last 24 bytes are just uninitalized memory.

They are:
Frame 308:

32 00 2e 00 33 00 31 00
2e 00 39 00 2e 00 32 00
31 00 34 00 00 00 00 00

Frame 310:

35 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 02 00 00 00 00 00

Frame 311: (I think it's random because the pdu is so long and point
memory in other aeas)

51 03 21 9b 41 84 cc 90
e7 e8 70 1c 52 60 55 5a
64 0c 6a 17 be 07 de 80

Looks like a unicode string instead of parts of a checksum and a confounder.

metze

> Meanwhile, I provide some sample values that I captured from debugger
for you to verify your logic.

>
> OWF Password :
>
>    13 c0 b0 4b 66 25 0d 08-b8 a3 90 4d cc 8b 34 e3
>
> Client Challenge:
>
>   25 63 e3 5f 69 e1 5a 24
>
> Server Challenge:
>
>   9C 66 5F 90 D9 83 DF 43
>
> Session Key calculated:
>  
>    c9 c7 f7 2f c6 b9 13 e3-67 ae a9 1d 0a e3 a7 70
>
> Client Credential:
>
>   58 6a df 53 ef 72 78 d9
>
> Server Credential
>
>   E1 41 62 09 B2 3E 57 51
>

It would be great if you could add this values to the docs.

metze



_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Stefan (metze) Metzmacher]

Hongwei Sun schrieb:
> Could you send the attachment of w2k8r2rc-l4-w2k8r2-trust-aes-schannel-01.pcap ?

It was already in the tar.gz of one of the last mails, but
here it is again:-)

metze

> -----Original Message-----
> From: Stefan (metze) Metzmacher [mailto:metze@...]
> Sent: Wednesday, September 16, 2009 1:46 PM
> To: Hongwei Sun
> Cc: pfif@...; cifs-protocol@...; Nick Meier; Guenther Deschner
> Subject: Re: [Pfif] MS-NRPC: AES Schannel problems
>
> Hi Hongwei,
>
>>    I think that Nick already informed you that AES 128 with 8 bit CFB mode has to be used.  I filed a request to add the information into 3.1.4.4 of MS-NRPC.  I also noticed that in  mxnrpc.c you attached , you used AES_cfb128_encrypt() (128 bit CFB mode) for computing server credential.  Please let us know if you have resolved the issue and if we can provide further help.
>
> Yes, he does and we got that part working. Thanks!
> using AES_cfb8_encrypt() instead of AES_cfb128_encrypt().
>
> However we have the next challenge, the Netlogon SSPI provider.
>
> I used tried both AES_cfb8_encrypt() and AES_cfb128_encrypt() but both don't work.
>
> Looking at the frame 308 and the following in w2k8r2rc-l4-w2k8r2-trust-aes-schannel-01.pcap.
>
> I think there's a bug in w2k8r2 in the docs.
>
> The NL_AUTH_SHA2_SIGNATURE is filled in with very strange values.
>
> It seem that the checksum is still 8 byte and the confounder directly follows. The last 24 bytes are just uninitalized memory.
>
> They are:
> Frame 308:
>
> 32 00 2e 00 33 00 31 00
> 2e 00 39 00 2e 00 32 00
> 31 00 34 00 00 00 00 00
>
> Frame 310:
>
> 35 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 02 00 00 00 00 00
>
> Frame 311: (I think it's random because the pdu is so long and point memory in other aeas)
>
> 51 03 21 9b 41 84 cc 90
> e7 e8 70 1c 52 60 55 5a
> 64 0c 6a 17 be 07 de 80
>
> Looks like a unicode string instead of parts of a checksum and a confounder.
>
> metze
>
>> Meanwhile, I provide some sample values that I captured from debugger
> for you to verify your logic.
>> OWF Password :
>>
>>    13 c0 b0 4b 66 25 0d 08-b8 a3 90 4d cc 8b 34 e3
>>
>> Client Challenge:
>>
>>   25 63 e3 5f 69 e1 5a 24
>>
>> Server Challenge:
>>
>>   9C 66 5F 90 D9 83 DF 43
>>
>> Session Key calculated:
>>  
>>    c9 c7 f7 2f c6 b9 13 e3-67 ae a9 1d 0a e3 a7 70
>>
>> Client Credential:
>>
>>   58 6a df 53 ef 72 78 d9
>>
>> Server Credential
>>
>>   E1 41 62 09 B2 3E 57 51
>>
>
> It would be great if you could add this values to the docs.
>
> metze
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Stefan (metze) Metzmacher]

Hi Hongwei,

Nick just told me that Windows seems to have a bug there and I tried to
"reproduce" this
bug in our code, but I still can't get windows to accept signed or
sealed traffic from us.

See the attached capture:

Frames 178 and 179 are with signing
Frames 330 and 331 are with sealing

You can take a look at my code here (see the top 5 commits)
http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel

metze

> -----Original Message-----
> From: Stefan (metze) Metzmacher [mailto:metze@...]
> Sent: Wednesday, September 16, 2009 1:46 PM
> To: Hongwei Sun
> Cc: pfif@...; cifs-protocol@...; Nick Meier; Guenther Deschner
> Subject: Re: [Pfif] MS-NRPC: AES Schannel problems
>
> Hi Hongwei,
>
>>    I think that Nick already informed you that AES 128 with 8 bit CFB mode has to be used.  I filed a request to add the information into 3.1.4.4 of MS-NRPC.  I also noticed that in  mxnrpc.c you attached , you used AES_cfb128_encrypt() (128 bit CFB mode) for computing server credential.  Please let us know if you have resolved the issue and if we can provide further help.
>
> Yes, he does and we got that part working. Thanks!
> using AES_cfb8_encrypt() instead of AES_cfb128_encrypt().
>
> However we have the next challenge, the Netlogon SSPI provider.
>
> I used tried both AES_cfb8_encrypt() and AES_cfb128_encrypt() but both don't work.
>
> Looking at the frame 308 and the following in w2k8r2rc-l4-w2k8r2-trust-aes-schannel-01.pcap.
>
> I think there's a bug in w2k8r2 in the docs.
>
> The NL_AUTH_SHA2_SIGNATURE is filled in with very strange values.
>
> It seem that the checksum is still 8 byte and the confounder directly follows. The last 24 bytes are just uninitalized memory.
>
> They are:
> Frame 308:
>
> 32 00 2e 00 33 00 31 00
> 2e 00 39 00 2e 00 32 00
> 31 00 34 00 00 00 00 00
>
> Frame 310:
>
> 35 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 02 00 00 00 00 00
>
> Frame 311: (I think it's random because the pdu is so long and point memory in other aeas)
>
> 51 03 21 9b 41 84 cc 90
> e7 e8 70 1c 52 60 55 5a
> 64 0c 6a 17 be 07 de 80
>
> Looks like a unicode string instead of parts of a checksum and a confounder.
>
> metze
>
>> Meanwhile, I provide some sample values that I captured from debugger
> for you to verify your logic.
>> OWF Password :
>>
>>    13 c0 b0 4b 66 25 0d 08-b8 a3 90 4d cc 8b 34 e3
>>
>> Client Challenge:
>>
>>   25 63 e3 5f 69 e1 5a 24
>>
>> Server Challenge:
>>
>>   9C 66 5F 90 D9 83 DF 43
>>
>> Session Key calculated:
>>  
>>    c9 c7 f7 2f c6 b9 13 e3-67 ae a9 1d 0a e3 a7 70
>>
>> Client Credential:
>>
>>   58 6a df 53 ef 72 78 d9
>>
>> Server Credential
>>
>>   E1 41 62 09 B2 3E 57 51
>>
>
> It would be great if you could add this values to the docs.
>
> metze
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Metze,

   Yes,  your initial observation is right.   Checksum is only 8 bytes and the cofounder follows with 8 bytes of checksum.  I filed a request to update the document.  

   I will look at the code and compare it with the documentation and Windows implementation.  I will let you know.

Thanks!

Hongwei

-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze@...]
Sent: Thursday, September 17, 2009 11:17 AM
To: Hongwei Sun; pfif@...; cifs-protocol@...; Nick Meier; Guenther Deschner
Subject: Re: [Pfif] MS-NRPC: AES Schannel problems

Hi Hongwei,

Nick just told me that Windows seems to have a bug there and I tried to "reproduce" this bug in our code, but I still can't get windows to accept signed or sealed traffic from us.

See the attached capture:

Frames 178 and 179 are with signing
Frames 330 and 331 are with sealing

You can take a look at my code here (see the top 5 commits) http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel

metze

> -----Original Message-----
> From: Stefan (metze) Metzmacher [mailto:metze@...]
> Sent: Wednesday, September 16, 2009 1:46 PM
> To: Hongwei Sun
> Cc: pfif@...; cifs-protocol@...; Nick Meier; Guenther
> Deschner
> Subject: Re: [Pfif] MS-NRPC: AES Schannel problems
>
> Hi Hongwei,
>
>>    I think that Nick already informed you that AES 128 with 8 bit CFB mode has to be used.  I filed a request to add the information into 3.1.4.4 of MS-NRPC.  I also noticed that in  mxnrpc.c you attached , you used AES_cfb128_encrypt() (128 bit CFB mode) for computing server credential.  Please let us know if you have resolved the issue and if we can provide further help.
>
> Yes, he does and we got that part working. Thanks!
> using AES_cfb8_encrypt() instead of AES_cfb128_encrypt().
>
> However we have the next challenge, the Netlogon SSPI provider.
>
> I used tried both AES_cfb8_encrypt() and AES_cfb128_encrypt() but both don't work.
>
> Looking at the frame 308 and the following in w2k8r2rc-l4-w2k8r2-trust-aes-schannel-01.pcap.
>
> I think there's a bug in w2k8r2 in the docs.
>
> The NL_AUTH_SHA2_SIGNATURE is filled in with very strange values.
>
> It seem that the checksum is still 8 byte and the confounder directly follows. The last 24 bytes are just uninitalized memory.
>
> They are:
> Frame 308:
>
> 32 00 2e 00 33 00 31 00
> 2e 00 39 00 2e 00 32 00
> 31 00 34 00 00 00 00 00
>
> Frame 310:
>
> 35 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 02 00 00 00 00 00
>
> Frame 311: (I think it's random because the pdu is so long and point
> memory in other aeas)
>
> 51 03 21 9b 41 84 cc 90
> e7 e8 70 1c 52 60 55 5a
> 64 0c 6a 17 be 07 de 80
>
> Looks like a unicode string instead of parts of a checksum and a confounder.
>
> metze
>
>> Meanwhile, I provide some sample values that I captured from debugger
> for you to verify your logic.
>> OWF Password :
>>
>>    13 c0 b0 4b 66 25 0d 08-b8 a3 90 4d cc 8b 34 e3
>>
>> Client Challenge:
>>
>>   25 63 e3 5f 69 e1 5a 24
>>
>> Server Challenge:
>>
>>   9C 66 5F 90 D9 83 DF 43
>>
>> Session Key calculated:
>>  
>>    c9 c7 f7 2f c6 b9 13 e3-67 ae a9 1d 0a e3 a7 70
>>
>> Client Credential:
>>
>>   58 6a df 53 ef 72 78 d9
>>
>> Server Credential
>>
>>   E1 41 62 09 B2 3E 57 51
>>
>
> It would be great if you could add this values to the docs.
>
> metze
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Metze,

   We just found that there is a problem with the logic in step 9 of 3.3.4.2.1 (Generating an Initial Netlogon Signature Token) and step 5 of 3.3.4.2.2 (Receiving an Initial Netlogon Signature Token). When we  encrypt or decrypt SequenceNumber,  the IV is actually the concatenation of checksum, instead of SequenceNumber itself.    I will file a request to update the document.

   You can change your function netsec_do_seq_num() to use checksum to construct IV.

Thanks!

Hongwei

 
 


-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze@...]
Sent: Thursday, September 17, 2009 11:17 AM
To: Hongwei Sun; pfif@...; cifs-protocol@...; Nick Meier; Guenther Deschner
Subject: Re: [Pfif] MS-NRPC: AES Schannel problems

Hi Hongwei,

Nick just told me that Windows seems to have a bug there and I tried to "reproduce" this bug in our code, but I still can't get windows to accept signed or sealed traffic from us.

See the attached capture:

Frames 178 and 179 are with signing
Frames 330 and 331 are with sealing

You can take a look at my code here (see the top 5 commits) http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel

metze

> -----Original Message-----
> From: Stefan (metze) Metzmacher [mailto:metze@...]
> Sent: Wednesday, September 16, 2009 1:46 PM
> To: Hongwei Sun
> Cc: pfif@...; cifs-protocol@...; Nick Meier; Guenther
> Deschner
> Subject: Re: [Pfif] MS-NRPC: AES Schannel problems
>
> Hi Hongwei,
>
>>    I think that Nick already informed you that AES 128 with 8 bit CFB mode has to be used.  I filed a request to add the information into 3.1.4.4 of MS-NRPC.  I also noticed that in  mxnrpc.c you attached , you used AES_cfb128_encrypt() (128 bit CFB mode) for computing server credential.  Please let us know if you have resolved the issue and if we can provide further help.
>
> Yes, he does and we got that part working. Thanks!
> using AES_cfb8_encrypt() instead of AES_cfb128_encrypt().
>
> However we have the next challenge, the Netlogon SSPI provider.
>
> I used tried both AES_cfb8_encrypt() and AES_cfb128_encrypt() but both don't work.
>
> Looking at the frame 308 and the following in w2k8r2rc-l4-w2k8r2-trust-aes-schannel-01.pcap.
>
> I think there's a bug in w2k8r2 in the docs.
>
> The NL_AUTH_SHA2_SIGNATURE is filled in with very strange values.
>
> It seem that the checksum is still 8 byte and the confounder directly follows. The last 24 bytes are just uninitalized memory.
>
> They are:
> Frame 308:
>
> 32 00 2e 00 33 00 31 00
> 2e 00 39 00 2e 00 32 00
> 31 00 34 00 00 00 00 00
>
> Frame 310:
>
> 35 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 02 00 00 00 00 00
>
> Frame 311: (I think it's random because the pdu is so long and point
> memory in other aeas)
>
> 51 03 21 9b 41 84 cc 90
> e7 e8 70 1c 52 60 55 5a
> 64 0c 6a 17 be 07 de 80
>
> Looks like a unicode string instead of parts of a checksum and a confounder.
>
> metze
>
>> Meanwhile, I provide some sample values that I captured from debugger
> for you to verify your logic.
>> OWF Password :
>>
>>    13 c0 b0 4b 66 25 0d 08-b8 a3 90 4d cc 8b 34 e3
>>
>> Client Challenge:
>>
>>   25 63 e3 5f 69 e1 5a 24
>>
>> Server Challenge:
>>
>>   9C 66 5F 90 D9 83 DF 43
>>
>> Session Key calculated:
>>  
>>    c9 c7 f7 2f c6 b9 13 e3-67 ae a9 1d 0a e3 a7 70
>>
>> Client Credential:
>>
>>   58 6a df 53 ef 72 78 d9
>>
>> Server Credential
>>
>>   E1 41 62 09 B2 3E 57 51
>>
>
> It would be great if you could add this values to the docs.
>
> metze
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Stefan (metze) Metzmacher]

Hongwei,

>    We just found that there is a problem with the logic in step 9 of 3.3.4.2.1 (Generating an Initial Netlogon Signature Token) and step 5 of 3.3.4.2.2 (Receiving an Initial Netlogon Signature Token). When we  encrypt or decrypt SequenceNumber,  the IV is actually the concatenation of checksum, instead of SequenceNumber itself.    I will file a request to update the document.
>
>    You can change your function netsec_do_seq_num() to use checksum to construct IV.

Thanks very much, I got it working!

metze



_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol