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