1 2 3 4 5 6 7INTERNET-DRAFT Kerberized USM Keying M. Thomas 8 Cisco Systems 9 K. McCloghrie 10 Cisco Systems 11 July 13, 2000 12 13 14 15 16 17 18 Kerberized USM Keying 19 20 draft-thomas-snmpv3-kerbusm-00.txt 21 22 23 24Status of this Memo 25 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. 31 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." 36 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 39 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 42 43Abstract 44 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. 50 51The SNMP Management Framework 52 53 The SNMP Management Framework presently consists of five major 54 components: An overall architecture, described in RFC 2571 55 56 57 58Thomas draft-thomas-snmpv3-kerbusm-00 [Page 1] 59 60 61 62 63 64INTERNET-DRAFT Kerberized USM Keying 13 July 2000 65 66 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]. 87 88 A more detailed introduction to the current SNMP Management Framework 89 can be found in RFC 2570 [RFC2570]. 90 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. 94 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. 104 105 106Introduction 107 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 115 116 117 118Thomas draft-thomas-snmpv3-kerbusm-00 [Page 2] 119 120 121 122 123 124INTERNET-DRAFT Kerberized USM Keying 13 July 2000 125 126 127 authorized. 128 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. 137 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. 150 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. 159 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. 173 174 175 176 177 178Thomas draft-thomas-snmpv3-kerbusm-00 [Page 3] 179 180 181 182 183 184INTERNET-DRAFT Kerberized USM Keying 13 July 2000 185 186 187Operation 188 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. 201 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. 213 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. 222 223Keying Transactions 224 225 The following shows an error free transaction: 226 227 Note: optional steps or parameters are shown like [ ] 228 229 230 231 232 233 234 235 236 237 238Thomas draft-thomas-snmpv3-kerbusm-00 [Page 4] 239 240 241 242 243 244INTERNET-DRAFT Kerberized USM Keying 13 July 2000 245 246 247 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) --+ 258 259 3) ---------------------------------------------------------------> 260 TGS-REQ (krbUsmPrinTable[usmUserName].krbUsmMibMgrPrinName 261 [, krbUsmPrinTable[usmUserName].krbUsmMibTgt]); 262 263 4) <-------------------------------------------------------------- 264 Tick[usmUserSecurityName] = TGS-REP (); 265 266 5) ------------------------------> 267 INFORM (krbUsmPrinTable[usmUserName].krbUsmMibApReq = 268 AP_REQ[Tick[usmUserSecurityName]]; 269 [ krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx]); 270 271 6) <------------------------------ 272 SET (krbUsmPrinTable[usmUserName].krbUsmMibApRep = AP_REP[]); 273 274 275 7) ------------------------------> 276 Response 277 278 279 The above flow translates to: 280 281 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). 288 289 290 2) This step acknowledges the SET. There are no MIB specific errors 291 which can happen here. 292 293 294 3) If the Agent is not already in possession of a service ticket for 295 296 297 298Thomas draft-thomas-snmpv3-kerbusm-00 [Page 5] 299 300 301 302 303 304INTERNET-DRAFT Kerberized USM Keying 13 July 2000 305 306 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]). 314 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. 321 322 4) If step 3 was performed, this step receives the ticket or an 323 error from the KDC. 324 325 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. 335 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. 345 346 347 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. 354 355 356 357 358Thomas draft-thomas-snmpv3-kerbusm-00 [Page 6] 359 360 361 362 363 364INTERNET-DRAFT Kerberized USM Keying 13 July 2000 365 366 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. 378 379 Otherwise, the Manager MUST send a SET PDU to the Agent which 380 contains a krbUsmMibApRep. 381 382 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. 389 390Unsolicited Agent Keying Requests 391 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. 408 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. 412 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 415 416 417 418Thomas draft-thomas-snmpv3-kerbusm-00 [Page 7] 419 420 421 422 423 424INTERNET-DRAFT Kerberized USM Keying 13 July 2000 425 426 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. 437 438Retransmissions 439 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]. 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478Thomas draft-thomas-snmpv3-kerbusm-00 [Page 8] 479 480 481 482 483 484INTERNET-DRAFT Kerberized USM Keying 13 July 2000 485 486 487 488Manager Solicited Retransmission State Machine 489 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 | | 513 514 +----------+ 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538Thomas draft-thomas-snmpv3-kerbusm-00 [Page 9] 539 540 541 542 543 544INTERNET-DRAFT Kerberized USM Keying 13 July 2000 545 546 547 548Agent Unsolicited Retransmission State Machine 549 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 +----------+ 574 575Session Duration and Failures 576 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?]. 584 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. 595 596 597 598Thomas draft-thomas-snmpv3-kerbusm-00 [Page 10] 599 600 601 602 603 604INTERNET-DRAFT Kerberized USM Keying 13 July 2000 605 606 607Manager Collisions 608 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: 616 617 618 6191) 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. 625 626 6272) 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. 634 635 In all cases, the krbUsmMibNonce MUST be the last value to be 636 transmitted, though its position within a PDU is unimportant. 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658Thomas draft-thomas-snmpv3-kerbusm-00 [Page 11] 659 660 661 662 663 664INTERNET-DRAFT Kerberized USM Keying 13 July 2000 665 666 667 668 KrbUSM MIB 669 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 677 678 679 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" 696 697 ::= { snmpModules nnn } -- not sure what needs to be here. 698 krbUsmMibObjects OBJECT INDENTIFIER ::= { krbUsmMib 1 } 699 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 } 710 711 krbUsmMibAuthOutAttemps 712 SYNTAX Counter32 713 MAX-ACCESS read-only 714 STATUS current 715 716 717 718Thomas draft-thomas-snmpv3-kerbusm-00 [Page 12] 719 720 721 722 723 724INTERNET-DRAFT Kerberized USM Keying 13 July 2000 725 726 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 } 746 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 } 759 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 } 769 770 krbUsmMibPrinEntry OBJECT-TYPE 771 SYNTAX KrbUsmMibPrinEntry 772 MAX-ACCESS not-accessible 773 STATUS current 774 DESCRIPTION 775 776 777 778Thomas draft-thomas-snmpv3-kerbusm-00 [Page 13] 779 780 781 782 783 784INTERNET-DRAFT Kerberized USM Keying 13 July 2000 785 786 787 "an entry into the krbMibPrinTable which is a 788 parallel table to UsmUserEntry table" 789 AUGMENTS { usmUserEntry } 790 ::= { krbUsmMibPrinTable 1 } 791 792 KrbUsmMibPrinEntry SEQUENCE 793 { 794 krbUsmMibApReq OCTET STRING, 795 krbUsmMibApRep OCTET STRING, 796 krbUsmMibNonce OCTET STRING, 797 krbUsmMibMgrTGT OCTET STRING, 798 krbUsmMibUnsolicitedNotify TruthValue, 799 } 800 801 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 } 816 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. 832 833 This variable is in effect a write-only variable. 834 attempts to read this variable will result in a 835 836 837 838Thomas draft-thomas-snmpv3-kerbusm-00 [Page 14] 839 840 841 842 843 844INTERNET-DRAFT Kerberized USM Keying 13 July 2000 845 846 847 null octet string being returned" 848 ::= { krbUsmMibPrinEntry 2 } 849 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: 864 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 872 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. 881 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. 886 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" 890 891 892 ::= { krbUsmMibPrinEntry 3 } 893 894 895 896 897 898Thomas draft-thomas-snmpv3-kerbusm-00 [Page 15] 899 900 901 902 903 904INTERNET-DRAFT Kerberized USM Keying 13 July 2000 905 906 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. 918 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. 923 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 } 928 929 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. 938 939 Attempts to SET this variable by the no-auth 940 no-priv user MUST be rejected." 941 ::= { krbUsmMibPrinEntry 5 } 942 943 -- 944 -- Conformance section... nothing optional. 945 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 } 954 955 956 957 958Thomas draft-thomas-snmpv3-kerbusm-00 [Page 16] 959 960 961 962 963 964INTERNET-DRAFT Kerberized USM Keying 13 July 2000 965 966 967 END 968 969 970Key Derivation 971 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. 984 985Security Considerations 986 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. 997 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. 1003 1004 1005References 1006 1007[1] The CAT Working Group, J. Kohl, C.Neuman, "The Kerberos 1008 Network Authentication Service (V5)", RFC 1510, September 1009 1993 1010 1011[2] The SNMPV3 Working Group, U. Blumenthal, B. Wijnen, "The 1012 User-based Security Model of SNMP V3", RFC 2574, April 1999 1013 1014[3] The SNMPV3 Working Group, B. Wijnen, R. Presuhn, 1015 1016 1017 1018Thomas draft-thomas-snmpv3-kerbusm-00 [Page 17] 1019 1020 1021 1022 1023 1024INTERNET-DRAFT Kerberized USM Keying 13 July 2000 1025 1026 1027 K.McCloghrie, "The View-based Access Control Model of SNMP 1028 V3", RFC 2575, April 1999 1029 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 1033 1034[5] Arango, et al, "Media Gateway Control Protocl (MGCP)", RFC 1035 2705, October 1999 1036 1037 1038[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, An Architecture 1039 for Describing SNMP Management Frameworks, RFC 2571, April 1040 1999. 1041 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. 1045 1046[RFC1212] Rose, M., and K. McCloghrie, Concise MIB Definitions, STD 1047 16, RFC 1212, March 1991. 1048 1049[RFC1215] M. Rose, A Convention for Defining Traps for use with the 1050 SNMP, RFC 1215, March 1991. 1051 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. 1055 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. 1059 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. 1063 1064[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, Simple 1065 Network Management Protocol, STD 15, RFC 1157, May 1990. 1066 1067[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1068 Introduction to Community-based SNMPv2, RFC 1901, January 1069 1996. 1070 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. 1074 1075 1076 1077 1078Thomas draft-thomas-snmpv3-kerbusm-00 [Page 18] 1079 1080 1081 1082 1083 1084INTERNET-DRAFT Kerberized USM Keying 13 July 2000 1085 1086 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. 1090 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. 1094 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. 1098 1099[RFC2573] Levi, D., Meyer, P., and B. Stewart, SNMPv3 Applications, 1100 RFC 2573, April 1999. 1101 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. 1105 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. 1109 1110Author's Address 1111 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 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138Thomas draft-thomas-snmpv3-kerbusm-00 [Page 19] 1139 1140 1141