[Ietf-http-auth] Narrative notes from bar BoF
lisa at osafoundation.org
Wed Dec 5 10:14:44 PST 2007
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
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.
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
Chris Newman: There may be some priorities. I think the anti-
phishing goal is more important than some others.
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
Sam: It is a goal that this supports things other than browsers.
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
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.
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
Eliot: do we focus on form authentication in this forum?
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
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
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
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
Eliot: Authentication across transactions, if you will. This was in
your phishing draft.
Lisa: Any disagreemtent on addressing that? [none at first, but
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
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:
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
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
***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
Eliot: What is gating you from addressing the problem you just
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
Robert: The identity should be encrypted, even if the message is not
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
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
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
Sam: Please review my draft, section 1.1. Are we headed in the right
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
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...
More information about the Ietf-http-auth