]>
Commit | Line | Data |
---|---|---|
ff8a0c21 MW |
1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group H. Orman | |
8 | Request for Comments: 2412 Department of Computer Science | |
9 | Category: Informational University of Arizona | |
10 | November 1998 | |
11 | ||
12 | ||
13 | The OAKLEY Key Determination Protocol | |
14 | ||
15 | Status of this Memo | |
16 | ||
17 | This memo provides information for the Internet community. It does | |
18 | not specify an Internet standard of any kind. Distribution of this | |
19 | memo is unlimited. | |
20 | ||
21 | Copyright Notice | |
22 | ||
23 | Copyright (C) The Internet Society (1998). All Rights Reserved. | |
24 | ||
25 | Abstract | |
26 | ||
27 | This document describes a protocol, named OAKLEY, by which two | |
28 | authenticated parties can agree on secure and secret keying material. | |
29 | The basic mechanism is the Diffie-Hellman key exchange algorithm. | |
30 | ||
31 | The OAKLEY protocol supports Perfect Forward Secrecy, compatibility | |
32 | with the ISAKMP protocol for managing security associations, user- | |
33 | defined abstract group structures for use with the Diffie-Hellman | |
34 | algorithm, key updates, and incorporation of keys distributed via | |
35 | out-of-band mechanisms. | |
36 | ||
37 | 1. INTRODUCTION | |
38 | ||
39 | Key establishment is the heart of data protection that relies on | |
40 | cryptography, and it is an essential component of the packet | |
41 | protection mechanisms described in [RFC2401], for example. A | |
42 | scalable and secure key distribution mechanism for the Internet is a | |
43 | necessity. The goal of this protocol is to provide that mechanism, | |
44 | coupled with a great deal of cryptographic strength. | |
45 | ||
46 | The Diffie-Hellman key exchange algorithm provides such a mechanism. | |
47 | It allows two parties to agree on a shared value without requiring | |
48 | encryption. The shared value is immediately available for use in | |
49 | encrypting subsequent conversation, e.g. data transmission and/or | |
50 | authentication. The STS protocol [STS] provides a demonstration of | |
51 | how to embed the algorithm in a secure protocol, one that ensures | |
52 | that in addition to securely sharing a secret, the two parties can be | |
53 | sure of each other's identities, even when an active attacker exists. | |
54 | ||
55 | ||
56 | ||
57 | ||
58 | Orman Informational [Page 1] | |
59 | \f | |
60 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
61 | ||
62 | ||
63 | Because OAKLEY is a generic key exchange protocol, and because the | |
64 | keys that it generates might be used for encrypting data with a long | |
65 | privacy lifetime, 20 years or more, it is important that the | |
66 | algorithms underlying the protocol be able to ensure the security of | |
67 | the keys for that period of time, based on the best prediction | |
68 | capabilities available for seeing into the mathematical future. The | |
69 | protocol therefore has two options for adding to the difficulties | |
70 | faced by an attacker who has a large amount of recorded key exchange | |
71 | traffic at his disposal (a passive attacker). These options are | |
72 | useful for deriving keys which will be used for encryption. | |
73 | ||
74 | The OAKLEY protocol is related to STS, sharing the similarity of | |
75 | authenticating the Diffie-Hellman exponentials and using them for | |
76 | determining a shared key, and also of achieving Perfect Forward | |
77 | Secrecy for the shared key, but it differs from the STS protocol in | |
78 | several ways. | |
79 | ||
80 | The first is the addition of a weak address validation mechanism | |
81 | ("cookies", described by Phil Karn in the Photuris key exchange | |
82 | protocol work in progress) to help avoid denial of service | |
83 | attacks. | |
84 | ||
85 | The second extension is to allow the two parties to select | |
86 | mutually agreeable supporting algorithms for the protocol: the | |
87 | encryption method, the key derivation method, and the | |
88 | authentication method. | |
89 | ||
90 | Thirdly, the authentication does not depend on encryption using | |
91 | the Diffie-Hellman exponentials; instead, the authentication | |
92 | validates the binding of the exponentials to the identities of the | |
93 | parties. | |
94 | ||
95 | The protocol does not require the two parties compute the shared | |
96 | exponentials prior to authentication. | |
97 | ||
98 | This protocol adds additional security to the derivation of keys | |
99 | meant for use with encryption (as opposed to authentication) by | |
100 | including a dependence on an additional algorithm. The derivation | |
101 | of keys for encryption is made to depend not only on the Diffie- | |
102 | Hellman algorithm, but also on the cryptographic method used to | |
103 | securely authenticate the communicating parties to each other. | |
104 | ||
105 | Finally, this protocol explicitly defines how the two parties can | |
106 | select the mathematical structures (group representation and | |
107 | operation) for performing the Diffie-Hellman algorithm; they can | |
108 | use standard groups or define their own. User-defined groups | |
109 | provide an additional degree of long-term security. | |
110 | ||
111 | ||
112 | ||
113 | ||
114 | Orman Informational [Page 2] | |
115 | \f | |
116 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
117 | ||
118 | ||
119 | OAKLEY has several options for distributing keys. In addition to the | |
120 | classic Diffie-Hellman exchange, this protocol can be used to derive | |
121 | a new key from an existing key and to distribute an externally | |
122 | derived key by encrypting it. | |
123 | ||
124 | The protocol allows two parties to use all or some of the anti- | |
125 | clogging and perfect forward secrecy features. It also permits the | |
126 | use of authentication based on symmetric encryption or non-encryption | |
127 | algorithms. This flexibility is included in order to allow the | |
128 | parties to use the features that are best suited to their security | |
129 | and performance requirements. | |
130 | ||
131 | This document draws extensively in spirit and approach from the | |
132 | Photuris work in progress by Karn and Simpson (and from discussions | |
133 | with the authors), specifics of the ISAKMP document by Schertler et | |
134 | al. the ISAKMP protocol document, and it was also influenced by | |
135 | papers by Paul van Oorschot and Hugo Krawcyzk. | |
136 | ||
137 | 2. The Protocol Outline | |
138 | ||
139 | 2.1 General Remarks | |
140 | ||
141 | The OAKLEY protocol is used to establish a shared key with an | |
142 | assigned identifier and associated authenticated identities for the | |
143 | two parties. The name of the key can be used later to derive | |
144 | security associations for the RFC 2402 and RFC 2406 protocols (AH and | |
145 | ESP) or to achieve other network security goals. | |
146 | ||
147 | Each key is associated with algorithms that are used for | |
148 | authentication, privacy, and one-way functions. These are ancillary | |
149 | algorithms for OAKLEY; their appearance in subsequent security | |
150 | association definitions derived with other protocols is neither | |
151 | required nor prohibited. | |
152 | ||
153 | The specification of the details of how to apply an algorithm to data | |
154 | is called a transform. This document does not supply the transform | |
155 | definitions; they will be in separate RFC's. | |
156 | ||
157 | The anti-clogging tokens, or "cookies", provide a weak form of source | |
158 | address identification for both parties; the cookie exchange can be | |
159 | completed before they perform the computationally expensive part of | |
160 | the protocol (large integer exponentiations). | |
161 | ||
162 | It is important to note that OAKLEY uses the cookies for two | |
163 | purposes: anti-clogging and key naming. The two parties to the | |
164 | protocol each contribute one cookie at the initiation of key | |
165 | establishment; the pair of cookies becomes the key identifier | |
166 | (KEYID), a reusable name for the keying material. Because of this | |
167 | ||
168 | ||
169 | ||
170 | Orman Informational [Page 3] | |
171 | \f | |
172 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
173 | ||
174 | ||
175 | dual role, we will use the notation for the concatenation of the | |
176 | cookies ("COOKIE-I, COOKIE-R") interchangeably with the symbol | |
177 | "KEYID". | |
178 | ||
179 | OAKLEY is designed to be a compatible component of the ISAKMP | |
180 | protocol [ISAKMP], which runs over the UDP protocol using a well- | |
181 | known port (see the RFC on port assignments, STD02-RFC-1700). The | |
182 | only technical requirement for the protocol environment is that the | |
183 | underlying protocol stack must be able to supply the Internet address | |
184 | of the remote party for each message. Thus, OAKLEY could, in theory, | |
185 | be used directly over the IP protocol or over UDP, if suitable | |
186 | protocol or port number assignments were available. | |
187 | ||
188 | The machine running OAKLEY must provide a good random number | |
189 | generator, as described in [RANDOM], as the source of random numbers | |
190 | required in this protocol description. Any mention of a "nonce" | |
191 | implies that the nonce value is generated by such a generator. The | |
192 | same is true for "pseudorandom" values. | |
193 | ||
194 | 2.2 Notation | |
195 | ||
196 | The section describes the notation used in this document for message | |
197 | sequences and content. | |
198 | ||
199 | 2.2.1 Message descriptions | |
200 | ||
201 | The protocol exchanges below are written in an abbreviated notation | |
202 | that is intended to convey the essential elements of the exchange in | |
203 | a clear manner. A brief guide to the notation follows. The detailed | |
204 | formats and assigned values are given in the appendices. | |
205 | ||
206 | In order to represent message exchanges succinctly, this document | |
207 | uses an abbreviated notation that describes each message in terms of | |
208 | its source and destination and relevant fields. | |
209 | ||
210 | Arrows ("->") indicate whether the message is sent from the initiator | |
211 | to the responder, or vice versa ("<-"). | |
212 | ||
213 | The fields in the message are named and comma separated. The | |
214 | protocol uses the convention that the first several fields constitute | |
215 | a fixed header format for all messages. | |
216 | ||
217 | For example, consider a HYPOTHETICAL exchange of messages involving a | |
218 | fixed format message, the four fixed fields being two "cookies", the | |
219 | third field being a message type name, the fourth field being a | |
220 | multi-precision integer representing a power of a number: | |
221 | ||
222 | ||
223 | ||
224 | ||
225 | ||
226 | Orman Informational [Page 4] | |
227 | \f | |
228 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
229 | ||
230 | ||
231 | Initiator Responder | |
232 | -> Cookie-I, 0, OK_KEYX, g^x -> | |
233 | <- Cookie-R, Cookie-I, OK_KEYX, g^y <- | |
234 | ||
235 | The notation describes a two message sequence. The initiator begins | |
236 | by sending a message with 4 fields to the responder; the first field | |
237 | has the unspecified value "Cookie-I", second field has the numeric | |
238 | value 0, the third field indicates the message type is OK_KEYX, the | |
239 | fourth value is an abstract group element g to the x'th power. | |
240 | ||
241 | The second line indicates that the responder replies with value | |
242 | "Cookie-R" in the first field, a copy of the "Cookie-I" value in the | |
243 | second field, message type OK_KEYX, and the number g raised to the | |
244 | y'th power. | |
245 | ||
246 | The value OK_KEYX is in capitals to indicate that it is a unique | |
247 | constant (constants are defined in the appendices). | |
248 | ||
249 | Variable precision integers with length zero are null values for the | |
250 | protocol. | |
251 | ||
252 | Sometimes the protocol will indicate that an entire payload (usually | |
253 | the Key Exchange Payload) has null values. The payload is still | |
254 | present in the message, for the purpose of simplifying parsing. | |
255 | ||
256 | 2.2.2 Guide to symbols | |
257 | ||
258 | Cookie-I and Cookie-R (or CKY-I and CKY-R) are 64-bit pseudo-random | |
259 | numbers. The generation method must ensure with high probability | |
260 | that the numbers used for each IP remote address are unique over some | |
261 | time period, such as one hour. | |
262 | ||
263 | KEYID is the concatenation of the initiator and responder cookies and | |
264 | the domain of interpretation; it is the name of keying material. | |
265 | ||
266 | sKEYID is used to denote the keying material named by the KEYID. It | |
267 | is never transmitted, but it is used in various calculations | |
268 | performed by the two parties. | |
269 | ||
270 | OK_KEYX and OK_NEWGRP are distinct message types. | |
271 | ||
272 | IDP is a bit indicating whether or not material after the encryption | |
273 | boundary (see appendix B), is encrypted. NIDP means not encrypted. | |
274 | ||
275 | g^x and g^y are encodings of group elements, where g is a special | |
276 | group element indicated in the group description (see Appendix A) and | |
277 | g^x indicates that element raised to the x'th power. The type of the | |
278 | encoding is either a variable precision integer or a pair of such | |
279 | ||
280 | ||
281 | ||
282 | Orman Informational [Page 5] | |
283 | \f | |
284 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
285 | ||
286 | ||
287 | integers, as indicated in the group operation in the group | |
288 | description. Note that we will write g^xy as a short-hand for | |
289 | g^(xy). See Appendix F for references that describe implementing | |
290 | large integer computations and the relationship between various group | |
291 | definitions and basic arithmetic operations. | |
292 | ||
293 | EHAO is a list of encryption/hash/authentication choices. Each item | |
294 | is a pair of values: a class name and an algorithm name. | |
295 | ||
296 | EHAS is a set of three items selected from the EHAO list, one from | |
297 | each of the classes for encryption, hash, authentication. | |
298 | ||
299 | GRP is a name (32-bit value) for the group and its relevant | |
300 | parameters: the size of the integers, the arithmetic operation, and | |
301 | the generator element. There are a few pre-defined GRP's (for 768 | |
302 | bit modular exponentiation groups, 1024 bit modexp, 2048 bit modexp, | |
303 | 155-bit and 210-bit elliptic curves, see Appendix E), but | |
304 | participants can share other group descriptions in a later protocol | |
305 | stage (see the section NEW GROUP). It is important to separate | |
306 | notion of the GRP from the group descriptor (Appendix A); the former | |
307 | is a name for the latter. | |
308 | ||
309 | The symbol vertical bar "|" is used to denote concatenation of bit | |
310 | strings. Fields are concatenated using their encoded form as they | |
311 | appear in their payload. | |
312 | ||
313 | Ni and Nr are nonces selected by the initiator and responder, | |
314 | respectively. | |
315 | ||
316 | ID(I) and ID(R) are the identities to be used in authenticating the | |
317 | initiator and responder respectively. | |
318 | ||
319 | E{x}Ki indicates the encryption of x using the public key of the | |
320 | initiator. Encryption is done using the algorithm associated with | |
321 | the authentication method; usually this will be RSA. | |
322 | ||
323 | S{x}Ki indicates the signature over x using the private key (signing | |
324 | key) of the initiator. Signing is done using the algorithm | |
325 | associated with the authentication method; usually this will be RSA | |
326 | or DSS. | |
327 | ||
328 | prf(a, b) denotes the result of applying pseudo-random function "a" | |
329 | to data "b". One may think of "a" as a key or as a value that | |
330 | characterizes the function prf; in the latter case it is the index | |
331 | into a family of functions. Each function in the family provides a | |
332 | "hash" or one-way mixing of the input. | |
333 | ||
334 | prf(0, b) denotes the application of a one-way function to data "b". | |
335 | ||
336 | ||
337 | ||
338 | Orman Informational [Page 6] | |
339 | \f | |
340 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
341 | ||
342 | ||
343 | The similarity with the previous notation is deliberate and indicates | |
344 | that a single algorithm, e.g. MD5, might will used for both purposes. | |
345 | In the first case a "keyed" MD5 transform would be used with key "a"; | |
346 | in the second case the transform would have the fixed key value zero, | |
347 | resulting in a one-way function. | |
348 | ||
349 | The term "transform" is used to refer to functions defined in | |
350 | auxiliary RFC's. The transform RFC's will be drawn from those | |
351 | defined for IPSEC AH and ESP (see RFC 2401 for the overall | |
352 | architecture encompassing these protocols). | |
353 | ||
354 | 2.3 The Key Exchange Message Overview | |
355 | ||
356 | The goal of key exchange processing is the secure establishment of | |
357 | common keying information state in the two parties. This state | |
358 | information is a key name, secret keying material, the identification | |
359 | of the two parties, and three algorithms for use during | |
360 | authentication: encryption (for privacy of the identities of the two | |
361 | parties), hashing (a pseudorandom function for protecting the | |
362 | integrity of the messages and for authenticating message fields), and | |
363 | authentication (the algorithm on which the mutual authentication of | |
364 | the two parties is based). The encodings and meanings for these | |
365 | choices are presented in Appendix B. | |
366 | ||
367 | The main mode exchange has five optional features: stateless cookie | |
368 | exchange, perfect forward secrecy for the keying material, secrecy | |
369 | for the identities, perfect forward secrecy for identity secrecy, use | |
370 | of signatures (for non-repudiation). The two parties can use any | |
371 | combination of these features. | |
372 | ||
373 | The general outline of processing is that the Initiator of the | |
374 | exchange begins by specifying as much information as he wishes in his | |
375 | first message. The Responder replies, supplying as much information | |
376 | as he wishes. The two sides exchange messages, supplying more | |
377 | information each time, until their requirements are satisfied. | |
378 | ||
379 | The choice of how much information to include in each message depends | |
380 | on which options are desirable. For example, if stateless cookies | |
381 | are not a requirement, and identity secrecy and perfect forward | |
382 | secrecy for the keying material are not requirements, and if non- | |
383 | repudiatable signatures are acceptable, then the exchange can be | |
384 | completed in three messages. | |
385 | ||
386 | Additional features may increase the number of roundtrips needed for | |
387 | the keying material determination. | |
388 | ||
389 | ISAKMP provides fields for specifying the security association | |
390 | parameters for use with the AH and ESP protocols. These security | |
391 | ||
392 | ||
393 | ||
394 | Orman Informational [Page 7] | |
395 | \f | |
396 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
397 | ||
398 | ||
399 | association payload types are specified in the ISAKMP memo; the | |
400 | payload types can be protected with OAKLEY keying material and | |
401 | algorithms, but this document does not discuss their use. | |
402 | ||
403 | 2.3.1 The Essential Key Exchange Message Fields | |
404 | ||
405 | There are 12 fields in an OAKLEY key exchange message. Not all the | |
406 | fields are relevant in every message; if a field is not relevant it | |
407 | can have a null value or not be present (no payload). | |
408 | ||
409 | CKY-I originator cookie. | |
410 | CKY-R responder cookie. | |
411 | MSGTYPE for key exchange, will be ISA_KE&AUTH_REQ or | |
412 | ISA_KE&AUTH_REP; for new group definitions, | |
413 | will be ISA_NEW_GROUP_REQ or ISA_NEW_GROUP_REP | |
414 | GRP the name of the Diffie-Hellman group used for | |
415 | the exchange | |
416 | g^x (or g^y) variable length integer representing a power of | |
417 | group generator | |
418 | EHAO or EHAS encryption, hash, authentication functions, | |
419 | offered and selectedj, respectively | |
420 | IDP an indicator as to whether or not encryption with | |
421 | g^xy follows (perfect forward secrecy for ID's) | |
422 | ID(I) the identity for the Initiator | |
423 | ID(R) the identity for the Responder | |
424 | Ni nonce supplied by the Initiator | |
425 | Nr nonce supplied by the Responder | |
426 | ||
427 | The construction of the cookies is implementation dependent. Phil | |
428 | Karn has recommended making them the result of a one-way function | |
429 | applied to a secret value (changed periodically), the local and | |
430 | remote IP address, and the local and remote UDP port. In this way, | |
431 | the cookies remain stateless and expire periodically. Note that with | |
432 | OAKLEY, this would cause the KEYID's derived from the secret value to | |
433 | also expire, necessitating the removal of any state information | |
434 | associated with it. | |
435 | ||
436 | In order to support pre-distributed keys, we recommend that | |
437 | implementations reserve some portion of their cookie space to | |
438 | permanent keys. The encoding of these depends only on the local | |
439 | implementation. | |
440 | ||
441 | The encryption functions used with OAKLEY must be cryptographic | |
442 | transforms which guarantee privacy and integrity for the message | |
443 | data. Merely using DES in CBC mode is not permissible. The | |
444 | MANDATORY and OPTIONAL transforms will include any that satisfy this | |
445 | criteria and are defined for use with RFC 2406 (ESP). | |
446 | ||
447 | ||
448 | ||
449 | ||
450 | Orman Informational [Page 8] | |
451 | \f | |
452 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
453 | ||
454 | ||
455 | The one-way (hash) functions used with OAKLEY must be cryptographic | |
456 | transforms which can be used as either keyed hash (pseudo-random) or | |
457 | non-keyed transforms. The MANDATORY and OPTIONAL transforms will | |
458 | include any that are defined for use with RFC 2406 (AH). | |
459 | ||
460 | Where nonces are indicated, they will be variable precision integers | |
461 | with an entropy value that matches the "strength" attribute of the | |
462 | GRP used with the exchange. If no GRP is indicated, the nonces must | |
463 | be at least 90 bits long. The pseudo-random generator for the nonce | |
464 | material should start with initial data that has at least 90 bits of | |
465 | entropy; see RFC 1750. | |
466 | ||
467 | 2.3.1.1 Exponent Advice | |
468 | ||
469 | Ideally, the exponents will have at least 180 bits of entropy for | |
470 | every key exchange. This ensures complete independence of keying | |
471 | material between two exchanges (note that this applies if only one of | |
472 | the parties chooses a random exponent). In practice, implementors | |
473 | may wish to base several key exchanges on a single base value with | |
474 | 180 bits of entropy and use one-way hash functions to guarantee that | |
475 | exposure of one key will not compromise others. In this case, a good | |
476 | recommendation is to keep the base values for nonces and cookies | |
477 | separate from the base value for exponents, and to replace the base | |
478 | value with a full 180 bits of entropy as frequently as possible. | |
479 | ||
480 | The values 0 and p-1 should not be used as exponent values; | |
481 | implementors should be sure to check for these values, and they | |
482 | should also refuse to accept the values 1 and p-1 from remote parties | |
483 | (where p is the prime used to define a modular exponentiation group). | |
484 | ||
485 | 2.3.2 Mapping to ISAKMP Message Structures | |
486 | ||
487 | All the OAKLEY message fields correspond to ISAKMP message payloads | |
488 | or payload components. The relevant payload fields are the SA | |
489 | payload, the AUTH payload, the Certificate Payload, the Key Exchange | |
490 | Payload. The ISAKMP protocol framwork is a work in progress at this | |
491 | time, and the exact mapping of Oakley message fields to ISAKMP | |
492 | payloads is also in progress (to be known as the Resolution | |
493 | document). | |
494 | ||
495 | Some of the ISAKMP header and payload fields will have constant | |
496 | values when used with OAKLEY. The exact values to be used will be | |
497 | published in a Domain of Interpretation document accompanying the | |
498 | Resolution document. | |
499 | ||
500 | In the following we indicate where each OAKLEY field appears in the | |
501 | ISAKMP message structure. These are recommended only; the Resolution | |
502 | document will be the final authority on this mapping. | |
503 | ||
504 | ||
505 | ||
506 | Orman Informational [Page 9] | |
507 | \f | |
508 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
509 | ||
510 | ||
511 | CKY-I ISAKMP header | |
512 | CKY-R ISAKMP header | |
513 | MSGTYPE Message Type in ISAKMP header | |
514 | GRP SA payload, Proposal section | |
515 | g^x (or g^y) Key Exchange Payload, encoded as a variable | |
516 | precision integer | |
517 | EHAO and EHAS SA payload, Proposal section | |
518 | IDP A bit in the RESERVED field in the AUTH header | |
519 | ID(I) AUTH payload, Identity field | |
520 | ID(R) AUTH payload, Identity field | |
521 | Ni AUTH payload, Nonce Field | |
522 | Nr AUTH payload, Nonce Field | |
523 | S{...}Kx AUTH payload, Data Field | |
524 | prf{K,...} AUTH payload, Data Field | |
525 | ||
526 | 2.4 The Key Exchange Protocol | |
527 | ||
528 | The exact number and content of messages exchanged during an OAKLEY | |
529 | key exchange depends on which options the Initiator and Responder | |
530 | want to use. A key exchange can be completed with three or more | |
531 | messages, depending on those options. | |
532 | ||
533 | The three components of the key determination protocol are the | |
534 | ||
535 | 1. cookie exchange (optionally stateless) | |
536 | 2. Diffie-Hellman half-key exchange (optional, but essential for | |
537 | perfect forward secrecy) | |
538 | 3. authentication (options: privacy for ID's, privacy for ID's | |
539 | with PFS, non-repudiatable) | |
540 | ||
541 | The initiator can supply as little information as a bare exchange | |
542 | request, carrying no additional information. On the other hand the | |
543 | initiator can begin by supplying all of the information necessary for | |
544 | the responder to authenticate the request and complete the key | |
545 | determination quickly, if the responder chooses to accept this | |
546 | method. If not, the responder can reply with a minimal amount of | |
547 | information (at the minimum, a cookie). | |
548 | ||
549 | The method of authentication can be digital signatures, public key | |
550 | encryption, or an out-of-band symmetric key. The three different | |
551 | methods lead to slight variations in the messages, and the variations | |
552 | are illustrated by examples in this section. | |
553 | ||
554 | The Initiator is responsible for retransmitting messages if the | |
555 | protocol does not terminate in a timely fashion. The Responder must | |
556 | therefore avoid discarding reply information until it is acknowledged | |
557 | by Initiator in the course of continuing the protocol. | |
558 | ||
559 | ||
560 | ||
561 | ||
562 | Orman Informational [Page 10] | |
563 | \f | |
564 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
565 | ||
566 | ||
567 | The remainder of this section contains examples demonstrating how to | |
568 | use OAKLEY options. | |
569 | ||
570 | 2.4.1 An Aggressive Example | |
571 | ||
572 | The following example indicates how two parties can complete a key | |
573 | exchange in three messages. The identities are not secret, the | |
574 | derived keying material is protected by PFS. | |
575 | ||
576 | By using digital signatures, the two parties will have a proof of | |
577 | communication that can be recorded and presented later to a third | |
578 | party. | |
579 | ||
580 | The keying material implied by the group exponentials is not needed | |
581 | for completing the exchange. If it is desirable to defer the | |
582 | computation, the implementation can save the "x" and "g^y" values and | |
583 | mark the keying material as "uncomputed". It can be computed from | |
584 | this information later. | |
585 | ||
586 | Initiator Responder | |
587 | --------- --------- | |
588 | -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> | |
589 | ID(I), ID(R), Ni, 0, | |
590 | S{ID(I) | ID(R) | Ni | 0 | GRP | g^x | 0 | EHAO}Ki | |
591 | <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, | |
592 | ID(R), ID(I), Nr, Ni, | |
593 | S{ID(R) | ID(I) | Nr | Ni | GRP | g^y | g^x | EHAS}Kr <- | |
594 | -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP, -> | |
595 | ID(I), ID(R), Ni, Nr, | |
596 | S{ID(I) | ID(R) | Ni | Nr | GRP | g^x | g^y | EHAS}Ki | |
597 | ||
598 | NB "NIDP" means that the PFS option for hiding identities is not used. | |
599 | i.e., the identities are not encrypted using a key based on g^xy | |
600 | ||
601 | NB Fields are shown separated by commas in this document; they are | |
602 | concatenated in the actual protocol messages using their encoded | |
603 | forms as specified in the ISAKMP/Oakley Resolution document. | |
604 | ||
605 | The result of this exchange is a key with KEYID = CKY-I|CKY-R and | |
606 | value | |
607 | ||
608 | sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R). | |
609 | ||
610 | The processing outline for this exchange is as follows: | |
611 | ||
612 | ||
613 | ||
614 | ||
615 | ||
616 | ||
617 | ||
618 | Orman Informational [Page 11] | |
619 | \f | |
620 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
621 | ||
622 | ||
623 | Initiation | |
624 | ||
625 | The Initiator generates a unique cookie and associates it with the | |
626 | expected IP address of the responder, and its chosen state | |
627 | information: GRP (the group identifier), a pseudo-randomly | |
628 | selected exponent x, g^x, EHAO list, nonce, identities. The first | |
629 | authentication choice in the EHAO list is an algorithm that | |
630 | supports digital signatures, and this is used to sign the ID's and | |
631 | the nonce and group id. The Initiator further | |
632 | ||
633 | notes that the key is in the initial state of "unauthenticated", | |
634 | and | |
635 | ||
636 | sets a timer for possible retransmission and/or termination of the | |
637 | request. | |
638 | ||
639 | When the Responder receives the message, he may choose to ignore all | |
640 | the information and treat it as merely a request for a cookie, | |
641 | creating no state. If CKY-I is not already in use by the source | |
642 | address in the IP header, the responder generates a unique cookie, | |
643 | CKY-R. The next steps depend on the Responder's preferences. The | |
644 | minimal required response is to reply with the first cookie field set | |
645 | to zero and CKY-R in the second field. For this example we will | |
646 | assume that the responder is more aggressive (for the alternatives, | |
647 | see section 6) and accepts the following: | |
648 | ||
649 | group with identifier GRP, | |
650 | first authentication choice (which must be the digital signature | |
651 | method used to sign the Initiator message), | |
652 | lack of perfect forward secrecy for protecting the identities, | |
653 | identity ID(I) and identity ID(R) | |
654 | ||
655 | In this example the Responder decides to accept all the information | |
656 | offered by the initiator. It validates the signature over the signed | |
657 | portion of the message, and associate the pair (CKY-I, CKY-R) with | |
658 | the following state information: | |
659 | ||
660 | the source and destination network addresses of the message | |
661 | ||
662 | key state of "unauthenticated" | |
663 | ||
664 | the first algorithm from the authentication offer | |
665 | ||
666 | group GRP, a "y" exponent value in group GRP, and g^x from the | |
667 | message | |
668 | ||
669 | the nonce Ni and a pseudorandomly selected value Nr | |
670 | ||
671 | ||
672 | ||
673 | ||
674 | Orman Informational [Page 12] | |
675 | \f | |
676 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
677 | ||
678 | ||
679 | a timer for possible destruction of the state. | |
680 | ||
681 | The Responder computes g^y, forms the reply message, and then signs | |
682 | the ID and nonce information with the private key of ID(R) and sends | |
683 | it to the Initiator. In all exchanges, each party should make sure | |
684 | that he neither offers nor accepts 1 or g^(p-1) as an exponential. | |
685 | ||
686 | In this example, to expedite the protocol, the Responder implicitly | |
687 | accepts the first algorithm in the Authentication class of the EHAO | |
688 | list. This because he cannot validate the Initiator signature | |
689 | without accepting the algorithm for doing the signature. The | |
690 | Responder's EHAS list will also reflect his acceptance. | |
691 | ||
692 | The Initiator receives the reply message and | |
693 | validates that CKY-I is a valid association for the network | |
694 | address of the incoming message, | |
695 | ||
696 | adds the CKY-R value to the state for the pair (CKY-I, network | |
697 | address), and associates all state information with the pair | |
698 | (CKY-I, CKY-R), | |
699 | ||
700 | validates the signature of the responder over the state | |
701 | information (should validation fail, the message is discarded) | |
702 | ||
703 | adds g^y to its state information, | |
704 | ||
705 | saves the EHA selections in the state, | |
706 | ||
707 | optionally computes (g^y)^x (= g^xy) (this can be deferred until | |
708 | after sending the reply message), | |
709 | ||
710 | sends the reply message, signed with the public key of ID(I), | |
711 | ||
712 | marks the KEYID (CKY-I|CKY-R) as authenticated, | |
713 | ||
714 | and composes the reply message and signature. | |
715 | ||
716 | When the Responder receives the Initiator message, and if the | |
717 | signature is valid, it marks the key as being in the authenticated | |
718 | state. It should compute g^xy and associate it with the KEYID. | |
719 | ||
720 | Note that although PFS for identity protection is not used, PFS for | |
721 | the derived keying material is still present because the Diffie- | |
722 | Hellman half-keys g^x and g^y are exchanged. | |
723 | ||
724 | Even if the Responder only accepts some of the Initiator information, | |
725 | the Initiator will consider the protocol to be progressing. The | |
726 | Initiator should assume that fields that were not accepted by the | |
727 | ||
728 | ||
729 | ||
730 | Orman Informational [Page 13] | |
731 | \f | |
732 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
733 | ||
734 | ||
735 | Responder were not recorded by the Responder. | |
736 | ||
737 | If the Responder does not accept the aggressive exchange and selects | |
738 | another algorithm for the A function, then the protocol will not | |
739 | continue using the signature algorithm or the signature value from | |
740 | the first message. | |
741 | ||
742 | 2.4.1.1 Fields Not Present | |
743 | ||
744 | If the Responder does not accept all the fields offered by the | |
745 | Initiator, he should include null values for those fields in his | |
746 | response. Section 6 has guidelines on how to select fields in a | |
747 | "left-to-right" manner. If a field is not accepted, then it and all | |
748 | following fields must have null values. | |
749 | ||
750 | The Responder should not record any information that it does not | |
751 | accept. If the ID's and nonces have null values, there will not be a | |
752 | signature over these null values. | |
753 | ||
754 | 2.4.1.2 Signature via Pseudo-Random Functions | |
755 | ||
756 | The aggressive example is written to suggest that public key | |
757 | technology is used for the signatures. However, a pseudorandom | |
758 | function can be used, if the parties have previously agreed to such a | |
759 | scheme and have a shared key. | |
760 | ||
761 | If the first proposal in the EHAO list is an "existing key" method, | |
762 | then the KEYID named in that proposal will supply the keying material | |
763 | for the "signature" which is computed using the "H" algorithm | |
764 | associated with the KEYID. | |
765 | ||
766 | Suppose the first proposal in EHAO is | |
767 | EXISTING-KEY, 32 | |
768 | and the "H" algorithm for KEYID 32 is MD5-HMAC, by prior negotiation. | |
769 | The keying material is some string of bits, call it sK32. Then in | |
770 | the first message in the aggressive exchange, where the signature | |
771 | ||
772 | S{ID(I), ID(R), Ni, 0, GRP, g^x, EHAO}Ki | |
773 | ||
774 | is indicated, the signature computation would be performed by | |
775 | MD5-HMAC_func(KEY=sK32, DATA = ID(I) | ID(R) | Ni | 0 | GRP | g^x | |
776 | | g^y | EHAO) (The exact definition of the algorithm corresponding | |
777 | to "MD5-HMAC- func" will appear in the RFC defining that transform). | |
778 | ||
779 | The result of this computation appears in the Authentication payload. | |
780 | ||
781 | ||
782 | ||
783 | ||
784 | ||
785 | ||
786 | Orman Informational [Page 14] | |
787 | \f | |
788 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
789 | ||
790 | ||
791 | 2.4.2 An Aggressive Example With Hidden Identities | |
792 | ||
793 | The following example indicates how two parties can complete a key | |
794 | exchange without using digital signatures. Public key cryptography | |
795 | hides the identities during authentication. The group exponentials | |
796 | are exchanged and authenticated, but the implied keying material | |
797 | (g^xy) is not needed during the exchange. | |
798 | ||
799 | This exchange has an important difference from the previous signature | |
800 | scheme --- in the first message, an identity for the responder is | |
801 | indicated as cleartext: ID(R'). However, the identity hidden with | |
802 | the public key cryptography is different: ID(R). This happens | |
803 | because the Initiator must somehow tell the Responder which | |
804 | public/private key pair to use for the decryption, but at the same | |
805 | time, the identity is hidden by encryption with that public key. | |
806 | ||
807 | The Initiator might elect to forgo secrecy of the Responder identity, | |
808 | but this is undesirable. Instead, if there is a well-known identity | |
809 | for the Responder node, the public key for that identity can be used | |
810 | to encrypt the actual Responder identity. | |
811 | ||
812 | Initiator Responder | |
813 | --------- --------- | |
814 | -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> | |
815 | ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr' | |
816 | <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, | |
817 | E{ID(R), ID(I), Nr}Ki, | |
818 | prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS) <- | |
819 | -> CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP, | |
820 | prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS) -> | |
821 | ||
822 | Kir = prf(0, Ni | Nr) | |
823 | ||
824 | NB "NIDP" means that the PFS option for hiding identities is not used. | |
825 | ||
826 | NB The ID(R') value is included in the Authentication payload as | |
827 | described in Appendix B. | |
828 | ||
829 | The result of this exchange is a key with KEYID = CKY-I|CKY-R and | |
830 | value sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R). | |
831 | ||
832 | The processing outline for this exchange is as follows: | |
833 | ||
834 | Initiation | |
835 | The Initiator generates a unique cookie and associates it with the | |
836 | expected IP address of the responder, and its chosen state | |
837 | information: GRP, g^x, EHAO list. The first authentication choice | |
838 | in the EHAO list is an algorithm that supports public key | |
839 | ||
840 | ||
841 | ||
842 | Orman Informational [Page 15] | |
843 | \f | |
844 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
845 | ||
846 | ||
847 | encryption. The Initiator also names the two identities to be | |
848 | used for the connection and enters these into the state. A well- | |
849 | known identity for the responder machine is also chosen, and the | |
850 | public key for this identity is used to encrypt the nonce Ni and | |
851 | the two connection identities. The Initiator further | |
852 | ||
853 | notes that the key is in the initial state of "unauthenticated", | |
854 | and | |
855 | ||
856 | sets a timer for possible retransmission and/or termination of the | |
857 | request. | |
858 | ||
859 | When the Responder receives the message, he may choose to ignore all | |
860 | the information and treat it as merely a request for a cookie, | |
861 | creating no state. | |
862 | ||
863 | If CKY-I is not already in use by the source address in the IP | |
864 | header, the Responder generates a unique cookie, CKY-R. As before, | |
865 | the next steps depend on the responder's preferences. The minimal | |
866 | required response is a message with the first cookie field set to | |
867 | zero and CKY-R in the second field. For this example we will assume | |
868 | that responder is more aggressive and accepts the following: | |
869 | ||
870 | group GRP, first authentication choice (which must be the public | |
871 | key encryption algorithm used to encrypt the payload), lack of | |
872 | perfect forward secrecy for protecting the identities, identity | |
873 | ID(I), identity ID(R) | |
874 | ||
875 | The Responder must decrypt the ID and nonce information, using the | |
876 | private key for the R' ID. After this, the private key for the R ID | |
877 | will be used to decrypt the nonce field. | |
878 | ||
879 | The Responder now associates the pair (CKY-I, CKY-R) with the | |
880 | following state information: | |
881 | ||
882 | the source and destination network addresses of the message | |
883 | ||
884 | key state of "unauthenticated" | |
885 | ||
886 | the first algorithm from each class in the EHAO (encryption-hash- | |
887 | authentication algorithm offers) list | |
888 | ||
889 | group GRP and a y and g^y value in group GRP | |
890 | ||
891 | the nonce Ni and a pseudorandomly selected value Nr | |
892 | ||
893 | a timer for possible destruction of the state. | |
894 | ||
895 | ||
896 | ||
897 | ||
898 | Orman Informational [Page 16] | |
899 | \f | |
900 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
901 | ||
902 | ||
903 | The Responder then encrypts the state information with the public key | |
904 | of ID(I), forms the prf value, and sends it to the Initiator. | |
905 | ||
906 | The Initiator receives the reply message and | |
907 | validates that CKY-I is a valid association for the network | |
908 | address of the incoming message, | |
909 | ||
910 | adds the CKY-R value to the state for the pair (CKY-I, network | |
911 | address), and associates all state information with the pair | |
912 | (CKY-I, CKY-R), | |
913 | ||
914 | decrypts the ID and nonce information | |
915 | ||
916 | checks the prf calculation (should this fail, the message is | |
917 | discarded) | |
918 | ||
919 | adds g^y to its state information, | |
920 | ||
921 | saves the EHA selections in the state, | |
922 | ||
923 | optionally computes (g^x)^y (= g^xy) (this may be deferred), and | |
924 | ||
925 | sends the reply message, encrypted with the public key of ID(R), | |
926 | ||
927 | and marks the KEYID (CKY-I|CKY-R) as authenticated. | |
928 | ||
929 | When the Responder receives this message, it marks the key as being | |
930 | in the authenticated state. If it has not already done so, it should | |
931 | compute g^xy and associate it with the KEYID. | |
932 | ||
933 | The secret keying material sKEYID = prf(Ni | Nr, g^xy | CKY-I | | |
934 | CKY-R) | |
935 | ||
936 | Note that although PFS for identity protection is not used, PFS for | |
937 | the derived keying material is still present because the Diffie- | |
938 | Hellman half-keys g^x and g^y are exchanged. | |
939 | ||
940 | 2.4.3 An Aggressive Example With Private Identities and Without Diffie- | |
941 | Hellman | |
942 | ||
943 | Considerable computational expense can be avoided if perfect forward | |
944 | secrecy is not a requirement for the session key derivation. The two | |
945 | parties can exchange nonces and secret key parts to achieve the | |
946 | authentication and derive keying material. The long-term privacy of | |
947 | data protected with derived keying material is dependent on the | |
948 | private keys of each of the parties. | |
949 | ||
950 | ||
951 | ||
952 | ||
953 | ||
954 | Orman Informational [Page 17] | |
955 | \f | |
956 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
957 | ||
958 | ||
959 | In this exchange, the GRP has the value 0 and the field for the group | |
960 | exponential is used to hold a nonce value instead. | |
961 | ||
962 | As in the previous section, the first proposed algorithm must be a | |
963 | public key encryption system; by responding with a cookie and a non- | |
964 | zero exponential field, the Responder implicitly accepts the first | |
965 | proposal and the lack of perfect forward secrecy for the identities | |
966 | and derived keying material. | |
967 | ||
968 | Initiator Responder | |
969 | --------- --------- | |
970 | -> CKY-I, 0, OK_KEYX, 0, 0, EHAO, NIDP, -> | |
971 | ID(R'), E{ID(I), ID(R), sKi}Kr', Ni | |
972 | <- CKY-R, CKY-I, OK_KEYX, 0, 0, EHAS, NIDP, | |
973 | E{ID(R), ID(I), sKr}Ki, Nr, | |
974 | prf(Kir, ID(R) | ID(I) | Nr | Ni | EHAS) <- | |
975 | -> CKY-I, CKY-R, OK_KEYX, EHAS, NIDP, | |
976 | prf(Kir, ID(I) | ID(R) | Ni | Nr | EHAS) -> | |
977 | ||
978 | Kir = prf(0, sKi | sKr) | |
979 | ||
980 | NB The sKi and sKr values go into the nonce fields. The change in | |
981 | notation is meant to emphasize that their entropy is critical to | |
982 | setting the keying material. | |
983 | ||
984 | NB "NIDP" means that the PFS option for hiding identities is not | |
985 | used. | |
986 | ||
987 | The result of this exchange is a key with KEYID = CKY-I|CKY-R and | |
988 | value sKEYID = prf(Kir, CKY-I | CKY-R). | |
989 | ||
990 | 2.4.3 A Conservative Example | |
991 | ||
992 | In this example the two parties are minimally aggressive; they use | |
993 | the cookie exchange to delay creation of state, and they use perfect | |
994 | forward secrecy to protect the identities. For this example, they | |
995 | use public key encryption for authentication; digital signatures or | |
996 | pre-shared keys can also be used, as illustrated previously. The | |
997 | conservative example here does not change the use of nonces, prf's, | |
998 | etc., but it does change how much information is transmitted in each | |
999 | message. | |
1000 | ||
1001 | The responder considers the ability of the initiator to repeat CKY-R | |
1002 | as weak evidence that the message originates from a "live" | |
1003 | correspondent on the network and the correspondent is associated with | |
1004 | the initiator's network address. The initiator makes similar | |
1005 | assumptions when CKY-I is repeated to the initiator. | |
1006 | ||
1007 | ||
1008 | ||
1009 | ||
1010 | Orman Informational [Page 18] | |
1011 | \f | |
1012 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1013 | ||
1014 | ||
1015 | All messages must have either valid cookies or at least one zero | |
1016 | cookie. If both cookies are zero, this indicates a request for a | |
1017 | cookie; if only the initiator cookie is zero, it is a response to a | |
1018 | cookie request. | |
1019 | ||
1020 | Information in messages violating the cookie rules cannot be used for | |
1021 | any OAKLEY operations. | |
1022 | ||
1023 | Note that the Initiator and Responder must agree on one set of EHA | |
1024 | algorithms; there is not one set for the Responder and one for the | |
1025 | Initiator. The Initiator must include at least MD5 and DES in the | |
1026 | initial offer. | |
1027 | ||
1028 | Fields not indicated have null values. | |
1029 | ||
1030 | Initiator Responder | |
1031 | --------- --------- | |
1032 | -> 0, 0, OK_KEYX -> | |
1033 | <- 0, CKY-R, OK_KEYX <- | |
1034 | -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO -> | |
1035 | <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS <- | |
1036 | -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, IDP*, | |
1037 | ID(I), ID(R), E{Ni}Kr, -> | |
1038 | <- CKY-R, CKY-I, OK_KEYX, GRP, 0 , 0, IDP, <- | |
1039 | E{Nr, Ni}Ki, ID(R), ID(I), | |
1040 | prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS ) | |
1041 | -> CKY-I, CKY-R, OK_KEYX, GRP, 0 , 0, IDP, | |
1042 | prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS ) -> | |
1043 | ||
1044 | Kir = prf(0, Ni | Nr) | |
1045 | ||
1046 | * when IDP is in effect, authentication payloads are encrypted with | |
1047 | the selected encryption algorithm using the keying material prf(0, | |
1048 | g^xy). (The transform defining the encryption algorithm will | |
1049 | define how to select key bits from the keying material.) This | |
1050 | encryption is in addition to and after any public key encryption. | |
1051 | See Appendix B. | |
1052 | ||
1053 | Note that in the first messages, several fields are omitted from | |
1054 | the description. These fields are present as null values. | |
1055 | ||
1056 | The first exchange allows the Responder to use stateless cookies; if | |
1057 | the responder generates cookies in a manner that allows him to | |
1058 | validate them without saving them, as in Photuris, then this is | |
1059 | possible. Even if the Initiator includes a cookie in his initial | |
1060 | request, the responder can still use stateless cookies by merely | |
1061 | omitting the CKY-I from his reply and by declining to record the | |
1062 | Initiator cookie until it appears in a later message. | |
1063 | ||
1064 | ||
1065 | ||
1066 | Orman Informational [Page 19] | |
1067 | \f | |
1068 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1069 | ||
1070 | ||
1071 | After the exchange is complete, both parties compute the shared key | |
1072 | material sKEYID as prf(Ni | Nr, g^xy | CKY-I | CKY-R) where "prf" is | |
1073 | the pseudo-random function in class "hash" selected in the EHA list. | |
1074 | ||
1075 | As with the cookies, each party considers the ability of the remote | |
1076 | side to repeat the Ni or Nr value as a proof that Ka, the public key | |
1077 | of party a, speaks for the remote party and establishes its identity. | |
1078 | ||
1079 | In analyzing this exchange, it is important to note that although the | |
1080 | IDP option ensures that the identities are protected with an | |
1081 | ephemeral key g^xy, the authentication itself does not depend on | |
1082 | g^xy. It is essential that the authentication steps validate the g^x | |
1083 | and g^y values, and it is thus imperative that the authentication not | |
1084 | involve a circular dependency on them. A third party could intervene | |
1085 | with a "man-in-middle" scheme to convince the initiator and responder | |
1086 | to use different g^xy values; although such an attack might result in | |
1087 | revealing the identities to the eavesdropper, the authentication | |
1088 | would fail. | |
1089 | ||
1090 | 2.4.4 Extra Strength for Protection of Encryption Keys | |
1091 | ||
1092 | The nonces Ni and Nr are used to provide an extra dimension of | |
1093 | secrecy in deriving session keys. This makes the secrecy of the key | |
1094 | depend on two different problems: the discrete logarithm problem in | |
1095 | the group G, and the problem of breaking the nonce encryption scheme. | |
1096 | If RSA encryption is used, then this second problem is roughly | |
1097 | equivalent to factoring the RSA public keys of both the initiator and | |
1098 | responder. | |
1099 | ||
1100 | For authentication, the key type, the validation method, and the | |
1101 | certification requirement must be indicated. | |
1102 | ||
1103 | 2.5 Identity and Authentication | |
1104 | ||
1105 | 2.5.1 Identity | |
1106 | ||
1107 | In OAKLEY exchanges the Initiator offers Initiator and Responder ID's | |
1108 | -- the former is the claimed identity for the Initiator, and the | |
1109 | latter is the requested ID for the Responder. | |
1110 | ||
1111 | If neither ID is specified, the ID's are taken from the IP header | |
1112 | source and destination addresses. | |
1113 | ||
1114 | If the Initiator doesn't supply a responder ID, the Responder can | |
1115 | reply by naming any identity that the local policy allows. The | |
1116 | Initiator can refuse acceptance by terminating the exchange. | |
1117 | ||
1118 | ||
1119 | ||
1120 | ||
1121 | ||
1122 | Orman Informational [Page 20] | |
1123 | \f | |
1124 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1125 | ||
1126 | ||
1127 | The Responder can also reply with a different ID than the Initiator | |
1128 | suggested; the Initiator can accept this implicitly by continuing the | |
1129 | exchange or refuse it by terminating (not replying). | |
1130 | ||
1131 | 2.5.2 Authentication | |
1132 | ||
1133 | The authentication of principals to one another is at the heart of | |
1134 | any key exchange scheme. The Internet community must decide on a | |
1135 | scalable standard for solving this problem, and OAKLEY must make use | |
1136 | of that standard. At the time of this writing, there is no such | |
1137 | standard, though several are emerging. This document attempts to | |
1138 | describe how a handful of standards could be incorporated into | |
1139 | OAKLEY, without attempting to pick and choose among them. | |
1140 | ||
1141 | The following methods can appear in OAKLEY offers: | |
1142 | ||
1143 | a. Pre-shared Keys | |
1144 | When two parties have arranged for a trusted method of | |
1145 | distributing secret keys for their mutual authentication, they can | |
1146 | be used for authentication. This has obvious scaling problems for | |
1147 | large systems, but it is an acceptable interim solution for some | |
1148 | situations. Support for pre-shared keys is REQUIRED. | |
1149 | ||
1150 | The encryption, hash, and authentication algorithm for use with a | |
1151 | pre-shared key must be part of the state information distributed | |
1152 | with the key itself. | |
1153 | ||
1154 | The pre-shared keys have a KEYID and keying material sKEYID; the | |
1155 | KEYID is used in a pre-shared key authentication option offer. | |
1156 | There can be more than one pre-shared key offer in a list. | |
1157 | ||
1158 | Because the KEYID persists over different invocations of OAKLEY | |
1159 | (after a crash, etc.), it must occupy a reserved part of the KEYID | |
1160 | space for the two parties. A few bits can be set aside in each | |
1161 | party's "cookie space" to accommodate this. | |
1162 | ||
1163 | There is no certification authority for pre-shared keys. When a | |
1164 | pre-shared key is used to generate an authentication payload, the | |
1165 | certification authority is "None", the Authentication Type is | |
1166 | "Preshared", and the payload contains | |
1167 | ||
1168 | the KEYID, encoded as two 64-bit quantities, and the result of | |
1169 | applying the pseudorandom hash function to the message body | |
1170 | with the sKEYID forming the key for the function | |
1171 | ||
1172 | ||
1173 | ||
1174 | ||
1175 | ||
1176 | ||
1177 | ||
1178 | Orman Informational [Page 21] | |
1179 | \f | |
1180 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1181 | ||
1182 | ||
1183 | b. DNS public keys | |
1184 | Security extensions to the DNS protocol [DNSSEC] provide a | |
1185 | convenient way to access public key information, especially for | |
1186 | public keys associated with hosts. RSA keys are a requirement for | |
1187 | secure DNS implementations; extensions to allow optional DSS keys | |
1188 | are a near-term possibility. | |
1189 | ||
1190 | DNS KEY records have associated SIG records that are signed by a | |
1191 | zone authority, and a hierarchy of signatures back to the root | |
1192 | server establishes a foundation for trust. The SIG records | |
1193 | indicate the algorithm used for forming the signature. | |
1194 | ||
1195 | OAKLEY implementations must support the use of DNS KEY and SIG | |
1196 | records for authenticating with respect to IPv4 and IPv6 addresses | |
1197 | and fully qualified domain names. However, implementations are | |
1198 | not required to support any particular algorithm (RSA, DSS, etc.). | |
1199 | ||
1200 | c. RSA public keys w/o certification authority signature PGP | |
1201 | [Zimmerman] uses public keys with an informal method for | |
1202 | establishing trust. The format of PGP public keys and naming | |
1203 | methods will be described in a separate RFC. The RSA algorithm | |
1204 | can be used with PGP keys for either signing or encryption; the | |
1205 | authentication option should indicate either RSA-SIG or RSA-ENC, | |
1206 | respectively. Support for this is OPTIONAL. | |
1207 | ||
1208 | d.1 RSA public keys w/ certificates There are various formats and | |
1209 | naming conventions for public keys that are signed by one or more | |
1210 | certification authorities. The Public Key Interchange Protocol | |
1211 | discusses X.509 encodings and validation. Support for this is | |
1212 | OPTIONAL. | |
1213 | ||
1214 | d.2 DSS keys w/ certificates Encoding for the Digital Signature | |
1215 | Standard with X.509 is described in draft-ietf-ipsec-dss-cert- | |
1216 | 00.txt. Support for this is OPTIONAL; an ISAKMP Authentication | |
1217 | Type will be assigned. | |
1218 | ||
1219 | 2.5.3 Validating Authentication Keys | |
1220 | ||
1221 | The combination of the Authentication algorithm, the Authentication | |
1222 | Authority, the Authentication Type, and a key (usually public) define | |
1223 | how to validate the messages with respect to the claimed identity. | |
1224 | The key information will be available either from a pre-shared key, | |
1225 | or from some kind of certification authority. | |
1226 | ||
1227 | Generally the certification authority produces a certificate binding | |
1228 | the entity name to a public key. OAKLEY implementations must be | |
1229 | prepared to fetch and validate certificates before using the public | |
1230 | key for OAKLEY authentication purposes. | |
1231 | ||
1232 | ||
1233 | ||
1234 | Orman Informational [Page 22] | |
1235 | \f | |
1236 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1237 | ||
1238 | ||
1239 | The ISAKMP Authentication Payload defines the Authentication | |
1240 | Authority field for specifying the authority that must be apparent in | |
1241 | the trust hierarchy for authentication. | |
1242 | ||
1243 | Once an appropriate certificate is obtained (see 2.4.3), the | |
1244 | validation method will depend on the Authentication Type; if it is | |
1245 | PGP then the PGP signature validation routines can be called to | |
1246 | satisfy the local web-of-trust predicates; if it is RSA with X.509 | |
1247 | certificates, the certificate must be examined to see if the | |
1248 | certification authority signature can be validated, and if the | |
1249 | hierarchy is recognized by the local policy. | |
1250 | ||
1251 | 2.5.4 Fetching Identity Objects | |
1252 | ||
1253 | In addition to interpreting the certificate or other data structure | |
1254 | that contains an identity, users of OAKLEY must face the task of | |
1255 | retrieving certificates that bind a public key to an identifier and | |
1256 | also retrieving auxiliary certificates for certifying authorities or | |
1257 | co-signers (as in the PGP web of trust). | |
1258 | ||
1259 | The ISAKMP Credentials Payload can be used to attach useful | |
1260 | certificates to OAKLEY messages. The Credentials Payload is defined | |
1261 | in Appendix B. | |
1262 | ||
1263 | Support for accessing and revoking public key certificates via the | |
1264 | Secure DNS protocol [SECDNS] is MANDATORY for OAKLEY implementations. | |
1265 | Other retrieval methods can be used when the AUTH class indicates a | |
1266 | preference. | |
1267 | ||
1268 | The Public Key Interchange Protocol discusses a full protocol that | |
1269 | might be used with X.509 encoded certificates. | |
1270 | ||
1271 | 2.6 Interface to Cryptographic Transforms | |
1272 | ||
1273 | The keying material computed by the key exchange should have at least | |
1274 | 90 bits of entropy, which means that it must be at least 90 bits in | |
1275 | length. This may be more or less than is required for keying the | |
1276 | encryption and/or pseudorandom function transforms. | |
1277 | ||
1278 | The transforms used with OAKLEY should have auxiliary algorithms | |
1279 | which take a variable precision integer and turn it into keying | |
1280 | material of the appropriate length. For example, a DES algorithm | |
1281 | could take the low order 56 bits, a triple DES algorithm might use | |
1282 | the following: | |
1283 | ||
1284 | K1 = low 56 bits of md5(0|sKEYID) | |
1285 | K2 = low 56 bits of md5(1|sKEYID) | |
1286 | K3 = low 56 bits of md5(2|sKEYID) | |
1287 | ||
1288 | ||
1289 | ||
1290 | Orman Informational [Page 23] | |
1291 | \f | |
1292 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1293 | ||
1294 | ||
1295 | The transforms will be called with the keying material encoded as a | |
1296 | variable precision integer, the length of the data, and the block of | |
1297 | memory with the data. Conversion of the keying material to a | |
1298 | transform key is the responsibility of the transform. | |
1299 | ||
1300 | 2.7 Retransmission, Timeouts, and Error Messages | |
1301 | ||
1302 | If a response from the Responder is not elicited in an appropriate | |
1303 | amount of time, the message should be retransmitted by the Initiator. | |
1304 | These retransmissions must be handled gracefully by both parties; the | |
1305 | Responder must retain information for retransmitting until the | |
1306 | Initiator moves to the next message in the protocol or completes the | |
1307 | exchange. | |
1308 | ||
1309 | Informational error messages present a problem because they cannot be | |
1310 | authenticated using only the information present in an incomplete | |
1311 | exchange; for this reason, the parties may wish to establish a | |
1312 | default key for OAKLEY error messages. A possible method for | |
1313 | establishing such a key is described in Appendix B, under the use of | |
1314 | ISA_INIT message types. | |
1315 | ||
1316 | In the following the message type is OAKLEY Error, the KEYID supplies | |
1317 | the H algorithm and key for authenticating the message contents; this | |
1318 | value is carried in the Sig/Prf payload. | |
1319 | ||
1320 | The Error payload contains the error code and the contents of the | |
1321 | rejected message. | |
1322 | ||
1323 | ||
1324 | ||
1325 | ||
1326 | ||
1327 | ||
1328 | ||
1329 | ||
1330 | ||
1331 | ||
1332 | ||
1333 | ||
1334 | ||
1335 | ||
1336 | ||
1337 | ||
1338 | ||
1339 | ||
1340 | ||
1341 | ||
1342 | ||
1343 | ||
1344 | ||
1345 | ||
1346 | Orman Informational [Page 24] | |
1347 | \f | |
1348 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1349 | ||
1350 | ||
1351 | 1 2 3 | |
1352 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
1353 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
1354 | ! ! | |
1355 | ~ Initiator-Cookie ~ | |
1356 | / ! ! | |
1357 | KEYID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
1358 | \ ! ! | |
1359 | ~ Responder-Cookie ~ | |
1360 | ! ! | |
1361 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
1362 | ! Domain of Interpretation ! | |
1363 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
1364 | ! Message Type ! Exch ! Vers ! Length ! | |
1365 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
1366 | ! SPI (unused) ! | |
1367 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
1368 | ! SPI (unused) ! | |
1369 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
1370 | ! Error Payload ! | |
1371 | ~ ~ | |
1372 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
1373 | ! Sig/prf Payload | |
1374 | ~ ~ | |
1375 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
1376 | ||
1377 | The error message will contain the cookies as presented in the | |
1378 | offending message, the message type OAKLEY_ERROR, and the reason for | |
1379 | the error, followed by the rejected message. | |
1380 | ||
1381 | Error messages are informational only, and the correctness of the | |
1382 | protocol does not depend on them. | |
1383 | ||
1384 | Error reasons: | |
1385 | ||
1386 | TIMEOUT exchange has taken too long, state destroyed | |
1387 | AEH_ERROR an unknown algorithm appears in an offer | |
1388 | GROUP_NOT_SUPPORTED GRP named is not supported | |
1389 | EXPONENTIAL_UNACCEPTABLE exponential too large/small or is +-1 | |
1390 | SELECTION_NOT_OFFERED selection does not occur in offer | |
1391 | NO_ACCEPTABLE_OFFERS no offer meets host requirements | |
1392 | AUTHENTICATION_FAILURE signature or hash function fails | |
1393 | RESOURCE_EXCEEDED too many exchanges or too much state info | |
1394 | NO_EXCHANGE_IN_PROGRESS a reply received with no request in progress | |
1395 | ||
1396 | ||
1397 | ||
1398 | ||
1399 | ||
1400 | ||
1401 | ||
1402 | Orman Informational [Page 25] | |
1403 | \f | |
1404 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1405 | ||
1406 | ||
1407 | 2.8 Additional Security for Privacy Keys: Private Groups | |
1408 | ||
1409 | If the two parties have need to use a Diffie-Hellman key | |
1410 | determination scheme that does not depend on the standard group | |
1411 | definitions, they have the option of establishing a private group. | |
1412 | The authentication need not be repeated, because this stage of the | |
1413 | protocol will be protected by a pre-existing authentication key. As | |
1414 | an extra security measure, the two parties will establish a private | |
1415 | name for the shared keying material, so even if they use exactly the | |
1416 | same group to communicate with other parties, the re-use will not be | |
1417 | apparent to passive attackers. | |
1418 | ||
1419 | Private groups have the advantage of making a widespread passive | |
1420 | attack much harder by increasing the number of groups that would have | |
1421 | to be exhaustively analyzed in order to recover a large number of | |
1422 | session keys. This contrasts with the case when only one or two | |
1423 | groups are ever used; in that case, one would expect that years and | |
1424 | years of session keys would be compromised. | |
1425 | ||
1426 | There are two technical challenges to face: how can a particular user | |
1427 | create a unique and appropriate group, and how can a second party | |
1428 | assure himself that the proposed group is reasonably secure? | |
1429 | ||
1430 | The security of a modular exponentiation group depends on the largest | |
1431 | prime factor of the group size. In order to maximize this, one can | |
1432 | choose "strong" or Sophie Germaine primes, P = 2Q + 1, where P and Q | |
1433 | are prime. However, if P = kQ + 1, where k is small, then the | |
1434 | strength of the group is still considerable. These groups are known | |
1435 | as Schnorr subgroups, and they can be found with much less | |
1436 | computational effort than Sophie-Germaine primes. | |
1437 | ||
1438 | Schnorr subgroups can also be validated efficiently by using probable | |
1439 | prime tests. | |
1440 | ||
1441 | It is also fairly easy to find P, k, and Q such that the largest | |
1442 | prime factor can be easily proven to be Q. | |
1443 | ||
1444 | We estimate that it would take about 10 minutes to find a new group | |
1445 | of about 2^1024 elements, and this could be done once a day by a | |
1446 | scheduled process; validating a group proposed by a remote party | |
1447 | would take perhaps a minute on a 25 MHz RISC machine or a 66 MHz CISC | |
1448 | machine. | |
1449 | ||
1450 | We note that validation is done only between previously mutually | |
1451 | authenticated parties, and that a new group definition always follows | |
1452 | and is protected by a key established using a well-known group. | |
1453 | There are five points to keep in mind: | |
1454 | ||
1455 | ||
1456 | ||
1457 | ||
1458 | Orman Informational [Page 26] | |
1459 | \f | |
1460 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1461 | ||
1462 | ||
1463 | a. The description and public identifier for the new group are | |
1464 | protected by the well-known group. | |
1465 | ||
1466 | b. The responder can reject the attempt to establish the new | |
1467 | group, either because he is too busy or because he cannot validate | |
1468 | the largest prime factor as being sufficiently large. | |
1469 | ||
1470 | c. The new modulus and generator can be cached for long periods of | |
1471 | time; they are not security critical and need not be associated | |
1472 | with ongoing activity. | |
1473 | ||
1474 | d. Generating a new g^x value periodically will be more expensive | |
1475 | if there are many groups cached; however, the importance of | |
1476 | frequently generating new g^x values is reduced, so the time | |
1477 | period can be lengthened correspondingly. | |
1478 | ||
1479 | e. All modular exponentiation groups have subgroups that are | |
1480 | weaker than the main group. For Sophie Germain primes, if the | |
1481 | generator is a square, then there are only two elements in the | |
1482 | subgroup: 1 and g^(-1) (same as g^(p-1)) which we have already | |
1483 | recommended avoiding. For Schnorr subgroups with k not equal to | |
1484 | 2, the subgroup can be avoided by checking that the exponential is | |
1485 | not a kth root of 1 (e^k != 1 mod p). | |
1486 | ||
1487 | 2.8.1 Defining a New Group | |
1488 | ||
1489 | This section describes how to define a new group. The description of | |
1490 | the group is hidden from eavesdroppers, and the identifier assigned | |
1491 | to the group is unique to the two parties. Use of the new group for | |
1492 | Diffie-Hellman key exchanges is described in the next section. | |
1493 | ||
1494 | The secrecy of the description and the identifier increases the | |
1495 | difficulty of a passive attack, because if the group descriptor is | |
1496 | not known to the attacker, there is no straightforward and efficient | |
1497 | way to gain information about keys calculated using the group. | |
1498 | ||
1499 | Only the description of the new group need be encrypted in this | |
1500 | exchange. The hash algorithm is implied by the OAKLEY session named | |
1501 | by the group. The encryption is the encryption function of the | |
1502 | OAKLEY session. | |
1503 | ||
1504 | The descriptor of the new group is encoded in the new group payload. | |
1505 | The nonces are encoded in the Authentication Payload. | |
1506 | ||
1507 | Data beyond the encryption boundary is encrypted using the transform | |
1508 | named by the KEYID. | |
1509 | ||
1510 | ||
1511 | ||
1512 | ||
1513 | ||
1514 | Orman Informational [Page 27] | |
1515 | \f | |
1516 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1517 | ||
1518 | ||
1519 | The following messages use the ISAKMP Key Exchange Identifier OAKLEY | |
1520 | New Group. | |
1521 | ||
1522 | To define a new modular exponentiation group: | |
1523 | ||
1524 | Initiator Responder | |
1525 | --------- ---------- | |
1526 | -> KEYID, -> | |
1527 | INEWGRP, | |
1528 | Desc(New Group), Na | |
1529 | prf(sKEYID, Desc(New Group) | Na) | |
1530 | ||
1531 | <- KEYID, | |
1532 | INEWGRPRS, | |
1533 | Na, Nb | |
1534 | prf(sKEYID, Na | Nb | Desc(New Group)) <- | |
1535 | ||
1536 | -> KEYID, | |
1537 | INEWGRPACK | |
1538 | prf(sKEYID, Nb | Na | Desc(New Group)) -> | |
1539 | ||
1540 | These messages are encrypted at the encryption boundary using the key | |
1541 | indicated. The hash value is placed in the "digital signature" field | |
1542 | (see Appendix B). | |
1543 | ||
1544 | New GRP identifier = trunc16(Na) | trunc16(Nb) | |
1545 | ||
1546 | (trunc16 indicates truncation to 16 bits; the initiator and | |
1547 | responder must use nonces that have distinct upper bits from any | |
1548 | used for current GRPID's) | |
1549 | ||
1550 | Desc(G) is the encoding of the descriptor for the group descriptor | |
1551 | (see Appendix A for the format of a group descriptor) | |
1552 | ||
1553 | The two parties must store the mapping between the new group | |
1554 | identifier GRP and the group descriptor Desc(New Group). They must | |
1555 | also note the identities used for the KEYID and copy these to the | |
1556 | state for the new group. | |
1557 | ||
1558 | Note that one could have the same group descriptor associated with | |
1559 | several KEYID's. Pre-calculation of g^x values may be done based | |
1560 | only on the group descriptor, not the private group name. | |
1561 | ||
1562 | 2.8.2 Deriving a Key Using a Private Group | |
1563 | ||
1564 | Once a private group has been established, its group id can be used | |
1565 | in the key exchange messages in the GRP position. No changes to the | |
1566 | protocol are required. | |
1567 | ||
1568 | ||
1569 | ||
1570 | Orman Informational [Page 28] | |
1571 | \f | |
1572 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1573 | ||
1574 | ||
1575 | 2.9 Quick Mode: New Keys From Old, | |
1576 | ||
1577 | When an authenticated KEYID and associated keying material sKEYID | |
1578 | already exist, it is easy to derive additional KEYID's and keys | |
1579 | sharing similar attributes (GRP, EHA, etc.) using only hashing | |
1580 | functions. The KEYID might be one that was derived in Main Mode, for | |
1581 | example. | |
1582 | ||
1583 | On the other hand, the authenticated key may be a manually | |
1584 | distributed key, one that is shared by the initiator and responder | |
1585 | via some means external to OAKLEY. If the distribution method has | |
1586 | formed the KEYID using appropriately unique values for the two halves | |
1587 | (CKY-I and CKY-R), then this method is applicable. | |
1588 | ||
1589 | In the following, the Key Exchange Identifier is OAKLEY Quick Mode. | |
1590 | The nonces are carried in the Authentication Payload, and the prf | |
1591 | value is carried in the Authentication Payload; the Authentication | |
1592 | Authority is "None" and the type is "Pre-Shared". | |
1593 | ||
1594 | The protocol is: | |
1595 | ||
1596 | Initiator Responder | |
1597 | --------- --------- | |
1598 | -> KEYID, INEWKRQ, Ni, prf(sKEYID, Ni) -> | |
1599 | <- KEYID, INEWKRS, Nr, prf(sKEYID, 1 | Nr | Ni) <- | |
1600 | -> KEYID, INEWKRP, 0, prf(sKEYID, 0 | Ni | Nr) -> | |
1601 | ||
1602 | The New KEYID, NKEYID, is Ni | Nr | |
1603 | ||
1604 | sNKEYID = prf(sKEYID, Ni | Nr ) | |
1605 | ||
1606 | The identities and EHA values associated with NKEYID are the same as | |
1607 | those associated with KEYID. | |
1608 | ||
1609 | Each party must validate the hash values before using the new key for | |
1610 | any purpose. | |
1611 | ||
1612 | 2.10 Defining and Using Pre-Distributed Keys | |
1613 | ||
1614 | If a key and an associated key identifier and state information have | |
1615 | been distributed manually, then the key can be used for any OAKLEY | |
1616 | purpose. The key must be associated with the usual state | |
1617 | information: ID's and EHA algorithms. | |
1618 | ||
1619 | Local policy dictates when a manual key can be included in the OAKLEY | |
1620 | database. For example, only privileged users would be permitted to | |
1621 | introduce keys associated with privileged ID's, an unprivileged user | |
1622 | could only introduce keys associated with her own ID. | |
1623 | ||
1624 | ||
1625 | ||
1626 | Orman Informational [Page 29] | |
1627 | \f | |
1628 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1629 | ||
1630 | ||
1631 | 2.11 Distribution of an External Key | |
1632 | ||
1633 | Once an OAKLEY session key and ancillary algorithms are established, | |
1634 | the keying material and the "H" algorithm can be used to distribute | |
1635 | an externally generated key and to assign a KEYID to it. | |
1636 | ||
1637 | In the following, KEYID represents an existing, authenticated OAKLEY | |
1638 | session key, and sNEWKEYID represents the externally generated keying | |
1639 | material. | |
1640 | ||
1641 | In the following, the Key Exchange Identifier is OAKLEY External | |
1642 | Mode. The Key Exchange Payload contains the new key, which is | |
1643 | protected | |
1644 | ||
1645 | Initiator Responder | |
1646 | --------- --------- | |
1647 | -> KEYID, IEXTKEY, Ni, prf(sKEYID, Ni) -> | |
1648 | <- KEYID, IEXTKEY, Nr, prf(sKEYID, 1 | Nr | Ni) <- | |
1649 | -> KEYID, IEXTKEY, Kir xor sNEWKEYID*, prf(Kir, sNEWKEYID | Ni | Nr) -> | |
1650 | ||
1651 | Kir = prf(sKEYID, Ni | Nr) | |
1652 | ||
1653 | * this field is carried in the Key Exchange Payload. | |
1654 | ||
1655 | Each party must validate the hash values using the "H" function in | |
1656 | the KEYID state before changing any key state information. | |
1657 | ||
1658 | The new key is recovered by the Responder by calculating the xor of | |
1659 | the field in the Authentication Payload with the Kir value. | |
1660 | ||
1661 | The new key identifier, naming the keying material sNEWKEYID, is | |
1662 | prf(sKEYID, 1 | Ni | Nr). | |
1663 | ||
1664 | Note that this exchange does not require encryption. Hugo Krawcyzk | |
1665 | suggested the method and noted its advantage. | |
1666 | ||
1667 | 2.11.1 Cryptographic Strength Considerations | |
1668 | ||
1669 | The strength of the key used to distribute the external key must be | |
1670 | at least equal to the strength of the external key. Generally, this | |
1671 | means that the length of the sKEYID material must be greater than or | |
1672 | equal to the length of the sNEWKEYID material. | |
1673 | ||
1674 | The derivation of the external key, its strength or intended use are | |
1675 | not addressed by this protocol; the parties using the key must have | |
1676 | some other method for determining these properties. | |
1677 | ||
1678 | ||
1679 | ||
1680 | ||
1681 | ||
1682 | Orman Informational [Page 30] | |
1683 | \f | |
1684 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1685 | ||
1686 | ||
1687 | As of early 1996, it appears that for 90 bits of cryptographic | |
1688 | strength, one should use a modular exponentiation group modulus of | |
1689 | 2000 bits. For 128 bits of strength, a 3000 bit modulus is required. | |
1690 | ||
1691 | 3. Specifying and Deriving Security Associations | |
1692 | ||
1693 | When a security association is defined, only the KEYID need be given. | |
1694 | The responder should be able to look up the state associated with the | |
1695 | KEYID value and find the appropriate keying material, sKEYID. | |
1696 | ||
1697 | Deriving keys for use with IPSEC protocols such as ESP or AH is a | |
1698 | subject covered in the ISAKMP/Oakley Resolution document. That | |
1699 | document also describes how to negotiate acceptable parameter sets | |
1700 | and identifiers for ESP and AH, and how to exactly calculate the | |
1701 | keying material for each instance of the protocols. Because the | |
1702 | basic keying material defined here (g^xy) may be used to derive keys | |
1703 | for several instances of ESP and AH, the exact mechanics of using | |
1704 | one-way functions to turn g^xy into several unique keys is essential | |
1705 | to correct usage. | |
1706 | ||
1707 | 4. ISAKMP Compatibility | |
1708 | ||
1709 | OAKLEY uses ISAKMP header and payload formats, as described in the | |
1710 | text and in Appendix B. There are particular noteworthy extensions | |
1711 | beyond the version 4 draft. | |
1712 | ||
1713 | 4.1 Authentication with Existing Keys | |
1714 | ||
1715 | In the case that two parties do not have suitable public key | |
1716 | mechanisms in place for authenticating each other, they can use keys | |
1717 | that were distributed manually. After establishment of these keys | |
1718 | and their associated state in OAKLEY, they can be used for | |
1719 | authentication modes that depend on signatures, e.g. Aggressive Mode. | |
1720 | ||
1721 | When an existing key is to appear in an offer list, it should be | |
1722 | indicated with an Authentication Algorithm of ISAKMP_EXISTING. This | |
1723 | value will be assigned in the ISAKMP RFC. | |
1724 | ||
1725 | When the authentication method is ISAKMP_EXISTING, the authentication | |
1726 | authority will have the value ISAKMP_AUTH_EXISTING; the value for | |
1727 | this field must not conflict with any authentication authority | |
1728 | registered with IANA and is defined in the ISAKMP RFC. | |
1729 | ||
1730 | ||
1731 | ||
1732 | ||
1733 | ||
1734 | ||
1735 | ||
1736 | ||
1737 | ||
1738 | Orman Informational [Page 31] | |
1739 | \f | |
1740 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1741 | ||
1742 | ||
1743 | The authentication payload will have two parts: | |
1744 | ||
1745 | the KEYID for the pre-existing key | |
1746 | ||
1747 | the identifier for the party to be authenticated by the pre- | |
1748 | existing key. | |
1749 | ||
1750 | The pseudo-random function "H" in the state information for that | |
1751 | KEYID will be the signature algorithm, and it will use the keying | |
1752 | material for that key (sKEYID) when generating or checking the | |
1753 | validity of message data. | |
1754 | ||
1755 | E.g. if the existing key has an KEYID denoted by KID and 128 bits of | |
1756 | keying material denoted by sKID and "H" algorithm a transform named | |
1757 | HMAC, then to generate a "signature" for a data block, the output of | |
1758 | HMAC(sKID, data) will be the corresponding signature payload. | |
1759 | ||
1760 | The KEYID state will have the identities of the local and remote | |
1761 | parties for which the KEYID was assigned; it is up to the local | |
1762 | policy implementation to decide when it is appropriate to use such a | |
1763 | key for authenticating other parties. For example, a key distributed | |
1764 | for use between two Internet hosts A and B may be suitable for | |
1765 | authenticating all identities of the form "alice@A" and "bob@B". | |
1766 | ||
1767 | 4.2 Third Party Authentication | |
1768 | ||
1769 | A local security policy might restrict key negotiation to trusted | |
1770 | parties. For example, two OAKLEY daemons running with equal | |
1771 | sensitivity labels on two machines might wish to be the sole arbiters | |
1772 | of key exchanges between users with that same sensitivity label. In | |
1773 | this case, some way of authenticating the provenance of key exchange | |
1774 | requests is needed. I.e., the identities of the two daemons should | |
1775 | be bound to a key, and that key will be used to form a "signature" | |
1776 | for the key exchange messages. | |
1777 | ||
1778 | The Signature Payload, in Appendix B, is for this purpose. This | |
1779 | payload names a KEYID that is in existence before the start of the | |
1780 | current exchange. The "H" transform for that KEYID is used to | |
1781 | calculate an integrity/authentication value for all payloads | |
1782 | preceding the signature. | |
1783 | ||
1784 | Local policy can dictate which KEYID's are appropriate for signing | |
1785 | further exchanges. | |
1786 | ||
1787 | ||
1788 | ||
1789 | ||
1790 | ||
1791 | ||
1792 | ||
1793 | ||
1794 | Orman Informational [Page 32] | |
1795 | \f | |
1796 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1797 | ||
1798 | ||
1799 | 4.3 New Group Mode | |
1800 | ||
1801 | OAKLEY uses a new KEI for the exchange that defines a new group. | |
1802 | ||
1803 | 5. Security Implementation Notes | |
1804 | ||
1805 | Timing attacks that are capable of recovering the exponent value used | |
1806 | in Diffie-Hellman calculations have been described by Paul Kocher | |
1807 | [Kocher]. In order to nullify the attack, implementors must take | |
1808 | pains to obscure the sequence of operations involved in carrying out | |
1809 | modular exponentiations. | |
1810 | ||
1811 | A "blinding factor" can accomplish this goal. A group element, r, is | |
1812 | chosen at random. When an exponent x is chosen, the value r^(-x) is | |
1813 | also calculated. Then, when calculating (g^y)^x, the implementation | |
1814 | will calculate this sequence: | |
1815 | ||
1816 | A = (rg^y) | |
1817 | B = A^x = (rg^y)^x = (r^x)(g^(xy)) | |
1818 | C = B*r^(-x) = (r^x)(r^-(x))(g^(xy)) = g^(xy) | |
1819 | ||
1820 | The blinding factor is only necessary if the exponent x is used more | |
1821 | than 100 times (estimate by Richard Schroeppel). | |
1822 | ||
1823 | 6. OAKLEY Parsing and State Machine | |
1824 | ||
1825 | There are many pathways through OAKLEY, but they follow a left-to- | |
1826 | right parsing pattern of the message fields. | |
1827 | ||
1828 | The initiator decides on an initial message in the following order: | |
1829 | ||
1830 | 1. Offer a cookie. This is not necessary but it helps with | |
1831 | aggressive exchanges. | |
1832 | ||
1833 | 2. Pick a group. The choices are the well-known groups or any | |
1834 | private groups that may have been negotiated. The very first | |
1835 | exchange between two Oakley daemons with no common state must | |
1836 | involve a well-known group (0, meaning no group, is a well-known | |
1837 | group). Note that the group identifier, not the group descriptor, | |
1838 | is used in the message. | |
1839 | ||
1840 | If a non-null group will be used, it must be included with the | |
1841 | first message specifying EHAO. It need not be specified until | |
1842 | then. | |
1843 | ||
1844 | 3. If PFS will be used, pick an exponent x and present g^x. | |
1845 | ||
1846 | 4. Offer Encryption, Hash, and Authentication lists. | |
1847 | ||
1848 | ||
1849 | ||
1850 | Orman Informational [Page 33] | |
1851 | \f | |
1852 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1853 | ||
1854 | ||
1855 | 5. Use PFS for hiding the identities | |
1856 | ||
1857 | If identity hiding is not used, then the initiator has this | |
1858 | option: | |
1859 | ||
1860 | 6. Name the identities and include authentication information | |
1861 | ||
1862 | The information in the authentication section depends on the first | |
1863 | authentication offer. In this aggressive exchange, the Initiator | |
1864 | hopes that the Responder will accept all the offered information and | |
1865 | the first authentication method. The authentication method | |
1866 | determines the authentication payload as follows: | |
1867 | ||
1868 | 1. Signing method. The signature will be applied to all the | |
1869 | offered information. | |
1870 | ||
1871 | 2. A public key encryption method. The algorithm will be used to | |
1872 | encrypt a nonce in the public key of the requested Responder | |
1873 | identity. There are two cases possible, depending on whether or | |
1874 | not identity hiding is used: | |
1875 | ||
1876 | a. No identity hiding. The ID's will appear as plaintext. | |
1877 | b. Identity hiding. A well-known ID, call it R', will appear | |
1878 | as plaintext in the authentication payload. It will be | |
1879 | followed by two ID's and a nonce; these will be encrypted using | |
1880 | the public key for R'. | |
1881 | ||
1882 | 3. A pre-existing key method. The pre-existing key will be used | |
1883 | to encrypt a nonce. If identity hiding is used, the ID's will be | |
1884 | encrypted in place in the payload, using the "E" algorithm | |
1885 | associated with the pre-existing key. | |
1886 | ||
1887 | The Responder can accept all, part or none of the initial message. | |
1888 | ||
1889 | The Responder accepts as many of the fields as he wishes, using the | |
1890 | same decision order as the initiator. At any step he can stop, | |
1891 | implicitly rejecting further fields (which will have null values in | |
1892 | his response message). The minimum response is a cookie and the GRP. | |
1893 | ||
1894 | 1. Accept cookie. The Responder may elect to record no state | |
1895 | information until the Initiator successfully replies with a cookie | |
1896 | chosen by the responder. If so, the Responder replies with a | |
1897 | cookie, the GRP, and no other information. | |
1898 | ||
1899 | 2. Accept GRP. If the group is not acceptable, the Responder will | |
1900 | not reply. The Responder may send an error message indicating the | |
1901 | the group is not acceptable (modulus too small, unknown | |
1902 | identifier, etc.) Note that "no group" has two meanings during | |
1903 | ||
1904 | ||
1905 | ||
1906 | Orman Informational [Page 34] | |
1907 | \f | |
1908 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1909 | ||
1910 | ||
1911 | the protocol: it may mean the group is not yet specified, or it | |
1912 | may mean that no group will be used (and thus PFS is not | |
1913 | possible). | |
1914 | ||
1915 | 3. Accept the g^x value. The Responder indicates his acceptance | |
1916 | of the g^x value by including his own g^y value in his reply. He | |
1917 | can postpone this by ignoring g^x and putting a zero length g^y | |
1918 | value in his reply. He can also reject the g^x value with an | |
1919 | error message. | |
1920 | ||
1921 | 4. Accept one element from each of the EHA lists. The acceptance | |
1922 | is indicated by a non-zero proposal. | |
1923 | ||
1924 | 5. If PFS for identity hiding is requested, then no further data | |
1925 | will follow. | |
1926 | ||
1927 | 6. If the authentication payload is present, and if the first item | |
1928 | in the offered authentication class is acceptable, then the | |
1929 | Responder must validate/decrypt the information in the | |
1930 | authentication payload and signature payload, if present. The | |
1931 | Responder should choose a nonce and reply using the same | |
1932 | authentication/hash algorithm as the Initiator used. | |
1933 | ||
1934 | The Initiator notes which information the Responder has accepted, | |
1935 | validates/decrypts any signed, hashed, or encrypted fields, and if | |
1936 | the data is acceptable, replies in accordance to the EHA methods | |
1937 | selected by the Responder. The Initiator replies are distinguished | |
1938 | from his initial message by the presence of the non-zero value for | |
1939 | the Responder cookie. | |
1940 | ||
1941 | The output of the signature or prf function will be encoded as a | |
1942 | variable precision integer as described in Appendix C. The KEYID | |
1943 | will indicate KEYID that names keying material and the Hash or | |
1944 | Signature function. | |
1945 | ||
1946 | 7. The Credential Payload | |
1947 | ||
1948 | Useful certificates with public key information can be attached to | |
1949 | OAKLEY messages using Credential Payloads as defined in the ISAKMP | |
1950 | document. It should be noted that the identity protection option | |
1951 | applies to the credentials as well as the identities. | |
1952 | ||
1953 | Security Considerations | |
1954 | ||
1955 | The focus of this document is security; hence security considerations | |
1956 | permeate this memo. | |
1957 | ||
1958 | ||
1959 | ||
1960 | ||
1961 | ||
1962 | Orman Informational [Page 35] | |
1963 | \f | |
1964 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
1965 | ||
1966 | ||
1967 | Author's Address | |
1968 | ||
1969 | Hilarie K. Orman | |
1970 | Department of Computer Science | |
1971 | University of Arizona | |
1972 | ||
1973 | EMail: ho@darpa.mil | |
1974 | ||
1975 | ||
1976 | ||
1977 | ||
1978 | ||
1979 | ||
1980 | ||
1981 | ||
1982 | ||
1983 | ||
1984 | ||
1985 | ||
1986 | ||
1987 | ||
1988 | ||
1989 | ||
1990 | ||
1991 | ||
1992 | ||
1993 | ||
1994 | ||
1995 | ||
1996 | ||
1997 | ||
1998 | ||
1999 | ||
2000 | ||
2001 | ||
2002 | ||
2003 | ||
2004 | ||
2005 | ||
2006 | ||
2007 | ||
2008 | ||
2009 | ||
2010 | ||
2011 | ||
2012 | ||
2013 | ||
2014 | ||
2015 | ||
2016 | ||
2017 | ||
2018 | Orman Informational [Page 36] | |
2019 | \f | |
2020 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2021 | ||
2022 | ||
2023 | APPENDIX A Group Descriptors | |
2024 | ||
2025 | Three distinct group representations can be used with OAKLEY. Each | |
2026 | group is defined by its group operation and the kind of underlying | |
2027 | field used to represent group elements. The three types are modular | |
2028 | exponentiation groups (named MODP herein), elliptic curve groups over | |
2029 | the field GF[2^N] (named EC2N herein), and elliptic curve groups over | |
2030 | GF[P] (named ECP herein) For each representation, many distinct | |
2031 | realizations are possible, depending on parameter selection. | |
2032 | ||
2033 | With a few exceptions, all the parameters are transmitted as if they | |
2034 | were non-negative multi-precision integers, using the format defined | |
2035 | in this appendix (note, this is distinct from the encoding in | |
2036 | Appendix C). Every multi-precision integer has a prefixed length | |
2037 | field, even where this information is redundant. | |
2038 | ||
2039 | For the group type EC2N, the parameters are more properly thought of | |
2040 | as very long bit fields, but they are represented as multi-precision | |
2041 | integers, (with length fields, and right-justified). This is the | |
2042 | natural encoding. | |
2043 | ||
2044 | MODP means the classical modular exponentiation group, where the | |
2045 | operation is to calculate G^X (mod P). The group is defined by the | |
2046 | numeric parameters P and G. P must be a prime. G is often 2, but | |
2047 | may be a larger number. 2 <= G <= P-2. | |
2048 | ||
2049 | ECP is an elliptic curve group, modulo a prime number P. The | |
2050 | defining equation for this kind of group is | |
2051 | Y^2 = X^3 + AX + B The group operation is taking a multiple of an | |
2052 | elliptic-curve point. The group is defined by 5 numeric parameters: | |
2053 | The prime P, two curve parameters A and B, and a generator (X,Y). | |
2054 | A,B,X,Y are all interpreted mod P, and must be (non-negative) | |
2055 | integers less than P. They must satisfy the defining equation, | |
2056 | modulo P. | |
2057 | ||
2058 | EC2N is an elliptic curve group, over the finite field F[2^N]. The | |
2059 | defining equation for this kind of group is | |
2060 | Y^2 + XY = X^3 + AX^2 + B (This equation differs slightly from the | |
2061 | mod P case: it has an XY term, and an AX^2 term instead of an AX | |
2062 | term.) | |
2063 | ||
2064 | We must specify the field representation, and then the elliptic | |
2065 | curve. The field is specified by giving an irreducible polynomial | |
2066 | (mod 2) of degree N. This polynomial is represented as an integer of | |
2067 | size between 2^N and 2^(N+1), as if the defining polynomial were | |
2068 | evaluated at the value U=2. | |
2069 | ||
2070 | ||
2071 | ||
2072 | ||
2073 | ||
2074 | Orman Informational [Page 37] | |
2075 | \f | |
2076 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2077 | ||
2078 | ||
2079 | For example, the field defined by the polynomial U^155 + U^62 + 1 is | |
2080 | represented by the integer 2^155 + 2^62 + 1. The group is defined by | |
2081 | 4 more parameters, A,B,X,Y. These parameters are elements of the | |
2082 | field GF[2^N], and can be thought of as polynomials of degree < N, | |
2083 | with (mod 2) coefficients. They fit in N-bit fields, and are | |
2084 | represented as integers < 2^N, as if the polynomial were evaluated at | |
2085 | U=2. For example, the field element U^2 + 1 would be represented by | |
2086 | the integer 2^2+1, which is 5. The two parameters A and B define the | |
2087 | curve. A is frequently 0. B must not be 0. The parameters X and Y | |
2088 | select a point on the curve. The parameters A,B,X,Y must satisfy the | |
2089 | defining equation, modulo the defining polynomial, and mod 2. | |
2090 | ||
2091 | Group descriptor formats: | |
2092 | ||
2093 | Type of group: A two-byte field, | |
2094 | assigned values for the types "MODP", "ECP", "EC2N" | |
2095 | will be defined (see ISAKMP-04). | |
2096 | Size of a field element, in bits. This is either Ceiling(log2 P) | |
2097 | or the degree of the irreducible polynomial: a 32-bit integer. | |
2098 | The prime P or the irreducible field polynomial: a multi-precision | |
2099 | integer. | |
2100 | The generator: 1 or 2 values, multi-precision integers. | |
2101 | EC only: The parameters of the curve: 2 values, multi-precision | |
2102 | integers. | |
2103 | ||
2104 | The following parameters are Optional (each of these may appear | |
2105 | independently): | |
2106 | a value of 0 may be used as a place-holder to represent an unspecified | |
2107 | parameter; any number of the parameters may be sent, from 0 to 3. | |
2108 | ||
2109 | The largest prime factor: the encoded value that is the LPF of the | |
2110 | group size, a multi-precision integer. | |
2111 | ||
2112 | EC only: The order of the group: multi-precision integer. | |
2113 | (The group size for MODP is always P-1.) | |
2114 | ||
2115 | Strength of group: 32-bit integer. | |
2116 | The strength of the group is approximately the number of key-bits | |
2117 | protected. | |
2118 | It is determined by the log2 of the effort to attack the group. | |
2119 | It may change as we learn more about cryptography. | |
2120 | ||
2121 | This is a generic example for a "classic" modular exponentiation group: | |
2122 | Group type: "MODP" | |
2123 | Size of a field element in bits: Log2 (P) rounded *up*. A 32bit | |
2124 | integer. | |
2125 | Defining prime P: a multi-precision integer. | |
2126 | Generator G: a multi-precision integer. 2 <= G <= P-2. | |
2127 | ||
2128 | ||
2129 | ||
2130 | Orman Informational [Page 38] | |
2131 | \f | |
2132 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2133 | ||
2134 | ||
2135 | <optional> | |
2136 | Largest prime factor of P-1: the multi-precision integer Q | |
2137 | Strength of group: a 32-bit integer. We will specify a formula | |
2138 | for calculating this number (TBD). | |
2139 | ||
2140 | This is a generic example for an elliptic curve group, mod P: | |
2141 | Group type: "ECP" | |
2142 | Size of a field element in bits: Log2 (P) rounded *up*, | |
2143 | a 32 bit integer. | |
2144 | Defining prime P: a multi-precision integer. | |
2145 | Generator (X,Y): 2 multi-precision integers, each < P. | |
2146 | Parameters of the curve A,B: 2 multi-precision integers, each < P. | |
2147 | <optional> | |
2148 | Largest prime factor of the group order: a multi-precision integer. | |
2149 | Order of the group: a multi-precision integer. | |
2150 | Strength of group: a 32-bit integer. Formula TBD. | |
2151 | ||
2152 | This is a specific example for an elliptic curve group: | |
2153 | Group type: "EC2N" | |
2154 | Degree of the irreducible polynomial: 155 | |
2155 | Irreducible polynomial: U^155 + U^62 + 1, represented as the | |
2156 | multi-precision integer 2^155 + 2^62 + 1. | |
2157 | Generator (X,Y) : represented as 2 multi-precision integers, each | |
2158 | < 2^155. | |
2159 | For our present curve, these are (decimal) 123 and 456. Each is | |
2160 | represented as a multi-precision integer. | |
2161 | Parameters of the curve A,B: represented as 2 multi-precision | |
2162 | integers, each < 2^155. | |
2163 | For our present curve these are 0 and (decimal) 471951, represented | |
2164 | as two multi-precision integers. | |
2165 | ||
2166 | <optional> | |
2167 | Largest prime factor of the group order: | |
2168 | ||
2169 | 3805993847215893016155463826195386266397436443, | |
2170 | ||
2171 | represented as a multi-precision integer. | |
2172 | The order of the group: | |
2173 | ||
2174 | 45671926166590716193865565914344635196769237316 | |
2175 | ||
2176 | represented as a multi-precision integer. | |
2177 | ||
2178 | Strength of group: 76, represented as a 32-bit integer. | |
2179 | ||
2180 | The variable precision integer encoding for group descriptor fields | |
2181 | is the following. This is a slight variation on the format defined | |
2182 | in Appendix C in that a fixed 16-bit value is used first, and the | |
2183 | ||
2184 | ||
2185 | ||
2186 | Orman Informational [Page 39] | |
2187 | \f | |
2188 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2189 | ||
2190 | ||
2191 | length is limited to 16 bits. However, the interpretation is | |
2192 | otherwise identical. | |
2193 | ||
2194 | 1 2 3 | |
2195 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
2196 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2197 | ! Fixed value (TBD) ! Length ! | |
2198 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2199 | . . | |
2200 | . Integer . | |
2201 | . . | |
2202 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2203 | ||
2204 | ||
2205 | The format of a group descriptor is: | |
2206 | 1 2 3 | |
2207 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
2208 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2209 | !1!1! Group Description ! MODP ! | |
2210 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2211 | !1!0! Field Size ! Length ! | |
2212 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2213 | ! MPI ! | |
2214 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2215 | !1!0! Prime ! Length ! | |
2216 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2217 | ! MPI ! | |
2218 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2219 | !1!0! Generator1 ! Length ! | |
2220 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2221 | ! MPI ! | |
2222 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2223 | !1!0! Generator2 ! Length ! | |
2224 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2225 | ! MPI ! | |
2226 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2227 | !1!0! Curve-p1 ! Length ! | |
2228 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2229 | ! MPI ! | |
2230 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2231 | !1!0! Curve-p2 ! Length ! | |
2232 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2233 | ! MPI ! | |
2234 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2235 | !1!0! Largest Prime Factor ! Length ! | |
2236 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2237 | ! MPI ! | |
2238 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2239 | ||
2240 | ||
2241 | ||
2242 | Orman Informational [Page 40] | |
2243 | \f | |
2244 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2245 | ||
2246 | ||
2247 | !1!0! Order of Group ! Length ! | |
2248 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2249 | ! MPI ! | |
2250 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2251 | !0!0! Strength of Group ! Length ! | |
2252 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2253 | ! MPI ! | |
2254 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2255 | ||
2256 | ||
2257 | ||
2258 | ||
2259 | ||
2260 | ||
2261 | ||
2262 | ||
2263 | ||
2264 | ||
2265 | ||
2266 | ||
2267 | ||
2268 | ||
2269 | ||
2270 | ||
2271 | ||
2272 | ||
2273 | ||
2274 | ||
2275 | ||
2276 | ||
2277 | ||
2278 | ||
2279 | ||
2280 | ||
2281 | ||
2282 | ||
2283 | ||
2284 | ||
2285 | ||
2286 | ||
2287 | ||
2288 | ||
2289 | ||
2290 | ||
2291 | ||
2292 | ||
2293 | ||
2294 | ||
2295 | ||
2296 | ||
2297 | ||
2298 | Orman Informational [Page 41] | |
2299 | \f | |
2300 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2301 | ||
2302 | ||
2303 | APPENDIX B Message formats | |
2304 | ||
2305 | The encodings of Oakley messages into ISAKMP payloads is deferred to | |
2306 | the ISAKMP/Oakley Resolution document. | |
2307 | ||
2308 | ||
2309 | ||
2310 | ||
2311 | ||
2312 | ||
2313 | ||
2314 | ||
2315 | ||
2316 | ||
2317 | ||
2318 | ||
2319 | ||
2320 | ||
2321 | ||
2322 | ||
2323 | ||
2324 | ||
2325 | ||
2326 | ||
2327 | ||
2328 | ||
2329 | ||
2330 | ||
2331 | ||
2332 | ||
2333 | ||
2334 | ||
2335 | ||
2336 | ||
2337 | ||
2338 | ||
2339 | ||
2340 | ||
2341 | ||
2342 | ||
2343 | ||
2344 | ||
2345 | ||
2346 | ||
2347 | ||
2348 | ||
2349 | ||
2350 | ||
2351 | ||
2352 | ||
2353 | ||
2354 | Orman Informational [Page 42] | |
2355 | \f | |
2356 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2357 | ||
2358 | ||
2359 | APPENDIX C Encoding a variable precision integer. | |
2360 | ||
2361 | Variable precision integers will be encoded as a 32-bit length field | |
2362 | followed by one or more 32-bit quantities containing the | |
2363 | representation of the integer, aligned with the most significant bit | |
2364 | in the first 32-bit item. | |
2365 | ||
2366 | 1 2 3 | |
2367 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
2368 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2369 | ! length ! | |
2370 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2371 | ! first value word (most significant bits) ! | |
2372 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2373 | ! ! | |
2374 | ~ additional value words ~ | |
2375 | ! ! | |
2376 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2377 | ||
2378 | An example of such an encoding is given below, for a number with 51 | |
2379 | bits of significance. The length field indicates that 2 32-bit | |
2380 | quantities follow. The most significant non-zero bit of the number | |
2381 | is in bit 13 of the first 32-bit quantity, the low order bits are in | |
2382 | the second 32-bit quantity. | |
2383 | ||
2384 | 1 2 3 | |
2385 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
2386 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2387 | ! 1 0! | |
2388 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2389 | !0 0 0 0 0 0 0 0 0 0 0 0 0 1 x x x x x x x x x x x x x x x x x x! | |
2390 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2391 | !x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x! | |
2392 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2393 | ||
2394 | ||
2395 | ||
2396 | ||
2397 | ||
2398 | ||
2399 | ||
2400 | ||
2401 | ||
2402 | ||
2403 | ||
2404 | ||
2405 | ||
2406 | ||
2407 | ||
2408 | ||
2409 | ||
2410 | Orman Informational [Page 43] | |
2411 | \f | |
2412 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2413 | ||
2414 | ||
2415 | APPENDIX D Cryptographic strengths | |
2416 | ||
2417 | The Diffie-Hellman algorithm is used to compute keys that will be | |
2418 | used with symmetric algorithms. It should be no easier to break the | |
2419 | Diffie-Hellman computation than it is to do an exhaustive search over | |
2420 | the symmetric key space. A recent recommendation by an group of | |
2421 | cryptographers [Blaze] has recommended a symmetric key size of 75 | |
2422 | bits for a practical level of security. For 20 year security, they | |
2423 | recommend 90 bits. | |
2424 | ||
2425 | Based on that report, a conservative strategy for OAKLEY users would | |
2426 | be to ensure that their Diffie-Hellman computations were as secure as | |
2427 | at least a 90-bit key space. In order to accomplish this for modular | |
2428 | exponentiation groups, the size of the largest prime factor of the | |
2429 | modulus should be at least 180 bits, and the size of the modulus | |
2430 | should be at least 1400 bits. For elliptic curve groups, the LPF | |
2431 | should be at least 180 bits. | |
2432 | ||
2433 | If long-term secrecy of the encryption key is not an issue, then the | |
2434 | following parameters may be used for the modular exponentiation | |
2435 | group: 150 bits for the LPF, 980 bits for the modulus size. | |
2436 | ||
2437 | The modulus size alone does not determine the strength of the | |
2438 | Diffie-Hellman calculation; the size of the exponent used in | |
2439 | computing powers within the group is also important. The size of the | |
2440 | exponent in bits should be at least twice the size of any symmetric | |
2441 | key that will be derived from it. We recommend that ISAKMP | |
2442 | implementors use at least 180 bits of exponent (twice the size of a | |
2443 | 20-year symmetric key). | |
2444 | ||
2445 | The mathematical justification for these estimates can be found in | |
2446 | texts that estimate the effort for solving the discrete log problem, | |
2447 | a task that is strongly related to the efficiency of using the Number | |
2448 | Field Sieve for factoring large integers. Readers are referred to | |
2449 | [Stinson] and [Schneier]. | |
2450 | ||
2451 | ||
2452 | ||
2453 | ||
2454 | ||
2455 | ||
2456 | ||
2457 | ||
2458 | ||
2459 | ||
2460 | ||
2461 | ||
2462 | ||
2463 | ||
2464 | ||
2465 | ||
2466 | Orman Informational [Page 44] | |
2467 | \f | |
2468 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2469 | ||
2470 | ||
2471 | APPENDIX E The Well-Known Groups | |
2472 | ||
2473 | The group identifiers: | |
2474 | ||
2475 | 0 No group (used as a placeholder and for non-DH exchanges) | |
2476 | 1 A modular exponentiation group with a 768 bit modulus | |
2477 | 2 A modular exponentiation group with a 1024 bit modulus | |
2478 | 3 A modular exponentiation group with a 1536 bit modulus (TBD) | |
2479 | 4 An elliptic curve group over GF[2^155] | |
2480 | 5 An elliptic curve group over GF[2^185] | |
2481 | ||
2482 | values 2^31 and higher are used for private group identifiers | |
2483 | ||
2484 | Richard Schroeppel performed all the mathematical and computational | |
2485 | work for this appendix. | |
2486 | ||
2487 | Classical Diffie-Hellman Modular Exponentiation Groups | |
2488 | ||
2489 | The primes for groups 1 and 2 were selected to have certain | |
2490 | properties. The high order 64 bits are forced to 1. This helps the | |
2491 | classical remainder algorithm, because the trial quotient digit can | |
2492 | always be taken as the high order word of the dividend, possibly +1. | |
2493 | The low order 64 bits are forced to 1. This helps the Montgomery- | |
2494 | style remainder algorithms, because the multiplier digit can always | |
2495 | be taken to be the low order word of the dividend. The middle bits | |
2496 | are taken from the binary expansion of pi. This guarantees that they | |
2497 | are effectively random, while avoiding any suspicion that the primes | |
2498 | have secretly been selected to be weak. | |
2499 | ||
2500 | Because both primes are based on pi, there is a large section of | |
2501 | overlap in the hexadecimal representations of the two primes. The | |
2502 | primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also | |
2503 | prime), to have the maximum strength against the square-root attack | |
2504 | on the discrete logarithm problem. | |
2505 | ||
2506 | The starting trial numbers were repeatedly incremented by 2^64 until | |
2507 | suitable primes were located. | |
2508 | ||
2509 | Because these two primes are congruent to 7 (mod 8), 2 is a quadratic | |
2510 | residue of each prime. All powers of 2 will also be quadratic | |
2511 | residues. This prevents an opponent from learning the low order bit | |
2512 | of the Diffie-Hellman exponent (AKA the subgroup confinement | |
2513 | problem). Using 2 as a generator is efficient for some modular | |
2514 | exponentiation algorithms. [Note that 2 is technically not a | |
2515 | generator in the number theory sense, because it omits half of the | |
2516 | possible residues mod P. From a cryptographic viewpoint, this is a | |
2517 | virtue.] | |
2518 | ||
2519 | ||
2520 | ||
2521 | ||
2522 | Orman Informational [Page 45] | |
2523 | \f | |
2524 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2525 | ||
2526 | ||
2527 | E.1. Well-Known Group 1: A 768 bit prime | |
2528 | ||
2529 | The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its | |
2530 | decimal value is | |
2531 | 155251809230070893513091813125848175563133404943451431320235 | |
2532 | 119490296623994910210725866945387659164244291000768028886422 | |
2533 | 915080371891804634263272761303128298374438082089019628850917 | |
2534 | 0691316593175367469551763119843371637221007210577919 | |
2535 | ||
2536 | This has been rigorously verified as a prime. | |
2537 | ||
2538 | The representation of the group in OAKLEY is | |
2539 | ||
2540 | Type of group: "MODP" | |
2541 | Size of field element (bits): 768 | |
2542 | Prime modulus: 21 (decimal) | |
2543 | Length (32 bit words): 24 | |
2544 | Data (hex): | |
2545 | FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 | |
2546 | 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD | |
2547 | EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 | |
2548 | E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF | |
2549 | Generator: 22 (decimal) | |
2550 | Length (32 bit words): 1 | |
2551 | Data (hex): 2 | |
2552 | ||
2553 | Optional Parameters: | |
2554 | Group order largest prime factor: 24 (decimal) | |
2555 | Length (32 bit words): 24 | |
2556 | Data (hex): | |
2557 | 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 | |
2558 | 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E | |
2559 | F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 | |
2560 | F242DABB 312F3F63 7A262174 D31D1B10 7FFFFFFF FFFFFFFF | |
2561 | Strength of group: 26 (decimal) | |
2562 | Length (32 bit words) 1 | |
2563 | Data (hex): | |
2564 | 00000042 | |
2565 | ||
2566 | E.2. Well-Known Group 2: A 1024 bit prime | |
2567 | ||
2568 | The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. | |
2569 | Its decimal value is | |
2570 | 179769313486231590770839156793787453197860296048756011706444 | |
2571 | 423684197180216158519368947833795864925541502180565485980503 | |
2572 | 646440548199239100050792877003355816639229553136239076508735 | |
2573 | 759914822574862575007425302077447712589550957937778424442426 | |
2574 | 617334727629299387668709205606050270810842907692932019128194 | |
2575 | ||
2576 | ||
2577 | ||
2578 | Orman Informational [Page 46] | |
2579 | \f | |
2580 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2581 | ||
2582 | ||
2583 | 467627007 | |
2584 | ||
2585 | The primality of the number has been rigorously proven. | |
2586 | ||
2587 | The representation of the group in OAKLEY is | |
2588 | Type of group: "MODP" | |
2589 | Size of field element (bits): 1024 | |
2590 | Prime modulus: 21 (decimal) | |
2591 | Length (32 bit words): 32 | |
2592 | Data (hex): | |
2593 | FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 | |
2594 | 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD | |
2595 | EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 | |
2596 | E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED | |
2597 | EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 | |
2598 | FFFFFFFF FFFFFFFF | |
2599 | Generator: 22 (decimal) | |
2600 | Length (32 bit words): 1 | |
2601 | Data (hex): 2 | |
2602 | ||
2603 | Optional Parameters: | |
2604 | Group order largest prime factor: 24 (decimal) | |
2605 | Length (32 bit words): 32 | |
2606 | Data (hex): | |
2607 | 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 | |
2608 | 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E | |
2609 | F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 | |
2610 | F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 | |
2611 | F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F67329C0 | |
2612 | FFFFFFFF FFFFFFFF | |
2613 | Strength of group: 26 (decimal) | |
2614 | Length (32 bit words) 1 | |
2615 | Data (hex): | |
2616 | 0000004D | |
2617 | ||
2618 | E.3. Well-Known Group 3: An Elliptic Curve Group Definition | |
2619 | ||
2620 | The curve is based on the Galois field GF[2^155] with 2^155 field | |
2621 | elements. The irreducible polynomial for the field is u^155 + u^62 + | |
2622 | 1. The equation for the elliptic curve is | |
2623 | ||
2624 | Y^2 + X Y = X^3 + A X + B | |
2625 | ||
2626 | X, Y, A, B are elements of the field. | |
2627 | ||
2628 | For the curve specified, A = 0 and | |
2629 | ||
2630 | B = u^18 + u^17 + u^16 + u^13 + u^12 + u^9 + u^8 + u^7 + u^3 + u^2 + | |
2631 | ||
2632 | ||
2633 | ||
2634 | Orman Informational [Page 47] | |
2635 | \f | |
2636 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2637 | ||
2638 | ||
2639 | u + 1. | |
2640 | ||
2641 | B is represented in binary as the bit string 1110011001110001111; in | |
2642 | decimal this is 471951, and in hex 7338F. | |
2643 | ||
2644 | The generator is a point (X,Y) on the curve (satisfying the curve | |
2645 | equation, mod 2 and modulo the field polynomial). | |
2646 | ||
2647 | X = u^6 + u^5 + u^4 + u^3 + u + 1 | |
2648 | ||
2649 | and | |
2650 | ||
2651 | Y = u^8 + u^7 + u^6 + u^3. | |
2652 | ||
2653 | The binary bit strings for X and Y are 1111011 and 111001000; in | |
2654 | decimal they are 123 and 456. | |
2655 | ||
2656 | The group order (the number of curve points) is | |
2657 | 45671926166590716193865565914344635196769237316 | |
2658 | which is 12 times the prime | |
2659 | ||
2660 | 3805993847215893016155463826195386266397436443. | |
2661 | (This prime has been rigorously proven.) The generating point (X,Y) | |
2662 | has order 4 times the prime; the generator is the triple of some | |
2663 | curve point. | |
2664 | ||
2665 | OAKLEY representation of this group: | |
2666 | Type of group: "EC2N" | |
2667 | Size of field element (bits): 155 | |
2668 | Irreducible field polynomial: 21 (decimal) | |
2669 | Length (32 bit words): 5 | |
2670 | Data (hex): | |
2671 | 08000000 00000000 00000000 40000000 00000001 | |
2672 | Generator: | |
2673 | X coordinate: 22 (decimal) | |
2674 | Length (32 bit words): 1 | |
2675 | Data (hex): 7B | |
2676 | Y coordinate: 22 (decimal) | |
2677 | Length (32 bit words): 1 | |
2678 | Data (hex): 1C8 | |
2679 | Elliptic curve parameters: | |
2680 | A parameter: 23 (decimal) | |
2681 | Length (32 bit words): 1 | |
2682 | Data (hex): 0 | |
2683 | B parameter: 23 (decimal) | |
2684 | Length (32 bit words): 1 | |
2685 | Data (hex): 7338F | |
2686 | ||
2687 | ||
2688 | ||
2689 | ||
2690 | Orman Informational [Page 48] | |
2691 | \f | |
2692 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2693 | ||
2694 | ||
2695 | Optional Parameters: | |
2696 | Group order largest prime factor: 24 (decimal) | |
2697 | Length (32 bit words): 5 | |
2698 | Data (hex): | |
2699 | 00AAAAAA AAAAAAAA AAAAB1FC F1E206F4 21A3EA1B | |
2700 | Group order: 25 (decimal) | |
2701 | Length (32 bit words): 5 | |
2702 | Data (hex): | |
2703 | 08000000 00000000 000057DB 56985371 93AEF944 | |
2704 | Strength of group: 26 (decimal) | |
2705 | Length (32 bit words) 1 | |
2706 | Data (hex): | |
2707 | 0000004C | |
2708 | ||
2709 | E.4. Well-Known Group 4: A Large Elliptic Curve Group Definition | |
2710 | ||
2711 | This curve is based on the Galois field GF[2^185] with 2^185 field | |
2712 | elements. The irreducible polynomial for the field is | |
2713 | ||
2714 | u^185 + u^69 + 1. | |
2715 | ||
2716 | The equation for the elliptic curve is | |
2717 | ||
2718 | Y^2 + X Y = X^3 + A X + B. | |
2719 | ||
2720 | X, Y, A, B are elements of the field. For the curve specified, A = 0 | |
2721 | and | |
2722 | ||
2723 | B = u^12 + u^11 + u^10 + u^9 + u^7 + u^6 + u^5 + u^3 + 1. | |
2724 | ||
2725 | B is represented in binary as the bit string 1111011101001; in | |
2726 | decimal this is 7913, and in hex 1EE9. | |
2727 | ||
2728 | The generator is a point (X,Y) on the curve (satisfying the curve | |
2729 | equation, mod 2 and modulo the field polynomial); | |
2730 | ||
2731 | X = u^4 + u^3 and Y = u^3 + u^2 + 1. | |
2732 | ||
2733 | The binary bit strings for X and Y are 11000 and 1101; in decimal | |
2734 | they are 24 and 13. The group order (the number of curve points) is | |
2735 | ||
2736 | 49039857307708443467467104857652682248052385001045053116, | |
2737 | ||
2738 | which is 4 times the prime | |
2739 | ||
2740 | 12259964326927110866866776214413170562013096250261263279. | |
2741 | ||
2742 | (This prime has been rigorously proven.) | |
2743 | ||
2744 | ||
2745 | ||
2746 | Orman Informational [Page 49] | |
2747 | \f | |
2748 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2749 | ||
2750 | ||
2751 | The generating point (X,Y) has order 2 times the prime; the generator | |
2752 | is the double of some curve point. | |
2753 | ||
2754 | OAKLEY representation of this group: | |
2755 | ||
2756 | Type of group: "EC2N" | |
2757 | Size of field element (bits): 185 | |
2758 | Irreducible field polynomial: 21 (decimal) | |
2759 | Length (32 bit words): 6 | |
2760 | Data (hex): | |
2761 | 02000000 00000000 00000000 00000020 00000000 00000001 | |
2762 | Generator: | |
2763 | X coordinate: 22 (decimal) | |
2764 | Length (32 bit words): 1 | |
2765 | Data (hex): 18 | |
2766 | Y coordinate: 22 (decimal) | |
2767 | Length (32 bit words): 1 | |
2768 | Data (hex): D | |
2769 | Elliptic curve parameters: | |
2770 | A parameter: 23 (decimal) | |
2771 | Length (32 bit words): 1 | |
2772 | Data (hex): 0 | |
2773 | B parameter: 23 (decimal) | |
2774 | Length (32 bit words): 1 | |
2775 | Data (hex): 1EE9 | |
2776 | ||
2777 | Optional parameters: | |
2778 | Group order largest prime factor: 24 (decimal) | |
2779 | Length (32 bit words): 6 | |
2780 | Data (hex): | |
2781 | 007FFFFF FFFFFFFF FFFFFFFF F6FCBE22 6DCF9210 5D7E53AF | |
2782 | Group order: 25 (decimal) | |
2783 | Length (32 bit words): 6 | |
2784 | Data (hex): | |
2785 | 01FFFFFF FFFFFFFF FFFFFFFF DBF2F889 B73E4841 75F94EBC | |
2786 | Strength of group: 26 (decimal) | |
2787 | Length (32 bit words) 1 | |
2788 | Data (hex): | |
2789 | 0000005B | |
2790 | ||
2791 | E.5. Well-Known Group 5: A 1536 bit prime | |
2792 | ||
2793 | The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 | |
2794 | }. | |
2795 | Its decimal value is | |
2796 | 241031242692103258855207602219756607485695054850245994265411 | |
2797 | 694195810883168261222889009385826134161467322714147790401219 | |
2798 | 650364895705058263194273070680500922306273474534107340669624 | |
2799 | ||
2800 | ||
2801 | ||
2802 | Orman Informational [Page 50] | |
2803 | \f | |
2804 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2805 | ||
2806 | ||
2807 | 601458936165977404102716924945320037872943417032584377865919 | |
2808 | 814376319377685986952408894019557734611984354530154704374720 | |
2809 | 774996976375008430892633929555996888245787241299381012913029 | |
2810 | 459299994792636526405928464720973038494721168143446471443848 | |
2811 | 8520940127459844288859336526896320919633919 | |
2812 | ||
2813 | The primality of the number has been rigorously proven. | |
2814 | ||
2815 | The representation of the group in OAKLEY is | |
2816 | Type of group: "MODP" | |
2817 | Size of field element (bits): 1536 | |
2818 | Prime modulus: 21 (decimal) | |
2819 | Length (32 bit words): 48 | |
2820 | Data (hex): | |
2821 | FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 | |
2822 | 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD | |
2823 | EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 | |
2824 | E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED | |
2825 | EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D | |
2826 | C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F | |
2827 | 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D | |
2828 | 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF | |
2829 | Generator: 22 (decimal) | |
2830 | Length (32 bit words): 1 | |
2831 | Data (hex): 2 | |
2832 | ||
2833 | Optional Parameters: | |
2834 | Group order largest prime factor: 24 (decimal) | |
2835 | Length (32 bit words): 48 | |
2836 | Data (hex): | |
2837 | 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 | |
2838 | 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E | |
2839 | F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 | |
2840 | F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 | |
2841 | F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E | |
2842 | E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF | |
2843 | C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 | |
2844 | B3861AA7 255E4C02 78BA3604 6511B993 FFFFFFFF FFFFFFFF | |
2845 | Strength of group: 26 (decimal) | |
2846 | Length (32 bit words) 1 | |
2847 | Data (hex): | |
2848 | 0000005B | |
2849 | ||
2850 | ||
2851 | ||
2852 | ||
2853 | ||
2854 | ||
2855 | ||
2856 | ||
2857 | ||
2858 | Orman Informational [Page 51] | |
2859 | \f | |
2860 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2861 | ||
2862 | ||
2863 | Appendix F Implementing Group Operations | |
2864 | ||
2865 | The group operation must be implemented as a sequence of arithmetic | |
2866 | operations; the exact operations depend on the type of group. For | |
2867 | modular exponentiation groups, the operation is multi-precision | |
2868 | integer multiplication and remainders by the group modulus. See | |
2869 | Knuth Vol. 2 [Knuth] for a discussion of how to implement these for | |
2870 | large integers. Implementation recommendations for elliptic curve | |
2871 | group operations over GF[2^N] are described in [Schroeppel]. | |
2872 | ||
2873 | ||
2874 | ||
2875 | ||
2876 | ||
2877 | ||
2878 | ||
2879 | ||
2880 | ||
2881 | ||
2882 | ||
2883 | ||
2884 | ||
2885 | ||
2886 | ||
2887 | ||
2888 | ||
2889 | ||
2890 | ||
2891 | ||
2892 | ||
2893 | ||
2894 | ||
2895 | ||
2896 | ||
2897 | ||
2898 | ||
2899 | ||
2900 | ||
2901 | ||
2902 | ||
2903 | ||
2904 | ||
2905 | ||
2906 | ||
2907 | ||
2908 | ||
2909 | ||
2910 | ||
2911 | ||
2912 | ||
2913 | ||
2914 | Orman Informational [Page 52] | |
2915 | \f | |
2916 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2917 | ||
2918 | ||
2919 | BIBLIOGRAPHY | |
2920 | ||
2921 | [RFC2401] Atkinson, R., "Security Architecture for the | |
2922 | Internet Protocol", RFC 2401, November 1998. | |
2923 | ||
2924 | [RFC2406] Atkinson, R., "IP Encapsulating Security Payload (ESP)", | |
2925 | RFC 2406, November 1998. | |
2926 | ||
2927 | [RFC2402] Atkinson, R., "IP Authentication Header", RFC 2402, | |
2928 | November 1998. | |
2929 | ||
2930 | [Blaze] Blaze, Matt et al., MINIMAL KEY LENGTHS FOR SYMMETRIC | |
2931 | CIPHERS TO PROVIDE ADEQUATE COMMERCIAL SECURITY. A | |
2932 | REPORT BY AN AD HOC GROUP OF CRYPTOGRAPHERS AND COMPUTER | |
2933 | SCIENTISTS... -- | |
2934 | http://www.bsa.org/policy/encryption/cryptographers.html | |
2935 | ||
2936 | [STS] W. Diffie, P.C. Van Oorschot, and M.J. Wiener, | |
2937 | "Authentication and Authenticated Key Exchanges," in | |
2938 | Designs, Codes and Cryptography, Kluwer Academic | |
2939 | Publishers, 1992, pp. 107 | |
2940 | ||
2941 | [SECDNS] Eastlake, D. and C. Kaufman, "Domain Name System | |
2942 | Security Extensions", RFC 2065, January 1997. | |
2943 | ||
2944 | [Random] Eastlake, D., Crocker, S. and J. Schiller, "Randomness | |
2945 | Recommendations for Security", RFC 1750, December 1994. | |
2946 | ||
2947 | [Kocher] Kocher, Paul, Timing Attack, | |
2948 | http://www.cryptography.com/timingattack.old/timingattack.html | |
2949 | ||
2950 | [Knuth] Knuth, Donald E., The Art of Computer Programming, Vol. | |
2951 | 2, Seminumerical Algorithms, Addison Wesley, 1969. | |
2952 | ||
2953 | [Krawcyzk] Krawcyzk, Hugo, SKEME: A Versatile Secure Key Exchange | |
2954 | Mechanism for Internet, ISOC Secure Networks and | |
2955 | Distributed Systems Symposium, San Diego, 1996 | |
2956 | ||
2957 | [Schneier] Schneier, Bruce, Applied cryptography: protocols, | |
2958 | algorithms, and source code in C, Second edition, John | |
2959 | Wiley & Sons, Inc. 1995, ISBN 0-471-12845-7, hardcover. | |
2960 | ISBN 0-471-11709-9, softcover. | |
2961 | ||
2962 | [Schroeppel] Schroeppel, Richard, et al.; Fast Key Exchange with | |
2963 | Elliptic Curve Systems, Crypto '95, Santa Barbara, 1995. | |
2964 | Available on-line as | |
2965 | ftp://ftp.cs.arizona.edu/reports/1995/TR95-03.ps (and | |
2966 | .Z). | |
2967 | ||
2968 | ||
2969 | ||
2970 | Orman Informational [Page 53] | |
2971 | \f | |
2972 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
2973 | ||
2974 | ||
2975 | [Stinson] Stinson, Douglas, Cryptography Theory and Practice. CRC | |
2976 | Press, Inc., 2000, Corporate Blvd., Boca Raton, FL, | |
2977 | 33431-9868, ISBN 0-8493-8521-0, 1995 | |
2978 | ||
2979 | [Zimmerman] Philip Zimmermann, The Official Pgp User's Guide, | |
2980 | Published by MIT Press Trade, Publication date: June | |
2981 | 1995, ISBN: 0262740176 | |
2982 | ||
2983 | ||
2984 | ||
2985 | ||
2986 | ||
2987 | ||
2988 | ||
2989 | ||
2990 | ||
2991 | ||
2992 | ||
2993 | ||
2994 | ||
2995 | ||
2996 | ||
2997 | ||
2998 | ||
2999 | ||
3000 | ||
3001 | ||
3002 | ||
3003 | ||
3004 | ||
3005 | ||
3006 | ||
3007 | ||
3008 | ||
3009 | ||
3010 | ||
3011 | ||
3012 | ||
3013 | ||
3014 | ||
3015 | ||
3016 | ||
3017 | ||
3018 | ||
3019 | ||
3020 | ||
3021 | ||
3022 | ||
3023 | ||
3024 | ||
3025 | ||
3026 | Orman Informational [Page 54] | |
3027 | \f | |
3028 | RFC 2412 The OAKLEY Key Determination Protocol November 1998 | |
3029 | ||
3030 | ||
3031 | Full Copyright Statement | |
3032 | ||
3033 | Copyright (C) The Internet Society (1998). All Rights Reserved. | |
3034 | ||
3035 | This document and translations of it may be copied and furnished to | |
3036 | others, and derivative works that comment on or otherwise explain it | |
3037 | or assist in its implementation may be prepared, copied, published | |
3038 | and distributed, in whole or in part, without restriction of any | |
3039 | kind, provided that the above copyright notice and this paragraph are | |
3040 | included on all such copies and derivative works. However, this | |
3041 | document itself may not be modified in any way, such as by removing | |
3042 | the copyright notice or references to the Internet Society or other | |
3043 | Internet organizations, except as needed for the purpose of | |
3044 | developing Internet standards in which case the procedures for | |
3045 | copyrights defined in the Internet Standards process must be | |
3046 | followed, or as required to translate it into languages other than | |
3047 | English. | |
3048 | ||
3049 | The limited permissions granted above are perpetual and will not be | |
3050 | revoked by the Internet Society or its successors or assigns. | |
3051 | ||
3052 | This document and the information contained herein is provided on an | |
3053 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
3054 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
3055 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
3056 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
3057 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
3058 | ||
3059 | ||
3060 | ||
3061 | ||
3062 | ||
3063 | ||
3064 | ||
3065 | ||
3066 | ||
3067 | ||
3068 | ||
3069 | ||
3070 | ||
3071 | ||
3072 | ||
3073 | ||
3074 | ||
3075 | ||
3076 | ||
3077 | ||
3078 | ||
3079 | ||
3080 | ||
3081 | ||
3082 | Orman Informational [Page 55] | |
3083 | \f |