[Ietf-http-auth] Narrative notes from bar BoF

[Lisa Dusseault]

6:00pm to 7:30 pm, Vancouver 70th IETF, narrative notes

Eliot Lear: volunteer to put some goals, if we can agree on them,  
into a draft charter.
Phil Hallam-Baker: ... We need to have identifiers that consistently  
identify us across the Web.
Lisa Dusseault: Does everybody agree we need leveraged identities?
Jeff Hodges: That's called single sign-on
Eliot Lear: authentication has a role to play in devaluing the assets  
of botnet controllers.
Sam Hartman: I can host a workshop on this
Yutaka Oiwa: For a web system, the ultimate goal is authentication of  
Web system, not only HTTP request, but actually the response:  
authenticate the *response* and the user reacts to that.
Sam: I like Nico's extensions for integrating this as they're  
modular.  Not mechanism-specific.
Lisa: Any disagreement with the goal that we're not inventing new  
authentication mechanism?
Phil: Go further, it's not a goal to invent a new authentication  
*framework* since we already have some.
Leif Johansson: you have to be careful about layering ...
Joseph Salowey: there are a lot of ways you can layer these things,  
this doesn't mean you'll do all these things together
Kurt Zeilenga: We want to reuse mechanisms from existing frameworks.
	[agreement]
Sam: If we can change my phishing draft to express goals for this  
effort, let's change it (as long as they're phishing related goals)
Leif: Enterprise goal of reusing frameworks, is a goal but not a  
phishing goal.
Chris Newman: There may be some priorities.  I think the anti- 
phishing goal is more important than some others.
	[agreement]
Lisa: I've heard other groups with the goal of making new  
authentication that works without upgrading browsers with new code.
Sam: I don't think that's consistent with security.
Lisa: Right. I don't think you can have all of: browser backward- 
compatibility, leveraged identities and phishing protection.
Jeff: Anyway, other organizations have covered this space. SAML, OpenID.
Chris: It is likely the outcome of this effort will require browser  
changes.
	[Agreement]
Sam: It is a goal that this supports things other than browsers.   
CalDAV, WebDAV.
	[agreement.]
Sam: Let's not break any mechanism that support that case, but not go  
out of our way to solve it:
Eliot: Very small federation inside the house may be in scope.
Sam: Specific example.  To scale down kerberos or digest, you would  
need an initial way to get your account setup. That's mechanism  
specific, but to scale down to small number of users, you'dneed a way  
to do that.  Requirements for that use case may be in scope, but  
changes to existing mechanisms like Digest or Kerberos should not be  
inscope for this forum.
Eliot: The neighbour managing the routing case, which is "have I seen  
you before"
Leif: This is lightweight federation
Stephen Farrell: What about scaling up, people who have not met each  
other being able to interact?
Sam: The mechanism work shouldn't be in scope, but the requirements  
are in scope.
Joseph Salowey: That means that we have to pick only existing  
mechanisms that solve these requirements?
Leif: Can you push the work onto another group like Kerberos?
Sam: Your mechanism needs to have an enrollment strategy that does  
specific things.  We're trying to do the glue and not
Lisa: Are we choosing what to glue?
Sam: We may choose mandatory to implement, but not limit the selection.
	[agreement]
