RFC relevance of security

As per Relevance of the word security, we have this rfc below:

Network Working Group R.
Request for Comments: 2451 TimeStep
Category: Standards Track R.
Cisco Systems Inc
November 1998

The ESP CBC-Mode Cipher

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (1998). All Rights Reserved

This document describes how to use CBC-mode cipher algorithms
the IPSec ESP (Encapsulating Security Payload) Protocol. It not
clearly states how to use certain cipher algorithms, but also how
use all CBC-mode cipher algorithms

Table of

1. Introduction...................................................2
1.1 Specification of Requirements...............................2
1.2 Intellectual Property Rights Statement......................2
2. Cipher Algorithms..............................................2
2.1 Mode........................................................3
2.2 Key Size....................................................3
2.3 Weak Keys...................................................4
2.4 Block Size and Padding......................................5
2.5 Rounds......................................................6
2.6 Backgrounds.................................................6
2.7 Performance.................................................8
3. ESP Payload....................................................8
3.1 ESP Environmental Considerations............................9
3.2 Keying Material.............................................9
4. Security Considerations........................................9
5. References....................................................10
6. Acknowledgments...............................................11
7. Editors' Addresses............................................12

Pereira & Adams Standards Track [Page 1]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

8. Full Copyright Statement......................................14

1.

The Encapsulating Security Payload (ESP) [Kent98]
confidentiality for IP datagrams by encrypting the payload data to
protected. This specification describes the ESP use of CBC-
cipher algorithms

While this document does not describe the use of the default
algorithm DES, the reader should be familiar with that document
[Madson98]

It is assumed that the reader is familiar with the terms and
described in the "Security Architecture for the Internet Protocol
[Atkinson95], "IP Security Document Roadmap" [Thayer97], and "
Encapsulating Security Payload (ESP)" [Kent98] documents

Furthermore, this document is a companion to [Kent98] and MUST
read in its context

1.1 Specification of

The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
and "MAY" that appear in this document are to be interpreted
described in [Bradner97].

1.2 Intellectual Property Rights

The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP-11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of
proprietary rights by implementers or users of this specification
be obtained from the IETF Secretariat

2. Cipher

All symmetric block cipher algorithms share common
and variables. These include mode, key size, weak keys, block size
and rounds. All of which will be explained below

Pereira & Adams Standards Track [Page 2]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

While this document illustrates certain cipher algorithms such
Blowfish [Schneier93], CAST-128 [Adams97], 3DES, IDEA [Lai] [MOV],
and RC5 [Baldwin96], any other block cipher algorithm may be
with ESP if all of the variables described within this document
clearly defined

2.1

All symmetric block cipher algorithms described or insinuated
this document use Cipher Block Chaining (CBC) mode. This
requires an Initialization Vector (IV) that is the same size as
block size. Use of a randomly generated IV prevents generation
identical ciphertext from packets which have identical data
spans the first block of the cipher algorithm's blocksize

The IV is XOR'd with the first plaintext block, before it
encrypted. Then for successive blocks, the previous ciphertext
is XOR'd with the current plaintext, before it is encrypted

More information on CBC mode can be obtained in [Schneier95].

2.2 Key

Some cipher algorithms allow for variable sized keys, while
only allow a specific key size. The length of the key
with the strength of that algorithm, thus larger keys are
harder to break than shorter ones

This document stipulates that all key sizes MUST be a multiple of 8
bits

This document does specify the default key size for each
algorithm. This size was chosen by consulting experts on
algorithm and by balancing strength of the algorithm
performance

Pereira & Adams Standards Track [Page 3]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

+==============+==================+=================+==========+
| Algorithm | Key Sizes (bits) | Popular Sizes | Default |
+==============+==================+=================+==========+
| CAST-128 [1] | 40 to 128 | 40, 64, 80, 128 | 128 |
+--------------+------------------+-----------------+----------+
| RC5 | 40 to 2040 | 40, 128, 160 | 128 |
+--------------+------------------+-----------------+----------+
| IDEA | 128 | 128 | 128 |
+--------------+------------------+-----------------+----------+
| Blowfish | 40 to 448 | 128 | 128 |
+--------------+------------------+-----------------+----------+
| 3DES [2] | 192 | 192 | 192 |
+--------------+------------------+-----------------+----------+

Notes

[1] With CAST-128, keys less than 128 bits MUST be padded with
in the rightmost, or least significant, positions out to 128
since the CAST-128 key schedule assumes an input key of 128 bits
Thus if you had a key with a size of 80 bits '3B5D831CFE', it
be padded to produce a key with a size of 128
'3B5D831CFE000000'.

[2] The first 3DES key is taken from the first 64 bits, the
from the next 64 bits, and the third from the last 64 bits
Implementations MUST take into consideration the parity bits
initially accepting a new set of keys. Each of the three keys
really 56 bits in length with the extra 8 bits used for parity

The reader should note that the minimum key size for all of the
cipher algorithms is 40 bits, and that the authors strongly
that implementations do NOT use key sizes smaller than 40 bits

2.3 Weak

Weak key checks SHOULD be performed. If such a key is found, the
SHOULD be rejected and a new SA requested. Some cipher
have weak keys or keys that MUST not be used due to their
nature

New weak keys might be discovered, so this document does not in
way contain all possible weak keys for these ciphers. Please
with other sources of cryptography such as [MOV] and [Schneier]
further weak keys

CAST-128:

No known weak keys

Pereira & Adams Standards Track [Page 4]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

RC5:

No known weak keys when used with 16 rounds

IDEA

IDEA has been found to have weak keys. Please check with [MOV]
[Schneier] for more information

Blowfish

Weak keys for Blowfish have been discovered. Weak keys are keys
produce the identical entries in a given S-box. Unfortunately,
is no way to test for weak keys before the S- box values
generated. However, the chances of randomly generating such a
are small

3DES

DES has 64 known weak keys, including so-called semi-weak keys
possibly-weak keys [Schneier95, pp 280-282]. The likelihood
picking one at random is negligible

For DES-EDE3, there is no known need to reject weak
complementation keys. Any weakness is obviated by the use
multiple keys

However, if the first two or last two independent 64-bit keys
equal (k1 == k2 or k2 == k3), then the 3DES operation is simply
same as DES. Implementers MUST reject keys that exhibit
property

2.4 Block Size and

All of the algorithms described in this document use a block size
eight octets (64 bits).

Padding is used to align the payload type and pad length octets
specified in [Kent98]. Padding must be sufficient to align the
to be encrypted to an eight octet (64 bit) boundary

Pereira & Adams Standards Track [Page 5]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

2.5

This variable determines how many times a block is encrypted.
this variable MAY be negotiated, a default value MUST always
when it is not negotiated

+====================+============+======================+
| Algorithm | Negotiable | Default Rounds |
+====================+============+======================+
| CAST-128 | No | key<=80 bits, 12 |
| | | key>80 bits, 16 |
+--------------------+------------+----------------------+
| RC5 | No | 16 |
+--------------------+------------+----------------------+
| IDEA | No | 8 |
+--------------------+------------+----------------------+
| Blowfish | No | 16 |
+--------------------+------------+----------------------+
| 3DES | No | 48 (16x3) |
+--------------------+------------+----------------------+

2.6

CAST-128:

The CAST design procedure was originally developed by Carlisle
and Stafford Tavares at Queen's University, Kingston, Ontario
Canada. Subsequent enhancements have been made over the years
Carlisle Adams and Michael Wiener of Entrust Technologies. CAST-128
is the result of applying the CAST Design Procedure as outlined
[Adams97].

RC5:

The RC5 encryption algorithm was developed by Ron Rivest for RSA
Security Inc. in order to address the need for a high-
software and hardware ciphering alternative to DES. It is
(pat.no. 5,724,428). A description of RC5 may be found in [MOV]
[Schneier].

IDEA

Xuejia Lai and James Massey developed the IDEA (International
Encryption Algorithm) algorithm. The algorithm is described
detail in [Lai], [Schneier] and [MOV].

Pereira & Adams Standards Track [Page 6]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

The IDEA algorithm is patented in Europe and in the United
with patent application pending in Japan. Licenses are required
commercial uses of IDEA

For patent and licensing information, contact

Ascom Systec AG, Dept.
Gewerbepark, CH-5506
Magenwil,
Phone: +41 64 56 59 83
Fax: +41 64 56 59 90
idea@ascom.
http://www.ascom.ch/Web/systec/policy/normal/exhibit1.

Blowfish

Bruce Schneier of Counterpane Systems developed the Blowfish
cipher algorithm. The algorithm is described in detail
[Schneier93], [Schneier95] and [Schneier].

3DES

This DES variant, colloquially known as "Triple DES" or as DES-EDE3,
processes each block three times, each time with a different key
This technique of using more than one DES operation was proposed
[Tuchman79].

P1 P2
| | |
IV->->(X) +>->->->(X) +>->->->(X
v ^ v ^
+-----+ ^ +-----+ ^ +-----+
k1->| E | ^ k1->| E | ^ k1->| E |
+-----+ ^ +-----+ ^ +-----+
| ^ | ^ |
v ^ v ^
+-----+ ^ +-----+ ^ +-----+
k2->| D | ^ k2->| D | ^ k2->| D |
+-----+ ^ +-----+ ^ +-----+
| ^ | ^ |
v ^ v ^
+-----+ ^ +-----+ ^ +-----+
k3->| E | ^ k3->| E | ^ k3->| E |
+-----+ ^ +-----+ ^ +-----+
| ^ | ^ |
+>->->+ +>->->+ +>->->
| | |
C1 C2

Pereira & Adams Standards Track [Page 7]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

The DES-EDE3-CBC algorithm is a simple variant of the DES-
algorithm [FIPS-46]. The "outer" chaining technique is used

In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with
first 64-bit (8 byte) plaintext block (P1). The keyed DES
is iterated three times, an encryption (Ek1) followed by a
(Dk2) followed by an encryption (Ek3), and generates the
(C1) for the block. Each iteration uses an independent key: k1, k
and k3.

For successive blocks, the previous ciphertext block is XOR'd
the current plaintext (Pi). The keyed DES-EDE3 encryption
generates the ciphertext (Ci) for that block

To decrypt, the order of the functions is reversed: decrypt with k3,
encrypt with k2, decrypt with k1, and XOR the previous
block

Note that when all three keys (k1, k2 and k3) are the same, DES
EDE3-CBC is equivalent to DES-CBC. This property allows the DES-EDE
hardware implementations to operate in DES mode without modification

For more explanation and implementation information for Triple DES
see [Schneier95].

2.7

For a comparison table of the estimated speed of any of these
other cipher algorithms, please see [Schneier97] or for an up-to-
performance comparison, please see [Bosseleaers].

3. ESP

The ESP payload is made up of the IV followed by raw cipher-text
Thus the payload field, as defined in [Kent98], is broken
according to the following diagram

+---------------+---------------+---------------+---------------+
| |
+ Initialization Vector (8 octets) +
| |
+---------------+---------------+---------------+---------------+
| |
~ Encrypted Payload (variable length) ~
| |
+---------------------------------------------------------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

Pereira & Adams Standards Track [Page 8]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

The IV field MUST be same size as the block size of the
algorithm being used. The IV MUST be chosen at random.
practice is to use random data for the first IV and the last block
encrypted data from an encryption process as the IV for the
encryption process

Including the IV in each datagram ensures that decryption of
received datagram can be performed, even when some datagrams
dropped, or datagrams are re-ordered in transit

To avoid ECB encryption of very similar plaintext blocks in
packets, implementations MUST NOT use a counter or other low-
distance source for IVs

3.1 ESP Environmental

Currently, there are no known issues regarding interactions
these algorithms and other aspects of ESP, such as use of
authentication schemes

3.2 Keying

The minimum number of bits sent from the key exchange protocol
this ESP algorithm must be greater or equal to the key size

The cipher's encryption and decryption key is taken from the
bits of the keying material, where represents the
key size

4. Security

Implementations are encouraged to use the largest key sizes they
when taking into account performance considerations for
particular hardware and software configuration. Note that
necessarily impacts both sides of a secure channel, so
consideration must take into account not only the client side,
the server as well

For information on the case for using random values please
[Bell97].

For further security considerations, the reader is encouraged to
the documents that describe the actual cipher algorithms

Pereira & Adams Standards Track [Page 9]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

5.

[Adams97] Adams, C, "The CAST-128 Encryption Algorithm",
RFC2144, 1997.

[Atkinson98]Kent, S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.

[Baldwin96] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC
Pad, and RC5-CTS Algorithms", RFC 2040, October 1996.

[Bell97] S. Bellovin, "Probable Plaintext Cryptanalysis of the
Security Protocols", Proceedings of the Symposium
Network and Distributed System Security, San Diego, CA
pp. 155-160, February 1997 (
http://www.research.att.com/~smb/probtxt.{ps, pdf}).

[Bosselaers]A. Bosselaers, "Performance of Pentium implementations",
http://www.esat.kuleuven.ac.be/~bosselae

[Bradner97] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.

[Crypto93] J. Daemen, R. Govaerts, J. Vandewalle, "Weak Keys
IDEA", Advances in Cryptology, CRYPTO 93 Proceedings
Springer-Verlag, pp. 224-230.

[FIPS-46] US National Bureau of Standards, "Data
Standard", Federal Information Processing Standard (FIPS
Publication 46, January 1977.

[Kent98] Kent, S. and R. Atkinson, "IP Encapsulating
Payload (ESP)", RFC 2406, November 1998.

[Lai] X. Lai, "On the Design and Security of Block Ciphers",
ETH Series in Information Processing, v. 1, Konstanz
Hartung-Gorre Verlag, 1992.

[Madson98] Madson, C. and N. Dorswamy, "The ESP DES-CBC
Algorithm With Explicit IV", RFC 2405, November 1998.

[MOV] A. Menezes, P. Van Oorschot, S. Vanstone, "Handbook
Applied Cryptography", CRC Press, 1997. ISBN 0-8493-
8523-7

[Schneier] B. Schneier, "Applied Cryptography Second Edition",
Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7

Pereira & Adams Standards Track [Page 10]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

[Schneier93]B. Schneier, "Description of a New Variable-Length Key
64-Bit Block Cipher", from "Fast Software Encryption
Cambridge Security Workshop Proceedings", Springer
Verlag, 1994, pp. 191-204.
http://www.counterpane.com/bfsverlag.

[Schneier95]B. Schneier, "The Blowfish Encryption Algorithm -
Year Later", Dr. Dobb's Journal, September 1995,
http://www.counterpane.com/bfdobsoyl.

[Schneier97]B. Scheier, "Speed Comparisons of Block Ciphers on
Pentium." February 1997,
http://www.counterpane.com/speed.

[Thayer97] Thayer, R., Doraswamy, N. and R. Glenn, "IP
Document Roadmap", RFC 2411, November 1998.

[Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions
DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41.

6.

This document is a merger of most of the ESP cipher
documents. This merger was done to facilitate greater
of the commonality of all of the ESP algorithms and to further
development of these algorithm within ESP

The content of this document is based on suggestions originally
Stephen Kent and subsequent discussions from the IPSec mailing
as well as other IPSec documents

Special thanks to Carlisle Adams and Paul Van Oorschot both
Entrust Technologies who provided input and review of CAST

Thanks to all of the editors of the previous ESP 3DES documents; W
Simpson, N. Doraswamy, P. Metzger, and P. Karn

Thanks to Brett Howard from TimeStep for his original work of ESP
RC5.

Thanks to Markku-Juhani Saarinen, Helger Lipmaa and Bart Preneel
their input on IDEA and other ciphers

Pereira & Adams Standards Track [Page 11]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

7. Editors'

Roy
TimeStep

Phone: +1 (613) 599-3610 x 4808
EMail: rpereira@timestep.

Rob
Cisco Systems Inc

Phone: +1 (408) 457-5397
EMail: adams@cisco.

Contributors

Robert W.
RSA Data Security, Inc

Phone: +1 (415) 595-8782
EMail: baldwin@rsa.com or baldwin@lcs.mit.

Greg
Entrust

Phone: +1 (613) 763-1358
EMail: carterg@entrust.

Rodney
Sable Technology

Phone: +1 (617) 332-7292
EMail: rodney@sabletech.

Pereira & Adams Standards Track [Page 12]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

The IPSec working group can be contacted via the IPSec
group's mailing list (ipsec@tis.com) or through its chairs

Robert
International Computer Security

EMail: rgm@icsa.

Theodore Y. Ts'
Massachusetts Institute of

EMail: tytso@MIT.

Pereira & Adams Standards Track [Page 13]

RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998

8. Full Copyright

Copyright (C) The Internet Society (1998). 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

Pereira & Adams Standards Track [Page 14]

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