path: root/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt

INTERNET-DRAFT   Kerberized USM Keying    M. Thomas
                                          Cisco Systems
                                          K. McCloghrie
                                          Cisco Systems
                                          July 13, 2000






                         Kerberized USM Keying

                   draft-thomas-snmpv3-kerbusm-00.txt



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The KerbUSM MIB provides a means of leveraging a trusted third party
   authentication and authorization mechanism using Kerberos for SNMP V3
   USM users and their associated VACM views. The MIB encodes the normal
   Kerberos AP-REQ and AP-REP means of both authenticating and creating
   a shared secret between the SNMP V3 Manager and Agent.

The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:  An overall architecture, described in RFC 2571



Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 1]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


   [RFC2571].  Mechanisms for describing and naming objects and events
   for the purpose of management.  The first version of this Structure
   of Management Information (SMI) is called SMIv1 and described in STD
   16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
   [RFC1215].  The second version, called SMIv2, is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].  Message protocols for transferring management
   information.  The first version of the SNMP message protocol is
   called SNMPv1 and described in STD 15, RFC 1157 [RFC1157].  A second
   version of the SNMP message protocol, which is not an Internet
   standards track protocol, is called SNMPv2c and described in RFC 1901
   [RFC1901] and RFC 1906 [RFC1906].  The third version of the message
   protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC
   2572 [RFC2572] and RFC 2574 [RFC2574].  Protocol operations for
   accessing management information.  The first set of protocol
   operations and associated PDU formats is described in STD 15, RFC
   1157 [RFC1157].  A second set of protocol operations and associated
   PDU formats is described in RFC 1905 [RFC1905].  A set of fundamental
   applications described in RFC 2573 [RFC2573] and the view-based
   access control mechanism described in RFC 2575 [RFC2575].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [RFC2570].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64).  Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.


Introduction

   The User based Security Model of SNMP V3 (USM) [2] provides a means
   of associating different users with different access privileges of
   the various MIB's that an agent supports. In conjunction with the
   View based Access Control Model of SNMP V3 (VACM) [3], SNMP V3
   provides a means of providing resistance from various threats both
   from outside attacks such as spoofing, and inside attacks such as an
   user having, say, SET access to MIB variable for which they are not



Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 2]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


   authorized.

   SNMP V3, unfortunately, does not specify a means of doing key
   distribution between the managers and the agents. For small numbers
   of agents and managers, the O(n*m) manual keying is a cumbersome, but
   possibly tractable problem. For a large number of agents with
   distribution of managers, the key distribution quickly goes from
   cumbersome to unmanageable. Also: there is always the lingering
   concern of the security precautions taken for keys on either local
   management stations, or even directories.

   Kerberos [1] provides a means of centralizing key management into an
   authentication and authorization server known as a Key Distribution
   Center (KDC).  At a minimum, Kerberos changes the key distribution
   problem from a O(n*m) problem to a O(n) problem since keys are shared
   between the KDC and the Kerberos principals rather directly between
   each host pair. Kerberos also provides a means to use public key
   based authentication which can be used to further scale down the
   number of pre-shared secrets required. Furthermore, a KDC is intended
   and explicitly expected to be a standalone server which is managed
   with a much higher level of security concern than a management
   station or even a central directory which may host many services and
   thus be exposed to many more possible vectors of attack.

   The MIB defined in this memo describes a means of using the desirable
   properties of Kerberos within the context of SNMP V3. Kerberos
   defines a standardized means of communicating with the KDC as well as
   a standard format of Kerberos tickets which Kerberos principals
   exchange in order to authenticate to one another. The actual means of
   exchanging tickets, however, is left as application specific. This
   MIB defines the SNMP MIB designed to transport Kerberos tickets and
   by doing so set up SNMP V3 USM keys for authentication and privacy.

   It should be noted that using Kerberos does introduce reliance on a
   key network element, the KDC. This flies in the face of one of SNMP's
   dictums of working when the network is misbehaving. While this is a
   valid concern, the risk of reliance on the KDC can be significantly
   diminished with a few common sense actions. Since Kerberos tickets
   can have long life times (days, weeks) a manager of key network
   elements can and should maintain Kerberos tickets well ahead ticket
   expiration so that likelihood of not being able to rekey a session
   while the network is misbehaving is minimized. For non-critical, but
   high fanout elements such as user CPE, etc, requiring a pre-fetched
   ticket may not be practical, which puts the KDC into the critical
   path. However, if all KDC's are unreachable, the non-critical network
   elements are probably the least of the worries.





Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 3]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


