One document matched: draft-ietf-ipngwg-auth-00.txt
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) |
+--------------+---------------+----------------+--------------+
_N_E_X_T _P_A_Y_L_O_A_D
8 bits wide. Identifies the next payload after the Authentication
Payload (as is normal for IPv6).
_P_A_Y_L_O_A_D _L_E_N_G_T_H
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.
_R_E_S_E_R_V_E_D
Reserved for future use. MUST be set to all zeros when sent and
ignored upon receipt.
_S_E_C_U_R_I_T_Y _A_S_S_O_C_I_A_T_I_O_N _I_D_E_N_T_I_F_I_E_R (_S_A_I_D)
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.
_A_U_T_H_E_N_T_I_C_A_T_I_O_N _D_A_T_A
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]
| PAFTECH AB 2003-2026 | 2026-04-23 06:05:10 |