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

E. Rescorla | E. Rescorla | |||

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

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

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. An algorithm for converting the shared secret into an arbi- | group. Diffie-Hellam is a key agreement algorithm used by two parties | |||

trary amount of keying material is provided. | to agree on a shared secret. An algorithm for converting the shared | |||

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

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

D-H variant described requires the recipient to have a certificate, | ||||

but the originator may have a static key pair (with the 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. | |||

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

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

(MEK) 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 ZZ (which will be constant for any pair of Diffie- | secret number, called ZZ. When the same originator and recipient | |||

Hellman keys). ZZ is then converted into a shared symmetric key. Note | public/private key pairs are used, the same ZZ value will result. | |||

that the symmetric key will be different for each key agreement, due | The ZZ value is then converted into a shared symmetric cryptographic | |||

to the introduction of public random components. | key. When the originator employs a static private/public key pair, | |||

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

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

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

j a large integer such that | ||||

q is a large prime and 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. | |||

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

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] | H is the message digest function SHA-1 [FIPS-180] | |||

ZZ is the shared key computed in Section 2.1.1 | ZZ is the shared key computed in Section 2.1.1 | |||

skipping to change at line 129 | skipping to change at line 139 | |||

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

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

as an OCTET 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, if pubInfo is different | |||

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

message. | Note that pubInfo is required in Static-Static mode, but MAY appear | |||

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

Consequently, for a DES [FIPS-46-1] key, which requires 64 bits of | For 3DES, which requires 192 bits of keying material, the algorithm | |||

keying material, the algorithm is only run once, with a counter value | must be run twice, once with a counter value of 1 (to generate K1', | |||

of 1. The first 64 bits of the output are parity adjusted and con- | K2', and the first 32 bits of K3') and once with a counter value of 2 | |||

verted into a DES key. For 3DES, which requires 192 bits of keying | (to generate the last 32 bits of K3). K1',K2' and K3' are then parity | |||

material, the algorithm must be run twice, once with a counter value | adjusted to generate the 3 DES keys K1,K2 and K3. For RC2, which | |||

of 1 (to generate K1', K2', and the first 32 bits of K3') and once | requires 128 bits of keying material, the algorithm is run once, with | |||

with a counter value of 2 (to generate the last 32 bits of K3). | a counter value of 1, and the left-most 128 bits are directly con- | |||

K1',K2' and K3' are then parity adjusted to generate the 3 DES keys | verted to an RC2 key. | |||

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

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

Static mode is used, this check is unnecessary. Note that this pro- | mode is used, this check may not be necessary. | |||

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

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

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

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 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: | 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 | 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: | The input to the second 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 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: | 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 | 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.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 | ||||

The key encryption algorithm is RC2 | ||||

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

30 10 | ||||

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

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

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

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

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

Consequently, | ||||

K=f3 91 81 0b 33 34 3e c5 48 e5 a5 49 51 83 c0 0a | ||||

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

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

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

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

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

a larger m may be advisable. | larger m 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 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] | |||

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

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

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

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

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

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

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

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. | [LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, | |||

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

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

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

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

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

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

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

Static-Static mode, both originator and recipient SHOULD either per- | ||||

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

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

mode, the recipient SHOULD perform 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. | ||||

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

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 ............................................ 3 | 2.1.3. KEK Computation ............................................ 4 | |||

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

2.2. Key and Parameter Requirements ............................... 5 | 2.1.7. Example 2 .................................................. 5 | |||

2.2.1. Group Parameter Generation ................................. 5 | 2.2. Key and Parameter Requirements ............................... 6 | |||

2.2.2. Group Parameter Validation ................................. 5 | 2.2.1. Group Parameter Generation ................................. 6 | |||

2.3. Ephemeral-Static Mode ........................................ 6 | 2.2.2. Group Parameter Validation ................................. 6 | |||

2.3. Acknowledgements ............................................. 6 | 2.3. Ephemeral-Static Mode ........................................ 7 | |||

2.3. References ................................................... 6 | 2.3. Acknowledgements ............................................. 7 | |||

Security Considerations ........................................... 7 | 2.3. References ................................................... 7 | |||

Author's Address .................................................. 7 | Security Considerations ........................................... 8 | |||

Author's Address .................................................. 8 | ||||

End of changes. | ||||

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