draft-ietf-smime-x942-01.txt | draft-ietf-smime-x942-02.txt | |||
---|---|---|---|---|

E. Rescorla | E. Rescorla | |||

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

<draft-ietf-smime-x942-01.txt> October 1998 (Expires April 1999) | <draft-ietf-smime-x942-02.txt> November 1998 (Expires May 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 33 | skipping to change at line 33 | |||

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. An algorithm for converting the shared secret into an arbi- | group. An algorithm for converting the shared secret into an arbi- | |||

trary amount of keying material is provided. | trary amount of keying material is provided. | |||

TODO | ||||

Redo the examples to match the new algorithm for computing K. | ||||

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. | |||

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

This draft is being discussed on the "ietf-smime" mailing list. To | This draft is being discussed on the "ietf-smime" mailing list. To | |||

join the list, send a message to <ietf-smime-request@imc.org> with | join the list, send a message to <ietf-smime-request@imc.org> with | |||

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

the single word "subscribe" in the body of the message. Also, there | the single word "subscribe" in the body of the message. Also, there | |||

is a Web site for the mailing list at <http://www.imc.org/ietf- | is a Web site for the mailing list at <http://www.imc.org/ietf- | |||

smime/>. | smime/>. | |||

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

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

Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and | Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and | |||

"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 key (a message encryp- | key encryption key (KEK) to encrypt (wrap) a message encrytion key | |||

tion key -- MEK) which is in turn used to encrypt the message data. | (MEK) 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 ZZ (which will be constant for any pair of Diffie- | secret number ZZ (which will be constant for any pair of Diffie- | |||

Hellman keys). ZZ is then converted into a shared symmetric key. Note | Hellman keys). ZZ is then converted into a shared symmetric key. Note | |||

that the symmetric key will be different for each key agreement, due | that the symmetric key will be different for each key agreement, due | |||

to the introduction of public random components. | to the introduction of public random components. | |||

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

skipping to change at line 100 | skipping to change at line 95 | |||

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 | |||

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 is a generator for the integer group specified by p. | |||

(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 | In CMS, the recipient's key is identified by the CMS RecipientIden- | |||

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

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

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

key. | ||||

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

RecipientIdentifier, which points to the recipient's certificate. | ||||

The sender's key is identified using the OriginatorIdentifierOrKey | ||||

field, either by reference to the sender's certificate or by inline | ||||

inclusion of a 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. | |||

KM = H ( ZZ || OtherInfo) | KM = H ( ZZ || OtherInfo) | |||

H is the message digest function SHA-1 [FIPS-180] ZZ is the shared | H is the message digest function SHA-1 [FIPS-180] | |||

key computed in Section 2.1.1 OtherInfo is the DER encoding of the | ZZ is the shared key computed in Section 2.1.1 | |||

following structure: | OtherInfo is the DER encoding of the following structure: | |||

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) } | |||

skipping to change at line 151 | skipping to change at line 145 | |||

message. | message. | |||

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. | |||

Consequently, for a DES [FIPS-46-1] key, which requires 64 bits of | Consequently, for a DES [FIPS-46-1] key, which requires 64 bits of | |||

keying material, the algorithm is only run once, with a counter value | keying material, the algorithm is only run once, with a counter value | |||

of 1. The first 64 bits of the output are parity adjusted and con- | of 1. The first 64 bits of the output are parity adjusted and con- | |||

verted into a DES key. For 3DES, which requires 192 bits of keying | verted into a DES key. For 3DES, which requires 192 bits of keying | |||

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

material, the algorithm must be run twice, once with a counter value | material, the algorithm must be run twice, once with a counter value | |||

of 1 (to generate K1', K2', and the first 32 bits of K3') and once | of 1 (to generate K1', K2', and the first 32 bits of K3') and once | |||

with a counter value of 2 (to generate the last 32 bits of K3). | with a counter value of 2 (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' are then parity adjusted to generate the 3 DES keys | |||

K1,K2 and K3. | K1,K2 and K3. | |||

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

2.1.4. Keylengths for common algorithms | 2.1.4. Keylengths for common algorithms | |||

Some common key encryption algorithms have KEKs of the following | Some common key encryption algorithms have KEKs of the following | |||

lengths. | lengths. | |||

DES-ECB 64 bits | DES-ECB 64 bits | |||

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 [REFERENCE?] on the sender's key pair. If Ephemeral- | subgroup attack [SUBGROUP] on the sender's key pair. If Ephemeral- | |||

Static mode is used, this check is unnecessary. Note that this pro- | Static mode is used, this check is unnecessary. Note that this pro- | |||

cedure may be subject to pending patents. | cedure may be subject to pending patents. | |||

2.1.6. Example | 2.1.6. Example | |||

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 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: 00 01 02 | Consequently, the input to the first invocation of SHA-1 is: | |||

03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ 30 13 | ||||

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

30 13 | ||||

30 11 | 30 11 | |||

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

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

And the output is the 20 bytes: a8 c6 4e 46 1a aa c2 36 45 c9 2e c6 | And the output is the 20 bytes: | |||

0e 8a c1 96 8f fb 94 b3 | ||||

a8 c6 4e 46 1a aa c2 36 45 c9 2e c6 0e 8a c1 96 8f fb 94 b3 | ||||

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

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

The input to the second invocation of SHA-1 is: 00 01 02 03 04 05 06 | 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ | |||

07 08 09 0a 0b 0c 0d 0e 0f ; ZZ 30 13 | 30 13 | |||

30 11 | 30 11 | |||

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

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

And the output is the 20 bytes: 49 eb c8 09 27 77 19 c1 a3 0c cc 49 | And the output is the 20 bytes: | |||

bd 0c 12 5e e0 f9 1a cc | ||||

49 eb c8 09 27 77 19 c1 a3 0c cc 49 bd 0c 12 5e e0 f9 1a cc | ||||

Consequently, | Consequently, | |||

K1=a8 c6 4e 46 1a aa c2 36 | K1=a8 c6 4e 46 1a aa c2 36 | |||

K2=45 c9 2e c6 0e 8a c1 96 | K2=45 c9 2e c6 0e 8a c1 96 | |||

K3=8f fb 94 b3 49 eb c8 09 | K3=8f fb 94 b3 49 eb c8 09 | |||

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

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

skipping to change at line 243 | skipping to change at line 242 | |||

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

specified in Appendixes 2 and 3 of [FIPS-186]. | specified in Appendixes 2 and 3 of [FIPS-186]. | |||

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: | |||

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

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] Appendix 2 | 2. Verify that when the p,q generation procedure of [FIPS-186] Appendix 2 | |||

is followed with seed 'seed', that p is found when 'counter' = pgenCounter. | is followed with seed 'seed', that p is found when 'counter' = pgenCounter. | |||

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

have a special form. | have a special form. | |||

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

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. | |||

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, | |||

skipping to change at line 292 | skipping to change at line 291 | |||

[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. | |||

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

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

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. | |||

[SUBGROUP] I still need a reference for the Small Subgroup attack. | ||||

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

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

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

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. | |||

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

End of changes. | ||||

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