Operation

   The normal Kerberos application ticket exchange is accomplished by  a
   client  first  fetching  a  service ticket from a KDC for the service
   principal and then sending an AP-REQ  to  a  server  to  authenticate
   itself  to  the  server. The server then sends a AP-REP to finish the
   exchange. This MIB maps Kerberos' concept of client and  server  into
   the  SNMP  V3  concept  of  Manager and Agent by designating that the
   Kerberos Client is the SNMP V3 Agent. Although  it  could  be  argued
   that an Agent is really a server, in practice there may be many, many
   agents and relatively few managers. Also: Kerberos clients  may  make
   use  of  public  key authentication as defined in [4], and it is very
   advantageous to take advantage of that capability for  Agents  rather
   than Managers.

   The MIB is intended to be stateless and map USM users to Kerberos
   principals. This mapping is explicitly done by putting a Kerberos
   principal name into the usmUserSecurityName in the usmUser MIB and
   instatiating the krbUsmMibEntry for the usmUserEntry. MIB variables
   are accessed with INFORM's or TRAP PDU's and SET's to perform a
   normal Kerberos AP-REQ/AP-REP exchange transaction which causes the
   keys for a USM user to be derived and installed. The basic structure
   of the MIB is a table which augements usmUserEntry's with a Kerberos
   principal name as well as the transaction varbinds. In the normal
   case, multiple varbinds should be sent in a single PDU which prevents
   various race conditions, as well as increasing efficiency.

   It should be noted that this MIB is silent on the subject of how the
   Agent and Manager find the KDC. In practice, this may be either
   statically provisioned or use either DNS SRV records (RFC 2782) or
   Service Location (RFC 2608). This MIB is does not provide for a means
   of doing cipher suite negotiation either. It is expected that the
   choices for ciphers in the USM MIB will reflect site specific choices
   for ciphers. This matches well with the general philosophy of
   centralized keying.

