Internet DRAFT - draft-ietf-ipsec-ah

draft-ietf-ipsec-ah




Network Working Group                                          P Metzger
Internet Draft                                               W A Simpson
expires in six months                                       January 1995


                    IPv4 Authentication Header (4AH)
                       draft-ietf-ipsec-ah-00.txt



Status of this Memo

   This document is a submission to the IP Security Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the ipsec@ans.net mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is not appropriate to use Internet Drafts as
   reference material, or to cite them other than as a ``working draft''
   or ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
   Directories on:

      ftp.is.co.za (Africa)
      nic.nordu.net (Europe)
      ds.internic.net (US East Coast)
      ftp.isi.edu (US West Coast)
      munnari.oz.au (Pacific Rim)



Abstract

   This document describes an authentication mechanism for IPv4, by
   inserting an intervening header between the IPv4 Header and any
   transport headers.





Troublemakers            expires in six months                  [Page 1]
DRAFT                             4AH                       January 1995


1.  Introduction

   The Authentication Header (AH) seeks to provide integrity and
   authentication for IP datagrams.  It may also provide non-
   repudiation, depending on which algorithm is used.

   Users desiring confidentiality should consider using the
   Encapsulating Security Protocol (ESP) [RAesp], either in lieu of or
   in conjunction with the Authentication Header.

   This document assumes that the reader is familiar with the related
   document "IPv4 Security Overview" [RAsa], which defines the overall
   security plan for IPv4, and provides important background for this
   specification.



1.1.  Overview

   The Authentication Header (AH) seeks to provide security by adding
   authentication information to an IP datagram.  The authentication
   information is calculated using all of the fields in the IP datagram
   which do not change in transit.  This includes portions of the IP
   Header, transport headers, and the user data.

   In order for the Authentication Header to work properly without
   changing the entire Internet infrastructure (particularly non-
   participating routers), the authentication data is carried in its own
   IP protocol payload.  Nodes that aren't participating in the
   authentication ignore the Authentication Header.

   In some environments, intermediate routing authentication might be
   desirable [RFC-1636].  If an asymmetric authentication algorithm is
   used, then the routers performing such intermediate authentication
   would need to be aware of the appropriate public keys and
   authentication algorithm.  The routers could authenticate the traffic
   being handled, without being able to forge or modify otherwise
   legitimate traffic.

   If a symmetric authentication algorithm is used, then the routers
   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.

   Use of this specification will increase the protocol processing costs
   in participating systems, and will also increase the communications



Troublemakers            expires in six months                  [Page 1]
DRAFT                             4AH                       January 1995


   latency.  The increased latency is primarily due to time required for
   calculation of the authentication data by the sender, and the
   calculation and comparison of the authentication data by the
   receiver, over each datagram containing an Authentication Header.
   The impact will vary with authentication algorithm used and other
   factors, but is expected to be relatively inexpensive to implement.



1.2.  Key Management

   Key management is an important part of the IP security architecture.
   A scalable standard Internet key management protocol is needed to
   make widespread use of authentication practical.

   However, in order to facilitate early adoption, manual key management
   is the only key management technique required by this specification.

   The only coupling between key management and the AH is the Security
   Association Identifier (SAID), which is described in more detail
   later.  This 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.  Thus, key management is specified in a separate
   specification [TBD].

      Nota Bene: It is intended that the key management mechanisms being
      developed in other IETF Working Groups will be useful for both
      IPv4 and IPv6.



1.3.  Security Associations

   The key management mechanism is used to negotiate a number of
   parameters for each Security Association between the communicating
   parties.  This includes the key(s) used to generate the
   authentication data, and also other parameters (such as the
   authentication algorithm and mode).

   The key management protocol implementation usually maintains a table
   containing the several parameters for each current Security
   Association.  The AH implementation needs to access that security
   parameter table to determine how to process each datagram.

   The Security Association Identifier (SAID) is assigned by the entity



