· web viewkerberos token profile . interop scenarios. working draft 01, 21 sep 2004. editor: alan...

Web Services Security: Kerberos Token Profile Interop ScenariosWorking Draft 01, 21 Sep 2004Editor:

Alan Geller, Microsoft <[email protected]>

Contributors:Vijay Gajjala, Microsoft <[email protected]>HongMei Ge, Microsoft <[email protected]>Chris Kaler, Microsoft <[email protected]>Doug Walter, Microsoft <[email protected]>

Abstract:This document documents the two scenarios to be used in the first WSS Kerberos Token Profile Interoperability Event.

Status:Committee members should send comments on this specification to the [email protected] list. Others should subscribe to and send comments to the [email protected] list. To subscribe, send an email message to [email protected] with the word "subscribe" as the body of the message.

20-Sep-2004 of 19

1

2

3

4

5

67

89101112

131415

161718192021

12

3456

mailto:[email protected]






Table of Contents1 Introduction............................................................................................................................ 3

1.1 Terminology.......................................................................................................................... 31.2 Namespaces......................................................................................................................... 3

2 Test Application...................................................................................................................... 43 Scenario #1............................................................................................................................ 5

3.1 Agreements.......................................................................................................................... 53.2 Parameters........................................................................................................................... 53.3 General Message Flow.........................................................................................................53.4 First Message - Request.......................................................................................................5

3.4.1 Message Elements and Attributes.................................................................................53.4.2 Message Creation.........................................................................................................73.4.3 Message Processing.....................................................................................................73.4.4 Example (Non-normative).............................................................................................8

3.5 Second Message - Response...............................................................................................93.5.1 Message Elements and Attributes.................................................................................93.5.2 Message Creation.......................................................................................................103.5.3 Message Processing...................................................................................................103.5.4 Example (Non-normative)...........................................................................................10

3.6 Other processing................................................................................................................113.6.1 Requester....................................................................................................................113.6.2 Responder................................................................................................................... 11

3.7 Successful Completion.......................................................................................................113.8 Expected Security Properties.............................................................................................12

4 Scenario #2..........................................................................................................................135 References........................................................................................................................... 14

5.1 Normative........................................................................................................................... 14Appendix A. Ping Application WSDL File......................................................................................15Appendix B. Revision History........................................................................................................16Appendix C. Notices..................................................................................................................... 17

20-Sep-2004 of 19

22

2324252627282930313233343536373839404142434445464748495051

52

78

9101112

1 IntroductionThis document describes the two message exchanges to be tested during the first Kerberos token profile interoperability event of the WSS TC. Both use the Request/Response Message Exchange Pattern (MEP) with no intermediaries. Both invoke the same simple application. These scenarios are intended to test the interoperability of different implementations performing common operations and to test the soundness of the various specifications and clarity and mutual understanding of their meaning and proper application.THESE SCENARIOS ARE NOT INTENDED TO REPRESENT REASONABLE OR USEFUL PRACTICAL APPLICATIONS OF THE SPECIFICATIONS. THEY HAVE BEEN DESIGNED PURELY FOR THE PURPOSES INDICATED ABOVE AND DO NOT NECESSARILY REPRESENT EFFICIENT OR SECURE MEANS OF PERFORMING THE INDICATED FUNCTIONS. IN PARTICULAR THESE SCENARIOS ARE KNOWN TO VIOLATE SECURITY BEST PRACTICES IN SOME RESPECTS AND IN GENERAL HAVE NOT BEEN EXTENSIVELY VETTED FOR ATTACKS.

1.1 TerminologyThe key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].

1.2 NamespacesThe following namespaces are used in this document. The choice of any namespace prefix is arbitrary and not semantically significant.

Prefix Namespace

soap http://schemas.xmlsoap.org/soap/envelope/

wsse http://www.docs.oasis-open.org/wss/2004/01oasis-200401-wss-wssecurity-secext-1.0.xsd

