draft-ietf-smime-x942-03.txt | draft-ietf-smime-x942-04.txt | |||
---|---|---|---|---|

E. Rescorla | E. Rescorla | |||

INTERNET-DRAFT RTFM Inc. | INTERNET-DRAFT RTFM Inc. | |||

<draft-ietf-smime-x942-03.txt> November 1998 (Expires May 1999) | <draft-ietf-smime-x942-04.txt> December 1998 (Expires June 1999) | |||

Diffie-Hellman Key Agreement Method | Diffie-Hellman Key Agreement Method | |||

Status of this Memo | Status of this Memo | |||

This document is an Internet-Draft. Internet-Drafts are working | This document is an Internet-Draft. Internet-Drafts are working | |||

documents of the Internet Engineering Task Force (IETF), its areas, | documents of the Internet Engineering Task Force (IETF), its areas, | |||

and its working groups. Note that other groups may also distribute | and its working groups. Note that other groups may also distribute | |||

working documents as Internet-Drafts. | working documents as Internet-Drafts. | |||

skipping to change at line 30 | skipping to change at line 29 | |||

To learn the current status of any Internet-Draft, please check the | To learn the current status of any Internet-Draft, please check the | |||

``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow | ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow | |||

Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), | Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), | |||

munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or | munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or | |||

ftp.isi.edu (US West Coast). | ftp.isi.edu (US West Coast). | |||

Abstract | Abstract | |||

This document standardizes one particular Diffie-Hellman variant, | This document standardizes one particular Diffie-Hellman variant, | |||

based on the ANSI X9.42 standard, developed by the ANSI X9F1 working | based on the ANSI X9.42 standard, developed by the ANSI X9F1 working | |||

group. Diffie-Hellam is a key agreement algorithm used by two parties | group. Diffie-Hellman is a key agreement algorithm used by two par- | |||

to agree on a shared secret. An algorithm for converting the shared | ties to agree on a shared secret. An algorithm for converting the | |||

secret into an arbitrary amount of keying material is provided. The | shared secret into an arbitrary amount of keying material is pro- | |||

resulting keying material is used as a symmetric encryption key. The | vided. The resulting keying material is used as a symmetric encryp- | |||

D-H variant described requires the recipient to have a certificate, | tion key. The D-H variant described requires the recipient to have a | |||

but the originator may have a static key pair (with the public key | certificate, but the originator may have a static key pair (with the | |||

placed in a certificate) or an ephemeral key pair. | public key placed in a certificate) or an ephemeral key pair. | |||

1. Introduction | 1. Introduction | |||

In [DH76] Diffie and Hellman describe a means for two parties to | In [DH76] Diffie and Hellman describe a means for two parties to | |||

agree upon a shared secret in such a way that the secret will be una- | agree upon a shared secret in such a way that the secret will be una- | |||

vailable to eavesdroppers. This secret may then be converted into | vailable to eavesdroppers. This secret may then be converted into | |||

cryptographic keying material for other (symmetric) algorithms. A | cryptographic keying material for other (symmetric) algorithms. A | |||

large number of minor variants of this process exist. This document | large number of minor variants of this process exist. This document | |||

describes one such variant, based on the ANSI X9.42 specification. | describes one such variant, based on the ANSI X9.42 specification. | |||

skipping to change at line 70 | skipping to change at line 69 | |||

"MAY" that appear in this document are to be interpreted as described | "MAY" that appear in this document are to be interpreted as described | |||

in [RFC2119]. | in [RFC2119]. | |||

2. Overview Of Method | 2. Overview Of Method | |||

Diffie-Hellman key agreement requires that both the sender and reci- | Diffie-Hellman key agreement requires that both the sender and reci- | |||

pient of a message have key pairs. By combining one's private key and | pient of a message have key pairs. By combining one's private key and | |||

the other party's public key, both parties can compute the same | the other party's public key, both parties can compute the same | |||

shared secret number. This number can then be converted into crypto- | shared secret number. This number can then be converted into crypto- | |||

