File: rfc1826.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 (731 lines) | stat: -rw-r--r-- 30,475 bytes parent folder | download | duplicates (8)
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






Network Working Group                                        R. Atkinson
Request for Comments: 1826                     Naval Research Laboratory
Category: Standards Track                                    August 1995


                        IP Authentication Header

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.

ABSTRACT

   This document describes a mechanism for providing cryptographic
   authentication for IPv4 and IPv6 datagrams.  An Authentication Header
   (AH) is normally inserted after an IP header and before the other
   information being authenticated.

1. INTRODUCTION

   The Authentication Header is a mechanism for providing strong
   integrity and authentication for IP datagrams.  It might also provide
   non-repudiation, depending on which cryptographic algorithm is used
   and how keying is performed.  For example, use of an asymmetric
   digital signature algorithm, such as RSA, could provide non-
   repudiation.

   Confidentiality, and protection from traffic analysis are not
   provided by the Authentication Header.  Users desiring
   confidentiality should consider using the IP Encapsulating Security
   Protocol (ESP) either in lieu of or in conjunction with the
   Authentication Header [Atk95b].  This document assumes the reader has
   previously read the related IP Security Architecture document which
   defines the overall security architecture for IP and provides
   important background information for this specification [Atk95a].

1.1 Overview

   The IP Authentication Header seeks to provide security by adding
   authentication information to an IP datagram. This authentication
   information is calculated using all of the fields in the IP datagram
   (including not only the IP Header but also other headers and the user
   data) which do not change in transit.  Fields or options which need
   to change in transit (e.g., "hop count", "time to live", "ident",



Atkinson                    Standards Track                     [Page 1]

RFC 1826                IP Authentication Header             August 1995


   "fragment offset", or "routing pointer") are considered to be zero
   for the calculation of the authentication data.  This provides
   significantly more security than is currently present in IPv4 and
   might be sufficient for the needs of many users.

   Use of this specification will increase the IP protocol processing
   costs in participating end systems and will also increase the
   communications latency.  The increased latency is primarily due to
   the calculation of the authentication data by the sender and the
   calculation and comparison of the authentication data by the receiver
   for each IP datagram containing an Authentication Header.  The impact
   will vary with authentication algorithm used and other factors.

   In order for the Authentication Header to work properly without
   changing the entire Internet infrastructure, the authentication data
   is carried in its own payload.  Systems that aren't participating in
   the authentication MAY ignore the Authentication Data.  When used
   with IPv6, the Authentication Header is normally placed after the
   Fragmentation and End-to-End headers and before the ESP and
   transport-layer headers.  The information in the other IP headers is
   used to route the datagram from origin to destination.  When used
   with IPv4, the Authentication Header immediately follows an IPv4
   header.

   If a symmetric authentication algorithm is used and intermediate
   authentication is desired, then the nodes performing such
   intermediate authentication would need to be provided with the
   appropriate keys.  Possession of those keys would permit any one of
   those systems to forge traffic claiming to be from the legitimate
   sender to the legitimate receiver or to modify the contents of
   otherwise legitimate traffic.  In some environments such intermediate
   authentication might be desirable [BCCH94].  If an asymmetric
   authentication algorithm is used and the routers are aware of the
   appropriate public keys and authentication algorithm, then the
   routers possessing the authentication public key could authenticate
   the traffic being handled without being able to forge or modify
   otherwise legitimate traffic.  Also, Path MTU Discovery MUST be used
   when intermediate authentication of the Authentication Header is
   desired and IPv4 is in use because with this method it is not
   possible to authenticate a fragment of a packet [MD90] [Kno93].











Atkinson                    Standards Track                     [Page 2]

RFC 1826                IP Authentication Header             August 1995