wsu http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd

ds http://www.w3.org/2000/09/xmldsig#

xenc http://www.w3.org/2001/04/xmlenc#

p http://xmlsoap.org/Ping

20-Sep-2004 of 19

5354555657585960616263646566

67686970

717273

74

1314

15161718

http://www.w3.org/2001/04/xmlenc#

http://www.w3.org/2000/09/xmldsig#

2 Test ApplicationBoth scenarios use the same, simple application: the Requestor sends a Ping element with a value of a string, and the Responder returns a PingResponse element with a value of the same string. In both scenarios, the initial request includes a Kerberos AP_REQ token; the session key contained therein is used to sign specific elements of the request. The response contains a reference to the token that was included in the request, and uses the same session key to sign and encrypt the contents of the response body.In the first scenario, the Requestor obtains the AP_REQ token from a key distribution center (KDC) manufactured by the same vendor as the Requestor; in the second, the AP_REQ token is obtained from a KDC manufactured by the same vendor as the Responder.Pictorially, scenario 1 looks like:

And scenario 2 looks like:

20-Sep-2004 of 19

Vendor BVendor A

Requestor Responder

Kerberos KDC

Vendor BVendor A

Requestor Responder

Kerberos KDC

757677787980818283848586

8788

1920

21222324

3 Scenario #13.1 AgreementsThis section describes the agreements that must be made, directly or indirectly between parties who wish to interoperate.Both Requestor and Responder MUST belong to a single Kerberos realm. The KDC for this realm MUST be manufactured by the same vendor as the Requestor.

3.2 ParametersThis section describes parameters that are required to correctly create or process messages, but not a matter of mutual agreement.No parameters are required.

3.3 General Message FlowThis section provides a general overview of the flow of messages.This contract covers a request/response MEP over the http binding. SOAP 1.1 MUST be used. As required by SOAP 1.1, the SOAPAction http header MUST be present in the request. The value MUST be "Ping". The recipient SHOULD ignore the value. The request contains a Kerberos AP_REQ message embedded in a BinarySecurityToken. The Responder checks the message and issues a Fault if any errors are found. Otherwise, it returns the response.

3.4 First Message - Request

3.4.1 Message Elements and AttributesHeader elements not listed in the following table MAY be present, but MUST NOT be marked with the mustUnderstand=”1” attribute. Items marked mandatory MUST be generated and processed. Items marked optional MAY be generated and MUST be processed if present.The values provided for IDs and URI references, "token", "timestamp", and "body", within the message may be changed so long as the references remain valid.

Name Mandatory?

/soap:Header Mandatory

/wsse:Security Mandatory

@mustUnderstand=“1” Mandatory

/wsu:Timestamp Mandatory

20-Sep-2004 of 19

89

9091929394

95969798

99100101102103104105106

107

108109110111112113

114

2526

27282930

@wsu:Id="timestamp" Mandatory

/wsu:Created Mandatory

/wsu:Expires Optional

/wsse:BinarySecurityToken Mandatory

@ValueType="http://www.docs.oasis-open.org/wss/2004/07/oasis-000000-wss-kerberos-token-profile-1.0#Kerberosv5_AP_REQ"

Mandatory

@EncodingType ="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"

Mandatory

@wsu:Id="token" Mandatory

/ds:Signature Mandatory

/ds:SignedInfo Mandatory

/ds:CanonicalizationMethod Mandatory

@Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" Mandatory

/ds:SignatureMethod Mandatory

@Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" Mandatory

/ds:Reference URI="#timestamp" Mandatory

/ds:Transforms Mandatory

/ds:Transform Mandatory


/ds:DigestMethod Mandatory

@Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" Mandatory

/ds:DigestValue Mandatory

/ds:Reference URI="#body" Mandatory







20-Sep-2004 of 19

3132

33343536

/ds:SignatureValue Mandatory

/ds:KeyInfo Mandatory