graphic keying material. That keying material is typically used as a | graphic keying material. That keying material is typically used as a | |||

key encryption key (KEK) to encrypt (wrap) a content encryption key | key-encryption key (KEK) to encrypt (wrap) a content-encryption key | |||

(CEK) which is in turn used to encrypt the message data. | (CEK) which is in turn used to encrypt the message data. | |||

2.1. Key Agreement | 2.1. Key Agreement | |||

The first stage of the key agreement process is to compute a shared | The first stage of the key agreement process is to compute a shared | |||

secret number, called ZZ. When the same originator and recipient | secret number, called ZZ. When the same originator and recipient | |||

public/private key pairs are used, the same ZZ value will result. | public/private key pairs are used, the same ZZ value will result. | |||

The ZZ value is then converted into a shared symmetric cryptographic | The ZZ value is then converted into a shared symmetric cryptographic | |||

key. When the originator employs a static private/public key pair, | key. When the originator employs a static private/public key pair, | |||

the introduction of public random values are used to ensure that the | the introduction of public random values are used to ensure that the | |||

resulting symmetric key will be different for each key agreement. | resulting symmetric key will be different for each key agreement. | |||

2.1.1. Generation of ZZ | 2.1.1. Generation of ZZ | |||

X9.42 defines that the shared secret ZZ is generated as follows: | X9.42 defines that the shared secret ZZ is generated as follows: | |||

ZZ = g ^ (xb * xa) (mod p) | ZZ = g ^ (xb * xa) mod p | |||

Note that the individual parties actually perform the computations: | Note that the individual parties actually perform the computations: | |||

ZZ = yb ^ xa (mod p) = ya ^ xb (mod p) | ZZ = yb ^ xa (mod p) = ya ^ xb mod p | |||

where ^ denotes exponentiation | where ^ denotes exponentiation | |||

ya is party a's public key; ya = g ^ xa (mod p) | ya is party a's public key; ya = g ^ xa mod p | |||

yb is party b's public key; yb = g ^ xb (mod p) | yb is party b's public key; yb = g ^ xb mod p | |||

xa is party a's private key | xa is party a's private key | |||

Rescorla [Page 2]Internet-Draft Diffie-Hellman Key Agreement Method | Rescorla [Page 2]Internet-Draft Diffie-Hellman Key Agreement Method | |||

xb is party b's private key | xb is party b's private key | |||

p is a large prime | p is a large prime | |||

g is a generator for the integer group specified by p. | g = h(p-1)/q mod p, where | |||

j a large integer such that | h is any integer with 1 < h < p-1 such that h(p-1)/q mod p > 1 | |||

q is a large prime and p=qj + 1 | (g has order q mod p) | |||

q is a large prime | ||||

j a large integer such that p=qj + 1 | ||||

(See Section 2.2 for criteria for keys and parameters) | (See Section 2.2 for criteria for keys and parameters) | |||

In CMS, the recipient's key is identified by the CMS RecipientIden- | In [CMS], the recipient's key is identified by the CMS RecipientIden- | |||

tifier, which points to the recipient's certificate. The sender's | tifier, which points to the recipient's certificate. The sender's | |||

key is identified using the OriginatorIdentifierOrKey field, either | key is identified using the OriginatorIdentifierOrKey field, either | |||

by reference to the sender's certificate or by inline inclusion of a | by reference to the sender's certificate or by inline inclusion of a | |||

key. | key. | |||

2.1.2. Generation of Keying Material | 2.1.2. Generation of Keying Material | |||

X9.42 provides an algorithm for generating an essentially arbitrary | X9.42 provides an algorithm for generating an essentially arbitrary | |||

amount of keying material from ZZ. Our algorithm is derived from that | amount of keying material from ZZ. Our algorithm is derived from that | |||

algorithm by mandating some optional fields and omitting others. | algorithm by mandating some optional fields and omitting others. | |||

skipping to change at line 135 | skipping to change at line 136 | |||

