Network Working Group Randall Atkinson
Internet Draft Naval Research Laboratory
draft-ietf-sipp-ap-03.txt 19 April 1994
SIPP 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 SIP Plus
Working Group. It is intended that a future version of this draft
will be submitted to the IPng Area Directors and the IESG as a whole
for consideration as a standards-track document (as part of the SIP
Plus proposal for IPng). Distribution of this document is unlimited.
Discussion of this draft may be posted to the SIP Plus mailing list:
sipp@sunroof.eng.sun.com
1. INTRODUCTION & OVERVIEW
This memo describes the SIPP Authentication Header (AH). This
payload seeks to provide integrity and authentication for SIPP
datagrams. Non-repudiation may be provided by an authentication
algorithm used with AH, but it is not provided with all
authentication algorithms that might be used with AH.
Confidentiality, and protection from traffic analysis are not
provided by AH. Users desiring confidentiality should consider using
the SIPP Encapsulating Security Protocol (ESP) either in lieu of or
in conjunction with AH. This document assumes the reader has
previously read and understood the related "SIPP Security
Architecture" document which defines the overall security
Atkinson [Page 1]
Internet Draft - 2 - 19 April 1994
architecture for SIP Plus and provides important background
information for this specification.
The SIPP Authentication Header (AH) seeks to provide security by
adding authentication information to a SIPP datagram. This
authentication information is calculated using all of the fields in
the SIPP datagram (including not only the SIPP 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 SIPP 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 SIPP datagram containing an Authentication Header. The
impact will vary with authentication algorithm used and other
factors.
In order for AH 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. For performance
reasons, the AH should normally be the next to the last header (i.e.
just before TCP or UDP). The information in the other SIPP headers
is used to route the datagram from origin to destination. If a
symmetric authentication algorithm will be used, routers will not be
able to authenticate traffic because they won't have the needed
authentication keys. If an asymmetric authentication algorithm is
used and the routers are aware of the appropriate public keys and
authentication algorithm, then the routers might be able to
authenticate the traffic being handled, subject to the router being
able to parse all the headers preceding the Authentication Header,
the router having appropriate security association data, and other
such factors.
2. KEY MANAGEMENT
Key management is an important part of the SIPP 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. SIPP 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
Atkinson [Page 2]
Internet Draft - 3 - 19 April 1994
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 protocol
implementation usually creates and maintains a table containing the
several parameters for each current security association. A SIPP
Authentication Header implementation normally needs to read that
security parameter table to determine how to process each datagram
containing an AH (e.g. which algorithm/mode and key to use). The
SAID value is typically used as the index into that security
configuration table. Manual key distribution is the only key
management mechanism required by this specification. A scalable
standard Internet key management protocol is needed to make
widespread use of this mechanism practical. Such a key management
protocol should support not only SIPP, but also other Internet
protocols. Other mechanisms may also be used between cooperating
computer systems.
3. PAYLOAD SYNTAX
The Authentication Header (AH) may appear anywhere after the SIP
Plus header, but for performance reasons is best placed as the last
payload before the transport layer data. The Authentication Header
consists of a few clear text AH header fields and then the
authentication data. The authentication data is the output of the
authentication algorithm calculated over the invariant portions of
the entire SIPP 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 a SIPP datagram with
the Authentication Header follows.
+-------------+---------------------+------------------------+------------+
| SIPP Header | Other SIPP headers | Authentication Header | User Data |
+-------------+---------------------+------------------------+------------+
Atkinson [Page 3]
Internet Draft - 4 - 19 April 1994
The SIPP Header is the conventional SIPP Header defined by others
in a separate Internet Draft. The AH 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 SIPP).
_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 0x0000. The
set of SAID values in the range 0xFF01 through 0xFFFF 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
receiving host uses the combination of SAID value and originating
address to distinguish the correct association.
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 because each originating system is using a
Atkinson [Page 4]
Internet Draft - 5 - 19 April 1994
different security configuration. If asymmetric algorithms are
used, then authentication of multicast traffic is much easier.
Each SAID value implies the key(s) used with the authentication
algorithm, the authentication algorithm and its mode, the block
size (if any), and initialisation vectors (if any) of the
authentication algorithm.
_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 may be filled with arbitrary values by the
sender and shall be ignored by the receiver.
4. CALCULATION OF THE AUTHENTICATION DATA
The authentication data is usually calculated using a message
digest algorithm (e.g. MD5) or by encrypting a strong conventional
checksum (e.g. standard CRC-32 encrypted in DES). If a block-
oriented authentication algorithm is in use and the SIPP packet is
not an integral number of blocks, then the SIPP Padding option
described in the base SIPP specification should be used.
If a message digest algorithm (e.g. MD5) is used, the secret key is
fed into the algorithm first, followed by the invariant fields of the
SIPP datagram in sequence. The sender places the output from message
digest algorithm into the Authentication Data field within the
Authentication Payload, while the receiver compares the received
contents of the Authentication Data field 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 SIPP datagram as non-authentic and log the occurence to the
system log or audit log. The secret key is fed in first because that
increases the work function for someone attempting to cryptanalyse
the key from knowing the packet data and the Authentication Data of
the Authentication Header. The key is not fed in at the end because
authentication of the SIPP Header's Payload Length field precludes
appending attacks.
If the other approach is used, then the conventional checksum (e.g.
CRC-32) is calculated across the invariant fields of the SIPP
datagram in order. The sender then encrypts that checksum using the
agreed upon encryption algorithm, mode, and key, and places the
Atkinson [Page 5]
Internet Draft - 6 - 19 April 1994
encrypted checksum into the Authentication Data field of the
Authentication Header. The receiver decrypts the encrypted checksum
and compares the decrypted checksum with the checksum calculated over
the received SIPP datagram. If the checksums are identical, then the
received SIPP datagram is accepted as authentic. Otherwise the SIPP
datagram is discarded as non-authentic and the occurence is audited.
Not all of the fields of the SIPP 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 should be included within the
authentication calculation or 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 SIPP implementation. The
SIPP specification provides additional information on the SIPP Hop-
by-Hop Options Header. [5]
The fields in the SIPP Routing Header are normally reordered during
transit through the internetwork. Consequently the SIPP Routing
Header needs special processing by the sender when used with the SIPP
Authentication Header. If the outgoing SIPP datagram contains a SIPP
Routing Header, then the sender shall calculate the authentication
data as if the address sequence were already in the order it will be
when the packet arrives at the receiver. For example, if the 5
addresses in a route sequence were "S, I1, I2, I3, D", then the
sender shall calculate the authentication data as if the fields were
in the received order of "S, D, I1, I2, I3". The NEXT ADDR field of
the SIPP Routing Header is always omitted (i.e. skipped over) during
authentication calculation by both sender and receiver. The receiver
of a SIPP datagram containing a SIPP Source Routing header shall
reply using the reverse source route using only the authenticated
fields of the SIPP Source Routing header. This practice will
eliminate the current (IPv4) security problem of using source routing
to engage in a host masquerading attack, which is described by
Bellovin, while still permitting SIPP to take full advantage of these
advanced routing capabilities. [6]
5. CONFORMANCE REQUIREMENTS
Implementations that claim conformance or compliance with this
specification must fully implement the option described here, must
support 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 other algorithms with this option is not
mandatory to comply or conform with this specification. Implementors
Atkinson [Page 6]
Internet Draft - 7 - 19 April 1994
should consult the most recent version of the IAB Official Standards
document for further guidance.
6. SECURITY CONSIDERATIONS
This entire RFC discusses an authentication mechanism for SIPP.
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 AH and SIPP 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 their products.
Users interested in confidentiality should consider using the SIPP
Encapsulating Security Payload (ESP) instead of or in conjunction
with this specification. 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. [7] Users interested in combining the SIPP
Authentication Header with the SIPP Encapsulating Security Payload
should consult the SIPP Encapsulating Security Payload specification
for details.
ACKNOWLEDGEMENTS
The basic concept here is derived in large part from the SNMPv2
Security Protocol work described in [1]. Steve Bellovin, Steve
Deering, and Dave Mihelcic provided useful critiques of earlier
versions of this draft.
REFERENCES
[1] James Galvin & Keith McCloghrie, Security Protocols for version 2
of the Simple Network Management Protocol (SNMPv2), RFC-1446,
DDN Network Information Center, April 1993.
[2] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, DDN Network Information
Center, April 1992.
[3] Randall Atkinson, SIPP Security Architecture, Internet Draft,
draft-ietf-sip-sa-02.txt, 19 April 1994.
Atkinson [Page 7]
Internet Draft - 8 - 19 April 1994
[4] Randall Atkinson, SIPP Encapsulating Security Payload, Internet
Draft, draft-ietf-sipp-esp-02.txt, 19 April 1994.
[5] Steve Deering, Simple Internet Protocol Plus (SIPP) Specification,
draft-ietf-sipp-spec-00.txt, 21 February 1994.
[6] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite",
ACM Computer Communications Review, Vol. 19, No. 2, March 1989.
[7] 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.
Atkinson [Page 8]
Internet Draft - 9 - 19 April 1994
AUTHOR INFORATION
Randall Atkinson <atkinson@itd.nrl.navy.mil>
Information Technology Division
Naval Research Laboratory
Washington, DC 20375-5320
USA
Atkinson [Page 9]
Internet Draft - 10 - 19 April 1994
APPENDIX A: USE OF KEYED MD5 WITH THE SIPP Authentication Header
This section describes the use of the MD5 message digest algorithm
with the SIPP Authentication Header to provide integrity and
authentication. A 128-bit digest is calculated over the invariant
portion of the entire SIPP datagram and the result is included in the
Authentication Data field of the SIPP Authentication Header. The
specification of MD5 in RFC-1321 includes a 'C' programming language
description of the MD5 algorithm. The secret authentication key shall
be 128 bits long.
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 SIPP datagram in the order they appear in the
SIPP datagram. All SIPP headers and payloads that are present shall
be included in the computation, omitting only the specified fields
(e.g. ttl) which vary in transit, and including the user data
(e.g. TCP or UDP data) being carried in the SIPP datagram. For the
purposes of the calculation, the Authentication Data field of the SIPP
Authentication Payload shall be considered to contain all zeros. The
Sequence Number of the Authentication Header shall be included in the
authentication calculation. Because MD5's output is naturally 64-bit
aligned, there is no wasted space in the Authentication Data field.
Atkinson [Page 10]