added draft-ietf-tls-wireless

1 files changed, 743 insertions, 0 deletions

diff --git a/doc/draft-ietf-tls-wireless-00.txt b/doc/draft-ietf-tls-wireless-00.txt
new file mode 100644
index 0000000000..77e59277d8
--- /dev/null
+++ b/doc/draft-ietf-tls-wireless-00.txt
@@ -0,0 +1,743 @@
+
+
+
+
+TLS Working Group                             Simon Blake-Wilson, Certicom
+INTERNET-DRAFT                                Magnus Nystrom, RSA Security
+Expires May 16, 2001                                     November 17, 2000
+
+                        Wireless Extensions to TLS
+                     <draft-ietf-tls-wireless-00.txt>
+
+                          Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026. Internet-Drafts are working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or made obsolete by other documents at
+   any time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as work in progress.
+
+   The list of current Internet-Drafts may be found at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories may be found at
+   http://www.ietf.org/shadow.html.
+
+
+                               Abstract
+
+   This document suggests extensions to TLS designed to make TLS more 
+   amenable to use within wireless environments. The extensions may be
+   used by TLS clients and servers. The extensions are backwards
+   compatible - communication is possible between TLS 1.0 clients
+   that support the extensions and TLS 1.0 servers that do not
+   support the extensions, and vice versa.
+
+   The document suggests extensions of two types: generic extension
+   mechanisms for the TLS client and server hellos, and specific
+   extensions using these generic mechanisms. It is hoped that the
+   structure of the document will allow each suggested extension to be
+   evaluated independently.
+
+   This document is based on discussions at the TLS working group
+   meeting during the Pittsburgh IETF meeting, and on discussions
+   within the WAP security group.
+
+   The 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 RFC 2119.
+
+   Please send comments on this document to the TLS mailing list.
+
+
+Blake-Wilson, Nystrom                                           [Page 1]
+
+INTERNET-DRAFT                                          17 November 2000
+
+
+                            Table of Contents
+
+   1. Introduction ............................................... 2
+   2. General Extension Mechanisms ............................... 4
+   2.1. Extended Client Hello .................................... 4
+   2.2. Extended Server Hello .................................... 4
+   2.3. Hello Extensions ......................................... 5
+   3. Wireless Extensions ........................................ 6
+   3.1.	Maximum Record Size Negotiation .......................... 6
+   3.2.	Client Certificate URLs .................................. 7
+   3.3.	Trusted CA Indication .................................... 8
+   3.4.	Small Session Identifiers ................................ 9
+   3.5.	Truncated MACs .......................................... 10 
+   3.6.	OCSP .................................................... 11
+   4. Security Considerations ................................... 12
+   5. Intellectual Property Rights .............................. 12
+   6. Acknowledgments ........................................... 12
+   7. References ................................................ 12
+   8. Authors' Addresses ........................................ 13
+
+
+1. Introduction
+
+Wireless environments often suffer from a number of constraints not
+commonly present in wired environments - these constraints may include
+bandwidth limitations, computational power limitations, memory 
+limitations, and battery life limitations.
+
+Use within wireless environments was not one of the initial design
+criteria of the TLS protocol. As a result, implementations of TLS
+within wireless environments face a number of challenges.
+
+This document specifies extensions to the TLS 1.0 protocol designed to
+make TLS more amenable to use within wireless environments. The 
+extensions described here focus on extending the functionality provided
+by the TLS protocol message formats. Other issues, such as the addition
+of "wireless-friendly" cipher suites, are deferred.
+
+Specifically, the extensions described in this document are designed
+to:
+
+- Allow TLS clients and servers to negotiate the maximum record size to
+  be sent. This functionality is desirable as a result of memory 
+  constraints common among wireless clients, and bandwidth constraints
+  common among wireless networks.
+
+- Allow TLS clients and servers to negotiate the use of client
+  certificate URLs. This functionality is desirable in order to
+  conserve memory on wireless clients.
+
+
+Blake-Wilson, Nystrom                                           [Page 2]
+
+INTERNET-DRAFT                                          17 November 2000
+
+
+- Allow TLS clients to indicate to TLS servers which CA root keys they
+  possess. This functionality is desirable in order to prevent multiple
+  handshake failures involving TLS clients which are only able to store
+  a small number of CA root keys due to memory limitations.
+
+- Encourage TLS servers to use small session identifiers. This 
+  functionality is desirable in order to conserve memory on wireless
+  clients.
+
+- Allow TLS clients and servers to negotiate the use of truncated MACs.
+  This functionality is desirable in order to conserve bandwidth in
+  wireless networks.
+
+- Allow TLS clients and servers to negotiate that the server sends the
+  client an OCSP response during a TLS handshake. This functionality is
+  desirable in order to avoid sending a CRL over a wireless network and
+  therefore save bandwidth.  
+
+In order to support the extensions above, general extension mechanisms
+for the client hello message and the server hello message are
+introduced.
+
+The extensions described in this document may be used by TLS 1.0
+clients and TLS 1.0 servers. The extensions are designed to be
+backwards compatible - meaning that TLS 1.0 clients that support the
+extensions can talk to TLS 1.0 servers that do not support the
+extensions, and vice versa. 
+
+Backwards compatibility is primarily achieved via two considerations:
+
+- Clients typically request the use of extensions via the extended
+  client hello message described in Section 2.1. TLS 1.0 [TLS] requires
+  servers to "accept" extended client hello messages, even if the server
+  does not "understand" the extension.
+
+- For the specific extensions described here, no mandatory server
+  response is required when clients request extended functionality.
+
+Note however, that although backwards compatibility is supported, some
+wireless clients may be forced to reject communications with servers
+that do not support the extensions as a result of the limited
+capabilities of the wireless clients.
+
+The remainder of this document is organized as follows. Section 2
+describes general extension mechanisms for the client hello and server
+hello handshake messages. Section 3 describes specific extensions to
+TLS 1.0. The final sections of the document address IPR, security
+considerations, acknowledgements, and references.
+
+
+
+Blake-Wilson, Nystrom                                           [Page 3]
+
+INTERNET-DRAFT                                          17 November 2000
+
+
+2. General Extension Mechanisms
+
+This section presents general extension mechanisms for the TLS
+handshake client hello and server hello messages. 
+
+These general extension mechanisms are necessary in order to enable 
+clients and servers to negotiate whether to use specific extensions,
+and how to use specific extensions. The extension formats described are
+based on [MAILING LIST].
+
+Section 2.1 specifies the extended client hello message format, Section
+2.2 specifies the extended server hello message format, and Section 2.3
+describes the actual extension format used with the extended client and
+server hellos.
+
+   
+2.1. Extended Client Hello
+
+The extended client hello message format MAY be sent in place of the
+client hello message format when clients wish to request extended
+functionality from servers. The extended client hello message format is:
+
+          struct {
+              ProtocolVersion client_version;
+              Random random;
+              SessionID session_id;
+              CipherSuite cipher_suites<2..2^16-1>;
+              CompressionMethod compression_methods<1..2^8-1>;
+              Extension client_hello_extension_list<0..2^16-1>;
+          } ClientHello;   
+
+Here the new "client_hello_extension_list" field contains a list of
+extensions. The actual "Extension" format is defined in Section 2.3.
+
+In the event that clients request additional functionality using the
+extended client hello, and this functionality is not supplied by the
+server, clients MAY abort the handshake.
+
+Note that TLS, Section 7.4.1.2, allows additional information to be
+added to the client hello message. Thus the use of the extended client
+hello defined above should not "break" existing TLS 1.0 servers.
+
+
+2.2. Extended Server Hello
+
+The extended server hello message format MAY be sent in place of the
+server hello message when the client has requested extended
+functionality via the extended client hello message specified in
+Section 2.1. The extended server hello message format is:
+
+
+Blake-Wilson, Nystrom                                           [Page 4]
+
+INTERNET-DRAFT                                          17 November 2000
+
+
+       struct {
+           ProtocolVersion server_version;
+           Random random;
+           SessionID session_id;
+           CipherSuite cipher_suite;
+           CompressionMethod compression_method;
+           Extension server_hello_extension_list<0..2^16-1>;
+       } ServerHello;
+
+Here the new "server_hello_extension_list" field contains a list of
+extensions. The actual "Extension" format is defined in Section 2.3.
+
+Note that the extended server hello message is only sent in response to
+an extended client hello message. This prevents the possibility that
+the extended server hello message could "break" existing TLS 1.0
+clients.
+
+
+2.3. Hello Extensions
+
+The extension format for extended client hellos and extended server
+hellos is:
+
+          struct {
+              ExtensionType extensionType;
+              opaque unknown_extension<0..2^16-1>;
+          } Extension;
+
+Here:
+
+- "extensionType" identifies the particular extension type.
+
+- "unknown_extension" contains information specific to the particular
+  extension type. 
+
+The extension types defined in this document are:
+
+          enum { 
+                reserved(0), max_record_size(1), 
+                client_certificate_url(2), trusted_key_ids(3), 
+                truncated_MAC(4), status_request(5), (65535) 
+          } ExtensionType;
+
+Note that for all the extension types defined in this document, the
+extension type should appear in the extended server hello only if the
+same extension type appeared in the corresponding client hello. Thus
+clients MUST abort the handshake if they receive an extension type in
+the extended server hello that they did not request in the associated
+(extended) client hello.
+
+
+Blake-Wilson, Nystrom                                           [Page 5]
+
+INTERNET-DRAFT                                          17 November 2000
+
+
+Also note that when multiple extensions are present in the extended
+client hello or the extended server hello, the extensions must appear
+in the order identified in "ExtensionType". Thus clients and servers
+MUST abort the handshake if they receive an extended hello message in
+which the extensions are not in the correct order.
+
+Finally note that it is possible to alternatively define
+"unknown_extension" using a selection on "extensionType" (instead of
+just defining it as type "opaque"). This approach appears to have pros
+and cons - using a selection is more restrictive and thus less prone to
+implementation errors, but using "opaque" ensures inclusion of the
+length and thus ensures that users can skip extensions they don't
+understand. We would particularly welcome comments on this issue.
+
+
+3. Wireless Extensions
+
+This section describes the specific TLS extensions specified in this
+document.
+
+Note that any messages associated with these extensions that is sent 
+during the TLS handshake MUST be included in the hash calculations
+involved in "Finished" messages.
+
+Section 3.1 describes the extension of TLS to provide maximum record 
+size negotiation. Section 3.2 describes the extension to allow client
+certificate URLs. Section 3.3 describes the extension to allow clients
+to indicate which CA root keys they possess. Section 3.4 describes the
+extension to restrict the size of session identifiers. Section 3.5
+describes the extension to allow the use of truncated MACs. Section 3.6
+describes the extension to support integration of OCSP into TLS
+handshakes. 
+   
+
+3.1. Maximum Record Size Negotiation
+
+TLS specifies a fixed maximum record size of 2^14 bytes. It may be
+desirable for wireless clients to negotiate a smaller maximum record
+size due to memory limitations or bandwidth limitations.
+
+In order to negotiate smaller maximum record sizes, clients MAY include
+an extension of type "max_record_size" in the (extended) client hello. 
+The "unknown-extension" field of this extension shall contain:
+
+         enum{ 
+           2^8(1), 2^9(2), 2^10(3), 2^11(4), 2^12(5), (255) 
+         } Negotiated_max_record_size ;
+
+whose value is the desired maximum record size. The allowed values for
+this field are: 2^8, 2^9, 2^10, 2^11, and 2^12.
+
+Blake-Wilson, Nystrom                                           [Page 6]
+
+INTERNET-DRAFT                                          17 November 2000
+
+
+
+Servers that receive an extended client hello containing a
+"max_record_size" extension, MAY accept the requested maximum record
+size by including an extension of type "max_record_size" in the
+(extended) server hello. The "unknown_extension" field of this
+extension shall contain "Negotiated_max_record_size" whose value is the
+same as the requested maximum record size.
+
+Servers receiving maximum record size negotiation requests for values
+other than the allowed values  MUST abort the handshake. Similarly,
+clients receiving maximum record size negotiation responses that differ
+from the size they requested MUST also abort the handshake.
+
+Once a maximum record size other than 2^14 has been successfully
+negotiated during a TLS handshake, both the client and server pass the
+negotiated maximum record size value to the TLS record layer along with
+the negotiated security parameters. (Note that it may be desirable in
+the future to update the TLS security parameters to include the maximum
+record size value.) During the subsequent session after exchange of
+change cipher spec messages, the client and server MUST ensure that no
+messages larger than the negotiated size are sent.
+
+3.2. Client Certificate URLs
+   
+TLS specifies that when client authentication is performed, client
+certificates are sent by clients to servers during the TLS handshake.
+It may be desirable for wireless clients to send a certificate URL in
+place of a certificate so that they do not need to store their
+certificate and can therefore save memory.
+
+In order to negotiate to send a certificate URL to a server, clients
+MAY include an extension of type "client_certificate_url" in the
+(extended) client hello. The "unknown_extension" field of this
+extension shall be empty. 
+
+(Note that it is necessary to negotiate use of a client certificate URL
+in order to avoid "breaking" existing TLS 1.0 servers.)
+
+Servers that receive an extended client hello containing a
+"client_certificate_url" extension, MAY indicate that they are willing
+to accept a certificate URL by including an extension of type
+"client_certificate_url" in the (extended) server hello. The
+"unknown_extension" field of this extension shall be empty.
+
+After negotiation of the use of a client certificate URL has been
+successfully completed (by exchanging hellos including
+"client_certificate_url" extensions), clients send a "CertificateorURL"
+message in place of a "Certificate" message:
+
+
+
+
+Blake-Wilson, Nystrom                                           [Page 7]
+
+INTERNET-DRAFT                                          17 November 2000
+
+
+         struct{
+              Certificate_or_URL certificate_transport_type;
+              select (Certificate_or_URL) {
+                  case certificate: 
+                      ASN.1Cert certificate_list<0..2^24-1>;
+                  case url: 
+                      opaque url<0..2^8-1>;
+              } certificate_transport_body;
+         } CertificateorURL;
+
+         enum{ certificate(1), url(2), (255) } Certificate_or_URL ;
+
+(Nevertheless, the handshake message is identified as being of type
+"certificate".)  
+
+Here:
+
+- "certificate_transport_type" indicates whether a certificate chain or
+  URL is being sent.
+
+- "certificate_transport_body" contains either a certificate chain, or
+  a certificate URL.
+
+Servers receiving "CertificateorURL" shall attempt to retrieve the
+client's certificate chain from the URL (if necessary), and then process the
+certificate chain as usual.
+
+Note that "CertificateorURL" allows the client to send either a
+certificate or a URL. The option to send a certificate, even after
+successfully negotiating the possibility to send a URL, is included to
+provide flexibility to clients possessing multiple certificates.
+
+
+3.3. Trusted CA Indication
+
+Wireless clients which, due to memory limitations, possess only a small
+number of CA root keys, may wish to indicate to servers which root keys
+they possess, in order to avoid repeated handshake failures.
+
+In order to indicate which CA root keys they possess, clients MAY
+include an extension of type "trusted_key_ids" in the (extended) client
+hello. The "unknown_extension" field of this extension shall contain
+"TrustedAuthorities" where:
+
+          TrustedAuthority TrustedAuthorities<0..2^16-1>;
+
+
+
+
+
+
+Blake-Wilson, Nystrom                                           [Page 8]
+
+INTERNET-DRAFT                                          17 November 2000
+
+
+          struct {
+              IdentifierType identifier_type;
+              select (identifier_type) {
+                  case null: struct {};
+                  case key_hash_sha: KeyHash;
+                  case x509_name: DistinguishedName;
+              } identifier;
+          } TrustedAuthority;
+
+          enum { null(0), key_hash_sha(1), x509_name(2),(255)}
+              IdentifierType;
+
+          opaque DistinguishedName<1..2^16-1>;
+
+          opaque KeyHash[20];
+
+Here "TrustedAuthorities" provides a list of CA root key identifiers
+that the client possesses. Each CA root key is identified via either:
+
+- "null" - no CA root key identity supplied.
+       
+- "key_hash_sha" - contains the SHA-1 hash of the CA root key. (For DSA
+  and ECDSA keys, this is the hash of the "subjectPublicKey" value. For
+  RSA keys, this is the hash of the byte string representation of the
+  modulus.) 
+       
+- "x509_name" - contains the X.509 distinguished name of the CA.
+
+Note that clients may include none, some, or all of the CA root keys
+they possess in this extension.
+
+(The option to include no CA root keys is included both to maintain
+syntactical similarity with Section 3.6, and to allow the client to
+indicate possession of some pre-defined set of CA root keys.)
+
+Servers that receive a client hello containing the "trusted_key_ids"
+extension, MAY use the information contained in the extension to guide
+their selection of an appropriate certificate chain to return to the
+client. 
+   
+
+3.4. Small Session Identifiers
+   
+TLS specifies that session identifiers can be up to 32 bytes in length.
+In order to save memory, it is desirable to restrict the size of
+session identifiers which are stored by wireless clients.
+
+The syntax used by TLS for session identifiers is:
+
+          opaque SessionID<0..32>;
+
+Blake-Wilson, Nystrom                                           [Page 9]
+
+INTERNET-DRAFT                                          17 November 2000
+
+
+In order to encourage use of small session identifiers, servers SHOULD
+select session identifiers whose length is 8 bytes or less.
+
+
+3.5. Truncated MACs
+
+TLS uses the MAC construction HMAC with either MD5 or SHA-1 [HMAC] to
+authenticate record layer communications. In TLS the entire output of
+the hash function is used as the MAC tag. However it may be desirable
+in wireless environments to save bandwidth by truncating the output of
+the hash function when forming MAC tags.
+
+In order to negotiate the use of truncated MACs, clients MAY include an
+extension of type "truncated_MAC" in the extended client hello. The
+"unknown_extension" field of this extension shall contain
+"MACTruncations", where:
+
+          MACTruncation MACTruncations<0..2^8-1>;
+
+          struct {
+              MACAlgorithm mac_type;
+              uint16 trucation_size_in_bits
+          } MACTruncation;
+
+          enum { null(0), md5(1), sha1(2), (255) } MACAlgorithm;
+
+Here "MACTruncations" contains a list of MAC truncation sizes suggested
+by the client. Allowed values for suggested truncation sizes are: for
+HMAC-with-SHA1 ("sha1") - 80 bits; and for HMAC-with-MD5 ("md5") - 80
+bits. 
+
+Servers that receive an extended hello containing a "truncated_MAC"
+extension, MAY agree to use a truncated MAC by including an extension
+of type "truncated_MAC" in the extended server hello. The
+"unknown_extension" field of this extension shall contain
+"MACTruncation". Here "MACTruncation" shall contain the agreed MAC
+truncation size, select from the list suggested by the client. Note
+that the "MACAlgorithm" identified in "MACTruncation" must match the
+MAC used by the established cipher suite.
+
+Servers receiving MAC truncation negotiation requests requesting values
+other than the allowed values, MUST abort the handshake. Similarly
+clients receiving MAC truncation negotiation responses that differ from
+the values they suggested, or that do not match the established cipher
+suite, MUST abort the handshake.
+
+Once MAC truncation has been successfully negotiated during a TLS
+handshake, both the client and the server pass the negotiated
+truncation size to the TLS record layer along with the other negotiated
+security parameters. Subsequently during the session, clients and
+
+Blake-Wilson, Nystrom                                          [Page 10]
+
+INTERNET-DRAFT                                          17 November 2000
+
+servers MUST use truncated MACs. (Truncated MACs are calculated as
+specified in [HMAC].)
+
+3.6. OCSP
+   
+Wireless clients may wish to use OCSP [OCSP] to check the validity of
+server certificates, in order to avoid transmission of CRLs and
+therefore save bandwidth on wireless networks.
+
+In order to indicate their desire to use OCSP, clients MAY include an
+extension of type "status_request" in the (extended) client hello. The
+"unknown_extension" field of this extension shall contain
+"TrustedAuthorities" as defined in Section 3.3.
+
+Here "TrustedAuthorities" provides a list of OCSP responders that the
+client trusts. The "null" alternative in "TrustedAuthorities" can be
+used to indicate that the responders are implicitly known to the server
+- e.g. by prior arrangement.
+
+Servers that receive a client hello containing the "status_request"
+extension, MAY return an OCSP response to the client along with their
+certificate, and MAY use the information contained in the extension
+when selecting an OCSP responder.
+
+Servers return an OCSP response along with their certificate by sending
+"CertificateAndOCSPResponse" in place of the "Certificate" message. If
+a server returns an OCSP response, then the server MUST include an
+extension of type "status_request" with empty "unknown_extensions" in the
+extended server hello. 
+
+          struct {
+              ASN.1Cert    certificate_list<0..2^24-1>;
+              OCSPResponse ocsp_response;
+          } CertificateAndOCSPResponse;
+
+          opaque ASN.1Cert<1..2^24-1>;
+
+          opaque OCSPResponse<1..2^24-1>;
+
+(Nevertheless, the handshake message is identified as being of type
+"certificate".) 
+
+Here "ocsp_response" contains a complete, DER-encoded OCSP response.
+Note that only one OCSP response may be sent.
+
+Note that a server MAY also choose not to send the
+"CertificateAndOCSPResponse" message, and instead send the "Certificate"
+message, even if it receives a "status_request" extension in the
+client hello message. 
+
+Note in addition that servers MUST NOT send the
+"CertificateAndOCSPResponse" message unless it received a
+"status_request" extension in the client hello message.
+
+Clients requesting an OCSP response, and receiving an OCSP response in
+a "CertificateAndOCSPResponse" field:
+
+- MUST process the certificate as if it was received in a "Certificate"
+  message, and;
+
+- MAY check the OCSP response and abort the handshake if the response
+  is not satisfactory. 
+
+Blake-Wilson, Nystrom                                          [Page 11]
+
+INTERNET-DRAFT                                          17 November 2000
+
+
+4. Security Considerations
+
+The use of the extensions specified in this document may introduce
+security concerns for TLS clients and servers.
+
+In particular, it is possible that truncated MACs are weaker than
+"un-truncated" MACs. No such weaknesses are currently known for the
+truncation sizes specified in this document.
+
+In addition, it is possible that which CA root keys a client possesses
+could be regarded as confidential information. As a result, the CA root
+key indication extension should be used with care.
+
+Also, TLS entities must be aware of the fact that until the handshake
+has been authenticated, active attackers can modify messages and
+insert, remove, or replace extensions.
+
+In general, implementers should continue to monitor the state of the
+art, and address any weaknesses identified.
+
+Additional security considerations are described in the TLS RFC [TLS].    
+
+
+5. Intellectual Property Rights
+ 
+The IETF 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 practice this
+document. Please address the information to the IETF Executive Director.
+  
+
+6. Acknowledgments
+
+The authors wish to thank the WAP Security Group. This document is
+based on discussion within the WAP Security Group.
+
+
+7. References
+
+[HMAC] Krawczyk, H., Bellare, M., and Canetti, R. - HMAC: Keyed-hashing
+  for message authentication. IETF RFC 2104, February 1997.
+
+[MAILING LIST] Mikkelsen, J. Eberhard, R., and J. Kistler, "General
+  ClientHello extension mechanism and virtual hosting," Ietf-tls
+  mailing list posting, August 14, 2000.
+
+[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
+  Adams, "Internet X.509 Public Key Infrastructure: Online Certificate
+  Status Protocol - OCSP," IETF RFC 2560, June 1999.
+
+
+Blake-Wilson, Nystrom                                          [Page 12]
+
+INTERNET-DRAFT                                          17 November 2000
+
+
+[TLS] Dierks, T., and C. Allen, "The TLS Protocol - Version 1.0,"
+  IETF RFC 2246, January 1999.
+
+
+8. Authors' Addresses
+
+           Simon Blake-Wilson
+           Certicom Corp.
+           sblake-wilson@certicom.com
+
+           Magnus Nystrom
+           RSA Security
+           magnus@rsasecurity.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blake-Wilson, Nystrom                                          [Page 13]
+