OtherInfo ::= SEQUENCE { | OtherInfo ::= SEQUENCE { | |||

keyInfo KeySpecificInfo, | keyInfo KeySpecificInfo, | |||

pubInfo [2] OCTET STRING OPTIONAL, | pubInfo [2] OCTET STRING OPTIONAL, | |||

} | } | |||

KeySpecificInfo ::= SEQUENCE { | KeySpecificInfo ::= SEQUENCE { | |||

algorithm OBJECT IDENTIFIER, | algorithm OBJECT IDENTIFIER, | |||

counter OCTET STRING SIZE (4..4) } | counter OCTET STRING SIZE (4..4) } | |||

algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which | algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which | |||

this KEK will be used. | this KEK will be used. Note that this is NOT an AlgorithmIdentifier, | |||

counter is a 32 bit number, represented in network byte order. | but simply the OBJECT IDENTIFIER. No paramters are used. | |||

Its initial value is 1, i.e. the byte sequence 00 00 00 01 (hex) | counter is a 32 bit number, represented in network byte order. Its | |||

pubInfo is a random string provided by the sender. In CMS, it is provided | initial value is 1 for any ZZ, i.e. the byte sequence 00 00 00 01 | |||

as a parameter in the UserKeyingMaterial field (a 512 bit value represented | (hex), and it is incremented by one every time the above key generation | |||

as an OCTET STRING). | function is run for a given KEK. | |||

pubInfo is a random string provided by the sender. In CMS, it is provided as | ||||

a parameter in the UserKeyingMaterial field (encoded as an OCTET STRING). If | ||||

provided this pubInfo MUST contain 512 bits. | ||||

Note that the only source of secret entropy in this computation is | Note that the only source of secret entropy in this computation is | |||

Rescorla [Page 3]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

ZZ, so the security of this data is limited to the size of ZZ, even | ZZ, so the security of this data is limited to the size of ZZ, even | |||

if more data than ZZ is generated. However, if pubInfo is different | if more data than ZZ is generated. However, if pubInfo is different | |||

for each message, a different KEK will be generated for each message. | for each message, a different KEK will be generated for each message. | |||

Note that pubInfo is required in Static-Static mode, but MAY appear | Note that pubInfo MUST be used in Static-Static mode, but MAY appear | |||

in Ephemeral-Static mode. | in Ephemeral-Static mode. | |||

Rescorla [Page 3]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

2.1.3. KEK Computation | 2.1.3. KEK Computation | |||

Each key encryption algorithm requires a specific size key (n). The | Each key encryption algorithm requires a specific size key (n). The | |||

KEK is generated by mapping the left n-most bytes of KM onto the key. | KEK is generated by mapping the left n-most bytes of KM onto the key. | |||

For 3DES, which requires 192 bits of keying material, the algorithm | For 3DES, which requires 192 bits of keying material, the algorithm | |||

must be run twice, once with a counter value of 1 (to generate K1', | must be run twice, once with a counter value of 1 (to generate K1', | |||

K2', and the first 32 bits of K3') and once with a counter value of 2 | K2', and the first 32 bits of K3') and once with a counter value of 2 | |||

(to generate the last 32 bits of K3). K1',K2' and K3' are then parity | (to generate the last 32 bits of K3). K1',K2' and K3' are then parity | |||

adjusted to generate the 3 DES keys K1,K2 and K3. For RC2, which | adjusted to generate the 3 DES keys K1,K2 and K3. For RC2, which | |||

requires 128 bits of keying material, the algorithm is run once, with | requires 128 bits of keying material, the algorithm is run once, with | |||

skipping to change at line 178 | skipping to change at line 183 | |||

3DES-EDE-ECB 192 bits | 3DES-EDE-ECB 192 bits | |||

RC2 (all) 128 bits | RC2 (all) 128 bits | |||

2.1.5. Public Key Validation | 2.1.5. Public Key Validation | |||

The following algorithm MAY be used to validate received public keys. | The following algorithm MAY be used to validate received public keys. | |||

1. Verify that y lies within the interval [2,p-1]. If it does not, | 1. Verify that y lies within the interval [2,p-1]. If it does not, | |||