Troublemakers            expires in six months                  [Page 2]
DRAFT                             4AH                       January 1995


   controlling the Destination IP address of the Security Association.
   The selection mechanism used for the SAID is implementation
   dependent.

      A given Destination is not necessarily in control of the
      negotiation process.  In the case of multicast groups, a single
      node or cooperating subset of the multicast group may work on
      behalf of the entire group to set up a Security Association.

   A session between two nodes will normally have two SAID values (one
   in each direction).  The nodes use the combination of SAID and IP
   Destination to distinguish the correct association.

   Senders to a multicast group may share a common Security Association,
   if all communications are authenticated using the same security
   configuration parameters.  In this case, the receiver only knows that
   the message came from a node knowing the Security Association for the
   group, and cannot authenticate which member of the group sent the
   datagram when symmetric algorithms are in use.

   Multicast groups may also use a separate Security Association value
   for each Source.  If each sender is keyed separately and asymmetric
   algorithms are used, data origin authentication is also provided.



1.4.  Mechanisms

   It is intended that the AH format should be sufficiently general to
   permit the specification of new mechanisms as new cryptographic
   algorithms are developed.

   Each SAID value indicates the algorithm and mode used, the block size
   (if any) of the algorithm, and the presence/absence and size of a
   cryptographic synchronization or initialization vector field.  These
   parameters are described in companion mechanism documents.

   The authentication mechanism uses a message digest algorithm (such as
   MD5), either encrypting that message digest or keying the message
   digest directly.  Because conventional checksums (such as CRC-16) are
   not cryptographically strong and can be easily reversed, they MUST
   NOT be used with the Authentication Header.









Troublemakers            expires in six months                  [Page 3]
DRAFT                             4AH                       January 1995


2.  Payload Format

   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 header immediately
   preceding the Authentication Header will always contain the value
   <TBD> in its Next Header (Protocol) field.

   +-----------+-----------------+-----------+---------+-----------+
   | IP Header | Routing/Hop-Hop | Auth Head | End-End | Transport |
   +-----------+-----------------+-----------+---------+-----------+




2.1.  Header Fields

   A more detailed diagram of the Authentication Header follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |    Length     |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Security Association Identifier (SAID)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Authentication Data                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Next Header

      Identifies the next header after the Authentication Header, using
      the IP Protocol/Payload value.  Up-to-date values of the IP
      Protocol/Payload are specified in the most recent "Assigned
      Numbers" [RFC-1700].

   Length

      The length of the Authentication Data field in 64-bit increments.
      Minimum value is 0, which is only used in the degenerate case of a
      "null" authentication algorithm.

   Security Association Identifier (SAID)

      A value identifying the Security Association for this datagram.
      If no Security Association has been established, the value of this
      field is zero.



Troublemakers            expires in six months                  [Page 4]
DRAFT                             4AH                       January 1995


      SAID values in the range 0xFFFFFFF1 through 0xFFFFFFFF are
      reserved for future use.

   Authentication Data

      The length of this field is variable, but is always an integral
      number of 64-bits.

      An implementation will normally use the SAID to determine the
      field's size and use.  It retains the same format for all
      datagrams of any given SAID and IP Destination.

      The Authentication Data fills the field beginning immediately
      after the SAID field.  If the field is longer than necessary to
      store the actual authentication data, then the unused bit
      positions MUST be ignored by the receiver.  Each mechanism will
      have such special processing instructions included in its
      specification.

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



3.  Processing

   This chapter describes the steps taken when the AH is in use between
   two communicating parties.

   The sender first determines if a Security Association has been
   established with the target Destination.  If not, then the key
   management mechanism is used to establish the SAID for this
   communications session prior to the use of the AH.

   If an unauthenticated datagram arrives from a Source after a SAID has
   been established, or a SAID is received which is not valid, then an
   error is indicated.  The datagram is discarded, and an appropriate
   ICMP message is returned.  The failure SHOULD be recorded in the
   system or audit log, including the cleartext values for the SAID,
   date/time, Source, Destination, and other identifying information.

   Multicast is different from unicast only in the area of key
   management.








Troublemakers            expires in six months                  [Page 5]
DRAFT                             4AH                       January 1995