Keying Transactions

   The following shows an error free transaction:

   Note: optional steps or parameters are shown like [ ]










Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 4]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000



    Agent                       Manager                            KDC
 +--                                                               --+
 | 1) <-------------------------------                               |
 |     SET (krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx;      |
 |          [ krbUsmPrinTable[usmUserName].krbUsmMibTgt =            |
 |                                  TGT[usmUserSecurityName] ]);     |
 |                                                                   |
 | 2) ------------------------------->                               |
 |    Response                                                       |
 +--                     (optional)                                --+

   3) --------------------------------------------------------------->
        TGS-REQ (krbUsmPrinTable[usmUserName].krbUsmMibMgrPrinName
                 [, krbUsmPrinTable[usmUserName].krbUsmMibTgt]);

   4) <--------------------------------------------------------------
        Tick[usmUserSecurityName] = TGS-REP ();

   5)  ------------------------------>
        INFORM (krbUsmPrinTable[usmUserName].krbUsmMibApReq =
                   AP_REQ[Tick[usmUserSecurityName]];
                   [ krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx]);

   6)  <------------------------------
        SET (krbUsmPrinTable[usmUserName].krbUsmMibApRep = AP_REP[]);


   7)  ------------------------------>
       Response


   The above flow translates to:


   1)  This step is used when the Manager does not currently have a ses-
       sion with the Agent but wishes to start one. The Manager MAY
       place a ticket granting ticket into the krbUsmMibMgrTgt varbind
       in the same PDU as the krbUsmMibNonce if it does not share a
       secret with the KDC (as would be the case if the Manager used
       PKinit to do initial authentication with the KDC).


   2)  This step acknowledges the SET. There are no MIB specific errors
       which can happen here.


   3)  If the Agent is not already in possession of a service ticket for



Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 5]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


       the Manager in its ticket cache, it MUST request a service ticket
       from the Agent's KDC for the service principal given by
       krbUsmMibMgrPrinName in the row that the krbUsmMibNonce was SET
       in, optionally adding a krbUsmMibMgrTgt.  If the TGT is speci-
       fied, the Manager's TGT must be placed in the additional-tickets
       field with the ENC-TKT-IN-SKEY option set in the TGS-REQ to
       obtain a service ticket (see section 3.3.3 of [1]).

       Note:   a Kerberos TGS-REQ is but one way to obtain a service
               ticket. An Agent may use any normal Kerberos means to
               obtain the service ticket. This flow has also elided ini-
               tial authentication (ie, AS-REQ) and any cross realm con-
               siderations, though those may be necessary prerequisites
               to obtaining the service ticket.

   4)  If step 3 was performed, this step receives the ticket or an
       error from the KDC.


   5)  This step sends a krbUsmMibApReq to the Manager via an INFORM or
       TRAP PDU.  If the message is the result of a request by the
       Manager, krbUsmMibNonce received from the Manager MUST be sent in
       the same PDU. If the Manager did not initiate the transaction,
       the Agent MUST NOT send a krbUsmMibNonce varbind. The Agent also
       MUST check krbUsmMibUnsolicitedNotify is not false, otherwise it
       MUST abort the transaction.  All krbUsmMibApReq's MUST contain a
       sequence nonce so that the resulting krbUsmMibApRep can provide a
       proof of the freshness of the message to prevent replay attacks.

       If the Agent encounters an error either generated by the KDC or
       internally, the Agent MUST send an INFORM or TRAP PDU indicating
       the error in the form of a KRB-ERROR placed in krbUsmMibApReq
       with the same rules applied to krbUsmMibNonce and krbUsmMibUnsol-
       icitedNotify above. If the Agent suspects that it is being
       attacked by a purported Manager which is generating many failed
       TGS-REQ's to the KDC, it SHOULD meter its TGS-REQ transactions
       for that Manager to the KDC using an exponential backoff mechan-
       ism truncated at 10 seconds.



   6)  Upon recepit of an INFORM or TRAP PDU with a krbUsmMibApReq, a
       Manager may accept the AP-REQ. If it is accompanied with a
       krbUsmMibNonce it MUST correlate it with any outstanding transac-
       tions using its stored nonce for the transaction. If it does not
       correlate with a current nonce, the request MUST be rejected as
       it may be a replay.




Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 6]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


       If the Manager chooses to reject an unsolicited keying request,
       it SHOULD send a WrongValue Error to the Agent with the krbUsmMi-
       bApReq as the subject of the WrongValue. If an Agent receives a
       WrongValue Error from a Manager it MUST cease retransmission of
       the INFORM or TRAP PDU's so as to mitigate event avalanches by
       Agents. There is a possible denial of service attack here, but it
       must be weighed against the larger problem of network congestion,
       flapping, etc. Therefore, if the Agent finds that it cannot can-
       cel an unsolicited Notify (ie, it must be reliable), it MUST use
       a truncated exponential backoff mechanism with the maximum trun-
       cation interval set to 10 minutes.

       Otherwise, the Manager MUST send a SET PDU to the Agent which
       contains a krbUsmMibApRep.


   7)  If the Agent detects an error (including detecting replays) in
       the final AP-REP, it MUST send a WrongValue error with a pointer
       to the krbUsmMibApRep varbind to indicate its inability to estab-
       lish the security association. Otherwise, receipt of the positive
       acknowledgement from the final SET indicates to the Manager that
       the proper keys have been installed on the Agent in the USM MIB.