1.2 Requirements Terminology

   In this document, the words that are used to define the significance
   of each particular requirement are usually capitalised.  These words
   are:

   - MUST

      This word or the adjective "REQUIRED" means that the item is an
      absolute requirement of the specification.

   - SHOULD

      This word or the adjective "RECOMMENDED" means that there might
      exist valid reasons in particular circumstances to ignore this
      item, but the full implications should be understood and the case
      carefully weighed before taking a different course.

   - MAY

      This word or the adjective "OPTIONAL" means that this item is
      truly optional.  One vendor might choose to include the item
      because a particular marketplace requires it or because it
      enhances the product, for example; another vendor may omit the
      same item.

2. KEY MANAGEMENT

   Key management is an important part of the IP security architecture.
   However, it is not integrated with this specification because of a
   long history in the public literature of subtle flaws in key
   management algorithms and protocols.  The IP Authentication Header
   tries to decouple the key management mechanisms from the security
   protocol mechanisms.  The only coupling between the key management
   protocol and the security protocol is with the Security Parameters
   Index (SPI), which is described in more detail below.  This
   decoupling permits several different key management mechanisms to be
   used.  More importantly, it permits the key management protocol to be
   changed or corrected without unduly impacting the security protocol
   implementations.

   The key management mechanism is used to negotiate a number of
   parameters for each "Security Association", including not only the
   keys but also other information (e.g., the authentication algorithm
   and mode) used by the communicating parties.  The key management
   mechanism creates and maintains a logical table containing the
   several parameters for each current security association.  An
   implementation of the IP Authentication Header will need to read that



Atkinson                    Standards Track                     [Page 3]

RFC 1826                IP Authentication Header             August 1995


   logical table of security parameters to determine how to process each
   datagram containing an Authentication Header (e.g., to determine
   which algorithm/mode and key to use in authentication).

   Security Associations are unidirectional.  A bidirectional
   communications session will normally have one Security Association in
   each direction.  For example, when a TCP session exists between two
   systems A and B, there will normally be one Security Association from
   A to B and a separate second Security Assocation from B to A.  The
   receiver assigns the SPI value to the the Security Association with
   that sender.  The other parameters of the Security Association are
   determined in a manner specified by the key management mechanism.
   Section 4 of this document describes in detail the process of
   selecting a Security Association for an outgoing packet and
   identifying the Security Assocation for an incoming packet.

   The IP Security Architecture document describes key management in
   detail.  It includes specification of the key management requirements
   for this protocol, and is incorporated here by reference [Atk95a].

3. AUTHENTICATION HEADER SYNTAX

   The Authentication Header (AH) may appear after any other headers
   which are examined at each hop, and before any other headers which
   are not examined at an intermediate hop.  The IPv4 or IPv6 header
   immediately preceding the Authentication Header will contain the
   value 51 in its Next Header (or Protocol) field [STD-2].

   Example high-level diagrams of IP datagrams with the Authentication
   Header follow.

 +------------+-------------------+------------+-------+---------------+
 | IPv6 Header| Hop-by-Hop/Routing| Auth Header| Others| Upper Protocol|
 +------------+-------------------+------------+-------+---------------+

                Figure 1: IPv6 Example















Atkinson                    Standards Track                     [Page 4]

RFC 1826                IP Authentication Header             August 1995


   When used with IPv6, the Authentication Header normally appears after
   the IPv6 Hop-by-Hop Header and before the IPv6 Destination Options.

    +-------------+--------------+-------------------------------+
    | IPv4 Header |  Auth Header | Upper Protocol (e.g. TCP, UDP)|
    +-------------+--------------+-------------------------------+

                   Figure 2:  IPv4 Example


   When used with IPv4, the Authentication Header normally follows the
   main IPv4 header.

