Internet DRAFT - draft-dthakore-tls-authz
draft-dthakore-tls-authz
Transport Layer Security D. Thakore
Internet-Draft CableLabs
Intended status: Informational February 2, 2015
Expires: August 6, 2015
Transport Layer Security (TLS) Authorization Using DTCP Certificate
draft-dthakore-tls-authz-09
Abstract
This document specifies the use of Digital Transmission Content
Protection (DTCP) certificates as an authorization data type in the
authorization extension for the Transport Layer Security (TLS)
Protocol. This is in accordance with the guidelines for
authorization extensions as specified in [RFC5878]. As with other
TLS extensions, this authorization data can be included in the client
and server Hello messages to confirm that both parties support the
desired authorization data types. If supported by both the client
and the server, DTCP certificates are exchanged in the supplemental
data TLS handshake message as specified in RFC4680. This
authorization data type extension is in support of devices containing
DTCP certificates, issued by the Digital Transmission Licensing
Administrator [DTLA].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted 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."
This Internet-Draft will expire on August 6, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Thakore Expires August 6, 2015 [Page 1]
Internet-Draft TLS Auth Using DTCP February 2015
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overview of DTCP Certificates . . . . . . . . . . . . . . 4
2.2. Overview of Supplemental Data handshake . . . . . . . . . 4
2.3. Overview of authorization extensions . . . . . . . . . . 5
2.4. Overview of supplemental data usage for authorization . . 6
3. DTCP Authorization Data Format . . . . . . . . . . . . . . . 6
3.1. DTCP Authorization Type . . . . . . . . . . . . . . . . . 6
3.2. DTCP Authorization Data . . . . . . . . . . . . . . . . . 6
3.3. Usage rules for clients to exchange DTCP Authorization
data . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Usage rules for servers to exchange DTCP Authorization
data . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. TLS message exchange with dtcp_authz_data . . . . . . . . 8
3.6. Alert Messages . . . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
The Transport Layer Security (TLS) protocol (TLS1.0 [RFC2246], TLS1.1
[RFC4346], TLS1.2 [RFC5246]) is being used in an ever increasing
variety of operational environments, the most common among which is
its use in securing HTTP traffic ([RFC2818]). [RFC5878] introduces
extensions that enable TLS to operate in environments where
authorization information needs to be exchanged between the client
and the server before any protected data is exchanged. The use of
these TLS authorization extensions is especially attractive since it
allows the client and server to determine the type of protected data
to exchange based on the authorization information received in the
extensions.
Thakore Expires August 6, 2015 [Page 2]
Internet-Draft TLS Auth Using DTCP February 2015
A substantial number of deployed consumer electronics devices such as
televisions, tablets, game consoles, set-top boxes and other
multimedia devices contain [DTLA] issued Digital Transmission Content
Protection [DTCP] certificates. These DTCP certificates enable
secure transmission of premium audio-visual content between devices
over various types of links (e.g., DTCP over IP [DTCP-IP]). These
DTCP certificates can also be used to verify device functionality
(e.g., supported device features)
This document describes the format and necessary identifiers to
exchange DTCP certificates within the supplemental data message (see
[RFC4680]) while negotiating a TLS session. The DTCP certificates
are then used independent of their use for content protection (e.g.,
to verify supported features) and the corresponding DTCP
Authentication and Key Exchange (AKE) protocol. This communication
allows either the client or the server or both to perform certain
actions or provide specific services. The actual semantics of the
authorization decision by the client/server are beyond the scope of
this document. The DTCP certificate, which is not an X.509
certificate, can be cryptographically tied to the X.509 certificate
being used during the TLS tunnel establishment by an EC-DSA [DTCP]
signature.
1.1. Applicability Statement
DTCP-enabled consumer electronics devices (eg. televisions, game
consoles) use DTCP certificates for secure transmission of audio-
visual content. The Authentication and Key Exchange (AKE) protocol
defined in [DTCP] is used to exchange DTCP Certificates and allows a
device to be identified and authenticated based on the information in
the DTCP Certificate. However these DTCP-enabled devices offer
additional functionality (e.g., via HTML5 User Agents or web enabled
applications) that is distinct from its capability to transmit and
play audio-visual content. The mechanism outlined in this document
allows a DTCP-enabled consumer electronics device to authenticate and
authorize using its DTCP Certificate when accessing services over the
internet; for example ,web applications on televisions that can
enable value-added services. This is anticipated to be very valuable
since there are a considerable number of such devices. The re-use of
well-known web security will also keep such communication consistent
with existing standards and best practices.
1.2. Conventions
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 [RFC2119].
Thakore Expires August 6, 2015 [Page 3]
Internet-Draft TLS Auth Using DTCP February 2015
2. Overview
2.1. Overview of DTCP Certificates
DTCP certificates issued by [DTLA] to DTLA-compliant devices come in
three general variations (see [DTCP], Section 4.2.3.1)
* Restricted Authentication device certificate format (Format 0):
Typically issued to devices with limited computation resources.
* Baseline Full Authentication device certificate format (Format 1):
This is the most commonly issued certificate format. Format 1
certificates include a unique Device ID and device EC-DSA
public/private key pair generated by the DTLA. (See Section 4.3
of [DTCP])
* Extended Full Authentication device certificate format (Format 2):
This is issued to devices that possess additional functions
(e.g., additional channel ciphers, specific device properties).
The presence of these additional functions is indicated by the
device capability mask as specified in Section 4.2.3.2 of the
DTCP specification [DTCP]. Format 2 certificates also include a
unique Device ID and device EC-DSA public/private key pair
generated by the DTLA. (See Section 4.3 of [DTCP])
The mechanism specified in this document allows only Format 1 and
Format 2 DTCP certificates to be exchanged in the supplemental data
message since it requires the use of the EC-DSA private key
associated with the certificate.
2.2. Overview of Supplemental Data handshake
Figure 1 illustrates the exchange of SupplementalData message during
the TLS handshake as specified in [RFC4680] and is repeated here for
convenience:
Thakore Expires August 6, 2015 [Page 4]
Internet-Draft TLS Auth Using DTCP February 2015
Client Server
ClientHello (with extensions) -------->
ServerHello(with extensions)
SupplementalData*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
SupplementalData*
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates optional or situation-dependent messages that are
not always sent.
[] Indicates that ChangeCipherSpec is an independent TLS
protocol content type; it is not a TLS handshake message.
TLS handshake message exchange with Supplemental Data
Figure 1
2.3. Overview of authorization extensions
[RFC5878] defines two authorization extension types that are used in
the ClientHello and ServerHello messages and are repeated below for
convenience:
enum {
client_authz(7), server_authz(8), (65535)
} ExtensionType;
A client uses the client_authz and server_authz extensions in the
ClientHello message to indicate that it will send client
Thakore Expires August 6, 2015 [Page 5]
Internet-Draft TLS Auth Using DTCP February 2015
authorization data and receive server authorization data respectively
in the SupplementalData messages. A server uses the extensions in a
similar manner in its ServerHello message. [RFC5878] also
establishes a registry that is maintained by IANA for registering
authorization data formats. This document defines a new
authorization data type for both the client_authz and server_authz
extensions and allows the client and server to exchange DTCP
certificates in the SupplementalData message.
2.4. Overview of supplemental data usage for authorization
Section 3 of [RFC5878] specifies the syntax of the supplemental data
message when carrying the authz_data message that is negotiated in
the client_authz and/or server_authz types. This document defines a
new authorization data format that is used in the authz_data message
when sending DTCP Authorization data.
3. DTCP Authorization Data Format
3.1. DTCP Authorization Type
The DTCP Authorization type definition in the TLS Authorization Data
Formats registry is:
dtcp_authorization(TBA);
Note to RFC Editor: Please populate the number assigned by IANA
3.2. DTCP Authorization Data
The DTCP Authorization data is used when the AuthzDataFormat type is
dtcp_authorization. The syntax of the authorization data is:
Thakore Expires August 6, 2015 [Page 6]
Internet-Draft TLS Auth Using DTCP February 2015
struct {
opaque random_bytes[32];
} RandomNonce;
struct {
opaque RandomNonce nonce;
opaque DTCPCert<0..2^24-1>;
opaque ASN.1Cert<0..2^24-1>;
opaque signature<0..2^16-1>;
} dtcp_authz_data;
RandomNonce is generated by the server and consists of 32 bytes
generated by a high quality secure random number generator. The
client always sends back the server generated RandomNonce in its
dtcp_authz_data structure. The RandomNonce helps the server in
detecting replay attacks. A client can detect replay attacks by
associating the ASN.1 Certificate in the dtcp_authz_data structure
with the certificate received in the Certificate message of the TLS
handshake so a separate nonce for the client is not required.
DTCPCert is the sender's DTCP certificate, see Section 4.2.3.1 of the
DTCP Specification [DTCP]
ASN.1Cert is the sender's certificate used to establish the TLS
session, i.e. sent in the Certificate or ClientCertificate message
using the Certificate structure defined in Section 7.4.2 of
[RFC5246].
The DTCPCert and ASN.1Cert are variable length vectors as specified
in Section 4.3 of [RFC5246]. Hence the actual length precedes the
vector's contents in the byte stream. If the ASN.1Cert is not being
sent, the ASN.1Cert_length MUST be zero.
dtcp_authz_data - contains the RandomNonce, DTCP Certificate and the
optional ASN.1 Certificate. This is then followed by the digital
signature covering the RandomNonce, DTCP Certificate and the ASN.1
certificate (if present). The signature is generated using the
private key associated with the DTCP certificate using the Signature
Algorithm and Hash Algorithm as specified in Section 4.4 of [DTCP].
This signature provides proof of the possession of the private key by
the sender. A sender sending its own DTCP Certificate MUST populate
this field. The length of the signature field is determined by the
Signature Algorithm and Hash Algorithm as specified in Section 4.4 of
[DTCP] and so it is not explicitly encoded in the dtcp_authz_data
structure (e.g. The length will be 40 bytes for SHA1+ECDSA algorithm
combination).
Thakore Expires August 6, 2015 [Page 7]
Internet-Draft TLS Auth Using DTCP February 2015
3.3. Usage rules for clients to exchange DTCP Authorization data
A client includes both the client_authz and server_authz extensions
in the extended client hello message when indicating its desire to
exchange DTCP authorization data with the server. Additionally, the
client includes the AuthzDataFormat type specified in Section 3.1 in
the extension_data field to specify the format of the authorization
data.
A client will receive the server's dtcp_authz_data before it sends
its own dtcp_authz_data. When sending its own dtcp_authz_data
message, the client includes the same RandomNonce that it receives in
the server's dtcp_authz_data message. Clients MUST include its DTCP
Certificate in the dtcp_authz_data message. Clients MAY include its
ASN.1 Certificate (certificate in the ClientCertificate message) in
the ASN.1Cert field of the dtcp_authz_data to cryptographically tie
the dtcp_authz_data with its ASN.1Cert being used to establish the
TLS session (i.e. sent in the ClientCertificate message).
3.4. Usage rules for servers to exchange DTCP Authorization data
A server responds with both the client_authz and server_authz
extensions in the extended server hello message when indicating its
desire to exchange dtcp_authorization data with the client.
Additionally, the server includes the AuthzDataFormat type specified
in Section 3.1 in the extension_data field to specify the format of
the dtcp_authorization data. A client may or may not include an
ASN.1 Cerificate during the TLS handshake. However, the server will
not know that at the time of sending the SupplementalData message.
Hence a server MUST generate and populate the RandomNonce in the
dtcp_authz_data message. If the client's hello message does not
contain both the client_authz and server_authz extensions with
dtcp_authorization type, the server MUST NOT include support for
dtcp_authorization data in its hello message. A server MAY include
its DTCP Certificate in the dtcp_authz_data message. If the server
does not send a DTCP Certificate, it will send only the RandomNonce
in its dtcp_authz_data message. If the server includes its DTCP
Certificate, it MUST also include its server certificate (sent in the
TLS Certificate message) in the certs field to cryptographically tie
its dtcp_authz_data with the ASN.1 Certificate used in the TLS
session being established. This also helps the client in detecting
replay attacks.
3.5. TLS message exchange with dtcp_authz_data
Based on the usage rules in the sections above, Figure 2 (Figure 2)
below provides one possible TLS message exchange where the client
Thakore Expires August 6, 2015 [Page 8]
Internet-Draft TLS Auth Using DTCP February 2015
sends its DTCP Certificate to the server within the dtcp_authz_data
message.
Client Server
ClientHello (with extensions) -------->
ServerHello(with extensions)
SupplementalData(with Nonce N1)
Certificate
ServerKeyExchange*
CertificateRequest
<-------- ServerHelloDone
SupplementalData(with Data D1)
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
N1 Random nonce generated by server
D1 Contains dtcp_authz_data populated with the following
{(N1, DTCP Cert, Client X.509 Cert) Signature over all elements}
* Indicates optional or situation-dependent messages that are
not always sent.
[] Indicates that ChangeCipherSpec is an independent TLS
protocol content type; it is not a TLS handshake message.
Figure 2
3.6. Alert Messages
This document reuses TLS Alert messages for any errors that arise
during authorization processing, and reuses the AlertLevels as
specified in [RFC5878]. Additionally the following AlertDescription
values are used to report errors in dtcp_authorization processing:
Thakore Expires August 6, 2015 [Page 9]
Internet-Draft TLS Auth Using DTCP February 2015
unsupported_extension:
During processing of dtcp_authorization, a client uses this
when it receives a server hello message that includes support
for dtcp_authorization in only one of client_authz or
server_authz but not in both the extensions.
This message is always fatal.
Note: Completely omitting the dtcp_authorization extension
and/or omitting the client_authz and server_authz completely
is allowed and should not constitute the reason that this
alert is sent.
certificate_unknown:
During processing of dtcp_authorization, a client or server
uses this when it has received an X.509 certificate in the
dtcp_authorization data and that X.509 certificate does
not match the certificate sent in the corresponding
ClientCertificate or Certificate message.
4. IANA Considerations
This document proposes a new entry to be registered in the IANA-
maintained TLS Authorization Data Formats registry for
dtcp_authorization(TBA). This registry is defined in [RFC5878] and
defines two ranges: one is IETF review and the other is specification
required. The value for dtcp_authorization should be assigned via
[RFC5226] Specification Required. The extension defined in this
document is compatible with DTLS [RFC6347] and the registry
assignment should be marked "Y" for DTLS-OK.
Note to RFC Editor: Please populate the number assigned by IANA in
TBA above.
5. Security Considerations
The dtcp_authorization data as specified in this document carries the
DTCP Certificate that identifies the associated device. Inclusion of
the X.509 Certificate being used to establish a TLS Session in the
dtcp_authorization data allows an application to cryptographically
tie them. However a TLS Client is not required to (and may not
possess) an X.509 Certificate. In this case, the dtcp_authorization
data exchange is prone to a man-in-the-middle attack. In such
situations, a TLS server MUST deny access to the application features
dependent on the DTCP Certificate or use a double handshake. The
double handshake mechanism is also vulnerable to the TLS MITM
Renegotiation exploit as explained in [RFC5746]. In order to address
this vulnerability, clients and servers MUST use the
Thakore Expires August 6, 2015 [Page 10]
Internet-Draft TLS Auth Using DTCP February 2015
secure_renegotiation extension as specified in [RFC5746] when
exchanging dtcp_authorization data. Additionally, the renegotiation
is also vulnerable to the Triple Handshake exploit. To mitigate
this, servers MUST use the same ASN.1 certificate during
renegotiation as the one used in the initial handshake.
It should be noted that for double handshake to succeed, any
extension (e.g., TLS Session Ticket [RFC5077]) that results in the
TLS Handshake sequence being modified may result in failure to
exchange SupplementalData.
Additionally the security considerations specified in [RFC5878] and
[RFC5246] apply to the extension specified in this document. In
addition, the dtcp_authorization data may be carried along with other
supplemental data or some other authorization data and that
information may require additional protection. Finally, implementers
should also reference [DTCP] and [DTCP-IP] for more information
regarding DTCP certificates, their usage and associated security
considerations.
6. Acknowledgements
The author wishes to thank Mark Brown, Sean Turner, Sumanth
Channabasappa; and the Chairs (EKR, Joe Saloway) and members of the
TLS Working Group who provided feedback and comments on one or more
revisions of this document.
This document derives its structure and much of its content from
[RFC4680], [RFC5878] and [RFC6042].
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999,
<http://tools.ietf.org/html/rfc2246>.
[RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.1", RFC 4346, April 2006,
<http://tools.ietf.org/html/rfc4346>.
[RFC5246] Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.2", RFC 5246, August 2008,
<http://tools.ietf.org/html/rfc5246>.
Thakore Expires August 6, 2015 [Page 11]
Internet-Draft TLS Auth Using DTCP February 2015
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, February 2010,
<http://tools.ietf.org/html/rfc5746>.
[RFC4680] Santesson, S., "TLS Handshake Message for Supplemental
Data", September 2006,
<http://tools.ietf.org/html/rfc4680>.
[RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS)
Authorization Extensions", RFC 5878, May 2010,
<http://tools.ietf.org/html/rfc5878>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, Jan 2012,
<http://tools.ietf.org/html/rfc6347>.
[DTCP] Digital Transmission Licensing Administrator, "Digital
Transmission Content Protection",
<http://www.dtcp.com/documents/dtcp/
info-20130605-dtcp-v1-rev-1-7-ed2.pdf>.
[DTCP-IP] Digital Transmission Licensing Administrator, "DTCP Volume
1 Supplement E", <http://www.dtcp.com/documents/dtcp/
info-20130605-dtcp-v1se-ip-rev-1-4-ed3.pdf>.
7.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[DTLA] Digital Transmission Licensing Administrator, "DTLA",
<http://www.dtcp.com>.
[RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000,
<http://tools.ietf.org/html/rfc2818>.
[RFC5077] Salowey, J. and P. Eronen, "Transport Layer Security (TLS)
Session Resumption without Server-Side State", RFC 5077,
January 2008, <http://tools.ietf.org/html/rfc5077>.
Thakore Expires August 6, 2015 [Page 12]
Internet-Draft TLS Auth Using DTCP February 2015
[RFC6042] Keromytis, A., "Transport Layer Security (TLS)
Authorization Using KeyNote", RFC 6042, October 2010,
<http://tools.ietf.org/html/rfc6042>.
Appendix A. Additional Stuff
This document specifies a TLS authorization data extension that
allows TLS clients and servers to exchange DTCP certificates during a
TLS handshake exchange. In cases where the supplemental data
contains sensitive information, the double handshake technique
described in [RFC4680] can be used to provide protection for the
supplemental data information. The double handshake specified in
[RFC4680] assumes that the client knows the context of the TLS
session that is being set up and uses the authorization extensions as
needed. Figure 3 illustrates a variation of the double handshake
that addresses the case where the client may not have a priori
knowledge that it will be communicating with a server capable of
exchanging dtcp_authz_data (typical for https connections; see
[RFC2818]). In Figure 3 (Figure 3), the client's Hello messages
includes the client_authz and server_authz extensions. The server
simply establishes an encrypted TLS session with the client in the
first handshake by not indicating support for any authz extensions.
The server initiates a second handshake by sending a HelloRequest.
The second handshake will include server's support for authz
extensions which will result in SupplementalData being exchanged.
Alternately, it is also possible to do a double handshake where the
server sends the authorization extensions during both the first and
the second handshake. Depending on the information received in the
first handshake, the server can decide if a second handshake is
needed or not.
Thakore Expires August 6, 2015 [Page 13]
Internet-Draft TLS Auth Using DTCP February 2015
Double Handshake to protect Supplemental Data
Client Server
ClientHello (w/ extensions) --------> |0
ServerHello (no authz extensions) |0
Certificate* |0
ServerKeyExchange* |0
CertificateRequest* |0
<-------- ServerHelloDone |0
Certificate* |0
ClientKeyExchange |0
CertificateVerify* |0
[ChangeCipherSpec] |0
Finished --------> |1
[ChangeCipherSpec] |0
<-------- Finished |1
<-------- HelloRequest |1
ClientHello (w/ extensions) --------> |1
ServerHello (w/ extensions) |1
SupplementalData* |1
Certificate* |1
ServerKeyExchange* |1
CertificateRequest* |1
<-------- ServerHelloDone |1
SupplementalData* |1
Certificate* |1
ClientKeyExchange |1
CertificateVerify* |1
[ChangeCipherSpec] |1
Finished --------> |2
[ChangeCipherSpec] |1
<-------- Finished |2
Application Data <-------> Application Data |2
* Indicates optional or situation-dependent messages.
Figure 3
Thakore Expires August 6, 2015 [Page 14]
Internet-Draft TLS Auth Using DTCP February 2015
Author's Address
D. Thakore
Cable Television Laboratories, Inc.
858 Coal Creek Circle
Louisville, CO 80023
USA
Email: d.thakore@cablelabs.com
Thakore Expires August 6, 2015 [Page 15]
