File: rfc2841.txt

package info (click to toggle)
doc-rfc 20170121-1
  • links: PTS, VCS
  • area: non-free
  • in suites: stretch
  • size: 541,932 kB
  • ctags: 32
  • sloc: xml: 267,963; sh: 101; python: 90; perl: 42; makefile: 13
file content (507 lines) | stat: -rw-r--r-- 14,139 bytes parent folder | download | duplicates (6)
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






Network Working Group                                         P. Metzger
Request for Comments: 2841                                      Piermont
Category: Historic                                            W. Simpson
Obsoletes: 1852                                               DayDreamer
                                                           November 2000


  IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)

Status of this Memo

   This memo defines a Historic Document for the Internet community.  It
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document describes the use of keyed SHA1 with the IP
   Authentication Header.

Table of Contents

   1.   Introduction ............................................. 2
   1.1. Keys ..................................................... 2
   1.2. Data Size ................................................ 2
   1.3. Performance .............................................. 3
   2.   Calculation .............................................. 3
   A.   Changes .................................................. 5
   Security Considerations ....................................... 6
   Acknowledgements .............................................. 6
   References .................................................... 7
   Contacts ...................................................... 8
   Editor's Note ................................................. 8
   Full Copyright Statement ...................................... 9













Metzger & Simpson               Historic                        [Page 1]

RFC 2841                     AH SHA1 IP-MAC                November 2000


1.  Introduction

   The Authentication Header (AH) [RFC-1826] provides integrity and
   authentication for IP datagrams.  This specification describes the AH
   use of keys with the Secure Hash Algorithm (SHA1) [FIPS-180-1].  This
   SHA1-IP-MAC algorithm uses a leading and trailing key (a variant of
   the "envelope method"), with alignment padding between both keys and
   data.

      It should be noted that this document specifies a newer version of
      SHA than that described in [FIPS-180], which was flawed.  The
      older version is not interoperable with the newer version.

   This document assumes that the reader is familiar with the related
   document "Security Architecture for the Internet Protocol" [RFC-
   1825], that defines the overall security plan for IP, and provides
   important background for this specification.

1.1.  Keys

   The secret authentication key shared between the communicating
   parties SHOULD be a cryptographically strong random number, not a
   guessable string of any sort.

   The shared key is not constrained by this transform to any particular
   size.  Lengths of 160-bits (20 octets) MUST be supported by the
   implementation, although any particular key may be shorter.  Longer
   keys are encouraged.

1.2.  Data Size

   SHA1's 160-bit output is naturally 32-bit aligned.  However, many
   implementations require 64-bit alignment of the following headers.

   Therefore, several options are available for data alignment (most
   preferred to least preferred):

   1) only the most significant 128-bits (16 octets) of output are used.

   2) an additional 32-bits (4 octets) of padding is added before the
      SHA1 output.

   3) an additional 32-bits (4 octets) of padding is added after the
      SHA1 output.

   4) the SHA1 output is variably bit-positioned within 192-bits (24
      octets).




Metzger & Simpson               Historic                        [Page 2]

RFC 2841                     AH SHA1 IP-MAC                November 2000


   The size and position of the output are negotiated as part of the key
   management.  Padding bits are filled with unspecified implementation
   dependent (random) values, which are ignored on receipt.

   Discussion:

      Although truncation of the output for alignment purposes may
      appear to reduce the effectiveness of the algorithm, some analysts
      of attack verification suggest that this may instead improve the
      overall robustness [PO95a].

1.3.  Performance

   Preliminary results indicate that SHA1 is 62% as fast as MD5, and 80%
   as fast as DES hashing.  That is:

                           SHA1 < DES < MD5

   This appears to be a reasonable performance tradeoff, as SHA1
   internal chaining is significantly longer than either DES or MD5:

                           DES < MD5 < SHA1

   Nota Bene:
      Suggestions are sought on alternative authentication algorithms
      that have significantly faster throughput, are not patent-
      encumbered, and still retain adequate cryptographic strength.

2.  Calculation

   The 160-bit digest is calculated as described in [FIPS-180-1].  A
   portable C language implementation of SHA1 is available via FTP from
   ftp://rand.org/pub/jim/sha.tar.gz.

   The form of the authenticated message is:

      SHA1( key, keyfill, datagram, datafill, key, sha1fill )

   First, the variable length secret authentication key is filled to the
   next 512-bit boundary, using the same pad-with-length technique
   defined for SHA1.  The padding technique includes a length that
   protects arbitrary length keys.

   Next, the filled key is concatenated with (immediately followed by)
   the invariant fields of the entire IP datagram (variant fields are
   zeroed).  This is also filled to the next 512-bit boundary, using the
   same pad-with-length technique defined for SHA1.  The length includes
   the leading key and data.



Metzger & Simpson               Historic                        [Page 3]

