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

[abartlet at samba.org]

Author: abartlet
Date: 2005-01-05 23:56:35 +0000 (Wed, 05 Jan 2005)
New Revision: 172

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

Log:
A bit more clarifying detail on the white papers.

Andrew Bartlett

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


Changeset:
Modified: trunk/white-papers/gensec-white-paper.lyx
===================================================================
--- trunk/white-papers/gensec-white-paper.lyx	2005-01-05 09:03:43 UTC (rev 171)
+++ trunk/white-papers/gensec-white-paper.lyx	2005-01-05 23:56:35 UTC (rev 172)
@@ -146,6 +146,23 @@
  communications channel, such that only the other party can decrypt it.
 \layout Subsection*
 
+Transparency and Single Sign on
+\layout Standard
+
+One of the biggest challenges in building a security subsystem is correct
+ implementation of `Single Sign On' and single source of password solutions.
+ 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
+ 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
+ the security subsystem.
+\layout Subsection*
+
 Authorization problems
 \layout Standard
 
@@ -227,6 +244,8 @@
  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.
+ 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.
  
@@ -317,10 +336,28 @@
  While it has been listed above as a security protocol, it really is a security
  negotiation protocol, which in turn selects a real protocol to handle the
  connection.
- GENSEC avoids cluttering each implementation module with understanding
- about this special wrapping, and handles all the details in the SPNEGO
- module.
+ As such, GENSEC has been designed with such recursing in mind, with most
+ of the details handled in the SPNEGO module.
  
+\layout Subsection*
+
+Single Sign On
+\layout Standard
+
+Following on from the special handling of SPNEGO is a particular problem
+ for the implementation of Single Sign On solutions.
+ On a Unix-like platform, the only Single Sign On technology currently available
+ is Kerberos, and this is selected (typically) via SPNEGO.
+ This means that the calling application has no idea if Kerberos is available,
+ nor if the user has sufficient credentials to use it.
+ (Only NTLMSSP may be available, or the KDC may be un-contactable, which
+ would require a password prompt).
+\layout Standard
+
+As such, an infrastructure of callbacks has and is being developed, to correctly
+ handle all the different cases.
+ This is not only at the GENSEC layer, but also into the calling applications,
+ which must no longer unconditionally prompt for a password.
 \layout Section*
 
 GENSEC Interfaces

Modified: trunk/white-papers/samba3-samba4.lyx
===================================================================
--- trunk/white-papers/samba3-samba4.lyx	2005-01-05 09:03:43 UTC (rev 171)
+++ trunk/white-papers/samba3-samba4.lyx	2005-01-05 23:56:35 UTC (rev 172)
@@ -230,9 +230,19 @@
  the pace at which Samba4 moved, and an unwillingness on the part of Samba4
  developers to `slow down' or compromise the Samba4 development to accommodate
  the half-merge.
- 
+\begin_inset Foot
+collapsed true
+
 \layout Standard
 
+Had a compromise been reached, certain `no go' zones been established, internal
+ interfaces fixed and significant effort put into the merge, it was feared
+ that Samba4 development could stall out entirely.
+\end_inset 
+
+
+\layout Standard
+
 Merging code-bases is perhaps one of the hardest tasks in software development,
  particularly when they have diverged in the way that Samba 3.0 and Samba4
  have.
@@ -301,6 +311,19 @@
  Win9X clients) must be explicitly handled.
 \layout Subsubsection*
 
+Authentication
+\layout Standard
+
+It should be noted that redirection of incoming PDUs on named pipes is not
+ as simple as simply forwarding datagrams, as there is a significant amount
+ of state that is inherited from the CIFS level connection.
+ Correctly handling this state transfer has for the XAD and Samba-TNG cases
+ been done by an `out of band' mechanism, or by prefixing it to the first
+ message.
+ In either case, details such as user identity, groups and session keys
+ must be communicated and accepted.
+\layout Subsubsection*
+
 Samba 3.0 to Samba4
 \layout Standard
 
@@ -320,7 +343,7 @@
  known RPC server.
  This is more interesting, until Samba4 surpasses Samba3 in RPC function,
  but will require some effort to correctly handle UID mappings (which are
- very integrated in ldb in samba4).
+ tightly integrated with ldb in samba4).
 \layout Subsection*
 
 LDB integration efforts