Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08

Brian Campbell <bcampbell@pingidentity.com> Sun, 16 July 2017 17:46 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED934124C27 for <oauth@ietfa.amsl.com>; Sun, 16 Jul 2017 10:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE74JjQV0YVj for <oauth@ietfa.amsl.com>; Sun, 16 Jul 2017 10:46:39 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5F3120724 for <oauth@ietf.org>; Sun, 16 Jul 2017 10:46:39 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id e199so5146382pfh.2 for <oauth@ietf.org>; Sun, 16 Jul 2017 10:46:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uwK1iOKjT3taNnXT5TVdX3oMe2J5wBe0uW2lJewxzUw=; b=PrBv30KJgZZGUu7Nw6CRd8KOEFHFMS/80bo/CFjnYy9Id4OvT2SDNBcOh4PIu19bu6 +fiCRsHi5NiCp7Nadaa+uS+ZMFa+yexAinoFdlB08axJ6YbE5uBEz01w0IVhQ/Xqrwq/ y724VYdRUtlEIZtlSgC+302v52VLN01OHtolg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uwK1iOKjT3taNnXT5TVdX3oMe2J5wBe0uW2lJewxzUw=; b=ZETKD6zOuZLsITydSeZmrmS3Ls1dx5hNsEmjoehAnuYhDMXJjKRUn3fDZHmW/A8Kuw qrpf+XmuzMI0EBpHMlAYhEre4/FnlLdIFtVDGuxy9leIjXDSrlmuQL1sVNr3N/DJh+qx 05a9p7FZxo0UlaO4ap0hw+ct3sm1ZIPwc6npefzAVUyOUp3vKe307C2sYDAz9HFfdEGf 5x2uzOYegpO1JKYM0qMrOVsLIvuTCLEiyeu2YprnKSA03pTouLy8GCqeGGVD/fYvFJVl 0Kd+NUwMdJSZXMs37UqxKVAESpnhZyz9PjtH7C6brItSs8r+iNOkN5FYhSJBa62qvQth Xepg==
X-Gm-Message-State: AIVw112huIm8SijmlVSTM/75SccVfWTfavu+XikMTpSdWmzQGr3SC5zi eJPefy8qPp4jkeZoRYt+/DWdngUCflkQazMzRbcWOpLNMhLqgDbPqUKUjYvr+aUDw5qwOZT9ovs ASQVM
X-Received: by 10.99.101.132 with SMTP id z126mr24781694pgb.64.1500227198892; Sun, 16 Jul 2017 10:46:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Sun, 16 Jul 2017 10:46:08 -0700 (PDT)
In-Reply-To: <109f3b1d-c346-d294-fe6e-519c18223a7d@free.fr>
References: <CAGL6ep+nx=XmHOJpKHhY6WnhWpAXF4krhQhGy2TBDTKFbyVfag@mail.gmail.com> <858f5a6a-f68c-c616-487a-a64cd8278755@free.fr> <CA+k3eCTbbVQM4NeMny2+9PQqCL6mgXhkmpQa0nxsdBXXrxDsOw@mail.gmail.com> <109f3b1d-c346-d294-fe6e-519c18223a7d@free.fr>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Sun, 16 Jul 2017 11:46:08 -0600
Message-ID: <CA+k3eCTr2gDFQeoDzpY4yFOMLS+Gw0-3VS_df+3Wm4unCt5eeg@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1171e845db01055472dd81"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bAnzsXBnd0Mn2kiw1bmhsAWJ4JE>
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Jul 2017 17:46:44 -0000

Speaking as an individual, for a number of reasons, I do not believe that
any of the additional comments or suggestions should be incorporated into
the document.

As a document editor working within the IETF processes, my aim is for the
document to reflect the (rough) consensus of this Working Group. And I
don't get the sense that there's support, let alone consensus, for any of
these changes. However, rather than relying on my interpretation of support
or lack thereof from the WG, I'll ask more explicitly - are there other WG
remembers who are in favor of working to incorporate any of these comments
or suggestions?

On Sun, Jul 16, 2017 at 8:38 AM, Denis <denis.ietf@free.fr> wrote:

> Hello Brian,
>
> It took 25 days to get a response to my WGLC comments and it took me 13
> days to answer to your reply.
>
> My responses are embedded in the text. At present, I only agree with the
> resolution of the comment numbered 6.
>
> Thanks for the review, Denis. And I apologize for the slow reply - I've
> had a lot of different things on my plate recently. And, quite frankly, I
> was sort of hoping one of the co-authors on the document might respond to
> your comments. But hope only goes so far. So replies are inline below...
>
> On Mon, Jun 5, 2017 at 5:30 AM, Denis <denis.ietf@free.fr> wrote:
>
>> Comments on OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-08
>>
>> 1. The abstract states:
>>
>>    "This specification defines a protocol for an HTTP- and JSON- based
>>    Security Token Service (STS) by defining how to request and obtain
>>    security tokens from OAuth 2.0 authorization servers, including
>>    security tokens employing impersonation and delegation".
>>
>> The problem is that the content of the abstract does not match with the
>> content of the document.
>>
>> The abstract clearly states that all cases of token requests are
>> supported, whereas the document mandates
>> the use of a subject_token parameter which restricts the scope to
>> impersonation and delegation.
>>
>> Currently the text states:
>>
>>    "subject_token
>>       *REQUIRED*.  A security token that represents the identity of the
>>       party on behalf of whom the request is being made.  Typically, the
>>       subject of this token will be the subject of the security token
>>       issued in response to this request".
>>
>> The abstract should be changed to reflect the content of the document.
>>
>
> I don't see a discrepancy between the content of the abstract and the
> content of the document.
>
> What text or changes would you suggest in the abstract?
>
>
> "This specification defines a protocol for an HTTP- and JSON- based
> Security Token Service (STS) by defining how to request and obtain
> security tokens from OAuth 2.0 authorization servers when a specific
> parameter
> is required to identify the party on behalf of whom the request is being
> made".
>
> However, please read the other comments, since I am not sure that this
> change will be sufficient.
>
>
>> 2. The text states on page 4:
>>
>>    "The scope of this specification is limited to the definition of a
>>    basic request and response protocol for an STS-style token exchange
>>    utilizing OAuth 2.0.  Although a few new JWT claims are defined that
>>    enable delegation semantics to be expressed, the specific syntax,
>>    semantics and security characteristics of the tokens themselves (both
>>    those presented to the AS and those obtained by the client) are
>>    explicitly out of scope and no requirements are placed on the trust
>>    model in which an implementation might be deployed".
>>
>> These statements are contradictory. One parameter of the request is
>> mandatory (i.e. subject_token)
>> but there is no indication of the kind of treatment which should be done
>> with this parameter so that
>> it will be taken into consideration one way or another in the token that
>> will be issued.
>>
>> This document by itself would be insufficient to allow any kind of
>> interoperability.
>> Conformance to this document would not mean anything.
>>
>
> The token exchange framework promotes interoperability in the form of
> common patterns and parameters that can be supported in libraries,
> products, and services. It facilitates deployments like this one
> https://help.salesforce.com/articleView?id=remoteaccess_oaut
> h_asset_token_flow.htm or this one https://developer.box.com/docs
> /getting-started-with-new-box-view, for example.
>
>
> This is not an adequate response to my comment. Text is currently missing
> to explain
> what kind of treatment should be done with this parameter.
>
>  What should the STS do with this parameter when it receives it ?
>
>  How, this parameter should be processed so that it can be placed in a
> security token ?
>
>  Is there a relationship (if any) between the "subject_token" and the
> "cid" (Client Identifier)
>  that will be placed in the security token ?
>
>  Why shall a security_token be used instead of simply an identifier of the
> OAuth 2.0 client
>  that requested the token ?
>
>  The current draft cannot be understood.
>
>
>>
>> 3. On page 7, the text states:
>>
>>    "subject_token
>>       REQUIRED.  A security token that represents the identity of the
>>       party on behalf of whom the request is being made".
>>
>> It is understood that one implementation is already using this parameter
>> to place in it a security token.
>> Since this parameter is indicated as REQUIRED, it is not understandable
>> why a security token shall necessarily be used.
>> There are other means for the STS to identify the "party on behalf of
>> whom the request is being made".
>>
>> Please add a rational.
>>
>
> I don't understand what kind of rational you are looking for here. Can you
> suggest some specific text for the document that would address the concern
> you have?
>
>
> In order to identify "the party on behalf of whom the request is being
> made", there is no need to use a security token.
> The text does not explain the benefits, if any, of using a security token.
>
> It does not explain either the drawbacks, i.e. the complexity for using
> it, in particular, how a relying party can verify
> that the security token is protected by the right key.
>
> What kind of trust relationships would need to be pre-established is not
> explained.
>
> I believe that using a security token to represent the identity of the
> party on behalf of whom the request is being made
> adds an extra level of complexity and for that reason a security token
> should NOT be used.
>
> If you believe that it should, then you have to explain the trust
> relationships, the benefits and the way to handle this parameter
> as it is currently not the case.
>
>
>> In addition, what the STS will do, can do or should do with this
>> parameter is left undefined.
>>
>>
>> 4. On page 7, the text states:
>>
>>    "subject_token
>>       REQUIRED.  (...)  Typically, the subject of this token will be
>>       the subject of the security token issued in response to this
>>       request".
>>
>> This sentence is quite hard to understand since the specific syntax,
>> semantics and security characteristics of the tokens themselves
>> are explicitly out of scope. The key point is what the STS should do with
>> this parameter: this is left undefined.
>>
>
> I don't view the sentence as difficult to understand.  Maybe that's
> because I wrote it?  But it is true that typically it is the case that the
> subject of the inbound token will be the subject of the issued token. I
> don't know how else to say it. Please offer suggested text, if you believe
> there's a way to say it that is easier to understand.
>
>
> Could we defined this parameter in the following way ?
>
> subject_token
>       REQUIRED.  An identifier of the party on behalf of whom the request
> is being made (...)
>                             This identifier will be copied and pasted into
> the security token issued in response to this request
>                             to designate the claimed holder of the issued
> security token designated as the "cid" (Client Identifier) claim in RFC
> 6749.
>
>
>> 5. The text states:
>>
>>    " (...) Additional
>>    profiles may provide more detailed requirements around the specific
>>    nature of the parties and trust involved, such as whether signing
>>    and/or encryption of tokens is needed or if proof-of-possession style
>>    tokens will be required or issued;
>>
>> Tokens are always signed. Please modify the sentence accordingly.
>>
>
> A token might well be cryptographically secure random sequence of
> characters that reference data that can be looked up by the appropriate
> parties. Or a token might be an AEAD symmetrically encrypted JWT. So no,
> tokens are not always signed.
>
>
> Could we rephrase in the following way?
>    " (...) Additional profiles may provide more detailed requirements
> around the specific nature of the parties and trust involved,
>      such as how integrity protection of the tokens shall be done and if
> proof-of-possession style tokens will be required or issued;
>
>
>
>
>>
>>
>> 6. The following sentence is important and is being noticed.
>>
>>    The security tokens obtained could be used in a number of contexts,
>>    the specifics of which are also beyond the scope of this
>>    specification.
>>
>> Changing the "could" into a "may" would however be more appropriate.
>>
>
> Agreed, I'll make that change.
>
>
> Thanks.
>
>
>
>>
>>
>> 7. In section  2.1 request, the text defines:
>>
>>    resource
>>       OPTIONAL.  Indicates the physical location of the target service
>>       or resource where the client intends to use the requested security
>>       token.
>>
>> and
>>
>>    audience
>>       OPTIONAL.  The logical name of the target service where the client
>>       intends to use the requested security token.
>>
>> If the resource or the audience parameter is being used, the STS will
>> have the ability to know exactly which individual
>> or entity has accessed which target service and may keep a log of that
>> activity. It would be in a position to act as Big Brother.
>> This should be clearly indicated in a section that is currently missing :
>> "7. Privacy Considerations". See a text proposal hereafter.
>>
>> However, there is indeed the need to restrict the use of tokens to
>> specific targets. The key point is that the target service
>> must be able to recognize itself that the token is indeed targeted to it.
>> As an example, a challenge may be requested to
>> the target service and that challenge may then be placed into a specific
>> filed of the token. The target service may then verify
>> that the value included in the token is the one that has been recently
>> provided.
>>
>> A parameter specifying the type of the control value and the value of the
>> control should be added.
>> This parameter would be called a target_id (tid). It would solve the Big
>> Brother case.
>>
>
> That is both beyond the scope of this document and potentiality applicable
> to a broader context of use. I'd suggest you write an individual draft for
> the concept, if you want to pursue it.
>
>
>
> This topic has been addressed twice by two presentations on July the 13 th
> at the end of the first day of the OAuth workshop in Zürich.
>
> During this meeting, there have been different proposals to solve the
> issue. I also said that other possibilities were possible.
>
> The fact is that currently no technique has been agreed to solve the issue.
>
> I see two options:
>
> a)     freeze this document and wait until a technique can be agreed
> within the WG and defined in another RFC,
> so that  we can reference it and then after continue the work on this
> document
>
> b)     don't wait, but mention that currently no parameter has been
> defined to address the issue.
>
> My preference would be for option a)
>
> What would be your preference ?
>
> If we take option b), then take a look at a new text proposal for the
> comment numbered 10.
>
>
>>
>> 8. The Security Considerations section states:
>>
>>    "In addition, both delegation and impersonation introduce unique
>>    security issues.  Any time one principal is delegated the rights of
>>    another principal, the potential for abuse is a concern.  The use of
>>    the "scp" claim is suggested to mitigate potential for such abuse, as
>>    it restricts the contexts in which the delegated rights can be
>>    exercised".
>>
>> Section 4.2 defines the "scp" (Scopes) claim in the following way:
>>
>>    The "scp" claim is an array of strings, each of which represents an
>>    OAuth scope granted for the issued security token.  Each array entry
>>    of the claim value is a scope-token, as defined in Section 3.3 of
>>    OAuth 2.0 [RFC6749].
>>
>> Section 3.3 from RFC 6749 defines the Access Token Scope as:
>>
>>    "The authorization and token endpoints allow the client to specify the
>>    scope of the access request using the "scope" request parameter.  In
>>    turn, the authorization server uses the "scope" response parameter to
>>    inform the client of the scope of the access token issued.
>>    The value of the scope parameter is expressed as a list of space-
>>    delimited, case-sensitive strings.  The strings are defined by the
>>    authorization server".
>>
>> Section 5.4.1 Registry Contents defines scp as:
>>
>>    o  Claim Name: "scp"
>>    o  Claim Description: Scope Values
>>    o  Change Controller: IESG
>>    o  Specification Document(s): Section 4.2 of [[ this specification ]]
>>
>> Since the "strings are defined by the authorization servers", what a
>> scope may mean is subject to multiple interpretations.
>> The current definition of scp is insufficient to allow any kind of
>> interoperability, now or in the future.
>>
>> It is thus unclear how the use of the "scp" claim might mitigate the risk.
>>
>
> Scoping the token restricts what the token can be used for which limits
> the impact of a compromised or misused token. The scope values are
> interpreted by the parties involved just as with regular OAuth.
>
> This is not an adequate response to my comment.
>
> You say that "scope values are interpreted by the parties involved just as
> with regular OAuth".
>
> I suggest the following text as a full replacement of the quoted text:
>
> Both delegation and impersonation introduce unique security issues.  The
> potential for abuse is a concern.
> The use of the "scp" claim allows to restrict the contexts in which the
> delegated rights can be exercised.
>
> Strings in the "scp" claim are defined by the authorization servers. If
> the client gets some knowledge
> on how these strings will be handled both by a resource server and by an
> authorization server, then the use
> of the "scp" claim can be used to mitigate potential for such abuse.
> However, at the time of the issuance of this RFC,
> techniques for applying such restrictions are not defined in other RFCs.
>
> In addition, users may collude and one user might be willing to allow
> another user to make use of a security token that it has obtained.
> This is not a concern in the context of a delegation scheme, but may be a
> serious concern in some other contexts. Whatever kind
> of cryptography is being used, there is no way to stop collusion between
> users, unless some secure hardware is required to be used
> by a security token requester in order to obtain a security token. In
> other words, a software-only implementation is unable to prevent
> collusion between users. A hardware solution simply protecting some secret
> key or some private key will also be ineffective, since
> one user would be able to perform all the cryptographic computations that
> the other user needs.
>
> Note: People that were present on July the 13 th on the first day of the
> OAuth workshop in Zürich may understand better what I mean.
> The text and the slides of this workshop should be publicly available
> shortly.
>
>
>
>> 9. This document is currently targeted to become a Standards Track
>> document.
>>
>> RFC 6410 recognizes two maturity levels:
>>
>>    - the First Maturity Level: Proposed Standard
>>    - the Second Maturity Level: Internet Standard
>>
>> It is not believed that currently it is possible to construct two
>> independent interoperating implementations
>> looking at this document only. Unless more guidance is provided, this
>> document should be targeted to "Experimental".
>>
>
> I completely disagree. And would also note that the the document's
> intended status has been stable and unquestioned by this WG for several
> years.
>
>
> Section 2.1 from RFC 6410 states:
>
>    The stated requirements for Proposed Standard are not changed; they
>    remain exactly as specified in RFC 2026 [1].  No new requirements are
>    introduced; no existing published requirements are relaxed.
>
> Section 4.1.1 from RFC 2026 states:
>
>    A Proposed Standard specification is generally stable, has resolved
>    known design choices, is believed to be *well-understood*, has received
>    significant community review, and appears to enjoy enough community
>    interest to be considered valuable.
>
> (...)
>
>    A Proposed Standard should have *no known technical omissions* with
>    respect to the requirements placed upon it.
>
> I don't believe that the current text complies with the previous
> statements.
>
> One of the goals of this document is to define a new parameter called
> "subject_token".
>
> In order to use it, we need to say how the client, the AS and the RP shall
> handle it.
> The current text is insufficient to know how to handle it.
>
> Unless additional information is provided, this document should be
> targeted to "Experimental".
>
>
>>
>> 10. Text proposal for a new section "7. Privacy Considerations".
>>
>>    7. Privacy Considerations
>>
>>    7.1. Resource and audience parameters
>>
>>    The use of any these two parameters allow the STS to know which
>>    target servers are being accessed by any party making a token
>>    request.  Any STS is then able to log token requests.  This is not
>>    a problem if the resource owner and the target server are collocated,
>>    but this document is not restricted to that case.
>>
>>    For the other cases, it should be noticed that the STS will be in
>>    position to act as Big Brother.  When privacy is a concern, the use
>>    of these parameters is deprecated and the use of a "tid" parameter
>>    is recommended.
>>
>>
> I will add a privacy considerations with mention of being able to track
> the target systems intended to be accessed by the party requesting a
> token.
>
>
> The privacy section that has been added is the following:
>
> Privacy Considerations
>
> Tokens typically carry personal information and their usage in Token
> Exchange may reveal details of the target services being accessed.
> As such, tokens should only be requested and sent according to the
> privacy policies at the respective organizations.
>
>
> It does not address my concern. Hereafter is a new text proposal to
> address my concern, ... if we follow option b) as mentioned beforehand.:
>
>    7. Privacy Considerations
>
>    7.1. Resource and audience parameters
>
>    The use of the resource or of the audience parameter allows the STS to
> know which target servers are being accessed
>    by any party making a token request.  Any STS will then be able to log
> token requests. This is not a problem as long as
>    the resource owner and the target server are collocated, but this
> document is not restricted to this case.
>
>    For the other cases, if either the resource parameter or the audience
> parameter is being used, the STS will be in position
>    to act as Big Brother. When privacy is a concern, the use of the
> resource parameter and of the audience parameter is deprecated
>    and another parameter should be used to restrict the target servers
> that can use the security token. At the time of the issuance
>    of this document, such a parameter was not yet defined in another RFC.
>
>
>    7.2. Use of RFC 7662 (OAuth 2.0 Token Introspection)
>
>    RFC7662 defines a protocol that allows authorized protected resources
> to query the authorization server to determine the set of metadata
>    for a given token that was presented to them by an OAuth 2.0 client.
>
>    The use of this protocol raises some privacy concerns, since the STS is
> then able to identify the clients accessing the introspection endpoint.
>    This concern will remain even when the resource parameter or the
> audience parameter will not be used. Such parameters might be in the future
>    replaced by another means to restrict the use of the security tokens to
> specific resource servers, but a call back to the authorization server
> would
>    ruin the benefits of the use of this alternative means.
>
>
> Denis
>
>
>
>>
>>
>>
>>
> Denis
>>
>> All,
>>
>> We are starting a WGLC on the Token Exchange document:
>> https://www.ietf.org/id/draft-ietf-oauth-token-exchange-08
>>
>> Please, review the document and provide feedback on any issues you see
>> with the document.
>>
>> The WGLC will end in two weeks, on June 17, 2017.
>>
>> Regards,
>>  Rifaat and Hannes
>>
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
>
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*