svn commit: lorikeet r116 - in trunk/samba4-ad-thesis: .

[abartlet at samba.org]

Author: abartlet
Date: 2004-10-29 01:23:58 +0000 (Fri, 29 Oct 2004)
New Revision: 116

WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=lorikeet&rev=116

Log:
- Add comments on the implications of KEY_EXCHANGE on the LSAKEY
crypto challenge, and make a few more of the things I've done clear.

- Death to dashes.

Andrew Bartlett

Modified:
   trunk/samba4-ad-thesis/chapters.lyx


Changeset:
Modified: trunk/samba4-ad-thesis/chapters.lyx
===================================================================
--- trunk/samba4-ad-thesis/chapters.lyx	2004-10-28 15:56:11 UTC (rev 115)
+++ trunk/samba4-ad-thesis/chapters.lyx	2004-10-29 01:23:58 UTC (rev 116)
@@ -2915,7 +2915,9 @@
 
 , Samba quietly evolved over the past 12 years from a barely functional
  prototype, used to communicate between a DOS Pathworks client and a Sun
- server, into a solid file and print server for Windows clients.
+ server, into a solid file and print server for Windows clients, maintained
+ by a team of over 30 international developers, 12 of which are active at
+ any one time.
 \layout Subsubsection*
 
 Samba 2.0
@@ -3116,11 +3118,16 @@
 Samba4 Status
 \layout Standard
 
-Samba version 4 is an ongoing research project, but has made significant
- headway into this problem space before I even proposed my thesis topic.
+Samba version 4 is an ongoing research project of the Samba Team, and had
+ made significant headway into this problem space before I even proposed
+ my thesis topic.
  It has grown up in a very modular style, and with a much cleaner code-base
  than Samba 3.0.
- While there is far more to Samba4 than these subsystems, the AD emulation
+ The core development on Samba4 has been by Dr Tridgell, Stefan Metzmacher
+ and myself, with contributions from many others from time to time.
+\layout Standard
+
+While there is far more to Samba4 than these subsystems, the AD emulation
  work hits on these in particular:
 \layout Section
 
@@ -3261,7 +3268,7 @@
  calls are made, negotiating security mechanisms such as 128-bit session
  keys.
 \begin_inset Foot
-collapsed false
+collapsed true
 
 \layout Standard
 
@@ -3348,8 +3355,8 @@
  easier initial development.
  In this case, we `hash' the passwords on the fly, but we can also store
  the pre-hashed password if the plain-text is not available.
- These requirements required a minor code restructure, that has now been
- included by Heimdal's developers into current snapshots.
+ These requirements required me to perform a minor code restructure, which
+ has now been included by Heimdal's developers into current snapshots.
 \layout Subsection
 
 No PAC at this stage
@@ -3361,7 +3368,7 @@
 
 \end_inset 
 
-, PAC support was not implemented - instead, the Samba server was modified
+, PAC support was not implemented: instead the Samba server was modified
  to accept Kerberos packets without the PAC.
  (The client does not process the PAC in the initial use case, so this complexit
 y was deferred).
@@ -3766,15 +3773,30 @@
  can be derived by extracting the cipher-text for a known plain-text.
 \layout Subsection
 
+Controlling the session key
+\layout Standard
+
+In researching this problem, I noticed that in NTLMSSP, the 
+\family typewriter 
+KEY_EXCHANGE
+\family default 
+ option allows the network client to chose the session key.
+ At this stage, it was unknown what encryption function was in use, but
+ by choosing a known weak encryption key, such as all-ones (all zeros was
+ not supported), we could analyise the properties of the cyphertext.
+ 
+\layout Subsection
+
 Proof that it's a fixed key
 \layout Standard
 
 One of the first breakthroughs in solving the puzzle was the realisation
- that, despite changes in user-names and passwords, the encrypted secret
- would not change.
+ that, despite changes in session keys, user-names or passwords, the encrypted
+ secret would not change.
  This was most puzzling, because secrets are typically encrypted with a
- session key, a secret to between the user and server (which implies that
- it should change with the user's password).
+ value shared between the user and server (which implies that it should
+ change with the user's password, even if somehow disconnected from the
+ key exchange mentioned above).
 \layout Standard
 
 This strongly suggests that the key is some constant value, possibly a `dummy'
@@ -3800,8 +3822,8 @@
  Microsoft implementations.
 \layout Standard
 
-It was suggested that the key was probably not a random value, but more
- likely an ASCII string used for initialisation.
+In considering the possible secret keys, I suggested that the key was probably
+ not a random value, but more likely an ASCII string used for initialisation.
 \begin_inset Foot
 collapsed true
 
@@ -3822,7 +3844,7 @@
 \layout Standard
 
 Eventually (and this only took a matter of 24 hours of CPU time) the fixed
- key was found - 
+ key was found: 
 \family typewriter 
 "SystemLibraryDTC"
 \family default