FW: X9.49

ANSI is working on a web authentication standard (X9.49) that W3C should
be aware of.  I thought the following email exchange in the X9F4
committee might be of interest to the WSC group, so I'm forwarding it
with permission:

-----Original Message-----
From: Eric Lengvenis

This is a tricky issue for sure. The problem seems to be that SSL
validation only extends to whether or not the presented certificate
matches the web site. We need to know whether the website is the one we
*ought* to be going to. 

One thing I'd like to see is a database in the browser that would allow
a user to associate a site and certificate pairing. When a user signs up
for online banking, they also enter that site and its certificate into
the database. If something changes in the certificate presented (maybe
it chains to a different CA), the connection is disallowed. Sort of like
what happens when you attempt to SSH into a host and that host's key has
changed.

That stops some things, but the MITM gets by because it is generic
validation of the phishing site not validation against the trusted sites
DB. More browser work could go on that would address this too. For
instance, having icons or other indicators that the site you are
visiting is not in the trusted sites DB. I know that EV Certificates
will have indicators that the site means high criteria. I don't know
enough to know whether or not they adequately address these issues.

Either way, SSL/TLS is a pretty solid, mature protocol. I don't think
re-designing it is a good idea, or would find a lot of traction in
industry. Web Browser and CA forums or W3C is a better place for this
type of activity.

To some degree If users would just never follow links to login sites in
their emails, and only use bookmarks or hand-typed URLs, it would help
too. 


-----Original Message-----
From: Joel.Weise@Sun.COM [mailto:Joel.Weise@Sun.COM]
Sent: Wednesday, September 26, 2007 5:24 PM
To: McCormick, Mike
Cc: Rudolph, Mike; x9f4@lists.x9.org
Subject: Re: [x9f4] Groups - X949 draft 20070923.doc uploaded

this is exactly where I was going with this - sounds like you and I are
looking at the same problem - my concern is that we should not just say,
use multi-factor auth and leave it at that - rather, we need to point to
effective authentication mechanisms that can address "phishing 2.0" as
you note.

I also recognize that nothing is perfect and we certainly want to note
that any authentication must be used within the context of an overall
security architecture and security program, but how specific can we get
in terms identifying specific technologies?  and are we constrained by
current technology?  or would we be open to discussing new technology
such as replacements for SSL?

michael.mccormick@wellsfargo.com wrote:
> This has become a hot topic, especially after a large US institution's

> commercial online banking site was apparently compromised last year by

> a MitM phish despite their use of 2-factor authentication with OTP
tokens.
> The lesson to be learned is strong 2FA can be completely ineffective 
> against certain real-time attacks such as "phishing 2.0".  If X9.49 
> can say anything helpful about mitigating this emerging risk it would 
> certainly make the standard more valuable to FIs.
>
>
> -----Original Message-----
> From: Joel.Weise@Sun.COM [mailto:Joel.Weise@Sun.COM]
> Sent: Wednesday, September 26, 2007 4:26 PM
> To: Rudolph, Mike
> Cc: x9f4@lists.x9.org
> Subject: Re: [x9f4] Groups - X949 draft 20070923.doc uploaded
>
>
> I had a discussion with someone today about man in the middle attacks 
> - we ref these as noteed below - my question is, do we want to specify

> what 'extra steps' one should take to address this?
>
> Note that a financial institution may not be able to stipulate that an

> end user prevents this type of attack, but should take extra steps to 
> prevent fraudulent transactions if they cannot be sure that the 
> connection is secure end to end.
> 1.Both parties shall be able to authenticate the security of the 
> connection, to detect if there is a "man in the middle."
>

Received on Thursday, 27 September 2007 16:45:45 UTC