Phil: I've been at a panel where people thought authentication meant  
two entirely different things. Are we doing contact authentication  
(like SSL certificates, password enrolment) or initial first-round  
authentication when you make contact with a Web server and use a one- 
time password, PKI token and a secondary mechanism to back it up?   
Cookies, lightweight recycling.  Three things to keep separate:  
enrolment (first contact), authentication and state management.
Sam: Our primary focus should be authentication, with possibly work  
on state management.
Leif: We might focus on state management for the purpose of  
authentication.   Not solve the general state management. An in-band  
mechanism for HTTP might not rely on cookies.
Phil: Cardspace is what cookies should have been: under user control  
and associated with information where the user can choose to release.
	[no disagreement on the scope possibly covering state maintenance or  
auth maintenance.]
Eliot: do we focus on form authentication in this forum?
Sam: Maybe.
Chris: I view it as authentication dialog branding as part of the  
mechanism.  There's a reason people choose forms.
Joseph: People want to do rich content...
Lisa: Saying "authentication dialog branding" is already selecting a  
user interface, I'm not sure we can do that.  We're not sure that  
branding is the only reason people eschew dialogs, there may also be  
need for navigation links, links and text for things you can do if  
you don't log in.
Sam: Nico's draft is good for this because it allows existing  
interfaces to be done securely.
Eliot.  A workshop that includes W3C and oasis could solve this problem.
Phil: Yes, the effort is diffuse and lacks critical mass.
Leif: So we carefully scope this.  In-band authentication seems to be  
the commonality.
Eliot: Not just the right standards bodies involved, but the right  
people involved: Google, MS, Mozilla, Apple are in the room.
Mark Nottingham: You need users involved: sites like EBay, Amazon,  
people who have concerns that nobody in this room is talking about.
Sam: That's too many people for a workshop.
Mark: Building something that works in the security world, but  
doesn't map to the requirements of users, happens all the time.
Tom Yu: Workshop should invite people who can agregate common  
concerns and present that.
Phil: Suggest David Solo from CitiGroup;
Peter St Andre: Be exclusive for this workshop.  Only people who are  
crucial.
Phil: W3C workshop: require people to write position papers, weeds  
out the tourists.
Sam: I volunteer Eliot and myself and one or two others to organize a  
workshop.    We could also just do a WG and simultaneously get the  
effort to get participation from other people.
Keith Moore: You need a workshop to decide what to do next even if  
it's a WG.
Mark: Will a workshop be substantially different than the BoF in  
Montreal?
Sam: If we're limiting it to IETF scope, then it would not be  
different and would be worthless.  So let's not limit it.
Eliot: we need to get the right people and that they understand the  
scope is not just IETF.
Phil: Doing this under "Note Well" rules is important.



Lisa: Did we have agreement on authenticating the response?
[somebody said this is the same as mutual auth]
Sam: No, that is differen than mutual auth.  You want to know that  
the page you get back was really from the party you mutually  
authenticated to.
Eliot: Authentication across transactions, if you will. This was in  
your phishing draft.
Lisa: Any disagreemtent on addressing that?  [none at first, but  
then...]
Joseph: Authenticating the data can be difficult, because it might  
not come from the source that you authenticatied.
Sam: Packaging it up is ok.  You need to know that the source you  
vetted provided it.
Jeff: Even images, links in pages?

Eliot read a bunch of charter notes and confirmed.

Cyrus Daboo: What's the expected outcome of the workshop?
Sam: Set of tasks to accomplish, where the tasks include writing  
code, IETF standards, and other organizations standards.

Eliot: And web forms?
Sam: In one model, you have glop in forms that triggers in-band  
notification.
Eliot: How can we express that without closing down too tightly?  The  
high level goal?
Sam: Yes, include the goal to support Web forms, and I'll argue that  
the solution is the same.
Mark. And Web services are covered.

Mark. What about OAuth?
Sam: My conclusion is that it didn't solve anti-phishing well.
Leif: It solves the N-tier problem:
Lisa: Explain?
Cyrus: WebMail. I need to proxy my credentials from my browser  
through the Web interface to my email server.
Mark: Or you want a mashup to be able to access your photos on Flickr  
for their cool thing; you give them rights.
Jeff: That's only one tier, you're delegating rights, not doing  
authentication.
Sam: it could be a limited use credential.


Tom: Are we agreed our task is larger than protocol? We work on  
conceptual things, cognitive landscape?
Mark: Who "we" are is interesting there.
Sam: The people sitting around this room need to be involved in more  
than just the IETF for this to work.

Lisa: who will be proposing a BOF?
Eliot: Perhaps an outcome of the workshop is charters for work in  
various SDOs.  Cisco sometimes asks academics to do vague things; we  
can do the analogous thing in asking help for a charter or WG.
Sam: I'm not convinced a workshop is strictly necessary.
Leif: The workshop could follow on a WG too, to establish consensus  
with other SDOs.

