[cifs-protocol] [REG:111101553031054] SystemLibraryDTC

Bryan Burgin bburgin at microsoft.com
Fri Jan 27 10:20:01 MST 2012


Andrew,

We completed our investigation to this issue and propose the following changes to [MS-DTYP], [MS-LSAD], [MS-SAMR] and [MS-WKST].  The text below contains yellow highlighting to identify changed text.  If the highlighting causes a problem for you, please let me know.

Thank you for your patience.

Bryan


[MS-DTYP]

Added new section:

2.3.14   Anonymous Session Key
The Anonymous Session Key is comprised of 16 bytes of UTF-8 characters:

UCHAR AnonymousSessionKey[] = {“SystemLibraryDTC”};

[MS-LSAD]

Added:

2.1   Transport
[…]
Cryptographic operations (as specified in section 5.1) MUST utilize a session key obtained from the SMB session on the client or server, or the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.

Added:

5   Security
5.1   Security Considerations for Implementers
[…]
The session key for sections 5.1.1 and 5.1.2 is obtained from the SMB transport, as specified in section 2.1. The session key is obtained from the SMB transport every time a message that needs encryption is to be sent or a message that needs decryption is to be received.  Clients should avoid using the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) to encrypt sensitive data since this does not protect the data.

[MS-SAMR]

Added:

2.2.7.6   SAMPR_USER_ALL_INFORMATION
[…]

LmOwfPassword:  An RPC_SHORT_BLOB structure where Length and MaximumLength MUST be 16, and the Buffer MUST be formatted with an ENCRYPTED_LM_OWF_PASSWORD structure with the cleartext value being an LM hash, and the encryption key being the 16-byte SMB [MS-SMB] session key established by the underlying authentication protocol (either Kerberos [MS-KILE] or NTLM [MS-NLMP]), or the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.

NtOwfPassword:  An RPC_SHORT_BLOB structure where Length and MaximumLength MUST be 16, and the Buffer MUST be formatted with an ENCRYPTED_NT_OWF_PASSWORD structure with the cleartext value being an NT hash, and the encryption key being the 16-byte SMB [MS-SMB] session key established by the underlying authentication protocol (either Kerberos [MS-KILE] or NTLM [MS-NLMP]) , or the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.

Added:

2.2.7.23   SAMPR_USER_INTERNAL1_INFORMATION
[…]

EncryptedNtOwfPassword:  An NT hash encrypted with the 16-byte SMB [MS-SMB] session key for the connection established by the underlying authentication protocol (either Kerberos [MS-KILE] or NTLM [MS-NLMP]) , or the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.

EncryptedLmOwfPassword:  An LM hash encrypted with the 16-byte SMB [MS-SMB] session key for the connection established by the underlying authentication protocol (either Kerberos [MS-KILE] or NTLM [MS-NLMP]), or the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.

Added:

2.2.7.26   SAMPR_USER_INTERNAL5_INFORMATION
[…]

UserPassword:  A cleartext password, encrypted according to the specification for SAMPR_ENCRYPTED_USER_PASSWORD, with the encryption key being the 16-byte SMB [MS-SMB] session key established by the underlying authentication protocol (either Kerberos [MS-KILE] or NTLM [MS-NLMP]) , or the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.

Added:

2.2.7.27   SAMPR_USER_INTERNAL5_INFORMATION_NEW
[…]

UserPassword:  A password, encrypted according to the specification for SAMPR_ENCRYPTED_USER_PASSWORD_NEW, with the encryption key being the 16-byte SMB [MS-SMB] session key established by the underlying authentication protocol (either Kerberos [MS-KILE] or NTLM [MS-NLMP]) , or the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.

Added:

3.1.5.6.4.4   UserInternal4Information
[…]

3.            If the USER_ALL_NTPASSWORDPRESENT or USER_ALL_LMPASSWORDPRESENT flag is present in the WhichFields field, the server MUST update the clearTextPassword attribute with the (decrypted) value of SAMPR_USER_INTERNAL4_INFORMATION.UserPassword, using the decryption key of the 16-byte SMB [MS-SMB] session key established by the underlying authentication protocol (Kerberos or NTLM) , or the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.

Added:

3.2.2.2   MD5 Usage
[…]
-              user-session-key is a 16-byte value obtained from the 16-byte SMB [MS-SMB] session key established by the underlying authentication protocol (either Kerberos [MS-KILE] or NTLM [MS-NLMP]) , or the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.

Added:

5   Security
5.1   Security Considerations for Implementers
Sensitive information, such as the cleartext password for accounts, is communicated through this protocol; therefore, implementers must pay special attention to the secrecy of this data. Although this protocol does not use transport-level encryption (with the exception of SamrValidatePassword), it does rely on the key strength of the SMB transport for encrypting cleartext data.  Clients should avoid using the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) to encrypt sensitive data since this does not protect the data.


[MS-WKST]

Added:

2.2.5.18.3   Encryption and Decryption
[…]
-              user-session-key is a 16-byte value obtained from the 16-byte SMB session key established by the underlying authentication protocol (either Kerberos [MS-KILE] or NTLM [MS-NLMP]), or the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection, as specified in [MS-SMB] Per SMB Session (section 3.2.1.3).

Added:

5   Security
5.1   Security Considerations for Implementers
[…]
This protocol relies on the key strength of the SMB transport for encrypting passwords (see section 2.2.5.18.3).  Clients should avoid using the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) to encrypt sensitive data since this does not protect the data.




-----Original Message-----
From: Bryan Burgin
Sent: Wednesday, January 04, 2012 2:38 PM
To: Andrew Bartlett (abartlet at samba.org)
Cc: 'cifs-protocol at cifs.org'; MSSolve Case Email
Subject: RE: [REG:111101553031054] [cifs-protocol] SystemLibraryDTC



[Hongwei to bcc]



Andrew,



I'm filling in for Hongwei on this issue.  I am engaged with several document groups here to sort this issue out.  Presently I'm working with Neil Martin, who you know, and the current thinking is that this might be addressed in an update to [MS-DTYP].  I'll let you know the outcome or ping you if we need any further information.



Going forward, I'll be your primary contact for this issue.



Bryan



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

From: Bryan Burgin

Sent: Wednesday, January 04, 2012 2:18 PM

To: "Hongwei Sun" <hongweis at microsoft.com<mailto:hongweis at microsoft.com>>

Cc: "cifs-protocol at cifs.org<mailto:cifs-protocol at cifs.org>" <cifs-protocol at cifs.org<mailto:cifs-protocol at cifs.org>>; "MSSolve Case Email" <casemail at microsoft.com<mailto:casemail at microsoft.com>>

Subject: [REG:111101553031054] [cifs-protocol] SystemLibraryDTC



On Tue, 2011-11-15 at 03:56 +0000, Hongwei Sun wrote:

> Andrew,

>

>   After reviewing code,  we confirmed that this fixed session key are

> used by some SAMR/LSAD RPC functions.  We are working on updating all

> the related documents.  When they are available , I will let you know.

Thanks!



Now would also be a good time to work out a way to remove them :-).  I would be very happy to work with your developers on a secure way we can indicate to a server that these keys should not be used, or that they should only be available over encrypted transports.



Andrew Bartlett



--

Andrew Bartlett

http://samba.org/~abartlet/

Authentication Developer, Samba Team           http://samba.org








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20120127/c3ad8a2c/attachment-0001.html>


More information about the cifs-protocol mailing list