1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
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
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
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
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
|
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]
|