doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc7321.txt b/doc/rfc/rfc7321.txt
new file mode 100644
index 0000000..779047e
--- /dev/null
+++ b/doc/rfc/rfc7321.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         D. McGrew
+Request for Comments: 7321                                 Cisco Systems
+Obsoletes: 4835                                               P. Hoffman
+Category: Standards Track                                 VPN Consortium
+ISSN: 2070-1721                                              August 2014
+
+
+ Cryptographic Algorithm Implementation Requirements and Usage Guidance
+for Encapsulating Security Payload (ESP) and Authentication Header (AH)
+
+Abstract
+
+   This document updates the Cryptographic Algorithm Implementation
+   Requirements for the Encapsulating Security Payload (ESP) and
+   Authentication Header (AH).  It also adds usage guidance to help in
+   the selection of these algorithms.
+
+   ESP and AH protocols make use of various cryptographic algorithms to
+   provide confidentiality and/or data origin authentication to
+   protected data communications in the IP Security (IPsec)
+   architecture.  To ensure interoperability between disparate
+   implementations, the IPsec standard specifies a set of mandatory-to-
+   implement algorithms.  This document specifies the current set of
+   mandatory-to-implement algorithms for ESP and AH, specifies
+   algorithms that should be implemented because they may be promoted to
+   mandatory at some future time, and also recommends against the
+   implementation of some obsolete algorithms.  Usage guidance is also
+   provided to help the user of ESP and AH best achieve their security
+   goals through appropriate choices of cryptographic algorithms.
+
+   This document obsoletes RFC 4835.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7321.
+
+
+
+
+
+
+McGrew & Hoffman             Standards Track                    [Page 1]
+
+RFC 7321               Requirements for ESP and AH           August 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+   2.  Implementation Requirements . . . . . . . . . . . . . . . . .   4
+     2.1.  ESP Authenticated Encryption (Combined Mode Algorithms) .   4
+     2.2.  ESP Encryption Algorithms . . . . . . . . . . . . . . . .   4
+     2.3.  ESP Authentication Algorithms . . . . . . . . . . . . . .   5
+     2.4.  AH Authentication Algorithms  . . . . . . . . . . . . . .   5
+     2.5.  Summary of Changes from RFC 4835  . . . . . . . . . . . .   5
+   3.  Usage Guidance  . . . . . . . . . . . . . . . . . . . . . . .   5
+   4.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   6
+     4.1.  Authenticated Encryption  . . . . . . . . . . . . . . . .   7
+     4.2.  Encryption Transforms . . . . . . . . . . . . . . . . . .   7
+     4.3.  Authentication Transforms . . . . . . . . . . . . . . . .   7
+   5.  Algorithm Diversity . . . . . . . . . . . . . . . . . . . . .   8
+   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
+
+
+
+McGrew & Hoffman             Standards Track                    [Page 2]
+
+RFC 7321               Requirements for ESP and AH           August 2014
+
+
+1.  Introduction
+
+   The Encapsulating Security Payload (ESP) [RFC4303] and the
+   Authentication Header (AH) [RFC4302] are the mechanisms for applying
+   cryptographic protection to data being sent over an IPsec Security
+   Association (SA) [RFC4301].
+
+   To ensure interoperability between disparate implementations, it is
+   necessary to specify a set of mandatory-to-implement algorithms.
+   This ensures that there is at least one algorithm that all
+   implementations will have in common.  This document specifies the
+   current set of mandatory-to-implement algorithms for ESP and AH,
+   specifies algorithms that should be implemented because they may be
+   promoted to mandatory at some future time, and also recommends
+   against the implementation of some obsolete algorithms.  Usage
+   guidance is also provided to help the user of ESP and AH best achieve
+   their security goals through appropriate choices of mechanisms.
+
+   The nature of cryptography is that new algorithms surface
+   continuously and existing algorithms are continuously attacked.  An
+   algorithm believed to be strong today may be demonstrated to be weak
+   tomorrow.  Given this, the choice of mandatory-to-implement algorithm
+   should be conservative so as to minimize the likelihood of it being
+   compromised quickly.  Thought should also be given to performance
+   considerations, as many uses of IPsec will be in environments where
+   performance is a concern.
+
+   The ESP and AH mandatory-to-implement algorithm(s) may need to change
+   over time to adapt to new developments in cryptography.  For this
+   reason, the specification of the mandatory-to-implement algorithms is
+   not included in the main IPsec, ESP, or AH specifications, but is
+   instead placed in this document.  Ideally, the mandatory-to-implement
+   algorithm of tomorrow should already be available in most
+   implementations of IPsec by the time it is made mandatory.  To
+   facilitate this, this document identifies such algorithms, as they
+   are known today.  There is no guarantee that the algorithms that we
+   predict will be mandatory in the future will actually be so.  All
+   algorithms known today are subject to cryptographic attack and may be
+   broken in the future.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+
+
+
+
+McGrew & Hoffman             Standards Track                    [Page 3]
+
+RFC 7321               Requirements for ESP and AH           August 2014
+
+
+   We define some additional keywords here:
+
+   MUST-  This term means the same as MUST.  However, we expect that at
+      some point in the future this algorithm will no longer be a MUST.
+
+   SHOULD+  This term means the same as SHOULD.  However, it is likely
+      that an algorithm marked as SHOULD+ will be promoted at some
+      future time to be a MUST.
+
+2.  Implementation Requirements
+
+   This section specifies the cryptographic algorithms that MUST be
+   implemented, and provides guidance about ones that SHOULD or SHOULD
+   NOT be implemented.
+
+   In the following sections, all AES modes are for 128-bit AES. 192-bit
+   and 256-bit AES MAY be supported for those modes, but the
+   requirements here are for 128-bit AES.
+
+2.1.  ESP Authenticated Encryption (Combined Mode Algorithms)
+
+   ESP combined mode algorithms provide both confidentiality and
+   authentication services; in cryptographic terms, these are
+   authenticated encryption algorithms [RFC5116].  Authenticated
+   encryption transforms are listed in the ESP encryption transforms
+   IANA registry.
+
+   Requirement    Authenticated Encryption Algorithm
+   -----------    ----------------------------------
+   SHOULD+        AES-GCM with a 16 octet ICV [RFC4106]
+   MAY            AES-CCM [RFC4309]
+
+2.2.  ESP Encryption Algorithms
+
+   Requirement    Encryption Algorithm
+   -----------    --------------------------
+   MUST           NULL [RFC2410]
+   MUST           AES-CBC [RFC3602]
+   MAY            AES-CTR [RFC3686]
+   MAY            TripleDES-CBC [RFC2451]
+   MUST NOT       DES-CBC [RFC2405]
+
+
+
+
+
+
+
+
+
+
+McGrew & Hoffman             Standards Track                    [Page 4]
+
+RFC 7321               Requirements for ESP and AH           August 2014
+
+
+2.3.  ESP Authentication Algorithms
+
+   Requirement    Authentication Algorithm (notes)
+   -----------    -----------------------------
+   MUST           HMAC-SHA1-96 [RFC2404]
+   SHOULD+        AES-GMAC with AES-128 [RFC4543]
+   SHOULD         AES-XCBC-MAC-96 [RFC3566]
+   MAY            NULL [RFC4303]
+
+   Note that the requirement level for NULL authentication depends on
+   the type of encryption used.  When using authenticated encryption
+   from Section 2.1, the requirement for NULL encryption is the same as
+   the requirement for the authenticated encryption itself.  When using
+   the encryption from Section 2.2, the requirement for NULL encryption
+   is truly "MAY"; see Section 3 for more detail.
+
+2.4.  AH Authentication Algorithms
+
+   The requirements for AH are the same as for ESP Authentication
+   Algorithms, except that NULL authentication is inapplicable.
+
+2.5.  Summary of Changes from RFC 4835
+
+   The following is a summary of the changes from RFC 4835.
+
+   Old            New
+   Requirement    Requirement      Algorithm (notes)
+   ----           -----------      -----------------
+   MAY            SHOULD+          AES-GCM with a 16 octet ICV [RFC4106]
+   MAY            SHOULD+          AES-GMAC with AES-128 [RFC4543]
+   MUST-          MAY              TripleDES-CBC [RFC2451]
+   SHOULD NOT     MUST NOT         DES-CBC [RFC2405]
+   SHOULD+        SHOULD           AES-XCBC-MAC-96 [RFC3566]
+   SHOULD         MAY              AES-CTR [RFC3686]
+
+3.  Usage Guidance
+
+   Since ESP and AH can be used in several different ways, this document
+   provides guidance on the best way to utilize these mechanisms.
+
+   ESP can provide confidentiality, data origin authentication, or the
+   combination of both of those security services.  AH provides only
+   data origin authentication.  Background information on those security
+   services is available [RFC4949].  In the following, we shorten "data
+   origin authentication" to "authentication".
+
+
+
+
+
+
+McGrew & Hoffman             Standards Track                    [Page 5]
+
+RFC 7321               Requirements for ESP and AH           August 2014
+
+
+   Providing both confidentiality and authentication offers the best
+   security.  If confidentiality is not needed, providing authentication
+   can still be useful.  Confidentiality without authentication is not
+   effective [DP07] and therefore SHOULD NOT be used.  We describe each
+   of these cases in more detail below.
+
+   To provide both confidentiality and authentication, an authenticated
+   encryption transform from Section 2.1 SHOULD be used in ESP, in
+   conjunction with NULL authentication.  Alternatively, an ESP
+   encryption transform and ESP authentication transform MAY be used
+   together.  It is NOT RECOMMENDED to use ESP with NULL authentication
+   in conjunction with AH; some configurations of this combination of
+   services have been shown to be insecure [PD10].
+
+   To provide authentication without confidentiality, an authentication
+   transform MUST be used in either ESP or AH.  The IPsec community
+   generally prefers ESP with NULL encryption over AH.  AH is still
+   required in some protocols and operational environments when there
+   are security-sensitive options in the IP header, such as source
+   routing headers; ESP inherently cannot protect those IP options.  It
+   is not possible to provide effective confidentiality without
+   authentication, because the lack of authentication undermines the
+   trustworthiness of encryption [B96][V02].  Therefore, an encryption
+   transform MUST NOT be used with a NULL authentication transform
+   (unless the encryption transform is an authenticated encryption
+   transform from Section 2.1).
+
+   Triple-DES SHOULD NOT be used in any scenario in which multiple
+   gigabytes of data will be encrypted with a single key.  As a 64-bit
+   block cipher, it leaks information about plaintexts above that
+   "birthday bound" [M13].  Triple-DES CBC is listed as a MAY implement
+   for the sake of backwards compatibility, but its use is discouraged.
+
+4.  Rationale
+
+   This section explains the principles behind the implementation
+   requirements described above.
+
+   The algorithms listed as "MAY implement" are not meant to be endorsed
+   over other non-standard alternatives.  All of the algorithms that
+   appeared in [RFC4835] are included in this document, for the sake of
+   continuity.  In some cases, these algorithms have moved from being
+   "SHOULD implement" to "MAY implement".
+
+
+
+
+
+
+
+
+McGrew & Hoffman             Standards Track                    [Page 6]
+
+RFC 7321               Requirements for ESP and AH           August 2014
+
+
+4.1.  Authenticated Encryption
+
+   This document encourages the use of authenticated encryption
+   algorithms because they can provide significant efficiency and
+   throughput advantages, and the tight binding between authentication
+   and encryption can be a security advantage [RFC5116].
+
+   AES-GCM [RFC4106] brings significant performance benefits [KKGEGD],
+   has been incorporated into IPsec recommendations [RFC6379], and has
+   emerged as the preferred authenticated encryption method in IPsec and
+   other standards.
+
+4.2.  Encryption Transforms
+
+   Since ESP encryption is optional, support for the "NULL" algorithm is
+   required to maintain consistency with the way services are
+   negotiated.  Note that while authentication and encryption can each
+   be "NULL", they MUST NOT both be "NULL" [RFC4301] [H10].
+
+   AES Counter Mode (AES-CTR) is an efficient encryption method, but it
+   provides no authentication capability.  The AES-GCM authenticated
+   encryption method has all of the advantages of AES-CTR, while also
+   providing authentication.  Thus, this document moves AES-CTR from a
+   SHOULD to a MAY.
+
+   The Triple Data Encryption Standard (TDES) is obsolete because of its
+   small block size; as with all 64-bit block ciphers, it SHOULD NOT be
+   used to encrypt more than one gigabyte of data with a single key
+   [M13].  Its key size is smaller than that of the Advanced Encryption
+   Standard (AES), while at the same time its performance and efficiency
+   are worse.  Thus, its use in new implementations is discouraged.
+
+   The Data Encryption Standard (DES) is obsolete because of its small
+   key size and small block size.  There have been publicly demonstrated
+   and open-design special-purpose cracking hardware.  Therefore, its
+   use is has been changed to MUST NOT in this document.
+
+4.3.  Authentication Transforms
+
+   AES-GMAC provides good security along with performance advantages,
+   even over HMAC-MD5.  In addition, it uses the same internal
+   components as AES-GCM and is easy to implement in a way that shares
+   components with that authenticated encryption algorithm.
+
+   The MD5 hash function has been found to not meet its goal of
+   collision resistance; it is so weak that its use in digital
+   signatures is highly discouraged [RFC6151].  There have been
+   theoretical results against HMAC-MD5, but that message authentication
+
+
+
+McGrew & Hoffman             Standards Track                    [Page 7]
+
+RFC 7321               Requirements for ESP and AH           August 2014
+
+
+   code does not seem to have a practical vulnerability.  Thus, it may
+   not be urgent to remove HMAC-MD5 from the existing protocols.
+
+   SHA-1 has been found to not meet its goal of collision resistance.
+   However, HMAC-SHA-1 does not rely on this property, and HMAC-SHA-1 is
+   believed to be secure.
+
+   HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to provide
+   a good security margin, and they perform adequately on many
+   platforms.  However, these algorithms are not recommended for
+   implementation in this document, because HMAC-SHA-1 support is
+   widespread and its security is good, AES-GMAC provides good security
+   with better performance, and Authenticated Encryption algorithms do
+   not need any authentication methods.
+
+   AES-XCBC has not seen widespread deployment, despite being previously
+   recommended as a SHOULD+ in RFC 4835.  Thus, this document lists it
+   only as a SHOULD.
+
+5.  Algorithm Diversity
+
+   When the AES cipher was first adopted, it was decided to continue
+   encouraging the implementation of Triple-DES, in order to provide
+   algorithm diversity.  But the passage of time has eroded the
+   viability of Triple-DES as an alternative to AES.  As it is a 64-bit
+   block cipher, its security is inadequate at high data rates (see
+   Section 4.2).  Its performance in software and Field-Programmable
+   Gate Arrays (FPGAs) is considerably worse than that of AES.  Since it
+   would not be possible to use Triple-DES as an alternative to AES in
+   high data rate environments, or in environments where its performance
+   could not keep up the requirements, the rationale of retaining
+   Triple-DES to provide algorithm diversity is disappearing.  (Of
+   course, this does not change the rationale of retaining Triple-DES in
+   IPsec implementations for backwards compatibility.)
+
+   Recent discussions in the IETF have started considering how to make
+   the selection of a different cipher that could provide algorithm
+   diversity in IPsec and other IETF standards.  That work is expected
+   to take a long time and involve discussions among many participants
+   and organizations.
+
+   It is important to bear in mind that it is very unlikely that an
+   exploitable flaw will be found in AES (e.g., a flaw that required
+   less than a terabyte of known plaintext, when AES is used in a
+   conventional mode of operation).  The only reason that algorithm
+   diversity deserves any consideration is because there would be large
+   problems if such a flaw were found.
+
+
+
+
+McGrew & Hoffman             Standards Track                    [Page 8]
+
+RFC 7321               Requirements for ESP and AH           August 2014
+
+
+6.  Acknowledgements
+
+   Some of the wording herein was adapted from [RFC4835], the document
+   that this one obsoletes.  That RFC itself borrows from earlier RFCs,
+   notably RFC 4305 and 4307.  RFC 4835, RFC 4305, and RFC 4307 were
+   authored by Vishwas Manral, Donald Eastlake, and Jeffrey Schiller
+   respectively.
+
+   Thanks are due to Wajdi Feghali, Brian Weis, Cheryl Madson, Dan
+   Harkins, Paul Wouters, Ran Atkinson, Scott Fluhrer, Tero Kivinen, and
+   Valery Smyslov for insightful feedback on this document.
+
+7.  Security Considerations
+
+   The security of a system that uses cryptography depends on both the
+   strength of the cryptographic algorithms chosen and the strength of
+   the keys used with those algorithms.  The security also depends on
+   the engineering and administration of the protocol used by the system
+   to ensure that there are no non-cryptographic ways to bypass the
+   security of the overall system.
+
+   This document concerns itself with the selection of cryptographic
+   algorithms for the use of ESP and AH, specifically with the selection
+   of mandatory-to-implement algorithms.  The algorithms identified in
+   this document as "MUST implement" or "SHOULD implement" are not known
+   to be broken at the current time, and cryptographic research to date
+   leads us to believe that they will likely remain secure into the
+   foreseeable future.  However, this is not necessarily forever.
+   Therefore, we expect that revisions of that document will be issued
+   from time to time to reflect the current best practice in this area.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
+              2005.
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
+              4303, December 2005.
+
+
+
+
+
+McGrew & Hoffman             Standards Track                    [Page 9]
+
+RFC 7321               Requirements for ESP and AH           August 2014
+
+
+8.2.  Informative References
+
+   [B96]      Bellovin, S., "Problem areas for the IP security
+              protocols", Proceedings of the Sixth Usenix Unix Security
+              Symposium, 1996.
+
+   [DP07]     Degabriele, J. and K. Paterson, "Attacking the IPsec
+              Standards in Encryption-only Configurations", IEEE
+              Symposium on Privacy and Security, 2007.
+
+   [H10]      Hoban, A., "Using Intel AES New Instructions and PCLMULQDQ
+              to Significantly Improve IPSec Performance on Linux",
+              Intel White Paper, August 2010.
+
+   [KKGEGD]   Kounavis, M., Kang, X., Grewal, K., Eszenyi, M., Gueron,
+              S., and D. Durham, "Encrypting the Internet", SIGCOMM,
+              2010.
+
+   [M13]      McGrew, D., "Impossible plaintext cryptanalysis and
+              probable-plaintext collision attacks of 64-bit block
+              cipher modes", IACR ePrint, 2012.
+
+   [PD10]     Paterson, K. and J. Degabriele, "On the (in)security of
+              IPsec in MAC-then-encrypt configurations", CCS '10, ACM
+              Conference on Computer and Communications Security, 2010.
+
+   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
+              ESP and AH", RFC 2404, November 1998.
+
+   [RFC2405]  Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
+              Algorithm With Explicit IV", RFC 2405, November 1998.
+
+   [RFC2410]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
+              Its Use With IPsec", RFC 2410, November 1998.
+
+   [RFC2451]  Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
+              Algorithms", RFC 2451, November 1998.
+
+   [RFC3566]  Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
+              and Its Use With IPsec", RFC 3566, September 2003.
+
+   [RFC3602]  Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
+              Algorithm and Its Use with IPsec", RFC 3602, September
+              2003.
+
+   [RFC3686]  Housley, R., "Using Advanced Encryption Standard (AES)
+              Counter Mode With IPsec Encapsulating Security Payload
+              (ESP)", RFC 3686, January 2004.
+
+
+
+McGrew & Hoffman             Standards Track                   [Page 10]
+
+RFC 7321               Requirements for ESP and AH           August 2014
+
+
+   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
+              (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
+              4106, June 2005.
+
+   [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM
+              Mode with IPsec Encapsulating Security Payload (ESP)", RFC
+              4309, December 2005.
+
+   [RFC4543]  McGrew, D. and J. Viega, "The Use of Galois Message
+              Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
+              May 2006.
+
+   [RFC4835]  Manral, V., "Cryptographic Algorithm Implementation
+              Requirements for Encapsulating Security Payload (ESP) and
+              Authentication Header (AH)", RFC 4835, April 2007.
+
+   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", RFC
+              4949, August 2007.
+
+   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
+              Encryption", RFC 5116, January 2008.
+
+   [RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
+              for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
+              RFC 6151, March 2011.
+
+   [RFC6379]  Law, L. and J. Solinas, "Suite B Cryptographic Suites for
+              IPsec", RFC 6379, October 2011.
+
+   [V02]      Vaudenay, S., "Security Flaws Induced by CBC Padding -
+              Applications to SSL, IPSEC, WTLS ...", EUROCRYPT, 2002.
+
+Authors' Addresses
+
+   David McGrew
+   Cisco Systems
+
+   EMail: mcgrew@cisco.com
+
+
+   Paul Hoffman
+   VPN Consortium
+
+   EMail: paul.hoffman@vpnc.org
+
+
+
+
+
+
+
+McGrew & Hoffman             Standards Track                   [Page 11]
+