the key is invalid. | the key is invalid. | |||

2. Compute y^q (mod p). If the result == 1, the key is valid. | 2. Compute y^q mod p. If the result == 1, the key is valid. | |||

Otherwise the key is invalid. | Otherwise the key is invalid. | |||

The primary purpose of public key validation is to prevent a small | The primary purpose of public key validation is to prevent a small | |||

subgroup attack [LAW98] on the sender's key pair. If Ephemeral-Static | subgroup attack [LAW98] on the sender's key pair. If Ephemeral-Static | |||

mode is used, this check may not be necessary. | mode is used, this check may not be necessary. | |||

Note that this procedure may be subject to pending patents. | Note that this procedure may be subject to pending patents. | |||

2.1.6. Example 1 | 2.1.6. Example 1 | |||

ZZ is the 16 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f | ZZ is the 16 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f | |||

Rescorla [Page 4]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

The key encryption algorithm is 3DES-EDE. | The key encryption algorithm is 3DES-EDE. | |||

No pubInfo is used | No pubInfo is used | |||

Consequently, the input to the first invocation of SHA-1 is: | Consequently, the input to the first invocation of SHA-1 is: | |||

Rescorla [Page 4]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ | 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ | |||

30 13 | 30 12 | |||

30 11 | 30 10 | |||

06 09 2a 86 48 86 f7 0d 03 06 00 ; 3DES-EDE OID | 06 08 2a 86 48 86 f7 0d 03 07 ; 3DES-EDE OID | |||

04 04 00 00 00 01 ; Counter | 04 04 00 00 00 01 ; Counter | |||

And the output is the 20 bytes: | And the output is the 20 bytes: | |||

a8 c6 4e 46 1a aa c2 36 45 c9 2e c6 0e 8a c1 96 8f fb 94 b3 | 20 be 23 e3 3b 72 ef 16 8e e3 ae 18 5a 00 93 b0 d6 49 56 22 | |||

The input to the second invocation of SHA-1 is: | The input to the second invocation of SHA-1 is: | |||

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ | 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ | |||

30 13 | 30 12 | |||

30 11 | 30 10 | |||

06 09 2a 86 48 86 f7 0d 03 06 00 ; 3DES-EDE OID | 06 08 2a 86 48 86 f7 0d 03 07 ; 3DES-EDE OID | |||

04 04 00 00 00 01 ; Counter | 04 04 00 00 00 02 ; Counter | |||

And the output is the 20 bytes: | And the output is the 20 bytes: | |||

49 eb c8 09 27 77 19 c1 a3 0c cc 49 bd 0c 12 5e e0 f9 1a cc | 3b 4e fd d4 6e ff 6b 6d 35 a9 cd e3 e3 e7 05 39 e0 31 53 de | |||

Consequently, | Consequently, | |||

K1'=a8 c6 4e 46 1a aa c2 36 | K1'=20 be 23 e3 3b 72 ef 16 | |||

K2'=45 c9 2e c6 0e 8a c1 96 | K2'=8e e3 ae 18 5a 00 93 b0 | |||

K3'=8f fb 94 b3 49 eb c8 09 | K3'=d6 49 56 22 3b 4e fd d4 | |||

Note: These keys are not parity adjusted | Note: These keys are not parity adjusted | |||

2.1.7. Example 2 | 2.1.7. Example 2 | |||

ZZ is the 16 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f | ZZ is the 16 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f | |||

The key encryption algorithm is RC2 | The key encryption algorithm is RC2 | |||

No pubInfo is used | The pubInfo used is the 64 bytes 01 23 45 67 89 ab cd ef 01 23 45 67 | |||

89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45 | ||||

67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 | ||||

45 67 89 ab cd ef | ||||

Consequently, the input to the first invocation of SHA-1 is: | Consequently, the input to SHA-1 is: | |||

Rescorla [Page 5]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ | 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ | |||

30 56 | 30 56 | |||

30 10 | 30 10 | |||

06 08 2a 86 48 86 f7 0d 03 02 ; RC2 OID | 06 08 2a 86 48 86 f7 0d 03 02 ; RC2 OID | |||

