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]