svn commit: lorikeet r255 - in trunk/white-papers: .

vance at samba.org vance at samba.org
Thu Apr 14 02:10:01 GMT 2005


Author: vance
Date: 2005-04-14 02:10:00 +0000 (Thu, 14 Apr 2005)
New Revision: 255

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

Log:
Add a Canadian flare ;)
(Minor touch ups and comments)

Vance


Modified:
   trunk/white-papers/gensec-white-paper.lyx


Changeset:
Modified: trunk/white-papers/gensec-white-paper.lyx
===================================================================
--- trunk/white-papers/gensec-white-paper.lyx	2005-04-14 01:07:00 UTC (rev 254)
+++ trunk/white-papers/gensec-white-paper.lyx	2005-04-14 02:10:00 UTC (rev 255)
@@ -42,12 +42,13 @@
 Background
 \layout Standard
 
+# the? maybe a? or the long-standing free/open source...
 Samba4 is the ambitious new development branch of the Samba project, the
  long-standing CIFS implementation.
  In this new version, the Samba team has taken on an unparalleled challenge
- of matching current windows versions exactly, in terms of network protocols
+ of matching current Windows versions exactly, in terms of network protocols
  and features.
- Doing so has thrown up many challenges, as well as the opportunity to do
+ While providing many challenges, this goal provides an opportunity to implement
  things 
 \emph on 
 right
@@ -63,11 +64,11 @@
 \layout Standard
 
 Because Samba4 took the challenge to match Microsoft's latest releases exactly,
- the issues surrounding Active Directory, and modern security technologies
+ the issues surrounding Active Directory and modern security technologies
  quickly came to the fore.
- It would no longer be possible to just pretend to be NT4, and hope that
+ It is no longer be possible to just pretend to be NT4 and hope that
  the clients did not expect any particularly difficult behaviour.
- This time, these challenges would need to be tackled, not just worked around.
+ With this incarnation of Samba these challenges are being tackled, not just worked around.
 \layout Standard
 
 Finally, while the word `security' does mean many different things, this
@@ -80,7 +81,7 @@
 
 Before we take a more in depth look at the technologies, it is perhaps wise
  to first describe the question that security subsystems should be able
- to answer.
+ to answer: who are you?.
  
 \layout Subsection*
 
@@ -89,6 +90,8 @@
 
 The most common operation performed by a security subsystem is proving a
  user's identity.
+
+# this is an example of authorization, not authentication....
  In a common example, a logged on user would say, `only I should be able
  to get at my mailbox'.
  This is an easy problem to solve in the abstract: you simply prove who
@@ -101,12 +104,13 @@
 \layout Standard
 
 One of the less-considered, but equally important matters that a security
- subsystem should deal with is the authentication of peers.
+ subsystem should take care of is peer authentication.
  It is readily accepted that the user must prove their identity to a server,
  but with a few exceptions (mostly involving `secure' websites), users do
  not expect a server to prove its identity to them.
 \layout Standard
 
+# this section should probably give a quick example of a spoof or a m-i-t-m attack
 Proof of server identity is a very important issue, as soon as any of the
  information given by that server needs to be trusted.
  Often called `mutual authentication', a solution to this problem ensures
@@ -118,7 +122,7 @@
 Data integrity
 \layout Standard
 
-Once the identity of a server or client has been established, there must
+Once the identities of a server and client has been established, there must
  be some way to ensure that only that server or client can continue to communica
 te with the other.
  Otherwise, it may be possible for an impostor to take over a connection
@@ -127,12 +131,17 @@
  documents, or server administration functionality.
 \layout Standard
 
+
+# this next sentence is really awkward. I was trying to replace from "involves"
+# on with "typically uses a cryptographic calculation to prove two things: 
+# the message was generated be who you think generated it, ..."
+# but I'm having trouble making it work. 
 The practice of data integrity, also known as `signing', typically involves
  a cryptographic calculation where both sides can prove that: could only
  be performed by the other, and could only have been performed over the
  data received.
- If the signature (the output of that calculation) is invalid, the message
- must be considered compromised.
+ If the output of that calculation, known as the signature, is invalid, 
+ the message must be considered compromised.
 \layout Subsection*
 
 Data encryption
@@ -160,12 +169,13 @@
  Users expect that if they have `logged on' to the network, that further
  network access will not require them to re-enter their passwords, and any
  security subsystem should be designed to accommodate this.
- The challenge is to do so in a way that does not allow the user to unwittingly
+ Though simple in concept, the challenge is to design the security subsystem
+ in a way that does not allow the user to unwittingly
  compromise their own security.
 \layout Standard
 
 Likewise, the choice of data integrity and encryption functions should be
- transparent to the user, and to a large extent to the applications using
+ transparent to the user, and as transparent as possible to the applications using
  the security subsystem.
 \layout Subsection*
 
@@ -174,23 +184,24 @@
 
 The problem of authentication and the problem of authorization are often
  lumped together, and this is certainly the case in Active Directory.
- However, we first need to consider them apart.
+ We will first need to consider them separately.
 \layout Standard
 
-Once a user is authenticated (they are who they claim to be, or more simply
- they know the password to the account), a decision needs to be made as
- to what resources they may access: what files may they read/write, what
+Once a user is authenticated, that is, they are who they claim to be, or 
+ more simply they know the password to the account, a server must then
+ determine what resources that user may access. What files may they 
+ read/write? What
  hosts may they login to? This process is authorization, and even extends
- to such ideas as impersonation: a user may be authorized to impersonate
+ to such ideas as impersonation; a user may be authorized to impersonate
  another user.
 \layout Standard
 
-The tempting thing to do when designing real-world systems it to embody
+The tempting thing to do when designing real-world systems is to embody
  a great deal of authorization information in the authentication process;
  information such as group membership may be returned as a product of the
  login process, and even evaluated to determine if an authentication attempt
  should succeed.
- This is frowned upon because it links the two processes very tightly: preventin
+ Unfortunately, it links the two processes very tightly: preventin
 g a single authentication identity from having multiple authorization identities.
  That said, the two are linked (as they are in AD) for reasons of network
  efficiency.
@@ -207,7 +218,7 @@
  data integrity, data privacy and user credentials (used for authorisation).
 \layout Standard
 
-The provision of a generic security API is not a new practice - such APIs
+The idea of a generic security API is not new - such APIs
  and protocols have been available for many years, and in many guises 
 \begin_inset LatexCommand \citep{jra-security-soup}
 
@@ -227,6 +238,9 @@
 \end_inset 
 
 .
+# this sentence seems to be composed of two separate thoughts, chained together
+# only by the fact that Cyrus-SASL is an abstraction layer. But you don't state
+# that anywhere, so only readers familiar with Cyrus-SASL would know.....
  Indeed, the same can be said for many other projects, and the use of libraries
  such as Cyrus-SASL is very common.
  
@@ -264,10 +278,11 @@
 , a very simple SASL client and an SCHANNEL implementation.
  While it did work, the lack of clear boundaries around many parts of this
  code made extracting and consolidating this infrastructure a nightmare.
+ Using it and extending it was no walk in the park either.
  A lack of clear interfaces also meant that libsmbclient and smbclient were
- largely unable to use Kerberos session credentials, when available.
- With Samba4, the opportunity was grasped to get in early, before too much
- code was written, and to ensure that boundaries were indeed kept.
+ largely unable to use Kerberos session credentials, even if they were available.
+ With Samba4, the opportunity was grasped early, and implemented before too much
+ code was written, allowing clean boundaries to be drawn.
  
 \layout Standard
 
@@ -281,16 +296,16 @@
 \layout Standard
 
 On the Microsoft side of the fence, it is well known that Microsoft uses
- a subsystem called SSPI (Security Support Porvider Interface)
+ a subsystem called SSPI (Security Support Provider Interface)
 \begin_inset LatexCommand \citep{sspi}
 
 \end_inset 
 
  to handle almost all their network authentication and encryption interactions.
  This module, modeled after GSSAPI but without API compatibility, provides
- all windows applications, but in particular the OS itself, with a single
+ all Windows applications and the OS itself, with a single
  interface to these `security functions'.
- This modal was chosen not only for quite sensible software engineering
+ This model was chosen not only for quite sensible software engineering
  reasons, but also to provide a single point of audit (and key weakening)
  for encryption export controls.
 \layout Standard
@@ -300,7 +315,7 @@
  As such, certain behaviours appear in the network protocols that cannot
  be strictly emulated via the public API, nor via GSSAPI, were we to place
  our modules behind that framework.
- These behaviours include in particular the use of the `user session key'
+ These behaviours include, in particular, the use of the `user session key'
  directly in arbitary encryption and digest functions, rather than the use
  of SSPI functions for these purposes.
 \layout Subsection*
@@ -312,9 +327,9 @@
  protocol, a security negotiation protocol used extensively by Microsoft
  to select a real protocol used to handle authentication on a particular
  connection.
- As such, GENSEC must be designed with recursion in mind: this GENSEC module
+ As such, GENSEC is be designed with recursion in mind; this GENSEC module
  should be able to choose another to perform the final task, while allowing
- the negotation details to be handled inside the SPNEGO module itself.
+ the negotiation details to be handled inside the SPNEGO module itself.
  
 \layout Subsection*
 
@@ -387,7 +402,7 @@
 
 \end_inset 
 
- Kerberos, oringally from MIT's project Athena is a crypographicly secure
+ Kerberos, originally from MIT's project Athena, is a crypographicly secure
  trusted-third-party security system.
  Kerberos version 5 (krb5) is the current standard.
 \layout List



More information about the samba-cvs mailing list