RFC 2841                     AH SHA1 IP-MAC                November 2000


   Then, the filled data is concatenated with (immediately followed by)
   the original variable length key again.  A trailing pad-with-length
   to the next 512-bit boundary for the entire message is added by SHA1
   itself.

   Finally, the 160-bit SHA1 digest is calculated, and the result is
   inserted into the Authentication Data field.

   Discussion:

      The leading copy of the key is padded in order to facilitate
      copying of the key at machine boundaries without requiring re-
      alignment of the following datagram.  Filling to the SHA1 block
      size also allows the key to be prehashed to avoid the physical
      copy in some implementations.

      The trailing copy of the key is not necessary to protect against
      appending attacks, as the IP datagram already includes a total
      length field.  It reintroduces mixing of the entire key, providing
      protection for very long and very short datagrams, and robustness
      against possible attacks on the IP length field itself.

      When the implementation adds the keys and padding in place before
      and after the IP datagram, care must be taken that the keys and/or
      padding are not sent over the link by the link driver.


























Metzger & Simpson               Historic                        [Page 4]

RFC 2841                     AH SHA1 IP-MAC                November 2000


A.  Changes

   Changes from RFC 1852:

   Use of SHA1 term (as always intended).

   Added shortened 128-bit output, and clarify output text.

   Added tradeoff text.

   Changed padding technique to comply with Crypto '95 recommendations.

   Updated references.

   Updated contacts.

   Minor editorial changes.


































Metzger & Simpson               Historic                        [Page 5]

RFC 2841                     AH SHA1 IP-MAC                November 2000


Security Considerations

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of the SHA1
   hash function, the correctness of that algorithm's implementation,
   the security of the key management mechanism and its implementation,
   the strength of the key, and upon the correctness of the
   implementations in all of the participating nodes.

   The SHA algorithm was originally derived from the MD4 algorithm
   [RFC-1320].  A flaw was apparently found in the original
   specification of SHA [FIPS-180], and this document specifies the use
   of a corrected version [FIPS-180-1].

   At the time of writing of this document, there are no known flaws in
   the SHA1 algorithm.  That is, there are no known attacks on SHA1 or
   any of its components that are better than brute force, and the 160-
   bit hash size of SHA1 is substantially more resistant to brute force
   attacks than the 128-bit hash size of MD4 and MD5.

   However, as the flaw in the original SHA1 algorithm shows,
   cryptographers are fallible, and there may be substantial
   deficiencies yet to be discovered in the algorithm.

Acknowledgements

   Some of the text of this specification was derived from work by
   Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups.

   Preliminary performance analysis was provided by Joe Touch.

   Padding the leading copy of the key to a hash block boundary for
   increased performance was originally suggested by William Allen
   Simpson.

   Padding the leading copy of the key to a hash block boundary for
   increased security was suggested by [KR95].  Including the key length
   for increased security was suggested by David Wagner.

   Padding the datagram to a hash block boundary to avoid (an
   impractical) key recovery attack was suggested by [PO95b].










Metzger & Simpson               Historic                        [Page 6]

RFC 2841                     AH SHA1 IP-MAC                November 2000


References

   [FIPS-180]   "Secure Hash Standard", Computer Systems Laboratory,
                National Institute of Standards and Technology, U.S.
                Department Of Commerce, May 1993.

                Also known as: 58 Fed Reg 27712 (1993).

   [FIPS-180-1] "Secure Hash Standard", National Institute of Standards
                and Technology, U.S. Department Of Commerce, April 1995.

                Also known as: 59 Fed Reg 35317 (1994).

   [KR95]       Kaliski, B., and Robshaw, M., "Message authentication
                with MD5", CryptoBytes (RSA Labs Technical Newsletter),
                vol.1 no.1, Spring 1995.

   [PO95a]      Preneel, B., and van Oorshot, P., "MDx-MAC and Building
                Fast MACs from Hash Functions", Advances in Cryptology
                -- Crypto '95 Proceedings, Santa Barbara, California,
                August 1995.

   [PO95b]      Preneel, B., and van Oorshot, P., "On the Security of
                Two MAC Algorithms", Presented at the Rump Session of
                Crypto '95, Santa Barbara, California, August 1995.

   [RFC 1320]   Rivest, R., "The MD4 Message-Digest Algorithm", RFC
                1320, April 1992.

   [RFC 1700]   Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
                RFC 1700, October 1994.

   [RFC 1825]   Atkinson, R., "Security Architecture for the Internet
                Protocol", RFC 1825, July 1995.

   [RFC 1826]   Atkinson, R., "IP Authentication Header", RFC 1826, July
                1995.














Metzger & Simpson               Historic                        [Page 7]

RFC 2841                     AH SHA1 IP-MAC                November 2000


Contacts

   Comments about this document should be discussed on the
   photuris@adk.gr mailing list.

   This document is a submission to the IP Security Working Group of the
   Internet Engineering Task Force (IETF).  The working group can be
   contacted via the current chairs:

   Questions about this document can also be directed to:

   Perry Metzger
   Piermont Information Systems Inc.
   160 Cabrini Blvd., Suite #2
   New York, NY  10033

   EMail: perry@piermont.com


   William Allen Simpson
   DayDreamer
   Computer Systems Consulting Services
   1384 Fontaine
   Madison Heights, Michigan  48071

   EMail: wsimpson@UMich.edu
          wsimpson@GreenDragon.com (preferred)

Editor's Note

   This paper was originally submitted May 1, 1996.




















Metzger & Simpson               Historic                        [Page 8]

RFC 2841                     AH SHA1 IP-MAC                November 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Metzger & Simpson               Historic                        [Page 9]