3.1 Authentication Header Syntax

   The authentication data is the output of the authentication algorithm
   calculated over the the entire IP datagram as described in more
   detail later in this document.  The authentication calculation must
   treat the Authentication Data field itself and all fields that are
   normally modified in transit (e.g., TTL or Hop Limit) as if those
   fields contained all zeros.  All other Authentication Header fields
   are included in the authentication calculation normally.

   The IP Authentication Header has the following syntax:

     +---------------+---------------+---------------+---------------+
     | Next Header   | Length        |           RESERVED            |
     +---------------+---------------+---------------+---------------+
     |                    Security Parameters Index                  |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     +     Authentication Data (variable number of 32-bit words)     |
     |                                                               |
     +---------------+---------------+---------------+---------------+
      1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8


                   Figure 3:  Authentication Header syntax













Atkinson                    Standards Track                     [Page 5]

RFC 1826                IP Authentication Header             August 1995


3.2 Fields of the Authentication Header

   NEXT HEADER
      8 bits wide.  Identifies the next payload after the Authentication
      Payload.  This values in this field are the set of IP Protocol
      Numbers as defined in the most recent RFC from the Internet
      Assigned Numbers Authority (IANA) describing "Assigned Numbers"
      [STD-2].

   PAYLOAD LENGTH
      8 bits wide.  The length of the Authentication Data field in 32-
      bit words.  Minimum value is 0 words, which is only used in the
      degenerate case of a "null" authentication algorithm.

   RESERVED
      16 bits wide.  Reserved for future use.  MUST be set to all zeros
      when sent.  The value is included in the Authentication Data
      calculation, but is otherwise ignored by the recipient.

   SECURITY PARAMETERS INDEX (SPI)
      A 32-bit pseudo-random value identifying the security association
      for this datagram.  The Security Parameters Index value 0 is
      reserved to indicate that "no security association exists".

      The set of Security Parameters Index values in the range 1 through
      255 are reserved to the Internet Assigned Numbers Authority (IANA)
      for future use.  A reserved SPI value will not normally be
      assigned by IANA unless the use of that particular assigned SPI
      value is openly specified in an RFC.

   AUTHENTICATION DATA
      This length of this field is variable, but is always an integral
      number of 32-bit words.

      Many implementations require padding to other alignments, such as
      64-bits, in order to improve performance.  All implementations
      MUST support such padding, which is specified by the Destination
      on a per SPI basis.  The value of the padding field is arbitrarily
      selected by the sender and is included in the Authentication Data
      calculation.

      An implementation will normally use the combination of Destination
      Address and SPI to locate the Security Association which specifies
      the field's size and use.  The field retains the same format for
      all datagrams of any given SPI and Destination Address pair.






Atkinson                    Standards Track                     [Page 6]

RFC 1826                IP Authentication Header             August 1995


      The Authentication Data fills the field beginning immediately
      after the SPI field.  If the field is longer than necessary to
      store the actual authentication data, then the unused bit
      positions are filled with unspecified, implementation-dependent
      values.

      Refer to each Authentication Transform specification for more
      information regarding the contents of this field.

3.3 Sensitivity Labeling

   As is discussed in greater detail in the IP Security Architecture
   document, IPv6 will normally use implicit Security Labels rather than
   the explicit labels that are currently used with IPv4 [Ken91]
   [Atk95a].  In some situations, users MAY choose to carry explicit
   labels (for example, IPSO labels as defined by RFC-1108 might be used
   with IPv4) in addition to using the implicit labels provided by the
   Authentication Header.  Explicit label options could be defined for
   use with IPv6 (e.g., using the IPv6 end-to-end options header or the
   IPv6 hop-by-hop options header).  Implementations MAY support
   explicit labels in addition to implicit labels, but implementations
   are not required to support explicit labels.  If explicit labels are
   in use, then the explicit label MUST be included in the
   authentication calculation.

