home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_i
/
draft-ietf-ipsec-esp-rc5-cbc-00.txt
< prev
next >
Wrap
Text File
|
1997-04-25
|
9KB
|
274 lines
Internet Engineering Task Force Roy Pereira
IP Security Working Group TimeStep Corporation
Internet Draft R. W. Baldwin
Expires in six months RSA Data Security, Inc.
April 25, 1997
The ESP RC5-CBC Algorithm
<draft-ietf-ipsec-esp-rc5-cbc-00.txt>
Status of this Memo
This document is a submission to the IETF Internet Protocol
Security (IPSEC) Working Group. Comments are solicited and should
be addressed to the working group mailing list (ipsec@tis.com) or
to the editor.
This document is an Internet-Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet-Drafts draft documents are valid for a maximum of six
months and may be updated, replaced, or obsolete by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "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),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
This draft describes the RC5 block cipher algorithm as to be used
with the IPSec Encapsulating Security Payload (ESP).
R. Pereira, B. Baldwin [Page 1]
Internet Draft The ESP RC5-CBC Algorithm April 25, 1997
Table of Contents
1. Introduction...................................................2
2. Cipher Algorithm...............................................2
2.1 Key Size....................................................2
2.2 Block Size and Padding......................................3
2.3 Payload.....................................................3
2.4 Weak Keys...................................................3
2.5 Rounds......................................................3
2.6 Background on RC5...........................................3
2.7 Performance.................................................3
3. Key Exchange Protocol Identifiers..............................4
4. Keying Material................................................4
5. Security Considerations........................................4
6. References.....................................................4
7. Acknowledgments................................................5
8. Editors' Address...............................................5
1. Introduction
This draft describes how the RC5 cipher algorithm may be used with
the IPSec ESP protocol.
It is assumed that the reader is familiar with the terms and
concepts described in the document "Security Architecture for the
Internet Protocol" [Atkinson95] and "IP Encapsulating Security
Payload (ESP)" [Kent97].
Furthermore, this document is a companion to [Kent97] and MUST be
read in its context.
2. Cipher Algorithm
The symmetric block cipher algorithm used to secure ESP is RC5 in
CBC mode with 16 rounds and a block size of 64 bits as described in
[Baldwin96].
2.1 Key Size
RC5's key size MUST be multiple of 8 bits and MUST be from 40 to
2040 bits inclusive. To facilitate interoperability, it is
recommended that key sizes SHOULD be chosen from the set of 40, 128
and 160 bits.
If the key size is not negotiated through the key exchange
protocol, then a value of 128 bits MUST be used. All compliant
implementations MUST support a key size of 128 bits.
R. Pereira, R. Baldwin [Page 2]
Internet Draft The ESP RC5-CBC Algorithm April 25, 1997
2.2 Block Size and Padding
RC5 has a variably length block size, but for the ESP algorithm
described in this document, the block size MUST be 8 octets (64
bits).
When padding is required, it MUST be done according to the
conventions specified in [Kent97].
2.3 Payload
RC5-CBC requires an explicit Initialization Vector (IV) of 8 octets
(64 bits) that immediately precedes the cipher-text in the payload.
A new IV must be pseudo-randomly generated for each packet and then
used to encrypt that plain-text. When decrypting, the first 8
octets of the payload are used as a IV to decrypt the remaining
payload octets.
2.4 Weak Keys
RC5 has no known weak keys when used with 16 rounds.
2.5 Rounds
RSA Labs recommends that RC5 be used with 16 rounds. Twelve rounds
is enough to make RC5 stronger than DES against differential and
linear cryptanalysis and sixteen rounds is sufficient to make RC5
secure against both forms of cryptanalysis even at a theoretical
level.
Compliant implementations MUST support 16 rounds.
2.6 Background on RC5
The RC5 encryption algorithm was developed by Ron Rivest for RSA
Data Security Inc. in order to address the need for a high-
performance software and hardware ciphering alternative to DES.
2.7 Performance
Benchmark numbers from RSA Data Security suggest that RC5-CBC runs
about twice as fast as Eric Young's DES-CBC implementation from
SSLeay on the popular 32-bit CPUs.
R. Pereira, R. Baldwin [Page 3]
Internet Draft The ESP RC5-CBC Algorithm April 25, 1997
3. Key Exchange Protocol Identifiers
For Oakley/ISAKMP [Harkins97] to negotiate ESP RC5 as described in
this draft, the transform id MUST be 4, which is stated in
[Piper97].
4. Keying Material
The minimum number of bits sent from the Key Exchange Protocol to
this ESP algorithm must be greater or equal to the key size plus
the key size of the negotiated authentication algorithm.
For example, if we are using a RC5 key size of 40 bits and we are
using HMAC-MD5 [Oehler97] as the authentication algorithm, then the
required number of bits of keying material would be:
Bits Required = Encryption Key Size + Authentication Key Size
Bits Required = 40 + 128
Bits Required = 168
The RC5 key is taken from the first <x> bits of the keying
material. Where <x> represents the required key size. The
remaining bits are truncated to equate the key size of the
authentication algorithm and used as its key.
5. Security Considerations
The ESP RC5 algorithm described in this draft has the same security
considerations as in [Baldwin96].
6. References
[Atkinson95] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC1825, August 1995
[Kent97] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
(ESP)", draft-ietf-ipsec-new-esp-01.txt, March 1997
[Baldwin96] Baldwin, R.W., Rivest, R., "The RC5, RC5-CBC, RC5-CBC-
Pad, and RC5-CTS Algorithms", RFC2040, October 1996
[Piper97] Derrel, P., "The Internet IP Domain of Interpretation for
ISAKMP", draft-ietf-ipsec-ipsec-doi-03.txt, February 1997
[Harkins97] Harkins, D. , Carrel, D., "The resolution of ISAKMP
with Oakley", draft-ietf-ipsec-isakmp-oakley-03.txt, February 1997
R. Pereira, R. Baldwin [Page 4]
Internet Draft The ESP RC5-CBC Algorithm April 25, 1997
[Oehler97] Oehler, M., Glenn, R., "HMAC-MD5 IP Authentication with
Replay Prevention", RFC2085, February 1997
7. Acknowledgments
This document is based on previous work by B. Howard of TimeStep
Corporation, suggestions from Stephen Kent, discussions from the
IPSec mailing list as well as the other IPSec drafts.
The IPSec working group can be contacted through its chairs:
Paul Lambert
<PALAMBER@us.oracle.com>
Oracle Corporation
or via the IPSec working group's mailing list (ipsec@tis.com)
8. Editors' Address
Roy Pereira
<rpereira@timestep.com>
TimeStep Corporation
(613) 599-3610 x 4808
Robert W. Baldwin
<baldwin@rsa.com> or <baldwin@lcs.mit.edu>
RSA Data Security, Inc.
(415) 595-8782
R. Pereira, R. Baldwin [Page 5]