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
|
<pre>Network Working Group U. Blumenthal
Request for Comments: 3826 Lucent Technologies
Category: Standards Track F. Maino
Andiamo Systems, Inc.
K. McCloghrie
Cisco Systems, Inc.
June 2004
<span class="h1">The Advanced Encryption Standard (AES) Cipher Algorithm</span>
<span class="h1">in the SNMP User-based Security Model</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes a symmetric encryption protocol that
supplements the protocols described in the User-based Security Model
(USM), which is a Security Subsystem for version 3 of the Simple
Network Management Protocol for use in the SNMP Architecture. The
symmetric encryption protocol described in this document is based on
the Advanced Encryption Standard (AES) cipher algorithm used in
Cipher FeedBack Mode (CFB), with a key size of 128 bits.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Goals and Constraints. . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.2">1.2</a>. Key Localization . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.3">1.3</a>. Password Entropy and Storage . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. CFB128-AES-128 Symmetric Encryption Protocol . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Mechanisms . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1.1">3.1.1</a>. The AES-based Symmetric Encryption Protocol . . <a href="#page-6">6</a>
3.1.2. Localized Key, AES Encryption Key and
Initialization Vector . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.1.3">3.1.3</a>. Data Encryption . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.1.4">3.1.4</a>. Data Decryption . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<span class="grey">Blumenthal, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
<a href="#section-3.2">3.2</a>. Elements of the AES Privacy Protocol . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.2.1">3.2.1</a>. Users . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.2.2">3.2.2</a>. msgAuthoritativeEngineID. . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.2.3">3.2.3</a>. SNMP Messages Using this Privacy Protocol . . . <a href="#page-10">10</a>
<a href="#section-3.2.4">3.2.4</a>. Services provided by the AES Privacy Modules. . <a href="#page-10">10</a>
<a href="#section-3.3">3.3</a>. Elements of Procedure. . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-3.3.1">3.3.1</a>. Processing an Outgoing Message. . . . . . . . . <a href="#page-12">12</a>
<a href="#section-3.3.2">3.3.2</a>. Processing an Incoming Message. . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4">4</a>. Security Considerations. . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5">5</a>. IANA Considerations. . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6">6</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8">8</a>. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-9">9</a>. Full Copyright Statement . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Within the Architecture for describing Internet Management Frameworks
[<a href="./rfc3411" title=""An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks"">RFC3411</a>], the User-based Security Model (USM) [<a href="./rfc3414" title=""User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)"">RFC3414</a>] for SNMPv3
is defined as a Security Subsystem within an SNMP engine. <a href="./rfc3414">RFC 3414</a>
describes the use of HMAC-MD5-96 and HMAC-SHA-96 as the initial
authentication protocols, and the use of CBC-DES as the initial
privacy protocol. The User-based Security Model, however, allows for
other such protocols to be used instead of, or concurrently with,
these protocols.
This memo describes the use of CFB128-AES-128 as an alternative
privacy protocol for the User-based Security Model. The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Goals and Constraints</span>
The main goal of this memo is to provide a new privacy protocol for
the USM based on the Advanced Encryption Standard (AES) [<a href="#ref-FIPS-AES" title=""Specification for the ADVANCED ENCRYPTION STANDARD (AES)"">FIPS-AES</a>].
The major constraint is to maintain a complete interchangeability of
the new protocol defined in this memo with existing authentication
and privacy protocols already defined in USM.
For a given user, the AES-based privacy protocol MUST be used with
one of the authentication protocols defined in <a href="./rfc3414">RFC 3414</a> or an
algorithm/protocol providing equivalent functionality.
<span class="grey">Blumenthal, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Key Localization</span>
As defined in [<a href="./rfc3414" title=""User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)"">RFC3414</a>], a localized key is a secret key shared
between a user U and one authoritative SNMP engine E. Even though a
user may have only one pair of authentication and privacy passwords
(and consequently only one pair of keys) for the entire network, the
actual secrets shared between the user and each authoritative SNMP
engine will be different. This is achieved by key localization.
If the authentication protocol defined for a user U at the
authoritative SNMP engine E is one of the authentication protocols
defined in [<a href="./rfc3414" title=""User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)"">RFC3414</a>], the key localization is performed according to
the two-step process described in <a href="./rfc3414#section-2.6">section 2.6 of [RFC3414]</a>.
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Password Entropy and Storage</span>
The security of various cryptographic functions lies both in the
strength of the functions themselves against various forms of attack,
and also, perhaps more importantly, in the keying material that is
used with them. While theoretical attacks against cryptographic
functions are possible, it is more probable that key guessing is the
main threat.
The following are recommended in regard to user passwords:
- Password length SHOULD be at least 12 octets.
- Password sharing SHOULD be prohibited so that passwords are not
shared among multiple SNMP users.
- Implementations SHOULD support the use of randomly generated
passwords as a stronger form of security.
It is worth remembering that, as specified in [<a href="./rfc3414" title=""User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)"">RFC3414</a>], if a user's
password or a non-localized key is disclosed, then key localization
will not help and network security may be compromised. Therefore, a
user's password or non-localized key MUST NOT be stored on a managed
device/node. Instead, the localized key SHALL be stored (if at all)
so that, in case a device does get compromised, no other managed or
managing devices get compromised.
<span class="grey">Blumenthal, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Definitions</span>
This MIB is written in SMIv2 [<a href="./rfc2578" title=""Structure of Management Information Version 2 (SMIv2)"">RFC2578</a>].
SNMP-USM-AES-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY,
snmpModules FROM SNMPv2-SMI -- [<a href="./rfc2578" title=""Structure of Management Information Version 2 (SMIv2)"">RFC2578</a>]
snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB; -- [<a href="./rfc3411" title=""An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks"">RFC3411</a>]
snmpUsmAesMIB MODULE-IDENTITY
LAST-UPDATED "200406140000Z"
ORGANIZATION "IETF"
CONTACT-INFO "Uri Blumenthal
Lucent Technologies / Bell Labs
67 Whippany Rd.
14D-318
Whippany, NJ 07981, USA
973-386-2163
uri@bell-labs.com
Fabio Maino
Andiamo Systems, Inc.
375 East Tasman Drive
San Jose, CA 95134, USA
408-853-7530
fmaino@andiamo.com
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706, USA
408-526-5260
kzm@cisco.com"
DESCRIPTION "Definitions of Object Identities needed for
the use of AES by SNMP's User-based Security
Model.
Copyright (C) The Internet Society (2004).
This version of this MIB module is part of <a href="./rfc3826">RFC 3826</a>;
see the RFC itself for full legal notices.
Supplementary information may be available on
<a href="http://www.ietf.org/copyrights/ianamib.html">http://www.ietf.org/copyrights/ianamib.html</a>."
<span class="grey">Blumenthal, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
REVISION "200406140000Z"
DESCRIPTION "Initial version, published as <a href="./rfc3826">RFC3826</a>"
::= { snmpModules 20 }
usmAesCfb128Protocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The CFB128-AES-128 Privacy Protocol."
REFERENCE "- Specification for the ADVANCED ENCRYPTION
STANDARD. Federal Information Processing
Standard (FIPS) Publication 197.
(November 2001).
- Dworkin, M., NIST Recommendation for Block
Cipher Modes of Operation, Methods and
Techniques. NIST Special Publication 800-38A
(December 2001).
"
::= { snmpPrivProtocols 4 }
END
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. CFB128-AES-128 Symmetric Encryption Protocol</span>
This section describes a Symmetric Encryption Protocol based on the
AES cipher algorithm [<a href="#ref-FIPS-AES" title=""Specification for the ADVANCED ENCRYPTION STANDARD (AES)"">FIPS-AES</a>], used in Cipher Feedback Mode as
described in [<a href="#ref-AES-MODE" title=""NIST Recommendation for Block Cipher Modes of Operation, Methods and Techniques"">AES-MODE</a>], using encryption keys with a size of 128
bits.
This protocol is identified by usmAesCfb128PrivProtocol.
The protocol usmAesCfb128PrivProtocol is an alternative to the
privacy protocol defined in [<a href="./rfc3414" title=""User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)"">RFC3414</a>].
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Mechanisms</span>
In support of data confidentiality, an encryption algorithm is
required. An appropriate portion of the message is encrypted prior
to being transmitted. The User-based Security Model specifies that
the scopedPDU is the portion of the message that needs to be
encrypted.
A secret value is shared by all SNMP engines which can legitimately
originate messages on behalf of the appropriate user. This secret
value, in combination with a timeliness value and a 64-bit integer,
is used to create the (localized) en/decryption key and the
initialization vector.
<span class="grey">Blumenthal, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. The AES-based Symmetric Encryption Protocol</span>
The Symmetric Encryption Protocol defined in this memo provides
support for data confidentiality. The designated portion of an SNMP
message is encrypted and included as part of the message sent to the
recipient.
The AES (Advanced Encryption Standard) is the symmetric cipher
algorithm that the NIST (National Institute of Standards and
Technology) has selected in a four-year competitive process as
Replacement for DES (Data Encryption Standard).
The AES homepage, <a href="http://www.nist.gov/aes">http://www.nist.gov/aes</a>, contains a wealth of
information on AES including the Federal Information Processing
Standard [<a href="#ref-FIPS-AES" title=""Specification for the ADVANCED ENCRYPTION STANDARD (AES)"">FIPS-AES</a>] that fully specifies the Advanced Encryption
Standard.
The following subsections contain descriptions of the relevant
characteristics of the AES ciphers used in the symmetric encryption
protocol described in this memo.
<span class="h5"><a class="selflink" id="section-3.1.1.1" href="#section-3.1.1.1">3.1.1.1</a>. Mode of operation</span>
The NIST Special Publication 800-38A [<a href="#ref-AES-MODE" title=""NIST Recommendation for Block Cipher Modes of Operation, Methods and Techniques"">AES-MODE</a>] recommends five
confidentiality modes of operation for use with AES: Electronic
Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB),
Output Feedback (OFB), and Counter (CTR).
The symmetric encryption protocol described in this memo uses AES in
CFB mode with the parameter S (number of bits fed back) set to 128
according to the definition of CFB mode given in [<a href="#ref-AES-MODE" title=""NIST Recommendation for Block Cipher Modes of Operation, Methods and Techniques"">AES-MODE</a>]. This
mode requires an Initialization Vector (IV) that is the same size as
the block size of the cipher algorithm.
<span class="h5"><a class="selflink" id="section-3.1.1.2" href="#section-3.1.1.2">3.1.1.2</a>. Key Size</span>
In the encryption protocol described by this memo AES is used with a
key size of 128 bits, as recommended in [<a href="#ref-AES-MODE" title=""NIST Recommendation for Block Cipher Modes of Operation, Methods and Techniques"">AES-MODE</a>].
<span class="h5"><a class="selflink" id="section-3.1.1.3" href="#section-3.1.1.3">3.1.1.3</a>. Block Size and Padding</span>
The block size of the AES cipher algorithms used in the encryption
protocol described by this memo is 128 bits, as recommended in [AES-
MODE].
<span class="grey">Blumenthal, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
<span class="h5"><a class="selflink" id="section-3.1.1.4" href="#section-3.1.1.4">3.1.1.4</a>. Rounds</span>
This parameter determines how many times a block is encrypted. The
encryption protocol described in this memo uses 10 rounds, as
recommended in [<a href="#ref-AES-MODE" title=""NIST Recommendation for Block Cipher Modes of Operation, Methods and Techniques"">AES-MODE</a>].
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Localized Key, AES Encryption Key, and Initialization Vector</span>
The size of the Localized Key (Kul) of an SNMP user, as described in
[<a href="./rfc3414" title=""User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)"">RFC3414</a>], depends on the authentication protocol defined for that
user U at the authoritative SNMP engine E.
The encryption protocol defined in this memo MUST be used with an
authentication protocol that generates a localized key with at least
128 bits. The authentication protocols described in [<a href="./rfc3414" title=""User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)"">RFC3414</a>]
satisfy this requirement.
<span class="h5"><a class="selflink" id="section-3.1.2.1" href="#section-3.1.2.1">3.1.2.1</a>. AES Encryption Key and IV</span>
The first 128 bits of the localized key Kul are used as the AES
encryption key. The 128-bit IV is obtained as the concatenation of
the authoritative SNMP engine's 32-bit snmpEngineBoots, the SNMP
engine's 32-bit snmpEngineTime, and a local 64-bit integer. The 64-
bit integer is initialized to a pseudo-random value at boot time.
The IV is concatenated as follows: the 32-bit snmpEngineBoots is
converted to the first 4 octets (Most Significant Byte first), the
32-bit snmpEngineTime is converted to the subsequent 4 octets (Most
Significant Byte first), and the 64-bit integer is then converted to
the last 8 octets (Most Significant Byte first). The 64-bit integer
is then put into the msgPrivacyParameters field encoded as an OCTET
STRING of length 8 octets. The integer is then modified for the
subsequent message. We recommend that it is incremented by one until
it reaches its maximum value, at which time it is wrapped.
An implementation can use any method to vary the value of the local
64-bit integer, providing the chosen method never generates a
duplicate IV for the same key.
A duplicated IV can result in the very unlikely event that multiple
managers, communicating with a single authoritative engine, both
accidentally select the same 64-bit integer within a second. The
probability of such an event is very low, and does not significantly
affect the robustness of the mechanisms proposed.
<span class="grey">Blumenthal, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
The 64-bit integer must be placed in the privParameters field to
enable the receiving entity to compute the correct IV and to decrypt
the message. This 64-bit value is called the "salt" in this
document.
Note that the sender and receiver must use the same IV value, i.e.,
they must both use the same values of the individual components used
to create the IV. In particular, both sender and receiver must use
the values of snmpEngineBoots, snmpEngineTime, and the 64-bit integer
which are contained in the relevant message (in the
msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime, and
privParameters fields respectively).
<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>. Data Encryption</span>
The data to be encrypted is treated as a sequence of octets.
The data is encrypted in Cipher Feedback mode with the parameter s
set to 128 according to the definition of CFB mode given in <a href="#section-6.3">Section</a>
<a href="#section-6.3">6.3</a> of [<a href="#ref-AES-MODE" title=""NIST Recommendation for Block Cipher Modes of Operation, Methods and Techniques"">AES-MODE</a>]. A clear diagram of the encryption and decryption
process is given in Figure 3 of [<a href="#ref-AES-MODE" title=""NIST Recommendation for Block Cipher Modes of Operation, Methods and Techniques"">AES-MODE</a>].
The plaintext is divided into 128-bit blocks. The last block may
have fewer than 128 bits, and no padding is required.
The first input block is the IV, and the forward cipher operation is
applied to the IV to produce the first output block. The first
ciphertext block is produced by exclusive-ORing the first plaintext
block with the first output block. The ciphertext block is also used
as the input block for the subsequent forward cipher operation.
The process is repeated with the successive input blocks until a
ciphertext segment is produced from every plaintext segment.
The last ciphertext block is produced by exclusive-ORing the last
plaintext segment of r bits (r is less than or equal to 128) with the
segment of the r most significant bits of the last output block.
<span class="h4"><a class="selflink" id="section-3.1.4" href="#section-3.1.4">3.1.4</a>. Data Decryption</span>
In CFB decryption, the IV is the first input block, the first
ciphertext is used for the second input block, the second ciphertext
is used for the third input block, etc. The forward cipher function
is applied to each input block to produce the output blocks. The
output blocks are exclusive-ORed with the corresponding ciphertext
blocks to recover the plaintext blocks.
<span class="grey">Blumenthal, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
The last ciphertext block (whose size r is less than or equal to 128)
is exclusive-ORed with the segment of the r most significant bits of
the last output block to recover the last plaintext block of r bits.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Elements of the AES Privacy Protocol</span>
This section contains definitions required to realize the privacy
modules defined by this memo.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Users</span>
Data en/decryption using this Symmetric Encryption Protocol makes use
of a defined set of userNames. For any user on whose behalf a
message must be en/decrypted at a particular SNMP engine, that SNMP
engine must have knowledge of that user. An SNMP engine that needs
to communicate with another SNMP engine must also have knowledge of a
user known to that SNMP engine, including knowledge of the applicable
attributes of that user.
A user and its attributes are defined as follows:
<userName>
An octet string representing the name of the user.
<privAlg>
The algorithm used to protect messages generated on behalf of the
user from disclosure.
<privKey>
The user's secret key to be used as input to the generation of the
localized key for encrypting/decrypting messages generated on
behalf of the user. The length of this key MUST be greater than
or equal to 128 bits (16 octets).
<authAlg>
The algorithm used to authenticate messages generated on behalf of
the user, which is also used to generate the localized version of
the secret key.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. msgAuthoritativeEngineID</span>
The msgAuthoritativeEngineID value contained in an authenticated
message specifies the authoritative SNMP engine for that particular
message (see the definition of SnmpEngineID in the SNMP Architecture
document [<a href="./rfc3411" title=""An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks"">RFC3411</a>]).
<span class="grey">Blumenthal, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
The user's (private) privacy key is different at each authoritative
SNMP engine, and so the snmpEngineID is used to select the proper key
for the en/decryption process.
<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>. SNMP Messages Using this Privacy Protocol</span>
Messages using this privacy protocol carry a msgPrivacyParameters
field as part of the msgSecurityParameters. For this protocol, the
privParameters field is the serialized OCTET STRING representing the
"salt" that was used to create the IV.
<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>. Services provided by the AES Privacy Modules</span>
This section describes the inputs and outputs that the AES Privacy
module expects and produces when the User-based Security module
invokes one of the AES Privacy modules for services.
<span class="h5"><a class="selflink" id="section-3.2.4.1" href="#section-3.2.4.1">3.2.4.1</a>. Services for Encrypting Outgoing Data</span>
The AES privacy protocol assumes that the selection of the privKey is
done by the caller, and that the caller passes the localized secret
key to be used.
Upon completion, the privacy module returns statusInformation and, if
the encryption process was successful, the encryptedPDU and the
msgPrivacyParameters encoded as an OCTET STRING. The abstract
service primitive is:
statusInformation = -- success or failure
encryptData(
IN encryptKey -- secret key for encryption
IN dataToEncrypt -- data to encrypt (scopedPDU)
OUT encryptedData -- encrypted data (encryptedPDU)
OUT privParameters -- filled in by service provider
)
The abstract data elements are:
statusInformation
An indication of the success or failure of the encryption process.
In case of failure, it is an indication of the error.
encryptKey
The secret key to be used by the encryption algorithm. The length
of this key MUST be 16 octets.
dataToEncrypt
The data that must be encrypted.
<span class="grey">Blumenthal, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
encryptedData
The encrypted data upon successful completion.
privParameters
The privParameters encoded as an OCTET STRING.
<span class="h5"><a class="selflink" id="section-3.2.4.2" href="#section-3.2.4.2">3.2.4.2</a>. Services for Decrypting Incoming Data</span>
This AES privacy protocol assumes that the selection of the privKey
is done by the caller and that the caller passes the localized secret
key to be used.
Upon completion the privacy module returns statusInformation and, if
the decryption process was successful, the scopedPDU in plain text.
The abstract service primitive is:
statusInformation =
decryptData(
IN decryptKey -- secret key for decryption
IN privParameters -- as received on the wire
IN encryptedData -- encrypted data (encryptedPDU)
OUT decryptedData -- decrypted data (scopedPDU)
)
The abstract data elements are:
statusInformation
An indication of whether the data was successfully decrypted, and
if not, an indication of the error.
decryptKey
The secret key to be used by the decryption algorithm. The length
of this key MUST be 16 octets.
privParameters
The 64-bit integer to be used to calculate the IV.
encryptedData
The data to be decrypted.
decryptedData
The decrypted data.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Elements of Procedure</span>
This section describes the procedures for the AES privacy protocol
for SNMP's User-based Security Model.
<span class="grey">Blumenthal, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Processing an Outgoing Message</span>
This section describes the procedure followed by an SNMP engine
whenever it must encrypt part of an outgoing message using the
usmAesCfb128PrivProtocol.
1) The secret encryptKey is used to construct the AES encryption key,
as described in <a href="#section-3.1.2.1">section 3.1.2.1</a>.
2) The privParameters field is set to the serialization according to
the rules in [<a href="./rfc3417" title=""Transport Mappings for the Simple Network Management Protocol (SNMP)"">RFC3417</a>] of an OCTET STRING representing the 64-bit
integer that will be used in the IV as described in <a href="#section-3.1.2.1">section</a>
<a href="#section-3.1.2.1">3.1.2.1</a>.
3) The scopedPDU is encrypted (as described in <a href="#section-3.1.3">section 3.1.3</a>) and the
encrypted data is serialized according to the rules in [<a href="./rfc3417" title=""Transport Mappings for the Simple Network Management Protocol (SNMP)"">RFC3417</a>]
as an OCTET STRING.
4) The serialized OCTET STRING representing the encrypted scopedPDU
together with the privParameters and statusInformation indicating
success is returned to the calling module.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Processing an Incoming Message</span>
This section describes the procedure followed by an SNMP engine
whenever it must decrypt part of an incoming message using the
usmAesCfb128PrivProtocol.
1) If the privParameters field is not an 8-octet OCTET STRING, then
an error indication (decryptionError) is returned to the calling
module.
2) The 64-bit integer is extracted from the privParameters field.
3) The secret decryptKey and the 64-bit integer are then used to
construct the AES decryption key and the IV that is computed as
described in <a href="#section-3.1.2.1">section 3.1.2.1</a>.
4) The encryptedPDU is then decrypted (as described in <a href="#section-3.1.4">section</a>
<a href="#section-3.1.4">3.1.4</a>).
5) If the encryptedPDU cannot be decrypted, then an error indication
(decryptionError) is returned to the calling module.
6) The decrypted scopedPDU and statusInformation indicating success
are returned to the calling module.
<span class="grey">Blumenthal, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
The security of the cryptographic functions defined in this document
lies both in the strength of the functions themselves against various
forms of attack, and also, perhaps more importantly, in the keying
material that is used with them. The recommendations in <a href="#section-1.3">Section 1.3</a>
SHOULD be followed to ensure maximum entropy to the selected
passwords, and to protect the passwords while stored.
The security of the CFB mode relies upon the use of a unique IV for
each message encrypted with the same key [<a href="#ref-CRYPTO-B" title=""Probable Plaintext Cryptanalysis of the IP Security Protocols"">CRYPTO-B</a>]. If the IV is
not unique, a cryptanalyst can recover the corresponding plaintext.
<a href="#section-3.1.2.1">Section 3.1.2.1</a> defines a procedure to derive the IV from a local
64-bit integer (the salt) initialized to a pseudo-random value at
boot time. An implementation can use any method to vary the value of
the local 64-bit integer, providing the chosen method never generates
a duplicate IV for the same key.
The procedure of <a href="#section-3.1.2.1">section 3.1.2.1</a> suggests a method to vary the local
64-bit integer value that generates unique IVs for every message.
This method can result in a duplicated IV in the very unlikely event
that multiple managers, communicating with a single authoritative
engine, both accidentally select the same 64-bit integer within a
second. The probability of such an event is very low, and does not
significantly affect the robustness of the mechanisms proposed.
This AES-based privacy protocol MUST be used with one of the
authentication protocols defined in <a href="./rfc3414">RFC 3414</a> or with an
algorithm/protocol providing equivalent functionality (including
integrity), because CFB encryption mode does not detect ciphertext
modifications.
For further security considerations, the reader is encouraged to read
[<a href="./rfc3414" title=""User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)"">RFC3414</a>], and the documents that describe the actual cipher
algorithms.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
IANA has assigned OID 20 for the snmpUsmAesMIB module under the
snmpModules subtree, maintained in the registry at
<a href="http://www.iana.org/assignments/smi-numbers">http://www.iana.org/assignments/smi-numbers</a>.
IANA has assigned OID 4 for the usmAesCfb128Protocol under the
snmpPrivProtocols registration point, as defined in <a href="./rfc3411">RFC 3411</a>
[<a href="./rfc3411" title=""An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks"">RFC3411</a>].
<span class="grey">Blumenthal, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgements</span>
Portions of this text, as well as its general structure, were
unabashedly lifted from [<a href="./rfc3414" title=""User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)"">RFC3414</a>]. The authors are grateful to many
of the SNMPv3 WG members for their help, especially Wes Hardaker,
Steve Moulton, Randy Presuhn, David Town, and Bert Wijnen. Security
discussions with Steve Bellovin helped to streamline this protocol.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-AES-MODE">AES-MODE</a>] Dworkin, M., "NIST Recommendation for Block Cipher Modes
of Operation, Methods and Techniques", NIST Special
Publication 800-38A, December 2001.
[<a id="ref-FIPS-AES">FIPS-AES</a>] "Specification for the ADVANCED ENCRYPTION STANDARD
(AES)", Federal Information Processing Standard (FIPS)
Publication 197, November 2001.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2578">RFC2578</a>] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, <a href="./rfc2578">RFC 2578</a>, April 1999.
[<a id="ref-RFC3411">RFC3411</a>] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, <a href="./rfc3411">RFC 3411</a>,
December 2002.
[<a id="ref-RFC3414">RFC3414</a>] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, <a href="./rfc3414">RFC 3414</a>, December 2002.
[<a id="ref-RFC3417">RFC3417</a>] Presuhn, R., Ed., "Transport Mappings for the Simple
Network Management Protocol (SNMP)", STD 62, <a href="./rfc3417">RFC 3417</a>,
December 2002.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-CRYPTO-B">CRYPTO-B</a>] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP
Security Protocols", Proceedings of the Symposium on
Network and Distributed System Security, San Diego, CA,
pp. 155-160, February 1997.
<span class="grey">Blumenthal, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Authors' Addresses</span>
Uri Blumenthal
Lucent Technologies / Bell Labs
67 Whippany Rd.
14D-318
Whippany, NJ 07981, USA
Phone: +1-973-386-2163
EMail: uri@bell-labs.com
Fabio Maino
Andiamo Systems, Inc.
375 East Tasman Drive
San Jose, CA. 95134 USA
Phone: +1-408-853-7530
EMail: fmaino@andiamo.com
Keith McCloghrie
Cisco Systems, Inc.
170 East Tasman Drive
San Jose, CA. 95134-1706 USA
Phone: +1-408-526-5260
EMail: kzm@cisco.com
<span class="grey">Blumenthal, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3826">RFC 3826</a> AES for SNMP's USM June 2004</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Blumenthal, et al. Standards Track [Page 16]
</pre>
|