3.1.  Calculation

   The Authentication Data is the output of the authentication algorithm
   calculated over the invariant portions of the entire IPv4 datagram.
   The sender places this algorithm output into the Authentication Data
   field within the Authentication Header.

   When a keyed message digest algorithm is used (such as MD5), the
   secret key is fed into the algorithm first, followed by the invariant
   fields of the IP datagram in sequence.

      The secret key is fed in first, because that increases the work
      function for someone attempting to cryptanalyse the key from
      knowledge of the plaintext datagram.  Feeding the secret key in
      first also permits implementations to precompute the start of the
      hash for a given destination, and possibly improve performance
      thereby.

      The key does not need to be fed in at the end.  Including the IP
      Header's invariant Total Length field in the authentication
      calculation precludes appending attacks.

   Fields which will necessarily vary in transit from the sender to the
   receiver (such as the Hop Count), are included in the calculation,
   but the value zero is substituted for the actual value of such
   fields.

   The Authentication Data field itself is also zeroed during the
   calculation.  All other Authentication Header fields are included.

      This substitution of zero is used instead of omitting those
      fields, because it preserves alignment of the data during
      calculation, which can significantly improve performance.

   If a block-oriented authentication algorithm is in use (such as MD2,
   MD4, MD5), and the IP datagram is not an integral number of blocks,
   the authentication data calculation is performed using zero bytes at
   the end of the datagram to pad the length out to an integral number
   of blocks.

      These block padding bytes are not included in the actual IP
      datagram, and are not sent over the link.  Adding padding at that
      point in protocol processing could make implementation of MTU
      related calculations very difficult.

   The sender MUST compute the calculation over the datagram as it will
   appear at the receiver.  This requirement allows for future
   intervening headers which are removed or altered during transit.  The



Troublemakers            expires in six months                  [Page 6]
DRAFT                             4AH                       January 1995


   sender needs to know the final values when including such headers in
   the datagram.  Each such header will have special processing
   instructions included in its specification.

   Upon receipt of a datagram containing an Authentication Header, the
   receiver independently calculates the authentication data.  It
   compares the received Authentication Data field contents with the
   calculated authentication value.

   If they differ, then the receiver SHOULD discard the received IP
   datagram, and return an appropriate ICMP message.  The failure MUST
   be recorded in the system or audit log, as described earlier.



Security Considerations

   This specification is principly concerned with a security mechanism
   for use with IP.  This mechanism is not a panacea, but it does
   provide an important component useful in creating 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 that has been implemented, 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 systems.

   If any of these assumptions do not hold, then little or no real
   security will be provided to the user.  Implementers are encouraged
   to use high assurance development techniques to develop all of the
   security relevant parts of their products.



Acknowledgements

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

   The basic concept is derived in large part from the work done for
   SNMPv2 [RFC-1446].

   Steve Bellovin, Steve Deering, Frank Kastenholz, and Dave Mihelcic
   provided useful critiques of earlier versions of this draft.




Troublemakers            expires in six months                  [Page 7]
DRAFT                             4AH                       January 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.

   [RAsa]   Randall Atkinson, IPv6 Security Architecture, work in
            progress, 4 November 1994.

   [RAesp]  Randall Atkinson, IPv6 Encapsulating Security Payload, work
            in progress, 4 November 1994.

   [RFC-1446]
            James Galvin & Keith McCloghrie, Security Protocols for
            version 2 of the Simple Network Management Protocol
            (SNMPv2), RFC-1446, DDN Network Information Center, April
            1993.

   [RFC-1636]
            R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of
            IAB Workshop on Security in the Internet Architecture",
            RFC-1636, DDN Network Information Center, 9 June 1994, pp.
            21-34.

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


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

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



Author's Address

   Questions about this memo can also be directed to:

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



Troublemakers            expires in six months                  [Page 8]
DRAFT                             4AH                       January 1995


      Telephone:      (DSN) 354-8590
      Fax:            (DSN) 354-7942
      <atkinson@itd.nrl.navy.mil>


      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






























Troublemakers            expires in six months                  [Page 9]
DRAFT                             4AH                       January 1995


                           Table of Contents


     1.     Introduction ..........................................    1
        1.1       Overview ........................................    1
        1.2       Key Management ..................................    2
        1.3       Security Associations ...........................    2
        1.4       Mechanisms ......................................    3

     2.     Payload Format ........................................    4
        2.1       Header Fields ...................................    4

     3.     Processing ............................................    5
        3.1       Calculation .....................................    6

     SECURITY CONSIDERATIONS ......................................    7

     ACKNOWLEDGEMENTS .............................................    7

     REFERENCES ...................................................    8

     AUTHOR'S ADDRESS .............................................    8