idnits 2.17.00 (12 Aug 2021) /tmp/idnits46860/draft-ietf-ipsec-oakley-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 89 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 436: '... authentication MUST be completed bef...' RFC 2119 keyword, line 523: '...e-shared keys is REQUIRED. See Quick ...' RFC 2119 keyword, line 529: '... OPTIONAL....' RFC 2119 keyword, line 538: '... X.509. Support for this is OPTIONAL....' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1996) is 9591 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1825' on line 1221 looks like a reference -- Missing reference section? 'RFC1826' on line 52 looks like a reference -- Missing reference section? 'RFC1827' on line 52 looks like a reference -- Missing reference section? 'STS' on line 1225 looks like a reference -- Missing reference section? 'Photuris' on line 1233 looks like a reference -- Missing reference section? 'ISAKMP' on line 1245 looks like a reference -- Missing reference section? 'TBD' on line 157 looks like a reference -- Missing reference section? 'ISAKMP-03' on line 388 looks like a reference -- Missing reference section? 'Krawcyzk' on line 1238 looks like a reference -- Missing reference section? 'A' on line 459 looks like a reference -- Missing reference section? 'B' on line 460 looks like a reference -- Missing reference section? 'Nb' on line 455 looks like a reference -- Missing reference section? 'Na' on line 456 looks like a reference -- Missing reference section? 'Zimmerman' on line 1262 looks like a reference -- Missing reference section? 'SECDNS' on line 1230 looks like a reference -- Missing reference section? 'Kocher' on line 1236 looks like a reference -- Missing reference section? 'P' on line 834 looks like a reference -- Missing reference section? 'Blaze-Diffie-et-al' on line 1146 looks like a reference -- Missing reference section? 'Stinson' on line 1258 looks like a reference -- Missing reference section? 'Schneier' on line 1249 looks like a reference -- Missing reference section? 'Knuth' on line 1215 looks like a reference -- Missing reference section? 'Schroeppel' on line 1254 looks like a reference -- Missing reference section? 'Blaze' on line 1223 looks like a reference -- Missing reference section? 'DSS' on line 1228 looks like a reference -- Missing reference section? 'PKIX' on line 1241 looks like a reference -- Missing reference section? 'Random' on line 1243 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSEC Working Group H. K. Orman 2 INTERNET-DRAFT Dept. of Computer Science, Univ. of Arizona 3 draft-ietf-ipsec-oakley-00.txt February 1996 5 The Oakley Key Determination Protocol 6 8 This document describes a protocol, named OAKLEY, 9 by which two authenticated parties can agree on secure and secret 10 keying material. The basic mechanism is the Diffie-Hellman key 11 exchange algorithm. 13 This protocol supports Perfect Forward Secrecy, compatibility with 14 the ISAKMP protocol for managing security associations, user- 15 defined abstract group structures for use with the Diffie-Hellman 16 algorithm, key updates, and incorporation of keys distributed via 17 out-of-band mechanisms. 19 Status of this Memo 21 This document is being distributed to members of the Internet community in 22 order to solicit their comments on the protocol described in it. 24 This draft expires six months from the day of issue. The expiration 25 date will be August 24, 1996. 27 Required text: 29 This document is an Internet-Draft. Internet-Drafts are working 30 documents of the Internet Engineering Task Force (IETF), its 31 areas, and its working groups. Note that other groups may also 32 distribute working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other 36 documents at any time. It is inappropriate to use Internet- 37 Drafts as reference material or to cite them other than as ``work 38 in progress.'' 40 To learn the current status of any Internet-Draft, please check 41 the ``1id-abstracts.txt'' listing contained in the Internet- 42 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 43 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 44 Coast), or ftp.isi.edu (US West Coast). 46 Distribution of this memo is unlimited. 48 1. INTRODUCTION 50 Key establishment is the heart of data protection that relies on 51 cryptography, and it is an essential component of the packet 52 protection mechanisms described in [RFC1825, RFC1826, RFC1827], for 53 example. A scalable and secure key distribution mechanism for the 54 Internet is a necessity. The goal of this protocol is to provide 55 that mechanism, coupled with a great deal of cryptographic strength. 57 The Diffie-Hellman key exchange algorithm provides such a mechanism. 58 It allows two parties to agree on a shared value without requiring 59 encryption. The shared value is immediately available for use in 60 encrypting subsequent conversation, e.g. data transmission and/or 61 authentication. The STS protocol [STS] provides a demonstration of 62 how to embed the algorithm in a secure protocol, one that ensures 63 that in addition to securely sharing a secret, the two parties can be 64 sure of each other's identities, even when an active attacker exists. 66 Because this is a generic key exchange protocol, and because the keys 67 that it generates might be used for encrypting data with a long 68 privacy lifetime, 20 years or more, it is important that the 69 algorithms underlying the protocol be able to ensure the security of 70 the keys for that period of time, based on the best prediction 71 capabilities available for seeing into the mathematical future. The 72 protocol therefore has two options for adding to the difficulties 73 faced by an attacker who has a large amount of recorded key exchange 74 traffic at his disposal (a passive attacker). These options are 75 useful for deriving keys which will be used for encryption. 77 The OAKLEY protocol is related to STS, sharing the similarity of 78 doing key exchange first and encrypted authentication next, but it 79 extends the STS protocol in five ways. 81 The first is the addition of a weak authentication mechanism 82 ("cookies", described by Phil Karn [Photuris]) to help avoid 83 denial of service attacks. 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. 90 Thirdly, the protocol provides Perfect Forward Secrecy (PFS) in 91 its standard mode of operation; with PFS, the security of the 92 shared key against passive attacks is not dependent on other any 93 other secret. 95 This protocol adds additional security to the derivation of keys 96 meant for use with encryption (as opposed to authentication) by 97 including a dependence on an additional algorithm. The derivation 98 of keys for encryption is made to depend not only on the Diffie- 99 Hellman algorithm, but also on the cryptographic method used to 100 securely authenticate the communicating parties to each other. 102 Finally, this protocol explicitly defines how the two parties can 103 select the mathematical structures (group representation and 104 operation) for performing the Diffie-Hellman algorithm; they can 105 use standard groups or define their own. User-defined groups 106 provide an additional degree of long-term security. 108 OAKLEY has several modes for distributing keys. In addition to the 109 classic Diffie-Hellman exchange, this protocol has a mode of use for 110 deriving a new key from a pre-existing key, and a mode for 111 distributing an externally derived key by encrypting it. 113 This document draws extensively in spirit and approach from the 114 Photuris draft by Karn and Simpson [Photuris] (and from discussions 115 with the authors), specifics of the ISAKMP draft by Schertler et al. 116 [ISAKMP], and it was also influenced by papers by Paul van Oorschot 117 and Hugo Krawcyzk. 119 2. The Protocol Outline 121 2.1 General Remarks 123 The OAKLEY protocol is used to establish a shared key with an 124 assigned identifier and associated authenticated identities for the 125 two parties. Subsequent stages of the protocol may derive other keys 126 from a named key and assign an identifier to the new key. The name 127 of the key can be used later to derive security associations for the 128 RFC1826 and RFC1827 protocols (AH and ESP) or to achieve other 129 network security goals. 131 Each key is associated with algorithms that are used for 132 authentication, privacy, and one-way functions. These are anciliary 133 algorithms for OAKLEY; their appearance in subsequent security 134 association definitions derived with other protocols is neither 135 required nor prohibited. 137 The anti-clogging tokens, or "cookies", provide a weak form of 138 authentication for both parties; the cookie exchange can be completed 139 before they must perform the computationally expensive part of the 140 protocol (the exponentiations). 142 It is important to note that OAKLEY uses the cookies for two 143 purposes: anti-clogging and key naming. The two parties to the 144 protocol each contribute one cookie at the initiation of key 145 establishment; the pair of cookies becomes the key identifier 146 (KEYID), a reusable name for the keying material. Because of this 147 dual role, we will use the notation for the concatenation of the 148 cookies ("COOKIE-I, COOKIE-R") interchangeably with the symbol 149 "KEYID". 151 The only requirement for the protocol environment is that the 152 underlying protocol stack must be able to supply the Internet address 153 of the remote party for each message. Thus, OAKLEY can be used 154 directly over the IP protocol as protocol id [TBD] or over the UDP 155 protocol. In the latter case, the only addressing requirement is 156 that protocol exchanges be initiated by using the OAKLEY well-known 157 port [TBD] in the destination address. 159 The machine running OAKLEY must provide a good random number 160 generator, as described in RFCxxxx, as the source of random numbers 161 required in this protocol description. Any mention of a "nonce" 162 implies that the nonce value is generated by such a generator. 164 2.2 Notation 166 The section describes the notation used in this document for message 167 sequences and content. 169 2.2.1 Message descriptions 171 The protocol exchanges below are written in an abbreviated notation 172 that is intended to convey the essential elements of the exchange in 173 a clear manner. A brief guide to the notation follows. The detailed 174 formats and assigned values are given in the appendices. 176 In order to represent message exchanges succinctly, this document 177 uses an abbreviated notation that describes each message in terms of 178 its source and destination and relevant fields. 180 Arrows ("->") indicate whether the message sent from the initiator to 181 the responder, or vice versa ("<-"). 183 The fields in the message are named and comma separated. The 184 protocol uses the convention that the first several fields constitute 185 a fixed header format for all messages. 187 For example, consider a HYPOTHETICAL exchange of messages involving a 188 fixed format message, the four fixed fields being two "cookies", the 189 third field being a message type name, the fourth field being a 190 multi-precision integer representing a power of a number: 192 Initiator Responder 193 -> Cookie-I, 0, IREQ, g^x -> 194 <- Cookie-R, Cookie-I, IRES, g^y <- 196 The notation describes a two message sequence. The initiator begins 197 by sending a message with 4 fields to the responder; the first field 198 has the unspecified value "Cookie-I", second field has the numeric 199 value 0, the third field indicates the message type is IREQ, the 200 fourth value is an abstract group element g to the x'th power. 202 The second line indicates that the responder replies with value 203 "Cookie-R" in the first field, a copy of the "Cookie-I" value in the 204 second field, message type IRES, and the number g raised to the y'th 205 power. 207 The values IRES and IREQ are in capitals to indicate that they are 208 unique constants (constants are defined the appendices). 210 2.2.2 Guide to symbols 212 Cookie-I and Cookie-R are 64-bit pseudo-random numbers. The 213 generation method must ensure with high probability that the numbers 214 are unique over some previous time period, such as one hour. 216 DOI is the Domain of Interpretation; see appendix I. The domains are 217 statically assigned numbers that indicate classes of cryptographic 218 service -- particularly the strength of the algorithm. 220 KEYID is the concatenation of the initiator and responder cookies and 221 the domain of interpretation; it is the name of keying material. 223 sKEYID is used to denote the keying material named by the KEYID. It 224 is never transmitted, but it is used in various calculations 225 performed by the two parties. 227 IREQ, IREP, IKERQ, and IKERS are distinct message identifiers. 229 Auth/Priv (or A/P) is the encoded choice for the intended use of the 230 keying material; either authentication or privacy. 232 g^x and g^y are encodings of group elements, where g is a special 233 group element indicated in the group description (see Appendix Group 234 Descriptors) and g^x indicates that element raised to the x'th power. 235 The type of the encoding is either a variable precision integer or a 236 pair of such integers, as indicated in the group operation in the 237 group description. Note that we will write g^xy as a short-hand for 238 g^(xy). See Appenix J for references that describe implementing 239 large integer computations and the relationship between various group 240 definitions and basic arithmetic operations. 242 EHAO is a list of encryption/hash/authentication choices. Each item 243 is a pair values: a class name and an algorithm name. 245 EHAS is a set of three items selected from the EHAO list, one from 246 each of the classes for encryption, hash, authentication. 248 GRP is a name for the group and its relevant parameters: the size of 249 the integers, the arithmetic operation, and the generator element. 250 There are a few pre-defined GRP's (for 768 bit modular exponentiation 251 groups, 1024 bit modexp, 2048 bit modexp, 155-bit elliptic curve, see 252 Appendix H), but participants can share other group descriptions in a 253 later protocol stage (see the section NEW GROUP). 255 The symbol vertical bar "|" is used to denote concatenation of bit 256 strings. 258 2.3 Main Mode 260 The goal of Main Mode processing is to establish common state in the 261 two parties. This state information is a key name, secret keying 262 material, and three algorithms for use during authentication: 264 encryption, hashing, and authentication. The encodings and meanings 265 for these choices are presented in an Appendix. 267 Main Mode processing is always followed by Authentication, as 268 described in the Authentication Exchange section. However, see also 269 the section on use of Main Mode with private group definitions. 271 Initiator Responder 272 -> Cookie-I, 0, DOI, IREQ, A/P, GRP, EHAO -> 273 <- Cookie-R, Cookie-I, DOI, IKREQ, A/P, g^y, EHAS <- 274 -> Cookie-I, Cookie-R, DOI, IKRES, g^x -> 276 The processing outline for each stage of the protocol is as follows: 278 Initiation 279 The initiator generates a unique cookie and associates it with the 280 expected IP address of the responder, and its chosen state 281 information: DOI, Auth/Priv, GRP, EHAO list, 283 notes that the key is in the initial state of "unauthenticated", 284 and 286 sets a timer for possible retransmission and/or termination of the 287 request. 289 The responder receives IREQ and does the following: 290 Generates a unique cookie, Cookie-R, 292 associates the triple (Cookie-I, Cookie-R, DOI) with the Auth/Priv 293 choice, the group GRP and the IP address of the responder, and 295 puts the network address of the message into the state and, 297 notes that the key is in the initial state of "unauthenticated", 298 and 300 selects one algorithm from each class in the EHAO (encryption- 301 hash-authentication algorithm offers) list, and 303 selects a g^y value and associates it with the current state, and 305 sets a timer for possible retransmission, and 307 sends the IKREQ message. 309 The initiator receives the IKREQ message and 310 validates that Cookie-I is a valid association for the network 311 address of the incoming message, 313 adds the Cookie-R value to the state for the pair (Cookie-I, 314 network address), and associates all state information with the 315 pair (Cookie-I, Cookie-R DOI), 316 adds g^y to its state information, 318 chooses an exponent x and corresponding g^x value, 320 saves the EHA selections in the state, 322 computes (g^x)^y (= g^xy) at this point, or 324 sends the IKRES message. 326 The responder receives the IKRES message and 327 validates the Cookie pair against the network address for the 328 incoming messages, 330 computes (g^y)^x (= g^yx = g^xy). 332 The responder can upgrade the initiator's A/P choice from 333 Authentication to Privacy; the initiator must cooperate. 335 If privacy is a requirement, then encryption in the algorithm 336 indicated by the EHA class will affect subsequent messages of the 337 exchange. The cookies and message type word will be the only non- 338 encrypted part of those messages (see Appendix Message Formats for 339 the encryption boundary). 341 Note that the Initiator must and Responder must agree on one set of 342 EHA algorithms; there is not one set for the Responder and one for 343 the Initiator. The Initiator must include at least MD5 and DES in 344 the initial offer. 346 Both parties compute the shared key material sKEYID as 347 hash(g^xy | Cookie-I | Cookie-R) 348 where "hash" is the algorithm in class "hash" selected in the EHA 349 list. 351 The initiator considers the ability of the responder to repeat 352 Cookie-I as weak evidence that the message originates from a "live" 353 correspondent on the network and the correspondent is associated with 354 the responder's network address. The responder makes similar 355 assumptions when Cookie-R is repeated to the responder. All messages 356 except IREQ messages must have valid cookies; information in 357 violating messages cannot be used for any OAKLEY operations. 359 2.3.1 Retransmission, Timeouts, and Error Messages 361 Retransmissions due to failure to elicit an expected response in the 362 appropriate time interval must be handled gracefully by both parties. 364 Either party may destroy the current state and optionally send an 365 error message at any point in the protocol. 367 The responder can explicitly reject the initial request for several 368 reasons: no support for a well-known but optional group, a malformed 369 EHA list, or a temporary lack of resources, for example. The exact 370 format for error messages is TBD. 372 2.3.2 ISAKMP Compatibility 374 In addition to Main Mode, this document describes three other key 375 determination methods. Each method is intended to constitute a Key 376 Exchange Interface (KEI) that could be used with ISAKMP; each method 377 also constitutes a protocol that could be used independently from 378 ISAKMP. 380 The next method is described in order to establish an exact 381 correspondence with the initial processing of ISAKMP in draft 03; the 382 cookie exchange and the g^x exchanges are done as separate steps. 383 This orthogonality may be desirable to some implementors, and it is 384 thus included as a required OAKLEY mode. 386 2.3.2.1 ISAKMP Cookie/KE Mode 388 The ISAKMP protocol draft [ISAKMP-03] separates the cookie exchange 389 entirely from the exchange of group elements. This is also allowable 390 in OAKLEY. The following table illustrates the message sequence and 391 fields roughly as described in ISAKMP-03. This sequence uses 392 notation from the ISAKMP-03 draft and is included for merely to 393 illustrate how Oakley and ISAKMP can be closely related to each 394 other. A fuller treatment will appear later. 396 Initiator Responder 397 --------- ---------- 398 -> Cookie-I, 0, IREQI, SPI-I -> 399 <- Cookie-R, Cookie-I, IRESI, SPI-R <- 400 -> Cookie-I, Cookie-R, IKREQI, SPI-I, g^x, EHAO -> 401 <- Cookie-R, Cookie-I, IKRESI, SPI-R, g^y, EHAS <- 403 For compatibility with ISAKMP, the following message type value 404 equivalences are required: 405 IREQI == ISA_INIT_REQ 406 IRESI == ISA_INIT_RESP 407 IKREQI == ISA_KE_REQ 408 IKRESI == ISA_KE_RESP 409 Note that the ISAKMP version 3 uses the GRPID field for a SPI field. 410 Appendix C shows the correspondence of fields. 412 Fields that are not mentioned in the message summaries above are must 413 contain the value zero. 415 2.4 Authentication 417 After the shared keying material and its identifier are established 418 in Main Mode, the two parties must establish their identities to each 419 other. The keying material cannot be used for any trusted purpose 420 until the authentication is completed. If the purpose of the keying 421 material is for encryption, then the identities of the initiator and 422 responder will be hidden by encrypting the messages using the 423 algorithm selected from the encryption clas in the EHAO list. 425 The authentication exchange not only hides the identities of the two 426 parties, but it also avoids using public key technology that would 427 provide a proof, verifiable by a third party, of communication 428 between the initiator and responder. This technique and its 429 justification are due to [Krawcyzk]. 431 2.4.1 The Authentication Exchange 433 The Authentication Exchange should be initiated after Main Mode. The 434 purpose of it is to change the state of KEYID from Unauthenticated to 435 Authenticated. When using Main Mode with a well-known group, The 436 authentication MUST be completed before using the keying material for 437 any purpose, other than described in this section. 439 The authentication sequence binds the identities of the two parties 440 to the KEYID. However, for most authentication methods, there will 441 be two further steps: retrieving the material that describes the 442 binding between the identity and a public key (e.g. a certificate), 443 and validating that material (e.g. verifying the signature of the 444 certifying authority). This section describes the binding to the 445 KEYID; subsequent sections discuss the formats for the descriptive 446 material and the retrieval methods. 448 The Authentication Exchange is carried out in the following classic 449 Needham-Schroeder style: 451 Initiator Responder 452 --------- ---------- 453 -> KEYID, IAUTH_REQ, ID[A] -> 454 <- KEYID, IAUTH_RES, ID[B], ID[A], 455 E[Nb]KA, hash(sKEYID | Nb | ID[A] | ID[B]) <- 456 -> KEYID, IAUTH_PRF, E[Na]KB, hash(sKEYID | Na | Nb | ID[A],ID[B]) -> 457 <- KEYID, IAUTH_PRF_R, hash(sKEYID | Nb | Na | ID[B] | ID[A]) <- 459 The symbol ID[A] means the encoding of the identity of the initiator, 460 the symbol ID[B] is for the responder. See the next section for a 461 discussion of the encoding of the identities. 463 The notation E[Nb]KA means the encryption of the nonce supplied by 464 the responder encrypted using the key belonging to the initiator. 465 When public key technology is used for authentication, this 466 encryption is done using the public key encryption algorithm. If 467 symmetric keys are used, the encryption is done in the symmetric 468 algorithm. 470 The encryption of the nonces is carried out in addition to the 471 encryption described next. The nonce encryption is used to validate 472 identities; the privacy encryption is to prevent disclosure of the 473 purported identities of the two parties. 475 If the Auth/Priv type of KEYID is Privacy, then these messages are 476 encrypted using the algorithm implied by the KEYID. The encryption 477 boundary is shown in Appendix C. The KEYID and Message Type word are 478 in cleartext. 480 The encryption of the nonces Na and Nb is done with the privacy 481 algorithm established for the keyid. The key used in the encryption 482 varies, depending on the authentication type selected during the Main 483 Mode. If pre-shared keys are used, then the encryption is done with 484 the pre-shared key. If public keys are used, then the public key of 485 the opposite party is used. 487 As with the cookies, each party considers the ability of the remote 488 side to repeat the Na or Nb value as a proof that Ki, the public key 489 of party i, speaks for the remote party and establishes its identity. 491 After the Authentication Exchange is complete, the state of the KEYID 492 is changed from Unauthenticated to Authenticated, and the keying 493 material is ready for use. 495 2.4.1.1 Extra Strength for Protection of Encryption Keys 497 If the Auth/Priv type associated with KEYID is Privacy, then after 498 the authentication exchange is complete, the nonces Na and Nb are 499 used to provide an extra dimension of secrecy in deriving session 500 keys. They are used as input to a hash function that derives the 501 keying material: 503 sKEYID <- hash(sKEYID | Na | Nb) 505 This makes the secrecy of the key depend on two different problems: 506 the discrete logarithm problem in the group G, and the problem of 507 breaking the nonce encryption scheme. If RSA encryption is used, 508 then this second problem is roughly equivalent to factoring the RSA 509 public keys of both the initiator and responder. 511 2.4.2 Formats of Identity Data Structures 513 At this time, there is no commonly accepted basis for determining 514 identities on the Internet, so the protocol must maintain room for 515 flexibility on this point. There will be the following 516 possibilities: 518 a. Pre-shared symmetric keys 519 Each pair of parties has arranged for a trusted method of 520 distributing secret keys for their mutual authentication. This 521 has obvious scaling problems for large systems, but it is an 522 acceptable interim solution for some situations. Support for 523 pre-shared keys is REQUIRED. See Quick Mode. 525 b. RSA public keys w/o certification authority signature 526 PGP [Zimmerman] uses public keys with an informal method for 527 establishing trust. The format of PGP public keys and naming 528 methods is described in Appendix PGP. Support for this is 529 OPTIONAL. 531 c. RSA public keys w/ certificates 532 There are various formats and naming conventions for public keys 533 that are signed by one or more certification authorities. The 534 Public Key Interchange Protocol discusses X.509 encodings and 535 validation. 537 i. The format for X.509 OAKLEY certificates is described in 538 Appendix X.509. Support for this is OPTIONAL. 540 d. DSS keys w/ certificates 541 Encoding for the Digital Signature Standard is described in 542 Appendix H and in internet-draft-dss-00.txt. 544 2.4.2 Validating Identity Data Structures 546 The combination of the Authentication algorithm defines how to 547 interpret the identity, its certificate, and the preferred method for 548 fetching the cerificate if it is not included as part of the identity 549 in the authentication exchange. 551 Once the certificate is obtained (see 2.4.3), the validation method 552 will depend on the Authentication algorithm; if it is PGP then the 553 PGP signature validation routines can be called to satisfy the local 554 web-of-trust predicates; if it is RSA with X.509 certificates, the 555 certificate must be examined to see if the certification authority 556 signature can be validated, and if the hierarchy is recognized by the 557 local policy. 559 At this time there is no required format or validation method. 561 2.4.3 Fetching Identity Objects 563 In addition to interpreting the certificate or other data structure 564 that contains an identity, users of OAKLEY must face the task of 565 retrieving certificates that bind a public key to an identifier and 566 also retrieving auxiliary certificates for certifying authorities or 567 co-signers (as in the PGP web of trust). 569 The retrieval method will be specified via an implicit attribute of 570 the Auth class name. 572 Support for accessing and revoking public key certificates via the 573 Secure DNS protocol [SECDNS] is MANDATORY for Oakley implementations. 575 Other retrieval methods can be used when the AUTH class indicates a 576 preference. 578 The Public Key Interchange Protocol discusses a full protocol that 579 might be used with X.509 encoded certificates. 581 2.5 Additional Security for Privacy Keys: Private Groups 583 If the two parties have need to use a Diffie-Hellman key 584 determination scheme that does not depend on the standard group 585 definitions, they have the option of establishing a private group. 586 The authentication need not be repeated, because this stage of the 587 protocol will be protected by encryption. As an extra security 588 measure, the two parties will establish a private name for the shared 589 keying material, so even if they use exactly the same group to 590 communicate with other parties, the re-use will not be apparent to 591 passive attackers. 593 Private groups have the advantage of making a widespread passive 594 attack much harder by increasing the number of groups that would have 595 to be exhaustively analyzed in order to recover a large number of 596 session keys. This contrasts with the case when only one or two 597 groups are ever used; in that case, one would expect that years and 598 years of session keys would be compromised. 600 There are two technical challenges to face: how can a particular user 601 create a unique and appropriate group, and how can a second party 602 assure himself that the proposed group is reasonably secure? 604 The security of a modular exponentiation group depends on the largest 605 prime factor of the group size. In order to maximize this, one can 606 choose "strong" or Sophie-Germaine primes, P = 2Q + 1, where P and Q 607 are prime. However, if P = kQ + 1, where k is small, then the 608 strength of the group is still considerable. These groups are known 609 as Schnorr subgroups, and they can be found with much less 610 computational effort than Sophie-Germaine primes. 612 Schnorr subgroups can also be validated efficiently by using probable 613 prime tests. 615 It is also fairly easy to find P, k, and Q such that the largest 616 prime factor can be easily proven to be Q. 618 We estimate that it would take about 10 minutes to find a new group 619 of about 2^1024 elements, and this could be done once a day by a 620 scheduled process; validating a group proposed by a remote party 621 would take perhaps a minute on a 25 MHz RISC machine or a 66 MHz CISC 622 machine. 624 We note that validation is done only between previously mutually 625 authenticated parties, and that a new group definition always follows 626 and is protected by a key established using a well-known group. 627 There are four points to keep in mind: 629 a. The description and public identifier for the new group are 630 protected by the well-known group. 632 b. The responder can reject the attempt to establish the new 633 group, either because he is too busy or because he cannot validate 634 the largest prime factor as being sufficiently large. 636 c. The new modulus and generator can be cached for long periods of 637 time; they are not security critical and need not be associated 638 with ongoing activity. 640 d. Generating a new g^x value periodically will be more expensive 641 if there are many groups cached; however, the importance of 642 frequently generating new g^x values is reduced, so the time 643 period can be lengthened correspondingly. 645 2.5.1 Defining a New Group 646 This section describes how to define a new group. The description of 647 the group is hidden from eavesdroppers, and the identifier assigned 648 to the group is unique to the two parties. Use of the new group for 649 Diffie-Hellman key exchanges is described in the next section. 651 The secrecy of the description and the identifier increases the 652 difficulty of a passive attack, because if the group descriptor is 653 not known to the attacker, there is no straightforward and efficient 654 way to gain information about keys calculated using the group. 656 Only the description of the new group need be encrypted in this 657 exchange. The hash algorithm is implied by the OAKLEY session named 658 by the group. The encryption is the authentication encryption 659 function of the OAKLEY session. 661 To define a new modular exponentiation group: 662 Initiator Responder 663 --------- ---------- 664 -> KEYID, -> 665 INEWGRP, 666 E[Desc(New Group), Na]Kb, 667 hash(Desc(New Group) | Na) 669 <- KEYID, 670 INEWGRPRS, 671 E[Nb, Na]Ka, 672 hash(Na | Nb | Desc(New Group)) <- 674 -> KEYID, 675 INEWGRPACK 676 hash( Nb | Na | Desc(New Group)) -> 678 These messages are encrypted at the encryption boundary using the key 679 indicated. The hash value is placed in the "digital signature" field 680 (see Appendix C). 682 INEWGRP, INEWGRPRS, INEWGRPACK are distinct message identifiers 684 Kb is the authentication key for B 686 Ka is the authentication key for A 688 These keys are derived during the authentication phase and are 689 part of the state associated with the OAKLEY session named by the 690 cookies. 692 E[x]Ka indicates encryption of x using the initiator's key; Kb 693 indicates the responder's key (if the encryption algorithm is 694 symmetric one the keys will be identical). 696 If Ka and Kb are public keys, then encryption will use the 697 algorithm implied by the public key scheme, i.e., RSA encryption 698 for RSA public keys. 700 New GRP identifier = Na | Nb (the initiator and responder must use 701 nonces that are distinct from any cookies used for current 702 KEYID's; i.e., the initiator ensures that Na is distinct from any 703 Cookie-I, the responder ensures that Nb is distinct from any 704 Cookie-R). 706 Desc(G) is the encoding of the descriptor for the group descriptor 707 (see Appendix A for the format of a group descriptor) 709 The two parties must store the mapping between the new group 710 identifier GRP and the group descriptor Desc(New Group). They must 711 also note the identities used for the KEYID and copy these to the 712 state for the new group. 714 Note that one could have the same group descriptor associated with 715 several KEYID's. Pre-calculation of g^x values may be done based 716 only on the group descriptor, not the private group name. 718 2.6 Deriving a Key Using a Private Group 720 Once a private group has been established, its group id can be used 721 in Main Mode (or ISAKMP mode) to derive new keying material. 723 The authentication exchange is unnecessary, because the new group 724 establishment was done using an authenticated key. The identities 725 used in that exchange must be carried over to new key. 727 2.7 Quick Mode: New Keys From Old 729 When an authenticated KEYID and associated keying material sKEYID 730 already exist, it is easy to derive additional KEYID's and keys, 731 using only hashing functions. The KEYID might be one that was 732 derived in Main Mode, for example. 734 On the other hand, the authenticated key may be a manually 735 distributed key, one that is shared by the initiator and responder 736 via some means external to OAKLEY. If the the distribution method 737 has formed the KEYID using appropriately unique values for the two 738 halves (Cookie-I and Cookie-R), then this method is applicable. 740 The protocol is: 742 Initiator Responder 743 --------- --------- 744 -> KEYID, INEWKRQ, Na, hash(Na, sKEYID) -> 745 <- KEYID, INEWKRS, Nb, hash(1 | Na | Nb | sKEYID) <- 746 -> KEYID, INEWKRP, 0, hash(1 | Nb | Na | sKEYID) -> 748 The New KEYID, NKEYID, is NonceA | NonceB 750 sNKEYID = hash(sKEYID, Na, Nb) 752 The identities associated with NKEYID are the same as those 753 associated with KEYID. 755 Each party must validate the hash values before changing any state 756 information associated with keys. 758 2.8 Distribution of an External Key 759 Once an OAKLEY session key and anciliary algorithms are established, 760 the keying material and the encryption algorithm can be used to 761 distribute an externally generated key and to assign a KEYID to it. 763 In the following, KEYID represents an existing, authenticated OAKLEY 764 session key, and sNEWKEYID represents the externally generated keying 765 material. Only the first two fields of each message are plaintext, 766 the rest is encrypted using the encryption algorithm associated with 767 the KEYID state. 769 Initiator Responder 770 --------- --------- 771 -> KEYID, INEWEXTKEY, Na, sNEWKEYID -> 772 <- KEYID, INEWEXTKEYRQ, Nb, hash(Nb, Na, sNEWKEYID) <- 773 -> KEYID, INEWEXTKEYRS, hash(Na, Nb, sNEWKEYID) -> 775 Each party must validate the hash values using the hash function in 776 the KEYID state before changing any key state information. 778 The new key identifier, naming the keying material sNEWKEYID, is 779 hash( 1 | Na | Nb). 781 2.7.1 Retransmissions, Timeouts, and Error Messages 783 TBD 785 2.8.2 Cryptographic Strength Considerations 786 The strength of the key used to distribute the external key must be 787 at least equal to the strength of the external key. Generally, this 788 means that the length of the sKEYID material must be greater than or 789 equal to the length of the sNEWKEYID material. 791 The derivation of the external key, its strength or intended use are 792 not addressed by this protocol; the parties using the key must have 793 some other method for determining these properties. 795 3. Specifying and Deriving Security Associations 797 When a security association is defined, only the KEYID need be given. 798 The responder should be able to look up the state associated with the 799 KEYID value and find the appropriate keying material, sKEYID. 801 The OAKLEY protocol does not define security association encodings or 802 message formats. These can be defined through a protocol such as 803 ISAKMP. Compatibility with ISAKMP is a goal of the OAKLEY design, 804 and coordination of the message formats and use of identifiers is an 805 ongoing activity at this time. 807 4. Security Implementation Notes 809 Timing attacks that are capable of recovering the exponent value used 810 in Diffie-Hellman calculations have been described by Paul Kocher 811 [Kocher]. In order to nullify the attack, implementors must take 812 pains to obscure the sequence of operations involved in carrying out 813 modular exponentiations. 815 A "blinding factor" can accomplish this goal. A group element, r, is 816 chosen at random. When an exponent x is chosen, the value r^(-x) is 817 also calculated. Then, when calculating (g^y)^x, the implementation 818 will calculate this sequence: 820 A = (rg^y) 821 B = A^x = (rg^y)^x = (r^x)(g^(xy)) 822 C = B*r^(-x) = (r^x)(r^-(x))(g^(xy)) = g^(xy) 824 The blinding factor is only necessary if the exponent x is used more 825 than 100 times (estimate by Richard Schroeppel). 827 APPENDIX A Group Descriptors 829 Three distinct group representations can be used with OAKLEY. Each 830 group is defined by its group operation and the kind of underlying 831 field used to represent group elements. The three types are modular 832 exponentiation groups (named MODP herein), elliptic curve groups 833 over the field GF[2^N] (named EC2N herein), and elliptic curve groups 834 over GF[P] (named ECP herein) For each representation, many distinct 835 realizations are possible, depending on parameter selection. 837 With a few exceptions, all the parameters are transmitted as if they 838 were non-negative multi-precision integers, using the format defined 839 in this appendix (note, this is distinct from the encoding in Appendix 840 D). Every multi-precision integer has a prefixed length field, even 841 where this information is redundant. 843 For the group type EC2N, the parameters are more properly thought of 844 as very long bit fields, but they are represented as multi-precision 845 integers, (with length fields, and right-justified). This is the 846 natural encoding. 848 MODP means the classical modular exponentiation group, where the 849 operation is to calculate G^X (mod P). The group is defined by 850 the numeric parameters P and G. P must be a prime. G is often 2, 851 but may be a larger number. 2 <= G <= P-2. 853 ECP is an elliptic curve group, modulo a prime number P. 854 The defining equation for this kind of group is 855 Y^2 = X^3 + AX + B 856 The group operation is taking a multiple of an elliptic-curve point. 857 The group is defined by 5 numeric parameters: The prime P, two curve 858 parameters A and B, and a generator (X,Y). A,B,X,Y are all 859 interpreted mod P, and must be (non-negative) integers less than P. 860 They must satisfy the defining equation, modulo P. 862 EC2N is an elliptic curve group, over the finite field F[2^N]. The 863 defining equation for this kind of group is 864 Y^2 + XY = X^3 + AX^2 + B 865 (This equation differs slightly from the mod P case: it has an XY 866 term, and an AX^2 term instead of an AX term.) 868 We must specify the field representation, and then the elliptic 869 curve. The field is specified by giving an irreducible polynomial 870 (mod 2) of degree N. This polynomial is represented as an integer of 871 size between 2^N and 2^(N+1), as if the defining polynomial were 872 evaluated at the value U=2. 874 For example, the field defined by the polynomial 875 U^155 + U^62 + 1 876 is represented by the integer 2^155 + 2^62 + 1. The group is defined 877 by 4 more parameters, A,B,X,Y. These parameters are elements of the 878 field F[2^N], and can be though of as polynomials of degree < N, with 879 (mod 2) coefficients. They fit in N-bit fields, and are represented 880 as integers < 2^N, as if the polynomial were evaluated at U=2. For 881 example, the field element U^2 + 1 would be represented by the 882 integer 2^2+1, which is 5. The two parameters A and B define the 883 curve. A is frequently 0. B must not be 0. The parameters X and Y 884 select a point on the curve. The parameters A,B,X,Y must satisfy the 885 defining equation, modulo the defining polynomial, and mod 2. 887 Group descriptor formats: .sp. nf Type of group: A two-byte field, 888 assigned values for the types "MODP", "ECP", "EC2N" 889 will be defined (see ISAKMP-04). Size of a field element, in 890 bits. This is either Ceiling(log2 P) 891 or the degree of the irreducible polynomial: a 32-bit integer. 892 The prime P or the irreducible field polynomial: a multi-precision 893 integer. The generator: 1 or 2 values, multi-precision integers. EC 894 only: The parameters of the curve: 2 values, multi-precision 895 integers. 896 The following parameters are Optional (each of these may appear 897 independently): 898 a value of 0 may be used as a place-holder to represent an 899 unspecified 900 parameter; any number of the parameters may be sent, from 0 to 3. 902 The largest prime factor: the encoded value that is the LPF of the 903 group size, 904 a multi-precision integer. 906 EC only: The order of the group: multi-precision integer. 907 (The group size for MODP is always P-1.) 909 Strength of group: 32-bit integer. 910 The strength of the group is approximately the number of key-bits 911 protected. 912 It is determined by the log2 of the effort to attack the group. 913 It may change as we learn more about cryptography. 915 This is a generic example for a "classic" modular exponentiation 916 group: 917 Group type: "MODP" 918 Size of a field element in bits: Log2 (P) rounded *up*. A 32bit integer. 919 Defining prime P: a multi-precision integer. 920 Generator G: a multi-precision integer. 2 <= G <= P-2. 921 922 Largest prime factor of P-1: the multi-precision integer Q 923 Strength of group: a 32-bit integer. We will specify a formula 924 for calculating this number (TBD). 926 This is a generic example for elliptic curve group, mod P: 927 Group type: "ECP" 928 Size of a field element in bits: Log2 (P) rounded *up*, 929 a 32 bit integer. 930 Defining prime P: a multi-precision integer. 931 Generator (X,Y): 2 multi-precision integers, each < P. 932 Parameters of the curve A,B: 2 multi-precision integers, each < P. 934 935 Largest prime factor of the group order: a multi-precision integer. 936 Order of the group: a multi-precision integer. 937 Strength of group: a 32-bit integer. Formula TBD. 939 This is a specific example for elliptic curve group: 940 Group type: "EC2N" 941 Degree of the irreducible polynomial: 155 942 Irreducible polynomial: U^155 + U^62 + 1, represented as the 943 multi-precision integer 2^155 + 2^62 + 1. 944 Generator (X,Y) : represented as 2 multi-precision integers, each < 2^155. 945 For our present curve, these are (decimal) 123 and 456. Each is represented 946 as a multi-precision integer. 947 Parameters of the curve A,B: represented as 2 multi-precision 948 integers, each < 2^155. 949 For our present curve these are 0 and (decimal) 471951, represented as two 950 multi-precision integers. 952 953 Largest prime factor of the group order: 955 3805993847215893016155463826195386266397436443, 957 represented as a multi-precision integer. 958 The order of the group: 960 45671926166590716193865565914344635196769237316 962 represented as a multi-precision integer. 964 Strength of group: 76, represented as a 32-bit integer. 966 The variable precision integer encoding for group descriptor fields 967 is the following. This is a slight variation on the format defined 968 in Appendix D in that a fixed 16-bit value is used first, and the 969 length is limited to 16 bits. However, the interpretation is 970 otherwise identical. 972 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 ! Fixed value (TBD) ! Length ! 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 . . 978 . Integer . 979 . . 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 APPENDIX B New Group Definition 984 TBD 985 APPENDIX C Message format 987 1. Message format template 989 The following message format is meant to be compatible with ISAKMP 990 formats. Any anomalies will be resolved by ongoing coordination 991 activities. 993 1 2 3 994 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 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 ! ! 997 ~ Initiator-Cookie ~ 998 / ! ! 999 KEYID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 \ ! ! 1001 ~ Responder-Cookie ~ 1002 ! ! 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 ! Domain of Interpretation ! 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 ! Message Type ! Exch ! Vers ! Length ! 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 ! Group ID (or SPI) ! 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 ! SPI (unused) ! 1011 eeee +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ eeee 1012 ! ! 1013 ~ Identification ~ 1014 ! ! 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 ! ! 1017 ~ Payload ~ 1018 ! ! 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 ! ! 1021 ~ Digital Signature ~ 1022 ! ! 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 ! ! 1025 ~ Padding ~ 1026 ! ! 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 "eeee" represents the encryption boundary for messages requiring privacy. 1031 The Group ID field is used for the group identifier for the key 1032 exchange methods described in this document; in other ISAKMP messages 1033 the field is used for a SPI. 1035 The second SPI field is not used in OAKLEY. It must contain the 1036 value zero. 1038 2. Message Types 1040 The following indicates the constant values for message types. These 1041 will be assigned unique values, although the values are TBD at the 1042 time of this writing. 1044 IREQ 1045 IKREQ 1046 IKREP 1047 IAUTH_REQ 1048 IAUTH_REP 1049 IAUTH_PRF 1050 IAUTH_PRF_R 1051 INEWGRP 1052 INEWGRRS 1053 INEWGRPACK 1054 INEWKRQ 1055 INEWKRS 1056 INEWKRP 1057 INEWEXTKEY 1058 INEWEXTKEYRQ 1059 INEWEXTKEYRS 1061 Related ISAKMP types 1062 ISA_INIT_REQ 1063 ISA_INIT_RESP 1064 ISA_AUTH&KE_REQ 1065 ISA_AUTH&KE_RESP 1066 ISA_NEW_GROUP_REQ (recommended addition) 1067 ISA_NEW_GROUP_RESP (recommended addition) 1069 3. Payload 1071 The Payload section will carry the g^x values, encoded as variable 1072 precision integers. 1074 3.1 Generic List Exchange Format for Encryption/Hash/Authentication 1075 Up to three attribute classes, each followed by a count and a list of 1076 algorithms. The encoding is as in ISAKMP: 1078 a list of pairs, each one indicating its mode of use 1079 (encryption or hashing), and the algorithm type. 1080 The length of the list is indicated by the count field. 1082 1 2 3 1084 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 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 ! Attribute Class ! Count ! 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 ! Attribute Type ! Attribute Type ! 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 ~ ~ 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 ! Attribute Type ! Attribute Type ! 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 4. Identification 1097 The Identification section will carry the values indicated by "ID" in 1098 the text of this document. 1100 5. Digital Signature 1102 The Digital Signature section will carry the values indicated by 1103 "hash" in the text of this document. 1105 APPENDIX D Encoding a variable precision integer. 1107 Variable precision integers will be encoded as a 32-bit length field 1108 followed by one or more 32-bit quantities containing the 1109 representation of the integer, aligned with the most significant bit 1110 in the first 32-bit item. 1112 1 2 3 1113 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 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 ! length ! 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 ! first value word (most significant bits) ! 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 ! ! 1120 ~ additional value words ~ 1121 ! ! 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 An example of such an encoding is given below, for a number with 51 1125 bits of significance. The length field indicates that 2 32-bit 1126 quantities follow. The most significant non-zero bit of the number 1127 is in bit 13 of the first 32-bit quantity, the low order bits are in 1128 the second 32-bit quantity. 1130 1 2 3 1131 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 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 ! 1 0! 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 !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! 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 !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! 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 APPENDIX E Cryptographic strengths 1142 The Diffie-Hellman algorithm is used to compute keys that will be 1143 used with symmetric algorithms. It should be no easier to break the 1144 Diffie-Hellman computation than it is to do an exhaustive search over 1145 the symmetric key space. A recent recommendation by an group of 1146 cryptographers [Blaze-Diffie-et-al] has recommended a symmetric key 1147 size of 75 bits for a practical level of security. For 20 year 1148 security, they recommend 90 bits. 1150 Based on that report, a conservative strategy for OAKLEY users would 1151 be to ensure that their Diffie-Hellman computations were as secure as 1152 at least a 90-bit key space. In order to accomplish this for modular 1153 exponentiation groups, the size of the largest prime factor of the 1154 modulus should be at least 180 bits, and the size of the modulus 1155 should be at least 1400 bits. For elliptic curve groups, the LPF 1156 should be at least 180 bits. 1158 If long-term secrecy of the encryption key is not an issue, then the 1159 following parameters may be used for the modular exponentiation 1160 group: 150 bits for the LPF, 980 bits for the modulus size. 1162 The modulus size alone does not determine the strength of the 1163 Diffie-Hellman calculation; the size of the exponent used in 1164 computing powers within the group is also important. The size of the 1165 exponent in bits should be at least twice the size of any symmetric 1166 key that will be derived from it. We recommend that ISAKMP 1167 implementors use at least 180 bits of exponent (twice the size of a 1168 20-year symmetric key). 1170 The mathematical justification for these estimates can be found in 1171 texts that estimate the effort for solving the discrete log problem, 1172 a task that is strongly related to the efficiency of using the Number 1173 Field Sieve for factoring large integers. Readers are referred to 1174 [Stinson] and [Schneier]. 1176 APPENDIX F PGP Keys for Authentication 1178 TBD 1180 APPENDIX G X509 Certificates 1182 TBD 1184 APPENDIX H DSS Certificates 1186 The format and validation methods will be specified in an Internet 1187 draft, draft-cylink-dss-cert-00.txt. 1189 APPENDIX I The Well-Known Groups 1191 This section will have explicit descriptors for three modular 1192 exponentiation groups and two elliptic curve over GF[2^n] groups. 1194 The identifiers for the groups (the well-known KEYID's) will also be 1195 given here. 1197 0 Reserved 1198 1 A modular exponentiation group with a 768 bit modulus (TBD) 1199 2 A modular exponentiation group with a 1024 bit modulus (TBD) 1200 3 A modular exponentiation group with a 2048 bit modulus (TBD) 1201 4 An elliptic curve group over GF[2^155] 1202 5 An elliptic curve group over GF[2^210] 1204 2^32 and higher are used for private group identifiers 1206 Until then, TBD. 1208 Appendix J Domain of Interpretation 1209 Appendix K Implementing Group Operations 1211 The group operation must be implemented as a sequence of arithmetic 1212 operations; the exact operations depend on the type of group. For 1213 modular exponentiation groups, the operation is multi-precision 1214 integer multiplication and remainders by the group modulus. See 1215 Knuth Vol. 2 [Knuth] for a discussion of how to implement these for 1216 large integers. Implementation recommendations for elliptic curve 1217 group operations over GF[2^N] are described in [Schroeppel]. 1219 BIBLIOGRAPHY 1221 [RFC1825] Atkinson, Randall, RFC's 1825-1827 1223 [Blaze] Blaze, Matt et al., Recent symmetric key report 1225 [STS] Diffie, van Oorschot, and Wiener, Authentication and 1226 Authenticated Key Exchanges 1228 [DSS] DSS draft-cylink-dss-cert-00.txt 1230 [SECDNS] DNS Signed Keys, Eastlake & Kaufman, 1231 draft-ietf-dnssec-secext-09.txt 1233 [Photuris] Karn, Phil and Simpson, William, Photuris, draft-ietf- 1234 ipsec-photuris-09.txt 1236 [Kocher] Kocher, Paul, Timing Attack 1238 [Krawcyzk] Krawcyzk, Hugo, SKEME, ISOC, SNDS Symposium, San Diego, 1239 1996 1241 [PKIX] PKIX internet drafts, draft-ietf-pkix-ipki-00.txt 1243 [Random] Random number RFC 1750 1245 [ISAKMP] Schertler, Mark, ISAKMP, draft-ietf-ipsec-isakmp-03.txt and 1246 draft-ietf-ipsec-isakmp-04.txt. The transition from version 3 to 1247 version 4 was in progress at the time of this writing. 1249 [Schneier] Schneier, Bruce, Applied cryptography: protocols, 1250 algorithms, and source code in C, Second edition, John Wiley & Sons, 1251 Inc. 1995, ISBN 0-471-12845-7, hardcover. ISBN 0-471-11709-9, 1252 softcover. 1254 [Schroeppel] Schroeppel, Richard, et al.; Fast Key Exchange with 1255 Elliptic Curve Systems, Crypto '95, Santa Barbara, 1995. Available 1256 on-line as ftp://ftp.cs.arizona.edu/reports/1995/TR95-03.ps (and .Z). 1258 [Stinson] Stinson, Douglas, Cryptography Theory and Practice. CRC 1259 Press, Inc., 2000, Corporate Blvd., Boca Raton, FL, 33431-9868, ISBN 1260 0-8493-8521-0, 1995 1262 [Zimmerman] Philip Zimmermann, The Official Pgp User's Guide, 1263 Published by MIT Press Trade, Publication date: June 1995, ISBN: 1264 0262740176 1266 This draft expires six months from the day of issue. The 1267 expiration date will be August 24, 1996.