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

E. Rescorla | E. Rescorla | |||

INTERNET-DRAFT Terisa Systems, Inc. | INTERNET-DRAFT RTFM Inc. | |||

<draft-ietf-smime-x942-00.txt> June 1998 (Expires December 1998) | <draft-ietf-smime-x942-01.txt> October 1998 (Expires April 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 31 | skipping to change at line 31 | |||

``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. 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. In addition, a standard | trary amount of keying material is provided. | |||

group that meets the X9.42 requirements is provided. | ||||

TODO | TODO | |||

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

ally generate the group. | ||||

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

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

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

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

skipping to change at line 98 | skipping to change at line 97 | |||

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

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

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

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

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

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

key is identified using the OriginatorIdentifier field, either by | ||||

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

key. | ||||

Senders SHOULD verify the receiver's public key using the procedure | Rescorla [Page 2]Internet-Draft Diffie-Hellman Key Agreement Method | |||

of Section 2.1.5 before generating shared secrets. This check MAY be | ||||

omitted if the CA which certified the key performs this check. Simi- | RecipientIdentifier, which points to the recipient's certificate. | |||

larly, recipient's SHOULD verify the sender's public key before | The sender's key is identified using the OriginatorIdentifierOrKey | |||

decrypting messages. | 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] ZZ is the shared | |||

skipping to change at line 148 | skipping to change at line 141 | |||

this KEK will be used. | this KEK will be used. | |||

counter is a 32 bit number, represented in network byte order. | counter is a 32 bit number, represented in network byte order. | |||

Its initial value is 1, i.e. the byte sequence 00 00 00 01 (hex) | Its initial value is 1, i.e. the byte sequence 00 00 00 01 (hex) | |||

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

as a parameter in the UserKeyingMaterial field (a 512 bit byte string). | as a parameter in the UserKeyingMaterial field (a 512 bit byte string). | |||

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

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, since pubInfo is dif- | if more data than ZZ is generated. However, since pubInfo is dif- | |||

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

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

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

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

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

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

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

2.1.6. Example | 2.1.6. Example | |||

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

No pubInfo is used | ||||

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

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

30 11 | ||||

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

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

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

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

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

30 11 | ||||

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

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

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

Consequently, | ||||

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

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

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

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

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 can be found in FIPS PUB 186-1[DSS] and | |||

ANSI, X9.30-1 1996 [X930], as well as in [X942]. | ANSI, X9.30-1 1996 [X930], as well as in [X942]. | |||

X9.42 requires that the private key x be in the interval [2^(m-1) + | X9.42 requires that the private key x be in the interval [2^(m-1) + | |||

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

1, (q - 2)]. x should be randomly generated in this interval. y is | 1, (q - 2)]. x should be randomly generated in this interval. y is | |||

then computed by calculating g^x (mod p). To comply with this draft, | then computed by calculating g^x (mod p). To comply with this draft, | |||

m MUST be >=128, (consequently, q and x MUST each be at least 128 | m MUST be >=128, (consequently, q and x MUST each be at least 128 | |||

bits long). When symmetric ciphers stronger than DES are to be used, | bits long). When symmetric ciphers stronger than DES are to be used, | |||

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

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

This standard specifies a common IETF DH group that satisfies the | Agents SHOULD generate domain parameters (g,p,q) using the algorithms | |||

above parameters. Standards incorporating this key exchange method | specified in Appendixes 2 and 3 of [FIPS-186]. | |||

may choose to require support of this group. TBD | ||||

2.2.2. Group Parameter 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 | ||||

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

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

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

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

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

have a special form. | ||||

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

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

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

2.3. Ephemeral-Static Mode | ||||

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

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

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

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

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

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

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

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

mode. | ||||

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 Russ Housley, Brian Korver, Mark | The author also wishes to thank Paul Hoffman, Russ Housley, Brian | |||

Schertler, and Peter Yee for their expert advice and review. | Korver, Mark Schertler, and Peter Yee for their expert advice and | |||

review. | ||||

References | References | |||

[CMS] Housley, R., "Cryptographic Message Syntax", draft-ietf-smime-cms-05.txt. | [CMS] Housley, R., "Cryptographic Message Syntax", draft-ietf-smime-cms-05.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) | ||||

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

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

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

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

Rescorla [Page 5]Internet-Draft Diffie-Hellman Key Agreement Method | Eric Rescorla <ekr@rtfm.com> | |||

RTFM Inc. | ||||

Eric Rescorla <ekr@terisa.com> | 30 Newell Road, #16 | |||

Terisa Systems, Inc. | East Palo Alto, CA 94303 | |||

4984 El Camino Real | ||||

Los Altos, CA 94022 | ||||

Phone: (650) 919-1753 | ||||

Rescorla [Page 6]Internet-Draft Diffie-Hellman Key Agreement Method | Rescorla [Page 7]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 ..................................... 1 | |||

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

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

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

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

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

2.1.3. KEK Computation ............................................ 4 | 2.1.3. KEK Computation ............................................ 3 | |||

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

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

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

2.2. Key and Parameter Requirements ............................... 4 | 2.2. Key and Parameter Requirements ............................... 5 | |||

2.2.1. Common Group ............................................... 5 | 2.2.1. Group Parameter Generation ................................. 5 | |||

2.2.1. Acknowledgements ........................................... 5 | 2.2.2. Group Parameter Validation ................................. 5 | |||

2.2.1. References ................................................. 5 | 2.3. Ephemeral-Static Mode ........................................ 6 | |||

Security Considerations ........................................... 5 | 2.3. Acknowledgements ............................................. 6 | |||

Author's Address .................................................. 5 | 2.3. References ................................................... 6 | |||

Security Considerations ........................................... 7 | ||||

Author's Address .................................................. 7 | ||||

End of changes. | ||||

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