idnits 2.17.1 draft-ietf-ipsec-cdp-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-03-28) 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 == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 65 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages 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 17 instances of too long lines in the document, the longest one being 4 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 116: '...in the message. A CDP header MUST be...' RFC 2119 keyword, line 131: '...r, the responder SHOULD still process ...' RFC 2119 keyword, line 150: '...The responder MUST either indicate an ...' RFC 2119 keyword, line 152: '...e to each request CDP record MUST have...' RFC 2119 keyword, line 154: '...response MAY simply be an error if the...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 174 has weird spacing: '...pensive 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 (June 6, 1996) is 10157 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '12' is defined on line 441, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-09) exists of draft-ietf-dnssec-secext-04 -- No information found for draft-atkins-pgpformats - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-01) exists of draft-ietf-ipsec-skip-udh-00 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-addr-arch is -02, but you're referring to -03. (However, the state information for draft-atkins-pgpformats is not up-to-date. The last update was unsuccessful) ** Downref: Normative reference to an Historic draft: draft-ietf-ipngwg-addr-arch (ref. '6') ** Obsolete normative reference: RFC 822 (ref. '7') (Obsoleted by RFC 2822) -- No information found for draft-ietf-ipsec-photuris - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Normative reference to a draft: ref. '12' Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 - 1 - 3 IPSEC Working Group Ashar Aziz 4 INTERNET-DRAFT Tom Markson 5 Hemma Prafullchandra 6 Rich Skrenta 7 Sun Microsystems, Inc. 9 Germano Caronni 10 Swiss Federal Institute of 11 Technology 13 Expires in six months June 6, 1996 15 Certificate Discovery Protocol 16 18 Status of this Memo 20 This document is a submission to the IETF Internet Protocol Security 21 (IPSEC) Working Group. Comments are solicited and should be addressed to 22 to the working group mailing list (ipsec@ans.net) or to the authors. 24 This document is an Internet-Draft. Internet Drafts are working 25 documents of the Internet Engineering Task Force (IETF), its areas, and 26 its working Groups. Note that other groups may also distribute working 27 documents as Internet Drafts. 29 Internet-Drafts draft documents are valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference material 32 or to cite them other than as "work in progress." 34 To learn the current status of any Internet-Draft, please check the 35 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 36 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 37 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 38 ftp.isi.edu (US West Coast). 40 Distribution of this memo is unlimited. 42 Abstract 44 Use of Public key cryptography is becoming widespread on the Internet in 45 such applications as electronic mail and IP Security (IPSEC). 46 Currently, however, a common public key certificate infrastructure does 47 not exist which is interoperable with other systems and ubiquitous. In 48 light of this, we describe a protocol which may be used to exchange or 49 retrieve certificates (essentially signed public keys) with or from 50 another entity. The protocol may be used to request certificates from a 51 directory/name server or from the entity who owns the certificate. 53 1. Overview 55 The distribution of authenticated public keys is a fundamental problem 56 which needs to be resolved with use of public key cryptography. Many 57 solutions exist for distributing authenticated public keys. Two of the 58 more common distribution methods are the X.500 directory service [1] and 59 Secure Domain Name System (Secure-DNS) [2]. Each method has a different 60 encoding format for the entity identity and the public key that belongs 61 to it. It is expected that many distribution mechanisms will co-exist on 62 the Internet and hence many "certificate" formats. 64 We describe a protocol which may be used to exchange certificates on the 65 Internet. The protocol has the advantage that it does not require 66 changes to existing services or deployment of large directory services 67 in order to be used. The Certificate Discovery Protocol allows 68 certificate requests to be made to any arbitrary IP-node. This feature 69 allows the initiator to send requests to, say, an IP-node which is 70 acting as a certificate server (and hence would have many certificates 71 stored in its local certificate database) or to a single IP-node which 72 only has it's own certificate. 74 As noted earlier, there are several different types of certificates in 75 existence: X.509 certificates [11], PGP certificates [3], Secure DNS 76 resource records and hashed public keys [4]. This protocol is designed 77 to support all of these and new ones as they emerge. 79 A Certificate has at least two properties: 81 (1) it provides for a cryptographic binding to a name/identity of an 82 entity, and 83 (2) it provides integrity protection of a public key. 85 The name may be encoded in the certificate (for example, as in X.509 and 86 PGP certificates) or it may be implicit in the public key itself (i.e., 87 the cryptographic hash of the public key). 89 As with various certificate types, numerous naming conventions exist on 90 the Internet, for example, IP addresses [5],[6], RFC 822 addresses [7], 91 DNS names and PGP user names. This protocol attempts to support all of 92 these and allows for other syntaxes. 94 Note, that a particular entity may have more than one certificate. An 95 entity may have the same public value in different certificate formats, 96 or have multiple public values each in a separate certificate or have 97 the same public value certified by different Certifying Authorities, and 98 so on. In all these possible certificates the identity of the entity 99 remains constant. 101 2. Overview of the Certificate Discovery Protocol (CDP) 103 The Certificate Discovery protocol is a request/response protcocol used 104 by two parties to transfer certificates. The Requester initiates 105 Certificate Discovery. The Responder receives the Certificate Discovery 106 message and responds. 108 All certificate discovery protocol communication uses the User Datagram 109 Protocol (UDP) [8]. The requester binds to a random port and sends a 110 request to port cert-responder. The port assignment is described later. 111 The responder has bound to port cert-responder and sends the response to 112 the random port on which the requester sent the request. 114 The CDP consists of two parts: a Certificate Discovery Header and zero 115 or more CDP records. The CDP header contains global status and the 116 number of CDP records present in the message. A CDP header MUST be 117 present in a CDP. One CDP record is present for each "question" or 118 "answer", if present. 120 The simplest example of CDP is the requester asking for a particular 121 certificate from the responder. The responder replies with that 122 certificate. If the responder does not have the certificate the 123 requester asked for, it will set the error status and not return a 124 certificate. In this example, one CDP header and one CDP record would 125 be sent in both the request and the response. 127 A CDP message may be requests for multiple certificates. The requester 128 will produce one CDP record for each certificate being requested. The 129 responder will reply with a set of CDP records containing certificates 130 or errors. It is important to note that if one CDP question generated 131 an error, the responder SHOULD still process all of the other CDP 132 questions. Errors are generally handled in the CDP record per- 133 certificate level. 135 It is also important to note that questions and answers may not 136 necessarily map one to one. For instance, the requester may ask the 137 responder for a certificate and receive multiple certificates as a 138 response. The request might contain one CDP record, but the response 139 would contain one CDP record for EACH certificate returned. 141 The use of the term requester is a bit confusing. Not only may the 142 requester request certificates from the responder, but it may also PUT 143 certificates to the responder. A PUT is an unsolicited presentation of 144 certificates from requester to responder. The responder will reply 145 with a status indicating whether the PUT was successful. 147 The protocol supports a mixing of GETs and PUTs. The requester may 148 PUT it's certificate in the same CDP that he GETs the responders. 150 The responder MUST either indicate an error in the STATUS field of the 151 CDP header or generate at least one CDP record for each CDP record 152 present in a request. The response to each request CDP record MUST have 153 the same name fields (name type, name len, Name) as the request. The 154 response MAY simply be an error if the responder chooses not to process 155 the request. 157 For example, if a requester asks for 5 certificates from the responder, 158 the request packet will contain the CDP header and 5 CDP records. In 159 the absence of an error in the header STATUS field, if the responder has 160 5 certificates to return, the response packet will also contain 5 CDP 161 packets. If the responder only had 2 of the 5 certificates, it would 162 still contain 5 CDP records. Three of the CDP records would indicate an 163 error. 165 2.1 Clogging Defense 167 The Certificate Discovery Protocol allows a requester to both make 168 certificate discovery requests (i.e. GET), as well present certificates 169 (i.e. push). This could lead to a situation where a requester may 170 attempt to clog a certificate server by flooding it with bogus 171 certificate pushes. The server, when presented with a set of 172 certificates would at a minimum parse the request and check if it 173 already has the presented certificates in its local database. It may 174 also have to verify a signature using a (possibly) expensive public key 175 operation. Rather than discarding certificate pushes when it feels 176 clogged, the server may request that the requester use the optional 177 cookie exchange mechanism. With this approach, the server may continue 178 to serve legitimate requests. 180 If the Responder requires a cookie, it will expect the requester to send 181 the cookie with the expected value. If the requester does not send this 182 cookie, the Responder SHOULD send a message with the "Cookie Required" 183 status and the desired cookie in the cookie field. 185 The protocol also supports a cookie the initiator may set. The 186 responder MUST send this cookie back to the initiator in a response. 187 This cookie may be used for replay protection, clogging defense or as a 188 means for the client to associate responses with requests. 190 If either the requester or the Responder is feeling clogged it SHOULD 191 give preference in calculating the shared secrets (i.e. g^ij) 192 computations to certificates sent to it with cookies. (For example, it 193 could precompute g^ij immediately upon receiving the certificate and 194 after verifying it.) 196 2.1.1 Cookie Generation 198 The cookie generation method may be as recommended in the Photuris 199 Internet Draft [9], i.e., an MD5 [10] hash is applied over the IP Source 200 and IP Destination Addresses, the UDP source and destination ports, and 201 a locally generated secret random value. A subset of this hash is then 202 used as a cookie. 204 Note that this is an implementation detail in that the mechanism 205 employed is purely a local matter, two communicating entities do not 206 have to use the same mechanism. 208 3. Certificate Discovery Packet 210 The Certificate Discovery Protocol message consists of two parts: 212 1) the certificate discovery Header (CDP header), 213 2) zero or more CDP record(s). 215 3.1 CDP Header 217 The following describes a certificate discovery header. All values 218 are in network order. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | VERS | ACTION/STATUS | #-OF-RECS | Reserved | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Requester Cookie | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Responder Cookie | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 VERS indicates protocol version number, VERS = 1 for this protocol. 232 Action/Status indicates either a request or the status of a response. 233 It MUST be set to the value REQUEST by the initiator. The responder 234 MUST set the field to one of the values RESPONSE, COOKIE_REQUIRED 235 or REQUEST_TOO_LARGE. 237 0 (REQUEST) - This Certificate discovery packet is 238 initiating CDP. 240 1 (RESPONSE) - This Certificate discovery packet is a 241 response to a previous CDP initiate. 243 2 (COOKIE_REQUIRED) - Responder requires the initiator to resend this 244 request with a non-zero responder cookie. 245 This cookie is present in the Responder Cookie 246 field. 248 3 (REQUEST_TOO_LARGE) - Request cannot be satisfied in one UDP packet 249 (64K). This may occur, for example, if the 250 initiator has asked for too many certificates 251 in a request. If the initiator receives this 252 response then it SHOULD resend the request 253 with fewer queries. The responder, 254 however, SHOULD send as many certificates as 255 it can in the response. 257 #-OF-RECS - The number of CDP Records present. If this 258 value is 0 then no CDP Records are present in 259 the message. 261 Reserved - This field is current reserved. It should be 262 set to zero by the sender and ignored by the 263 receiver. 265 Requester Cookie - In a request message, this contains a 266 value that the Responder should send back 267 in the Requester Cookie field of the response. 269 In a response message, this field MUST contain 270 the value that was sent by the requester in this 271 field in the request. 273 Responder Cookie - In a request, this contains the value 274 that the Responder previously indicated should 275 be sent in the request. In a response message, 276 if the "Cookie Required" status is set, this 277 contains the value that MUST be sent in a 278 new request. If the requester has not received 279 a cookie from the responder, the requester MUST 280 set this field to be zero. 282 3.2 CDP Record 284 Following the Certificate Discovery header is one CDP record for each 285 name or certificate included in the request message. A correctly formed 286 Certificate Discovery message MUST contain as many CDP records as the 287 #-OF-RECS field in the CDP header specifies. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |Action/Status | Name Type | Name Length | Name ~ 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | CERT-Type | CERT-Length | Certificate ~ 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Action/Status - is used to indicate either the action that is requested 298 in a particular CDP record or the status of a response. 299 The initiator MUST treat this field as an action field. 300 The responder MUST treat this field as a status field. 302 Actions values are as follows: 303 1 GET 304 2 PUT 306 Status values are as follows: 307 100 GET SUCCEEDED 308 101 GET FAILED 309 102 PUT SUCCEEDED 310 103 PUT FAILED 312 Name Type - Identifies the type of the Name. The values of this 313 field will be assigned by the Internet Assigned Numbers 314 Authority (IANA). 316 Name Length - The length of the name in bytes. 318 Name - The name of the entity who owns the certificate for 319 which the request is being made. This field must be 320 the size as specified in Name Length. 322 Cert-Type - specifies the certificate type of the certificate that 323 is to follow. If no certificate is present, this field 324 is set to zero. These values will be assigned by IANA. 326 Cert-Length - specifies the length of the certificate in bytes. If no 327 certificate is present, this field is set to 0. 329 Certificate - the certificate. This field must be the size that is 330 specified in the Cert-Length field. 332 4. Assigned Numbers 334 4.1 Port Number Assignments 336 IANA has assigned cert-responder UDP port 1640. 338 4.2 Name Type Assignments 340 Name Type Value Name Type 342 1 SKIP 343 2 PGP Printable String 344 3 PGP KeyID 345 4 DNS name 346 5 RFC 822 name 347 6 X.509 Distinguished Name 349 Name Type values 1 through 6 are assigned as is described above. Name 350 Type values 7 through 249 inclusive are reserved to IANA for future 351 allocation as Assigned Numbers. Such future allocation by IANA will 352 normally require that a public specification exist for the Name Type 353 obtaining such allocation. Name Types in the range 250 through 255 354 inclusive are reserved for private use among consenting parties. Name 355 Types in the range 250 through 255 inclusive will hence only have local 356 uniqueness properties. 358 4.3 Certificate Type Assignments 360 CERT-Type Value Certificate Type 362 1 X.509 [1] 363 2 PGP [3] 364 3 Secure DNS [2] 365 4 MD5 of Unsigned DH Public Value [4] 366 5 MD5 of Unsigned Elliptic Curve Public Value 367 6 MD5 of Unsigned RSA Public Value 368 7 X509 Certificate Revocation List 370 CERT-Type values 1 through 6 are assigned as is described above. CERT- 371 Type values 7 through 249 inclusive are reserved to IANA for future 372 allocation as Assigned Numbers. Such future allocation by IANA will 373 normally require that a public specification exist for the Certificate 374 Type obtaining such allocation. CERT-Types in the range 250 through 255 375 inclusive are reserved for private use among consenting parties. CERT- 376 Types in the range 250 through 255 inclusive will hence only have local 377 uniqueness properties. 379 5. Security Considerations 381 A responder should use the cookie exchange mechanism when it feels 382 clogged. 384 We suggest that the UDP ports used by the Certificate Discovery Protocol 385 be treated as a "by-pass" channel for encryption (i.e. non encrypted 386 traffic is permitted to be sent on these ports). As only certificates 387 GETs/PUTs are satisfied on these ports the window for vulnerability is 388 limited. 390 Acknowledgements 392 We would like to thank all of the people who helped make this draft 393 possible. 395 Bill Danielson, Marc Dye and Ben Stoltz for reviewing this draft and 396 providing constructive suggestions. 398 Special thanks to Colin Plumb for his valuable suggestions and 399 contributions to this protocol. 401 Ran Atkinson suggested that this protocol should be independent of other 402 IPSEC drafts. 404 Phil Karn and Bill Simpson for their work on the Cookie Exchange scheme 405 for the Photuris Session Key Management Protocol which influenced the 406 addition of the Cookie field to this protocol. 408 References 410 [1] CCITT Recommendation X.500 (1988), "The Directory" 412 [2] Eastlake, D., Kaufman, C., "Domain Name Security Extensions", (I-D 413 draft-ietf-dnssec-secext-04.txt), Work In Progress 415 [3] Atkins, D., Stallings, W., Zimmermann, P., "PGP Message Exchange 416 Formats", (I-D draft-atkins-pgpformats-01.txt), Work In Progress 418 [4] Aziz, A., Markson, T., Prafullchandra, H., "Encoding of an Unsigned 419 Diffie-Hellman Public Value", (I-D draft-ietf-ipsec-skip-udh- 420 00.txt), Work In Progress 422 [5] Postel, J., "Address Mappings", IEN 115, USC/Information Sciences 423 Institute, August 1979 425 [6] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 426 (I-D draft-ietf-ipngwg-addr-arch-03.txt), Work In Progress 428 [7] Crocker, D., "Standard for the format of ARPA Internet text 429 messages", RFC 822 431 [8] Postel, J., "User Datagram Protocol", RFC 768 433 [9] Karn, P., Simpson, W. A., "The Photuris Session Key Management 434 Protocol", (I-D draft-ietf-ipsec-photuris-08.txt), Work In Progress 436 [10] R. Rivest, "The MD5 Message Digest Algorithm", RFC 1321, April 1992 438 [11] CCITT Recommendation X.509 (1988), "The Directory - Authentication 439 Framework" 441 [12] Aziz, A., Markson, T., Prafullchandra, H., "Simple Key-Management 442 for Internet Protocols", (I-D draft-ietf-ipsec-skip-06.txt), Work In 443 Progress 445 Author's Address(es) 446 Ashar Aziz 447 Sun Microsystems, Inc. 448 M/S PAL1-550 449 2550 Garcia Avenue 450 Mountain View, CA 94043 451 ashar.aziz@eng.sun.com 453 Tom Markson 454 Sun Microsystems, Inc. 455 M/S PAL1-550 456 2550 Garcia Avenue 457 Mountain View, CA 94043 458 markson@eng.sun.com 460 Hemma Prafullchandra 461 Sun Microsystems, Inc. 462 M/S PAL1-550 463 2550 Garcia Avenue 464 Mountain View, CA 94043 465 hemma@eng.sun.com 467 Rich Skrenta 468 Sun Microsystems, Inc. 469 M/S PAL1-550 470 2550 Garcia Avenue 471 Mountain View, CA 94043 472 skrenta@eng.sun.com 474 Germano Caronni 475 Computer Engineering and Networks Laboratory 476 Swiss Federal Institute of Technology (ETH) 477 ETH Zentrum 478 CH-8092 Zurich 479 caronni@tik.ee.ethz.ch 481 CONTENTS 483 Status of this Memo................................. 1 485 Abstract............................................ 2 487 1. Overview............................................ 3 489 2. Overview of the Certificate Discovery Protocol 490 (CDP)............................................... 4 492 2.1 Clogging Defense............................... 5 494 2.1.1 Cookie Generation 6 496 3. Certificate Discovery Packet........................ 6 498 3.1 CDP Header..................................... 7 500 3.2 CDP Record..................................... 8 502 4. Assigned Numbers.................................... 10 504 4.1 Port Number Assignments........................ 10 506 4.2 Name Type Assignments.......................... 10 508 4.3 Certificate Type Assignments................... 10 510 5. Security Considerations............................. 11 512 Acknowledgements.................................... 11 514 References.......................................... 11 516 Author's Address(es)................................ 12 518 - i -