4. CALCULATION OF THE AUTHENTICATION DATA

   The authentication data carried by the IP Authentication Header is
   usually calculated using a message digest algorithm (for example,
   MD5) either encrypting that message digest or keying the message
   digest directly [Riv92].  Only algorithms that are believed to be
   cryptographically strong one-way functions should be used with the IP
   Authentication Header.

   Because conventional checksums (e.g., CRC-16) are not
   cryptographically strong, they MUST NOT be used with the
   Authentication Header.

   When processing an outgoing IP packet for Authentication, the first
   step is for the sending system to locate the appropriate Security
   Association.  All Security Associations are unidirectional.  The
   selection of the appropriate Security Association for an outgoing IP
   packet is based at least upon the sending userid and the Destination
   Address.  When host-oriented keying is in use, all sending userids
   will share the same Security Association to a given destination.
   When user-oriented keying is in use, then different users or possibly
   even different applications of the same user might use different
   Security Associations.  The Security Association selected will



Atkinson                    Standards Track                     [Page 7]

RFC 1826                IP Authentication Header             August 1995


   indicate which algorithm, algorithm mode, key, and other security
   properties apply to the outgoing packet.

   Fields which NECESSARILY are modified during transit from the sender
   to the receiver (e.g., TTL and HEADER CHECKSUM for IPv4 or Hop Limit
   for IPv6) and whose value at the receiver are not known with
   certainty by the sender are included in the authentication data
   calculation but are processed specially.  For these fields which are
   modified during transit, the value carried in the IP packet is
   replaced by the value zero for the purpose of the authentication
   calculation.  By replacing the field's value with zero rather than
   omitting these fields, alignment is preserved for the authentication
   calculation.

   The sender MUST compute the authentication over the packet as that
   packet will appear at the receiver.  This requirement is placed in
   order to allow for future IP optional headers which the receiver
   might not know about but the sender necessarily knows about if it is
   including such options in the packet.  This also permits the
   authentication of data that will vary in transit but whose value at
   the final receiver is known with certainty by the sender in advance.

   The sender places the calculated message digest algorithm output into
   the Authentication Data field within the Authentication Header.  For
   purposes of Authentication Data computation, the Authentication Data
   field is considered to be filled with zeros.

   The IPv4 "TIME TO LIVE" and "HEADER CHECKSUM" fields are the only
   fields in the IPv4 base header that are handled specially for the
   Authentication Data calculation.  Reassembly of fragmented packets
   occurs PRIOR to processing by the local IP Authentication Header
   implementation.  The "more" bit is of course cleared upon reassembly.
    Hence, no other fields in the IPv4 header will vary in transit from
   the perspective of the IP Authentication Header implementation.  The
   "TIME TO LIVE" and "HEADER CHECKSUM" fields of the IPv4 base header
   MUST be set to all zeros for the Authentication Data calculation.
   All other IPv4 base header fields are processed normally with their
   actual contents.  Because IPv4 packets are subject to intermediate
   fragmentation in routers, it is important that the reassembly of IPv4
   packets be performed prior to the Authentication Header processing.
   IPv4 Implementations SHOULD use Path MTU Discovery when the IP
   Authentication Header is being used [MD90].  For IPv4, not all
   options are openly specified in a RFC, so it is not possible to
   enumerate in this document all of the options that might normally be
   modified during transit.  The IP Security Option (IPSO) MUST be
   included in the Authentication Data calculation whenever that option
   is present in an IP datagram [Ken91].  If a receiving system does not
   recognise an IPv4 option that is present in the packet, that option



Atkinson                    Standards Track                     [Page 8]

