File: rfc1852.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (339 lines) | stat: -rw-r--r-- 9,367 bytes parent folder | download | duplicates (5)
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






Network Working Group                                         P. Metzger
Request for Comments: 1852                                      Piermont
Category: Experimental                                        W. Simpson
                                                              Daydreamer
                                                          September 1995


                   IP Authentication using Keyed SHA



Status of this Memo

   This document defines an Experimental Protocol for the Internet
   community.  This does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.


Abstract

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


Table of Contents

     1.     Introduction ..........................................    2
        1.1       Keys ............................................    2
        1.2       Data Size .......................................    2
        1.3       Performance .....................................    2

     2.     Calculation ...........................................    3

     SECURITY CONSIDERATIONS ......................................    4
     ACKNOWLEDGEMENTS .............................................    4
     REFERENCES ...................................................    5
     AUTHOR'S ADDRESS .............................................    6













Metzger & Simpson             Experimental                      [Page 1]

RFC 1852                         AH SHA                   September 1995


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 (SHA) [FIPS-180-1].

      It should be noted that this document specifies a newer version of
      the 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], which 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 up to 160 bits MUST be supported by the
   implementation, although any particular key may be shorter.  Longer
   keys are encouraged.



1.2.  Data Size

   SHA's 160-bit output is naturally 32-bit aligned.  However, many
   implementations require 64-bit alignment of the following headers, in
   which case an additional 32 bits of padding is added, either before
   or after the SHA output.

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



1.3.  Performance

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



Metzger & Simpson             Experimental                      [Page 2]

RFC 1852                         AH SHA                   September 1995


                           SHA < DES < MD5

   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].  At
   the time of writing, a portable C language implementation of SHA is
   available via FTP from ftp://rand.org/pub/jim/sha.tar.gz.

   The form of the authenticated message is

            key, keyfill, datagram, key, SHAfill

   First, the variable length secret authentication key is filled to the
   next 512-bit boundary, using the same pad with length technique
   defined for SHA.

   Then, the filled key is concatenated with (immediately followed by)
   the invariant fields of the entire IP datagram (variant fields are
   zeroed), 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 SHA itself.  The 160-bit SHA 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.  The padding technique
      includes a length which protects arbitrary length keys.  Filling
      to the SHA 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
      minimal protection for very long and very short datagrams, and
      marginal robustness against possible attacks on the IP length
      field itself.




Metzger & Simpson             Experimental                      [Page 3]

RFC 1852                         AH SHA                   September 1995


      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.



Security Considerations

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of the SHA hash
   function, the correctness of that algorithm's implementation, the
   security of the key management mechanism and its implementation, the
   strength of the key [CN94], 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 SHA algorithm.  That is, there are no known attacks on SHA or any
   of its components that are better than brute force, and the 160-bit
   hash output by SHA 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 SHA 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.

   Comments should be submitted to the ipsec@ans.net mailing list.











Metzger & Simpson             Experimental                      [Page 4]

RFC 1852                         AH SHA                   September 1995


References

   [CN94]   John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data:
            Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp.
            253-280, July 1994.

   [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).

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

   [RFC-1700]
            Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
            1700, USC/Information Sciences Institute, October 1994.

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

   [RFC-1826]
            Atkinson, R., "IP Authentication Header", RFC-1826, Naval
            Research Laboratory, July 1995.

















Metzger & Simpson             Experimental                      [Page 5]

RFC 1852                         AH SHA                   September 1995


Author's Address

   Questions about this memo can also be directed to:

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

      perry@piermont.com


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

      Bill.Simpson@um.cc.umich.edu
          bsimpson@MorningStar.com































Metzger & Simpson             Experimental                      [Page 6]