... two approaches - shared secret, and a reverse single sign-on where servers authenticate to clients

14:14:18 [chaals]

slide: Shared secret approach

14:15:02 [chaals]

FH: No CA required... but there are other standardising issues

14:15:16 [chaals]

... discussed in previous talk.

14:15:34 [chaals]

... This brings us back to what kerberos was doing.

14:15:53 [chaals]

slide: simplified server authentication

14:16:24 [chaals]

slide: SSA advantages and issues

14:16:36 [chaals]

FH: you can leverage existing work.

14:17:23 [chaals]

slide: SSA Approaches

14:17:52 [chaals]

FH: Assumes some sort of relationship among the parties

14:18:27 [chaals]

... You can use a proxy for clients that don't handle the whole lifting themselves

14:18:43 [chaals]

slide: IDP secret approach

14:20:06 [chaals]

FH: Use an ID provider to proxy authentication of service

14:21:13 [chaals]

... The client can enforce a requirement that the service provider authenticate too, if required to authenticate to them.

14:21:28 [chaals]

slide: IDP secret approach (second slide)

14:21:38 [chaals]

slide: Flow diagram

14:21:50 [chaals]

FH: Like SAML but added steps for service provider

14:22:03 [chaals]

slide: IDP Accessed as Portal

14:23:13 [chaals]

FH: Then the client doesn't need to go back and forth authenticating if it trusts a portal providing ID...

14:23:22 [chaals]

slide: IDP Portal operation

14:23:36 [chaals]

slide: flow diagram for IDP portal

14:24:01 [chaals]

slide: Enhanced client or proxy

14:24:18 [Alan]

Alan has joined #security-ws

14:24:24 [chaals]

FH: Put something more into the flow

14:24:56 [chaals]

... so you know how to get to the right ID. Bunch of this stuff went into SAML.

14:25:16 [chaals]

slide: flow diagram - enhanced client

14:25:44 [chaals]

slide: summary

14:26:53 [chaals]

Q: clarification. problem is mutual authentication in a single sign-on context?

14:26:58 [chaals]

FH: Yes.

14:27:10 [chaals]

Q...: leveraging a ring of trust?

14:27:14 [chaals]

FH: Right.

14:27:48 [chaals]

Q...: How does this compare to other approaches to site authentication

14:27:56 [chaals]

FH: Didn't think about it :)

14:28:10 [chaals]

... this is a presentation of another idea, but not comparative

14:28:12 [DanC_lap]

DanC_lap has joined #security-ws

14:29:04 [chaals]

... Oh. Hang on. This doesn't assume an authentication mechanism per se. There are various techniques that could be plugged into this approach.

14:29:25 [chaals]

Q: Trying to understand difference between this and static authentication.

14:29:59 [chaals]

... what are benefits?

14:30:11 [chaals]

FH: Client doesn't need to do a lot of crypto/PKI

14:30:27 [chaals]

... underlying is still the authentication infrastructure

14:31:00 [chaals]

Q: Under enhanced client / proxy you assume there are no requirements for changing client. that is if it knows about the IDP, right?

14:31:05 [chaals]

FH: Right...

14:31:20 [chaals]

Topic: deviance

14:32:11 [chaals]

s/deviance/Applying context to Web Authentication/

14:32:18 [chaals]

John Linn et al.

14:32:31 [chaals]

slide: Overview

14:34:09 [chaals]

slide: Web Authentication Today

14:34:26 [chaals]

JL: The situation today is not very pretty...

14:35:58 [chaals]

slide: user authentication flow, decomposed

14:36:48 [chaals]

JL: There are various points of attack available

14:37:07 [chaals]

... but in the happy case you get data to the site...

14:37:23 [chaals]

slide: authenticator data: 3 reusability classes

14:39:17 [chaals]

slide: Partially reusable data - example context dimensions

14:39:51 [chaals]

JL: Make the data something that makes no sense outside some aspect(s) of the original context(s)

14:40:16 [chaals]

... the more dimensions of unique contextual value, the better your protection

14:40:29 [chaals]

slide: Protecting evidence in a destination context

14:42:26 [chaals]

slide: aspects of approach

14:43:19 [chaals]

JL: Password is a deterrent - not necessarily guaranteed, but can be made relatively pointless...

14:43:39 [chaals]

... to break down

14:44:32 [chaals]

slide: safeguarding the evidence

14:45:18 [DanC_lap]

DanC_lap has joined #security-ws

14:46:19 [chaals]

slide: mutual authentication

14:47:09 [chaals]

JL: User Interface design here is important...

14:47:41 [chaals]

... you can say "here is what we found, what do you want to do", or interpret and act on behalf of user. Perhaps neither is the right universal approach

14:47:55 [chaals]

slide: standardisation prospects

14:49:15 [chaals]

slide: concluding observations

14:50:17 [chaals]

Q: ??? licensing ???

14:50:47 [chaals]