RFC 1826                IP Authentication Header             August 1995


   is included in the Authentication Data calculation.  This means that
   any IPv4 packet containing an IPv4 option that changes during transit
   in a manner not predictable by the sender and which IPv4 option is
   unrecognised by the receiver will fail the authentication check and
   consequently be dropped by the receiver.

   The IPv6 "HOP LIMIT" field is the only field in the IPv6 base header
   that is handled specially for Authentication Data calculation.  The
   value of the HOP LIMIT field is zero for the purpose of
   Authentication Data calculation.  All other fields in the base IPv6
   header MUST be included in the Authentication Data calculation using
   the normal procedures for calculating the Authentication Data.  All
   IPv6 "OPTION TYPE" values contain a bit which MUST be used to
   determine whether that option data will be included in the
   Authentication Data calculation.  This bit is the third-highest-order
   bit of the IPv6 OPTION TYPE field. If this bit is set to zero, then
   the corresponding option is included in the Authentication Data
   calculation.  If this bit is set to one, then the corresponding
   option is replaced by all zero bits of the same length as the option
   for the purpose of the Authentication Data calculation.  The IPv6
   Routing Header "Type 0" will rearrange the address fields within the
   packet during transit from source to destination.  However, this is
   not a problem because the contents of the packet as it will appear at
   the receiver are known to the sender and to all intermediate hops.
   Hence, the IPv6 Routing Header "Type 0" is included in the
   Authentication Data calculation using the normal procedure.

   Upon receipt of a packet containing an IP Authentication Header, the
   receiver first uses the Destination Address and SPI value to locate
   the correct Security Association.  The receiver then independently
   verifies that the Authentication Data field and the received data
   packet are consistent.  Again, the Authentication Data field is
   assumed to be zero for the sole purpose of making the authentication
   computation.  Exactly how this is accomplished is algorithm
   dependent.  If the processing of the authentication algorithm
   indicates the datagram is valid, then it is accepted.  If the
   algorithm determines that the data and the Authentication Header do
   not match, then the receiver SHOULD discard the received IP datagram
   as invalid and MUST record the authentication failure in the system
   log or audit log.  If such a failure occurs, the recorded log data
   MUST include the SPI value, date/time received, clear-text Sending
   Address, clear-text Destination Address, and (if it exists) the
   clear-text Flow ID.  The log data MAY also include other information
   about the failed packet.







Atkinson                    Standards Track                     [Page 9]

RFC 1826                IP Authentication Header             August 1995


5. CONFORMANCE REQUIREMENTS

   Implementations that claim conformance or compliance with this
   specification MUST fully implement the header described here, MUST
   support manual key distribution for use with this option, MUST comply
   with all requirements of the "Security Architecture for the Internet
   Protocol" [Atk95a], and MUST support the use of keyed MD5 as
   described in the companion document entitled "IP Authentication using
   Keyed MD5" [MS95].  Implementations MAY also implement other
   authentication algorithms.  Implementors should consult the most
   recent version of the "IAB Official Standards" RFC for further
   guidance on the status of this document.

6. SECURITY CONSIDERATIONS

   This entire RFC discusses an authentication mechanism for IP.  This
   mechanism is not a panacea to the several security issues in any
   internetwork, however it does provide a component useful in building
   a secure internetwork.

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of whichever
   cryptographic algorithm has been implemented, the strength of the key
   being used, the correctness of that algorithm's implementation, upon
   the security of the key management mechanism and its implementation,
   and upon the correctness of the IP Authentication Header and IP
   implementations in all of the participating systems. If any of these
   assumptions do not hold, then little or no real security will be
   provided to the user.  Implementors are encouraged to use high
   assurance methods to develop all of the security relevant parts of
   their products.

   Users interested in confidentiality should consider using the IP
   Encapsulating Security Payload (ESP) instead of or in conjunction
   with this specification [Atk95b].  Users seeking protection from
   traffic analysis might consider the use of appropriate link
   encryption.  Description and specification of link encryption is
   outside the scope of this note [VK83].  Users interested in combining
   the IP Authentication Header with the IP Encapsulating Security
   Payload should consult the IP Encapsulating Security Payload
   specification for details.

   One particular issue is that in some cases a packet which causes an
   error to be reported back via ICMP might be so large as not to
   entirely fit within the ICMP message returned.  In such cases, it
   might not be possible for the receiver of the ICMP message to
   independently authenticate the portion of the returned message.  This
   could mean that the host receiving such an ICMP message would either



Atkinson                    Standards Track                    [Page 10]