04 04 00 00 00 02 ; Counter | 04 04 00 00 00 01 ; Counter | |||

a2 42 04 40 | a2 42 | |||

04 40 | ||||

01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef ; PubInfo | 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef ; PubInfo | |||

01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef | 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef | |||

01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef | 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef | |||

Rescorla [Page 5]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef | 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef | |||

And the output is the 20 bytes: | And the output is the 20 bytes: | |||

f3 91 81 0b 33 34 3e c5 48 e5 a5 49 51 83 c0 0a 99 7e b4 1e | c7 4e c5 80 68 7d 70 aa 06 38 d3 e3 c7 2a da 5a 67 4e cf 06 | |||

Consequently, | Consequently, | |||

K=f3 91 81 0b 33 34 3e c5 48 e5 a5 49 51 83 c0 0a | K=c7 4e c5 80 68 7d 70 aa 06 38 d3 e3 c7 2a da 5a | |||

2.2. Key and Parameter Requirements | 2.2. Key and Parameter Requirements | |||

X9.42 requires that the group parameters be of the form p=jq + 1 | X9.42 requires that the group parameters be of the form p=jq + 1 | |||

where q is a large prime of length m and j>=2. An algorithm for gen- | where q is a large prime of length m and j>=2. An algorithm for gen- | |||

