[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                    Randall Atkinson
Internet Draft                                  Naval Research Laboratory
draft-ietf-ipngwg-auth-00.txt                            16 February 1995




                       IPv6 Authentication Header




STATUS OF THIS MEMO

     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 6 months.
   Internet Drafts 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".  Please check the I-D abstract listing contained
   in each Internet Draft directory to learn the current status of this
   or any other Internet Draft.

     This particular Internet Draft is a product of the IETF's IPng
   Working Group.  It is intended that a future version of this draft
   will be submitted for consideration as a standards-track document.
   Distribution of this document is unlimited.  Discussion of this draft
   may be posted to the IPng WG mailing list: ipng@sunroof.eng.sun.com
   Administrative requests regarding that mailing list should always be
   sent to: ipng-request@sunroof.eng.sun.com

1. INTRODUCTION & OVERVIEW

     The Internet community is working on a transition from version 4 of
   the Internet Protocol (IPv4) to version 6 of the Internet Protocol
   (IPv6).  This memo describes the IPv6 Authentication Header.  This
   optional header provides strong integrity and authentication for IPv6
   datagrams.  Non-repudiation might be provided by an authentication
   algorithm used with the Authentication Header, but it is not provided
   with all authentication algorithms that might be used.
   Confidentiality, and protection from traffic analysis are not provided
   by the Authentication Header.  Users desiring confidentiality should
   consider using the IPv6 Encapsulating Security Protocol (ESP) either
   in lieu of or in conjunction with the Authentication Header. [Atk95b]



Atkinson                                                        [Page 1]


Internet Draft         IPv6 Authentication Header       16 February 1995


   This document assumes the reader has previously read and understood
   the related IPv6 Security Architecture document which defines the
   overall security architecture for IPv6 and provides important
   background information for this specification. [Atk95a]

     The IPv6 Authentication Header seeks to provide security by
   adding authentication information to an IPv6 datagram. This
   authentication information is calculated using all of the fields in
   the IPv6 datagram (including not only the IPv6 Header but also other
   headers and the user data) which do not change in transit.  Fields
   which need to change in transit (e.g "hop count" or "routing pointer")
   are omitted from 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 IPv6 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 IPv6
   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 and systems that aren't participating in
   the authentication MAY ignore the Authentication Data.  The
   Authentication Header is normally placed after the Hop-by-Hop header,
   which is examined at each hop, and before the End-to-End Header, which
   is never examined at an intermediate hop.  The information in the
   other IPv6 headers is used to route the datagram from origin to
   destination.

     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.






Atkinson                                                        [Page 2]


Internet Draft         IPv6 Authentication Header       16 February 1995


2. KEY MANAGEMENT

     Key management is an important part of the IPv6 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.  IPv6 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 Association Identifier (SAID), 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 IPv6 Authentication Header will need to read that 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).  The SAID value is
   typically used as the index into that logical table of security
   configuration data.

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

3. PAYLOAD SYNTAX

     The Authentication Header normally appears after the IPv6 Hop-by-Hop
   Header and before the IPv6 End-to-End Header.  The Authentication
   Header consists of a few clear text fields and then the authentication
   data.  The authentication data is the output of the authentication
   algorithm calculated over the invariant portions of the entire IPv6
   datagram.  The Authentication Data field itself is ignored only during
   the authentication calculation.  All other Authentication Header
   fields are included in the authentication calculation normally.  A
   high-level diagram of an IPv6 datagram with the Authentication Header
   follows.  The IPv6 Authentication Header has been assigned the
   protocol number 51 by the Internet Assigned Numbers Authority (IANA).
   The IPv6 header immediately prior to the Authentication Header shall
   use the number 51 to indicate the the following header is the IPv6
   Authentication Header.




Atkinson                                                        [Page 3]


Internet Draft         IPv6 Authentication Header       16 February 1995


 +-------------+-------------------------+--------------+---------+---------+
 | IPv6 Header | Routing/Hop-by-Hop Hdrs |  Auth Header | E2E Hdr | TCP/UDP |
 +-------------+-------------------------+--------------+---------+---------+

     The IPv6 Header is the conventional IPv6 Header defined by others in
   a separate Internet Draft.  The IPv6 Authentication Header has the
   following syntax:

     +--------------+-----------------+----------------+------------+
     | Next Payload | Length          |  RESERVED                   |
     +--------------+-----------------+----------------+------------+
     |              Security Association Identifier                 |
     +--------------+---------------+----------------+--------------+
     | Authentication Data (variable number of 64-bit double words) |
     +--------------+---------------+----------------+--------------+
     |                     (more Authentication Data)               |
     +--------------+---------------+----------------+--------------+

   NEXT PAYLOAD
        8 bits wide.  Identifies the next payload after the Authentication
      Payload (as is normal for IPv6).

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

   RESERVED
        Reserved for future use.  MUST be set to all zeros when sent and
      ignored upon receipt.

   SECURITY ASSOCIATION IDENTIFIER (SAID)

        A 32-bit pseudo-random value identifying the security association
      for this datagram.  If no security association has been established,
      the value of this field shall be 0x00000000.  The set of SAID values
      in the range 0x00000001 through 0x000000FF are reserved for future
      use.  A security association is normally one-way.  An authenticated
      communications session between two hosts will normally have two SAIDs
      in use (one in each direction).  The combination of SAID value and
      destination address uniquely identifies the security association.  The
      destination address may, of course, be a multicast group address.

        This receiver-orientation implies that, in the case of unicast
      traffic, the destination system will usually select the SAID value.
      By having the destination select the SAID value, there is no potential
      for manually configured security associations to have SAID values that
      conflict with automatically configured (e.g. via a key management



Atkinson                                                        [Page 4]


Internet Draft         IPv6 Authentication Header       16 February 1995


      protocol) security associations.  For multicast traffic, there are
      multiple destination systems but a single destination multicast group
      so some system or person will need to select SAIDs for that multicast
      group and then communicate the information to all of the legitimate
      members of that multicast group via mechanisms not defined here.

        Multicast groups MAY share a common SAID for all communications if
      all communications are authenticated using the same security
      configuration parameters (e.g. algorithm, key, etc.).  In this case, a
      receiver only knows that the message came from a system which knew the
      security association data for that multicast group.  A receiver cannot
      generally authenticate which host sent the multicast traffic when
      symmetric algorithms are in use.  Multicast traffic MAY also use a
      separate SAID for each sender to the multicast group.  In this case,
      the originating system is fully authenticatable when each sender uses
      a different SAID and security configuration and asymmetric algorithms
      are in use.

        Each SAID value implies the key(s) used with the authentication
      algorithm, the authentication algorithm and its mode, the block size
      (if any), initialisation vectors (if any) of the authentication
      algorithm, and (optionally) the security classification level
      associated with this key and session.  As is discussed in greater
      detail in the IPv6 Security Architecture document, IPv6 will normally
      use implicit security classification labels rather than the explicit
      labels that are used for IPv4. [Ken91] [Atk95a]

        The sending host uses the sending userid and destination host to
      select an appropriate Security Association (and hence SAID value).
      The receiving host uses the combination of SAID value and originating
      address to distinguish the correct association.  Hence, an
      Authentication Header implementation will always be able to use the
      SAID in combination with the 128-bit Destination Address to determine
      the security association and related security configuration data for
      all valid incoming packets.

   AUTHENTICATION DATA
        This data carried in this field is variable length, but the field
      size is always an integral number of 64-bit double words. The
      authentication data fills the field beginning immediately after the
      SAID field and continuing until all the authentication data is in
      place.  If the Authentication Data field is longer than necessary to
      store the actual authentication data, then the unused trailing bit
      positions MUST be ignored by the receiver.







Atkinson                                                        [Page 5]


Internet Draft         IPv6 Authentication Header       16 February 1995


