| blob | 68c170b499ed439927c14badd9a58b4ae87809fa |
7 INTERNET-DRAFT Kerberized USM Keying M. Thomas
8 Cisco Systems
9 K. McCloghrie
10 Cisco Systems
11 July 13, 2000
18 Kerberized USM Keying
20 draft-thomas-snmpv3-kerbusm-00.txt
24 Status of this Memo
26 This document is an Internet-Draft and is in full conformance with
27 all provisions of Section 10 of RFC2026. Internet-Drafts are working
28 documents of the Internet Engineering Task Force (IETF), its areas,
29 and its working groups. Note that other groups may also distribute
30 working documents as Internet-Drafts.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 The list of current Internet-Drafts can be accessed at
38 http://www.ietf.org/ietf/1id-abstracts.txt
40 The list of Internet-Draft Shadow Directories can be accessed at
41 http://www.ietf.org/shadow.html.
43 Abstract
45 The KerbUSM MIB provides a means of leveraging a trusted third party
46 authentication and authorization mechanism using Kerberos for SNMP V3
47 USM users and their associated VACM views. The MIB encodes the normal
48 Kerberos AP-REQ and AP-REP means of both authenticating and creating
49 a shared secret between the SNMP V3 Manager and Agent.
51 The SNMP Management Framework
53 The SNMP Management Framework presently consists of five major
54 components: An overall architecture, described in RFC 2571
58 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 1]
64 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
67 [RFC2571]. Mechanisms for describing and naming objects and events
68 for the purpose of management. The first version of this Structure
69 of Management Information (SMI) is called SMIv1 and described in STD
70 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
71 [RFC1215]. The second version, called SMIv2, is described in STD 58,
72 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
73 [RFC2580]. Message protocols for transferring management
74 information. The first version of the SNMP message protocol is
75 called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second
76 version of the SNMP message protocol, which is not an Internet
77 standards track protocol, is called SNMPv2c and described in RFC 1901
78 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message
79 protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC
80 2572 [RFC2572] and RFC 2574 [RFC2574]. Protocol operations for
81 accessing management information. The first set of protocol
82 operations and associated PDU formats is described in STD 15, RFC
83 1157 [RFC1157]. A second set of protocol operations and associated
84 PDU formats is described in RFC 1905 [RFC1905]. A set of fundamental
85 applications described in RFC 2573 [RFC2573] and the view-based
86 access control mechanism described in RFC 2575 [RFC2575].
88 A more detailed introduction to the current SNMP Management Framework
89 can be found in RFC 2570 [RFC2570].
91 Managed objects are accessed via a virtual information store, termed
92 the Management Information Base or MIB. Objects in the MIB are
93 defined using the mechanisms defined in the SMI.
95 This memo specifies a MIB module that is compliant to the SMIv2. A
96 MIB conforming to the SMIv1 can be produced through the appropriate
97 translations. The resulting translated MIB must be semantically
98 equivalent, except where objects or events are omitted because no
99 translation is possible (use of Counter64). Some machine readable
100 information in SMIv2 will be converted into textual descriptions in
101 SMIv1 during the translation process. However, this loss of machine
102 readable information is not considered to change the semantics of the
103 MIB.
106 Introduction
108 The User based Security Model of SNMP V3 (USM) [2] provides a means
109 of associating different users with different access privileges of
110 the various MIB's that an agent supports. In conjunction with the
111 View based Access Control Model of SNMP V3 (VACM) [3], SNMP V3
112 provides a means of providing resistance from various threats both
113 from outside attacks such as spoofing, and inside attacks such as an
114 user having, say, SET access to MIB variable for which they are not
118 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 2]
124 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
127 authorized.
129 SNMP V3, unfortunately, does not specify a means of doing key
130 distribution between the managers and the agents. For small numbers
131 of agents and managers, the O(n*m) manual keying is a cumbersome, but
132 possibly tractable problem. For a large number of agents with
133 distribution of managers, the key distribution quickly goes from
134 cumbersome to unmanageable. Also: there is always the lingering
135 concern of the security precautions taken for keys on either local
136 management stations, or even directories.
138 Kerberos [1] provides a means of centralizing key management into an
139 authentication and authorization server known as a Key Distribution
140 Center (KDC). At a minimum, Kerberos changes the key distribution
141 problem from a O(n*m) problem to a O(n) problem since keys are shared
142 between the KDC and the Kerberos principals rather directly between
143 each host pair. Kerberos also provides a means to use public key
144 based authentication which can be used to further scale down the
145 number of pre-shared secrets required. Furthermore, a KDC is intended
146 and explicitly expected to be a standalone server which is managed
147 with a much higher level of security concern than a management
148 station or even a central directory which may host many services and
149 thus be exposed to many more possible vectors of attack.
151 The MIB defined in this memo describes a means of using the desirable
152 properties of Kerberos within the context of SNMP V3. Kerberos
153 defines a standardized means of communicating with the KDC as well as
154 a standard format of Kerberos tickets which Kerberos principals
155 exchange in order to authenticate to one another. The actual means of
156 exchanging tickets, however, is left as application specific. This
157 MIB defines the SNMP MIB designed to transport Kerberos tickets and
158 by doing so set up SNMP V3 USM keys for authentication and privacy.
160 It should be noted that using Kerberos does introduce reliance on a
161 key network element, the KDC. This flies in the face of one of SNMP's
162 dictums of working when the network is misbehaving. While this is a
163 valid concern, the risk of reliance on the KDC can be significantly
164 diminished with a few common sense actions. Since Kerberos tickets
165 can have long life times (days, weeks) a manager of key network
166 elements can and should maintain Kerberos tickets well ahead ticket
167 expiration so that likelihood of not being able to rekey a session
168 while the network is misbehaving is minimized. For non-critical, but
169 high fanout elements such as user CPE, etc, requiring a pre-fetched
170 ticket may not be practical, which puts the KDC into the critical
171 path. However, if all KDC's are unreachable, the non-critical network
172 elements are probably the least of the worries.
178 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 3]
184 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
187 Operation
189 The normal Kerberos application ticket exchange is accomplished by a
190 client first fetching a service ticket from a KDC for the service
191 principal and then sending an AP-REQ to a server to authenticate
192 itself to the server. The server then sends a AP-REP to finish the
193 exchange. This MIB maps Kerberos' concept of client and server into
194 the SNMP V3 concept of Manager and Agent by designating that the
195 Kerberos Client is the SNMP V3 Agent. Although it could be argued
196 that an Agent is really a server, in practice there may be many, many
197 agents and relatively few managers. Also: Kerberos clients may make
198 use of public key authentication as defined in [4], and it is very
199 advantageous to take advantage of that capability for Agents rather
200 than Managers.
202 The MIB is intended to be stateless and map USM users to Kerberos
203 principals. This mapping is explicitly done by putting a Kerberos
204 principal name into the usmUserSecurityName in the usmUser MIB and
205 instatiating the krbUsmMibEntry for the usmUserEntry. MIB variables
206 are accessed with INFORM's or TRAP PDU's and SET's to perform a
207 normal Kerberos AP-REQ/AP-REP exchange transaction which causes the
208 keys for a USM user to be derived and installed. The basic structure
209 of the MIB is a table which augements usmUserEntry's with a Kerberos
210 principal name as well as the transaction varbinds. In the normal
211 case, multiple varbinds should be sent in a single PDU which prevents
212 various race conditions, as well as increasing efficiency.
214 It should be noted that this MIB is silent on the subject of how the
215 Agent and Manager find the KDC. In practice, this may be either
216 statically provisioned or use either DNS SRV records (RFC 2782) or
217 Service Location (RFC 2608). This MIB is does not provide for a means
218 of doing cipher suite negotiation either. It is expected that the
219 choices for ciphers in the USM MIB will reflect site specific choices
220 for ciphers. This matches well with the general philosophy of
221 centralized keying.
223 Keying Transactions
225 The following shows an error free transaction:
227 Note: optional steps or parameters are shown like [ ]
238 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 4]
244 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
248 Agent Manager KDC
249 +-- --+
250 | 1) <------------------------------- |
251 | SET (krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx; |
252 | [ krbUsmPrinTable[usmUserName].krbUsmMibTgt = |
253 | TGT[usmUserSecurityName] ]); |
254 | |
255 | 2) -------------------------------> |
256 | Response |
257 +-- (optional) --+
259 3) --------------------------------------------------------------->
260 TGS-REQ (krbUsmPrinTable[usmUserName].krbUsmMibMgrPrinName
261 [, krbUsmPrinTable[usmUserName].krbUsmMibTgt]);
263 4) <--------------------------------------------------------------
264 Tick[usmUserSecurityName] = TGS-REP ();
266 5) ------------------------------>
267 INFORM (krbUsmPrinTable[usmUserName].krbUsmMibApReq =
268 AP_REQ[Tick[usmUserSecurityName]];
269 [ krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx]);
271 6) <------------------------------
272 SET (krbUsmPrinTable[usmUserName].krbUsmMibApRep = AP_REP[]);
275 7) ------------------------------>
276 Response
279 The above flow translates to:
282 1) This step is used when the Manager does not currently have a ses-
283 sion with the Agent but wishes to start one. The Manager MAY
284 place a ticket granting ticket into the krbUsmMibMgrTgt varbind
285 in the same PDU as the krbUsmMibNonce if it does not share a
286 secret with the KDC (as would be the case if the Manager used
287 PKinit to do initial authentication with the KDC).
290 2) This step acknowledges the SET. There are no MIB specific errors
291 which can happen here.
294 3) If the Agent is not already in possession of a service ticket for
298 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 5]
304 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
307 the Manager in its ticket cache, it MUST request a service ticket
308 from the Agent's KDC for the service principal given by
309 krbUsmMibMgrPrinName in the row that the krbUsmMibNonce was SET
310 in, optionally adding a krbUsmMibMgrTgt. If the TGT is speci-
311 fied, the Manager's TGT must be placed in the additional-tickets
312 field with the ENC-TKT-IN-SKEY option set in the TGS-REQ to
313 obtain a service ticket (see section 3.3.3 of [1]).
315 Note: a Kerberos TGS-REQ is but one way to obtain a service
316 ticket. An Agent may use any normal Kerberos means to
317 obtain the service ticket. This flow has also elided ini-
318 tial authentication (ie, AS-REQ) and any cross realm con-
319 siderations, though those may be necessary prerequisites
320 to obtaining the service ticket.
322 4) If step 3 was performed, this step receives the ticket or an
323 error from the KDC.
326 5) This step sends a krbUsmMibApReq to the Manager via an INFORM or
327 TRAP PDU. If the message is the result of a request by the
328 Manager, krbUsmMibNonce received from the Manager MUST be sent in
329 the same PDU. If the Manager did not initiate the transaction,
330 the Agent MUST NOT send a krbUsmMibNonce varbind. The Agent also
331 MUST check krbUsmMibUnsolicitedNotify is not false, otherwise it
332 MUST abort the transaction. All krbUsmMibApReq's MUST contain a
333 sequence nonce so that the resulting krbUsmMibApRep can provide a
334 proof of the freshness of the message to prevent replay attacks.
336 If the Agent encounters an error either generated by the KDC or
337 internally, the Agent MUST send an INFORM or TRAP PDU indicating
338 the error in the form of a KRB-ERROR placed in krbUsmMibApReq
339 with the same rules applied to krbUsmMibNonce and krbUsmMibUnsol-
340 icitedNotify above. If the Agent suspects that it is being
341 attacked by a purported Manager which is generating many failed
342 TGS-REQ's to the KDC, it SHOULD meter its TGS-REQ transactions
343 for that Manager to the KDC using an exponential backoff mechan-
344 ism truncated at 10 seconds.
348 6) Upon recepit of an INFORM or TRAP PDU with a krbUsmMibApReq, a
349 Manager may accept the AP-REQ. If it is accompanied with a
350 krbUsmMibNonce it MUST correlate it with any outstanding transac-
351 tions using its stored nonce for the transaction. If it does not
352 correlate with a current nonce, the request MUST be rejected as
353 it may be a replay.
358 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 6]
364 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
367 If the Manager chooses to reject an unsolicited keying request,
368 it SHOULD send a WrongValue Error to the Agent with the krbUsmMi-
369 bApReq as the subject of the WrongValue. If an Agent receives a
370 WrongValue Error from a Manager it MUST cease retransmission of
371 the INFORM or TRAP PDU's so as to mitigate event avalanches by
372 Agents. There is a possible denial of service attack here, but it
373 must be weighed against the larger problem of network congestion,
374 flapping, etc. Therefore, if the Agent finds that it cannot can-
375 cel an unsolicited Notify (ie, it must be reliable), it MUST use
376 a truncated exponential backoff mechanism with the maximum trun-
377 cation interval set to 10 minutes.
379 Otherwise, the Manager MUST send a SET PDU to the Agent which
380 contains a krbUsmMibApRep.
383 7) If the Agent detects an error (including detecting replays) in
384 the final AP-REP, it MUST send a WrongValue error with a pointer
385 to the krbUsmMibApRep varbind to indicate its inability to estab-
386 lish the security association. Otherwise, receipt of the positive
387 acknowledgement from the final SET indicates to the Manager that
388 the proper keys have been installed on the Agent in the USM MIB.
390 Unsolicited Agent Keying Requests
392 An Agent may find that it needs to set up a security association for
393 a USM user in order to notify a Manager of some event. When the Agent
394 engine receives a request for a notify, it SHOULD check to see if
395 keying material has been established for the user and that the keying
396 material is valid. If the keying material is not valid and the USM
397 user has been tagged as being a Kerberos principal in a realm, the
398 Agent SHOULD first try to instantiate a security association by
399 obtaining a service ticket for the USM User and follow steps 3-7 of
400 the flow above. This insures that the USM User will have proper key-
401 ing material and providing a mechanism to allow for casual security
402 associations to be built up and torn down. This is especially useful
403 for Agents which may not normally need to be under constant Manager
404 supervision, such as the case with high fan out user residential CPE
405 and other SNMP managed "appliances". In all cases, the Agent MUST NOT
406 send an unsolicited Notify if krbUsmUnsolicitedNotify is set to
407 false.
409 How the Agent obtains the Manager's address, how it determines
410 whether a Manager, realm, and whether it can be keyed using this MIB
411 is outside of the scope of this memo.
413 Note: Although the MIB allows for a Manager to set up a session
414 using User-User mode of Kerberos by sending a TGT along with
418 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 7]
424 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
427 the nonce, this, is limited to Manager initiated sessions
428 only since there is no easy way to store the Manager's ticket
429 in the MIB since it is publicly writable and as such would be
430 subject to denial of service attacks. Another method might be
431 to have the Agent send a krbUsmMibNonce to the Manager which
432 would tell it to instigate a session. Overall, it seems like
433 a marginal feature to allow a PKinit authenticated user be
434 the target of unsolicited informs and it would complicate the
435 transactions. For this reason, this scenario has been omitted
436 in favor of simplicity.
438 Retransmissions
440 Since this MIB defines not only variables, but transactions, discus-
441 sion of the retransmission state machine is in order. There are two
442 similar but different state machines for the Manager Solicited and
443 Agent Unsolicited transactions. There is one timer Timeout which
444 SHOULD take into consideration round trip considerations and MUST
445 implement a truncated exponential backoff mechanism. In addition, in
446 the case where an Agent makes an unsolicited Agent keying request,
447 the Agent SHOULD perform an initial random backoff if the keying
448 request to the Manager may result in a restart avalanche. A suitable
449 method is described in section 4.3.4 of [5].
478 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 8]
484 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
488 Manager Solicited Retransmission State Machine
490 Timeout
491 +---+
492 | |
493 | V
494 +-----------+ Set-Ack (2) +----------+
495 | |------------>| |
496 | Set-Nonce | | Ap-Req |
497 | (1) |<------------| (5) |
498 +-----------+ Timeout +----------+
499 ^ |
500 | | Set-Ap-Rep
501 | +----------+ | (6)
502 +------| |<------+
503 Timeout | Estab-wt |
504 | (7) |
505 +----------+
506 |
507 | Set-Ap-Rep-Ack (7)
508 V
509 +----------+
510 | |
511 | Estab |
512 | |
514 +----------+
538 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 9]
544 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
548 Agent Unsolicited Retransmission State Machine
550 Timeout
551 +---+
552 | |
553 | V
554 +----------+
555 | |
556 +----> | Ap-Req |-------+
557 | | (5) | |
558 | +----------+ |
559 | |
560 | | Set-Ap-Rep
561 | +----------+ | (6)
562 +------| |<------+
563 Timeout | Estab-wt |
564 | (7) |
565 +----------+
566 |
567 | Set-Ap-Rep-Ack (7)
568 V
569 +----------+
570 | |
571 | Estab |
572 | |
573 +----------+
575 Session Duration and Failures
577 The KerbUsmMib uses the ticket lifetime to determine the life of the
578 USM session. The Agent MUST keep track of whether the ticket which
579 instigated the session is valid whenever it forms PDU's for that par-
580 ticular user. If a session expires, or if it wasn't valid to begin
581 with (from the Agent's perspective), the Agent MUST reject the PDU by
582 sending a XXX Error [mat: help me here Keith... what does USM say
583 about this?].
585 Kerberos also inherently implies adding state to the Agent and
586 Manager since they share not only a key, but a lifetime associated
587 with that key. This is in some sense soft state because failure of an
588 Agent will cause it to reject PDU's for Managers with whom it does
589 not share a secret. The Manager can use the Error PDU's as an indica-
590 tion that it needs to reauthenticate with the Agent, taking care not
591 to loop. The Manager is even easier: when it reboots, it can either
592 check its credential cache to reconstruct state or cause the Agent to
593 reauthenticate to the Manager with its service ticket by initiating a
594 authentication transaction with the manager.
598 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 10]
604 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
607 Manager Collisions
609 Managers may freely set up keys for different USM users using this
610 MIB without problem since they access different rows in the krbUsm-
611 PrinTable. However, multiple Managers trying to set up keys for the
612 same USM user is possible but discouraged. The requirement for the
613 Manager is that they MUST share the same service key with the KDC so
614 that they can all decrypt the same service ticket. There are two race
615 conditions, however, which are not well handled:
619 1) At the end of a ticket lifetime, one manager may request the agent
620 to refresh its service ticket causing a new session key to be
621 installed for the USM user leaving the other managers with stale
622 keys. The workaround here is that the Agent will reject the stale
623 manager's PDU's which should inform them to do their own rekeying
624 operations.
627 2) If multiple managers try to access the same row at the same time,
628 the Agent SHOULD try to keep the transactions separate based on the
629 nonce values. The Managers or the Agents SHOULD NOT break the
630 krbUsmMibNonce and any other additional varbinds into separate PDU's
631 as this may result in a meta stable state. Given normal MTU sizes,
632 this should not be an issue in practice, and this should at worst
633 devolve into the case above.
635 In all cases, the krbUsmMibNonce MUST be the last value to be
636 transmitted, though its position within a PDU is unimportant.
658 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 11]
664 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
668 KrbUSM MIB
670 KRB-USM-MIB DEFINITIONS ::= BEGIN
671 IMPORTS
672 MODULE-IDENTITY,
673 OBJECT-TYPE, OBJECT-IDENTITY,
674 snmpModules, Counter32, Unsigned32 FROM SNMPv2-SMI
675 TruthValue, DisplayString FROM SNMPv2-TC
676 usmUserEntry FROM SNMP-USER-BASED-SM-MIB
680 krbUsmMib MODULE-IDENTITY
681 LAST-UPDATED "00071300Z"
682 ORGANIZATION "IETF SNMP V3 Working Group"
683 CONTACT-INFO
684 "Michael Thomas
685 Cisco Systems
686 375 E Tasman Drive
687 San Jose, Ca 95134
688 Phone: +1 408-525-5386
689 Fax: +1 801-382-5284
690 email: mat@cisco.com"
691 DESCRIPTION
692 "This MIB contains the MIB variables to
693 exchange Kerberos credentials and a session
694 key to be used to authenticate and set up
695 USM keys"
697 ::= { snmpModules nnn } -- not sure what needs to be here.
698 krbUsmMibObjects OBJECT INDENTIFIER ::= { krbUsmMib 1 }
700 krbUsmMibAuthInAttemps
701 SYNTAX Counter32
702 MAX-ACCESS read-only
703 STATUS current
704 DESCRIPTION
705 "Counter of the number of Kerberos
706 authorization attempts as defined by
707 receipt of a PDU from a Manager with a
708 krbUsmMibNonce set in the principal table."
709 ::= { krbUsmMibObjects 1 }
711 krbUsmMibAuthOutAttemps
712 SYNTAX Counter32
713 MAX-ACCESS read-only
714 STATUS current
718 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 12]
724 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
727 DESCRIPTION
728 "Counter of the number of unsolicited Kerberos
729 authorization attempts as defined by
730 an Agent sending an INFORM or TRAP PDU with a
731 krbUsmMibApRep but without krbUsmApMibNonce
732 varbind."
733 ::= { krbUsmMibObjects 2 }
734 krbUsmMibAuthInFail
735 SYNTAX Counter32
736 MAX-ACCESS read-only
737 STATUS current
738 DESCRIPTION
739 "Counter of the number of Kerberos
740 authorization failures as defined by
741 a Manager setting the krbUsmMibNonce
742 in the principal table which results
743 in some sort of failure to install keys
744 in the requested USM user entry."
745 ::= { krbUsmMibObjects 3 }
747 krbUsmMibAuthOutFail
748 SYNTAX Counter32
749 MAX-ACCESS read-only
750 STATUS current
751 DESCRIPTION
752 "Counter of the number of unsolicited Kerberos
753 authorization failures as defined by
754 an Agent sending an INFORM or TRAP PDU with a
755 krbUsmMibApRep but without a krbUsmMibNonce
756 varbind which does not result in keys being
757 installed for that USM user entry."
758 ::= { krbUsmMibObjects 4 }
760 krbUsmMibPrinTable OBJECT-TYPE
761 SYNTAX SEQUENCE OF krbUsmMibEntry
762 MAX-ACCESS not-accessible
763 STATUS current
764 DESCRIPTION
765 "Table which maps Kerberos principals with USM
766 users as well as the per user variables to key
767 up sessions"
768 ::= { krbUsmMibObjects 5 }
770 krbUsmMibPrinEntry OBJECT-TYPE
771 SYNTAX KrbUsmMibPrinEntry
772 MAX-ACCESS not-accessible
773 STATUS current
774 DESCRIPTION
778 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 13]
784 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
787 "an entry into the krbMibPrinTable which is a
788 parallel table to UsmUserEntry table"
789 AUGMENTS { usmUserEntry }
790 ::= { krbUsmMibPrinTable 1 }
792 KrbUsmMibPrinEntry SEQUENCE
793 {
794 krbUsmMibApReq OCTET STRING,
795 krbUsmMibApRep OCTET STRING,
796 krbUsmMibNonce OCTET STRING,
797 krbUsmMibMgrTGT OCTET STRING,
798 krbUsmMibUnsolicitedNotify TruthValue,
799 }
802 krbUsmMibApReq OBJECT-TYPE
803 SYNTAX OCTET STRING
804 MAX-ACCESS accessible-for-notify
805 STATUS current
806 DESCRIPTION
807 "This variable contains a DER encoded Kerberos
808 AP-REQ or KRB-ERROR for the USM user which is
809 to be keyed. This is sent from the Agent to
810 the Manager in an INFORM or TRAP request.
811 KRB-ERROR MUST only be sent to the Manager
812 if it is in response to a keying request from
813 the Manager.
814 "
815 ::= { krbUsmMibPrinEntry 1 }
817 krbUsmMibApRep OBJECT-TYPE
818 SYNTAX OCTET STRING
819 MAX-ACCESS read-write
820 STATUS current
821 DESCRIPTION
822 "This variable contains the DER encoded response
823 to an AP-REQ. This variable is SET by the
824 Manager to acknowledge receipt of an AP-REQ. If
825 krbUsmMibApRep contains a Kerberos AP-REP, the
826 Agent must derive keys from the session key
827 of the Kerberos ticket in the AP-REQ and place
828 them in the USM database in a manner specified
829 by [RFC2574]. If the Manager detects an error,
830 it will instead place a KRB-ERROR in this
831 variable to inform the Agent of the error.
833 This variable is in effect a write-only variable.
834 attempts to read this variable will result in a
838 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 14]
844 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
847 null octet string being returned"
848 ::= { krbUsmMibPrinEntry 2 }
850 krbUsmMibNonce OBJECT-TYPE
851 SYNTAX OCTET STRING
852 MAX-ACCESS read-write
853 STATUS current
854 DESCRIPTION
855 "SET'ing a krbUsmMibnonce allows a Manager to
856 determine whether an INFORM or TRAP from an
857 Agent is an outstanding keying request, or
858 unsolicited from the Agent. The Manager
859 initiates keying for a particular USM user
860 by writing a nonce into the row for which
861 desires to establish a security association.
862 The nonce is an ASCII string of the form
863 ``host:port?nonce'' where:
865 host: is either an FQDN, or valid ipv4 or ipv6
866 numerical notation of the Manager which
867 desires to initiate keying
868 port: is the destination port at which that the
869 Manager may be contacted
870 nonce: is a number generated by the Manager to
871 correlate the transaction
873 The same nonce MUST be sent to the Manager in a
874 subsequent INFORM or TRAP with a krbUsmApReq.
875 The Agent MUST use the host address and port
876 supplied in the nonce as the destination of a
877 subsequent INFORM or TRAP. Unsolicited keying
878 requests MUST NOT contain a nonce, and should
879 instead use the destination stored Notifies of
880 this type.
882 Nonces MUST be highly collision resistant either
883 using a time based method or a suitable random
884 number generator. Managers MUST never create
885 nonces which are 0.
887 This variable is in effect a write-only variable.
888 Attempts to read this variable will result in a
889 nonce of value 0 being returned"
892 ::= { krbUsmMibPrinEntry 3 }
898 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 15]
904 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
907 krbUsmMibMgrTgt OBJECT-TYPE
908 SYNTAX OCTET STRING
909 MAX-ACCESS read-write
910 STATUS current
911 DESCRIPTION
912 "If the Manager does not possess a symmetric
913 key with the KDC as would be the case with
914 a Manager using PKinit for authentication,
915 the Manager MUST SET its DER encoded ticket
916 granting ticket into KrbUsmMgrTgt along
917 with krbUsmMibNonce.
919 The agent will then attach the Manager's TGT
920 into the additional tickets field of the
921 TGS-REQ message to the KDC to get a User-User
922 service ticket.
924 This variable is in effect a write-only variable.
925 Attempts to read this variable will result in a
926 null octet string being returned"
927 ::= { krbUsmMibPrinEntry 4 }
930 krbUsmMibUnsolicitedNotify OBJECT-TYPE
931 SYNTAX TruthValue
932 MAX-ACCESS read-write
933 STATUS current
934 DESCRIPTION
935 "If this variable is false, the Agent MUST NOT
936 send unsolicited INFORM or TRAP PDU's to the
937 Manager.
939 Attempts to SET this variable by the no-auth
940 no-priv user MUST be rejected."
941 ::= { krbUsmMibPrinEntry 5 }
943 --
944 -- Conformance section... nothing optional.
946 krbUsmMibCompliences MODULE-COMPLIANCE
947 STATUS current
948 DESCRIPTION "The compliance statement for SNMP
949 engines whichimplement the KRB-USM-MIB
950 "
951 MODULE -- this module
952 MANDATORY-GROUPS { krbUsmMib }
953 ::= { krbUsmMibCompliances 1 }
958 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 16]
964 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
967 END
970 Key Derivation
972 The session key provides the basis for the keying material for the
973 USM user specified in the AP-REQ. The actual keys for use for the
974 authentication and privacy are produced using the cryptographic hash-
975 ing function used to protect the ticket itself. The keying material
976 is derived using this function, F(key, salt), using successive
977 interations of F over the salt string "SNMPV3RULZ%d", where %d is a
978 monotonic counter starting at zero. The bits are taken directly from
979 the successive interations to produce two keys of appropriate size
980 (as specified in the USM user row) for the authentication transform
981 first, and the privacy transform second. If the authentication
982 transform is null, the first bits of the derived key are used for the
983 privacy transform.
985 Security Considerations
987 Various elements of this MIB must be readable and writable as the
988 no-auth, no-priv user. Unless specifically necessary for the key
989 negotiation, elements of this MIB SHOULD be protected by VACM views
990 which limit access. In particular, there is no reason anything in
991 this MIB should be visible to a no-auth, no-priv user with the excep-
992 tion of KrbUsmMibApReq, KrbUsmMibApRep, KrbUsmMibNonce, and
993 KrbUsmMibMgrTgt, and then only with the restrictions placed on them
994 in the MIB. As such, probing attacks are still possible, but should
995 not be profitable: all of the writable variables with interesting
996 information in them are defined in such a way as to be write only.
998 There are some interesting denial of service attacks which are possi-
999 ble by attackers spoofing managers and putting load on the KDC to
1000 generate unnecessary tickets. For large numbers or agents this could
1001 be problematic. This can probably be mitigated by the KDC prioritiz-
1002 ing TGS-REQ's though.
1005 References
1007 [1] The CAT Working Group, J. Kohl, C.Neuman, "The Kerberos
1008 Network Authentication Service (V5)", RFC 1510, September
1009 1993
1011 [2] The SNMPV3 Working Group, U. Blumenthal, B. Wijnen, "The
1012 User-based Security Model of SNMP V3", RFC 2574, April 1999
1014 [3] The SNMPV3 Working Group, B. Wijnen, R. Presuhn,
1018 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 17]
1024 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
1027 K.McCloghrie, "The View-based Access Control Model of SNMP
1028 V3", RFC 2575, April 1999
1030 [4] The CAT Working Group, Tung, et al, "Public Key Cryptography
1031 for Initial Authentication in Kerberos", draft-ietf-cat-pk-
1032 init-11, November 1999
1034 [5] Arango, et al, "Media Gateway Control Protocl (MGCP)", RFC
1035 2705, October 1999
1038 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, An Architecture
1039 for Describing SNMP Management Frameworks, RFC 2571, April
1040 1999.
1042 [RFC1155] Rose, M., and K. McCloghrie, Structure and Identification of
1043 Management Information for TCP/IP-based Internets, STD 16,
1044 RFC 1155, May 1990.
1046 [RFC1212] Rose, M., and K. McCloghrie, Concise MIB Definitions, STD
1047 16, RFC 1212, March 1991.
1049 [RFC1215] M. Rose, A Convention for Defining Traps for use with the
1050 SNMP, RFC 1215, March 1991.
1052 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
1053 Rose, M., and S. Waldbusser, Structure of Management Infor-
1054 mation Version 2 (SMIv2), STD 58, RFC 2578, April 1999.
1056 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
1057 Rose, M., and S. Waldbusser, Textual Conventions for SMIv2,
1058 STD 58, RFC 2579, April 1999.
1060 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
1061 Rose, M., and S. Waldbusser, Conformance Statements for
1062 SMIv2, STD 58, RFC 2580, April 1999.
1064 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, Simple
1065 Network Management Protocol, STD 15, RFC 1157, May 1990.
1067 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
1068 Introduction to Community-based SNMPv2, RFC 1901, January
1069 1996.
1071 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Tran-
1072 sport Mappings for Version 2 of the Simple Network Manage-
1073 ment Protocol (SNMPv2), RFC 1906, January 1996.
1078 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 18]
1084 INTERNET-DRAFT Kerberized USM Keying 13 July 2000
1087 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, Message
1088 Processing and Dispatching for the Simple Network Management
1089 Protocol (SNMP), RFC 2572, April 1999.
1091 [RFC2574] Blumenthal, U., and B. Wijnen, User-based Security Model
1092 (USM) for version 3 of the Simple Network Management Proto-
1093 col (SNMPv3), RFC 2574, April 1999.
1095 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Pro-
1096 tocol Operations for Version 2 of the Simple Network Manage-
1097 ment Protocol (SNMPv2), RFC 1905, January 1996.
1099 [RFC2573] Levi, D., Meyer, P., and B. Stewart, SNMPv3 Applications,
1100 RFC 2573, April 1999.
1102 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, View-based
1103 Access Control Model (VACM) for the Simple Network Manage-
1104 ment Protocol (SNMP), RFC 2575, April 1999.
1106 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, Introduc-
1107 tion to Version 3 of the Internet-standard Network Manage-
1108 ment Framework, RFC 2570, April 1999.
1110 Author's Address
1112 Michael Thomas
1113 Cisco Systems
1114 375 E Tasman Rd
1115 San Jose, Ca, 95134, USA
1116 Tel: +1 408-525-5386
1117 email: mat@cisco.com
1138 Thomas draft-thomas-snmpv3-kerbusm-00 [Page 19]