Assurance

[David Walker <>]

So this is more about session integrity than authentication, right?  There is a threat to authentication of not having a sufficiently security session, which is why the FICAM (and InCommon) assurance frameworks often require the use of Secure Channels (e.g., TLS with mutual authentication), but there's also a threat to the entire session, even after authentication.

FYI, one of the Cohortium white papers touches on the issue that not all multi-factor provide the same security:  How Much Security Is Enough? (https://wiki.cohortium.internet2.edu/confluence/x/HwBL)  If what you want to do is simply to regain the confidence you thought you had in passwords ten years ago, just about any multi-factor technology will work.  If you want something stronger, though, you need to be more selective.

David

On 03/12/2014 01:03 PM, Tom Scavo wrote:

On Wed, Mar 12, 2014 at 2:57 PM, Cantor, Scott  wrote:

On 3/12/14, 2:40 PM, "Josh Alexander"  wrote:

Additionally, so far the conversation has been
steered toward MiTM attack vectors against MFA, but what about MiTB and
various endpoint attacks that happen post session authentication - what
are your thoughts as to if/how MFA can defend against these attacks behind
session auth?

This is obviously off in a different direction...

MiTB is basically a total break, and given a poor enough browser
implementation or bug, you could even conceivable steal a key stored
locally on the machine in the process. A MiTB is simply saying there's
malware on the machine, e.g. the various Java applet sandbox bugs, etc.

But I think you're maybe asking about what kind of session strength you
have after logging in, and the answer there is "lousy". Without a private
key, you have cookies and that's it. With a client cert, you can do
better, but it's extremely common for people to build apps that leverage
client certs for login, but then end up with cookie-based sessions
afterward because that's the assumption the frameworks all make, since
client certs are rare.

What you want is a session at least bound to the client cert in some way,
or the SSL session, but you rarely get that, much like you often see
people punt on binding a cookie to an IP address because of NAT.

But a MitB can basically own any session, it's the endpoint of the session.

Very useful, Scott. Thank you for that.

And no, I see no real way MFA can do much here (speaking of MFA as
distinct from client certs, I don't consider them the same category). What
it can do is add a channel to authenticate a transaction, right? Which was
Bruce Schneier's point Tom was referring to. But in a sense that's saying
"you can't trust the session, so don't rely on it, login again every time
it matters".

I totally agree. One example I've heard is the bank example that
Schneier alludes to. At the point the user tries to make a money
transfer, require confirmation on an independent channel.

Tom