4. CALCULATION OF THE AUTHENTICATION DATA

     The authentication data is usually calculated using a message digest
   algorithm (e.g. 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
   this header.  Because conventional checksums (e.g.  CRC-16) are not
   cryptographically strong and can be reverse-engineered, they MUST NOT
   be used with the Authentication Header.  If a block-oriented
   authentication algorithm (e.g. MD5, MD4) is in use and the IPv6 packet
   is not an integral number of blocks, the authentication data
   calculation is performed using zero bytes at the end to pad the length
   out to an integral number of blocks.  [Riv92] These block padding
   bytes are not included in the actual IPv6 datagram and are not sent
   over the wire because adding padding at that point in IP protocol
   processing would make implementation of the MTU related calculations
   very difficult.

     When a keyed message digest algorithm (e.g. MD5) is used, the secret
   key is fed into the algorithm first, followed by the invariant fields
   of the IPv6 datagram in sequence.  Fields which will necessarily vary
   in transit from the sender to the receiver (e.g. Hop Count) are
   included in the calculation but the value zero is substituted for the
   actual value of such fields in the IPv6 packet.  This substitution of
   zero is used instead of omitting those fields because it preserves
   64-bit alignment throughout the authentication data calculation and
   thereby can significantly improve performance.  At the very end, the
   secret key is fed in to the keyed message digest algorithm again.

     The secret key is fed in first because that increases the work
   function for someone attempting to cryptanalyse the key from knowledge
   of the packet data and the Authentication Data of the Authentication
   Header.  Feeding the key in first also permits implementations to
   precompute the start of the hash for a given destination and possibly
   improve performance thereby.  The key is fed in again at the end to
   provide additional assurance for the authentication mechanism.

     The sender MUST compute the authentication over the packet as it
   will appear at the receiver.  This requirement is placed in order to
   allow for future IPv6 optional headers which the receiver might not
   know about but the sender necessarily knows about if it is including
   such options in the packet.  The sender places the calculated message
   digest algorithm output into the Authentication Data field within the
   Authentication Header.

     Upon receipt of a packet containing an IPv6 Authentication Header,
   the receiver independently calculates the authentication data for the
   received packet.  It then compares the received Authentication Data



Atkinson                                                        [Page 6]


Internet Draft         IPv6 Authentication Header       16 February 1995


   field contents with the calculated authentication value. If the two
   match, then the datagram is accepted as authentic.  If they differ,
   then the receiver SHOULD discard the received IPv6 datagram as
   non-authentic and MUST audit the authentication failure using normal
   operating system procedures.

     Not all of the fields of the IPv6 Hop-by-Hop Options header are
   included in the authentication calculation.  The third-highest-order
   bit of the Option Type field within the Hop-by-Hop Options Header
   indicates whether any particular option is included within the
   authentication calculation or is omitted from the authentication
   calculation.  If the particular option is to be omitted, that option
   is skipped over during the authentication calculation as if it were
   not present.  Because of this bit encoding, an implementation can
   authenticate newly defined hop-by-hop options without having to modify
   the authentication portion of the IPv6 implementation.  The IPv6
   specification provides additional information on the IPv6 Hop-by-Hop
   Options Header. [Hin94]

5. CONFORMANCE REQUIREMENTS

     Implementations that claim conformance or compliance with this
   specification MUST fully implement the option described here, MUST
   support user-to-user manual key distribution for use with this option,
   and MUST support the use of keyed MD5 as described in Appendix A of
   this document.  Support for host-to-host manual key distribution MAY
   also be present.  Support for other authentication algorithms is not
   mandatory to comply or conform with this specification.  Implementors
   should consult the most recent version of the IAB Official Standards
   document for further guidance on the status of this document.

6. SECURITY CONSIDERATIONS

     This entire RFC discusses an authentication mechanism for IPv6.
   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 IPv6 Authentication Header and IPv6
   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 methods to develop all of the security relevant parts of



Atkinson                                                        [Page 7]


Internet Draft         IPv6 Authentication Header       16 February 1995


   their products.

     Users interested in confidentiality should consider using the IPv6
   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 IPv6
   Authentication Header with the IPv6 Encapsulating Security Payload
   should consult the IPv6 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
   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 IPv6 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].  This 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 IPv6
   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 basic concept here is derived in large part from the SNMPv2
   Security Protocol work described in [GM93].  Steve Bellovin, Steve
   Deering, Frank Kastenholz, and Dave Mihelcic provided useful critiques
   of early versions of this draft.  Francis Dupont discovered and
   pointed out the ICMP security issue noted just above.

REFERENCES
   [Atk95a] Randall Atkinson, IPv6 Security Architecture, Internet Draft,
           draft-atkinson-ipng-sec-01.txt,  15 February 1995.

   [Atk95a] Randall Atkinson, IPv6 Encapsulating Security Payload, Internet
           Draft, draft-atkinson-ipng-esp-01.txt, 15 February 1995.



Atkinson                                                        [Page 8]


Internet Draft         IPv6 Authentication Header       16 February 1995


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

   [BCCH94] 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.

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

   [Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6) Specification,
           draft-hinden-ipv6-spec-00.txt, October 1994.

   [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol",
           RFC-1108, DDN Network Information Center, November 1991.

   [Riv92] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, DDN Network Information
           Center, April 1992.

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

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 INFORATION

   Randall Atkinson <atkinson@itd.nrl.navy.mil>
   Information Technology Division
   Naval Research Laboratory
   Washington, DC 20375-5320
   USA

   Phone:  (DSN) 354-8590
   Fax:    (DSN) 354-7942





Atkinson                                                        [Page 9]


Internet Draft         IPv6 Authentication Header       16 February 1995


APPENDIX A: USE OF KEYED MD5 WITH THE IPv6 Authentication Header

     This section describes the use of the MD5 message digest algorithm
   with the IPv6 Authentication Header to provide integrity and
   authentication.  A 128-bit digest is calculated over the invariant
   portion of the entire IPv6 datagram and the result is included in the
   Authentication Data field of the IPv6 Authentication Header.  The
   specification of MD5 in RFC-1321 includes a portable 'C' programming
   language description of the MD5 algorithm.  [Riv92]

     The secret authentication key used with the IPv6 Authentication
   Header MUST be 128 bits long.  The key SHOULD be a pseudo-random
   number, not a guessable string of any sort.

     The 128-bit digest shall be calculated as described in Section 3 of
   RFC-1321.  The "b-bit message" referred to in RFC-1321 shall consist
   of the 128 bit secret authentication key prepended to the invariant
   fields of the entire IPv6 datagram in the order they appear in the
   IPv6 datagram.

     All IPv6 headers and payloads that are present MUST be included in
   the computation, with header fields whose value varies in transit
   (e.g. Hop Count) being assumed to contain all zeros for the purpose of
   the authentication calculation.  For the purposes of the calculation,
   the Authentication Data field of the IPv6 Authentication Payload is
   considered to contain all zeros.  Because MD5's output is naturally
   64-bit aligned, there is no wasted space in the Authentication Data
   field.























Atkinson                                                       [Page 10]