idnits 2.17.1 draft-ietf-ipsec-ciph-des3-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) 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. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 1997) is 9775 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: 'Piermont' is mentioned on line 5, but not defined == Missing Reference: 'DayDreamer' is mentioned on line 7, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellovin96' -- Possible downref: Non-RFC (?) normative reference: ref. 'BS93' -- Possible downref: Non-RFC (?) normative reference: ref. 'CN94' -- Possible downref: Non-RFC (?) normative reference: ref. 'CW92' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-74' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-81' -- Possible downref: Non-RFC (?) normative reference: ref. 'IB93' -- Possible downref: Non-RFC (?) normative reference: ref. 'IBK93' -- Possible downref: Non-RFC (?) normative reference: ref. 'Matsui94' -- Possible downref: Non-RFC (?) normative reference: ref. 'MH81' -- Possible downref: Non-RFC (?) normative reference: ref. 'OW91' ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-wwww' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Tuchman79' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N Doraswamy 3 Internet Draft [Bay Networks] 4 P Metzger 5 [Piermont] 6 W A Simpson 7 [DayDreamer] 8 expires in six months July 1997 10 The ESP Triple DES Transform 11 draft-ietf-ipsec-ciph-des3-00.txt 13 Status of this Memo 15 Follows draft-simpson-esp-des3-x-01.txt. 17 This document is an Internet-Draft. Internet Drafts are working doc- 18 uments of the Internet Engineering Task Force (IETF), its Areas, and 19 its Working Groups. Note that other groups may also distribute work- 20 ing documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months, and may be updated, replaced, or obsoleted by other documents 24 at any time. It is not appropriate to use Internet Drafts as refer- 25 ence material, or to cite them other than as a ``working draft'' or 26 ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 30 Directories on: 32 ftp.is.co.za (Africa) 33 nic.nordu.net (Europe) 34 ds.internic.net (US East Coast) 35 ftp.isi.edu (US West Coast) 36 munnari.oz.au (Pacific Rim) 38 Distribution of this memo is unlimited. 40 Astract 42 This document describes the "Triple" DES-EDE3-CBC block cipher trans- 43 form interface used with the IP Encapsulating Security Payload (ESP). 44 It provides compatible migration from RFC-1851. 46 1. Introduction 48 The Encapsulating Security Payload (ESP) [RFC-1827x] provides confi- 49 dentiality for IP datagrams by encrypting the payload data to be pro- 50 tected. This specification describes the ESP use of a variant of the 51 Cipher Block Chaining (CBC) mode of the US Data Encryption Standard 52 (DES) algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81]. 54 This variant, colloquially known as "Triple DES", processes each 55 block three times, each time with a different key [Tuchman79]. 57 For an explanation of the use of CBC mode with this cipher, see [RFC- 58 wwww]. 60 For more explanation and implementation information for Triple DES, 61 see [Schneier95]. 63 This document assumes that the reader is familiar with the related 64 document "Security Architecture for the Internet Protocol" 65 [RFC-1825x], that defines the overall security plan for IP, and pro- 66 vides important background for this specification. 68 In this document, the key words "MAY", "MUST", "recommended", 69 "required", and "SHOULD", are to be interpreted as described in 70 [RFC-2119]. 72 1.1. Availability 74 There were a number of US patents (see [Schneier95] for listing). 75 All patents have expired. Several freely available implementations 76 have been published world-wide. 78 1.2. Performance 80 As this specification requires "outer" chaining, it is not possible 81 to provide parallel computation for the same data stream. Triple DES 82 is approximately 2.5 times slower than "single" DES (rather than 3 83 times), because inner permutations may be removed. 85 Phil Karn has tuned DES-EDE3-CBC software to achieve 6.22 Mbps with a 86 133 MHz Pentium. Other DES speed estimates may be found at 87 [Schneier95, page 279]. Your milage may vary. 89 2. Description 90 2.1. Block Size 92 The US Data Encryption Standard (DES) algorithm operates on blocks of 93 64-bits (8 bytes). This often requires padding before encrypting, 94 and subsequent removal of padding after decrypting. 96 The output is the same number of bytes that are input. This facili- 97 tates in-place encryption and decryption. 99 2.2. Mode 101 P1 P2 Pi 102 | | | 103 IV->->(X) +>->->->(X) +>->->->(X) 104 v ^ v ^ v 105 +-----+ ^ +-----+ ^ +-----+ 106 k1->| E | ^ k1->| E | ^ k1->| E | 107 +-----+ ^ +-----+ ^ +-----+ 108 | ^ | ^ | 109 v ^ v ^ v 110 +-----+ ^ +-----+ ^ +-----+ 111 k2->| D | ^ k2->| D | ^ k2->| D | 112 +-----+ ^ +-----+ ^ +-----+ 113 | ^ | ^ | 114 v ^ v ^ v 115 +-----+ ^ +-----+ ^ +-----+ 116 k3->| E | ^ k3->| E | ^ k3->| E | 117 +-----+ ^ +-----+ ^ +-----+ 118 | ^ | ^ | 119 +>->->+ +>->->+ +>->-> 120 | | | 121 C1 C2 Ci 123 The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC algo- 124 rithm [RFC-wwww, RFC-1829x]. The "outer" chaining technique is used. 126 In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with the 127 first 64-bit (8 byte) plaintext block (P1). The keyed DES function 128 is iterated three times, an encryption (Ek1) followed by a decryption 129 (Dk2) followed by an encryption (Ek3), and generates the ciphertext 130 (C1) for the block. Each iteration uses an independant key: k1, k2 131 and k3. 133 For successive blocks, the previous ciphertext block is XOR'd with 134 the current plaintext (Pi). The keyed DES-EDE3 encryption function 135 generates the ciphertext (Ci) for that block. 137 To decrypt, the order of the functions is reversed: decrypt with k3, 138 encrypt with k2, decrypt with k1, and XOR the previous ciphertext 139 block. 141 Note that when all three keys (k1, k2 and k3) are the same, DES- 142 EDE3-CBC is equivalent to DES-CBC. This property allows the DES-EDE3 143 hardware implementations to operate in DES mode without modification. 145 2.3. Interaction with Authentication 147 There is no known interaction of DES with any currently specified 148 Authenticator algorithm. Never-the-less, any Authenticator MUST use 149 a separate and independently generated key. 151 3. Initialization Vector 153 DES-EDE3-CBC requires an Initialization Vector (IV) that is 64-bits 154 (8 bytes) in length [RFC-wwww]. 156 By default, the 64-bit IV is generated from the 32-bit ESP Sequence 157 Number field followed by (concatenated with) the bit-wise complement 158 of the same 32-bit value: 160 SN || -SN 162 Alternative IV generation techniques MAY be specified when dynami- 163 cally configured via a key management protocol. 165 Security Notes: 167 Using the Sequence Number provides an easy method for preventing 168 IV repetition, and is sufficiently robust for practical use with 169 the DES algorithm. But, when used alone, cryptanalysis might be 170 aided by the rare serendipitous occurrence when the Sequence Num- 171 ber increments in exactly the same fashion as a corresponding bit 172 position in the first block. 174 No commonly used IP (Next Header) Protocols exhibit this property. 175 Never-the-less, inclusion of the bit-wise complement ensures that 176 Sequence Number bit changes are reflected twice in the IV. 178 4. Keys 180 The secret DES-EDE3 key shared between the communicating parties is 181 effectively 168-bits long. This key consists of three independent 182 56-bit quantities used by the DES algorithm. Each of the three 183 56-bit sub-keys is stored as a 64-bit (8 byte) quantity, with the 184 least significant bit of each byte used as a parity bit. 186 4.1. Weak Keys 188 DES has 64 known weak keys, including so-called semi-weak keys and 189 possibly-weak keys [Schneier95, pp 280-282]. The likelihood of pick- 190 ing one at random is negligible. 192 For DES-EDE3, there is no known need to reject weak or complementa- 193 tion keys. Any weakness is obviated by the other keys. 195 However, since checking for weak keys is quite easy, the configura- 196 tion mechanisms are expected to incorporate the test. 198 4.2. Manual Key Management 200 When configured manually, three independently generated keys are 201 required, in the order used for encryption, and 64-bits (8 bytes) are 202 configured for each individual key. 204 Keys with incorrect parity SHOULD be rejected by the configuration 205 utility, ensuring that the keys have been correctly configured. 207 Each key is examined sequentially, in the order used for encryption. 208 A key that is identical to a previous key MAY be rejected. The 64 209 known weak DES keys [RFC-1829x] SHOULD be rejected. 211 4.3. Automated Key Management 213 When configured via a Security Association management protocol, three 214 independently generated keys are required, in the order used for 215 encryption, and 64-bits (8 bytes) are returned for each individual 216 key. 218 The key manager MAY be required to generate the correct parity. 219 Alternatively, the least significant bit of each key byte is ignored, 220 or locally set to parity by the DES implementation. 222 Each key is examined sequentially, in the order used for encryption. 224 A key that is identical to a previous key MUST be rejected. The 64 225 known weak DES keys [RFC-1829x] MUST be rejected. 227 4.4. Refresh Rate 229 To prevent differential and linear cryptanalysis of collisions [RFC- 230 wwww], no more than 2**32 plaintext blocks SHOULD be encrypted with 231 the same key. Depending on the average size of the datagrams, the 232 key SHOULD be changed at least as frequently as 2**30 datagrams. 234 5. ESP Alterations 235 5.1. ESP Sequence Number 237 The Sequence Number is a 32-bit (4 byte) unsigned counter. This 238 field protects against replay attacks, and may also be used for syn- 239 chronization by stream or block-chaining ciphers. 241 When configured manually, the first value sent SHOULD be a random 242 number. The limited anti-replay security of the sequence of data- 243 grams depends upon the unpredictability of the values. 245 When configured via an automated Security Association management pro- 246 tocol, the first value sent is 1, unless otherwise negotiated. 248 Thereafter, the value is monotonically increased for each datagram 249 sent. A replacement SPI SHOULD be established before the value 250 repeats. That is, no more than 2**32 datagrams SHOULD be sent with 251 any single key. 253 5.2. ESP Padding 255 The Padding field may be zero or more bytes in length. 257 Prior to encryption, this field is filled with a series of integer 258 values to align the Pad Length and Payload Type fields at the end of 259 a 64-bit (8 byte) block boundary (measured from the beginning of the 260 Transform Data). 262 By default, each byte contains the index of the byte. For example, 263 three pad bytes would contain the values 1, 2, 3. 265 After decryption, this field MAY be examined for a valid series of 266 integer values. Verification of the sequence of values is at the 267 discretion of the receiver. 269 Operational Considerations 271 The specification provides only a few manually configurable parame- 272 ters: 274 SPI 275 Manually configured SPIs are limited in range to aid operations. 276 Automated SPIs are pseudo-randomly distributed throughout the 277 remaining 2**32 values. 279 Default: 0 (none). Range: 256 to 65,535. 281 SPI LifeTime (SPILT) 282 Manually configured LifeTimes are generally measured in days. 283 Automated LifeTimes are specified in seconds. 285 Default: 32 days (2,764,800 seconds). Maximum: 182 days 286 (15,724,800 seconds). 288 Replay Window 289 Long term replay prevention requires automated configuration. 290 Also, some earlier implementations used pseudo-random values. 291 This check must only be used with those peers that have imple- 292 mented this feature. 294 Default: 0 (checking off). Range: 32 to 256. 296 Pad Values 297 New implementations use verifiable values. However, some earlier 298 implementations used pseudo-random values. This check must only 299 be used with those peers that have implemented this feature. 301 Also, some operations desire additional padding to inhibit traffic 302 analysis. 304 Default: 0 (checking off). Range: 7 to 255. 306 Key 307 Three 56-bit keys are configured as a 192-bit quantity, with par- 308 ity included as appropriate. 310 Each party configures a list of known SPIs and symmetric secret-keys. 312 In addition, each party configures local policy that determines what 313 access (if any) is granted to the holder of a particular SPI. For 314 example, a party might allow FTP, but prohibit Telnet. Such consid- 315 erations are outside the scope of this document. 317 Security Considerations 319 Users need to understand that the quality of the security provided by 320 this specification depends completely on the strength of the Triple 321 DES algorithm, the correctness of that algorithm's implementation, 322 the security of the Security Association management mechanism and its 323 implementation, the strength of the key [CN94], and upon the correct- 324 ness of the implementations in all of the participating nodes. 326 The padding bytes have a predictable value. They provide a small 327 measure of tamper detection on their own block and the previous block 328 in CBC mode. This makes it somewhat harder to perform splicing 329 attacks, and avoids a possible covert channel. This small amount of 330 known plaintext does not create any problems for modern ciphers. 332 It was originally thought that DES might be a group, but it has been 333 demonstrated that it is not [CW92]. Since DES is not a group, compo- 334 sition of multiple rounds of DES is not equivalent to simply using 335 DES with a different key. 337 Triple DES with independent keys is not, as naively might be 338 expected, as difficult to break by brute force as a cryptosystem with 339 three times the keylength. A space/time tradeoff has been shown 340 which can brute-force break triple block encryptions in the time 341 naively expected for double encryption [MH81]. 343 However, "double" DES (DES-EE2) can be broken with a meet-in-the- 344 middle attack, without significantly more complexity than breaking 345 DES requires [ibid]. DES-EDE3 with three independant keys is actu- 346 ally needed to provide significantly more security than "single" DES. 348 An attack has been shown on DES-EDE2 (using only two independent 349 keys) [Tuchman79] that is somewhat (sixteen times) faster than 350 exhaustive search [OW91]. Again, DES-EDE3 with three independant 351 keys is actually needed to provide the expected level of security. 353 Although it is widely believed that DES-EDE3 is substantially 354 stronger than single DES alone, as it is less amenable to brute force 355 attack, it should be noted that real cryptanalysis of DES-EDE3 might 356 not use brute force methods at all. Instead, it might be performed 357 using variants on differential [BS93] or linear [Matsui94] cryptanal- 358 ysis. It should also be noted that no encryption algorithm is perma- 359 nently safe from brute force attack, because of the increasing speed 360 of modern computers. 362 As with all cryptosystems, those responsible for applications with 363 substantial risk when security is breeched should pay close attention 364 to developments in cryptology, and especially cryptanalysis, and 365 switch to other transforms should DES-EDE3 prove weak. 367 Changes from RFC-1851: 369 This specification results in the same default bits-on-the-wire as 370 the 32-bit IV calculation method of RFC-1851. The 32-bit field is 371 semantically identical to a Sequence Number when implemented as a 372 counter (the recommended method). 374 The 64-bit explicit IV option is deprecated, as no hardware manufac- 375 turers were found that required it. It does not meet 64-bit field 376 alignment expectations of IPv6, it is a cryptographically weaker con- 377 struct than a calculated IV [Bellovin96], and it conflicts with the 378 use of a Sequence Number immediately following the SPI. 380 Clarified to specify "outer" CBC, as originally intended. 382 Updated performance estimates. Replaced erroneous text about paral- 383 lel computation. 385 Padding is a known series of integers, that may be checked upon 386 receipt. 388 Many implementation details by Karn were found to be common to all 389 ESP Ciphers, and are awaiting consolidation in the ESP specification. 391 Added an operational section. 393 Updated acknowledgements, references, and contacts. 395 Reorganized according to the new "road map" document. 397 Acknowledgements 399 The basic field naming and layout is based on "swIPe" [IBK93, IB93]. 401 Some of the text of this specification was derived from work by Ran- 402 dall Atkinson for the SIP, SIPP, and IPv6 Working Groups. 404 Perry Metzger provided the original Security Considerations text, 405 some of which is distributed throughout the document. 407 William Allen Simpson was responsible for the name and semantics of 408 the SPI, the IV calculation technique(s), editing and formatting. 410 The use of known padding values was suggested in various forms by 411 Robert Baldwin, Phil Karn, and David Wagner. This specification uses 412 Self-Describing-Padding [RFC-1570]. 414 Steve Bellovin, Angelos Keromytis, Holger Kummert, and Rodney Thayer 415 provided useful critiques of earlier versions of this document. 417 References 419 [Bellovin96] 420 Bellovin, S., "Problem Areas for the IP Security Protocols", 421 Proceedings of the Sixth Usenix Security Symposium, July 422 1996. 424 [BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of 425 the Data Encryption Standard", Berlin: Springer-Verlag, 426 1993. 428 [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: 429 Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 430 253-280, July 1994. 432 [CW92] Campbell, K.W., and Wiener, M.J., "Proof that DES Is Not a 433 Group", Advances in Cryptology -- Crypto '92 Proceedings, 434 Berlin: Springer-Verlag, 1993, pp 518-526. 436 [FIPS-46] 437 US National Bureau of Standards, "Data Encryption Standard", 438 Federal Information Processing Standard (FIPS) Publication 439 46, January 1977. 441 [FIPS-46-1] 442 US National Bureau of Standards, "Data Encryption Standard", 443 Federal Information Processing Standard (FIPS) Publication 444 46-1, January 1988. 446 [FIPS-74] 447 US National Bureau of Standards, "Guidelines for Implement- 448 ing and Using the Data Encryption Standard", Federal Infor- 449 mation Processing Standard (FIPS) Publication 74, April 450 1981. 452 [FIPS-81] 453 US National Bureau of Standards, "DES Modes of Operation" 454 Federal Information Processing Standard (FIPS) Publication 455 81, December 1980. 457 [IB93] Ioannidis, J., and Blaze, M., "The Architecture and Imple- 458 mentation of Network-Layer Security Under Unix", Proceedings 459 of the Fourth Usenix Security Symposium, Santa Clara Cali- 460 fornia, October 1993. 462 [IBK93] Ioannidis, J., Blaze, M., and Karn, P., "swIPe: Network- 463 Layer Security for IP", Presentation at the 26th Internet 464 Engineering Task Force, Columbus Ohio, March 1993. 466 [Matsui94] 467 Matsui, M., "Linear Cryptanalysis method for DES Cipher," 468 Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: 469 Springer-Verlag, 1994. 471 [MH81] Merkle, R.C., and Hellman, M., "On the Security of Multiple 472 Encryption", Communications of the ACM, v. 24 n. 7, 1981, 473 pp. 465-467. 475 [OW91] van Oorschot, P.C., and Weiner, M.J. "A Known-Plaintext 476 Attack on Two-Key Triple Encryption", Advances in Cryptology 477 -- Eurocrypt '90 Proceedings, Berlin: Springer-Verlag, 1991, 478 pp. 318-325. 480 [RFC-1570] 481 Simpson, W., "PPP LCP Extensions", DayDreamer, January 1994. 483 [RFC-1825x] 484 Atkinson, R., "Security Architecture for the Internet Proto- 485 col", Naval Research Laboratory, July 1995. 487 [RFC-1827x] 488 Simpson, W., "IP Encapsulating Security Protocol (ESP) for 489 implementors", 491 [RFC-1829x] 492 Karn, P., Metzger, P., Simpson, W.A., "The ESP DES-CBC 493 Transform", work in progress. 495 [RFC-2119] 496 Bradner, S., "Key words for use in RFCs to Indicate Require- 497 ment Levels", BCP 14, Harvard University, March 1997. 499 [RFC-wwww] 500 Simpson, W.A, "ESP with Cipher Block Chaining (CBC)", work 501 in progress. 503 [Schneier95] 504 Schneier, B., "Applied Cryptography Second Edition", John 505 Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 507 [Tuchman79] 508 Tuchman, W, "Hellman Presents No Shortcut Solutions to DES", 509 IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41. 511 Contacts 513 Comments about this document should be discussed on the ipsec@tis.com 514 mailing list. 516 Questions about this document can also be directed to: 518 Naganand Doraswamy 519 Bay Networks 520 3 Federal Street #BL3-04 521 Billerica, Massachusetts 01821 523 naganand@BayNetworks.Com 525 Perry Metzger 526 Piermont Information Systems Inc. 527 160 Cabrini Blvd., Suite #2 528 New York, NY 10033 530 perry@piermont.com 532 William Allen Simpson 533 DayDreamer 534 Computer Systems Consulting Services 535 1384 Fontaine 536 Madison Heights, Michigan 48071 538 wsimpson@UMich.edu 539 wsimpson@GreenDragon.com (preferred) 540 bsimpson@MorningStar.com