Lisa: I personally was hoping we would do some small yet important  
fixes, even if we didn't solve the big problems with other SDOs.
Derek Atkins: To do the small fixes, do we have the IE and firefox  
people here?


***Leif: Can we get everybody on the list?

Eliot: What would solve your problem Robert Sayre?
Robert Sayre: I've been trying to find a solution to shared secret  
authentication, that we can actually use, and do branding.
Sam: I think you could turn HTTP-Nego into something you could use  
for that.
Eliot: What is gating you from addressing the problem you just  
described?
Robert: Every time we get into mutual authentication and message  
integrity, TLS becomes a requirement.  I'm dubious of that.  People  
don't use that.
Sam: You believe a mechanism should provide message integrity even  
without TLS?
Robert: The identity should be encrypted, even if the message is not  
encrypted.
Phil: We seem to think the auth here should be username/password.
Robert.  That's one problem I'm trying to solve.

Sam: We're hearing don't gate on a workshop.  I'd like to get Robert  
and somebody from the right part of Apple, the safari group.
Cyrus: I'm not from the right part, the CalSched group is trying to  
do cross-domain scheduling.  We don't want to have the spam problem  
we have in email, so we need federated authetnication and access  
control to do this.  We're not trying to define protocols, but rather  
requirements for the IETF work.

Eliot: How do we bring implementors in?
Cyrus: Interops.  People demonstrate phishing, see problem in real  
products.
Eliot: Demonstrating problems, not solutions?  Everybody accepts  
there is a problem.
Tom: The problem with demonstrating phishing is that will focus  
people on the details of phishing, not on the conceptual model.
Leif: How do you get implementors involved? You have a BOF and you  
ask if anybody in the room is going to implement the work.
Eliot: That's what WAE did and it failed.
Lisa: It didn't fail, it just failed to follow through.
Sam: It didn't even fail to follow through, Leif has been working on  
his draft, several of us have been working on pieces and will be  
ready with a specific proposal for a BoF.
Eliot: This argues not even a workshop, but a cabal building a  
constituency.
Mark: Devils advocate, not just getting vendors involved in the  
beginning.  If we get a new protocol introduced on a number of large  
Web sites, and in Mozilla, that is a path forward.   You need a  
browser and a site.
Eliot: You want to have a couple more people than you would otherwise  
try, because RSI or IIW have a ton of solutions and we have so many  
pet solutions.  They want to drive it through.
Mark: I've heard probelms on the table, the hard part is figuring out  
what's going forward.
Eliot; People trying to solve this problem can't have vendors own  
solutions.  The biggest vendor tried to play that.  We have sloughs  
of vendors playing kings of mountains, and diffusion.

Leif: We shouldn't hang up non-browser applications on the phishing  
problem.  We may find phishing to be a social problem.
Keith: you can't separate the probelms.
Leif: The non-browser, HTTP problem is unique to us and we need to  
solve it.

Sam: Please review my draft, section 1.1. Are we headed in the right  
section.

Chris: How do we get convergence? The thing that no other  
organization is doing is trying to solve the non-browser problem.
Sam: I dont' know if anybody else is looking at mutual authentication.
Chris: True, but I don't know if mutual auth is a req't of people  
we'd need to converge.
Sam: We can use people like the banks to convince them they need it.
Mark: Non-browser auth is in my area, with interesting and hard  
req'ts.  I want to allow 3rd party code to auth against my service,  
but not to get the user access to those credentials
Chris: That's too hard.

Lisa; The list is ietf-http-auth at osafoundation.org.  Everybody  
joining or on that list, right?
Lisa: Any objections if I post these notes to the list?  [none]

Eliot: What are we doing next?  I haven't heard a consensus view how  
to proceed.
Leif: We could do a BOF around the non-browser auth.
Keith: That's a piece the IETF could work on, yes, and get moving,  
but the workshop is important too.

Eliot: Sam, Mark and I will propose how to proceed to this list.   
We're going to do that through email next week.

Eliot: So everybody's going to look at Sam and Leif's documents.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-http-auth/attachments/20071205/e02b2742/attachment-0001.html