Author: abartlet Date: 2004-10-28 14:11:55 +0000 (Thu, 28 Oct 2004) New Revision: 114
WebSVN: http://websvn.samba.org/websvn/changeset.php?rep=lorikeet&path=/trunk/samba4-ad-thesis&rev=114&nolog=1 Log: More fixes - jmcd is again generous with his time. 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 13:22:14 UTC (rev 113) +++ trunk/samba4-ad-thesis/chapters.lyx 2004-10-28 14:11:55 UTC (rev 114) @@ -911,8 +911,8 @@ \layout Standard Many distributed authentication systems allow logins to occur on numerous - hosts, but only a few hosts (possibly one) actually confirms or denies - an authentication request. + hosts, but only a few hosts (possibly one) actually confirm or deny an + authentication request. These are trusted third party systems; all hosts trust those with the passwords (the third party in the authentication exchange) to correctly return authentica tions success or failure. @@ -975,9 +975,9 @@ Single Sign On \layout Standard -Often abbreviated as simply SSO, the concept of Single Sign On is quite - simply a matter of usability; users wish to establish their identity once, - and not have to think about it after that. +Often abbreviated as simply SSO, the concept of Single Sign On is a matter + of usability; users wish to establish their identity once, and not have + to think about it after that. This allows for more complex authentication procedures as the user only has to tolerate them once per session. SSO has become the expectation in modern network environments. @@ -1188,10 +1188,30 @@ \end_inset . - Unfortunately a number of other improvements are also labeled NTLMv2, but - we will start by describing the new NTLMv2 challenge-response: + Unfortunately a number of other improvements are also labeled NTLMv2 +\begin_inset Foot +collapsed true + \layout Standard +The improvements labeled as NTLMv2 include the NTLM2 session response (described + in Section +\begin_inset LatexCommand \ref{sub:NTLM2-Session-Response} + +\end_inset + +) and NTLMv2 Session Security, which changes the NTLMSSP signing and sealing + algorithm, (described in section +\begin_inset LatexCommand \ref{sub:NTLMSSP-Signing-and} + +\end_inset + +). +\end_inset + +, but we will start by describing the new NTLMv2 challenge-response: +\layout Standard + NTLMv2 uses the same NT hash, but instead of the LM challenge-response formula, a new system based on HMAC-MD5 \begin_inset LatexCommand \citet{rfc2104} @@ -1207,11 +1227,11 @@ Session Keys \layout Standard -As part of the byproduct of NTLM authentication, a password-derived `session - key' is produced for use in verifying or encrypting data carried between - the client and server. - The algorithm used varies depending on the method of authentication, but - unfortunately can be very weak - often a fixed derivative of the user's +As a byproduct of NTLM authentication, a password-derived `session key' + is produced for use in verifying or encrypting data carried between the + client and server. + The algorithm used varies depending on the method of authentication and + unfortunately can be very weak - often a fixed derivative of the user's password! This key is known as the `user session key', and is used in a number of places within CIFS directly, as well as by the NTLMSSP suite. \layout Subsubsection* @@ -1259,17 +1279,21 @@ ). As such, the NTLM challenge-response steps have been wrapped into a framework - such that a calling application need only know how to pass messages, not - to understand them. - At each end of the connection, these blobs of data are passed down to the - security libraries for processing. + such that a calling application need only know how to pass these messages, + not to understand them. + At each end of the connection, these messages are passed down to the security + libraries for processing. \layout Subsection NTLMSSP Packets \layout Standard -Within those blobs of data is a particular packet format, which is known - as NTLMSSP, partly because this ASCII string prepends every protocol message. +Within those messages is a particular packet format, which is known as NTLMSSP, + partly because the ASCII string +\family typewriter +"NTLMSSP" +\family default + prepends every protocol exchange. Three different packets pass back and forth between client and server: \layout List \labelwidthstring 00.00.0000 @@ -1355,21 +1379,26 @@ \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 strength, but again, - the key is fixed until the user's password changes. - Unfortunately 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. + the session key is the NT Key from the NTLM authentication exchange. + This key is 128 bits in strength, but fixed until the user's password changes. + Unfortunately, despite being 128 bits in strength, the session key's value + can be obtained by breaking the 56-bit DES in the LM response algorithm, + so it never provides 128 bits of cryptographic protection. \layout Subsubsection* NTLM2 Session Response \layout Standard + +\begin_inset LatexCommand \label{sub:NTLM2-Session-Response} + +\end_inset + 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 + This option also changes 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* @@ -1398,6 +1427,11 @@ NTLMSSP Signing and Sealing \layout Standard + +\begin_inset LatexCommand \label{sub:NTLMSSP-Signing-and} + +\end_inset + NTLMSSP provides generic functions to sign and seal quantities of data, and this is used in DCE-RPC. Using the session key negotiated between the client and server, a cipher @@ -1447,10 +1481,10 @@ a network. In short, NTLM assumes that the server being contacted is also the server holding the passwords. - In order to implement a distributed network architecture, compromises must - be made at the server, which are invisible to the client. + In order to implement a distributed network architecture, compromises, + which are invisible to the client, must be made at the server. Typically these are to somehow contact the Domain Controller (DC) to confirm - or deny a incoming user's identity. + or deny an incoming user's identity. \layout Subsection Pass-though Authentication @@ -1469,7 +1503,7 @@ configuration option, the challenge is generated by a remote server, and the response forwarded to it likewise. - The server in the middle, to which the client wants to access, simply assumes + The server in the middle, to which the client wants access, simply assumes that the remote server will correctly signal authentication success or failure. Such a server does not gain any additional knowledge, such as session keys, @@ -1499,8 +1533,8 @@ is removed, and instead the DC is presented with both the challenge and the response. The server in the middle (the member server) gains in return a set of details - about the user - their name, groups and the cryptographic session keys - described above. + about the user: their name, groups and the cryptographic session keys described + above. \layout Standard @@ -3043,11 +3077,17 @@ hdb module development. \layout Section -Clapd + +\family typewriter +clapd \layout Standard -Clapd is a simple Connectionless LDAP daemon, written as part of the IBM - research effort + +\family typewriter +clapd +\family default + is a simple Connectionless LDAP daemon, written as part of the IBM research + effort \begin_inset LatexCommand \citep{jmcdAD} \end_inset