erating primes of this form can be found in FIPS PUB 186-1[DSS] and | erating primes of this form (derived from the algorithms in FIPS PUB | |||

ANSI, X9.30-1 1996 [X930], as well as in [X942]. | 186-1[DSS], and [X942]can be found in appendix A. | |||

X9.42 requires that the private key x be in the interval [2, (q - | X9.42 requires that the private key x be in the interval [2, (q - | |||

2)]. x should be randomly generated in this interval. y is then com- | 2)]. x should be randomly generated in this interval. y is then com- | |||

puted by calculating g^x (mod p). To comply with this draft, m MUST | puted by calculating g^x mod p. To comply with this draft, m MUST be | |||

be >=128, (consequently, q and x MUST each be at least 128 bits | >=160, (consequently, q and x MUST each be at least 128 bits long). | |||

long). When symmetric ciphers stronger than DES are to be used, a | When symmetric ciphers stronger than DES are to be used, a larger m | |||

larger m may be advisable. | may be advisable. | |||

2.2.1. Group Parameter Generation | 2.2.1. Group Parameter Generation | |||

Agents SHOULD generate domain parameters (g,p,q) using the algorithms | Agents SHOULD generate domain parameters (g,p,q) using the following | |||

specified in Appendixes 2 and 3 of [FIPS-186]. | algorithm, derived from [FIPS-186] and [X942]. When this algorithm is | |||

used, the correctness of the generation procedure can be verified by | ||||

a third party by the algorithm of 2.2.2. | ||||

2.2.1.1. Generation of p, q | ||||

This algorithm generates a p, q pair where q is of length m and | ||||

p is of length L. | ||||

Let L - 1 = n*m + b where both b and n are integers and | ||||

0 <= b < 160. | ||||

Rescorla [Page 6]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

1. Choose an arbitrary sequence of at least m bits and call it SEED. | ||||

Let g be the length of SEED in bits. | ||||

2. Set U = 0 | ||||

3. Set m' = m / 160, where / represents integer division, | ||||

consequently, if m = 200, m' = 1. | ||||

4. for i = 0 to m' - 1 | ||||

U = U + SHA[SEED + i] XOR SHA[(SEED + m' + i) mod 2^160] * 2^(160 * i) | ||||

Note that for m=160, this reduces to the algorithm of [FIPS186] | ||||

U = SHA[SEED] XOR SHA[(SEED+1) mod 2^160 ]. | ||||

5. Form q from U by setting the most significant bit (the 2^(m-1) bit) | ||||

and the least significant bit to 1. In terms of boolean operations, | ||||

q = U OR 2^(m-1) OR 1. Note that 2^(m-1) < q < 2^m | ||||

6. Use a robust primality algorithm to test whether q is prime. | ||||

7. If q is not prime then go to 1. | ||||

8. Let counter = 0 and offset = 2 | ||||

9. For k = 0 to n let | ||||

Vk = SHA[(SEED + offset + k) mod 2^160 ]. | ||||

10. Let W be the integer | ||||

W = V0 + V1*2^160 + ... + Vn-1*2(n-1)*160 + (Vn mod 2^b) | ||||

* 2n*160 | ||||

and let | ||||

X = W + 2^(L-1) | ||||

Note that 0 <= W < 2^(L-1) and hence 2^(L-1) | ||||

11. Let c = X mod (2 * q) and set p = X - (c-1). Note that p is congruent | ||||

to 1 mod (2 * q). | ||||

12. If p < 2^(L -1) then go to step 15. | ||||

13. Perform a robust primality test on p. | ||||

14. If p passes the test performed in step 13 go to step 17. | ||||

Rescorla [Page 7]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

15. Let counter = counter + 1 and offset = offset + n + 1. | ||||

16. If counter >= 4096 go to step 1. Otherwise go to step 9. | ||||

17. Save the value of SEED and the value of counter for use | ||||

in certifying the proper generation of p and q. | ||||

Note: A robust primality test is one where the probability of | ||||

a non-prime number passing the test is at most 2^-80. | ||||

2.2.1.2. Generation of g | ||||

This section gives an algorithm (derived from [FIPS186]) for generat- | ||||

ing g. | ||||

1. Let j = (p - 1)/q. | ||||

2. Set h = any integer, where 1 < h < p - 1 and h differs | ||||

from any value previously tried. | ||||

3. Set g = h^j mod p | ||||

4. If g = 1 go to step 2 | ||||

2.2.2. Group Parameter Validation | 2.2.2. Group Parameter Validation | |||

The ASN.1 for DH keys in [PKIX] includes elements j and validation- | The ASN.1 for DH keys in [PKIX] includes elements j and validation- | |||

Parms which MAY be used by recipients of a key to verify that the | Parms which MAY be used by recipients of a key to verify that the | |||

group parameters were correctly generated. Two checks are possible: | group parameters were correctly generated. Two checks are possible: | |||

1. Verify that p=qj + 1. This demonstrates that the parameters meet | 1. Verify that p=qj + 1. This demonstrates that the parameters meet | |||

the X9.42 parameter criteria. | the X9.42 parameter criteria. | |||

2. Verify that when the p,q generation procedure of [FIPS-186] | 2. Verify that when the p,q generation procedure of [FIPS-186] | |||

Appendix 2 is followed with seed 'seed', that p is found when | Appendix 2 is followed with seed 'seed', that p is found when | |||

This demonstrates that the parameters were randomly chosen and | This demonstrates that the parameters were randomly chosen and | |||

do not have a special form. | do not have a special form. | |||

Whether agents provide validation information in their certificates | Whether agents provide validation information in their certificates | |||

is a local matter between the agents and their CA. | is a local matter between the agents and their CA. | |||

Rescorla [Page 6]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

2.3. Ephemeral-Static Mode | 2.3. Ephemeral-Static Mode | |||

In Ephemeral-Static mode, the recipient has a static (and certified) | In Ephemeral-Static mode, the recipient has a static (and certified) | |||

key pair, but the sender generates a new key pair for each message | key pair, but the sender generates a new key pair for each message | |||

and sends it using the originatorKey production. If the sender's key | and sends it using the originatorKey production. If the sender's key | |||

is freshly generated for each message, the shared secret ZZ will be | is freshly generated for each message, the shared secret ZZ will be | |||

similarly different for each message and pubInfo MAY be omitted, | similarly different for each message and pubInfo MAY be omitted, | |||

since it serves merely to decouple multiple KEKs generated by the | since it serves merely to decouple multiple KEKs generated by the | |||

Rescorla [Page 8]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

same set of pairwise keys. If, however, the same ephemeral sender key | same set of pairwise keys. If, however, the same ephemeral sender key | |||

is used for multiple messages (e.g. it is cached as a performance | is used for multiple messages (e.g. it is cached as a performance | |||

optimization) then a separate pubInfo MUST be used for each message. | optimization) then a separate pubInfo MUST be used for each message. | |||

All implementations of this standard MUST implement Ephemeral-Static | All implementations of this standard MUST implement Ephemeral-Static | |||

mode. | mode. | |||

In order to resist small subgroup attacks, the recipient SHOULD per- | ||||

form the check described in 2.1.5. If the sender cannot determine | ||||

success or failure of decryption, the recipient MAY choose to omit | ||||

this check. | ||||

2.4. Static-Static Mode | ||||

In Static-Static mode, both the sender and the recipient have a | ||||

static (and certified) key pair. Since the sender's and recipient's | ||||

keys are therefore the same for each message, ZZ will be the same for | ||||

each message. Thus, pubInfo MUST be used (and different for each mes- | ||||

sage) in order to ensure that different messages use different KEKs. | ||||

Implementations MAY implement Static-Static mode. | ||||

In order to prevent small subgroup attacks, both originator and reci- | ||||

pient SHOULD either perform the validation step described in S 2.1.5 | ||||

or verify that the CA has properly verified the validity of the key. | ||||

Acknowledgements | Acknowledgements | |||

The Key Agreement method described in this document is based on work | The Key Agreement method described in this document is based on work | |||

done by the ANSI X9F1 working group. The author wishes to extend his | done by the ANSI X9F1 working group. The author wishes to extend his | |||

thanks for their assistance. | thanks for their assistance. | |||

The author also wishes to thank Paul Hoffman, Stephen Henson, Russ | The author also wishes to thank Paul Hoffman, Stephen Henson, Russ | |||

Housley, Brian Korver, Mark Schertler, and Peter Yee for their expert | Housley, Brian Korver, Jim Schaad, Mark Schertler, and Peter Yee for | |||

advice and review. | their expert advice and review. | |||

References | References | |||

[CMS] Housley, R., "Cryptographic Message Syntax", draft-ietf-smime-cms-07.txt. | [CMS] Housley, R., "Cryptographic Message Syntax", draft-ietf-smime-cms-07.txt. | |||

[FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB) | [FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB) | |||

46-1, Data Encryption Standard, Reaffirmed 1988 January 22 | 46-1, Data Encryption Standard, Reaffirmed 1988 January 22 | |||

(supersedes FIPS PUB 46, 1977 January 15). | (supersedes FIPS PUB 46, 1977 January 15). | |||

[FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) | [FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) | |||

81, DES Modes of Operation, 1980 December 2. | 81, DES Modes of Operation, 1980 December 2. | |||

[FIPS-180] Federal Information Processing Standards Publication (FIPS PUB) | [FIPS-180] Federal Information Processing Standards Publication (FIPS PUB) | |||

180-1, "Secure Hash Standard", 1995 April 17. | 180-1, "Secure Hash Standard", 1995 April 17. | |||

[FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) | [FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) | |||

Rescorla [Page 9]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

186, "Digital Signature Standard", 1994 May 19. | 186, "Digital Signature Standard", 1994 May 19. | |||

[PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public | [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public | |||

Key Infrastructure Certificate and CRL Profile", RFC-XXXX. | Key Infrastructure Certificate and CRL Profile", RFC-XXXX. | |||

[LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, | [LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, | |||

"An efficient protocol for authenticated key agreement", | "An efficient protocol for authenticated key agreement", | |||

Technical report CORR 98-05, University of Waterloo, 1998. | Technical report CORR 98-05, University of Waterloo, 1998. | |||

[X942] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms", | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||

Levels." RFC 2119. March 1997. | ||||

Rescorla [Page 7]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

[X942] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms", | ||||

ANSI draft, 1998. | ANSI draft, 1998. | |||

Security Considerations | Security Considerations | |||

All the security in this system is provided by the secrecy of the | All the security in this system is provided by the secrecy of the | |||

private keying material. If either sender or recipient private keys | private keying material. If either sender or recipient private keys | |||

are disclosed, all messages sent or received using that key are | are disclosed, all messages sent or received using that key are | |||

compromised. Similarly, loss of the private key results in an inabil- | compromised. Similarly, loss of the private key results in an inabil- | |||

ity to read messages sent using that key. | ity to read messages sent using that key. | |||

Static Diffie-Hellman keys are vulnerable to a small subgroup attack | Static Diffie-Hellman keys are vulnerable to a small subgroup attack | |||

[LAW98]. In practice, this issue arises for both sides in Static- | [LAW98]. In practice, this issue arises for both sides in Static- | |||

Static mode and for the receiver during Ephemeral-Static mode. In | Static mode and for the receiver during Ephemeral-Static mode. S 2.3 | |||

Static-Static mode, both originator and recipient SHOULD either per- | and 2.4 describe appropriate practices to protect against this | |||

form the validation step described in S 2.1.5 or verify that the CA | attack. | |||

has properly verified the validity of the key. In Ephemeral-Static | ||||

mode, the recipient SHOULD perform the check described in 2.1.5. If | In order to securely generate a symmetric key of length l, m (the | |||

the sender cannot determine success or failure of decryption, the | length in bits of q, and hence x) should be at least 2l. m MUST | |||

recipient MAY choose to omit this check. | always be >= 160. Consequently, for RC2, m should be >=256 and for | |||

3DES, >=336 (the effective length of 3DES keys is 168 bits). | ||||

Author's Address | Author's Address | |||

Eric Rescorla <ekr@rtfm.com> | Eric Rescorla <ekr@rtfm.com> | |||

RTFM Inc. | RTFM Inc. | |||

30 Newell Road, #16 | 30 Newell Road, #16 | |||

East Palo Alto, CA 94303 | East Palo Alto, CA 94303 | |||

Rescorla [Page 8]Internet-Draft Diffie-Hellman Key Agreement Method | Rescorla [Page 10]Internet-Draft Diffie-Hellman Key Agreement Method | |||

Table of Contents | Table of Contents | |||

1. Introduction ................................................... 1 | 1. Introduction ................................................... 1 | |||

1.1. Discussion of this Draft ..................................... 2 | 1.1. Discussion of this Draft ..................................... 2 | |||

1.2. Requirements Terminology ..................................... 2 | 1.2. Requirements Terminology ..................................... 2 | |||

2. Overview Of Method ............................................. 2 | 2. Overview Of Method ............................................. 2 | |||

skipping to change at line 406 | skipping to change at line 522 | |||

2.1.5. Public Key Validation ...................................... 4 | 2.1.5. Public Key Validation ...................................... 4 | |||

2.1.6. Example 1 .................................................. 4 | 2.1.6. Example 1 .................................................. 4 | |||

2.1.7. Example 2 .................................................. 5 | 2.1.7. Example 2 .................................................. 5 | |||

2.2. Key and Parameter Requirements ............................... 6 | 2.2. Key and Parameter Requirements ............................... 6 | |||

2.2.1. Group Parameter Generation ................................. 6 | 2.2.1. Group Parameter Generation ................................. 6 | |||

2.2.2. Group Parameter Validation ................................. 6 | 2.2.1.1. Generation of p, q ....................................... 6 | |||

2.3. Ephemeral-Static Mode ........................................ 7 | 2.2.1.2. Generation of g .......................................... 8 | |||

2.3. Acknowledgements ............................................. 7 | 2.2.2. Group Parameter Validation ................................. 8 | |||

2.3. References ................................................... 7 | 2.3. Ephemeral-Static Mode ........................................ 8 | |||

Security Considerations ........................................... 8 | 2.4. Static-Static Mode ........................................... 9 | |||

Author's Address .................................................. 8 | 2.4. Acknowledgements ............................................. 9 | |||

Rescorla [Page 11]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

2.4. References ................................................... 9 | ||||

Security Considerations ........................................... 10 | ||||

Author's Address .................................................. 10 | ||||

End of changes. | ||||

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |