draft-ietf-ipsec-ah-md5-03.txt   rfc1828.txt 
Network Working Group P Metzger Network Working Group P. Metzger
Internet Draft W A Simpson Request for Comments: 1828 Piermont
expires in six months April 1995 Category: Standards Track W. Simpson
Daydreamer
August 1995
IP Authentication using Keyed MD5 IP Authentication using Keyed MD5
draft-ietf-ipsec-ah-md5-03.txt |
Status of this Memo Status of this Memo
This document is a submission to the IP Security Working Group of the This document specifies an Internet standards track protocol for the
Internet Engineering Task Force (IETF). Comments should be submitted Internet community, and requests discussion and suggestions for
to the ipsec@ans.net mailing list. improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
Distribution of this memo is unlimited. and status of this protocol. Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet Drafts are working Abstract
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 This document describes the use of keyed MD5 with the IP
months, and may be updated, replaced, or obsoleted by other documents Authentication Header.
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 Table of Contents
``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
Directories on:
ftp.is.co.za (Africa) 1. Introduction .......................................... 1
nic.nordu.net (Europe) 1.1 Keys ............................................ 1
ds.internic.net (US East Coast) 1.2 Data Size ....................................... 1
ftp.isi.edu (US West Coast) 1.3 Performance ..................................... 1
munnari.oz.au (Pacific Rim)
Abstract 2. Calculation ........................................... 2
This document describes the use of keyed MD5 with the IP SECURITY CONSIDERATIONS ...................................... 2
Authentication Header. ACKNOWLEDGEMENTS ............................................. 3
REFERENCES ................................................... 3
AUTHOR'S ADDRESS ............................................. 4
1. Introduction 1. Introduction
The Authentication Header (AH) [A-AH] provides integrity and The Authentication Header (AH) [RFC-1826] provides integrity and
authentication for IP datagrams. authentication for IP datagrams. This specification describes the AH
use of keys with Message Digest 5 (MD5) [RFC-1321].
This specification describes the AH use of Message Digest 5 (MD5)
[RFC-1321].
All implementations that claim conformance or compliance with the All implementations that claim conformance or compliance with the
Authentication Header specification MUST implement this MD5 Authentication Header specification MUST implement this keyed MD5
mechanism. mechanism.
Implementors should consult the most recent version of the IAB |
Standards [RFC-1720] for further guidance on the status of this
document.
This document assumes that the reader is familiar with the related This document assumes that the reader is familiar with the related
document "Security Architecture for the Internet Protocol" [A-SA], document "Security Architecture for the Internet Protocol" [RFC-
which defines the overall security plan for IP, and provides 1825], which defines the overall security plan for IP, and provides
important background for this specification. important background for this specification.
1.1. Keys 1.1. Keys
The secret authentication key shared between the communicating The secret authentication key shared between the communicating
parties SHOULD be a pseudo-random number, not a guessable string of parties SHOULD be a cryptographically strong random number, not a
any sort. guessable string of any sort.
The shared key is not constrained by this transform to any particular
size. Lengths of up to 128 bits MUST be supported by the
implementation, although any particular key may be shorter. Longer
keys are encouraged.
1.2. Data Size 1.2. Data Size
MD5's 128-bit output is naturally 64-bit aligned. Typically, there MD5's 128-bit output is naturally 64-bit aligned. Typically, there
is no further padding of the Authentication Data field. is no further padding of the Authentication Data field.
1.3. Performance 1.3. Performance
MD5 reportedly has a throughput of about 60 Mbps on a fast 64-bit MD5 software speeds are adequate for commonly deployed LAN and WAN
RISC processor with slightly tuned MD5 code [Touch94]. links, but reportedly are too slow for newer link technologies [RFC-
1810].
Nota Bene: This is possibly too slow. Suggestions are sought on Nota Bene:
alternative authentication algorithms that have significantly Suggestions are sought on alternative authentication algorithms
faster throughput, are not patent-encumbered, and still retain that have significantly faster throughput, are not patent-
adequate cryptographic strength. encumbered, and still retain adequate cryptographic strength.
2. Calculation 2. Calculation
The 128-bit digest is calculated as described in [RFC-1321]. The The 128-bit digest is calculated as described in [RFC-1321]. The
specification of MD5 includes a portable 'C' programming language specification of MD5 includes a portable 'C' programming language
description of the MD5 algorithm. description of the MD5 algorithm.
The variable length secret authentication key is zero-filled to the | The form of the authenticated message is
next 128-bit boundary, concatenated with (immediately followed by) |
the invariant fields of the entire IP datagram, concatenated with | key, keyfill, datagram, key, MD5fill
(immediately followed by) the variable length secret authentication |
key again (trailing padding is added by the MD5 algorithm). The | First, the variable length secret authentication key is filled to the
resulting 128-bit digest is inserted into the Authentication Data | next 512-bit boundary, using the same pad with length technique
defined for MD5.
Then, the filled key is concatenated with (immediately followed by)
the invariant fields of the entire IP datagram (variant fields are
zeroed), concatenated with (immediately followed by) the original
variable length key again.
A trailing pad with length to the next 512-bit boundary for the
entire message is added by MD5 itself. The 128-bit MD5 digest is
calculated, and the result is inserted into the Authentication Data
field. field.
Care must be taken that the keys and padding are not sent over the | Discussion:
link. When the implementation adds the keys and padding in place before
and after the IP datagram, care must be taken that the keys and/or
padding are not sent over the link by the link driver.
Security Considerations Security Considerations
Users need to understand that the quality of the security provided by Users need to understand that the quality of the security provided by
this specification depends completely on the strength of the MD5 hash this specification depends completely on the strength of the MD5 hash
function, the correctness of that algorithm's implementation, the function, the correctness of that algorithm's implementation, the
security of the key management mechanism and its implementation, the security of the key management mechanism and its implementation, the
strength of the key [CN94], and upon the correctness of the strength of the key [CN94], and upon the correctness of the
implementations in all of the participating nodes. implementations in all of the participating nodes.
Among other considerations, applications may wish to take care not to
select weak keys, although the odds of picking one at random are low
[Schneier94, p 233].
At the time of writing of this document, it is known to be possible At the time of writing of this document, it is known to be possible
to produce collisions in the compression function of MD5 [BB93]. to produce collisions in the compression function of MD5 [dBB93].
There is not yet a known method to exploit these collisions to attack There is not yet a known method to exploit these collisions to attack
MD5 in practice, but this fact is disturbing to some authors MD5 in practice, but this fact is disturbing to some authors
[Schneier94]. [Schneier94].
It has also recently been determined [OW94] that it is possible to It has also recently been determined [vOW94] that it is possible to
build a machine for $10 Million that could find messages that hash to build a machine for $10 Million that could find two chosen text
an arbitrary given MD5 hash. This attack requires approximately 24 variants with a common MD5 hash value. However, it is unclear
days. Although this is not a substantial weakness for most IP whether this attack is applicable to a keyed MD5 transform.
security applications, it should be recognized that current
technology is catching up to the 128-bit hash length used by MD5. This attack requires approximately 24 days. The same form of attack
Applications requiring extremely high levels of security may wish to is useful on any iterated n-bit hash function, and the time is
move in the near future to algorithms with longer hash lengths. entirely due to the 128-bit length of the MD5 hash.
Although there is no substantial weakness for most IP security
applications, it should be recognized that current technology is
catching up to the 128-bit hash length used by MD5. Applications
requiring extremely high levels of security may wish to move in the
near future to algorithms with longer hash lengths.
Acknowledgements Acknowledgements
This document was reviewed by the IP Security Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the ipsec@ans.net mailing list.
Some of the text of this specification was derived from work by Some of the text of this specification was derived from work by
Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups. Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups.
The basic concept and use of MD5 is derived in large part from the The basic concept and use of MD5 is derived in large part from the
work done for SNMPv2 [RFC-1446]. work done for SNMPv2 [RFC-1446].
Steve Bellovin, Steve Deering, Frank Kastenholz, Charles Lynn, and * Steve Bellovin, Phil Karn, Charles Lynn, Dave Mihelcic, Hilarie
Dave Mihelcic provided useful critiques of earlier versions of this Orman, Jeffrey Schiller, Joe Touch, and David Wagner provided useful
draft. critiques of earlier versions of this draft.
References References
[A-SA] Randall Atkinson, "Security Architecture for the Internet [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data:
Protocol", work in progress. Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp.
253-280, July 1994.
[A-AH] Randall Atkinson, "IP Authentication Header", work in
progress.
[BB93] B. den Boer and A. Bosselaers, "Collisions for the [dBB93] den Boer, B., and Bosselaers, A., "Collisions for the
Compression function of MD5", Advances in Cryptology -- Compression function of MD5", Advances in Cryptology --
Eurocrypt '93 Proceedings, Berlin: Springer-Verlag 1994 Eurocrypt '93 Proceedings, Berlin: Springer-Verlag 1994
[CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: [KR95] Kaliski, B., and Robshaw, M., "Message authentication with
Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. MD5", CryptoBytes (RSA Labs Technical Newsletter), vol.1
253-280, July 1994. no.1, Spring 1995.
[RFC-1321] [RFC-1321]
Ronald Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DDN Network Information Center, April 1992. MIT and RSA Data Security, Inc., April 1992.
[RFC-1446] [RFC-1446]
Galvin, J., and McCloghrie, K., "Security Protocols for Galvin, J., and K. McCloghrie, "Security Protocols for
Version 2 of the Simple Network Management Protocol Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC-1446, DDN Network Information Center, April (SNMPv2)", RFC 1446, TIS, Hughes LAN Systems, April
1993. * 1993.
[RFC-1700] [RFC-1700]
Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
1700, USC/Information Sciences Institute, October 1994. | RFC 1700, USC/Information Sciences Institute, October 1994.
[RFC-1720] | [RFC-1800]
Postel, J., "Internet Official Protocol Standards", STD 1, | Postel, J., "Internet Official Protocol Standards", STD 1,
RFC 1720, USC/Information Sciences Institute, November 1994. RFC 1800, USC/Information Sciences Institute, July 1995.
[OW94] Paul C. van Oorschot & Michael J. Wiener, "Parallel [RFC-1810]
Collision Search with Application to Hash Functions and Touch, J., "Report on MD5 Performance", RFC 1810,
Discrete Logarithms", Proceedings of the 2nd ACM Conf. USC/Information Sciences Institute, June 1995.
Computer and Communications Security, Fairfax, VA, Nov 3-5
1994. [RFC-1825]
Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 1825, NRL, August 1995.
[RFC-1826]
Atkinson, R., "IP Authentication Header", RFC 1826, NRL
August 1995.
[Schneier94] [Schneier94]
Schneier, B., "Applied Cryptography", John Wiley & Sons, New Schneier, B., "Applied Cryptography", John Wiley & Sons, New
York, NY, 1994. ISBN 0-471-59756-2 York, NY, 1994. ISBN 0-471-59756-2
[Touch94] [vOW94] van Oorschot, P. C., and Wiener, M. J., "Parallel Collision
Touch, J., "Report on MD5 Performance", work in progress, Search with Applications to Hash Functions and Discrete
December 1994. Logarithms", Proceedings of the 2nd ACM Conf. Computer and
Communications Security, Fairfax, VA, November 1994.
Author's Address Author's Address
Questions about this memo can also be directed to: Questions about this memo can also be directed to:
Perry Metzger Perry Metzger
Piermont Information Systems Inc. Piermont Information Systems Inc.
160 Cabrini Blvd., Suite #2 160 Cabrini Blvd., Suite #2
New York, NY 10033 New York, NY 10033
perry@piermont.com perry@piermont.com
William Allen Simpson William Allen Simpson
Daydreamer Daydreamer
Computer Systems Consulting Services Computer Systems Consulting Services
1384 Fontaine 1384 Fontaine
Madison Heights, Michigan 48071 Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com bsimpson@MorningStar.com
Table of Contents
1. Introduction .......................................... 1
1.1 Keys ............................................ 1
1.2 Data Size ....................................... 1
1.3 Performance ..................................... 1
2. Calculation ........................................... 2
SECURITY CONSIDERATIONS ...................................... 2
ACKNOWLEDGEMENTS ............................................. 3
REFERENCES ................................................... 3
AUTHOR'S ADDRESS ............................................. 4
 End of changes. 34 change blocks. 
100 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/