idnits 2.17.1 draft-ietf-wts-gssapi-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-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. == 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1995) is 10391 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) ** Downref: Normative reference to an Informational draft: draft-ietf-wts-requirements (ref. '1') -- Unexpected draft version: The latest known version of draft-hickman-netscape-ssl is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-06) exists of draft-ietf-wts-shttp-00 ** Downref: Normative reference to an Historic draft: draft-ietf-wts-shttp (ref. '3') ** Obsolete normative reference: RFC 1508 (ref. '4') (Obsoleted by RFC 2078) == Outdated reference: A later version (-07) exists of draft-ietf-cat-gssv2-03 == Outdated reference: A later version (-07) exists of draft-ietf-cat-kerb5gss-02 == Outdated reference: A later version (-06) exists of draft-ietf-cat-spkmgss-04 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-08) exists of draft-ietf-cat-snego-00 == Outdated reference: A later version (-10) exists of draft-ietf-cat-idup-gss-02 ** Downref: Normative reference to an Informational draft: draft-ietf-cat-idup-gss (ref. '10') Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web Transaction Security Working Group D. Rosenthal 3 INTERNET-DRAFT TradeWave 4 November 1995 6 Use of the GSS-API for Web Security 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 23 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 24 Coast), or ftp.isi.edu (US West Coast). 26 ABSTRACT 28 This specification describes a means of using the Generic Security 29 Service Application Program Interface (GSS-API) to secure World 30 Wide Web transactions. Use of the GSS-API enables mutual 31 authentication and data encryption capabilities to be incorporated 32 into Web clients (browsers) and servers in a security 33 technology-independent manner. Such an approach facilitates the 34 use of Web applications in a variety of security environments, and 35 provides a basis for Web applications to negotiate common security 36 mechanisms at run-time. 38 1. INTRODUCTION 40 The role of the GSS-API in facilitating Web security is to provide 41 a standard programming interface that Web applications can use to 42 secure transactions over the Internet, as per the IETF requirements 43 for Web transaction security [1]. While the API itself does not 44 define a network/wire protocol, implementations of the API define 45 standard network security token formats and protocols for secure 46 client/server communications. Like the Secure Sockets Layer 47 (SSL) [2], the GSS-API can be used to secure other applications in 48 addition to the Web; like the Secure HyperText Transfer Protocol 49 (S-HTTP) [3], the GSS-API supports a variety of security 50 mechanisms. Thus, the GSS-API enables use of a uniform security 51 interface across Web and other electronic commerce applications, 52 and enables deployment of those applications in a variety of 53 security environments. 55 2. GSS-API OVERVIEW 57 The Generic Security Service Application Program Interface 58 (GSS-API) has been under development by the IETF Common 59 Authentication Technology (CAT) Working Group (WG) for several 60 years [4][5]. During this time, the GSS-API has evolved to include 61 a comprehensive set of functions for securing client/server 62 applications. This includes functions for credential management, 63 security context establishment, message privacy, and namespace 64 management. The security context functions support both unilateral 65 and mutual authentication. The message privacy functions support 66 both confidentiality and integrity protection of application data. 68 The GSS-API is "generic" in the sense that it can be implemented 69 using a variety of security mechanisms. As such, the IETF 70 specification for the GSS-API is accompanied by other 71 specifications which define the token formats, network protocols, 72 object identifiers (OIDs), etc., for implementations of the API 73 based on symmetric and asymmetric encryption algorithms [6][7][8]. 74 Public and commercial GSS-API implementations are already available 75 based on Kerberos, DCE, and RSA technology. These implementations 76 incorporate other networking standards as well, including ASN.1, 77 X.509, and FIPS-113. 79 The GSS-API is continuing to evolve through the efforts of the CAT 80 WG. A mechanism negotiation protocol is being defined to enable 81 GSS-API-based applications to negotiate and select common 82 security mechanisms at run-time [9]. This will facilitate 83 the interoperability of Web applications across different security 84 environments by allowing a Web client and/or server to support 85 multiple GSS-API mechanisms/protocols, whereby a common mechanism 86 can be negotiated and selected per client/server session. Note 87 that such a scenario inherently assumes that the appropriate 88 security credentials are available for the supported mechanisms. 89 Since the mechanism negotiation protocol specification is at an 90 Internet-Draft stage, this document discusses the Web/GSS-API 91 integration both in terms of having the negotiation capability 92 available (i.e. in the future) and not having it available. 94 In addition to mechanism negotiation, the CAT WG is also defining a 95 corollary API for store-and-forward applications [10]. This will 96 provide uniform security APIs for use across both session-oriented 97 (Web) and store-and-forward applications (such as email), and will 98 facilitate the use of a single set of credentials (single sign-on) 99 for both types of secure applications. 101 3. WEB APPLICATION INTEGRATION 103 The GSS-API can be incorporated into a variety of client/server 104 application protocols, including the World Wide Web Hypertext 105 Transfer Protocol (HTTP). The HTTP/GSS-API integration occurs at 106 the network communications level, whereby the initial HTTP 107 connection is strongly authenticated and the entire transaction is 108 protected using GSS-API functions. All types of HTTP transactions 109 are secured, including document retrievals, form submissions, and 110 CGI results. 112 The GSS-API integration isolates the application protocol and data 113 format (HTML) from the operating characteristics of the underlying 114 security technology (e.g. cryptographic token formats, credential 115 processing, etc.). This approach provides non-intrusive security 116 in that Web transactions are protected (encapsulated) without 117 modifying the standard HTTP/HTML constructs. 119 3.1 Secure HTTP URL Types 121 Given the stateless nature of HTTP, secure Web data is typically 122 identified by a unique HTTP URL type (e.g. "https" for SSL, and 123 "shttp" for S-HTTP). That is, since an HTTP session is composed of 124 a single request/response between client and server, it does not 125 avail itself to an initial protocol data unit (PDU) or command 126 sequence being sent (prior to the actual request) to determine 127 whether a server accepts/requires security for the session (as is 128 possible with the WAIS/Z39.50, NNTP, and FTP protocols). While the 129 "Authorization:" MIME header record is available in HTTP, it can 130 not be used to convey an authentication type simultaneously with a 131 protected request in the case of authentication methods which 132 require a multi-pass handshake to establish a unique session 133 encryption key. 135 A Web server's security capability is instead advertised via a 136 secure HTTP URL type on the data being served by that server. The 137 secure HTTP URL type indicates to a client that a particular 138 security method must be used to dereference the URL, and enables 139 the client to then use the appropriate method to secure its request 140 to the server. This is especially important for the secure 141 submission of private form data. 143 For the Web/GSS-API integration, a new secure HTTP URL type is 144 defined, named "gss-http". This URL type indicates that the 145 associated Web data must be accessed (or submitted) using a 146 GSS-API security mechanism. For GSS-API implementations that 147 support GSS-API mechanism negotiation, a common security mechanism 148 type and mechanism options are selected via the mechanism 149 negotiation protocol upon dereferencing the gss-http URL type. A 150 security context is then established using the selected mechanism. 152 In the case of Web applications that only support a single GSS-API 153 mechanism, a security context is established upon dereferencing the 154 gss-http URL type provided both the client and server support the 155 given mechanism. Otherwise, the GSS-API security context 156 establishment functions return an error. 158 (A request is being submitted to IANA for a standard gss-http port 159 number.) 161 3.2 Acquiring Credentials 163 Before a security context can be established, a Web client and 164 server must each acquire their respective credentials. This is 165 accomplished by either explicitly using the GSS_Acquire_cred() 166 function, or specifying that default credentials should be used. 167 Acquiring credentials makes available the relevant credential data 168 for the client and/or server to be authenticated via the subsequent 169 context establishment. Once acquired, credentials can be re-used 170 until their lifetime expires, at which time the credentials must be 171 re-acquired. The client and server may have different lifetimes 172 for their credentials. For example, client credentials may have a 173 shorter lifetime than server credentials, since the client host 174 environment may be less secure than that of the server. 176 Given that the underlying credential aquisition process is 177 dependent upon the type of GSS-API mechanism being used, one or 178 more mechanism-specific (non-GSS-API) functions must typically be 179 called prior to acquiring credentials, as specified by the 180 GSS-API implementation provider. For example, the end-user may 181 need to be prompted periodically for a login ID and password prior 182 to acquiring credentials. Example credential data includes Kerberos 183 tickets, private/public key pairs and public key certificates, etc. 184 Note that the process of acquiring credentials may involve network 185 communication with a key management service (e.g. a KDC or CA 186 service). 188 3.3 Security Context Establishment 190 Once credentials are acquired, a Web client/server security context 191 can be established using the pertinent GSS-API functions. The 192 security context establishment process authenticates the client and 193 server identities, and establishes a secret key for protecting the 194 subsequent Web transaction. In GSS-API parlance, The Web client 195 initiates the security context, and the Web server accepts the 196 security context (i.e. the server is the target). 198 3.3.1 Initiating a Security Context 200 The Web client initiates a security context using the 201 GSS_Init_sec_context() function, passing the following as input 202 arguments: 204 . The credential handle returned from GSS_Acquire_cred(), or 205 null to use default credentials 206 . The name of the server 207 . A mechanism type (which may be the negotiation mechanism) 208 . A set of context-quality flags 210 The server name is constructed from the secure URL being 211 dereferenced. The target server host name included in the URL is 212 used to form a GSS-API host-based service name. For example, given 213 the secure URL "gss-http://www.tradewave.com/", the server name is 214 constructed as "http@www.tradewave.com". The server name is used 215 by the underlying GSS-API mechanism to obtain the appropriate 216 server credential information needed to authenticate the client 217 with the server. This provides a means of directly associating the 218 target URL host name with the server's identity to be 219 authenticated. 221 In environments where multiple authentication domains exist 222 (e.g. Kerberos realms and/or public key certification authorities), 223 additional information may be needed to translate the URL into an 224 appropriate server name for authentication (e.g. a directory 225 service lookup to determine the realm/CA in which the server 226 resides). Also in such environments, consideration must be given 227 as to which domains are trusted; however, this issue is outside the 228 scope of this document. 230 If mechanism negotiation is supported, the mutual/anonymous 231 authentication state flags are set as per the mechanism type and 232 mechanism options selected during the mechanism negotiation phase. 233 That is, the mechanism negotiation process is used to determine 234 whether mutual authentication is required, e.g. based on the server 235 configuration. If mechanism negotiation is not supported, mutual 236 authentication is used by default. It is recommended that the 237 replay detection and message sequencing flags (replay_det_req_flag 238 and sequence_req_flag, respectively) also be enabled. 240 If successful, GSS_Init_sec_context() returns a context token, 241 which the client then sends to the server. Depending on the 242 GSS-API mechanism being used, the client may subsequently receive 243 another context token back from the server, which the client then 244 passes into a second call to GSS_Init_sec_context(). The 245 GSS_S_CONTINUE_NEEDED status returned from GSS_Init_sec_context() 246 indicates whether the client should expect to receive a context 247 token back from the server. The client/server context token 248 exchange continues until the GSS_S_COMPLETE status is returned from 249 GSS_Init_sec_context(). The token exchanges occur as per the token 250 protocol described in section 3.6. 252 If the security context initiation process fails, the client 253 disconnects from the server. 255 3.3.2 Accepting a Security Context 257 The Web server accepts a security context using the 258 GSS_Accept_sec_context() function, passing the following as input 259 arguments: 261 . The credential handle returned from GSS_Acquire_cred(), or 262 null to use default credentials 263 . The context token received from the client 265 If successful, GSS_Accept_sec_context() returns the following as 266 output arguments: 268 . The name of the client user 269 . A set of context-quality flags 270 . Message protection service flags 272 The returned client name represents the authenticated identity of 273 the user. This is an internal name which can be passed to the 274 GSS_Display_name function to obtain an external (human-readable, 275 printable) name, as well as the name type OID. The format of this 276 name is dependent upon the type of GSS-API mechanism being used. 277 The external representation of the authenticated user name can 278 subsequently be used to enforce access controls on client requests. 279 In addition, the external name should be passed to CGI programs in 280 an appropriate environment variable. 282 The returned context-quality flags indicate the quality parameters 283 associated with the security context, as conveyed by the client. 284 The message protection service flags indicate whether message 285 confidentiality and/or integrity services are available for the 286 context (via subsequent GSS-API function calls). 288 Depending on the GSS-API mechanism being used, 289 GSS_Accept_sec_context() may return another context token to be 290 sent back to the client. This is indicated by the 291 GSS_S_CONTINUE_NEEDED status being returned from 292 GSS_Accept_sec_context(); otherwise, the GSS_S_COMPLETE status is 293 returned. The client/server context token exchange continues until 294 the GSS_S_COMPLETE status is returned from GSS_Accept_sec_context(). 295 The token exchanges occur as per the token protocol described in 296 section 3.6. 298 If the security context acceptance process fails, the server 299 disconnects from the client. Example context acceptance failures 300 include detection of a normal (non-secure) HTTP request, an 301 unsuccessful return status from GSS_Accept_sec_context(), etc. 303 In the case of a Web server that creates sub-processes to handle 304 client requests, it is recommended that the context acceptance 305 occur in the sub-process rather than the parent server process, as 306 this will increase the efficiency/throughput of the parent. 308 3.4 Message Protection 310 After a security context is established, the Web client and server 311 can exchange information in a secure manner using various GSS-API 312 functions. Transactions can be secured by a Message Integrity 313 Code (MIC) alone, or by a MIC with encryption of the transaction 314 data as well. For public key implementations of the GSS-API, the 315 transaction integrity check can be in the form of a digital 316 signature. 318 The client and server use the GSS_GetMIC() and GSS_VerifyMIC() 319 functions to generate and verify a transaction MIC, respectively. 320 If encryption is also desired, the GSS_Wrap() function is used to 321 generate a MIC and encrypt the transaction, while GSS_Unwrap() is 322 used to verify the MIC and decrypt the transaction. As mentioned 323 previously, these functions do not actually perform any network 324 communication. Rather, GSS_GetMIC() and GSS_VerifyMIC() 325 return/accept a MIC as a token, which is sent/received as per the 326 token protocol described in section 3.6. Likewise, GSS_Wrap() and 327 GSS_Unwrap() return/accept an encapsulation of a given transaction 328 message, which is also sent/received as per the token protocol 329 described in section 3.6. 331 3.4.1 Quality of Protection 333 Immediately after a security context is established, the server 334 sends the client a message that is secured using GSS_Wrap() 335 according to the degree of transaction security being enforced by 336 the server (e.g. as per server configuration parameters). The 337 client uses GSS_Unwrap() on this message to determine the level and 338 type of transaction security required by the server. That is, the 339 server indicates to the client whether integrity alone or integrity 340 with encryption is required, and which integrity/encryption 341 algorithm(s) must be used (as well as key size(s) if variable-size 342 keys are supported by the underlying GSS-API mechanism). Note that 343 since GSS_Unwrap() returns this information via function output 344 arguments (conf_state and qop_state), the message content itself is 345 irrelevant with respect to the Web/GSS-API protocol. The client 346 and server then protect all subsequent messages using the same 347 quality of protection as indicated by the server. These subsequent 348 messages are standard HTTP requests and responses. This enables 349 service providers to specify the level of security needed for their 350 particular service, as per the security policies governing the 351 information content being provided by the service. 353 The level and type of transaction security indicated by the server 354 to the client must be commensurate with that supported by the 355 underlying GSS-API mechanism. If the mechanism does not support 356 the desired quality of protection (as detected by a GSS_Wrap() 357 failure), the server deletes the security context and disconnects 358 from the client. Likewise, if the server indicates a quality of 359 protection which the client does not support, the client deletes 360 the security context and disconnects from the server. 362 When the server receives messages from the client, it verifies that 363 the messages are protected in the same manner as was originally 364 indicated by the server. If a different quality of protection is 365 detected, the server deletes the security context and disconnects 366 from the client. 368 3.5 Context Deletion 370 After a Web client/server transaction is completed, or an 371 unrecoverable error condition is detected, the security context is 372 deleted by both the client and server using the 373 GSS_Delete_sec_context() function. The output_context_token 374 argument to this function is not used (null), since the client and 375 server are both aware of when the transaction ends (and thus don't 376 need to inform each other of context deletion). In addition, if 377 the credentials used to establish the security context were 378 explicitly acquired by GSS_Acquire_cred() and are not to be used 379 again, those credentials are released using the GSS_Release_cred() 380 function. However, it is recommended that clients and servers 381 reuse such credentials to establish multiple security contexts over 382 a finite credential lifetime, then release those credentials upon 383 expiration of the lifetime. This approach is more efficient since 384 the credentials are not re-acquired for each client/server security 385 context. 387 It may also be possible for clients to cache and reuse the security 388 context associated with a given target server, if context reuse is 389 supported by the underlying GSS-API mechanism. This would minimize 390 the context setup overhead for each connection to the given server. 391 However, the GSS-API mechanism may be caching the information it 392 uses to create the security context, in which case the context 393 setup overhead is already being minimized. 395 3.6 Web GSS-API Token Protocol 397 The GSS-API functions do not actually perform any network 398 communication between the Web client and server. Rather, a GSS-API 399 function may return a token which is sent by the client to the 400 server (or vice-versa), which then passes the token into another 401 GSS-API function for processing. Prior to having a security 402 context established, the following protocol is used by the client 403 and server for sending/receiving GSS-API tokens: 405 tokenLength 4 bytes 406 tokenLengthChecksum 4 bytes 407 majorVersionNumber 2 bytes 408 minorVersionNumber 2 bytes 409 reserved (future use) 4 bytes 410 token tokenLength bytes 412 The token length checksum is simply the negative (two's complement) 413 of the token length. The checksum can be used to validate the 414 token length, as well as to determine if a GSS-API token is being 415 received. For example, a secure Web server can use this to 416 determine if a normal (non-secure) HTTP request is being received, 417 and if so, to return an appropriate error code. The protocol 418 version information can be used to detect/support 419 backwards-compatibility as the protocol evolves. 421 Once a security context is established between the client and 422 server, the protocol is simplified to the following for 423 sending/receiving all subsequent GSS-API tokens (e.g. secure 424 message tokens): 426 tokenLength 4 bytes 427 tokenLengthChecksum 4 bytes 428 token tokenLength bytes 430 3.7 Client GUI Considerations 432 It is recommended that the client GUI provide a visual indicator 433 that differentiates secure Web transactions from non-secure 434 transactions. The indicator could be activated while a secure 435 transaction is occurring, and/or after a secure transaction has 436 completed and a secure page is being viewed. 438 4. SECURITY CONSIDERATIONS 440 Security issues are discussed throughout this document. Additional 441 issues regarding GSS-API-based Web transactions involving firewall 442 proxy servers or other server intermediaries will be addressed in 443 future versions of this document. 445 5. REFERENCES 447 [1] G. Bossert, S. Cooper, W. Drummond, "Requirements for Web 448 Transaction Security", Internet-Draft, 449 draft-ietf-wts-requirements-01.txt, October 1995. 451 [2] K. Hickman, T. Elgamal, "The SSL Protocol", Internet-Draft, 452 draft-hickman-netscape-ssl-01.txt, June 1995. 454 [3] E. Rescorla, A. Schiffman, "The Secure HyperText Transfer 455 Protocol", Internet-Draft, draft-ietf-wts-shttp-00.txt, July 1995. 457 [4] J. Linn, "Generic Security Service Application Program 458 Interface", RFC1508, September 1993. 460 [5] J. Linn, "Generic Security Service Application Program 461 Interface, Version 2", Internet-Draft, draft-ietf-cat-gssv2-03.txt, 462 June 1995. 464 [6] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", 465 Internet-Draft, draft-ietf-cat-kerb5gss-02.txt, February 1995. 467 [7] C. Adams, "The Simple Public-Key GSS-API Mechanism (SPKM)", 468 Internet-Draft, draft-ietf-cat-spkmgss-04.txt, May 1995. 470 [8] S. Murphy, D. Balenson, J. Galvin, "The FIPS PUB JJJ Entity 471 Authentication GSS-API Mechanism", Internet-Draft, 472 draft-ietf-cat-fipsjjjgss-00.txt, July 1995. 474 [9] E. Baize, D. Pinkas, "Simple GSS-API Negotiation Mechanism", 475 Internet-Draft, draft-ietf-cat-snego-00.txt, July 1995. 477 [10] C. Adams, "Independent Data Unit Protection Generic Security 478 Service Application Program Interface (IDUP-GSS-API)", 479 Internet-Draft, draft-ietf-cat-idup-gss-02.txt, July 1995. 481 6. ACKNOWLEDGEMENTS 483 The author thanks his colleagues at TradeWave for their review of 484 earlier drafts of this document, and also thanks Stephen Farrell of 485 Siemens-Nixdorf and John Linn of OpenVision Technologies for their 486 helpful comments. 488 This work was initiated at TradeWave (formerly EINet) and funded in 489 part by the ARPA Manufacturing Automation and Design Engineering 490 (MADE) program, under contract management by the USAF Wright 491 Laboratory. 493 7. AUTHOR'S ADDRESS 495 Doug Rosenthal 496 TradeWave 497 3636 Executive Center Dr., Ste. 100 498 Austin, TX 78731 USA 500 Phone: +1 512.433.5347 501 E-mail: rosenthal@tradewave.com