TSIG Trusted Admin Working Group Minutes

[Vern McGeorge <[e-mail]>]

==================================================================
>>> Submissions to the tsig list: [e-mail]
>>> Additions/deletions/questions: [e-mail]
>>> Archive Server: [e-mail]
==================================================================

Megan,
   I believe that this is due to you within 2 weeks of the ietf conference
   for inclusion in the proceedings (but I cannot find the yellow sheet to
   save my life).  I hope that you are the right recipient, but if not, can
   you please let me know who is.  I also hope that there is not an IETF
   official format and that this raw ASCII file with page breaks but without
   tabs or any other funny characters is acceptable.


TSIG'ers,
   The normal stuff follows.

Vern McGeorge
408-447-2768
[e-mail]


The following is a cleaned up version of the slide set for the
Trusted Administration working group summary report on 7/16/92.

This document will be archived.

Page breaks (via <ctrl>L's) have been included.

TRUSTED ADMINISTRATION

Activities:

Item                               Result
--------------------------------   --------------------------------------------
1. Trusted Admin                   - Still lack a solid proposal from any
                                     vendor.
                                   - Brainstormed the problem at some length
                                     from the perspective of "If I am a machine
                                     on the network, in order to be
                                     administered from a central place I have
                                     to be able to ..." and generated a list
                                     of these items (attached).
                                   - Started sorting/reducing this list into
                                     musts, high wants and low wants.
                                   - Need to leverage work from other working
                                     groups (POSIX etc.) working on the
                                     general administration problem.
                                   - May want to further refine this list
                                     via electronic forum.

2. Audit Transfer

   a. AITP (formally SITP)         - We have an updated AITP draft on the
                                     TSIG archive.

   b. Reviewed SNMP/SMP
      capabilities as possible
      audit transfer mechanism.
      Areas of possible concern
      were:

      - How does S*MP paradigm (a  - At any given time a snap shot of the
        name space corresponding     available audit records on a system can
        to a few control elements    be indexed field name (column) and
        on a device) map to          instance identifier (row).  This is
        thousands of audit           arbitrary but workable.
        record?

      - Can any message priority   - Neither S*MP or AITP do this.
        (alarms before bulk data
        upload) be provided.

      - Assured delivery, order    - AITP relies on TCP where S*MP usually
        and integrity.               runs over UDP therefore AITP is "more
                                     reliable" however if problems occur that
                                     require resynchronization at the
                                     application level, the variable and
                                     instance information built into the
                                     var-binds may provide better information
                                     to the application for this purpose.

      - Audit data volume (on the  - SNMP (w/o bulk transfer) is a non-starter.
        order of 20Mb/user/day)      SMP may work but the low information
                                     density of ASN.1 encoded var-binds (vs.
                                     raw data) opens a concern regarding the
                                     amount of network bandwidth needed.


TRUSTED ADMINISTRATION

Activities (continued)

      - Filtering at the source    - Filtering capabilities are built into
        for limited extractions.     AITP.  If the MIB is defined with filter
                                     variables that can be set by S*MP, then
                                     similar functions can be performed if the
                                     instance identifiers are remapped to only
                                     those records that pass the filters.

      - Error feedback from        - S*MP and AITP provide similar
        manager node.                capabilities.

      - Connection maintenance     - Not an issue for AITP as protocol defines
        during long data gathering   how to drop connection after request and
        and filtering operations.    re-establish connection on reply to
                                     prevent hogging unused resources.  Not
                                     an issue for S*MP when if run over UDP.

                                   BOTTOM LINE:

                                     We need to work though these issues and
                                     get inputs from TADMIN members that
                                     were not present at this meeting.

Attachments:

   1. "If I am a machine  on the network, in order to be administered from
       a central location, I have to be able to ..." list and partial
       analysis.

   2. Trusted Admin working group document history.



TRUSTED ADMINISTRATION

If I am a machine  on the network, in order to be administered from a
central location, I have to be able to ...

1.  Authenticate an administrator.

2.  Authenticate myself (or be authenticated) to an administrator.

3.  Add/delete/disable users.

4.  Respond to local and remote administration.

5.  Tell other systems that the user has changed his/her password.

6.  Allow users to change their passwords.

7.  Allow user privilege to be modified.

8.  Maintain synchronization with "master database."

9.  Get data from central database.

10. Synchonize time with all other systems in domain of interest.

11. Synchonize time with central administrator.

12. Protect security relevant data.

13. Provide audit data as requested.

14. Explicitly audit administrative actions.

15. Send/Receive alerts of security events.

16. Administer "privileges" in various vendor formats.

17. Administrate various vendor labeling formats.  [deleted]

18. Confirm integrity of administration messages (and provide trustworthy
    responses).

19. Modify privileges of local system.

20. Modify "accreditation range" of other systems (or self) in response
    to administrative updates.

21. Change user clearance.

22. Validate the network (or provide needed information to a centralized
    validation application).

23. Recover from errors in administrative exchanges.

24. Guarantee delivery of administrative messages.

25. Know who I can talk to (other machines).

26. Not have to know other systems in order to initiate administrative
    actions (i.e. be able to work through another server to allow other
    systems at higher levels to be hidden).


TRUSTED ADMINISTRATION

"If I am a machine ..." list (continued)

27. Provide remote proedure API to local administrative functions.

28. Ensure unique user ID across arbitrarily large admininstrative domain.

29. Catch up if I am down when administrative changes occur.

30. "Self audit" to generate minimum number of audit records at the
    granularity of complete administrative actions.

31. Add a new remote host.



                            High          Low
Class        Must           Want          Want             Note 
----------   ------------   -----------   --------------   ----------------
Managed      1,2,3,4,7,9,   5,6,8,11,     8,11,13,14,      Depends on
Secure       11,12,13,14,   13,14,15,                      Policy (8, 11,
Node         18, 19,                                       13,14,

                                                           Not our job (17,

                                                           Killed (10,

Manager      16,

---------------------------                                     


TRUSTED ADMINISTRATION

Trusted Admin working group document history.

Document   Title
Number        (- history & distinquishing characteristics)
--------   --------------------------------------------------------------------
1.         The Need for SITP
              - 1 - 1/26/92 introduced to TSIG 1/28/92

2.         Audit Event Criteria
              - 1 - faxed to TSIG 1/28/92

3.         Security Information Transfer Protocol (SITP)
              - 1.0 - discussed at TSIG 1/29/92
              - 2.0 - added set functionality 4/92

4.         Host Audit Data Event Types and Formats
           (as defined by SAC)
              - 1 - faxed to TSIG 1/18/92

5.         What and When to Audit During Trusted Sessions
              - 1 - 1/28/92

6.         Audit Information Transfer Protocol (AITP)
              - 2.1 - formerly SITP, discussed at TSIG 7/14/92