IRC log of security-ws on 2006-03-16

Timestamps are in UTC.

02:44:39 [peter]
peter has joined #security-ws
04:37:23 [jose-lap]
jose-lap has joined #security-ws
09:39:56 [herman]
herman has joined #security-ws
09:40:44 [herman]
herman has left #security-ws
11:34:57 [peter]
peter has joined #security-ws
11:59:58 [pecorra_]
pecorra_ has joined #security-ws
12:47:05 [pecorra_]
pecorra_ has joined #security-ws
13:35:02 [beltzner]
morning, y'all
13:36:27 [djweitzner]
djweitzner has joined #security-ws
13:37:31 [Robert_Capps]
Robert_Capps has joined #security-ws
13:37:41 [chaals]
chaals has joined #security-ws
13:37:55 [peter]
peter has joined #security-ws
13:38:08 [chaals]
Meeting: Transparent and Usable Security Workshop
13:38:08 [chaals]
Scribe: Chaals
13:38:15 [chaals]
scribenick: chaals
13:38:26 [chaals]
chair: Thomas Roessler
13:38:42 [chaals]
Topic: story about connection
13:39:29 [chaals]
This room had no power or network. Yesterday they pulled a whole lot of cables up from a lot of floors below. Today Cisco installed a satellite system to provide the networking
13:40:17 [chaals]
It was set up last night in about half an hour (mostly involving taking the things out of the boxes on the roof with the great view)
13:42:14 [beltzner]
800ms ping times; awesome!
13:43:08 [pecorraOffice]
pecorraOffice has joined #security-ws
13:44:51 [beltzner]
[so, I guess I shouldn't pull from trunk, eh?]
13:45:57 [chaals]
[various discussion about the satellite and how it works... ]
13:47:30 [chaals]
Topic: A Confidence Model of Web Browsing - Y!
13:47:45 [chaals]
Prasanta Behera and Naveen Agarwi
13:48:18 [chaals]
PB: we are in login / identity group...
13:48:44 [chaals]
... we are talking about an idea we hav been kicking around for a couple of months. Haven't prototyped it yet - will obviously need work.
13:49:25 [chaals]
slide 1: Problem.
13:49:55 [chaals]
PB: most of this has been discussed. Authentication is just one part - once a user has authenticated the whole interaction needs to be safe.
13:50:04 [chaals]
s/safe/"safe"/
13:50:06 [plipp]
plipp has joined #security-ws
13:51:04 [chaals]
NA: Main querstion - how does a company with multiple domains assert that they are all the same organisation
13:51:17 [chaals]
PB: SSL-only won't do the job
13:51:30 [chaals]
... pricing, deployment problems
13:52:02 [chaals]
... multiple domains - Yahoo, flickr, deli.cio.us ...
13:52:13 [chaals]
Q: Just management, not SSL performance?
13:52:29 [chaals]
NA: Performance is also a problem - makes a big difference in content stuff like flickr
13:53:21 [chaals]
... for banking it is important, but for general browsing it has too big a hit on servers and transfers.
13:53:33 [chaals]
PB: There is a lot of content that doesn't need to be secured.
13:54:13 [chaals]
... there is a model where you can decide on sites you want to trust - put a URI into a list. Kind of works, but you have to select each URI
13:54:22 [chaals]
... only works for HTTPS.
13:54:32 [chaals]
... so not scalable for large deployment case
13:54:57 [Mez]
Mez has joined #security-ws
13:55:01 [chaals]
Q: You want the user to know they are on teh authenticated site, but concerned about the overhead of SSL?
13:55:30 [chaals]
NA: Those are some of the problems. Also SSL only says transmission is secure - doesn't let you assert that you are dealing with the same company over a collection of domains
13:55:45 [chaals]
[/me likes that Yahoo does the right thing and not shift URIs when they buy existing services]
13:56:24 [chaals]
PB: Some solutions were discussed yesterday. Hashing some content...
13:57:40 [chaals]
NA: This is in addition to what a client can do - we are trying to find soething servers can do to help the client.
13:57:46 [chaals]
slide: approach
13:58:28 [chaals]
NA: You get a token based on a browser saying they trust a service, like a shared secret
13:58:38 [chaals]
[/me thinks "or digital signature?"]
13:58:42 [chaals]
slide: flow model
13:59:11 [beltzner]
[this requires that the user identify a site every time they start a session, right?]
13:59:17 [Alan]
Alan has joined #security-ws
13:59:28 [chaals]
Q: What if you don't get a response from an SSL request
13:59:33 [chaals]
NA: Well, you don't mark it as trusted
14:00:15 [chaals]
Q: ??? The content and hash can be swapped?
14:00:49 [beltzner]
Q: With multiple requests, I could send one request and get a MiM/malicious response
14:00:58 [beltzner]
A: What would the hacker gain from that?
14:01:08 [beltzner]
chair then asked to hold questions until the end
14:01:11 [chaals]
slide: sample metadata
14:01:19 [chaals]
[thanks beltzner]
14:01:53 [chaals]
PB: There are companies trying to spoof Yahoo. So we want to capture the information of what really is yahoo.
14:02:22 [chaals]
NA: So you can say flickr.com and yahoo.com are part of the same group, using metadata - you get the same token from each domain.
14:02:31 [chaals]
slide: confidence browsing
14:03:02 [chaals]
PB: Browser can check that the token is the same as one they got from a trusted source.
14:03:41 [chaals]
slide: what is not addressed
14:05:16 [chaals]
slide: conclusion
14:05:56 [chaals]
Q: Why is binding from organisation to domains browser-specific not global?
14:06:15 [chaals]
PB: Each domain should have unique data from browser, to make the token have the nature of a shared secret
14:07:09 [chaals]
Q: The problem was that I see a website made to appear like someone else's website?
14:07:50 [chaals]
PB: Where you are getting data from a lot of different domains, you want to know that you are dealing with the same overall site/company
14:08:11 [chaals]
Q: So I can fool the user into thinking they are dealing with Yahoo...
14:08:47 [chaals]
NA: This is based on having established a relationship already. If you trusted Yahoo somewhere and selected them, then the bar will show if something is not part of a trusted site
14:09:07 [chaals]
... this could be used to insert personalised recognition token into the page.
14:09:35 [chaals]
... it is hard to make the chrome foolproof - unless you are relying on something personalised to the user
14:09:50 [Alan]
Alan has joined #security-ws
14:10:23 [chaals]
TR: Time please, gentlemen...
14:11:01 [chaals]
Topic: Frederick Hirsch, Nokia, ??? Sun (not here)
14:11:23 [chaals]
FH: looking at some approaches where single sign-on can be brought to bear on a problem
14:11:35 [beltzner]
s/???/Hubert Le Van Gong/
14:11:37 [chaals]
title: appraoches to simplify server authentication
14:12:02 [chaals]
FH: Constrained discussion. Two organisations - Liberty Alliance, OASIS XAML stuff
14:12:32 [chaals]
... Liberty Alliance has been around a while, done the Federation Framework (also a Web Services thing)
14:12:41 [chaals]
s/XAML/SSAML/
14:13:07 [chaals]
... talking loosely to outline an approach, not lay out a completed solution
14:13:21 [chaals]
slide: Motivation
14:13:52 [chaals]
FH: Lot of discussion already. This doesn't direct phishing directly I don't think.
14:14:14 [chaals]
... 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
15:16:32 [chaals]
SS: Already an IETF proposal for storing certificates in domain registry
15:16:55 [chaals]
AO: CAs still needed, e.g. to verify that a business really is themselves
15:17:27 [chaals]
Q: You have value here if you just have a policy record. You have to take account of fact that DNS is not extensible as claimed - it takes 5 years to deploy to 80%
15:17:39 [chaals]
... but you can make it work using prefix records.
15:19:17 [chaals]
Q: In some cases SSL might not be the right solution. It seems W3C could make contribution