- moved RFCs from ikev2 into doc dir
This commit is contained in:
Martin Willi
Binary file not shown.
Binary file not shown.
Binary file not shown.
+3248
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Binary file not shown.
@@ -0,0 +1,619 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group H. Krawczyk
|
||||
Request for Comments: 2104 IBM
|
||||
Category: Informational M. Bellare
|
||||
UCSD
|
||||
R. Canetti
|
||||
IBM
|
||||
February 1997
|
||||
|
||||
|
||||
HMAC: Keyed-Hashing for Message Authentication
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This memo provides information for the Internet community. This memo
|
||||
does not specify an Internet standard of any kind. Distribution of
|
||||
this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes HMAC, a mechanism for message authentication
|
||||
using cryptographic hash functions. HMAC can be used with any
|
||||
iterative cryptographic hash function, e.g., MD5, SHA-1, in
|
||||
combination with a secret shared key. The cryptographic strength of
|
||||
HMAC depends on the properties of the underlying hash function.
|
||||
|
||||
1. Introduction
|
||||
|
||||
Providing a way to check the integrity of information transmitted
|
||||
over or stored in an unreliable medium is a prime necessity in the
|
||||
world of open computing and communications. Mechanisms that provide
|
||||
such integrity check based on a secret key are usually called
|
||||
"message authentication codes" (MAC). Typically, message
|
||||
authentication codes are used between two parties that share a secret
|
||||
key in order to validate information transmitted between these
|
||||
parties. In this document we present such a MAC mechanism based on
|
||||
cryptographic hash functions. This mechanism, called HMAC, is based
|
||||
on work by the authors [BCK1] where the construction is presented and
|
||||
cryptographically analyzed. We refer to that work for the details on
|
||||
the rationale and security analysis of HMAC, and its comparison to
|
||||
other keyed-hash methods.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Krawczyk, et. al. Informational [Page 1]
|
||||
|
||||
RFC 2104 HMAC February 1997
|
||||
|
||||
|
||||
HMAC can be used in combination with any iterated cryptographic hash
|
||||
function. MD5 and SHA-1 are examples of such hash functions. HMAC
|
||||
also uses a secret key for calculation and verification of the
|
||||
message authentication values. The main goals behind this
|
||||
construction are
|
||||
|
||||
* To use, without modifications, available hash functions.
|
||||
In particular, hash functions that perform well in software,
|
||||
and for which code is freely and widely available.
|
||||
|
||||
* To preserve the original performance of the hash function without
|
||||
incurring a significant degradation.
|
||||
|
||||
* To use and handle keys in a simple way.
|
||||
|
||||
* To have a well understood cryptographic analysis of the strength of
|
||||
the authentication mechanism based on reasonable assumptions on the
|
||||
underlying hash function.
|
||||
|
||||
* To allow for easy replaceability of the underlying hash function in
|
||||
case that faster or more secure hash functions are found or
|
||||
required.
|
||||
|
||||
This document specifies HMAC using a generic cryptographic hash
|
||||
function (denoted by H). Specific instantiations of HMAC need to
|
||||
define a particular hash function. Current candidates for such hash
|
||||
functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD].
|
||||
These different realizations of HMAC will be denoted by HMAC-SHA1,
|
||||
HMAC-MD5, HMAC-RIPEMD, etc.
|
||||
|
||||
Note: To the date of writing of this document MD5 and SHA-1 are the
|
||||
most widely used cryptographic hash functions. MD5 has been recently
|
||||
shown to be vulnerable to collision search attacks [Dobb]. This
|
||||
attack and other currently known weaknesses of MD5 do not compromise
|
||||
the use of MD5 within HMAC as specified in this document (see
|
||||
[Dobb]); however, SHA-1 appears to be a cryptographically stronger
|
||||
function. To this date, MD5 can be considered for use in HMAC for
|
||||
applications where the superior performance of MD5 is critical. In
|
||||
any case, implementers and users need to be aware of possible
|
||||
cryptanalytic developments regarding any of these cryptographic hash
|
||||
functions, and the eventual need to replace the underlying hash
|
||||
function. (See section 6 for more information on the security of
|
||||
HMAC.)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Krawczyk, et. al. Informational [Page 2]
|
||||
|
||||
RFC 2104 HMAC February 1997
|
||||
|
||||
|
||||
2. Definition of HMAC
|
||||
|
||||
The definition of HMAC requires a cryptographic hash function, which
|
||||
we denote by H, and a secret key K. We assume H to be a cryptographic
|
||||
hash function where data is hashed by iterating a basic compression
|
||||
function on blocks of data. We denote by B the byte-length of such
|
||||
blocks (B=64 for all the above mentioned examples of hash functions),
|
||||
and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
|
||||
SHA-1). The authentication key K can be of any length up to B, the
|
||||
block length of the hash function. Applications that use keys longer
|
||||
than B bytes will first hash the key using H and then use the
|
||||
resultant L byte string as the actual key to HMAC. In any case the
|
||||
minimal recommended length for K is L bytes (as the hash output
|
||||
length). See section 3 for more information on keys.
|
||||
|
||||
We define two fixed and different strings ipad and opad as follows
|
||||
(the 'i' and 'o' are mnemonics for inner and outer):
|
||||
|
||||
ipad = the byte 0x36 repeated B times
|
||||
opad = the byte 0x5C repeated B times.
|
||||
|
||||
To compute HMAC over the data `text' we perform
|
||||
|
||||
H(K XOR opad, H(K XOR ipad, text))
|
||||
|
||||
Namely,
|
||||
|
||||
(1) append zeros to the end of K to create a B byte string
|
||||
(e.g., if K is of length 20 bytes and B=64, then K will be
|
||||
appended with 44 zero bytes 0x00)
|
||||
(2) XOR (bitwise exclusive-OR) the B byte string computed in step
|
||||
(1) with ipad
|
||||
(3) append the stream of data 'text' to the B byte string resulting
|
||||
from step (2)
|
||||
(4) apply H to the stream generated in step (3)
|
||||
(5) XOR (bitwise exclusive-OR) the B byte string computed in
|
||||
step (1) with opad
|
||||
(6) append the H result from step (4) to the B byte string
|
||||
resulting from step (5)
|
||||
(7) apply H to the stream generated in step (6) and output
|
||||
the result
|
||||
|
||||
For illustration purposes, sample code based on MD5 is provided as an
|
||||
appendix.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Krawczyk, et. al. Informational [Page 3]
|
||||
|
||||
RFC 2104 HMAC February 1997
|
||||
|
||||
|
||||
3. Keys
|
||||
|
||||
The key for HMAC can be of any length (keys longer than B bytes are
|
||||
first hashed using H). However, less than L bytes is strongly
|
||||
discouraged as it would decrease the security strength of the
|
||||
function. Keys longer than L bytes are acceptable but the extra
|
||||
length would not significantly increase the function strength. (A
|
||||
longer key may be advisable if the randomness of the key is
|
||||
considered weak.)
|
||||
|
||||
Keys need to be chosen at random (or using a cryptographically strong
|
||||
pseudo-random generator seeded with a random seed), and periodically
|
||||
refreshed. (Current attacks do not indicate a specific recommended
|
||||
frequency for key changes as these attacks are practically
|
||||
infeasible. However, periodic key refreshment is a fundamental
|
||||
security practice that helps against potential weaknesses of the
|
||||
function and keys, and limits the damage of an exposed key.)
|
||||
|
||||
4. Implementation Note
|
||||
|
||||
HMAC is defined in such a way that the underlying hash function H can
|
||||
be used with no modification to its code. In particular, it uses the
|
||||
function H with the pre-defined initial value IV (a fixed value
|
||||
specified by each iterative hash function to initialize its
|
||||
compression function). However, if desired, a performance
|
||||
improvement can be achieved at the cost of (possibly) modifying the
|
||||
code of H to support variable IVs.
|
||||
|
||||
The idea is that the intermediate results of the compression function
|
||||
on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed
|
||||
only once at the time of generation of the key K, or before its first
|
||||
use. These intermediate results are stored and then used to
|
||||
initialize the IV of H each time that a message needs to be
|
||||
authenticated. This method saves, for each authenticated message,
|
||||
the application of the compression function of H on two B-byte blocks
|
||||
(i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be
|
||||
significant when authenticating short streams of data. We stress
|
||||
that the stored intermediate values need to be treated and protected
|
||||
the same as secret keys.
|
||||
|
||||
Choosing to implement HMAC in the above way is a decision of the
|
||||
local implementation and has no effect on inter-operability.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Krawczyk, et. al. Informational [Page 4]
|
||||
|
||||
RFC 2104 HMAC February 1997
|
||||
|
||||
|
||||
5. Truncated output
|
||||
|
||||
A well-known practice with message authentication codes is to
|
||||
truncate the output of the MAC and output only part of the bits
|
||||
(e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some
|
||||
analytical advantages of truncating the output of hash-based MAC
|
||||
functions. The results in this area are not absolute as for the
|
||||
overall security advantages of truncation. It has advantages (less
|
||||
information on the hash result available to an attacker) and
|
||||
disadvantages (less bits to predict for the attacker). Applications
|
||||
of HMAC can choose to truncate the output of HMAC by outputting the t
|
||||
leftmost bits of the HMAC computation for some parameter t (namely,
|
||||
the computation is carried in the normal way as defined in section 2
|
||||
above but the end result is truncated to t bits). We recommend that
|
||||
the output length t be not less than half the length of the hash
|
||||
output (to match the birthday attack bound) and not less than 80 bits
|
||||
(a suitable lower bound on the number of bits that need to be
|
||||
predicted by an attacker). We propose denoting a realization of HMAC
|
||||
that uses a hash function H with t bits of output as HMAC-H-t. For
|
||||
example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
|
||||
and with the output truncated to 80 bits. (If the parameter t is not
|
||||
specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
|
||||
hash are output.)
|
||||
|
||||
6. Security
|
||||
|
||||
The security of the message authentication mechanism presented here
|
||||
depends on cryptographic properties of the hash function H: the
|
||||
resistance to collision finding (limited to the case where the
|
||||
initial value is secret and random, and where the output of the
|
||||
function is not explicitly available to the attacker), and the
|
||||
message authentication property of the compression function of H when
|
||||
applied to single blocks (in HMAC these blocks are partially unknown
|
||||
to an attacker as they contain the result of the inner H computation
|
||||
and, in particular, cannot be fully chosen by the attacker).
|
||||
|
||||
These properties, and actually stronger ones, are commonly assumed
|
||||
for hash functions of the kind used with HMAC. In particular, a hash
|
||||
function for which the above properties do not hold would become
|
||||
unsuitable for most (probably, all) cryptographic applications,
|
||||
including alternative message authentication schemes based on such
|
||||
functions. (For a complete analysis and rationale of the HMAC
|
||||
function the reader is referred to [BCK1].)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Krawczyk, et. al. Informational [Page 5]
|
||||
|
||||
RFC 2104 HMAC February 1997
|
||||
|
||||
|
||||
Given the limited confidence gained so far as for the cryptographic
|
||||
strength of candidate hash functions, it is important to observe the
|
||||
following two properties of the HMAC construction and its secure use
|
||||
for message authentication:
|
||||
|
||||
1. The construction is independent of the details of the particular
|
||||
hash function H in use and then the latter can be replaced by any
|
||||
other secure (iterative) cryptographic hash function.
|
||||
|
||||
2. Message authentication, as opposed to encryption, has a
|
||||
"transient" effect. A published breaking of a message authentication
|
||||
scheme would lead to the replacement of that scheme, but would have
|
||||
no adversarial effect on information authenticated in the past. This
|
||||
is in sharp contrast with encryption, where information encrypted
|
||||
today may suffer from exposure in the future if, and when, the
|
||||
encryption algorithm is broken.
|
||||
|
||||
The strongest attack known against HMAC is based on the frequency of
|
||||
collisions for the hash function H ("birthday attack") [PV,BCK2], and
|
||||
is totally impractical for minimally reasonable hash functions.
|
||||
|
||||
As an example, if we consider a hash function like MD5 where the
|
||||
output length equals L=16 bytes (128 bits) the attacker needs to
|
||||
acquire the correct message authentication tags computed (with the
|
||||
_same_ secret key K!) on about 2**64 known plaintexts. This would
|
||||
require the processing of at least 2**64 blocks under H, an
|
||||
impossible task in any realistic scenario (for a block length of 64
|
||||
bytes this would take 250,000 years in a continuous 1Gbps link, and
|
||||
without changing the secret key K during all this time). This attack
|
||||
could become realistic only if serious flaws in the collision
|
||||
behavior of the function H are discovered (e.g. collisions found
|
||||
after 2**30 messages). Such a discovery would determine the immediate
|
||||
replacement of the function H (the effects of such failure would be
|
||||
far more severe for the traditional uses of H in the context of
|
||||
digital signatures, public key certificates, etc.).
|
||||
|
||||
Note: this attack needs to be strongly contrasted with regular
|
||||
collision attacks on cryptographic hash functions where no secret key
|
||||
is involved and where 2**64 off-line parallelizable (!) operations
|
||||
suffice to find collisions. The latter attack is approaching
|
||||
feasibility [VW] while the birthday attack on HMAC is totally
|
||||
impractical. (In the above examples, if one uses a hash function
|
||||
with, say, 160 bit of output then 2**64 should be replaced by 2**80.)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Krawczyk, et. al. Informational [Page 6]
|
||||
|
||||
RFC 2104 HMAC February 1997
|
||||
|
||||
|
||||
A correct implementation of the above construction, the choice of
|
||||
random (or cryptographically pseudorandom) keys, a secure key
|
||||
exchange mechanism, frequent key refreshments, and good secrecy
|
||||
protection of keys are all essential ingredients for the security of
|
||||
the integrity verification mechanism provided by HMAC.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Krawczyk, et. al. Informational [Page 7]
|
||||
|
||||
RFC 2104 HMAC February 1997
|
||||
|
||||
|
||||
Appendix -- Sample Code
|
||||
|
||||
For the sake of illustration we provide the following sample code for
|
||||
the implementation of HMAC-MD5 as well as some corresponding test
|
||||
vectors (the code is based on MD5 code as described in [MD5]).
|
||||
|
||||
/*
|
||||
** Function: hmac_md5
|
||||
*/
|
||||
|
||||
void
|
||||
hmac_md5(text, text_len, key, key_len, digest)
|
||||
unsigned char* text; /* pointer to data stream */
|
||||
int text_len; /* length of data stream */
|
||||
unsigned char* key; /* pointer to authentication key */
|
||||
int key_len; /* length of authentication key */
|
||||
caddr_t digest; /* caller digest to be filled in */
|
||||
|
||||
{
|
||||
MD5_CTX context;
|
||||
unsigned char k_ipad[65]; /* inner padding -
|
||||
* key XORd with ipad
|
||||
*/
|
||||
unsigned char k_opad[65]; /* outer padding -
|
||||
* key XORd with opad
|
||||
*/
|
||||
unsigned char tk[16];
|
||||
int i;
|
||||
/* if key is longer than 64 bytes reset it to key=MD5(key) */
|
||||
if (key_len > 64) {
|
||||
|
||||
MD5_CTX tctx;
|
||||
|
||||
MD5Init(&tctx);
|
||||
MD5Update(&tctx, key, key_len);
|
||||
MD5Final(tk, &tctx);
|
||||
|
||||
key = tk;
|
||||
key_len = 16;
|
||||
}
|
||||
|
||||
/*
|
||||
* the HMAC_MD5 transform looks like:
|
||||
*
|
||||
* MD5(K XOR opad, MD5(K XOR ipad, text))
|
||||
*
|
||||
* where K is an n byte key
|
||||
* ipad is the byte 0x36 repeated 64 times
|
||||
|
||||
|
||||
|
||||
Krawczyk, et. al. Informational [Page 8]
|
||||
|
||||
RFC 2104 HMAC February 1997
|
||||
|
||||
|
||||
* opad is the byte 0x5c repeated 64 times
|
||||
* and text is the data being protected
|
||||
*/
|
||||
|
||||
/* start out by storing key in pads */
|
||||
bzero( k_ipad, sizeof k_ipad);
|
||||
bzero( k_opad, sizeof k_opad);
|
||||
bcopy( key, k_ipad, key_len);
|
||||
bcopy( key, k_opad, key_len);
|
||||
|
||||
/* XOR key with ipad and opad values */
|
||||
for (i=0; i<64; i++) {
|
||||
k_ipad[i] ^= 0x36;
|
||||
k_opad[i] ^= 0x5c;
|
||||
}
|
||||
/*
|
||||
* perform inner MD5
|
||||
*/
|
||||
MD5Init(&context); /* init context for 1st
|
||||
* pass */
|
||||
MD5Update(&context, k_ipad, 64) /* start with inner pad */
|
||||
MD5Update(&context, text, text_len); /* then text of datagram */
|
||||
MD5Final(digest, &context); /* finish up 1st pass */
|
||||
/*
|
||||
* perform outer MD5
|
||||
*/
|
||||
MD5Init(&context); /* init context for 2nd
|
||||
* pass */
|
||||
MD5Update(&context, k_opad, 64); /* start with outer pad */
|
||||
MD5Update(&context, digest, 16); /* then results of 1st
|
||||
* hash */
|
||||
MD5Final(digest, &context); /* finish up 2nd pass */
|
||||
}
|
||||
|
||||
Test Vectors (Trailing '\0' of a character string not included in test):
|
||||
|
||||
key = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
|
||||
key_len = 16 bytes
|
||||
data = "Hi There"
|
||||
data_len = 8 bytes
|
||||
digest = 0x9294727a3638bb1c13f48ef8158bfc9d
|
||||
|
||||
key = "Jefe"
|
||||
data = "what do ya want for nothing?"
|
||||
data_len = 28 bytes
|
||||
digest = 0x750c783e6ab0b503eaa86e310a5db738
|
||||
|
||||
key = 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
|
||||
|
||||
|
||||
|
||||
Krawczyk, et. al. Informational [Page 9]
|
||||
|
||||
RFC 2104 HMAC February 1997
|
||||
|
||||
|
||||
key_len 16 bytes
|
||||
data = 0xDDDDDDDDDDDDDDDDDDDD...
|
||||
..DDDDDDDDDDDDDDDDDDDD...
|
||||
..DDDDDDDDDDDDDDDDDDDD...
|
||||
..DDDDDDDDDDDDDDDDDDDD...
|
||||
..DDDDDDDDDDDDDDDDDDDD
|
||||
data_len = 50 bytes
|
||||
digest = 0x56be34521d144c88dbb8c733f0e8b3f6
|
||||
|
||||
Acknowledgments
|
||||
|
||||
Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided
|
||||
useful comments on early drafts, and ran the first interoperability
|
||||
tests of this specification. Jeff and Pau-Chen kindly provided the
|
||||
sample code and test vectors that appear in the appendix. Burt
|
||||
Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van
|
||||
Oorschot have provided useful comments and suggestions during the
|
||||
investigation of the HMAC construction.
|
||||
|
||||
References
|
||||
|
||||
[ANSI] ANSI X9.9, "American National Standard for Financial
|
||||
Institution Message Authentication (Wholesale)," American
|
||||
Bankers Association, 1981. Revised 1986.
|
||||
|
||||
[Atk] Atkinson, R., "IP Authentication Header", RFC 1826, August
|
||||
1995.
|
||||
|
||||
[BCK1] M. Bellare, R. Canetti, and H. Krawczyk,
|
||||
"Keyed Hash Functions and Message Authentication",
|
||||
Proceedings of Crypto'96, LNCS 1109, pp. 1-15.
|
||||
(http://www.research.ibm.com/security/keyed-md5.html)
|
||||
|
||||
[BCK2] M. Bellare, R. Canetti, and H. Krawczyk,
|
||||
"Pseudorandom Functions Revisited: The Cascade Construction",
|
||||
Proceedings of FOCS'96.
|
||||
|
||||
[Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack",
|
||||
RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
|
||||
http://www.rsa.com/rsalabs/pubs/cryptobytes.html
|
||||
|
||||
[PV] B. Preneel and P. van Oorschot, "Building fast MACs from hash
|
||||
functions", Advances in Cryptology -- CRYPTO'95 Proceedings,
|
||||
Lecture Notes in Computer Science, Springer-Verlag Vol.963,
|
||||
1995, pp. 1-14.
|
||||
|
||||
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm",
|
||||
RFC 1321, April 1992.
|
||||
|
||||
|
||||
|
||||
Krawczyk, et. al. Informational [Page 10]
|
||||
|
||||
RFC 2104 HMAC February 1997
|
||||
|
||||
|
||||
[MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,
|
||||
1982.
|
||||
|
||||
[RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A
|
||||
strengthened version of RIPEMD", Fast Software Encryption,
|
||||
LNCS Vol 1039, pp. 71-82.
|
||||
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.
|
||||
|
||||
[SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
|
||||
|
||||
[Tsu] G. Tsudik, "Message authentication with one-way hash
|
||||
functions", In Proceedings of Infocom'92, May 1992.
|
||||
(Also in "Access Control and Policy Enforcement in
|
||||
Internetworks", Ph.D. Dissertation, Computer Science
|
||||
Department, University of Southern California, April 1991.)
|
||||
|
||||
[VW] P. van Oorschot and M. Wiener, "Parallel Collision
|
||||
Search with Applications to Hash Functions and Discrete
|
||||
Logarithms", Proceedings of the 2nd ACM Conf. Computer and
|
||||
Communications Security, Fairfax, VA, November 1994.
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Hugo Krawczyk
|
||||
IBM T.J. Watson Research Center
|
||||
P.O.Box 704
|
||||
Yorktown Heights, NY 10598
|
||||
|
||||
EMail: [email protected]
|
||||
|
||||
Mihir Bellare
|
||||
Dept of Computer Science and Engineering
|
||||
Mail Code 0114
|
||||
University of California at San Diego
|
||||
9500 Gilman Drive
|
||||
La Jolla, CA 92093
|
||||
|
||||
EMail: [email protected]
|
||||
|
||||
Ran Canetti
|
||||
IBM T.J. Watson Research Center
|
||||
P.O.Box 704
|
||||
Yorktown Heights, NY 10598
|
||||
|
||||
EMail: [email protected]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Krawczyk, et. al. Informational [Page 11]
|
||||
|
||||
+1795
File diff suppressed because it is too large
Load Diff
+4819
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
+563
@@ -0,0 +1,563 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group T. Kivinen
|
||||
Request for Comments: 3526 M. Kojo
|
||||
Category: Standards Track SSH Communications Security
|
||||
May 2003
|
||||
|
||||
|
||||
More Modular Exponential (MODP) Diffie-Hellman groups
|
||||
for Internet Key Exchange (IKE)
|
||||
|
||||
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 (2003). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
This document defines new Modular Exponential (MODP) Groups for the
|
||||
Internet Key Exchange (IKE) protocol. It documents the well known
|
||||
and used 1536 bit group 5, and also defines new 2048, 3072, 4096,
|
||||
6144, and 8192 bit Diffie-Hellman groups numbered starting at 14.
|
||||
The selection of the primes for theses groups follows the criteria
|
||||
established by Richard Schroeppel.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 2
|
||||
2. 1536-bit MODP Group . . . . . . . . . . . . . . . . . . . 3
|
||||
3. 2048-bit MODP Group . . . . . . . . . . . . . . . . . . . 3
|
||||
4. 3072-bit MODP Group . . . . . . . . . . . . . . . . . . . 4
|
||||
5. 4096-bit MODP Group . . . . . . . . . . . . . . . . . . . 5
|
||||
6. 6144-bit MODP Group . . . . . . . . . . . . . . . . . . . 6
|
||||
7. 8192-bit MODP Group . . . . . . . . . . . . . . . . . . . 6
|
||||
8. Security Considerations . . . . . . . . . . . . . . . . . 8
|
||||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 8
|
||||
10. Normative References. . . . . . . . . . . . . . . . . . . 8
|
||||
11. Non-Normative References. . . . . . . . . . . . . . . . . 8
|
||||
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . 9
|
||||
13. Full Copyright Statement. . . . . . . . . . . . . . . . . 10
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kivinen & Kojo Standards Track [Page 1]
|
||||
|
||||
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
One of the important protocol parameters negotiated by Internet Key
|
||||
Exchange (IKE) [RFC-2409] is the Diffie-Hellman "group" that will be
|
||||
used for certain cryptographic operations. IKE currently defines 4
|
||||
groups. These groups are approximately as strong as a symmetric key
|
||||
of 70-80 bits.
|
||||
|
||||
The new Advanced Encryption Standard (AES) cipher [AES], which has
|
||||
more strength, needs stronger groups. For the 128-bit AES we need
|
||||
about a 3200-bit group [Orman01]. The 192 and 256-bit keys would
|
||||
need groups that are about 8000 and 15400 bits respectively. Another
|
||||
source [RSA13] [Rousseau00] estimates that the security equivalent
|
||||
key size for the 192-bit symmetric cipher is 2500 bits instead of
|
||||
8000 bits, and the equivalent key size 256-bit symmetric cipher is
|
||||
4200 bits instead of 15400 bits.
|
||||
|
||||
Because of this disagreement, we just specify different groups
|
||||
without specifying which group should be used with 128, 192 or 256-
|
||||
bit AES. With current hardware groups bigger than 8192-bits being
|
||||
too slow for practical use, this document does not provide any groups
|
||||
bigger than 8192-bits.
|
||||
|
||||
The exponent size used in the Diffie-Hellman must be selected so that
|
||||
it matches other parts of the system. It should not be the weakest
|
||||
link in the security system. It should have double the entropy of
|
||||
the strength of the entire system, i.e., if you use a group whose
|
||||
strength is 128 bits, you must use more than 256 bits of randomness
|
||||
in the exponent used in the Diffie-Hellman calculation.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kivinen & Kojo Standards Track [Page 2]
|
||||
|
||||
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
|
||||
|
||||
|
||||
2. 1536-bit MODP Group
|
||||
|
||||
The 1536 bit MODP group has been used for the implementations for
|
||||
quite a long time, but was not defined in RFC 2409 (IKE).
|
||||
Implementations have been using group 5 to designate this group, we
|
||||
standardize that practice here.
|
||||
|
||||
The prime is: 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }
|
||||
|
||||
Its hexadecimal value is:
|
||||
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
|
||||
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
|
||||
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
|
||||
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
|
||||
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
|
||||
|
||||
The generator is: 2.
|
||||
|
||||
3. 2048-bit MODP Group
|
||||
|
||||
This group is assigned id 14.
|
||||
|
||||
This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
|
||||
|
||||
Its hexadecimal value is:
|
||||
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
|
||||
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
|
||||
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
|
||||
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
|
||||
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
|
||||
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
|
||||
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
|
||||
15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
|
||||
|
||||
The generator is: 2.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kivinen & Kojo Standards Track [Page 3]
|
||||
|
||||
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
|
||||
|
||||
|
||||
4. 3072-bit MODP Group
|
||||
|
||||
This group is assigned id 15.
|
||||
|
||||
This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] + 1690314 }
|
||||
|
||||
Its hexadecimal value is:
|
||||
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
|
||||
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
|
||||
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
|
||||
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
|
||||
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
|
||||
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
|
||||
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
|
||||
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
|
||||
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
|
||||
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
|
||||
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
|
||||
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
|
||||
43DB5BFC E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
|
||||
|
||||
The generator is: 2.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kivinen & Kojo Standards Track [Page 4]
|
||||
|
||||
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
|
||||
|
||||
|
||||
5. 4096-bit MODP Group
|
||||
|
||||
This group is assigned id 16.
|
||||
|
||||
This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] + 240904 }
|
||||
|
||||
Its hexadecimal value is:
|
||||
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
|
||||
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
|
||||
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
|
||||
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
|
||||
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
|
||||
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
|
||||
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
|
||||
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
|
||||
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
|
||||
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
|
||||
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
|
||||
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
|
||||
43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
|
||||
88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
|
||||
2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
|
||||
287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
|
||||
1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
|
||||
93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
|
||||
FFFFFFFF FFFFFFFF
|
||||
|
||||
The generator is: 2.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kivinen & Kojo Standards Track [Page 5]
|
||||
|
||||
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
|
||||
|
||||
|
||||
6. 6144-bit MODP Group
|
||||
|
||||
This group is assigned id 17.
|
||||
|
||||
This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] + 929484 }
|
||||
|
||||
Its hexadecimal value is:
|
||||
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
|
||||
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
|
||||
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
|
||||
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
|
||||
49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
|
||||
FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
|
||||
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
|
||||
180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
|
||||
3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
|
||||
04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
|
||||
B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
|
||||
1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
|
||||
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
|
||||
E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
|
||||
99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
|
||||
04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
|
||||
233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
|
||||
D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
|
||||
36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
|
||||
AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
|
||||
DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
|
||||
2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
|
||||
F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
|
||||
BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
|
||||
CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
|
||||
B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
|
||||
387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
|
||||
6DCC4024 FFFFFFFF FFFFFFFF
|
||||
|
||||
The generator is: 2.
|
||||
|
||||
7. 8192-bit MODP Group
|
||||
|
||||
This group is assigned id 18.
|
||||
|
||||
This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] + 4743158 }
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kivinen & Kojo Standards Track [Page 6]
|
||||
|
||||
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
|
||||
|
||||
|
||||
Its hexadecimal value is:
|
||||
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
|
||||
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
|
||||
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
|
||||
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
|
||||
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
|
||||
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
|
||||
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
|
||||
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
|
||||
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
|
||||
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
|
||||
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
|
||||
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
|
||||
43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
|
||||
88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
|
||||
2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
|
||||
287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
|
||||
1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
|
||||
93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
|
||||
36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD
|
||||
F8FF9406 AD9E530E E5DB382F 413001AE B06A53ED 9027D831
|
||||
179727B0 865A8918 DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B
|
||||
DB7F1447 E6CC254B 33205151 2BD7AF42 6FB8F401 378CD2BF
|
||||
5983CA01 C64B92EC F032EA15 D1721D03 F482D7CE 6E74FEF6
|
||||
D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F BEC7E8F3
|
||||
23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
|
||||
CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328
|
||||
06A1D58B B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C
|
||||
DA56C9EC 2EF29632 387FE8D7 6E3C0468 043E8F66 3F4860EE
|
||||
12BF2D5B 0B7474D6 E694F91E 6DBE1159 74A3926F 12FEE5E4
|
||||
38777CB6 A932DF8C D8BEC4D0 73B931BA 3BC832B6 8D9DD300
|
||||
741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C 5AE4F568
|
||||
3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
|
||||
22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B
|
||||
4BCBC886 2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A
|
||||
062B3CF5 B3A278A6 6D2A13F8 3F44F82D DF310EE0 74AB6A36
|
||||
4597E899 A0255DC1 64F31CC5 0846851D F9AB4819 5DED7EA1
|
||||
B1D510BD 7EE74D73 FAF36BC3 1ECFA268 359046F4 EB879F92
|
||||
4009438B 481C6CD7 889A002E D5EE382B C9190DA6 FC026E47
|
||||
9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
|
||||
60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
|
||||
|
||||
The generator is: 2.
|
||||
|
||||
|
||||
|
||||
|
||||
Kivinen & Kojo Standards Track [Page 7]
|
||||
|
||||
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
|
||||
|
||||
|
||||
8. Security Considerations
|
||||
|
||||
This document describes new stronger groups to be used in IKE. The
|
||||
strengths of the groups defined here are always estimates and there
|
||||
are as many methods to estimate them as there are cryptographers.
|
||||
For the strength estimates below we took the both ends of the scale
|
||||
so the actual strength estimate is likely between the two numbers
|
||||
given here.
|
||||
|
||||
+--------+----------+---------------------+---------------------+
|
||||
| Group | Modulus | Strength Estimate 1 | Strength Estimate 2 |
|
||||
| | +----------+----------+----------+----------+
|
||||
| | | | exponent | | exponent |
|
||||
| | | in bits | size | in bits | size |
|
||||
+--------+----------+----------+----------+----------+----------+
|
||||
| 5 | 1536-bit | 90 | 180- | 120 | 240- |
|
||||
| 14 | 2048-bit | 110 | 220- | 160 | 320- |
|
||||
| 15 | 3072-bit | 130 | 260- | 210 | 420- |
|
||||
| 16 | 4096-bit | 150 | 300- | 240 | 480- |
|
||||
| 17 | 6144-bit | 170 | 340- | 270 | 540- |
|
||||
| 18 | 8192-bit | 190 | 380- | 310 | 620- |
|
||||
+--------+----------+---------------------+---------------------+
|
||||
|
||||
9. IANA Considerations
|
||||
|
||||
IKE [RFC-2409] defines 4 Diffie-Hellman Groups, numbered 1 through 4.
|
||||
|
||||
This document defines a new group 5, and new groups from 14 to 18.
|
||||
Requests for additional assignment are via "IETF Consensus" as
|
||||
defined in RFC 2434 [RFC-2434]. Specifically, new groups are
|
||||
expected to be documented in a Standards Track RFC.
|
||||
|
||||
10. Normative References
|
||||
|
||||
[RFC-2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
|
||||
(IKE)", RFC 2409, November 1998.
|
||||
|
||||
[RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
|
||||
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
|
||||
October 1998.
|
||||
|
||||
11. Non-Normative References
|
||||
|
||||
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard
|
||||
(AES)," November 2001.
|
||||
http://csrc.nist.gov/publications/fips/fips197/fips-
|
||||
197.{ps,pdf}
|
||||
|
||||
|
||||
|
||||
|
||||
Kivinen & Kojo Standards Track [Page 8]
|
||||
|
||||
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
|
||||
|
||||
|
||||
[RFC-2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
|
||||
2412, November 1998.
|
||||
|
||||
[Orman01] Orman, H. and P. Hoffman, "Determining Strengths For
|
||||
Public Keys Used For Exchanging Symmetric Keys", Work in
|
||||
progress.
|
||||
|
||||
[RSA13] Silverman, R. "RSA Bulleting #13: A Cost-Based Security
|
||||
Analysis of Symmetric and Asymmetric Key Lengths", April
|
||||
2000, http://www.rsasecurity.com/rsalabs/bulletins/
|
||||
bulletin13.html
|
||||
|
||||
[Rousseau00] Rousseau, F. "New Time and Space Based Key Size
|
||||
Equivalents for RSA and Diffie-Hellman", December 2000,
|
||||
http://www.sandelman.ottawa.on.ca/ipsec/2000/12/
|
||||
msg00045.html
|
||||
|
||||
12. Authors' Addresses
|
||||
|
||||
Tero Kivinen
|
||||
SSH Communications Security Corp
|
||||
Fredrikinkatu 42
|
||||
FIN-00100 HELSINKI
|
||||
Finland
|
||||
|
||||
EMail: [email protected]
|
||||
|
||||
|
||||
Mika Kojo
|
||||
HELSINKI
|
||||
Finland
|
||||
|
||||
EMail: [email protected]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kivinen & Kojo Standards Track [Page 9]
|
||||
|
||||
RFC 3526 MODP Diffie-Hellman groups for IKE May 2003
|
||||
|
||||
|
||||
13. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2003). 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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kivinen & Kojo Standards Track [Page 10]
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
+339
@@ -0,0 +1,339 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group J. Schiller
|
||||
Request for Comments: 4307 Massachusetts Institute of Technology
|
||||
Category: Standards Track December 2005
|
||||
|
||||
|
||||
Cryptographic Algorithms for Use in the
|
||||
Internet Key Exchange Version 2 (IKEv2)
|
||||
|
||||
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 (2005).
|
||||
|
||||
Abstract
|
||||
|
||||
The IPsec series of protocols makes use of various cryptographic
|
||||
algorithms in order to provide security services. The Internet Key
|
||||
Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate
|
||||
which algorithms should be used in any given association. However,
|
||||
to ensure interoperability between disparate implementations, it is
|
||||
necessary to specify a set of mandatory-to-implement algorithms to
|
||||
ensure that there is at least one algorithm that all implementations
|
||||
will have available. This document defines the current set of
|
||||
algorithms that are mandatory to implement as part of IKEv2, as well
|
||||
as algorithms that should be implemented because they may be promoted
|
||||
to mandatory at some future time.
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Internet Key Exchange protocol provides for the negotiation of
|
||||
cryptographic algorithms between both endpoints of a cryptographic
|
||||
|
||||
association. Different implementations of IPsec and IKE may provide
|
||||
different algorithms. However, the IETF desires that all
|
||||
implementations should have some way to interoperate. In particular,
|
||||
this requires that IKE define a set of mandatory-to-implement
|
||||
algorithms because IKE itself uses such algorithms as part of its own
|
||||
negotiations. This requires that some set of algorithms be specified
|
||||
as "mandatory-to-implement" for IKE.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schiller Standards Track [Page 1]
|
||||
|
||||
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
||||
|
||||
|
||||
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.
|
||||
|
||||
Finally, we need to recognize that the mandatory-to-implement
|
||||
algorithm(s) may need to change over time to adapt to the changing
|
||||
world. For this reason, the selection of mandatory-to-implement
|
||||
algorithms was removed from the main IKEv2 specification and placed
|
||||
in this document. As the choice of algorithm changes, only this
|
||||
document should need to be updated.
|
||||
|
||||
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, we will attempt to identify
|
||||
those algorithms (that are known today) in this document. There is
|
||||
no guarantee that the algorithms we believe today may be mandatory in
|
||||
the future will in fact become so. All algorithms known today are
|
||||
subject to cryptographic attack and may be broken in the future.
|
||||
|
||||
2. Requirements Terminology
|
||||
|
||||
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and
|
||||
"MAY" that appear in this document are to be interpreted as described
|
||||
in [RFC2119].
|
||||
|
||||
We define some additional terms here:
|
||||
|
||||
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.
|
||||
|
||||
SHOULD- This term means the same as SHOULD. However, an algorithm
|
||||
marked as SHOULD- may be deprecated to a MAY in a future
|
||||
version of this document.
|
||||
|
||||
MUST- This term means the same as MUST. However, we expect at
|
||||
some point that this algorithm will no longer be a MUST in
|
||||
a future document. Although its status will be determined
|
||||
at a later time, it is reasonable to expect that if a
|
||||
future revision of a document alters the status of a MUST-
|
||||
algorithm, it will remain at least a SHOULD or a SHOULD-.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schiller Standards Track [Page 2]
|
||||
|
||||
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
||||
|
||||
|
||||
3. Algorithm Selection
|
||||
|
||||
3.1. IKEv2 Algorithm Selection
|
||||
|
||||
3.1.1. Encrypted Payload Algorithms
|
||||
|
||||
The IKEv2 Encrypted Payload requires both a confidentiality algorithm
|
||||
and an integrity algorithm. For confidentiality, implementations
|
||||
MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For
|
||||
integrity, HMAC-SHA1 MUST be implemented.
|
||||
|
||||
3.1.2. Diffie-Hellman Groups
|
||||
|
||||
There are several Modular Exponential (MODP) groups that are defined
|
||||
for use in IKEv2. They are defined in both the [IKEv2] base document
|
||||
and in the MODP extensions document. They are identified by group
|
||||
number. Any groups not listed here are considered as "MAY be
|
||||
implemented".
|
||||
|
||||
Group Number Bit Length Status Defined
|
||||
2 1024 MODP Group MUST- [RFC2409]
|
||||
14 2048 MODP Group SHOULD+ [RFC3526]
|
||||
|
||||
3.1.3. IKEv2 Transform Type 1 Algorithms
|
||||
|
||||
IKEv2 defines several possible algorithms for Transfer Type 1
|
||||
(encryption). These are defined below with their implementation
|
||||
status.
|
||||
|
||||
Name Number Defined In Status
|
||||
RESERVED 0
|
||||
ENCR_3DES 3 [RFC2451] MUST-
|
||||
ENCR_NULL 11 [RFC2410] MAY
|
||||
ENCR_AES_CBC 12 [AES-CBC] SHOULD+
|
||||
ENCR_AES_CTR 13 [AES-CTR] SHOULD
|
||||
|
||||
3.1.4. IKEv2 Transform Type 2 Algorithms
|
||||
|
||||
Transfer Type 2 Algorithms are pseudo-random functions used to
|
||||
generate random values when needed.
|
||||
|
||||
Name Number Defined In Status
|
||||
RESERVED 0
|
||||
PRF_HMAC_MD5 1 [RFC2104] MAY
|
||||
PRF_HMAC_SHA1 2 [RFC2104] MUST
|
||||
PRF_AES128_CBC 4 [AESPRF] SHOULD+
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schiller Standards Track [Page 3]
|
||||
|
||||
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
||||
|
||||
|
||||
3.1.5. IKEv2 Transform Type 3 Algorithms
|
||||
|
||||
Transfer Type 3 Algorithms are Integrity algorithms used to protect
|
||||
data against tampering.
|
||||
|
||||
Name Number Defined In Status
|
||||
NONE 0
|
||||
AUTH_HMAC_MD5_96 1 [RFC2403] MAY
|
||||
AUTH_HMAC_SHA1_96 2 [RFC2404] MUST
|
||||
AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
The security of cryptographic-based systems 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 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 IKEv2, 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 so far
|
||||
leads us to believe that they will likely remain secure into the
|
||||
foreseeable future. However, this isn't necessarily forever. We
|
||||
would therefore expect that new revisions of this document will be
|
||||
issued from time to time that reflect the current best practice in
|
||||
this area.
|
||||
|
||||
5. Normative References
|
||||
|
||||
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
|
||||
(IKE)", RFC 2409, November 1998.
|
||||
|
||||
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
|
||||
Protocol", RFC 4306, December 2005.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential
|
||||
(MODP) Diffie-Hellman groups for Internet Key Exchange
|
||||
(IKE)", RFC 3526, May 2003.
|
||||
|
||||
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
|
||||
Algorithms", RFC 2451, November 1998.
|
||||
|
||||
|
||||
|
||||
Schiller Standards Track [Page 4]
|
||||
|
||||
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
||||
|
||||
|
||||
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm
|
||||
and Its Use With IPsec", RFC 2410, November 1998.
|
||||
|
||||
[AES-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
|
||||
Cipher Algorithm and Its Use with IPsec", RFC 3602,
|
||||
September 2003.
|
||||
|
||||
[AES-CTR] Housley, R., "Using Advanced Encryption Standard (AES)
|
||||
Counter Mode With IPsec Encapsulating Security Payload
|
||||
(ESP)", RFC 3686, January 2004.
|
||||
|
||||
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
|
||||
Keyed-Hashing for Message Authentication", RFC 2104,
|
||||
February 1997.
|
||||
|
||||
[AESPRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
|
||||
Internet Key Exchange Protocol (IKE)", RFC 3664, January
|
||||
2004.
|
||||
|
||||
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
|
||||
ESP and AH", RFC 2403, November 1998.
|
||||
|
||||
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
|
||||
within ESP and AH", RFC 2404, November 1998.
|
||||
|
||||
[AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
|
||||
Algorithm and Its Use With IPsec", RFC 3566, September
|
||||
2003.
|
||||
|
||||
Author's Address
|
||||
|
||||
Jeffrey I. Schiller
|
||||
Massachusetts Institute of Technology
|
||||
Room W92-190
|
||||
77 Massachusetts Avenue
|
||||
Cambridge, MA 02139-4307
|
||||
USA
|
||||
|
||||
Phone: +1 (617) 253-0161
|
||||
EMail: [email protected]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schiller Standards Track [Page 5]
|
||||
|
||||
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2005).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM 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.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at ietf-
|
||||
[email protected].
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schiller Standards Track [Page 6]
|
||||
|
||||
BIN
Binary file not shown.
Reference in New Issue
Block a user