home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1993 July / Disc.iso / inet / ietf / 92jul / tadmin.min < prev    next >
Encoding:
Text File  |  1993-02-17  |  8.9 KB  |  244 lines
  1. The following is a cleaned up version of the slide set for the
  2. Trusted Administration working group summary report on 7/16/92.
  3.  
  4. This document will be archived.
  5.  
  6. Page breaks (via <ctrl>L's) have been included.
  7.  
  8. TRUSTED ADMINISTRATION
  9.  
  10. Activities:
  11.  
  12. Item                               Result
  13. --------------------------------   --------------------------------------------
  14. 1. Trusted Admin                   - Still lack a solid proposal from any
  15.                                      vendor.
  16.                                    - Brainstormed the problem at some length
  17.                                      from the perspective of "If I am a machine
  18.                                      on the network, in order to be
  19.                                      administered from a central place I have
  20.                                      to be able to ..." and generated a list
  21.                                      of these items (attached).
  22.                                    - Started sorting/reducing this list into
  23.                                      musts, high wants and low wants.
  24.                                    - Need to leverage work from other working
  25.                                      groups (POSIX etc.) working on the
  26.                                      general administration problem.
  27.                                    - May want to further refine this list
  28.                                      via electronic forum.
  29.  
  30. 2. Audit Transfer
  31.  
  32.    a. AITP (formally SITP)         - We have an updated AITP draft on the
  33.                                      TSIG archive.
  34.  
  35.    b. Reviewed SNMP/SMP
  36.       capabilities as possible
  37.       audit transfer mechanism.
  38.       Areas of possible concern
  39.       were:
  40.  
  41.       - How does S*MP paradigm (a  - At any given time a snap shot of the
  42.         name space corresponding     available audit records on a system can
  43.         to a few control elements    be indexed field name (column) and
  44.         on a device) map to          instance identifier (row).  This is
  45.         thousands of audit           arbitrary but workable.
  46.         record?
  47.  
  48.       - Can any message priority   - Neither S*MP or AITP do this.
  49.         (alarms before bulk data
  50.         upload) be provided.
  51.  
  52.       - Assured delivery, order    - AITP relies on TCP where S*MP usually
  53.         and integrity.               runs over UDP therefore AITP is "more
  54.                                      reliable" however if problems occur that
  55.                                      require resynchronization at the
  56.                                      application level, the variable and
  57.                                      instance information built into the
  58.                                      var-binds may provide better information
  59.                                      to the application for this purpose.
  60.  
  61.       - Audit data volume (on the  - SNMP (w/o bulk transfer) is a non-starter.
  62.         order of 20Mb/user/day)      SMP may work but the low information
  63.                                      density of ASN.1 encoded var-binds (vs.
  64.                                      raw data) opens a concern regarding the
  65.                                      amount of network bandwidth needed.
  66.  
  67.  
  68. TRUSTED ADMINISTRATION
  69.  
  70. Activities (continued)
  71.  
  72.       - Filtering at the source    - Filtering capabilities are built into
  73.         for limited extractions.     AITP.  If the MIB is defined with filter
  74.                                      variables that can be set by S*MP, then
  75.                                      similar functions can be performed if the
  76.                                      instance identifiers are remapped to only
  77.                                      those records that pass the filters.
  78.  
  79.       - Error feedback from        - S*MP and AITP provide similar
  80.         manager node.                capabilities.
  81.  
  82.       - Connection maintenance     - Not an issue for AITP as protocol defines
  83.         during long data gathering   how to drop connection after request and
  84.         and filtering operations.    re-establish connection on reply to
  85.                                      prevent hogging unused resources.  Not
  86.                                      an issue for S*MP when if run over UDP.
  87.  
  88.                                    BOTTOM LINE:
  89.  
  90.                                      We need to work though these issues and
  91.                                      get inputs from TADMIN members that
  92.                                      were not present at this meeting.
  93.  
  94. Attachments:
  95.  
  96.    1. "If I am a machine  on the network, in order to be administered from
  97.        a central location, I have to be able to ..." list and partial
  98.        analysis.
  99.  
  100.    2. Trusted Admin working group document history.
  101.  
  102.  
  103.  
  104. TRUSTED ADMINISTRATION
  105.  
  106. If I am a machine  on the network, in order to be administered from a
  107. central location, I have to be able to ...
  108.  
  109. 1.  Authenticate an administrator.
  110.  
  111. 2.  Authenticate myself (or be authenticated) to an administrator.
  112.  
  113. 3.  Add/delete/disable users.
  114.  
  115. 4.  Respond to local and remote administration.
  116.  
  117. 5.  Tell other systems that the user has changed his/her password.
  118.  
  119. 6.  Allow users to change their passwords.
  120.  
  121. 7.  Allow user privilege to be modified.
  122.  
  123. 8.  Maintain synchronization with "master database."
  124.  
  125. 9.  Get data from central database.
  126.  
  127. 10. Synchonize time with all other systems in domain of interest.
  128.  
  129. 11. Synchonize time with central administrator.
  130.  
  131. 12. Protect security relevant data.
  132.  
  133. 13. Provide audit data as requested.
  134.  
  135. 14. Explicitly audit administrative actions.
  136.  
  137. 15. Send/Receive alerts of security events.
  138.  
  139. 16. Administer "privileges" in various vendor formats.
  140.  
  141. 17. Administrate various vendor labeling formats.  [deleted]
  142.  
  143. 18. Confirm integrity of administration messages (and provide trustworthy
  144.     responses).
  145.  
  146. 19. Modify privileges of local system.
  147.  
  148. 20. Modify "accreditation range" of other systems (or self) in response
  149.     to administrative updates.
  150.  
  151. 21. Change user clearance.
  152.  
  153. 22. Validate the network (or provide needed information to a centralized
  154.     validation application).
  155.  
  156. 23. Recover from errors in administrative exchanges.
  157.  
  158. 24. Guarantee delivery of administrative messages.
  159.  
  160. 25. Know who I can talk to (other machines).
  161.  
  162. 26. Not have to know other systems in order to initiate administrative
  163.     actions (i.e. be able to work through another server to allow other
  164.     systems at higher levels to be hidden).
  165.  
  166.  
  167. TRUSTED ADMINISTRATION
  168.  
  169. "If I am a machine ..." list (continued)
  170.  
  171. 27. Provide remote proedure API to local administrative functions.
  172.  
  173. 28. Ensure unique user ID across arbitrarily large admininstrative domain.
  174.  
  175. 29. Catch up if I am down when administrative changes occur.
  176.  
  177. 30. "Self audit" to generate minimum number of audit records at the
  178.     granularity of complete administrative actions.
  179.  
  180. 31. Add a new remote host.
  181.  
  182.  
  183.  
  184.                             High          Low
  185. Class        Must           Want          Want             Note 
  186. ----------   ------------   -----------   --------------   ----------------
  187. Managed      1,2,3,4,7,9,   5,6,8,11,     8,11,13,14,      Depends on
  188. Secure       11,12,13,14,   13,14,15,                      Policy (8, 11,
  189. Node         18, 19,                                       13,14,
  190.  
  191.                                                            Not our job (17,
  192.  
  193.                                                            Killed (10,
  194.  
  195. Manager      16,
  196.  
  197. ---------------------------                                     
  198.  
  199.  
  200. TRUSTED ADMINISTRATION
  201.  
  202. Trusted Admin working group document history.
  203.  
  204. Document   Title
  205. Number        (- history & distinquishing characteristics)
  206. --------   --------------------------------------------------------------------
  207. 1.         The Need for SITP
  208.               - 1 - 1/26/92 introduced to TSIG 1/28/92
  209.  
  210. 2.         Audit Event Criteria
  211.               - 1 - faxed to TSIG 1/28/92
  212.  
  213. 3.         Security Information Transfer Protocol (SITP)
  214.               - 1.0 - discussed at TSIG 1/29/92
  215.               - 2.0 - added set functionality 4/92
  216.  
  217. 4.         Host Audit Data Event Types and Formats
  218.            (as defined by SAC)
  219.               - 1 - faxed to TSIG 1/18/92
  220.  
  221. 5.         What and When to Audit During Trusted Sessions
  222.               - 1 - 1/28/92
  223.  
  224. 6.         Audit Information Transfer Protocol (AITP)
  225.               - 2.1 - formerly SITP, discussed at TSIG 7/14/92
  226.  
  227.  
  228. "David Belote"                <> 
  229. "Lee Benzinger"               <lab@wdl1.wdl.loral.com>
  230. "Charles Blauner"             <chazx@ctt.bellcore.com>
  231. "Luc Boulianne"               <lucb@cs.mcgill.ca>
  232. "Jeff Case"                   <case@cs.utk.edu>
  233. "Robert Cooney"               <cooney@wnyose.nctsw.navy.mil>
  234. "Jeffrey Edelheit"            <edelheit@mitre.org>
  235. "William Huyck"               <> 
  236. "Nina Lewis"                  <nina@cam.unisys.com>
  237. "Vern McGeorge"               <vern@hpda.cup.hp.com>
  238. "Wally Ramsey"                <wbr@mitre.org>
  239. "Bradley Rhoades"             <bdrhoades@mmc.mmmg.com>
  240. "Paul Vazquez"                <vazquez@dockmaster.ncsc.mil>
  241. "Moira West"                  <mjw@cert.org>
  242. "Peter Williams"              <p.williams@uk.ac.ucl.cs>
  243.  
  244.