Unsolicited Agent Keying Requests

   An Agent may find that it needs to set up a security association for
   a USM user in order to notify a Manager of some event. When the Agent
   engine receives a request for a notify, it SHOULD check to see if
   keying material has been established for the user and that the keying
   material is valid. If the keying material is not valid and the USM
   user has been tagged as being a Kerberos principal in a realm, the
   Agent SHOULD first try to instantiate a security association by
   obtaining a service ticket for the USM User and follow steps 3-7 of
   the flow above. This insures that the USM User will have proper key-
   ing material and providing a mechanism to allow for casual security
   associations to be built up and torn down. This is especially useful
   for Agents which may not normally need to be under constant Manager
   supervision, such as the case with high fan out user residential CPE
   and other SNMP managed "appliances". In all cases, the Agent MUST NOT
   send an unsolicited Notify if krbUsmUnsolicitedNotify is set to
   false.

   How the Agent obtains the Manager's address, how it determines
   whether a Manager, realm, and whether it can be keyed using this MIB
   is outside of the scope of this memo.

   Note:   Although the MIB allows for a Manager to set up a session
           using User-User mode of Kerberos by sending a TGT along with



Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 7]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


           the nonce, this, is limited to Manager initiated sessions
           only since there is no easy way to store the Manager's ticket
           in the MIB since it is publicly writable and as such would be
           subject to denial of service attacks. Another method might be
           to have the Agent send a krbUsmMibNonce to the Manager which
           would tell it to instigate a session. Overall, it seems like
           a marginal feature to allow a PKinit authenticated user be
           the target of unsolicited informs and it would complicate the
           transactions. For this reason, this scenario has been omitted
           in favor of simplicity.

Retransmissions

   Since this MIB defines not only variables, but transactions, discus-
   sion of the retransmission state machine is in order. There are two
   similar but different state machines for the Manager Solicited and
   Agent Unsolicited transactions.  There is one timer Timeout which
   SHOULD take into consideration round trip considerations and MUST
   implement a truncated exponential backoff mechanism. In addition, in
   the case where an Agent makes an unsolicited Agent keying request,
   the Agent SHOULD perform an initial random backoff if the keying
   request to the Manager may result in a restart avalanche. A suitable
   method is described in section 4.3.4 of [5].




























Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 8]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000



Manager Solicited Retransmission State Machine

                Timeout
                 +---+
                 |   |
                 |   V
              +-----------+ Set-Ack (2) +----------+
              |           |------------>|          |
              | Set-Nonce |             |  Ap-Req  |
              |   (1)     |<------------|   (5)    |
              +-----------+   Timeout   +----------+
                   ^                         |
                   |                         | Set-Ap-Rep
                   |      +----------+       |  (6)
                   +------|          |<------+
                  Timeout | Estab-wt |
                          |   (7)    |
                          +----------+
                               |
                               |  Set-Ap-Rep-Ack (7)
                               V
                          +----------+
                          |          |
                          |  Estab   |
                          |          |

                          +----------+























Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 9]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000



Agent Unsolicited Retransmission State Machine

                             Timeout
                              +---+
                              |   |
                              |   V
                          +----------+
                          |          |
                   +----> |  Ap-Req  |-------+
                   |      |   (5)    |       |
                   |      +----------+       |
                   |                         |
                   |                         | Set-Ap-Rep
                   |      +----------+       |  (6)
                   +------|          |<------+
                  Timeout | Estab-wt |
                          |   (7)    |
                          +----------+
                               |
                               |  Set-Ap-Rep-Ack (7)
                               V
                          +----------+
                          |          |
                          |  Estab   |
                          |          |
                          +----------+

Session Duration and Failures

   The KerbUsmMib uses the ticket lifetime to determine the life of the
   USM session. The Agent MUST keep track of whether the ticket which
   instigated the session is valid whenever it forms PDU's for that par-
   ticular user. If a session expires, or if it wasn't valid to begin
   with (from the Agent's perspective), the Agent MUST reject the PDU by
   sending a XXX Error [mat: help me here Keith... what does USM say
   about this?].

   Kerberos also inherently implies adding state to the Agent and
   Manager since they share not only a key, but a lifetime associated
   with that key. This is in some sense soft state because failure of an
   Agent will cause it to reject PDU's for Managers with whom it does
   not share a secret. The Manager can use the Error PDU's as an indica-
   tion that it needs to reauthenticate with the Agent, taking care not
   to loop. The Manager is even easier: when it reboots, it can either
   check its credential cache to reconstruct state or cause the Agent to
   reauthenticate to the Manager with its service ticket by initiating a
   authentication transaction with the manager.



Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 10]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


Manager Collisions

   Managers may freely set up keys for different USM users using this
   MIB without problem since they access different rows in the krbUsm-
   PrinTable. However, multiple Managers trying to set up keys for the
   same USM user is possible but discouraged. The requirement for the
   Manager is that they MUST share the same service key with the KDC so
   that they can all decrypt the same service ticket. There are two race
   conditions, however, which are not well handled:



1)  At the end of a ticket lifetime, one manager may request the agent
    to refresh its service ticket causing a new session key to be
    installed for the USM user leaving the other managers with stale
    keys. The workaround here is that the Agent will reject the stale
    manager's PDU's which should inform them to do their own rekeying
    operations.


2)  If multiple managers try to access the same row at the same time,
    the Agent SHOULD try to keep the transactions separate based on the
    nonce values. The Managers or the Agents SHOULD NOT break the
    krbUsmMibNonce and any other additional varbinds into separate PDU's
    as this may result in a meta stable state. Given normal MTU sizes,
    this should not be an issue in practice, and this should  at worst
    devolve into the case above.

   In all cases, the krbUsmMibNonce MUST be the last value to be
   transmitted, though its position within a PDU is unimportant.





















Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 11]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000



   KrbUSM MIB

   KRB-USM-MIB DEFINITIONS ::= BEGIN
   IMPORTS
       MODULE-IDENTITY,
       OBJECT-TYPE, OBJECT-IDENTITY,
       snmpModules, Counter32, Unsigned32 FROM SNMPv2-SMI
       TruthValue, DisplayString          FROM SNMPv2-TC
       usmUserEntry                       FROM SNMP-USER-BASED-SM-MIB



   krbUsmMib MODULE-IDENTITY
           LAST-UPDATED "00071300Z"
           ORGANIZATION "IETF SNMP V3 Working Group"
           CONTACT-INFO
             "Michael Thomas
              Cisco Systems
              375 E Tasman Drive
              San Jose, Ca 95134
              Phone: +1 408-525-5386
              Fax: +1 801-382-5284
              email: mat@cisco.com"
           DESCRIPTION
              "This MIB contains the MIB variables to
               exchange Kerberos credentials and a session
               key to be used to authenticate and set up
               USM keys"

           ::= { snmpModules nnn }   -- not sure what needs to be here.
   krbUsmMibObjects OBJECT INDENTIFIER ::= { krbUsmMib 1 }

   krbUsmMibAuthInAttemps
               SYNTAX      Counter32
               MAX-ACCESS  read-only
               STATUS      current
               DESCRIPTION
                   "Counter of the number of Kerberos
                    authorization attempts as defined by
                    receipt of a PDU from a Manager with a
                     krbUsmMibNonce set in the principal table."
               ::= { krbUsmMibObjects 1 }

   krbUsmMibAuthOutAttemps
               SYNTAX      Counter32
               MAX-ACCESS  read-only
               STATUS      current



Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 12]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


               DESCRIPTION
                   "Counter of the number of unsolicited Kerberos
                    authorization attempts as defined by
                    an Agent sending an INFORM or TRAP PDU with a
                    krbUsmMibApRep but without krbUsmApMibNonce
                    varbind."
               ::= { krbUsmMibObjects 2 }
   krbUsmMibAuthInFail
               SYNTAX      Counter32
               MAX-ACCESS  read-only
               STATUS      current
               DESCRIPTION
                   "Counter of the number of Kerberos
                    authorization failures as defined by
                    a Manager setting the krbUsmMibNonce
                    in the principal table which results
                    in some sort of failure to install keys
                    in the requested USM user entry."
               ::= { krbUsmMibObjects 3 }

   krbUsmMibAuthOutFail
               SYNTAX      Counter32
               MAX-ACCESS  read-only
               STATUS      current
               DESCRIPTION
                   "Counter of the number of unsolicited Kerberos
                    authorization failures as defined by
                    an Agent sending an INFORM or TRAP PDU with a
                    krbUsmMibApRep but without a krbUsmMibNonce
                    varbind which does not result in keys being
                    installed for that USM user entry."
               ::= { krbUsmMibObjects 4 }

   krbUsmMibPrinTable OBJECT-TYPE
               SYNTAX      SEQUENCE OF krbUsmMibEntry
               MAX-ACCESS  not-accessible
               STATUS      current
               DESCRIPTION
                   "Table which maps Kerberos principals with USM
                    users as well as the per user variables to key
                    up sessions"
               ::= { krbUsmMibObjects 5 }

   krbUsmMibPrinEntry OBJECT-TYPE
               SYNTAX     KrbUsmMibPrinEntry
               MAX-ACCESS  not-accessible
               STATUS      current
               DESCRIPTION



Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 13]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


                   "an entry into the krbMibPrinTable which is a
                    parallel table to UsmUserEntry table"
               AUGMENTS { usmUserEntry }
               ::= { krbUsmMibPrinTable 1 }

   KrbUsmMibPrinEntry SEQUENCE
    {
                   krbUsmMibApReq                  OCTET STRING,
                   krbUsmMibApRep                  OCTET STRING,
                   krbUsmMibNonce                  OCTET STRING,
                   krbUsmMibMgrTGT                 OCTET STRING,
                   krbUsmMibUnsolicitedNotify      TruthValue,
    }


   krbUsmMibApReq OBJECT-TYPE
               SYNTAX      OCTET STRING
               MAX-ACCESS  accessible-for-notify
               STATUS      current
               DESCRIPTION
                   "This variable contains a DER encoded Kerberos
                    AP-REQ or KRB-ERROR for the USM user which is
                    to be keyed. This is sent from the Agent to
                    the Manager in an INFORM or TRAP request.
                    KRB-ERROR MUST only be sent to the Manager
                    if it is in response to a keying request from
                    the Manager.
                   "
               ::= { krbUsmMibPrinEntry 1 }

   krbUsmMibApRep OBJECT-TYPE
               SYNTAX      OCTET STRING
               MAX-ACCESS  read-write
               STATUS      current
               DESCRIPTION
                   "This variable contains the DER encoded response
                    to an AP-REQ. This variable is SET by the
                    Manager to acknowledge receipt of an AP-REQ. If
                    krbUsmMibApRep contains a Kerberos AP-REP, the
                    Agent must derive keys from the session key
                    of the Kerberos ticket in the AP-REQ and place
                    them in the USM database in a manner specified
                    by [RFC2574]. If the Manager detects an error,
                    it will instead place a KRB-ERROR in this
                    variable to inform the Agent of the error.

                    This variable is in effect a write-only variable.
                    attempts to read this variable will result in a



Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 14]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


                    null octet string being returned"
               ::= { krbUsmMibPrinEntry 2 }

   krbUsmMibNonce OBJECT-TYPE
               SYNTAX      OCTET STRING
               MAX-ACCESS  read-write
               STATUS      current
               DESCRIPTION
                   "SET'ing a krbUsmMibnonce allows a Manager to
                    determine whether an INFORM or TRAP from an
                    Agent is an outstanding keying request, or
                    unsolicited from the Agent. The Manager
                    initiates keying for a particular USM user
                    by writing a nonce into the row for which
                    desires to establish a security association.
                    The nonce is an ASCII string of the form
                    ``host:port?nonce'' where:

                    host:  is either an FQDN, or valid ipv4 or ipv6
                           numerical notation of the Manager which
                           desires to initiate keying
                    port:  is the destination port at which that the
                           Manager may be contacted
                    nonce: is a number generated by the Manager to
                           correlate the transaction

                    The same nonce MUST be sent to the Manager in a
                    subsequent INFORM or TRAP with a krbUsmApReq.
                    The Agent MUST use the host address and port
                    supplied in the nonce as the destination of a
                    subsequent INFORM or TRAP. Unsolicited keying
                    requests MUST NOT contain a nonce, and should
                    instead use the destination stored Notifies of
                    this type.

                    Nonces MUST be highly collision resistant either
                    using a time based method or a suitable random
                    number generator. Managers MUST never create
                    nonces which are 0.

                    This variable is in effect a write-only variable.
                    Attempts to read this variable will result in a
                    nonce of value 0 being returned"


               ::= { krbUsmMibPrinEntry 3 }





Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 15]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


   krbUsmMibMgrTgt OBJECT-TYPE
               SYNTAX      OCTET STRING
               MAX-ACCESS  read-write
               STATUS      current
               DESCRIPTION
                   "If the Manager does not possess a symmetric
                    key with the KDC as would be the case with
                    a Manager using PKinit for authentication,
                    the Manager MUST SET its DER encoded ticket
                    granting ticket into KrbUsmMgrTgt along
                    with krbUsmMibNonce.

                    The agent will then attach the Manager's TGT
                    into the additional tickets field of the
                    TGS-REQ message to the KDC to get a User-User
                    service ticket.

                    This variable is in effect a write-only variable.
                    Attempts to read this variable will result in a
                    null octet string being returned"
               ::= { krbUsmMibPrinEntry 4 }


   krbUsmMibUnsolicitedNotify OBJECT-TYPE
               SYNTAX      TruthValue
               MAX-ACCESS  read-write
               STATUS      current
               DESCRIPTION
                   "If this variable is false, the Agent MUST NOT
                    send unsolicited INFORM or TRAP PDU's to the
                    Manager.

                    Attempts to SET this variable by the no-auth
                    no-priv user MUST be rejected."
               ::= { krbUsmMibPrinEntry 5 }

   --
   -- Conformance section... nothing optional.

   krbUsmMibCompliences MODULE-COMPLIANCE
               STATUS       current
               DESCRIPTION "The compliance statement for SNMP
                            engines whichimplement the KRB-USM-MIB
                   "
               MODULE       -- this module
                       MANDATORY-GROUPS { krbUsmMib }
       ::= { krbUsmMibCompliances 1 }




Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 16]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


   END


Key Derivation

   The session key provides the basis for the keying material for the
   USM user specified in the AP-REQ.  The actual keys for use for the
   authentication and privacy are produced using the cryptographic hash-
   ing function used to protect the ticket itself.  The keying material
   is derived using this function, F(key, salt), using successive
   interations of F over the salt string "SNMPV3RULZ%d", where %d is a
   monotonic counter starting at zero. The bits are taken directly from
   the successive interations to produce two keys of appropriate size
   (as specified in the USM user row) for the authentication transform
   first, and the privacy transform second. If the authentication
   transform is null, the first bits of the derived key are used for the
   privacy transform.

Security Considerations

   Various elements of this MIB must be readable and writable as the
   no-auth, no-priv user. Unless specifically necessary for the key
   negotiation, elements of this MIB SHOULD be protected by VACM views
   which limit access. In particular, there is no reason anything in
   this MIB should be visible to a no-auth, no-priv user with the excep-
   tion of KrbUsmMibApReq, KrbUsmMibApRep, KrbUsmMibNonce, and
   KrbUsmMibMgrTgt, and then only with the restrictions placed on them
   in the MIB. As such, probing attacks are still possible, but should
   not be profitable: all of the writable variables with interesting
   information in them are defined in such a way as to be write only.

   There are some interesting denial of service attacks which are possi-
   ble by attackers spoofing managers and putting load on the KDC to
   generate unnecessary tickets. For large numbers or agents this could
   be problematic. This can probably be mitigated by the KDC prioritiz-
   ing TGS-REQ's though.


