doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc2857.txt b/doc/rfc/rfc2857.txt
new file mode 100644
index 0000000..37a69d3
--- /dev/null
+++ b/doc/rfc/rfc2857.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        A. Keromytis
+Request for Comments: 2857                     University of Pennsylvania
+Category: Standards Track                                       N. Provos
+                            Center for Information Technology Integration
+                                                                June 2000
+
+
+            The Use of HMAC-RIPEMD-160-96 within ESP and AH
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This memo describes the use of the HMAC algorithm [RFC 2104] in
+   conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an
+   authentication mechanism within the revised IPSEC Encapsulating
+   Security Payload [ESP] and the revised IPSEC Authentication Header
+   [AH].  HMAC with RIPEMD-160 provides data origin authentication and
+   integrity protection.
+
+   Further information on the other components necessary for ESP and AH
+   implementations is provided by [Thayer97a].
+
+1.  Introduction
+
+   This memo specifies the use of RIPEMD-160 [RIPEMD-160] combined with
+   HMAC [RFC 2104] as a keyed authentication mechanism within the
+   context of the Encapsulating Security Payload and the Authentication
+   Header.  The goal of HMAC-RIPEMD-160-96 is to ensure that the packet
+   is authentic and cannot be modified in transit.
+
+   HMAC is a secret key authentication algorithm.  Data integrity and
+   data origin authentication as provided by HMAC are dependent upon the
+   scope of the distribution of the secret key.  If only the source and
+   destination know the HMAC key, this provides both data origin
+   authentication and data integrity for packets sent between the two
+   parties; if the HMAC is correct, this proves that it must have been
+   added by the source.
+
+
+
+Keromytis & Provos          Standards Track                     [Page 1]
+
+RFC 2857          HMAC-RIPEMD-160-96 within ESP and AH         June 2000
+
+
+   In this memo, HMAC-RIPEMD-160-96 is used within the context of ESP
+   and AH.  For further information on how the various pieces of ESP -
+   including the confidentiality mechanism -- fit together to provide
+   security services, refer to [ESP] and [Thayer97a].  For further
+   information on AH, refer to [AH] and [Thayer97a].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+2. Algorithm and Mode
+
+   [RIPEMD-160] describes the underlying RIPEMD-160 algorithm, while
+   [RFC 2104] describes the HMAC algorithm.  The HMAC algorithm provides
+   a framework for inserting various hashing algorithms such as RIPEMD-
+   160.
+
+   HMAC-RIPEMD-160-96 operates on 64-byte blocks of data.  Padding
+   requirements are specified in [RIPEMD-160] and are part of the
+   RIPEMD-160 algorithm.  Padding bits are only necessary in computing
+   the HMAC-RIPEMD-160 authenticator value and MUST NOT be included in
+   the packet.
+
+   HMAC-RIPEMD-160-96 produces a 160-bit authenticator value.  This
+   160-bit value can be truncated as described in RFC2104.  For use with
+   either ESP or AH, a truncated value using the first 96 bits MUST be
+   supported.  Upon sending, the truncated value is stored within the
+   authenticator field.  Upon receipt, the entire 160-bit value is
+   computed and the first 96 bits are compared to the value stored in
+   the authenticator field.  No other authenticator value lengths are
+   supported by HMAC-RIPEMD-160-96.
+
+   The length of 96 bits was selected because it is the default
+   authenticator length as specified in [AH] and meets the security
+   requirements described in [RFC 2104].
+
+2.1  Performance
+
+   [Bellare96a] states that "(HMAC) performance is essentially that of
+   the underlying hash function".  [RIPEMD-160] provides some
+   performance analysis.  As of this writing no detailed performance
+   analysis has been done of HMAC or HMAC combined with RIPEMD-160.
+
+   [RFC 2104] outlines an implementation modification which can improve
+   per-packet performance without affecting interoperability.
+
+
+
+
+
+
+Keromytis & Provos          Standards Track                     [Page 2]
+
+RFC 2857          HMAC-RIPEMD-160-96 within ESP and AH         June 2000
+
+
+3. Keying Material
+
+   HMAC-RIPEMD-160-96 is a secret key algorithm.  While no fixed key
+   length is specified in [RFC 2104], for use with either ESP or AH a
+   fixed key length of 160-bits MUST be supported.  Key lengths other
+   than 160-bits SHALL NOT be supported.  A key length of 160-bits was
+   chosen based on the recommendations in [RFC 2104] (i.e. key lengths
+   less than the authenticator length decrease security strength and
+   keys longer than the authenticator length do not significantly
+   increase security strength).
+
+   [RFC 2104] discusses requirements for key material, which includes a
+   discussion on requirements for strong randomness.  A strong pseudo-
+   random function MUST be used to generate the required 160-bit key.
+   Implementors should refer to RFC 1750 for guidance on the
+   requirements for such functions.
+
+   At the time of this writing there are no specified weak keys for use
+   with HMAC.  This does not mean to imply that weak keys do not exist.
+   If, at some point, a set of weak keys for HMAC are identified, the
+   use of these weak keys must be rejected followed by a request for
+   replacement keys or a newly negotiated Security Association.
+
+   [ESP] describes the general mechanism to obtain keying material for
+   the ESP transform.  The derivation of the key from some amount of
+   keying material does not differ between the manual and automatic key
+   management mechanisms.
+
+   In order to provide data origin authentication, the key distribution
+   mechanism must ensure that unique keys are allocated and that they
+   are distributed only to the parties participating in the
+   communication.
+
+   [RFC 2104] states that for "minimally reasonable hash functions" the
+   "birthday attack" is impractical.  For a 64-byte block hash such as
+   HMAC-RIPEMD-160-96, an attack involving the successful processing of
+   2**64 blocks would be infeasible unless it were discovered that the
+   underlying hash had collisions after processing 2**30 blocks.  (A
+   hash with such weak collision-resistance characteristics would
+   generally be considered to be unusable.) No time-based attacks are
+   discussed in the document.
+
+   While it it still cryptographically prudent to perform frequent
+   rekeying, current literature does not include any recommended key
+   lifetimes for HMAC-RIPEMD.  When recommendations for HMAC-RIPEMD key
+   lifetimes become available they will be included in a revised version
+   of this document.
+
+
+
+
+Keromytis & Provos          Standards Track                     [Page 3]
+
+RFC 2857          HMAC-RIPEMD-160-96 within ESP and AH         June 2000
+
+
+4.  Interaction with the ESP Cipher Mechanism
+
+   As of this writing, there are no known issues which preclude the use
+   of the HMAC-RIPEMD-160-96 algorithm with any specific cipher
+   algorithm.
+
+5.  Security Considerations
+
+   The security provided by HMAC-RIPEMD-160-96 is based upon the
+   strength of HMAC, and to a lesser degree, the strength of RIPEMD-160.
+   At the time of this writing there are no known practical
+   cryptographic attacks against RIPEMD-160.
+
+   It is also important to consider that while RIPEMD-160 was never
+   developed to be used as a keyed hash algorithm, HMAC had that
+   criteria from the onset.
+
+   [RFC 2104] also discusses the potential additional security which is
+   provided by the truncation of the resulting hash.  Specifications
+   which include HMAC are strongly encouraged to perform this hash
+   truncation.
+
+   As [RFC 2104] provides a framework for incorporating various hash
+   algorithms with HMAC, it is possible to replace RIPEMD-160 with other
+   algorithms such as SHA-1.  [RFC 2104] contains a detailed discussion
+   on the strengths and weaknesses of HMAC algorithms.
+
+   As is true with any cryptographic algorithm, part of its strength
+   lies in the correctness of the algorithm implementation, the security
+   of the key management mechanism and its implementation, the strength
+   of the associated secret key, and upon the correctness of the
+   implementation in all of the participating systems.  [Kapp97]
+   contains test vectors and example code to assist in verifying the
+   correctness of HMAC-RIPEMD-160-96 code.
+
+6.  Acknowledgements
+
+   This document is derived from work by C. Madson and R. Glenn and from
+   previous works by Jim Hughes, those people that worked with Jim on
+   the combined DES/CBC+HMAC-MD5 ESP transforms, the ANX bakeoff
+   participants, and the members of the IPsec working group.
+
+7.  References
+
+   [RIPEMD-160]  3.ISO/IEC 10118-3:1998, "Information technology -
+                 Security techniques - Hash-functions - Part 3:
+                 Dedicated hash-functions," International Organization
+                 for Standardization, Geneva, Switzerland, 1998.
+
+
+
+Keromytis & Provos          Standards Track                     [Page 4]
+
+RFC 2857          HMAC-RIPEMD-160-96 within ESP and AH         June 2000
+
+
+   [RFC 2104]    Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
+                 Keyed-Hashing for Message Authentication", RFC 2104,
+                 September, 1997.
+
+   [Bellare96a]  Bellare, M., Canetti, R., Krawczyk, H., "Keying Hash
+                 Functions for Message Authentication", Advances in
+                 Cryptography, Crypto96 Proceeding, June 1996.
+
+   [ESP]         Kent, S. and R. Atkinson, "IP Encapsulating Security
+                 Payload (ESP)", RFC 2406, November 1998.
+
+   [AH]          Kent, S. and R. Atkinson, "IP Authentication Header",
+                 RFC 2402, November 1998.
+
+   [Thayer97a]   Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
+                 Document Roadmap", RFC 2411, November 1998.
+
+   [Kapp97]      Kapp, J., "Test Cases for HMAC-RIPEMD160 and HMAC-
+                 RIPEMD128", RFC 2286, March 1998.
+
+   [RFC 1750]    Eastlake 3rd, D., Crocker, S. and J. Schiller,
+                 "Randomness Recommendations for Security", RFC 1750,
+                 December 1994.
+
+   [RFC 2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+8.  Authors' Addresses
+
+      Angelos D. Keromytis
+      Distributed Systems Lab
+      Computer and Information Science Department
+      University of Pennsylvania
+      200 S. 33rd Street
+      Philadelphia, PA 19104 - 6389
+
+      EMail: angelos@dsl.cis.upenn.edu
+
+
+      Niels Provos
+      Center for Information Technology Integration
+      University of Michigan
+      519 W. William
+      Ann Arbor, Michigan 48103 USA
+
+      EMail: provos@citi.umich.edu
+
+
+
+
+
+Keromytis & Provos          Standards Track                     [Page 5]
+
+RFC 2857          HMAC-RIPEMD-160-96 within ESP and AH         June 2000
+
+
+   The IPsec working group can be contacted through the chairs:
+
+      Robert Moskowitz
+      International Computer Security Association
+
+      EMail: rgm@icsa.net
+
+
+      Ted T'so
+      VA Linux Systems
+
+      EMail: tytso@valinux.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Keromytis & Provos          Standards Track                     [Page 6]
+
+RFC 2857          HMAC-RIPEMD-160-96 within ESP and AH         June 2000
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Keromytis & Provos          Standards Track                     [Page 7]
+