Author: abartlet Date: 2004-10-01 05:23:53 +0000 (Fri, 01 Oct 2004) New Revision: 82
WebSVN: http://websvn.samba.org/websvn/changeset.php?rep=lorikeet&path=/trunk/samba4-ad-thesis&rev=82&nolog=1 Log: Add yet more information on NTLMSSP Modified: trunk/samba4-ad-thesis/chapters.lyx Changeset: Modified: trunk/samba4-ad-thesis/chapters.lyx =================================================================== --- trunk/samba4-ad-thesis/chapters.lyx 2004-09-27 23:14:25 UTC (rev 81) +++ trunk/samba4-ad-thesis/chapters.lyx 2004-10-01 05:23:53 UTC (rev 82) @@ -858,9 +858,12 @@ this third party, preferably by some cryptographic proof. Often this is by yet another shared-secret authentication scheme. +\layout Chapter + +NTLM \layout Section -NTLM +NTLM Challenge Response \layout Standard The NTLM authentication scheme is a challenge-response authentication scheme, @@ -1053,17 +1056,25 @@ \layout Subsubsection* LM session key construction +\layout Standard + +The LM session key is constructed from the first 8 bytes of the LM hash, + padded to 16 bytes with zeros. + Given what we understand about the LM hash, it is equivilant to the password + for passwords of 7 characters or less! +\layout LyX-Code + +LM_key = concat(head(ascii(password), 8), zeros[8]); \layout Subsubsection* NT session key construction \layout Standard -The NT session key is a fixed derivative of the password - it contains none - of the per-session information that the otherwise weaker LM key does: +The NT session key is also fixed derivative of the password: \layout LyX-Code NT_key = md4(md4(unicode(password)); -\layout Subsection +\layout Section NLTMSSP \layout Standard @@ -1085,7 +1096,7 @@ to understand them. At each end of the connection, these blobs of data are passed down to the security libraries for processing. -\layout Subsubsection* +\layout Subsection NTLMSSP Packets \layout Standard @@ -1114,7 +1125,7 @@ \layout Standard The format of these packets, and the meaning of most of the options carried - in them is now reasonably well understood, and partially documented in + in them is now reasonably well understood, and partially documented by \begin_inset LatexCommand \citet{opengroupntlm} @@ -1122,8 +1133,91 @@ . +\layout Subsection + +NTLMSSP Options +\layout Standard + +Within the NTLMSSP context, a different set of session keys, cyphers and + authentication inputs are used - depending on the negotiated options. + The fact that these are negotiated is promlementic, but the implementation + may define minimum required options. + What follows is a discussion of some of the options - but a more complete + treatment (of some of the options) is given by +\begin_inset LatexCommand \citet{davenportntlm} + +\end_inset + +. \layout Subsubsection* +LM Session Key +\layout Standard + +The LM session key is created as specified by +\begin_inset LatexCommand \citet{opengroupntlm} + +\end_inset + + - it is based on the NTLM `LM Key', and includes part of the LM response + (and therefore the server-generated random challenge) in a DES based hash, + making it unique for each session. + It is negotiated by the specification of the +\family typewriter +NTLMSSP_NEGOTIATE_LM_KEY +\family default + in the negotiated options. +\layout Standard + +This key is then 'weakened' to various strengths, to fix export requirements. + The irony is that the 128 bit negotiated key is far from this real strength, + due to there being at most 56 bits of key input! +\layout Subsubsection* + +NT Sesssion Key (v1) +\layout Standard + +When the LM_KEY option is not negotiated, and no other options are specified, + the session key is the NT Key from the NTLM level. + This is stronger in hash strength, with real 128 bit stength, but again, + the key is fixed until the user's password changes. + Unfortunetly other factors - the use the LM response function for the authentic +ation step - means that the key can be discovered by breaking a 56 bit cypher. +\layout Subsubsection* + +NTLM2 Session Response +\layout Standard + +Another modification to the NTLMSSP login scheme, this option prevents a + server-initiated dictionary attack, by providing input from the client + and server in calculating the challenge input to the challenge-response + function. + This option also modifies the session key negotiation, to include mutually + agreed random data into the key. + This ensures that the session key again changes between sessions. +\layout Subsubsection* + +Key Exchange +\layout Standard + +In another modification to the session key negotiation, the specfication + of the +\family typewriter +NTLMSSP_NEGOTIATE_KEY_EXCHANGE +\family default + flag allows the client to specify a new session key, to be encrypted with + what otherwise would be the session key. + Presumably, the client would choose a random sequence of bytes, unrelated + to the password, but as will be noted in +\begin_inset LatexCommand \ref{sec:LSAKEY} + +\end_inset + +, the ability for the client the propose a known session key is an unexpected + weakness in the NTLMSSP scheme, particularly given the effort put into + the NTLM2 flag. +\layout Subsection + NTLMSSP Signing and Sealing \layout Standard @@ -1162,6 +1256,20 @@ . +\layout Section + +Distributed NTLM +\layout Standard + +NTLM by it's basic description has not inbuilt mechanism for distribution + over a network. + It assumes that the server being contacted is also the server being contacted. +\layout Subsection + +Pass-though Authentication +\layout Subsection + +NETLOGON \layout Chapter The Join process @@ -1981,6 +2089,14 @@ \layout Section LSAKEY +\layout Standard + + +\begin_inset LatexCommand \label{sec:LSAKEY} + +\end_inset + + \layout Subsection An opening: