Network Working Group W A Simpson
Internet Draft [DayDreamer]
expires in six months July 1997
The ESP CAST5-128-CBC Transform
draft-ietf-ipsec-ciph-cast-div-00.txt
Status of this Memo
This document is an Internet-Draft. Internet Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute work-
ing documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as refer-
ence 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
``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
Directories on:
ftp.is.co.za (Africa)
nic.nordu.net (Europe)
ds.internic.net (US East Coast)
ftp.isi.edu (US West Coast)
munnari.oz.au (Pacific Rim)
Distribution of this memo is unlimited.
Abstract
This document describes the CAST5-128-CBC block cipher transform
interface used with the IP Encapsulating Security Payload (ESP). It
provides a full-sized 128-bit key, with a more secure derived ini-
tialization variable, and a more efficient smaller datagram size.
Simpson expires in six months [Page i]
DRAFT ESP CAST-CBC July 1997
1. Introduction
The Encapsulating Security Payload (ESP) [RFC-1827x] provides confi-
dentiality for IP datagrams by encrypting the payload data to be pro-
tected. This specification describes the ESP use of the Cipher Block
Chaining (CBC) mode with CAST5-128.
The CAST Design Procedure was originally developed by Carlisle Adams
and Stafford Travares at Queen's University, Kingston, Ontario,
Canada. Subsequent enhancements have been made over the years by
Carlisle Adams and Michael Wiener of Entrust Technologies. CAST5-128
is the result of applying the CAST Design Procedure as outlined in
[RFC-2144].
For an explanation of the use of CBC mode with this cipher, see [RFC-
wwww].
This document assumes that the reader is familiar with the related
document "Security Architecture for the Internet Protocol"
[RFC-1825x], that defines the overall security plan for IP, and pro-
vides important background for this specification.
In this document, the key words "MAY", "MUST", "recommended",
"required", and "SHOULD", are to be interpreted as described in
[RFC-2119].
1.1. Availability
There are a number of patents. Unfortunately, the CAST authors have
not listed them in their drafts, as required as by the IETF. Watch
this space.
1.2. Performance
It is speculated that CAST5-128 runs approximately the same speed as
a highly optimized DES implementation. This is based on a non-
optimized C++ implementation. It is hoped that this can be tuned to
give even higher performance.
The following performance tests were run on a Pentium 90 MHz running
the Windows NT operating system using 20 Kbyte buffers, and do not
include file I/O. The DES-CBC implementation was not optimized for a
32-bit environment.
CAST5-64 bit key 12 round CBC encryption ..... 21,120,000 bits/sec
DES-CBC encryption ............................ 4,032,000 bits/sec
Simpson expires in six months [Page 1]
DRAFT ESP CAST-CBC July 1997
There is no data available on a full-sized 128-bit key with 16
rounds. Watch this space.
For comparison, Phil Karn has tuned DES-CBC software to achieve 10.45
Mbps with a 90 MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pen-
tium. Your milage may vary.
2. Description
2.1. Block Size
The CAST5-128 algorithm operates on blocks of 64-bits (8 bytes).
This often requires padding before encrypting, and subsequent removal
of padding after decrypting.
The output is the same number of bytes that are input. This facili-
tates in-place encryption and decryption.
2.2. Rounds
The algorithm MUST use the full 16 rounds.
2.3. Interaction with Authentication
There is no known interaction of CAST5-128 with any currently speci-
fied Authenticator algorithm.
3. Initialization Vector
CAST5-128-CBC requires an Initialization Vector (IV) that is 64-bits
(8 bytes) in length [RFC-wwww].
By default, the 64-bit IV is generated from the 32-bit Security
Parameters Index (SPI) field followed by (concatenated with) the
32-bit Sequence Number (SN) field. Then, the bit-wise complement of
the 32-bit Sequence Number (SN) value is XOR'd with the first 32-bits
(SPI):
(SPI ^ -SN) || SN
Alternative IV generation techniques MAY be specified when dynami-
cally configured via a key management protocol.
Security Notes:
Simpson expires in six months [Page 2]
DRAFT ESP CAST-CBC July 1997
Incorporating the ESP Security Parameters Index (SPI) and the
anti-replay ESP Sequence Number (SN) together can provide greater
uniqueness and mutual protection between the first block and the
ESP header. Modification of the SPI to alter the decryption
key(s) will prevent correct decryption of the first block.
Using the Sequence Number (SN) provides an easy method for pre-
venting IV repetition, and is sufficiently robust for practical
use with the CAST5-128 algorithm. Inclusion of the bit-wise com-
plement of SN ensures that bit changes are reflected twice in the
IV.
4. Keys
CAST5-128 is a symmetric secret key algorithm. The secret CAST5-128
key shared between the communicating parties is 128-bits in length.
Although CAST5-128 can be used with shorter keys, these other keys
sizes are not conformant with this specification.
4.1. Weak Keys
CAST5-128 has no known weak keys.
4.2. Refresh Rate
CAST5-128 is theorized to be immune to differential and linear crypt-
analysis.
5. ESP Alterations
5.1. ESP Sequence Number
The Sequence Number is a 32-bit (4 byte) unsigned counter. This
field protects against replay attacks, and may also be used for syn-
chronization by stream or block-chaining ciphers.
When configured manually, the first value sent SHOULD be a random
number.
When configured via an automated Security Association management pro-
tocol, the first value sent is 1, unless otherwise negotiated.
Thereafter, the value is monotonically increased for each datagram
sent. A replacement SPI SHOULD be established before the value
Simpson expires in six months [Page 3]
DRAFT ESP CAST-CBC July 1997
repeats. That is, less than 2**32 datagrams SHOULD be sent with any
single key.
Operational Considerations
The specification provides only a few manually configurable parame-
ters:
SPI
Manually configured SPIs are limited in range to aid operations.
Automated SPIs are pseudo-randomly distributed throughout the
remaining 2**32 values.
Default: 0 (none). Range: 256 to 65,535.
SPI LifeTime (SPILT)
Manually configured LifeTimes are generally measured in days.
Automated LifeTimes are specified in seconds.
Default: 32 days (2,764,800 seconds). Maximum: 182 days
(15,724,800 seconds).
Replay Window
Default: 0 (checking off). Range: 32 to 256.
Pad Values
Default: 7 (checking on). Range: 7 to 255.
Key
The 128-bit key is configured as required.
Each party configures a list of known SPIs and symmetric secret-keys.
In addition, each party configures local policy that determines what
access (if any) is granted to the holder of a particular SPI. For
example, a party might allow FTP, but prohibit Telnet. Such consid-
erations are outside the scope of this document.
Simpson expires in six months [Page 4]
DRAFT ESP CAST-CBC July 1997
Security Considerations
Users need to understand that the quality of the security provided by
this specification depends completely on the strength of the CAST
algorithm, the correctness of that algorithm's implementation, the
security of the Security Association management mechanism and its
implementation, the strength of the key, and upon the correctness of
the implementations in all of the participating nodes.
Acknowledgements
The basic field naming and layout is based on "swIPe" [IBK93, IB93].
Some of the text of this specification was derived from work by Roy
Pereira and Greg Carter.
William Allen Simpson was responsible for the name and semantics of
the SPI, the IV calculation technique(s), editing and formatting.
References
[IB93] Ioannidis, J., and Blaze, M., "The Architecture and Imple-
mentation of Network-Layer Security Under Unix", Proceedings
of the Fourth Usenix Security Symposium, Santa Clara Cali-
fornia, October 1993.
[IBK93] Ioannidis, J., Blaze, M., and Karn, P., "swIPe: Network-
Layer Security for IP", Presentation at the 26th Internet
Engineering Task Force, Columbus Ohio, March 1993.
[RFC-1825x]
Atkinson, R., "Security Architecture for the Internet Proto-
col", Naval Research Laboratory, July 1995.
[RFC-1827x]
Simpson, W., "IP Encapsulating Security Protocol (ESP) for
implementors", work in progress.
[RFC-2119]
Bradner, S., "Key words for use in RFCs to Indicate Require-
ment Levels", BCP 14, Harvard University, March 1997.
[RFC-2144]
Adams, C., "The CAST-128 Encryption Algorithm", May 1997.
Simpson expires in six months [Page 5]
DRAFT ESP CAST-CBC July 1997
[RFC-wwww]
Simpson, W.A, "ESP with Cipher Block Chaining (CBC)", work
in progress.
Contacts
Comments about this document should be discussed on the ipsec@tis.com
mailing list.
Questions about this document can also be directed to:
Perry Metzger
Piermont Information Systems Inc.
160 Cabrini Blvd., Suite #2
New York, NY 10033
perry@piermont.com
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
bsimpson@MorningStar.com
Simpson expires in six months [Page 6]
