As per Relevance of the word security, we have this rfc below:
Network Working Group P.
Request for Comments: 2841
Category: Historic W.
Obsoletes: 1852
November 2000
IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC
Status of this
This memo defines a Historic Document for the Internet community.
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document describes the use of keyed SHA1 with the
Authentication Header
Table of
1. Introduction ............................................. 2
1.1. Keys ..................................................... 2
1.2. Data Size ................................................ 2
1.3. Performance .............................................. 3
2. Calculation .............................................. 3
A. Changes .................................................. 5
Security Considerations ....................................... 6
Acknowledgements .............................................. 6
References .................................................... 7
Contacts ...................................................... 8
Editor's Note ................................................. 8
Full Copyright Statement ...................................... 9
Metzger & Simpson Historic [Page 1]
RFC 2841 AH SHA1 IP-MAC November 2000
1.
The Authentication Header (AH) [RFC-1826] provides integrity
authentication for IP datagrams. This specification describes the
use of keys with the Secure Hash Algorithm (SHA1) [FIPS-180-1].
SHA1-IP-MAC algorithm uses a leading and trailing key (a variant
the "envelope method"), with alignment padding between both keys
data
It should be noted that this document specifies a newer version
SHA than that described in [FIPS-180], which was flawed.
older version is not interoperable with the newer version
This document assumes that the reader is familiar with the
document "Security Architecture for the Internet Protocol" [RFC
1825], that defines the overall security plan for IP, and
important background for this specification
1.1.
The secret authentication key shared between the
parties SHOULD be a cryptographically strong random number, not
guessable string of any sort
The shared key is not constrained by this transform to any
size. Lengths of 160-bits (20 octets) MUST be supported by
implementation, although any particular key may be shorter.
keys are encouraged
1.2. Data
SHA1's 160-bit output is naturally 32-bit aligned. However,
implementations require 64-bit alignment of the following headers
Therefore, several options are available for data alignment (
preferred to least preferred):
1) only the most significant 128-bits (16 octets) of output are used
2) an additional 32-bits (4 octets) of padding is added before
SHA1 output
3) an additional 32-bits (4 octets) of padding is added after
SHA1 output
4) the SHA1 output is variably bit-positioned within 192-bits (24
octets).
Metzger & Simpson Historic [Page 2]
RFC 2841 AH SHA1 IP-MAC November 2000
The size and position of the output are negotiated as part of the
management. Padding bits are filled with unspecified
dependent (random) values, which are ignored on receipt
Discussion
Although truncation of the output for alignment purposes
appear to reduce the effectiveness of the algorithm, some
of attack verification suggest that this may instead improve
overall robustness [PO95a].
1.3.
Preliminary results indicate that SHA1 is 62% as fast as MD5, and 80%
as fast as DES hashing. That is
SHA1 < DES < MD
This appears to be a reasonable performance tradeoff, as SHA
internal chaining is significantly longer than either DES or MD5:
DES < MD5 < SHA
Nota Bene
Suggestions are sought on alternative authentication
that have significantly faster throughput, are not patent
encumbered, and still retain adequate cryptographic strength
2.
The 160-bit digest is calculated as described in [FIPS-180-1].
portable C language implementation of SHA1 is available via FTP
ftp://rand.org/pub/jim/sha.tar.gz
The form of the authenticated message is
SHA1( key, keyfill, datagram, datafill, key, sha1fill )
First, the variable length secret authentication key is filled to
next 512-bit boundary, using the same pad-with-length
defined for SHA1. The padding technique includes a length
protects arbitrary length keys
Next, the filled key is concatenated with (immediately followed by
the invariant fields of the entire IP datagram (variant fields
zeroed). This is also filled to the next 512-bit boundary, using
same pad-with-length technique defined for SHA1. The length
the leading key and data
Metzger & Simpson Historic [Page 3]
RFC 2841 AH SHA1 IP-MAC November 2000
Then, the filled data is concatenated with (immediately followed by
the original variable length key again. A trailing pad-with-
to the next 512-bit boundary for the entire message is added by SHA
itself
Finally, the 160-bit SHA1 digest is calculated, and the result
inserted into the Authentication Data field
Discussion
The leading copy of the key is padded in order to
copying of the key at machine boundaries without requiring re
alignment of the following datagram. Filling to the SHA1
size also allows the key to be prehashed to avoid the
copy in some implementations
The trailing copy of the key is not necessary to protect
appending attacks, as the IP datagram already includes a
length field. It reintroduces mixing of the entire key,
protection for very long and very short datagrams, and
against possible attacks on the IP length field itself
When the implementation adds the keys and padding in place
and after the IP datagram, care must be taken that the keys and/
padding are not sent over the link by the link driver
Metzger & Simpson Historic [Page 4]
RFC 2841 AH SHA1 IP-MAC November 2000
A.
Changes from RFC 1852:
Use of SHA1 term (as always intended).
Added shortened 128-bit output, and clarify output text
Added tradeoff text
Changed padding technique to comply with Crypto '95 recommendations
Updated references
Updated contacts
Minor editorial changes
Metzger & Simpson Historic [Page 5]
RFC 2841 AH SHA1 IP-MAC November 2000
Security
Users need to understand that the quality of the security provided
this specification depends completely on the strength of the SHA
hash function, the correctness of that algorithm's implementation
the security of the key management mechanism and its implementation
the strength of the key, and upon the correctness of
implementations in all of the participating nodes
The SHA algorithm was originally derived from the MD4
[RFC-1320]. A flaw was apparently found in the
specification of SHA [FIPS-180], and this document specifies the
of a corrected version [FIPS-180-1].
At the time of writing of this document, there are no known flaws
the SHA1 algorithm. That is, there are no known attacks on SHA1
any of its components that are better than brute force, and the 160-
bit hash size of SHA1 is substantially more resistant to brute
attacks than the 128-bit hash size of MD4 and MD5.
However, as the flaw in the original SHA1 algorithm shows
cryptographers are fallible, and there may be
deficiencies yet to be discovered in the algorithm
Some of the text of this specification was derived from work
Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups
Preliminary performance analysis was provided by Joe Touch
Padding the leading copy of the key to a hash block boundary
increased performance was originally suggested by William
Simpson
Padding the leading copy of the key to a hash block boundary
increased security was suggested by [KR95]. Including the key
for increased security was suggested by David Wagner
Padding the datagram to a hash block boundary to avoid (
impractical) key recovery attack was suggested by [PO95b].
Metzger & Simpson Historic [Page 6]
RFC 2841 AH SHA1 IP-MAC November 2000
[FIPS-180] "Secure Hash Standard", Computer Systems Laboratory
National Institute of Standards and Technology, U.S
Department Of Commerce, May 1993.
Also known as: 58 Fed Reg 27712 (1993).
[FIPS-180-1] "Secure Hash Standard", National Institute of
and Technology, U.S. Department Of Commerce, April 1995.
Also known as: 59 Fed Reg 35317 (1994).
[KR95] Kaliski, B., and Robshaw, M., "Message
with MD5", CryptoBytes (RSA Labs Technical Newsletter),
vol.1 no.1, Spring 1995.
[PO95a] Preneel, B., and van Oorshot, P., "MDx-MAC and
Fast MACs from Hash Functions", Advances in
-- Crypto '95 Proceedings, Santa Barbara, California
August 1995.
[PO95b] Preneel, B., and van Oorshot, P., "On the Security
Two MAC Algorithms", Presented at the Rump Session
Crypto '95, Santa Barbara, California, August 1995.
[RFC 1320] Rivest, R., "The MD4 Message-Digest Algorithm",
1320, April 1992.
[RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.
[RFC 1825] Atkinson, R., "Security Architecture for the
Protocol", RFC 1825, July 1995.
[RFC 1826] Atkinson, R., "IP Authentication Header", RFC 1826,
1995.
Metzger & Simpson Historic [Page 7]
RFC 2841 AH SHA1 IP-MAC November 2000
Comments about this document should be discussed on
photuris@adk.gr mailing list
This document is a submission to the IP Security Working Group of
Internet Engineering Task Force (IETF). The working group can
contacted via the current chairs
Questions about this document can also be directed to
Perry
Piermont Information Systems Inc
160 Cabrini Blvd., Suite #2
New York, NY 10033
EMail: perry@piermont.
William Allen
Computer Systems Consulting
1384
Madison Heights, Michigan 48071
EMail: wsimpson@UMich.
wsimpson@GreenDragon.com (preferred
Editor's
This paper was originally submitted May 1, 1996.
Metzger & Simpson Historic [Page 8]
RFC 2841 AH SHA1 IP-MAC November 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Metzger & Simpson Historic [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