References

[1]         The CAT Working Group,  J.  Kohl,  C.Neuman,  "The  Kerberos
            Network  Authentication  Service  (V5)", RFC 1510, September
            1993

[2]         The SNMPV3 Working Group, U.  Blumenthal,  B.  Wijnen,  "The
            User-based Security Model of SNMP V3", RFC 2574, April 1999

[3]         The SNMPV3 Working Group, B. Wijnen, R. Presuhn,



Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 17]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


            K.McCloghrie, "The View-based Access Control Model of SNMP
            V3", RFC 2575, April 1999

[4]         The CAT Working Group, Tung, et al, "Public Key Cryptography
            for Initial Authentication in Kerberos", draft-ietf-cat-pk-
            init-11, November 1999

[5]         Arango, et al, "Media Gateway Control Protocl (MGCP)", RFC
            2705, October 1999


[RFC2571]   Harrington, D., Presuhn, R., and B. Wijnen, An Architecture
            for Describing SNMP Management Frameworks, RFC 2571, April
            1999.

[RFC1155]   Rose, M., and K. McCloghrie, Structure and Identification of
            Management Information for TCP/IP-based Internets, STD 16,
            RFC 1155, May 1990.

[RFC1212]   Rose, M., and K. McCloghrie, Concise MIB Definitions, STD
            16, RFC 1212, March 1991.

[RFC1215]   M. Rose, A Convention for Defining Traps for use with the
            SNMP, RFC 1215, March 1991.

[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, Structure of Management Infor-
            mation Version 2 (SMIv2), STD 58, RFC 2578, April 1999.

[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, Textual Conventions for SMIv2,
            STD 58, RFC 2579, April 1999.

[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, Conformance Statements for
            SMIv2, STD 58, RFC 2580, April 1999.

[RFC1157]   Case, J., Fedor, M., Schoffstall, M., and J. Davin, Simple
            Network Management Protocol, STD 15, RFC 1157, May 1990.

[RFC1901]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
            Introduction to Community-based SNMPv2, RFC 1901, January
            1996.

[RFC1906]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Tran-
            sport Mappings for Version 2 of the Simple Network Manage-
            ment Protocol (SNMPv2), RFC 1906, January 1996.




Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 18]





INTERNET-DRAFT           Kerberized USM Keying              13 July 2000


[RFC2572]   Case, J., Harrington D., Presuhn R., and B. Wijnen, Message
            Processing and Dispatching for the Simple Network Management
            Protocol (SNMP), RFC 2572, April 1999.

[RFC2574]   Blumenthal, U., and B. Wijnen, User-based Security Model
            (USM) for version 3 of the Simple Network Management Proto-
            col (SNMPv3), RFC 2574, April 1999.

[RFC1905]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Pro-
            tocol Operations for Version 2 of the Simple Network Manage-
            ment Protocol (SNMPv2), RFC 1905, January 1996.

[RFC2573]   Levi, D., Meyer, P., and B. Stewart, SNMPv3 Applications,
            RFC 2573, April 1999.

[RFC2575]   Wijnen, B., Presuhn, R., and K. McCloghrie, View-based
            Access Control Model (VACM) for the Simple Network Manage-
            ment Protocol (SNMP), RFC 2575, April 1999.

[RFC2570]   Case, J., Mundy, R., Partain, D., and B. Stewart, Introduc-
            tion to Version 3 of the Internet-standard Network Manage-
            ment Framework, RFC 2570, April 1999.

Author's Address

          Michael Thomas
          Cisco Systems
          375 E Tasman Rd
          San Jose, Ca, 95134, USA
          Tel: +1 408-525-5386
          email: mat@cisco.com




















Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 19]