User-Based Security Model
   
   
   
                   A  Proposal from
     
            K. McCloghrie, M. Rose, G. Waters
   
   
========
   
                      Rationale
   
   - Any Security Model must have some "identity"
     which is authenticated and given access rights
   
   - May 31st I-D's had both parties and users
   
   - Having 2 methods with same/similar functionality
     was wrong
   
========
   
           McCloghrie/Rose/Waters Proposal
   
   
   Replaces:   Admin, Security, BCM, SCM, Party-MIB
   
   By 2 documents, with a 3rd to come
   
   plus minor updates to other documents to fix
   references
   
========
   
                 New Documents
   
   Admin framework
      - contexts and views, but NO parties
      - allows multiple Security Models
   
   User-Based Security Model
      - "user"s are authenticated/have access rights
      - every message is sent on behalf of a user
      - defines MD5 and DES algorithms, allows others
   
   (Future) User-Based Security Model Remote Config MIB
      - important
      - timely resolution needed
      - but not a reason to hold up other documents
   
========
   
                  Differences
   
   - users & contexts named by strings
   - some contexts have unique names within admin
     domain,
     some have same "selector" on each agent
   - qoS: noAuth/noPriv, auth/noPriv, or auth/priv
        - all types can be sent on behalf of a user
        - user is roughly equivalent to 6 parties
   - operator chooses if user has same secrets on
     each agent
   - secrets can be generated from passwords
   - simple installation parameters
   
========
   
                    Clocks
   
   - each agent has one (and only one) clock
       (agentTime = # of seconds since reboot)
   - clock used in conjunction with agentBoots
       (agentBoots = # of times rebooted)
   - only agentBoots is non-volatile
       - no requirement for NV-clock/periodic
         write to NV-storage
   - clock never advances faster than real-time
       - deterministic roll-over
         (60+ years or 4B reboots)
   - requires agentID in headers to prevent replay
   
========
   
                Message Format
   
    
   Message ::=
       SEQUENCE {
           version      INTEGER { v2 (2) },
           parameters   OCTET STRING,
           data
                  CHOICE {
                      plaintext   PDUs,
                      encrypted   OCTET STRING
                  }
       }
   
========
   
   'parameters' field is a concatenation of:
   
         <model=0><qoS><agentID><agentBoots><agentTime>
         <userLen><userName><authLen><authDigest>
         <maxSize><contextSelector>
   
   qoS =  bitnumber
          7654 3210     meaning
          ---- ----     -----------------------------
          .... ..00     no authentication nor privacy
          .... ..01     authentication, no privacy
          .... ..1.     authentication and privacy
          1... ....     maintenance function
   
========
   
      Compatibility with SNMPv1 Community Profiles
   
   For agents which don't implement security,
   and are configured via SNMPv1 community profiles:
   
   with:
            qoS=0, contextSelector is zero-length
   
   then:
            user is mapped to community-string
   
========
   
                   USEC MIB
   
   - MIB defined for
   
       - agentID, agentTime, agentBoots, agentSize
   
       - stats counters (used in Report-PDUs)
   
========
   
               Implementations
   
   Two implementations (at present):
   
      - a GUI-based manager (snmptcl)
   
      - an upgraded CMU-based agent
   
      - command-line manager tools
   
   They have interoperated.