/wsse:SecurityTokenReference Mandatory

/wsse:Reference Mandatory

@URI="#token" Mandatory


Mandatory

/soap:Body Mandatory

@wsu:Id="body" Mandatory

/p:Ping Mandatory

3.4.2 Message Creation

3.4.2.1 BinarySecurityTokenThe binary security token MUST contain the base 64 binary encoding of the KRB_AP_REQ message, as defined in [RFC1510]. The Kerberos message MUST NOT require mutual authentication in the ap-options field.

3.4.2.2 TimestampThe Created element MUST contain a timestamp that specifies when the request was created, according to the Requestor's clock.

3.4.2.3 SignatureThe signature MUST contain a signature over the Timestamp and Body elements, computed using the key embedded in the binary security token and the indicated canonicalization, digest, and signature algorithms.

3.4.2.4 BodyThe body is not encrypted. The Ping element should contain an arbitrary non-empty string selected by the Requestor.

3.4.3 Message ProcessingThis section describes the processing performed by the Responder. If an error is detected, the processing of this message stops and a Fault is issued.

20-Sep-2004 of 19

115

116

117118119120

121122123

124125126127

128129130

131132133

3738

39404142

3.4.3.1 BinarySecurityTokenThe Responder MUST decode the binary security token to recover the KRB_AP_REQ message. The KRB_AP_REQ message MUST be processed according to [RFC1510]; in particular, the authenticator contained within the KRB_AP_REQ message must be verified and the session key recovered.

3.4.3.2 SignatureThe Responder MUST validate the signature. If the signature is not correct, then processing of this message stops and a Fault is issued.

3.4.3.3 BodyThe body is passed to the application unmodified.

3.4.4 Example (Non-normative)Here is an example request.

<?xml version="1.0" encoding="utf-8" ?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd"> <soap:Header> <wsse:Security soap:mustUnderstand=“1” xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd"> <wsu:Timestamp wsu:Id="timestamp"> <wsu:Created> ... </wsu:Created> </wsu:Timestamp> <wsse:BinarySecurityToken ValueType="http://www.docs.oasis-open.org/wss/2004/07/oasis-000000-wss-kerberos-token-profile-1.0#Kerberosv5_AP_REQ" wsu:Id="token"> ... </wsse:BinarySecurityToken> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><ds:SignatureMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" /><ds:Reference URI="#timestamp">

<ds:Transforms><ds:Transform

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ds:Transforms><ds:DigestMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><ds:DigestValue> ... </DigestValue>

</ds:Reference><ds:Reference URI="#body">

<ds:Transforms>

20-Sep-2004 of 19

134135136137138

139140141

142143

144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181

4344

45464748

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />

</ds:Transforms><ds:DigestMethod


</ds:Reference> </ds:SignedInfo> <ds:SignatureValue> ... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#token"

ValueType="http://www.docs.oasis-open.org/wss/2004/07/oasis-000000-wss-kerberos-token-profile-1.0#Kerberosv5_AP_REQ" /> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </soap:Header> <soap:Body wsu:Id="body"> <p:Ping xmlns:p="http://xmlsoap.org/Ping"> ... </p:Ping> </soap:Body></soap:Envelope>

3.5 Second Message - Response

3.5.1 Message Elements and AttributesHeader elements not listed in the following table MAY be present, but MUST NOT be marked with the mustUnderstand=”1” attribute. Items marked mandatory MUST be generated and processed. Items marked optional MAY be generated and MUST be processed if present. The value provided for the ID and URI reference, "response", within the message may be changed so long as the reference remains valid.

Name Mandatory?

/soap:Header Mandatory

/wsse:Security Mandatory

@mustUnderstand=“1” Mandatory

/wsu:Timestamp Optional

/wsu:Created Optional

/wsu:Expires Optional

/xenc:ReferenceList Mandatory

/xenc:DataReference Mandatory

20-Sep-2004 of 19

