Re: use case: CA acceptance (ACTION-74)

This one didn't make it to the list...
-- 
Thomas Roessler, W3C  <tlr@w3.org>





On 2007-01-23 17:44:19 +0000, Dan Schutzer wrote:
> From: Dan Schutzer <dan.schutzer@fstc.org>
> To: public-wsc-wg-request@w3.org,
> 	'Mary Ellen Zurko' <Mary_Ellen_Zurko@notesdev.ibm.com>
> Cc: 'Dan Schutzer' <dan.schutzer@fstc.org>, 'Bob' <rubell@stevens.edu>,
> 	'Chuck Wade' <Chuck@Interisle.net>, chris.nautiyal@fstc.org,
> 	maritzaj@cs.columbia.edu
> Date: Tue, 23 Jan 2007 17:44:19 +0000
> Subject: RE: use case: CA acceptance (ACTION-74)
> X-Spam-Level: 
> Old-Date: Tue, 23 Jan 2007 12:43:22 -0500
> X-Diagnostic: Already on the subscriber list
> X-Diagnostic:   8 chris.nautiyal@fstc.org            32752 chris.nautiyal@fstc.org
> 
> Hi Mary Ellen,
> 
>  
> 
> I have rewritten my use case. There are now two use cases and supporting
> recommendations
> 
>  
> 
> Best Regards
> 
> Dan Schutzer
> 
>  
> 
> ----------------------------
> 
> Use Cases: 
> 
>  
> 
> Use case 1: Alice sees an advertisement from a bank regarding opening an
> account online and getting a very favorable interest rate. Alice has heard
> of the bank and goes on line to open the account. However, when she gets to
> the bank's website, she learns that to open the account, she has to provide
> sensitive personal information. Alice wants assurance about the website
> before providing this information.
> 
>  
> 
> Use Case 2: Alice has repeatedly visited her bank's web site. Every time she
> visits our bank's website she wants to be reassured that she is actually at
> the bank's website and not a spoofed website. She wants that reassurance to
> be accurate every time; never telling her it's not her bank when it is, nor
> telling her a web site that does not belong to her bank is from her bank.
> And Alice wants this reassurance even when she is using different machines
> in different locations (e.g. her laptop in a hotel room). Alice is
> particularly worried about attacks that have occurred and are on the news
> and her friends talk about (though she doesn't always understand what they
> are).
> 
>  
> 
> These use cases are getting at the concern a user has when everything
> appears valid on the screen they see, but they are not completely
> comfortable. In other words, they want to take some concrete step to get
> assurances that they're not being fooled. Even when technology "gets it
> right," the user should still be given the option of asking for confirmation
> in a way that is meaningful to a human being. And the confirmation should
> not make matters worse by (e.g. the confirmation or warning should not be
> spoofable).
> 
>  
> 
> Recommendation:
> 
>  
> 
> There is a class of web services that users are particularly anxious about
> interacting with in regard to safety. Users aren't particularly concerned
> when they visit many sites (such as Wikepedia, Google, Entertainment, and
> information sites such as electronic newspapers) because these involve their
> consuming information with little risk of their losing sensitive personal
> information or important credentials that permit access to important
> resources and assets. But some sites, such as banking sites (this is not
> restricted to banking however), to whom the user trusts to safeguard
> important resources and assets, and who permits access via the web, does
> provide anxiety to user. They are afraid that if are tricked into providing
> sensitive information to sites that are spoofs of the actual bank site, the
> information collected could be used by the criminal to commit fraud (e.g.
> take-over their account, assume your identity). 
> 
>  
> 
> Web Service Providers, such as banking web sites, are motivated to take the
> necessary extra steps to help the browser and service providers
> unambiguously distinguish between their web pages and an imposter site. This
> could be accomplished by a combination of things, some outside the domain of
> the browser: 
> 
>  
> 
> *	The website is signed by a special class of certificates with
> extended validation. 
> *	The web page has attributes that are consistent and kept constant;
> e.g. known IP addresses that are registered with that URL, 
> *	Contextual clues - images and information known only to user and the
> real web service provider
> *	Strong mutual challenge/response protocol; e.g. making use of client
> and server certificates
> *	Use of out of channel signals (e.g. ask for a security code provided
> via an email or voicemail
> 
>  
> 
> If the browser checks for a combination of this confirming information, we
> need indicators that can:
> 1. Communicate to Alice that the site is valid, where that communication
> cannot be forged by a spoofed site, or ignored in their absence (this
> includes preventing invalid pop-ups)
> 
> 2. Communicate to Alice when the site is not valid in a way that is not
> ignored and cannot be covered up
> 3. Have close to zero error in this communication (very little to no
> instances where the browser is communicating false rejects or false accepts)
> to prevent chicken little effect where user gets blocked or warned against
> going to a real bank site, or where user gets assured it is the real bank
> site when it is not.
> 4. Have this scheme still work against credible spoofing attacks (e.g.
> man-in-the-middle, false links embedded in phishing emails,
> picture-in-picture attacks)
> 
> Below are examples of solutions that might be considered for each of the two
> use cases.
> 
> First Use Case Recommendations
> 
> 
> 
> For the first use case, if the website is signed with an EV certificate, the
> browser can verify that a website is using an EV certificate, and can
> unambiguously display the name of the website (contained in the EV cert, and
> presumably verified to a rigorous degree by the certificate issuing
> procedure). This might even include a special type logo (e.g. Bank type
> logo).  This case would correspond to a situation where there is no prior
> trusted relationship between the user and the website, but where the user
> wants assurance about the website before providing sensitive information.
> It is not perfect, but if done correctly, along with other out-of-channel
> checks and balances, it should suffice.
> 
> So let's say you open your browser and are viewing XYZ Bank's webpage.  No
> sensitive information is requested on this page, so you might be in ordinary
> browsing mode.  Now you click a link that takes you to another page for
> opening a new account.  Your browser senses the EV cert, and opens this page
> under the Safe Browsing tab.  The name of the bank is clearly displayed.
> The user verifies that he/she is in Safe Browsing Mode by noting the colored
> or marked tab, and verifies the name of the bank.   The user then provides
> personal information for opening a new account.  [If the bank chooses, every
> page on its website could be associated with an EV cert, so the user could
> only access the bank's site in Safe Browsing Mode.]
> 
> Second Use Case Recommendations
> 
> The second use case corresponds to a situation where there exists a prior
> trusted relationship between the user and the website.  Here we need strong
> mutual authentication to take place between your computer and the website,
> so that both sides have assurance of who the other is.   This would be the
> case where the FI website uses an EV cert, and where there is also a
> client-side certificate and private key on the user's side (possibly on the
> computer's HD or TPM or USB token). An effective approach would be to have
> an easy way to allow the user put the browser in a Safe mode (Trusted path)
> where only certain classes of websites, and/or user-specified sites that can
> pass strong mutual authentication protocol, or other such tests, can be
> viewed. This can be tested by the user, by attempting to access a web site
> that is not on the trusted list when in the trusted mode. An example would
> be a user accessing a bank's webpage only after placing the browser in a
> Safe Browsing Mode that allows existing banking customers to access their
> accounts.  If there is a client-side certificate and private key on the
> user's side, mutual authentication between the bank website and the user's
> computer can take place.  If the mutual authentication fails, the web page
> will not be displayed. I would envision that browsers could be redesigned so
> that when a user initially opens the browser, two tabs are opened by
> default.  One tab would be for ordinary browsing, and this is where the user
> would be when the browser first opens.  A second tab, with some special tab
> color or indicator, would be the Safe Browsing Tab. In the Safe Browsing
> Tab, only webpages that conform to the Safe Browsing criteria would be
> viewable.   
> 
> If you already have an account at the bank, and have a client-side
> certificate, you might again be initially accessing the bank website in
> ordinary browsing mode, but when you click on a link for accessing your
> account, a new webpage would be opened under the Safe Browsing tab.  You now
> put in your User ID, and the bank realizes that your computer should have a
> client-side cert for mutual authentication.  If the bank's site can now
> authenticate your computer via the cert, you are now prompted for your
> password.  You recognize that you are in Safe Mode because of the special
> tab, and recognize the bank's name, so you provide the password. Or, maybe
> you have bookmarked the webpage where account access takes place.  That
> bookmark would automatically open this account access page under the Safe
> Browsing tab. One can always check that they are in the safe browsing mode,
> by testing to see if they can access a page that is has not been specially
> designated and authenticated.
> 
> If there is a client-side certificate/private key residing on Alice's
> computer HD or TPM for mutual authentication, but if Alice is going to be
> using a different computer at an internet cafe, there will be a problem.
> But that's the same problem you have even if you're not using a client-side
> cert, but are using the HD "signature" as the SYH authentication factor, as
> in the Passmark case.  Alice would then need to answer challenge questions,
> or authenticate via an out-of-band phone call.  If client-side certs and
> private keys are used in the mutual authentication process, the most
> portable solution would seem to be if Alice carries around a USB token on
> her keychain with the cert/private key.   If Alice wants to use the Safe
> Browsing Mode even at an Internet cafe, one approach is for Alice's USB
> token to also implement a properly-configured browser, in addition to the
> client-side cert.   One incentive for having banking customers carry around
> USB tokens for these purposes might be if the token also stored every
> password that's needed by Alice for all her financial transactions over the
> web.  The advantage to Alice would be that by carrying around such a token,
> she would not only have better security, but wouldn't have to keep track of
> all these other passwords.  She would only have to remember one password,
> the password that unlocks the token.  
> 
> Another approach would involve including a solution that combines the "under
> the covers" OCSP verification with the "click here to check this site"
> badge. The latter is easier for the user to understand and relate to, but is
> vulnerable since it depends on the web page to provide the appropriate
> hooks/links. The former may be effective, but it doesn't address the
> concerns that a person might have that they could be fooled regarding what
> is displayed. However, if a browser provided a button contained within the
> chrome to check the validity of the web site that is currently displayed
> (i.e., the url in the location bar), then third party validation would be
> less vulnerable, and it would become a more consistent option for users to
> invoke. IE7 already has such an option, but it is contained within special
> web pages that get displayed when a user attempts to visit a questionable
> site. 
> 
>   _____  
> 
> From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On
> Behalf Of Mary Ellen Zurko
> Sent: Wednesday, January 17, 2007 5:52 PM
> To: dan.schutzer@fstc.org
> Cc: 'WSC WG'
> Subject: RE: use case: CA acceptance (ACTION-74)
> 
>  
> 
> 
> Hi Dan,
> 
> This seems like a hybrid between a use case and a proposed recommendation.
> The use case would be:
> 
> Alice has repeatedly visited her bank's web site. Everytime she visits our
> bank's website she wants to be reassured that she is actually at the bank's
> website and not a spoofed website. And she wants that reassurance to be
> accurate every time; neither telling her it's not her bank, nor telling her
> a web site that does not belong to her bank is her bank. She is particularly
> worried about attacks that have occured and are on the news and her friends
> talk about (though she doesn't always understand what they are). 
> 
> The rest of your mail would be the core of a proposed recommendation. 
> 
> If you agree, you could write up both the use case (for the Note) and draft
> a proposed recommendation (since we'll start discussing our recommendations
> in less than two weeks). 
> 
>           Mez
> 
>  
> 
>  
>

Received on Tuesday, 23 January 2007 19:46:26 UTC