RFC 1826                IP Authentication Header             August 1995


   trust an unauthenticated ICMP message, which might in turn create
   some security problem, or not trust and hence not react appropriately
   to some legitimate ICMP message that should have been reacted to.  It
   is not clear that this issue can be fully resolved in the presence of
   packets that are the same size as or larger than the minimum IP MTU.
   Similar complications arise if an encrypted packet causes an ICMP
   error message to be sent and that packet is truncated.

   Active attacks are now widely known to exist in the Internet [CER95].
   The presence of active attacks means that unauthenticated source
   routing, either unidirectional (receive-only) or with replies
   following the original received source route represents a significant
   security risk unless all received source routed packets are
   authenticated using the IP Authentication Header or some other
   cryptologic mechanism.  It is noteworthy that the attacks described
   in [CER95] include a subset of those described in [Bel89].

   The use of IP tunneling with AH creates multiple pairs of endpoints
   that might perform AH processing.  Implementers and administrators
   should carefully consider the impacts of tunneling on authenticity of
   the received tunneled packets.

ACKNOWLEDGEMENTS

   This document benefited greatly from work done by Bill Simpson, Perry
   Metzger, and Phil Karn to make general the approach originally
   defined by the author for SIP, SIPP, and finally IPv6.

   The basic concept here is derived in large part from the SNMPv2
   Security Protocol work described in [GM93].  Steve Bellovin, Steve
   Deering, Frank Kastenholz, Dave Mihelcic, and Hilarie Orman provided
   thoughtful critiques of early versions of this note.  Francis Dupont
   discovered and pointed out the security issue with ICMP in low IP MTU
   links that is noted just above.

REFERENCES

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

   [Atk95b] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
            NRL, August 1995.

   [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol
           Suite", ACM Computer Communications Review, Vol. 19, No. 2,
           March 1989.





Atkinson                    Standards Track                    [Page 11]

RFC 1826                IP Authentication Header             August 1995


   [BCCH94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
            of IAB Workshop on Security in the Internet Architecture",
            RFC 1636, USC/Information Sciences Institute, MIT, Trusted
            Information Systems, INRIA, June 1994, pp. 21-34.

   [CER95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks
           and Hijacked Terminal Connections", CA-95:01, January 1995.
           Available via anonymous ftp from info.cert.org in
           /pub/cert_advisories.

   [GM93]  Galvin J., and K. McCloghrie, "Security Protocols for
           version 2 of the Simple Network Management Protocol
           (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN
           Systems, April 1993.

   [Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6)
           Specification, Work in Progress, October 1994.

   [Ken91] Kent, S., "US DoD Security Options for the Internet Protocol",
           RFC 1108, BBN Communications, November 1991.

   [Kno93] Knowles, Stev, "IESG Advice from Experience with Path MTU
           Discovery", RFC 1435, FTP Software, March 1993.

   [MS95]  Metzger, P., and W. Simpson, "IP Authentication with Keyed
           MD5", RFC 1828, Piermont, Daydreamer, August 1995.

   [MD90]  Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
           DECWRL, Stanford University, November 1990.

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

   [Riv92] Rivest, R., "MD5 Digest Algorithm", RFC 1321, MIT and RSA Data
           Security, Inc., April 1992.

   [VK83]  V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level
           Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.













Atkinson                    Standards Track                    [Page 12]

RFC 1826                IP Authentication Header             August 1995


DISCLAIMER

   The views and specification here are those of the author and are not
   necessarily those of his employer.  The Naval Research Laboratory has
   not passed judgement on the merits, if any, of this work.  The author
   and his employer specifically disclaim responsibility for any
   problems arising from correct or incorrect implementation or use of
   this specification.

AUTHOR INFORMATION

   Randall Atkinson
   Information Technology Division
   Naval Research Laboratory
   Washington, DC 20375-5320
   USA

   Phone:  (202) 767-2389
   Fax:    (202) 404-8590
   EMail:  atkinson@itd.nrl.navy.mil































Atkinson                    Standards Track                    [Page 13]