182183184185186187188189190191192193194195196197198199200201202203204205206

207

208209210211212213

214

4950

51525354

@URI="#response" Mandatory

/ds:Signature Mandatory

/ds:SignedInfo Mandatory

/ds:CanonicalizationMethod Mandatory


/ds:SignatureMethod Mandatory

@Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" Mandatory

/ds:Reference URI="#timestamp" Mandatory







/ds:Reference URI="#body" Mandatory







/ds:SignatureValue Mandatory



/wsse:KeyIdentifier Mandatory


Mandatory

/soap:Body Mandatory

@wsu:Id="body" Mandatory

20-Sep-2004 of 19

5556

57585960

/xenc:EncryptedData Mandatory

@Id="response" Mandatory

@Type="http://www.w3.org/2001/04/xmlenc#Content" Mandatory

/xenc:EncryptionMethod Mandatory

@Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" Mandatory



/wsse:KeyIdentifier Mandatory


Mandatory

/xenc:CipherData Mandatory

/xenc:CipherValue Mandatory

3.5.2 Message Creation

3.5.2.1 SecurityTokenReferenceThe security token reference MUST contain the base 64 binary encoding of the SHA1 hash of the pre-encoded octets that were used to form the contents of the <wsse:BinarySecurityToken> element in the original request, as specified in [WSS-Kerb] .

3.5.2.2 KeyIdentifierThe key identifier MUST contain the base 64 binary encoding of the SHA1 hash of the pre-encoded octets that were used to form the contents of the <wsse:BinarySecurityToken> element in the original request, as specified in [WSS-Kerb] .

3.5.2.3 SignatureThe signature MUST contain the HMAC-SHA1 signature of the (unencrypted) body and timestamp. If the signature is not correct, then processing of this message stops.

3.5.2.4 BodyThe body is encrypted using the key contained in the AP_REQ message. The unencrypted body MUST consist of exactly one p:PingResponse element that contains the same string that was contained in the p:Ping body element original request.

3.5.3 Message ProcessingThe decrypted body is passed to the application.

20-Sep-2004 of 19

215

216

217218219220

221222223224

225226227

228229230231

232233

6162

63646566

The application should verify that the string contained in the PingResponse element is the same as the string sent in the Ping element in the original request.

3.5.4 Example (Non-normative)Here is an example response.

<?xml version="1.0" encoding="utf-8" ?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <soap:Header> <wsse:Security soap:mustUnderstand=“1” xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd"> <wsu:Timestamp wsu:Id="timestamp"> <wsu:Created> ... </wsu:Created> <wsu:Expires> ... </wsu:Expires> </wsu:Timestamp> <xenc:ReferenceList> <xenc:DataReference URI="#response" /> </xenc:ReferenceList> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><ds:SignatureMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" /><ds:Reference URI="#timestamp">




</ds:Reference><ds:Reference URI="#body">




</ds:Reference> </ds:SignedInfo> <ds:SignatureValue> ... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:KeyIdentifier ValueType="http://www.docs.oasis-open.org/wss/2004/07/oasis-000000-wss-kerberos-token-profile-1.0#Kerberosv5_AP_REQ"> ...

20-Sep-2004 of 19

234235

236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287

6768

69707172

</wsse:KeyIdentifier> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </soap:Header> <soap:Body wsu:Id="body">  <xenc:EncryptedData Id="response" Type="http://www.w3.org/2001/04/xmlenc#Content"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" /> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:KeyIdentifier ValueType="http://www.docs.oasis-open.org/wss/2004/07/oasis-000000-wss-kerberos-token-profile-1.0#Kerberosv5_AP_REQ"> ... </wsse:KeyIdentifier> </wsse:SecurityTokenReference> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue> ... </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </soap:Body></soap:Envelope>

3.6 Other processingThis section describes processing that occurs outside of generating or processing a message.

3.6.1 RequesterNo additional processing is required.

3.6.2 ResponderNo additional processing is required.