Q: We have told users about trusted paths, but they still click dodgy links in email. Could I still do that...

14:51:00 [chaals]

JL: Think it is a fertile ground for thinking about it

14:52:07 [peter]

peter has joined #security-ws

14:52:35 [plipp]

plipp has joined #security-ws

14:52:39 [chaals]

Q: (comment) How do we put good password protection in browser? How do we generate critical mass for this technology? Would be no brainer to dump dig-auth in a form. I want mechanism that lets me buy an auth token, I am happy to get a plugin to use that, but there still needs to be some some glue for the transport. But I then want to use that anywhere...

14:53:16 [chaals]

... without being bothered by patents etc. That's stnadardisation question - then where do we do the work - w3c, ietf, ...?

14:53:30 [chaals]

JL: For deployability the ideal is to change nothing. Which is not possible.

14:53:50 [chaals]

... so question is what is the simplest change we can make

14:53:59 [chaals]

Q...: Think we can make one change...

14:54:55 [chaals]

Q: Nice idea. We have been working on a similar one. Problem - passwords can be broken. Better solution would be zero-knowledge password proofs - we posted a position paper on this.

14:55:31 [chaals]

Q: If you embed a one time password approach, why not use zero-knowledge proof?

14:55:45 [chaals]

JL: OTP is not necessarily challenge based, so may not have the same overhead

14:56:02 [chaals]

Topic: How sites can manage HTTPS when users dont.

14:56:06 [chaals]

Andy Ozment et al.

14:56:28 [chaals]

slide: simplifying tasks and decisions

14:56:49 [DanC_lap]

DanC_lap has joined #security-ws

14:56:58 [chaals]

AO: Two types of tasks for users - trying to remove the https tasks

14:57:04 [chaals]

slide: goals

14:57:13 [chaals]

slide: what's expected today

14:57:29 [chaals]

slide: method A request

14:57:44 [chaals]

AO: This is what we expect of users, not what they are actually doing.

14:58:09 [beltzner]

[um, why does this slide assume that users are typing in direct urls to their login pages?]

14:58:29 [beltzner]

[oh, wait, I get it]

14:58:45 [chaals]

AO: nothing in UI to help users decide if it is safe enough to use HTTP plain text

14:58:53 [chaals]

slide: method B: verify

14:59:44 [chaals]

AO: users can't tell why a domain isn't the one they expected

15:00:04 [chaals]

... mistyped? trsutable redirect? attack?

15:00:11 [chaals]

slide: tasks and decisions

15:01:23 [chaals]

AO: For an untrusted source, stop user making a mistake by preventing them from using unsafe method for trusted source, or if domain isn't recognised as safe then recheck

15:01:32 [chaals]

slide: Why don't we have this?

15:01:43 [chaals]

slide: proposal

15:02:30 [DanC_lap]

(dnssec... are the relevant roots doing that yet?)

15:02:32 [chaals]

slide: query root zone

15:06:15 [chaals]

AO: So the wonderful thing is that Alice uses the specified signed requirement to use SSL foo - no man-in-the-middle hole

15:06:26 [chaals]

slide: ssr record's capabilities

15:08:57 [chaals]

slide: design questions

15:10:06 [beltzner]

I don't know why this means a user doesn't need to know whether or not they're using an SSL connection, since that's how they'll understand the nature of their connection

15:10:37 [chaals]

Q: Are you anticipating DNSSec will be implemented at browser, or OS level?

15:11:02 [chaals]

AO: anticipate it eventually in OS, but there are resolvers out there and believe browsers can do this until then

15:11:50 [DanC_lap]

(what's the dns root's public key? where does a body get it? I'm having trouble navigating http://www.dnssec.net/ (

15:11:54 [DanC_lap]

)

15:11:59 [chaals]

SS: Browsers need to be aware of it anyway

15:12:29 [chaals]

Q: Key management is important - who is going to manage the keys and how will DNSSec be deployed?

15:12:38 [chaals]

SS: There is a root key managed by ICANN

15:13:32 [chaals]

AO: Every zone has to sign their zone. The extra complexity is not enormous.

15:14:01 [DanC_lap]

(huh? tlr, why is that not a discussion for here? bummer.)

15:14:10 [chaals]

[Thomas, please stop being so far to the right]

15:14:19 [chaals]

Q: Wells Fargo are 100% under SSL

15:14:23 [chaals]

(applause)

15:14:47 [chaals]

Q...: Security for pushing metadata down - hadn't considered putting that through DNS

15:15:04 [chaals]

[/me not too keen to fetch advertising through SSL on a phone]

15:15:36 [chaals]

AO: Problem isn't in SSL - we used SSL 2 for the handshae - this secures info in advance about how to secure the connection

15:16:16 [chaals]

Q: Assuming all this works, I would think the fingerprint of my site key would be useful information to include, since I already trust DNSSec - no onger need to deal with CAs