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

[abartlet at samba.org]

Author: abartlet
Date: 2004-10-27 13:10:48 +0000 (Wed, 27 Oct 2004)
New Revision: 111

WebSVN: http://websvn.samba.org/websvn/changeset.php?rep=lorikeet&path=/trunk/samba4-ad-thesis&rev=111&nolog=1

Log:
Fix a few references, and watch LyX reformat everything on save...

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-27 13:00:24 UTC (rev 110)
+++ trunk/samba4-ad-thesis/chapters.lyx	2004-10-27 13:10:48 UTC (rev 111)
@@ -910,9 +910,9 @@
 Trusted Third Party Authentication
 \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 authenticati
-on request.
+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.
  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.
@@ -978,8 +978,8 @@
 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.
- This allows for more complex authentication procedures as the user only has
- to tolerate them once per session.
+ 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.
 \layout Chapter
 
@@ -997,8 +997,9 @@
 NTLM Challenge Response
 \layout Standard
 
-NTLM is a challenge-response authentication scheme, designed to prevent a
- direct compromise of the user's password as it passes from client to server.
+NTLM is a challenge-response authentication scheme, designed to prevent
+ a direct compromise of the user's password as it passes from client to
+ server.
  In theory, the value that the client gives the server can only be generated
  with knowledge of the password, but does not reveal the password itself.
  
@@ -1209,8 +1210,8 @@
 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
+ The algorithm used varies depending on the method of authentication, but
+ 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*
@@ -1569,18 +1570,18 @@
 Kerberos Basics
 \layout Standard
 
+Kerberos
+\begin_inset LatexCommand \citep{appliedcrypto}
 
-\begin_inset LatexCommand \citet{appliedcrypto}
-
 \end_inset 
 
-Kerberos is described as a `trusted third party' authentication system,
- based around shared secrets and symmetric cryptography.
+ is described as a `trusted third party' authentication system, based around
+ shared secrets and symmetric cryptography.
  The hub of the Kerberos authentication system is the Key Distribution Center
  (KDC), which contains a copy of each user's passwords (in very much the
  same way a DC or standalone server does for NTLM).
  Kerberos is an Internet Standard
-\begin_inset LatexCommand \citet{rfc1510}
+\begin_inset LatexCommand \citep{rfc1510}
 
 \end_inset 
 
@@ -1588,7 +1589,7 @@
  Athena.
  In an interesting diversion from the standards documents, four-part dialogue,
  describing the system is available
-\begin_inset LatexCommand \citet{krb5-dialog}
+\begin_inset LatexCommand \citep{krb5-dialog}
 
 \end_inset 
 
@@ -1651,11 +1652,12 @@
  This is very nice in theory, but presents some practical difficulties in
  mapping a Kerberos identity to a user, and their access rights.
  In particular, it is the problem of performing this mapping in a network-effici
-ent manner that caused the PAC (Privilege Attribute Certificate) and associated infrastructure to be devised.
+ent manner that caused the PAC (Privilege Attribute Certificate) and associated
+ infrastructure to be devised.
 \layout Standard
 
- The PAC is a cryptographically signed blob of data including information on a user's groups, their home directory
- location, and similar details.
+The PAC is a cryptographically signed blob of data including information
+ on a user's groups, their home directory location, and similar details.
  This is nothing particularly special, but Microsoft created a storm by
  releasing the specification for this data format under a `click-though'
  licence, including a Non-Disclosure Agreement (NDA)
@@ -1728,9 +1730,9 @@
 \layout Standard
 
 Away from protocol implementation details, the names of security mechanisms
- are associated with particular levels of security. Clients and servers
- may place requirements on each other by which mechanisms they support,
- but this does not have any wire artifacts.
+ are associated with particular levels of security.
+ Clients and servers may place requirements on each other by which mechanisms
+ they support, but this does not have any wire artifacts.
 \layout Section
 
 GSSAPI
@@ -1742,7 +1744,8 @@
  an Object IDentifier (OID) to prefix its network messages.
  OIDs are globally unique streams of numbers, delegated out of a hierarchical
  name-space, and formatted (as is the case for all of GSSAPI) in ASN.1.
- (SASL uses simple text strings for the same purpose, with much clearer effect).
+ (SASL uses simple text strings for the same purpose, with much clearer
+ effect).
 \layout Standard
 
 GSSAPI, like SASL, exchanges datagrams until both sites are happy with the