3.7 Successful CompletionSuccessful completion of this scenario is defined as successful completion of the following steps:

1. Requestor sends the request message to Responder2. Responder verifies the signature on the request message3. Responder sends the response message to Requestor4. Requestor decrypts the response message5. Requestor verifies the signature on the request message against the decrypted response

message body

20-Sep-2004 of 19

288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318

319320

321322

323324

325326327328329330331332

7374

75767778

6. Requestor verifies that the decrypted p:PingResponse element contains the same string as the p:Ping element in the original request message

3.8 Expected Security PropertiesThe Requestor and Responder know that both are able to derive the session key from the Kerberos AP_REQ message.The request message body and timestamp are protected against modification but not interception.The response message is protected against interception and modification.

20-Sep-2004 of 19

333334

335336337338339340

7980

81828384

4 Scenario #2The second scenario is identical to the first, except that the KDC MUST be manufactured by the same vendor as the Recipient.

20-Sep-2004 of 19

341342343

8586

87888990

5 References5.1 Normative

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[RFC1510] J. Kohl, C. Neuman, The Kerberos Network Authentication Service (V5), http://rfc.net/rfc1510.html, IETF RFC 1510, September 1993.

[WSS] A. Nadalin et al, Web Services Security: SOAP Message Security 1.0, http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf, OASIS Standard 200401, March 2004

[WSS-Kerb] A. Nadalin et al, Web Services Security: Kerberos Token Profile 1.0, http://www.oasis-open.org/apps/org/workgroup/wss/download.php/8266/oasis-xxxxxx-wss-kerberos-token-profile-1%200.pdf, Working Draft 05, 27 July 2004

20-Sep-2004 of 19

344

345346347348349350351352353354355356

9192

93949596

http://www.oasis-open.org/apps/org/workgroup/wss/download.php/8266/oasis-xxxxxx-wss-kerberos-token-profile-1%200.pdf

http://www.oasis-open.org/apps/org/workgroup/wss/download.php/8266/oasis-xxxxxx-wss-kerberos-token-profile-1%200.pdf

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

http://rfc.net/rfc1510.html

http://www.ietf.org/rfc/rfc2119.txt

Appendix A. Ping Application WSDL File<definitions xmlns:tns=http://xmlsoap.org/Ping

xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" targetNamespace="http://xmlsoap.org/Ping" name="Ping">

<types><schema targetNamespace="http://xmlsoap.org/Ping"

xmlns="http://www.w3.org/2001/XMLSchema"><element name="Ping" type="xsd:string"/><element name="PingResponse" type="xsd:string"/>

</schema></types><message name="PingRequest">

<part name="ping" element="tns:Ping"/></message><message name="PingResponse">

<part name="pingResponse" element="tns:PingResponse"/></message><portType name="PingPort">

<operation name="Ping"><input message="tns:PingRequest"/><output message="tns:PingResponse"/>

</operation></portType><binding name="PingBinding" type="tns:PingPort">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="Ping"><soap:operation/><input>

<soap:body use="literal"/></input><output>

<soap:body use="literal"/></output>

</operation></binding><service name="PingService">

<port name="PingPort" binding="tns:PingBinding"><soap:address location="http://localhost:8080/ping/Ping"/>

</port></service>

</definitions>

20-Sep-2004 of 19

357

358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400

401

9798

99100101102

http://xmlsoap.org/Ping

Appendix B. Revision History

Rev Date By Whom What

wss-01 2003-09-23 Alan Geller Initial version

20-Sep-2004 of 19

402

403

404

103104

105106107108

Appendix C. NoticesOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.Copyright © OASIS Open 2004. All Rights Reserved.This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

20-Sep-2004 of 19

405

406407408409410411412413414415416417418419420421422423424425426427428429430431432433434

109110

111112113114

· web viewkerberos token profile . interop scenarios. working draft 01, 21 sep 2004. editor: alan...

Documents