idnits 2.17.1 draft-ietf-ipsec-oakley-01.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 (2024-04-27) 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) 2024 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 47 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 262 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 394: '... MANDATORY and OPTIONAL transforms w...' RFC 2119 keyword, line 399: '...he MANDATORY and OPTIONAL transforms w...' RFC 2119 keyword, line 959: '...pport for pre-shared keys is REQUIRED....' RFC 2119 keyword, line 998: '... implementations MUST support the use ...' RFC 2119 keyword, line 1009: '...tively. Support for this is OPTIONAL....' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 875 has weird spacing: '...ter any publi...' -- 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 (May 1996) is 10209 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 2243 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 2247 looks like a reference -- Missing reference section? 'Photuris' on line 2255 looks like a reference -- Missing reference section? 'ISAKMP' on line 2267 looks like a reference -- Missing reference section? 'RFC1750' on line 175 looks like a reference -- Missing reference section? 'DNSSEC' on line 987 looks like a reference -- Missing reference section? 'Zimmerman' on line 2284 looks like a reference -- Missing reference section? 'SECDNS' on line 2252 looks like a reference -- Missing reference section? 'Kocher' on line 2258 looks like a reference -- Missing reference section? 'P' on line 1599 looks like a reference -- Missing reference section? 'RFC-1422' on line 1956 looks like a reference -- Missing reference section? 'Blaze-Diffie-et-al' on line 2184 looks like a reference -- Missing reference section? 'Stinson' on line 2280 looks like a reference -- Missing reference section? 'Schneier' on line 2271 looks like a reference -- Missing reference section? 'Knuth' on line 2237 looks like a reference -- Missing reference section? 'Schroeppel' on line 2276 looks like a reference -- Missing reference section? 'Blaze' on line 2245 looks like a reference -- Missing reference section? 'DSS' on line 2250 looks like a reference -- Missing reference section? 'Krawcyzk' on line 2260 looks like a reference -- Missing reference section? 'PKIX' on line 2263 looks like a reference -- Missing reference section? 'Random' on line 2265 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 25 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-01.txt May 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 The OAKLEY protocol supports Perfect Forward Secrecy, 14 compatibility with the ISAKMP protocol for managing security 15 associations, user-defined abstract group structures for use with 16 the Diffie-Hellman algorithm, key updates, and incorporation of 17 keys distributed via 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 OAKLEY is a generic key exchange protocol, and because the 67 keys 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 authenticating the Diffie-Hellman exponentials and using them for 79 determining a shared key, and also of achieving Perfect Forward 80 Secrecy for the shared key, but it differs from the STS protocol in 81 several ways. 83 The first is the addition of a weak address identification 84 mechanism ("cookies", described by Phil Karn [Photuris]) to help 85 avoid denial of service attacks. 87 The second extension is to allow the two parties to select 88 mutually agreeable supporting algorithms for the protocol: the 89 encryption method, the key derivation method, and the 90 authentication method. 92 Thirdly, the authentication does not depend on encryption using 93 the Diffie-Hellman exponentials; instead, the authentication 94 validates the binding of the exponentials to the identities of the 95 parties. 97 The protocol does not require the two parties compute the shared 98 exponentials prior to authentication. 100 This protocol adds additional security to the derivation of keys 101 meant for use with encryption (as opposed to authentication) by 102 including a dependence on an additional algorithm. The derivation 103 of keys for encryption is made to depend not only on the Diffie- 104 Hellman algorithm, but also on the cryptographic method used to 105 securely authenticate the communicating parties to each other. 107 Finally, this protocol explicitly defines how the two parties can 108 select the mathematical structures (group representation and 109 operation) for performing the Diffie-Hellman algorithm; they can 110 use standard groups or define their own. User-defined groups 111 provide an additional degree of long-term security. 113 OAKLEY has several options for distributing keys. In addition to the 114 classic Diffie-Hellman exchange, this protocol can be used to derive 115 a new key from an existing key and to distribute an externally 116 derived key by encrypting it. 118 The protocol allows two parties to use all or some of the anti- 119 clogging and perfect forward secrecy features. It also permits the 120 use of authentication based on symmetric encryption or non-encryption 121 algorithms. This flexibility is included in order to allow the 122 parties to use the features that are best suited to their security 123 and performance requirements. 125 This document draws extensively in spirit and approach from the 126 Photuris draft by Karn and Simpson [Photuris] (and from discussions 127 with the authors), specifics of the ISAKMP draft by Schertler et al. 128 [ISAKMP], and it was also influenced by papers by Paul van Oorschot 129 and Hugo Krawcyzk. 131 2. The Protocol Outline 133 2.1 General Remarks 135 The OAKLEY protocol is used to establish a shared key with an 136 assigned identifier and associated authenticated identities for the 137 two parties. The name of the key can be used later to derive 138 security associations for the RFC1826 and RFC1827 protocols (AH and 139 ESP) or to achieve other network security goals. 141 Each key is associated with algorithms that are used for 142 authentication, privacy, and one-way functions. These are ancillary 143 algorithms for OAKLEY; their appearance in subsequent security 144 association definitions derived with other protocols is neither 145 required nor prohibited. 147 The specification of the details of how to apply an algorithm to data 148 is called a transform. This document does not supply the transform 149 definitions; they will be in separate RFC's. 151 The anti-clogging tokens, or "cookies", provide a weak form of source 152 address identification for both parties; the cookie exchange can be 153 completed before they perform the computationally expensive part of 154 the protocol (large integer exponentiations). 156 It is important to note that OAKLEY uses the cookies for two 157 purposes: anti-clogging and key naming. The two parties to the 158 protocol each contribute one cookie at the initiation of key 159 establishment; the pair of cookies becomes the key identifier 160 (KEYID), a reusable name for the keying material. Because of this 161 dual role, we will use the notation for the concatenation of the 162 cookies ("COOKIE-I, COOKIE-R") interchangeably with the symbol 163 "KEYID". 165 OAKLEY is designed to be a compatible component of the ISAKMP 166 protocol [ISAKMP], which runs over the UDP protocol using a well- 167 known port (see the RFC on port assignments, STD02-RFC-1700). The 168 only technical requirement for the protocol environment is that the 169 underlying protocol stack must be able to supply the Internet address 170 of the remote party for each message. Thus, OAKLEY could, in theory, 171 be used directly over the IP protocol or over UDP, if suitable 172 protocol or port number assignments were available. 174 The machine running OAKLEY must provide a good random number 175 generator, as described in [RFC1750], as the source of random numbers 176 required in this protocol description. Any mention of a "nonce" 177 implies that the nonce value is generated by such a generator. The 178 same is true for "pseudorandom" values. 180 2.2 Notation 182 The section describes the notation used in this document for message 183 sequences and content. 185 2.2.1 Message descriptions 187 The protocol exchanges below are written in an abbreviated notation 188 that is intended to convey the essential elements of the exchange in 189 a clear manner. A brief guide to the notation follows. The detailed 190 formats and assigned values are given in the appendices. 192 In order to represent message exchanges succinctly, this document 193 uses an abbreviated notation that describes each message in terms of 194 its source and destination and relevant fields. 196 Arrows ("->") indicate whether the message sent from the initiator to 197 the responder, or vice versa ("<-"). 199 The fields in the message are named and comma separated. The 200 protocol uses the convention that the first several fields constitute 201 a fixed header format for all messages. 203 For example, consider a HYPOTHETICAL exchange of messages involving a 204 fixed format message, the four fixed fields being two "cookies", the 205 third field being a message type name, the fourth field being a 206 multi-precision integer representing a power of a number: 208 Initiator Responder 209 -> Cookie-I, 0, OK_KEYX, g^x -> 210 <- Cookie-R, Cookie-I, OK_KEYX, g^y <- 212 The notation describes a two message sequence. The initiator begins 213 by sending a message with 4 fields to the responder; the first field 214 has the unspecified value "Cookie-I", second field has the numeric 215 value 0, the third field indicates the message type is OK_KEYX, the 216 fourth value is an abstract group element g to the x'th power. 218 The second line indicates that the responder replies with value 219 "Cookie-R" in the first field, a copy of the "Cookie-I" value in the 220 second field, message type OK_KEYX, and the number g raised to the 221 y'th power. 223 The value OK_KEYX is in capitals to indicate that it is a unique 224 constant (constants are defined the appendices). 226 Variable precision integers with length zero are null values for the 227 protocol. 229 Sometimes the protocol will indicate that an entire payload (usually 230 the Key Exchange Payload) has null values. The payload is still 231 present in the message, for the purpose of simplifying parsing. 233 2.2.2 Guide to symbols 235 Cookie-I and Cookie-R (or CKY-I and CKY-R) are 64-bit pseudo-random 236 numbers. The generation method must ensure with high probability 237 that the numbers used for each IP remote address are unique over some 238 previous time period, such as one hour. 240 KEYID is the concatenation of the initiator and responder cookies and 241 the domain of interpretation; it is the name of keying material. 243 sKEYID is used to denote the keying material named by the KEYID. It 244 is never transmitted, but it is used in various calculations 245 performed by the two parties. 247 OK_KEYX and OK_NEWGRP are distinct message types. 249 IDP is a bit indicating whether or not material after the encryption 250 boundary (see appendix D), is encrypted. 252 g^x and g^y are encodings of group elements, where g is a special 253 group element indicated in the group description (see Appendix A) and 254 g^x indicates that element raised to the x'th power. The type of the 255 encoding is either a variable precision integer or a pair of such 256 integers, as indicated in the group operation in the group 257 description. Note that we will write g^xy as a short-hand for 258 g^(xy). See Appendix J for references that describe implementing 259 large integer computations and the relationship between various group 260 definitions and basic arithmetic operations. 262 EHAO is a list of encryption/hash/authentication choices. Each item 263 is a pair of values: a class name and an algorithm name. 265 EHAS is a set of three items selected from the EHAO list, one from 266 each of the classes for encryption, hash, authentication. 268 GRP is a name (32-bit value) for the group and its relevant 269 parameters: the size of the integers, the arithmetic operation, and 270 the generator element. There are a few pre-defined GRP's (for 768 271 bit modular exponentiation groups, 1024 bit modexp, 2048 bit modexp, 272 155-bit elliptic curve, see Appendix H), but participants can share 273 other group descriptions in a later protocol stage (see the section 274 NEW GROUP). It is important to separate notion of the GRP from the 275 group descriptor (Appendix A); the former is a name for the latter. 277 The symbol vertical bar "|" is used to denote concatenation of bit 278 strings. Fields are concatenated using their encoded form as they 279 appear in their payload. 281 Ni and Nr are nonces selected by the initiator and responder, 282 respectively. 284 ID(I) and ID(R) are the identities to be used in authenticating the 285 initiator and responder respectively. 287 E{x}Ki indicates the encryption of x using the public key of the 288 initiator. Encryption is done using the algorithm associated with 289 the authentication method; usually this will be RSA. 291 S{x}Ki indicates the signature over x using the private key (signing 292 key) of the initiator. Signing is done using the algorithm 293 associated with the authentication method; usually this will be RSA 294 or DSS. 296 prf(a, b) denotes the result of applying pseudo-random function "a" 297 to data "b". One may think of "a" as a key or as a value that 298 characterizes the function prf; in the latter case it is the index 299 into a family of functions. 301 prf(0, b) denotes the application of a one-way function to data "b". 302 The similarity with the previous notation is deliberate and indicates 303 that a single algorithm, e.g. MD5, might will used for both purposes. 304 In the first case a "keyed" MD5 transform would be used with key "a"; 305 in the second case the transform would have the fixed key value zero, 306 resulting in a one-way function. 308 The term "transform" is used to refer to functions defined in 309 auxiliary RFC's. The the transform RFC's will be drawn from those 310 defined for IPSEC AH and ESP (see RFC1825 for the overall 311 architecture encompassing these protocols). 313 2.3 The Key Exchange Message Overview 315 The goal of key exchange processing is the secure establishment of 316 common keying information state in the two parties. This state 317 information is a key name, secret keying material, the identification 318 of the two parties, and three algorithms for use during 319 authentication: encryption (for privacy of the identities of the two 320 parties), hashing (a pseudorandom function for protecting the 321 integrity of the messages and for authenticating message fields), and 322 authentication (the algorithm on which the mutual authentication of 323 the two parties is based). The encodings and meanings for these 324 choices are presented in Appendix B. 326 The main mode exchange has five optional features: stateless cookie 327 exchange, perfect forward secrecy for the keying material, secrecy 328 for the identities, perfect forward secrecy for identity secrecy, use 329 of signatures (for non-repudiation). The two parties can use all or 330 none of these features. 332 The general outline of processing is that the Initiator of the 333 exchange begins by specifying as much information as he wishes in his 334 first message. The Responder replies, supplying as much information 335 as he wishes. The two sides exchange messages, supplying more 336 information each time, until their requirements are satisfied. 338 The choice of how much information to include in each message depends 339 on which options are desirable. For example, if stateless cookies 340 are not a requirement, and identity secrecy and perfect forward 341 secrecy for the keying material are not requirements, and if non- 342 repudiatable signatures are acceptable, then the exchange can be 343 completed in three messages. 345 Additional features may increase the number of roundtrips needed for 346 the keying material determination. 348 ISAKMP provides fields for specifying the security association 349 parameters for use with the AH and ESP protocols. These security 350 association payload types are specified in the ISAKMP draft; the 351 payload types can be protected with OAKLEY keying material and 352 algorithms, but this document does not discuss their use. 354 2.3.1 The Essential Key Exchange Message Fields 356 There are 12 fields in an OAKLEY key exchange message. Not all the 357 fields are relevant in every message; if a field is not relevant it 358 can have a null value or not be present (no payload). 360 CK-I originator cookie. 361 CK-R responder cookie. 362 MSGTYPE for key exchange, will be ISA_KE&AUTH_REQ or ISA_KE&AUTH_REP; 363 for new group definitions, will be ISA_NEW_GROUP_REQ 364 or ISA_NEW_GROUP_REP 365 GRP the name of the Diffie-Hellman group used for the exchange 366 g^x (or g^y) variable length integer representing a power of 367 group generator 368 EHAO or EHAS encryption, hash, authentication functions, offered 369 and selected 370 IDP an indicator as to whether or not encryption with 371 g^xy follows (perfect forward secrecy for ID's) 372 ID(I) the identity for the Initiator 373 ID(R) the identity for the Responder 374 Ni nonce supplied by the Initiator 375 Nr nonce supplied by the Responder 377 The construction of the cookies is implementation dependent. Phil 378 Karn has recommended making them the result of a one-way function 379 applied to a secret value (changed periodically), the local and 380 remote IP address, and the local and remote UDP port. In this way, 381 the cookies remain stateless and expire periodically. Note that with 382 OAKLEY, this would cause the KEYID's derived from the secret value to 383 also expire, necessitating the removal of any state information 384 associated with it. 386 In order to support pre-distributed keys, we recommend that 387 implementations reserved some portion of their cookie space to 388 permanent keys. The encoding of these depends only on the local 389 implementation. 391 The encryption functions used with OAKLEY must be cryptographic 392 transforms which guarantee privacy and integrity for the message 393 data. Merely using DES in CBC mode is not permissible. The 394 MANDATORY and OPTIONAL transforms will include any that satisfy this 395 criteria and are defined for use with RFC1827 (ESP). 397 The one-way (hash) functions used with OAKLEY must be cryptographic 398 transforms which can be used as either keyed hash (pseudo-random) or 399 non-keyed transforms. The MANDATORY and OPTIONAL transforms will 400 include any that are defined for use with RFC1826 (AH). 402 Where nonces are indicated, they will be variable precision integers 403 with an entropy value that matches the "strength" attribute of the 404 GRP used with the exchange. If no GRP is indicated, the nonces must 405 be at least 90 bits long. The pseudo-random generator for the nonce 406 material should start with initial data that has at least 90 bits of 407 entropy; see RFC1750. 409 2.3.2 Mapping to ISAKMP Message Structures 411 All the OAKLEY message fields correspond to ISAKMP message payloads 412 or payload components. The relevant payload fields are the SA 413 payload, the AUTH payload, the Certificate Payload, the Key Exchange 414 Payload. 416 Some of the ISAKMP header and payload fields will have constant 417 values when used with OAKLEY: 418 DOI, the Domain of Interpretation, will have the value INTERNET. In this 419 document, the DOI will not be mentioned; it is assumed that the 420 software implementing OAKLEY will always be in the IPv4 or IPv6 DOI. 422 Unless otherwise noted, the Key Exchange Identifier is Oakley Main Mode. 424 In the SA Payload, the Situation is ISAKMPID. This value is fixed 425 at a constant value because Oakley uses the ID fields in AUTH payload 426 to identify the two parties. 428 In the following we indicate where each OAKLEY field appears in the 429 ISAKMP message structure. 430 CK-I ISAKMP header 431 CK-R ISAKMP header 432 MSGTYPE Message Type in ISAKMP header 433 GRP SA payload, Proposal section 434 g^x (or g^y) Key Exchange Payload, encoded as a variable precision integer 435 EHAO and EHAS SA payload, Proposal section 436 IDP A bit in the RESERVED field in the AUTH header 437 ID(I) AUTH payload, Identity field 438 ID(R) AUTH payload, Identity field 439 Ni AUTH payload, Nonce Field 440 Nr AUTH payload, Nonce Field 441 S{...}Kx AUTH payload, Data Field 442 prf{K,...} AUTH payload, Data Field 444 2.4 The Key Exchange Protocol 446 The exact number and content of messages exchanged during an OAKLEY 447 key exchange depends on which options the Initiator and Responder 448 want to use. A key exchange can be completed with three or more 449 messages, depending on those options. 451 The three components of the key determination protocol are the 452 1. cookie exchange (optionally stateless) 453 2. Diffie-Hellman half-key exchange (optional, but essential for 454 perfect forward secrecy) 455 3. authentication (options: privacy for ID's, privacy for ID's with PFS, 456 non-repudiatable) 458 The initiator can supply as little information as a bare exchange 459 request, carrying no additional information. On the other hand the 460 initiator can begin by supplying all of the information necessary for 461 the responder to authenticate the request and complete the key 462 determination quickly, if the responder chooses to accept this 463 method. If not, the responder can reply with a minimal amount of 464 information (at the minimum, a cookie). 466 The Initiator is responsible for retransmitting messages if the 467 protocol does not terminate in a timely fashion. The Responder must 468 therefore avoid discarding reply information until it is acknowledged 469 by Initiator in the course of continuing the protocol. 471 The remainder of this section contains examples demonstrating how to 472 use OAKLEY options. 474 2.4.1 An Aggressive Example 476 The following example indicates how two parties can complete a key 477 exchange in two messages. The identities are not secret, the derived 478 keying material is protected by PFS. 480 By using digital signatures, the two parties will have a proof of 481 communication that can be recorded and presented later to a third 482 party. 484 The keying material implied by the group exponentials is not needed 485 for completing the exchange. If it is desirable to defer the 486 computation, the implementation can save the "x" and "g^y" values and 487 mark the keying material as "uncomputed". It can be computed from 488 this information later. 490 Initiator Responder 491 --------- --------- 492 -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> 493 ID(I), ID(R), Ni, 0, 494 S{ID(I) | ID(R) | Ni | 0 | GRP | g^x | EHAO}Ki 495 <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, 496 ID(R), ID(I), Nr, Ni, 497 S{ID(R) | ID(I) | Nr | Ni | GRP | g^y | EHAS}Kr <- 498 -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO, NIDP, -> 499 ID(I), ID(R), Ni, Nr, 500 S{ID(I) | ID(R) | Ni | Nr | GRP | g^y | EHAO}Ki 502 NB "NIDP" means that the PFS option for hiding identities is not used. 503 i.e., the identities are not encrypted using g^xy 505 NB Fields are concatenated using their encoded form as they appear in 506 their payload. 508 The result of this exchange is a key with KEYID = CKY-I|CKY-R and 509 value 511 sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R). 513 The processing outline for this exchange is as follows: 515 Initiation 517 The Initiator generates a unique cookie and associates it with the 518 expected IP address of the responder, and its chosen state 519 information: GRP, a pseudo-randomly selected exponent x, g^x, EHAO 520 list, nonce, identities. The first authentication choice in the 521 EHAO list is an algorithm that supports digital signatures, and 522 this is used to sign the ID's and the nonce and group id. The 523 initiator further 525 notes that the key is in the initial state of "unauthenticated", 526 and 528 sets a timer for possible retransmission and/or termination of the 529 request. 531 When the Responder receives the message, he may choose to ignore all 532 the information and treat it as merely a request for a cookie, 533 creating no state. If CKY-I is not already in use by the source 534 address in the IP header, the responder generates a unique cookie, 535 CKY-R. The next steps depend on the Responder's preferences. The 536 minimal required response is to reply with the first cookie field set 537 to zero and CKY-R in the second field. For this example we will 538 assume that responder is more aggressive (for the alternatives, see 539 section 6) and accepts the following: 540 group with identifier GRP, 541 first authentication choice (which must be the digital signature 542 method 543 used to sign the Initiator message), 544 lack of perfect forward secrecy for protecting the identities, 545 identity ID(I) and identity ID(R) 547 In this example the Responder decides to accept all the information 548 offered by the initiator. It validates the signature over the signed 549 portion of the message, and associate the pair (CKY-I, CKY-R) with 550 the following state information: 552 the source and destination network addresses of the message 554 key state of "unauthenticated" 556 the first algorithm from the authentication offer 558 group GRP, a "y" exponent value in group GRP, and g^x from the 559 message 561 the nonce Ni and a pseudorandomly selected value Nr 563 a timer for possible destruction of the state. 565 The Responder computes g^y, forms the reply message, and then signs 566 the state information with the private key of ID(R) and sends it to 567 the Initiator. 569 In this example, to expedite the protocol, the Responder implicitly 570 accepts the first algorithm in the Authentication class of the EHAO 571 list. This because he cannot validate the Initiator signature 572 without accepting the algorithm for doing the signature. The 573 Responder's EHAS list will also reflect his acceptance. 575 The Initiator receives the reply message and 576 validates that CKY-I is a valid association for the network 577 address of the incoming message, 579 adds the CKY-R value to the state for the pair (CKY-I, network 580 address), and associates all state information with the pair 581 (CKY-I, CKY-R), 583 validates the signature of the responder over the state 584 information (should validation fail, the message is discarded) 586 adds g^y to its state information, 588 saves the EHA selections in the state, 590 optionally computes (g^y)^x (= g^xy) (this can be deferred until 591 after sending the reply message), 593 sends the reply message, signed with the public key of ID(I), 595 marks the KEYID (CKY-I|CKY-R) as authenticated, 597 and composes the reply message and signature. 599 When the Responder receives the Initiator message, and if the 600 signature is valid, it marks the key as being in the authenticated 601 state. It should compute g^xy and associate it with the KEYID. 603 Note that although PFS for identity protection is not used, PFS for 604 the derived keying material is still present because the Diffie- 605 Hellman half-keys g^x and g^y are exchanged. 607 Even if the Responder only accepts some of the Initiator information, 608 the Initiator will consider the protocol to be progressing. The 609 Initiator should assume that fields that were not accepted by the 610 Responder were not recorded by the Responder. 612 If the Responder does not accept the aggressive exchange and selects 613 another algorithm for the A function, then the protocol will not 614 continue using the signature algorithm or the signature value from 615 the first message. 617 2.4.1.1 Fields Not Present 619 If the Responder does not accept all the fields offered by the 620 Initiator, he should include null values for those fields in his 621 response. Section 6 has guidelines on how to select fields in a 622 "left-to-right" manner. If a field is not accepted, then it and all 623 following fields must have null values. 625 The Responder should not record any information that it does not 626 accept. If the ID's and nonces have null values, there will not be a 627 signature over these null values. 629 2.4.1.2 Signature via Pseudo-Random Functions 631 The aggressive example is written to suggest that public key 632 technology is used for the signatures. However, a pseudorandom 633 function can be used, if the parties have previously agreed to such a 634 scheme and have a shared key. 636 If the first proposal in the EHAO list is an "existing key" method, 637 then the KEYID named in that proposal will supply the keying material 638 for the "signature" which is computed using the "H" algorithm 639 associated with the KEYID. 641 Suppose the first proposal in EHAO is 642 EXISTING-KEY, 32 643 and the "H" algorithm for KEYID 32 is MD5-HMAC, by prior negotiation. 644 The keying material is some string of bits, call it sK32. Then in 645 the first message in the aggressive exchange, where the signature 647 S{ID(I), ID(R), Ni, 0, GRP, g^x, EHAO}Ki 649 is indicated, the signature computation would be performed by 650 MD5-HMAC_func(KEY=sK32, DATA = ID(I) | ID(R) | Ni | 0 | GRP | g^x 651 | EHAO) 652 (The exact definition of the algorithm corresponding to "MD5-HMAC- 653 func" will appear in the RFC defining that transform). 655 The result of this computation appears in the Authentication payload. 657 2.4.2 An Aggressive Example With Hidden Identities 659 The following example indicates how two parties can complete a key 660 exchange without using digital signatures. Public key cryptography 661 hides the identities during authentication. The group exponentials 662 are exchanged and authenticated, but the implied keying material 663 (g^xy) is not needed during the exchange. 665 This exchange has an important difference from the previous signature 666 scheme --- in the first message, an identity for the responder is 667 indicated as cleartext: ID(R'). However, the identity hidden with 668 the public key cryptography is different: ID(R). This happens 669 because the Initiator must somehow tell the Responder which 670 public/private key pair to use for the decryption, but at the same 671 time, the identity is hidden by encryption with that public key. 673 The Initiator might elect to forgo secrecy of the Responder identity, 674 but this is undesirable. Instead, if there is a well-known identity 675 for the Responder node, the public key for that identity can be used 676 to encrypt the actual Responder identity. 678 Initiator Responder 679 --------- --------- 680 -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> 681 ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr' 682 <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, 683 E{ID(R), ID(I), Nr}Ki, 684 prf(Kir, ID(R) | ID(I) | Nr | Ni | GRP | g^y | g^x) <- 685 -> CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP, 686 prf(Kir, ID(I)| ID(R) | Ni | Nr | GRP | g^x | g^y) -> 688 Kir = prf(0, Ni | Nr) 690 NB "NIDP" means that the PFS option for hiding identities is not used. 692 NB The ID(R') value is included in the Authentication payload as 693 described in Appendix B. 695 The result of this exchange is a key with KEYID = CKY-I|CKY-R and 696 value sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R). 698 The processing outline for this exchange is as follows: 700 Initiation 701 The Initiator generates a unique cookie and associates it with the 702 expected IP address of the responder, and its chosen state 703 information: GRP, g^x, EHAO list. The first authentication choice 704 in the EHAO list is an algorithm that supports public key 705 encryption. The Initiator also names the two identities to be 706 used for the connection and enters these into the state. A well- 707 known identity for the responder machine is also chosen, and the 708 public key for this identity is used to encrypt the nonce Ni and 709 the two connection identities. The Initiator further 711 notes that the key is in the initial state of "unauthenticated", 712 and 714 sets a timer for possible retransmission and/or termination of the 715 request. 717 When the Responder receives the message, he may choose to ignore all 718 the information and treat it as merely a request for a cookie, 719 creating no state. 721 If CKY-I is not already in use by the source address in the IP 722 header, the Responder generates a unique cookie, CKY-R. As before, 723 the next steps depend on the responders preferences. The minimal 724 required response is a message with the first cookie field set to 725 zero and CKY-R in the second field. For this example we will assume 726 that responder is more aggressive and accepts the following: 727 group GRP, first authentication choice (which must be the public key 728 encryption algorithm used to encrypt the payload), lack of perfect 729 forward secrecy for protecting the identities, identity ID(I), 730 identity ID(R) 732 The Responder must decrypt the ID and nonce information, using the 733 private key for the R' ID. After this, the private key for the R ID 734 will be used to decrypt the nonce field. 736 The Responder now associates the pair (CKY-I, CKY-R) with the 737 following state information: 739 the source and destination network addresses of the message 741 key state of "unauthenticated" 743 the first algorithm from each class in the EHAO (encryption-hash- 744 authentication algorithm offers) list 746 group GRP and a y and g^y value in group GRP 748 the nonce Ni and a pseudorandomly selected value Nr 750 a timer for possible destruction of the state. 752 The Responder then encrypts the state information with the public key 753 of ID(I), forms the prf value, and sends it to the Initiator. 755 The Initiator receives the reply message and 756 validates that CKY-I is a valid association for the network 757 address of the incoming message, 759 adds the CKY-R value to the state for the pair (CKY-I, network 760 address), and associates all state information with the pair 761 (CKY-I, CKY-R), 763 decrypts the ID and nonce information 765 checks the prf calculation (should this fail, the message is 766 discarded) 768 adds g^y to its state information, 770 saves the EHA selections in the state, 772 optionally computes (g^x)^y (= g^xy) (this may be deferred), and 774 sends the reply message, encrypted with the public key of ID(R), 776 and marks the KEYID (CKY-I|CKY-R) as authenticated. 778 When the Responder receives this message, it marks the key as being 779 in the authenticated state. If it has not already done so, it should 780 compute g^xy and associate it with the KEYID. 782 The secret keying material sKEYID = prf(Ni | Nr, g^xy | CKY-I | 783 CKY-R) 785 Note that although PFS for identity protection is not used, PFS for 786 the derived keying material is still present because the Diffie- 787 Hellman half-keys g^x and g^y are exchanged. 789 2.4.3 An Aggressive Example With Private Identities and Without Diffie- 790 Hellman 792 Considerable computational expense can be avoided if perfect forward 793 secrecy is not a requirement for the session key derivation. The two 794 parties can exchange nonces and secret key parts to achieve the 795 authentication and derive keying material. The long-term privacy of 796 data protected with derived keying material is dependent on the 797 private keys of each of the parties. 799 In this exchange, the GRP has the value 0 and the field for the group 800 exponential is used to hold a nonce value instead. 802 As in the previous section, the first proposed algorithm must be a 803 public key encryption system; by responding with a cookie and a non- 804 zero exponential field, the Responder implicitly accepts the first 805 proposal and the lack of perfect forward secrecy for the identities 806 and derived keying material. 808 Initiator Responder 809 --------- --------- 810 -> CKY-I, 0, OK_KEYX, 0, 0, EHAO, NIDP, -> 811 ID(R'), E{ID(I), ID(R), sKi}Kr', 812 prf(Kir, ID(R), ID(I) <- 813 <- CKY-R, CKY-I, OK_KEYX, 0, 0, EHAS, NIDP, 814 E{ID(R), ID(I), sKr}Ki, 815 prf(Kir, ID(R), ID(I), Nr, Ni) <- 816 -> CKY-I, CKY-R, OK_KEYX, EHAS, NIDP, 817 prf(Kir, ID(I), ID(R), Ni, Nr) -> 819 Kir = prf(0, sKi | sKr) 821 NB The sKi and sKr values go into the nonce fields. The change in 822 notation is meant to emphasize that their entropy is critical to setting 823 the keying material. 825 NB "NIDP" means that the PFS option for hiding identities is not used. 827 The result of this exchange is a key with KEYID = CKY-I|CKY-R and 828 value sKEYID = prf(Kir, CKY-I | CKY-R). 830 2.4.4 A Conservative Example 832 In this example the two parties are minimally aggressive; they use 833 the cookie exchange to delay creation of state, and they use perfect 834 forward secrecy to protect the identities. 836 The responder considers the ability of the initiator to repeat CKY-R 837 as weak evidence that the message originates from a "live" 838 correspondent on the network and the correspondent is associated with 839 the initiator's network address. The initiator makes similar 840 assumptions when CKY-I is repeated to the initiator. 842 All messages must have either have valid cookies or at least one zero 843 cookie. If both cookies are zero, this indicates a request for a 844 cookie; if only the initiator cookie is zero, it is a response to a 845 cookie request. 847 Information in messages violating the cookie rules cannot be used for 848 any OAKLEY operations. 850 Note that the Initiator must and Responder must agree on one set of 851 EHA algorithms; there is not one set for the Responder and one for 852 the Initiator. The Initiator must include at least MD5 and DES in 853 the initial offer. 855 Fields not indicated have null values. 857 Initiator Responder 858 --------- --------- 859 -> 0, 0, OK_KEYX -> 860 <- 0, CKY-R, OK_KEYX <- 861 -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO -> 862 <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS <- 863 -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, IDP*, 864 ID(I), ID(R), E{Ni}Kr, -> 865 <- CKY-R, CKY-I, OK_KEYX, GRP, 0 , 0, IDP, <- 866 E{Nr, Ni}Ki, ID(R), ID(I), 867 prf(Nr | Ni, GRP, g^xy, ID(R), ID(I)) 868 -> CKY-I, CKY-R, OK_KEYX, GRP, 0 , 0, IDP, 869 prf(Ni | Nr, GRP | g^xy | ID(I) | ID(R)) -> 871 * when IDP is in effect, authentication payloads are encrypted with 872 the selected encryption algorithm using the keying material prf(0, g^xy). 873 (The transform defining the encryption algorithm will define 874 how to select key bits from the keying material.) 875 This encryption is in addition to and after any public key encryption. 876 See Appendix B. 878 Note the in first messages, several fields are omitted from the 879 description. These fields are present as null values. 881 The first exchange allows the Responder to use stateless cookies; if 882 the responder generates cookies in a manner that allows him to 883 validate them without saving them, as in Photuris, then this is 884 possible. Even if the Initiator includes a cookie in his initial 885 request, the responder can still use stateless cookies by merely 886 omitting the CKY-I from his reply and by declining to record the 887 Initiator cookie until it appears in a later message. 889 After the exchange is complete, both parties compute the shared key 890 material sKEYID as 891 prf(Ni | Nr, g^xy | CKY-I | CKY-R) 892 where "prf" is the pseudo-random function in class "hash" selected in 893 the EHA list. 895 As with the cookies, each party considers the ability of the remote 896 side to repeat the Ni or Nr value as a proof that Ka, the public key 897 of party a, speaks for the remote party and establishes its identity. 899 In analyzing this exchange, it is important to note that although the 900 IDP option ensures that the identities are protected with an 901 ephemeral key g^xy, the authentication itself does not depend on 902 g^xy. It is essential that the authentication steps validate the g^x 903 and g^y values, and it is thus imperative that the authentication not 904 involve a circular dependency on them. A third party could intervene 905 with a "man-in-middle" scheme to convince the initiator and responder 906 to use different g^xy values; although such an attack might result in 907 revealing the identities to the eavesdropper, the authentication 908 would fail. 910 2.4.5 Extra Strength for Protection of Encryption Keys 912 The nonces Ni and Nr are used to provide an extra dimension of 913 secrecy in deriving session keys. This makes the secrecy of the key 914 depend on two different problems: the discrete logarithm problem in 915 the group G, and the problem of breaking the nonce encryption scheme. 916 If RSA encryption is used, then this second problem is roughly 917 equivalent to factoring the RSA public keys of both the initiator and 918 responder. 920 For authentication, the key type, the validation method, and the 921 certification requirement must be indicated. 923 2.5 Identity and Authentication 925 2.5.1 Identity 927 In OAKLEY exchanges the Initiator offers Initiator and Responder ID's 928 -- the former is the claimed identity for the Initiator, and the 929 latter is the requested ID for the Responder. 931 If neither ID is specified, the ID's are taken from the IP header 932 source and destination addresses. 934 If the Initiator doesn't supply a responder ID, the Responder can 935 reply by naming any identity that the local policy allows. The 936 Initiator can refuse acceptance by terminating the exchange. 938 The Responder can also reply with a different ID than the Initiator 939 suggested; the Initiator can accept this implicitly by continuing the 940 exchange or refuse it by terminating (not replying). 942 2.5.2 Authentication 944 The authentication of principals to one another is at the heart of 945 any key exchange scheme. The Internet community must decide on a 946 scalable standard for solving this problem, and OAKLEY must make use 947 of that standard. At the time of this writing, there is no such 948 standard, though several are emerging. This document attempts to 949 describe how a handful of standards could be incorporated into 950 OAKLEY, without attempting to pick and choose among them. 952 The following methods can appear in OAKLEY offers: 954 a. Pre-shared Keys 955 When two parties have arranged for a trusted method of 956 distributing secret keys for their mutual authentication, they can 957 be used for authentication. This has obvious scaling problems for 958 large systems, but it is an acceptable interim solution for some 959 situations. Support for pre-shared keys is REQUIRED. 961 The encryption, hash, and authentication algorithm for use with a 962 pre-shared key must be part of the state information distributed 963 with the key itself. 965 The pre-shared keys have a KEYID and keying material sKEYID; the 966 KEYID is used in a pre-shared key authentication option offer. 967 There can be more than one pre-shared key offer in a list. 969 Because the KEYID persists over different invocations of OAKLEY 970 (after a crash, etc.), it must occupy a reserved part of the KEYID 971 space for the two parties. A few bits can be set aside in each 972 party's "cookie space" to accommodate this. 974 There is no certification authority for pre-shared keys. When a 975 pre-shared key is used to generate an authentication payload, the 976 certification authority is "None", the Authentication Type is 977 "Preshared", and the payload contains 978 the KEYID, encoded as two 64-bit quantities, and 980 the result of applying the pseudorandom hash function to the 981 message body with the sKEYID forming the key for the function 983 See Appendix B for details of formats for the Authentication 984 Payload. 986 b. DNS public keys 987 Security extensions to the DNS protocol [DNSSEC] provide a 988 convenient way to access public key information, especially for 989 public keys associated with hosts. RSA keys are a requirement for 990 secure DNS implementations; extensions to allow optional DSS keys 991 are a near-term possibility. 993 DNS KEY records have associated SIG records that are signed by a 994 zone authority, and a hierarchy of signatures back to the root 995 server establishes a foundation for trust. The SIG records 996 indicate the algorithm used for forming the signature. 998 OAKLEY implementations MUST support the use of DNS KEY and SIG 999 records for authenticating with respect to IPv4 and IPv6 addresses 1000 and fully qualified domain names. However, implementations are 1001 not required to support any particular algorithm (RSA, DSS, etc.). 1003 c. RSA public keys w/o certification authority signature 1004 PGP [Zimmerman] uses public keys with an informal method for 1005 establishing trust. The format of PGP public keys and naming 1006 methods will be described in a separate RFC. The RSA algorithm 1007 can be used with PGP keys for either signing or encryption; the 1008 authentication option should indicate either RSA-SIG or RSA-ENC, 1009 respectively. Support for this is OPTIONAL. 1011 d.1 RSA public keys w/ certificates 1012 There are various formats and naming conventions for public keys 1013 that are signed by one or more certification authorities. The 1014 Public Key Interchange Protocol discusses X.509 encodings and 1015 validation. Support for this is OPTIONAL. 1017 d.2 DSS keys w/ certificates 1018 Encoding for the Digital Signature Standard with X.509 is 1019 described in draft-ietf-ipsec-dss-cert-00.txt. Support for this 1020 is OPTIONAL; an ISAKMP Authentication Type will be assigned. 1022 2.5.3 Validating Authentication Keys 1024 The combination of the Authentication algorithm, the Authentication 1025 Authority, the Authentication Type, and a key (usually public) define 1026 how to validate the messages with respect to the claimed identity. 1027 The key information will be available either from a pre-shared key, 1028 or from some kind of certification authority. 1030 Generally the certification authority produces a certificate binding 1031 the entity name to a public key. OAKLEY implementations must be 1032 prepared to fetch and validate certificates before using the public 1033 key for OAKLEY authentication purposes. 1035 The ISAKMP Authentication Payload defines the Authentication 1036 Authority field for specifying the authority that must be apparent in 1037 the trust hierarchy for authentication. 1039 Once an appropriate certificate is obtained (see 2.4.3), the 1040 validation method will depend on the Authentication Type; if it is 1041 PGP then the PGP signature validation routines can be called to 1042 satisfy the local web-of-trust predicates; if it is RSA with X.509 1043 certificates, the certificate must be examined to see if the 1044 certification authority signature can be validated, and if the 1045 hierarchy is recognized by the local policy. 1047 2.5.4 Fetching Identity Objects 1049 In addition to interpreting the certificate or other data structure 1050 that contains an identity, users of OAKLEY must face the task of 1051 retrieving certificates that bind a public key to an identifier and 1052 also retrieving auxiliary certificates for certifying authorities or 1053 co-signers (as in the PGP web of trust). 1055 The ISAKMP Credentials Payload can be used to attach useful 1056 certificates to OAKLEY messages. The Credentials Payload is defined 1057 in Appendix B. 1059 Support for accessing and revoking public key certificates via the 1060 Secure DNS protocol [SECDNS] is MANDATORY for OAKLEY implementations. 1061 Other retrieval methods can be used when the AUTH class indicates a 1062 preference. 1064 The Public Key Interchange Protocol discusses a full protocol that 1065 might be used with X.509 encoded certificates. 1067 2.6 Interface to Cryptographic Transforms 1069 The keying material computed by the key exchange should have at least 1070 90 bits of entropy, which means that it must be at least 90 bits in 1071 length. This may be more or less than is required for keying the 1072 encryption and/or pseudorandom function transforms. 1074 The transforms used with OAKLEY should have auxiliary algorithms 1075 which take a variable precision integer and turn it into keying 1076 material of the appropriate length. For example, a DES algorithm 1077 could take the low order 56 bits, a triple DES algorithm might use 1078 the following: 1079 K1 = low 56 bits of md5(0|sKEYID) 1080 K2 = low 56 bits of md5(1|sKEYID) 1081 K3 = low 56 bits of md5(2|sKEYID) 1083 The transforms will be called with the keying material encoded as a 1084 variable precision integer, the length of the data, and the block of 1085 memory with the data. Conversion of the keying material to a 1086 transform key is the responsibility of the transform. 1088 2.7 Retransmission, Timeouts, and Error Messages 1090 If a response from the Responder is not elicited in an appropriate 1091 amount of time, the message should be retransmitted by the Initiator. 1092 These retransmissions must be handled gracefully by both parties; the 1093 Responder must retain information for retransmitting until the 1094 Initiator moves to the next message in the protocol or completes the 1095 exchange. 1097 Informational error messages present a problem because they cannot be 1098 authenticated using only the information present in an incomplete 1099 exchange; for this reason, the parties may wish to establish a 1100 default key for OAKLEY error messages. A possible method for 1101 establishing such a key is described in Appendix B, under the use of 1102 ISA_INIT message types. 1104 In the following the message type is OAKLEY Error, the KEYID supplies 1105 the H algorithm and key for authenticating the message contents; this 1106 value is carried in the Sig/Prf payload. 1108 The Error payload contains the error code and the contents of the 1109 rejected message. 1111 1 2 3 1112 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 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 ! ! 1115 ~ Initiator-Cookie ~ 1116 / ! ! 1117 KEYID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 \ ! ! 1119 ~ Responder-Cookie ~ 1120 ! ! 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 ! Domain of Interpretation ! 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 ! Message Type ! Exch ! Vers ! Length ! 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 ! SPI (unused) ! 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 ! SPI (unused) ! 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 ! Error Payload ! 1131 ~ ~ 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 ! Sig/prf Payload 1134 ~ ~ 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 The error message will contain the cookies as presented in the offending 1138 message, the message type OAKLEY_ERROR, and the reason for the error, 1139 followed by the rejected message. 1141 Error messages are informational only, and the correctness of the 1142 protocol does not depend on them. 1144 Error reasons: 1146 TIMEOUT exchange has taken too long, state destroyed 1147 AEH_ERROR an unknown algorithm appears in an offer 1148 GROUP_NOT_SUPPORTED GRP named is not supported 1149 EXPONENTIAL_UNACCEPTABLE exponential too large/small 1150 SELECTION_NOT_OFFERED selection does not occur in offer 1151 NO_ACCEPTABLE_OFFERS no offer meets host requirements 1152 AUTHENTICATION_FAILURE signature or hash function fails 1153 RESOURCE_EXCEEDED too many exchanges or too much state info 1154 NO_EXCHANGE_IN_PROGRESS a reply received with no request in progress 1156 2.8 Additional Security for Privacy Keys: Private Groups 1158 If the two parties have need to use a Diffie-Hellman key 1159 determination scheme that does not depend on the standard group 1160 definitions, they have the option of establishing a private group. 1161 The authentication need not be repeated, because this stage of the 1162 protocol will be protected by a pre-existing authentication key. As 1163 an extra security measure, the two parties will establish a private 1164 name for the shared keying material, so even if they use exactly the 1165 same group to communicate with other parties, the re-use will not be 1166 apparent to passive attackers. 1168 Private groups have the advantage of making a widespread passive 1169 attack much harder by increasing the number of groups that would have 1170 to be exhaustively analyzed in order to recover a large number of 1171 session keys. This contrasts with the case when only one or two 1172 groups are ever used; in that case, one would expect that years and 1173 years of session keys would be compromised. 1175 There are two technical challenges to face: how can a particular user 1176 create a unique and appropriate group, and how can a second party 1177 assure himself that the proposed group is reasonably secure? 1179 The security of a modular exponentiation group depends on the largest 1180 prime factor of the group size. In order to maximize this, one can 1181 choose "strong" or Sophie-Germaine primes, P = 2Q + 1, where P and Q 1182 are prime. However, if P = kQ + 1, where k is small, then the 1183 strength of the group is still considerable. These groups are known 1184 as Schnorr subgroups, and they can be found with much less 1185 computational effort than Sophie-Germaine primes. 1187 Schnorr subgroups can also be validated efficiently by using probable 1188 prime tests. 1190 It is also fairly easy to find P, k, and Q such that the largest 1191 prime factor can be easily proven to be Q. 1193 We estimate that it would take about 10 minutes to find a new group 1194 of about 2^1024 elements, and this could be done once a day by a 1195 scheduled process; validating a group proposed by a remote party 1196 would take perhaps a minute on a 25 MHz RISC machine or a 66 MHz CISC 1197 machine. 1199 We note that validation is done only between previously mutually 1200 authenticated parties, and that a new group definition always follows 1201 and is protected by a key established using a well-known group. 1202 There are four points to keep in mind: 1204 a. The description and public identifier for the new group are 1205 protected by the well-known group. 1207 b. The responder can reject the attempt to establish the new 1208 group, either because he is too busy or because he cannot validate 1209 the largest prime factor as being sufficiently large. 1211 c. The new modulus and generator can be cached for long periods of 1212 time; they are not security critical and need not be associated 1213 with ongoing activity. 1215 d. Generating a new g^x value periodically will be more expensive 1216 if there are many groups cached; however, the importance of 1217 frequently generating new g^x values is reduced, so the time 1218 period can be lengthened correspondingly. 1220 2.8.1 Defining a New Group 1221 This section describes how to define a new group. The description of 1222 the group is hidden from eavesdroppers, and the identifier assigned 1223 to the group is unique to the two parties. Use of the new group for 1224 Diffie-Hellman key exchanges is described in the next section. 1226 The secrecy of the description and the identifier increases the 1227 difficulty of a passive attack, because if the group descriptor is 1228 not known to the attacker, there is no straightforward and efficient 1229 way to gain information about keys calculated using the group. 1231 Only the description of the new group need be encrypted in this 1232 exchange. The hash algorithm is implied by the OAKLEY session named 1233 by the group. The encryption is the authentication encryption 1234 function of the OAKLEY session. 1236 The descriptor of the new group is encoded in the new group payload. 1237 The nonces are encoded in the Auth Payload. 1239 Data beyond the encryption boundary is encrypted using the transform 1240 named by the KEYID. 1242 The following message use the ISAKMP Key Exchange Identifier OAKLEY 1243 New Group. 1245 To define a new modular exponentiation group: 1246 Initiator Responder 1247 --------- ---------- 1248 -> KEYID, -> 1249 INEWGRP, 1250 Desc(New Group), Na 1251 prf(sKEYID, Desc(New Group) | Na) 1253 <- KEYID, 1254 INEWGRPRS, 1255 Na, Nb 1256 prf(sKEYID, Na | Nb | Desc(New Group)) <- 1258 -> KEYID, 1259 INEWGRPACK 1260 prf(sKEYID, Nb | Na | Desc(New Group)) -> 1262 These messages are encrypted at the encryption boundary using the key 1263 indicated. The hash value is placed in the "digital signature" field 1264 (see Appendix C). 1266 New GRP identifier = Na | Nb (the initiator and responder must use 1267 nonces that are distinct from any used for current GRPID's. 1269 Desc(G) is the encoding of the descriptor for the group descriptor 1270 (see Appendix A for the format of a group descriptor) 1272 The two parties must store the mapping between the new group 1273 identifier GRP and the group descriptor Desc(New Group). They must 1274 also note the identities used for the KEYID and copy these to the 1275 state for the new group. 1277 Note that one could have the same group descriptor associated with 1278 several KEYID's. Pre-calculation of g^x values may be done based 1279 only on the group descriptor, not the private group name. 1281 2.8.2 Deriving a Key Using a Private Group 1283 Once a private group has been established, its group id can be used 1284 in the key exchange messages in the GRP position. No changes to the 1285 protocol are required. 1287 2.9 Quick Mode: New Keys From Old, 1289 When an authenticated KEYID and associated keying material sKEYID 1290 already exist, it is easy to derive additional KEYID's and keys 1291 sharing similar attributes (GRP, EHA, etc.) using only hashing 1292 functions. The KEYID might be one that was derived in Main Mode, for 1293 example. 1295 On the other hand, the authenticated key may be a manually 1296 distributed key, one that is shared by the initiator and responder 1297 via some means external to OAKLEY. If the distribution method has 1298 formed the KEYID using appropriately unique values for the two halves 1299 (CKY-I and CKY-R), then this method is applicable. 1301 In the following, the Key Exchange Identifier is OAKLEY Quick Mode. 1303 The nonces are carried in the Authentication Payload, and the prf 1304 value is carried in the Authentication Payload; the Authentication 1305 Authority is "None" and the type is "Pre-Shared". 1307 The protocol is: 1309 Initiator Responder 1310 --------- --------- 1311 -> KEYID, INEWKRQ, Ni, prf(sKEYID, Ni) -> 1312 <- KEYID, INEWKRS, Nr, prf(sKEYID, 1 | Nr | Ni) <- 1313 -> KEYID, INEWKRP, 0, prf(sKEYID, 0 | Ni | Nr) -> 1315 The New KEYID, NKEYID, is Ni | Nr 1317 sNKEYID = prf(sKEYID, Ni | Nr ) 1319 The identities and EHA values associated with NKEYID are the same as 1320 those associated with KEYID. 1322 Each party must validate the hash values before using the new key for 1323 any purpose. 1325 2.10 Defining and Using Pre-Distributed Keys 1327 If a key and an associated key identifier and state information have 1328 been distributed manually, then the key can be used for any OAKLEY 1329 purpose. The key must be associated with the usual state 1330 information: ID's and EHA algorithms. 1332 Local policy dictates when a manual key can be included in the OAKLEY 1333 database. For example, only privileged users would be permitted to 1334 introduce keys associated with privileged ID's, an unprivileged user 1335 could only introduce keys associated with her own ID. 1337 2.11 Distribution of an External Key 1338 Once an OAKLEY session key and ancillary algorithms are established, 1339 the keying material and the "H" algorithm can be used to distribute 1340 an externally generated key and to assign a KEYID to it. 1342 In the following, KEYID represents an existing, authenticated OAKLEY 1343 session key, and sNEWKEYID represents the externally generated keying 1344 material. 1346 In the following, the Key Exchange Identifier is OAKLEY External 1347 Mode. The Key Exchange Payload contains the new key, which is 1348 protected 1350 Initiator Responder 1351 --------- --------- 1352 -> KEYID, IEXTKEY, Ni, prf(sKEYID, Ni) -> 1354 <- KEYID, IEXTKEY, Nr, prf(sKEYID, 1 | Nr | Ni) <- 1355 -> KEYID, IEXTKEY, Kir xor sNEWKEYID*, prf(Kir, sNEWKEYID | Ni | Nr) -> 1357 Kir = prf(sKEYID, Ni | Nr) 1359 * this field is carried in the Key Exchange Payload. 1361 Each party must validate the hash values using the "H" function in 1362 the KEYID state before changing any key state information. 1364 The new key is recovered by the Responder by calculating the xor of 1365 the field in the Authentication Payload with the Kir value. 1367 The new key identifier, naming the keying material sNEWKEYID, is 1368 prf(sKEYID, 1 | Ni | Nr). 1370 Note that this exchange does not require encryption. Hugo Krawcyzk 1371 suggested the method and its advantage. 1373 2.11.1 Cryptographic Strength Considerations 1375 The strength of the key used to distribute the external key must be 1376 at least equal to the strength of the external key. Generally, this 1377 means that the length of the sKEYID material must be greater than or 1378 equal to the length of the sNEWKEYID material. 1380 The derivation of the external key, its strength or intended use are 1381 not addressed by this protocol; the parties using the key must have 1382 some other method for determining these properties. 1384 As of early 1996, it appears that for 90 bits of cryptographic 1385 strength, one should use a modular exponentiation group modulus of 1386 2000 bits. For 128 bits of strength, a 3000 bit modulus is required. 1388 3. Specifying and Deriving Security Associations 1390 When a security association is defined, only the KEYID need be given. 1391 The responder should be able to look up the state associated with the 1392 KEYID value and find the appropriate keying material, sKEYID. 1394 The OAKLEY protocol does not define security association encodings or 1395 message formats. These can be defined through a protocol such as 1396 ISAKMP. Compatibility with ISAKMP is a goal of the OAKLEY design, 1397 and coordination of the message formats and use of identifiers is an 1398 ongoing activity at this time. 1400 4. ISAKMP Compatibility 1402 OAKLEY uses ISAKMP header and payload formats, as described in the 1403 text and in Appendix B. There are particular noteworthy extensions 1404 beyond the version 4 draft. 1406 4.1 Authentication with Existing Keys 1408 In the case that two parties do not have suitable public key 1409 mechanisms in place for authenticating each other, they can use keys 1410 that were distributed manually. After establishment of these keys 1411 and their associated state in OAKLEY, they can be used for 1412 authentication modes that depend on signatures, e.g. Aggressive Mode. 1414 When an existing key is to appear in an offer list, it should be 1415 indicated with an Authentication Algorithm of ISAKMP_EXISTING. This 1416 value will be assigned in the ISAKMP RFC. 1418 When the authentication method is ISAKMP_EXISTING, the authentication 1419 authority will have the value ISAKMP_AUTH_EXISTING; the value for 1420 this field must not conflict with any authentication authority 1421 registered with IANA and will be defined in the ISAKMP RFC. 1423 The authentication payload will have two parts: 1425 the KEYID for the pre-existing key 1427 the identifier for the party to be authenticated by the pre- 1428 existing key. 1430 The pseudo-random function "H" in the state information for that 1431 KEYID will be the signature algorithm, and it will use the keying 1432 material for that key (sKEYID) when generating or checking the 1433 validity of message data. 1435 E.g. if the existing key has an KEYID denoted by KID and 128 bits of 1436 keying material denoted by sKID and "H" algorithm a transform named 1437 HMAC, then to generate a "signature" for a data block, the output of 1438 HMAC(sKID, data) 1439 will be the corresponding signature payload. 1441 The KEYID state will have the identities of the local and remote 1442 parties for which the KEYID was assigned; it is up to the local 1443 policy implementation to decide when it is appropriate to use such a 1444 key for authenticating other parties. For example, a key distributed 1445 for use between two Internet hosts A and B may be suitable for 1446 authenticating all identities of the form "alice@A" and "bob@B". 1448 4.2 Third Party Authentication 1450 A local security policy might restrict key negotiation to trusted 1451 parties. For example, two OAKLEY daemons running with equal 1452 sensitivity labels on two machines might wish to be the sole arbiters 1453 of key exchanges between users with that same sensitivity label. In 1454 this case, some way of authenticating the provenance of key exchange 1455 requests is needed. I.e., the identities of the two daemons should 1456 be bound to a key, and that key will be used to form a "signature" 1457 for the key exchange messages. 1459 The Signature Payload, in Appendix B, is for this purpose. This 1460 payload names a KEYID that is in existence before the start of the 1461 current exchange. The "H" transform for that KEYID is used to 1462 calculate an integrity/authentication value for all payloads 1463 preceding the signature. 1465 Local policy can dictate which KEYID's are appropriate for signing 1466 further exchanges. 1468 4.3 New Group Mode 1470 OAKLEY uses a new KEI for the exchange that defines a new group. 1472 5. Security Implementation Notes 1474 Timing attacks that are capable of recovering the exponent value used 1475 in Diffie-Hellman calculations have been described by Paul Kocher 1476 [Kocher]. In order to nullify the attack, implementors must take 1477 pains to obscure the sequence of operations involved in carrying out 1478 modular exponentiations. 1480 A "blinding factor" can accomplish this goal. A group element, r, is 1481 chosen at random. When an exponent x is chosen, the value r^(-x) is 1482 also calculated. Then, when calculating (g^y)^x, the implementation 1483 will calculate this sequence: 1484 A = (rg^y) 1485 B = A^x = (rg^y)^x = (r^x)(g^(xy)) 1486 C = B*r^(-x) = (r^x)(r^-(x))(g^(xy)) = g^(xy) 1488 The blinding factor is only necessary if the exponent x is used more 1489 than 100 times (estimate by Richard Schroeppel). 1491 6. OAKLEY Parsing and State Machine 1493 There are many pathways through OAKLEY, but they follow a left-to- 1494 right parsing patterns of the message fields as defined in section 1495 2.1. 1497 The initiator decides on an initial message in the following order: 1498 1. Offer a cookie. This is not necessary but it helps with 1499 aggressive exchanges. 1501 2. Pick a group. The choices are the well-known groups or any 1502 private groups that may have been negotiated. The very first 1503 exchange between two Oakley daemons with no common state must 1504 involve a well-known group (0, meaning no group, is a well-known 1505 group). Note that the group identifier, not the group descriptor, 1506 is used in the message. 1508 If a non-null group will be used, it must be included with the 1509 first message specifying EHAO. It need not be specified until 1510 then. 1512 3. If PFS will be used, pick an exponent x and present g^x. 1514 4. Offer Encryption, Hash, and Authentication lists. 1516 5. Use PFS for hiding the identities 1518 If identity hiding is not used, then the initiator has this 1519 option: 1521 6. Name the identities and include authentication information 1523 The information in the authentication section depends on the first 1524 authentication offer. In this aggressive exchange, the Initiator 1525 hopes that the Responder will accept all the offered information and 1526 the first authentication method. The authentication method 1527 determines the authentication payload as follows: 1529 1. Signing method. The signature will be applied to all the offered 1530 information. 1532 2. A public key encryption method. The algorithm will be used to 1533 encrypt a nonce in the public key of the requested Responder identity. 1534 There are two cases possible, depending on whether or not identity 1535 hiding is used: 1537 a. No identity hiding. The ID's will appear as plaintext. 1538 b. Identity hiding. A well-known ID, call it R', will appear as 1539 plaintext in the authentication payload. It will be followed 1540 by two ID's and a nonce; these will be encrypted using the 1541 public key for R'. 1543 3. A pre-existing key method. The pre-existing key will be used to 1544 encrypt a nonce. If identity hiding is used, the ID's will be 1545 encrypted in place in the payload, using the "E" algorithm associated 1546 with the pre-existing key. 1548 The Responder can accept all, part or none of the initial message. 1550 The Responder accepts as many of the fields as he wishes, using the 1551 same decision order as the initiator. At any step he can stop, 1552 implicitly rejecting further fields (which will have null values in 1553 his response message). The minimum response is a cookie and the GRP. 1555 1. Accept cookie. The Responder may elect to record no state 1556 information until the Initiator successfully replies with a cookie 1557 chosen by the responder. If so, the Responder replies with a cookie, 1558 the GRP, and no other information. 1560 2. Accept GRP. If the group is not acceptable, the Responder will 1561 not reply. The Responder may send an error message indicating the 1562 the group is not acceptable (modulus too small, unknown identifier, 1563 etc.) Note that "no group" has two meanings during the protocol: it 1564 may mean the group is not yet specified, or it may mean that no group 1565 will be used (and thus PFS is not possible). 1567 3. Accept the g^x value. The Responder indicates his acceptance of 1568 the g^x value by including his own g^y value in his reply. He can 1569 postpone this by ignoring g^x and putting a zero length g^y value in 1570 his reply. 1572 4. Accept one element from each of the EHA lists. The acceptance is 1573 indicated by a non-zero proposal. 1575 5. If PFS for identity hiding is requested, then no further data will 1576 follow. 1578 6. If the authentication payload is present, and if the first item in 1579 the offered authentication class is acceptable, then the Responder 1580 must validate/decrypt the information in the authentication payload 1581 and signature payload, if present. The Responder should choose a 1582 nonce and reply using the same authentication/hash algorithm as the 1583 Initiator used. 1585 The Initiator notes which information the Responder has accepted, 1586 validates/decrypts any signed, hashed, or encrypted fields, and if 1587 the data is acceptable, replies in accordance to the EHA methods 1588 selected by the Responder. The Initiator replies are distinguished 1589 from his initial message by the presence of the non-zero value for 1590 the Responder cookie. 1592 APPENDIX A Group Descriptors 1594 Three distinct group representations can be used with OAKLEY. Each 1595 group is defined by its group operation and the kind of underlying 1596 field used to represent group elements. The three types are modular 1597 exponentiation groups (named MODP herein), elliptic curve groups 1598 over the field GF[2^N] (named EC2N herein), and elliptic curve groups 1599 over GF[P] (named ECP herein) For each representation, many distinct 1600 realizations are possible, depending on parameter selection. 1602 With a few exceptions, all the parameters are transmitted as if they 1603 were non-negative multi-precision integers, using the format defined 1604 in this appendix (note, this is distinct from the encoding in Appendix 1605 D). Every multi-precision integer has a prefixed length field, even 1606 where this information is redundant. 1608 For the group type EC2N, the parameters are more properly thought of 1609 as very long bit fields, but they are represented as multi-precision 1610 integers, (with length fields, and right-justified). This is the 1611 natural encoding. 1613 MODP means the classical modular exponentiation group, where the 1614 operation is to calculate G^X (mod P). The group is defined by 1615 the numeric parameters P and G. P must be a prime. G is often 2, 1616 but may be a larger number. 2 <= G <= P-2. 1618 ECP is an elliptic curve group, modulo a prime number P. 1619 The defining equation for this kind of group is 1620 Y^2 = X^3 + AX + B 1621 The group operation is taking a multiple of an elliptic-curve point. 1622 The group is defined by 5 numeric parameters: The prime P, two curve 1623 parameters A and B, and a generator (X,Y). A,B,X,Y are all 1624 interpreted mod P, and must be (non-negative) integers less than P. 1625 They must satisfy the defining equation, modulo P. 1627 EC2N is an elliptic curve group, over the finite field F[2^N]. The 1628 defining equation for this kind of group is 1629 Y^2 + XY = X^3 + AX^2 + B 1630 (This equation differs slightly from the mod P case: it has an XY 1631 term, and an AX^2 term instead of an AX term.) 1633 We must specify the field representation, and then the elliptic 1634 curve. The field is specified by giving an irreducible polynomial 1635 (mod 2) of degree N. This polynomial is represented as an integer of 1636 size between 2^N and 2^(N+1), as if the defining polynomial were 1637 evaluated at the value U=2. 1639 For example, the field defined by the polynomial 1640 U^155 + U^62 + 1 1641 is represented by the integer 2^155 + 2^62 + 1. The group is defined 1642 by 4 more parameters, A,B,X,Y. These parameters are elements of the 1643 field F[2^N], and can be though of as polynomials of degree < N, with 1644 (mod 2) coefficients. They fit in N-bit fields, and are represented 1645 as integers < 2^N, as if the polynomial were evaluated at U=2. For 1646 example, the field element U^2 + 1 would be represented by the 1647 integer 2^2+1, which is 5. The two parameters A and B define the 1648 curve. A is frequently 0. B must not be 0. The parameters X and Y 1649 select a point on the curve. The parameters A,B,X,Y must satisfy the 1650 defining equation, modulo the defining polynomial, and mod 2. 1652 Group descriptor formats: 1654 Type of group: A two-byte field, 1655 assigned values for the types "MODP", "ECP", "EC2N" 1656 will be defined (see ISAKMP-04). 1657 Size of a field element, in bits. This is either Ceiling(log2 P) 1658 or the degree of the irreducible polynomial: a 32-bit integer. 1659 The prime P or the irreducible field polynomial: a multi-precision integer. 1660 The generator: 1 or 2 values, multi-precision integers. 1661 EC only: The parameters of the curve: 2 values, multi-precision integers. 1663 The following parameters are Optional (each of these may appear 1664 independently): 1665 a value of 0 may be used as a place-holder to represent an unspecified 1666 parameter; any number of the parameters may be sent, from 0 to 3. 1668 The largest prime factor: the encoded value that is the LPF of the group size, 1669 a multi-precision integer. 1671 EC only: The order of the group: multi-precision integer. 1672 (The group size for MODP is always P-1.) 1674 Strength of group: 32-bit integer. 1675 The strength of the group is approximately the number of key-bits protected. 1676 It is determined by the log2 of the effort to attack the group. 1677 It may change as we learn more about cryptography. 1679 This is a generic example for a "classic" modular exponentiation group: 1680 Group type: "MODP" 1681 Size of a field element in bits: Log2 (P) rounded *up*. A 32bit integer. 1682 Defining prime P: a multi-precision integer. 1683 Generator G: a multi-precision integer. 2 <= G <= P-2. 1684 1685 Largest prime factor of P-1: the multi-precision integer Q 1686 Strength of group: a 32-bit integer. We will specify a formula 1687 for calculating this number (TBD). 1689 This is a generic example for elliptic curve group, mod P: 1690 Group type: "ECP" 1691 Size of a field element in bits: Log2 (P) rounded *up*, 1692 a 32 bit integer. 1693 Defining prime P: a multi-precision integer. 1694 Generator (X,Y): 2 multi-precision integers, each < P. 1695 Parameters of the curve A,B: 2 multi-precision integers, each < P. 1696 1697 Largest prime factor of the group order: a multi-precision integer. 1699 Order of the group: a multi-precision integer. 1700 Strength of group: a 32-bit integer. Formula TBD. 1702 This is a specific example for elliptic curve group: 1703 Group type: "EC2N" 1704 Degree of the irreducible polynomial: 155 1705 Irreducible polynomial: U^155 + U^62 + 1, represented as the 1706 multi-precision integer 2^155 + 2^62 + 1. 1707 Generator (X,Y) : represented as 2 multi-precision integers, each < 2^155. 1708 For our present curve, these are (decimal) 123 and 456. Each is represented 1709 as a multi-precision integer. 1710 Parameters of the curve A,B: represented as 2 multi-precision 1711 integers, each < 2^155. 1712 For our present curve these are 0 and (decimal) 471951, represented as two 1713 multi-precision integers. 1715 1716 Largest prime factor of the group order: 1718 3805993847215893016155463826195386266397436443, 1720 represented as a multi-precision integer. 1721 The order of the group: 1723 45671926166590716193865565914344635196769237316 1725 represented as a multi-precision integer. 1727 Strength of group: 76, represented as a 32-bit integer. 1729 The variable precision integer encoding for group descriptor fields 1730 is the following. This is a slight variation on the format defined 1731 in Appendix D in that a fixed 16-bit value is used first, and the 1732 length is limited to 16 bits. However, the interpretation is 1733 otherwise identical. 1735 1 2 3 1736 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 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 ! Fixed value (TBD) ! Length ! 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 . . 1741 . Integer . 1742 . . 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 The format of a group descriptor is: 1746 1 2 3 1747 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 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 !1!1! Group Description ! MODP ! 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 !1!0! Field Size ! Length ! 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 ! MPI ! 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 !1!0! Prime ! Length ! 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 ! MPI ! 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 !1!0! Generator1 ! Length ! 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 ! MPI ! 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 !1!0! Generator2 ! Length ! 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 ! MPI ! 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 !1!0! Curve-p1 ! Length ! 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 ! MPI ! 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 !1!0! Curve-p2 ! Length ! 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 ! MPI ! 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 !1!0! Largest Prime Factor ! Length ! 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 ! MPI ! 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 !1!0! Order of Group ! Length ! 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 ! MPI ! 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 !0!0! Strength of Group ! Length ! 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 ! MPI ! 1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 APPENDIX B Message formats 1790 1. The ISAKMP Message Types and Header 1792 OAKLEY uses the ISAKMP Message Types ISA_KE&AUTH_REQ and 1793 ISA_KE&AUTH_REP for all key exchanges. 1795 1 2 3 1796 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 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 ! ! 1799 ~ Initiator-Cookie ~ 1800 / ! ! 1801 KEYID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 \ ! ! 1803 ~ Responder-Cookie ~ 1804 ! ! 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 ! Message Type ! Exch ! Vers ! Length ! 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 ! (unused) ! 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 ! (unused) ! 1811 eeee +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ eeee 1812 ! ... ! 1814 "eeee" represents the encryption boundary for messages requiring privacy. 1815 The message after this point is subject to the encryption transform implied 1816 by the KEYID. 1818 The Group ID field is used for the group identifier for the key 1819 exchange methods described in this document; in other ISAKMP messages 1820 the field is used for a SPI. OAKLEY does not use the two SPI fields 1821 in an ISAKMP header. 1823 The second SPI field is not used in OAKLEY. It must contain the 1824 value zero. 1826 The OAKLEY proposal format contains the SA attributes that are 1827 exchanged in the ISA_INIT messages in order to establish the required 1828 security attributes for the key and authentication exchange. 1830 2. OAKLEY Use of ISA_AUTH&KE packets. 1832 1 2 3 1833 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 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 ~ ISAKMP Header ~ 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 ! Domain of Interpretation ! 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 ! Next Payload ! Payload Len ! RESERVED ! 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 ~ ~ 1842 ! Authentication Payload ! 1843 ~ ~ 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 ! Next Payload ! Payload Len ! RESERVED ! 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 ~ ~ 1848 ! Key Exchange Payload ! 1849 ~ ~ 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 ISA_AUTH&KE_REQ and ISA_AUTH&KE_RESP Packet Format 1853 The encodings of the OAKLEY parameters into these fields are 1854 described in the next sections. 1856 3. The Key Exchange Payload 1858 The Key Exchange Payload carries values that are used to derive 1859 secret keying material. Because OAKLEY uses both nonces and Diffie- 1860 Hellman exponentials for deriving keys, its use of the Key Exchange 1861 Payload is slightly different from the use described in ISAKMP; that 1862 document expects only one Key Exchange Payload per packet, but OAKLEY 1863 can have two, one for nonces, one for an exponential. 1865 1 2 3 1866 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 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 ! Next Payload ! Payload Len ! RESERVED ! 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 ! KEI ! Length ! 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 ~ ~ 1873 ! Key Exchange Data ! 1874 ~ ~ 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 Key Exchange Payload Format 1879 o KEI (2 octets) - Key Exchange Identifier 1881 o Length (2 octets) - Length of payload in octets 1883 o Key Exchange Data (variable) - Data required to 1884 create session key. 1886 OAKLEY uses four KEI values: OAKLEY Main Mode, OAKLEY Quick Mode, 1887 OAKLEY External Mode, OAKLEY New Group Mode. 1889 The value encoded in the Key Exchange Data field will be the Diffie- 1890 Hellman exponential (if it is used), encoded as variable precision 1891 integers as shown in Appendix D. For Oakley External Mode, the field 1892 will contain the external key. 1894 3. The OAKLEY Authentication Payload 1896 1 2 3 1897 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 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 ! Next Payload ! Payload Len ! RESERVED ! 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 ! Authentication Authority ! Reserved ! 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 ! Authentication Type ! Length ! 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 ~ ~ 1906 ! Authentication Data ! 1907 ~ ~ 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 Authentication Payload Format 1912 The Authentication Payload will be used to carry three pieces of 1913 essential information: the entity identifiers (ID's), the nonces, and 1914 the output of a function proving proving knowledge of a secret. 1916 The format of the ID's is described in the next section. A payload 1917 will have two ID's, for the Initiator and Responder, in that order. 1918 If the length of an ID is zero, the ID is unspecified. 1920 If the low order bit of the RESERVED field is set, the payload will 1921 have three ID's; see section 2.4.2, An Aggressive Example With Hidden 1922 Identities. Note that in this case, only the first ID will be in 1923 plaintext. The two following ID's and the encrypted nonce (see next 1924 paragraph) will be encrypted in the public key of the first ID. 1926 The nonce will follow the ID's; if a nonce is encoded with zero 1927 length, it is considered to be not present. If the low order bit of 1928 the RESERVED field is set, as in 2.4.2, then the nonce will be 1929 encrypted in the public key of the requested responder. 1931 The fourth part of the authentication payload will contain the result 1932 of applying the pseudorandom function or signature algorithm to the 1933 key exchange parameters, as described in the main text. For example, 1934 the output might be the result of applying a keyed MD5 transform to 1935 the ID's, the cookies, the nonces, and the exponentials. 1937 The pseudorandom function output will encoded as a variable precision 1938 integer as described in Appendix D. 1940 The Authentication Authority and Authentication Type will be taken 1941 from the ISAKMP requirements: 1943 If the second-most low order bit is set, it means that the remainder 1944 of the message is encrypted a key derived from the Diffie-Hellman 1945 g^xy value (this is the IDP bit). 1947 o Authentication Authority (2 octets) - This field identifies 1948 the party 1949 that generated the certificates used for authentication. 1950 Authorities 1951 must be assigned an identifier by the Internet Assigned 1953 Numbers 1954 Authority (IANA). Before being assigned an identifier, an 1955 authority 1956 must publish an RFC defining the authority's domain. [RFC- 1957 1422] 1958 describes the Internet Policy Registration Authority (IPRA) 1959 and the 1960 procedures for achieving this registration. 1962 If PGP certificates, based on the ``web of trust'', are 1963 carried in 1964 the authentication payload the Authentication Authority value 1965 is one 1966 (1). 1968 Example certificate authorities that would have to register 1969 for an 1970 identifier are: 1972 -- RSA Commercial Certificate Authority 1973 (http://www_csc.rsa.com/netsite) 1975 -- Stable Large E-mail Database (SLED) 1976 (http://www.four11.com) 1978 -- U.S. Postal Service. 1980 o Authentication Type (2 octets) - This field indicates the 1981 authentication payload format. This field is used by 1982 authentication 1983 authorities that support more than one certificate type. The 1984 authentication types supported by an authentication authority 1985 must be 1986 defined in the RFC required for authentication authority 1987 registration. Examples are: 1989 -- PKCS #7 certificates 1991 -- PGP certificates 1993 -- DNS Signed Keys 1995 -- Kerberos Tokens 1997 -- X.509 certificates 1999 o Length (2 octets) - Length of the Authentication Data field in 2000 octets. 2002 o Authentication Data (variable) - Actual authentication data. 2004 The 2005 type of certificate is indicated by the Authentication Type 2006 field. 2008 4. The OAKLEY Proposal 2010 1 2 3 2011 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 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 ! OAKLEY ! Proposal # ! Proposal Len ! RESERVED ! 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 ! EHA Format ! 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 ! Group Format ! 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 OAKLEY Proposal Format 2022 1 2 3 2023 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 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2025 !0!1! RESERVED ! GRP ! 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 ! GRPID ! 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 !0!1! GRP ! PRIV ! 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 !0!1! Encryption Algorithm ! DES ! 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 !0!1! Hash Algorithm ! MD5 ! 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 !1!1! Authentication Alg ! RSA ! 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 !0!1! Authentication Mode ! KEYED ! 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 OAKLEY Proposal - EHA Format 2042 5. Identity (ID) formats 2043 1 2 3 2044 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 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 ! Identification Type ! Length ! 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 ~ ~ 2049 ! Identification Data ! 2050 ~ ~ 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 There are three identification types: IP_ADDR (value 1), FQDN (value 2054 2), USER_FQDN (value 3). 2056 The length of the IP address will be 4 bytes for the IPv4 Domain of 2057 Interpretation, 8 bytes for the IPv6 DOI. 2059 FQDN is a fully qualified domain name, as used by the DNS protocol. 2060 Its form is an ASCII character string. The domain components are 2061 separated by "." characters, as in DNS. 2063 USER_FQDN is a user id followed by a "." character, followed by a 2064 fully qualified domain name, as used by the DNS protocol. Its form 2065 is an ASCII character string. 2067 6. OAKLEY's use ISA_INIT_REQ and ISA_INIT_RESP Packets 2069 OAKLEY does not require the use the ISAKMP ISA_INIT_REQ and 2070 ISA_INIT_RESP packets. Their optional use may include the 2071 establishment of ISAKMP-to-ISAKMP daemon KEYID's for later use as 2072 signatures over ISA_KE&AUTH packets, providing an extra level of 2073 authenticity checking. In this case, the Situation field will have 2074 the IP addresses of the two principals; the length of the IP address 2075 will depend on the Domain of Interpretation. 2077 1 2 3 2078 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 2079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 ~ ISAKMP Header ~ 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 ! Next Payload ! Payload Len ! RESERVED ! 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 ! Domain of Interpretation ! 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 ! ! 2087 ~ Situation ~ 2088 ! ! 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 ! ! 2091 ~ Proposal ~ 2092 ! ! 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 ISA_INIT_REQ and ISA_INIT_RESP Packet Format 2097 7. Digital Signature/PRF Payload 2099 The Digital Signature/PRF payload will carry a value for 2100 authenticating the entire message. When it occurs, it will be the 2101 last payload. 2103 1 2 3 2104 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 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 ! KEYID ! 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 ~ ~ 2110 ! Signature/hash data ! 2111 ~ ~ 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 The output of the signature or prf function will be encoded as a 2115 variable precision integer as described in Appendix D. The KEYID 2116 will indicate KEYID that names keying material and the Hash or 2117 Signature function. 2119 8. The Credential Payload 2121 Useful certificates with public key information can be attached to 2122 OAKLEY messages using Credential Payloads. The format of the payload 2123 depends on the Authentication Type, and separate RFC's define the 2124 formats. The encoding of the Authority and Type are the same as for 2125 the Authentication Payload. 2127 1 2 3 2128 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 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 ! Next Payload ! Payload Len ! RESERVED ! 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 ! Authentication Authority ! Reserved ! 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 ! Authentication Type ! Length ! 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 ~ ~ 2137 ! Credential Data ! 2138 ~ ~ 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 Credential Payload Format 2143 APPENDIX D Encoding a variable precision integer. 2145 Variable precision integers will be encoded as a 32-bit length field 2146 followed by one or more 32-bit quantities containing the 2147 representation of the integer, aligned with the most significant bit 2148 in the first 32-bit item. 2150 1 2 3 2151 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 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 ! length ! 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 ! first value word (most significant bits) ! 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 ! ! 2158 ~ additional value words ~ 2159 ! ! 2160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 An example of such an encoding is given below, for a number with 51 2163 bits of significance. The length field indicates that 2 32-bit 2164 quantities follow. The most significant non-zero bit of the number 2165 is in bit 13 of the first 32-bit quantity, the low order bits are in 2166 the second 32-bit quantity. 2168 1 2 3 2169 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 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 ! 1 0! 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 !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! 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 !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! 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 APPENDIX E Cryptographic strengths 2180 The Diffie-Hellman algorithm is used to compute keys that will be 2181 used with symmetric algorithms. It should be no easier to break the 2182 Diffie-Hellman computation than it is to do an exhaustive search over 2183 the symmetric key space. A recent recommendation by an group of 2184 cryptographers [Blaze-Diffie-et-al] has recommended a symmetric key 2185 size of 75 bits for a practical level of security. For 20 year 2186 security, they recommend 90 bits. 2188 Based on that report, a conservative strategy for OAKLEY users would 2189 be to ensure that their Diffie-Hellman computations were as secure as 2190 at least a 90-bit key space. In order to accomplish this for modular 2191 exponentiation groups, the size of the largest prime factor of the 2192 modulus should be at least 180 bits, and the size of the modulus 2193 should be at least 1400 bits. For elliptic curve groups, the LPF 2194 should be at least 180 bits. 2196 If long-term secrecy of the encryption key is not an issue, then the 2197 following parameters may be used for the modular exponentiation 2198 group: 150 bits for the LPF, 980 bits for the modulus size. 2200 The modulus size alone does not determine the strength of the 2201 Diffie-Hellman calculation; the size of the exponent used in 2202 computing powers within the group is also important. The size of the 2203 exponent in bits should be at least twice the size of any symmetric 2204 key that will be derived from it. We recommend that ISAKMP 2205 implementors use at least 180 bits of exponent (twice the size of a 2206 20-year symmetric key). 2208 The mathematical justification for these estimates can be found in 2209 texts that estimate the effort for solving the discrete log problem, 2210 a task that is strongly related to the efficiency of using the Number 2211 Field Sieve for factoring large integers. Readers are referred to 2212 [Stinson] and [Schneier]. 2214 APPENDIX F The Well-Known Groups 2216 This section will have explicit descriptors for three modular 2217 exponentiation groups and two elliptic curve over GF[2^n] groups. 2219 The identifiers for the groups (the well-known GRP's) will also be 2220 given here. 2222 0 No group (used as a placeholder and for non-DH exchanges) 2223 1 A modular exponentiation group with a 768 bit modulus (TBD) 2224 2 A modular exponentiation group with a 1024 bit modulus (TBD) 2225 3 A modular exponentiation group with a 2048 bit modulus (TBD) 2226 4 An elliptic curve group over GF[2^155] 2227 5 An elliptic curve group over GF[2^210] 2229 values 2^32 and higher are used for private group identifiers 2231 Appendix K Implementing Group Operations 2233 The group operation must be implemented as a sequence of arithmetic 2234 operations; the exact operations depend on the type of group. For 2235 modular exponentiation groups, the operation is multi-precision 2236 integer multiplication and remainders by the group modulus. See 2237 Knuth Vol. 2 [Knuth] for a discussion of how to implement these for 2238 large integers. Implementation recommendations for elliptic curve 2239 group operations over GF[2^N] are described in [Schroeppel]. 2241 BIBLIOGRAPHY 2243 [RFC1825] Atkinson, Randall, RFC's 1825-1827 2245 [Blaze] Blaze, Matt et al., Recent symmetric key report 2247 [STS] Diffie, van Oorschot, and Wiener, Authentication and 2248 Authenticated Key Exchanges 2250 [DSS] DSS draft-ietf-ipsec-dss-cert-00.txt 2252 [SECDNS] DNS Signed Keys, Eastlake & Kaufman, 2253 draft-ietf-dnssec-secext-09.txt 2255 [Photuris] Karn, Phil and Simpson, William, Photuris, draft-ietf- 2256 ipsec-photuris-09.txt 2258 [Kocher] Kocher, Paul, Timing Attack 2260 [Krawcyzk] Krawcyzk, Hugo, SKEME, ISOC, SNDS Symposium, San Diego, 2261 1996 2263 [PKIX] PKIX internet drafts, draft-ietf-pkix-ipki-00.txt 2265 [Random] Random number RFC 1750 2267 [ISAKMP] Schertler, Mark, ISAKMP, draft-ietf-ipsec-isakmp-03.txt and 2268 draft-ietf-ipsec-isakmp-04.txt. The transition from version 3 to 2269 version 4 was in progress at the time of this writing. 2271 [Schneier] Schneier, Bruce, Applied cryptography: protocols, 2272 algorithms, and source code in C, Second edition, John Wiley & Sons, 2273 Inc. 1995, ISBN 0-471-12845-7, hardcover. ISBN 0-471-11709-9, 2274 softcover. 2276 [Schroeppel] Schroeppel, Richard, et al.; Fast Key Exchange with 2277 Elliptic Curve Systems, Crypto '95, Santa Barbara, 1995. Available 2278 on-line as ftp://ftp.cs.arizona.edu/reports/1995/TR95-03.ps (and .Z). 2280 [Stinson] Stinson, Douglas, Cryptography Theory and Practice. CRC 2281 Press, Inc., 2000, Corporate Blvd., Boca Raton, FL, 33431-9868, ISBN 2282 0-8493-8521-0, 1995 2284 [Zimmerman] Philip Zimmermann, The Official Pgp User's Guide, 2285 Published by MIT Press Trade, Publication date: June 1995, ISBN: 2286 0262740176 2288 This draft expires six months from the day of issue. The 2289 expiration date will be August 24, 1996.