Re: [dix] DRAFT: WAE BOF minutes

[Eliot Lear <[e-mail]>]

Dick,

Here are my notes from yesterday that you may wish to merge.

Eliot

    Summary

There was a general concern that we could end up boiling the ocean. 
There are four problems that we could work on:

   1. Non-insane replacement for HTTP digest / anti-phishing
   2. Cross Site Identity
   3. Claim and Attribute Transferral
   4. Eliot's Dad's Problem (EDP) of unhealthy password reuse / storage
      or failure to remember !@#%. 

There seem to be strong support for working on the first two, weak
support for the third, and a general agreement that 4 should not be
forgotten, although it was unclear whether 4 needed to be solved
separately from 1 and 2.  There was discussion on dependency between 1
and 2.

There also seemed to be general agreement that we should focus our
efforts on fixing HTTP browsing first, non-browsing second, and not
worry about cross application credentials.

Lisa and the IESG now have to determine whether there should be another
BoF, separate BoFs for separate working groups or to do something else. 
We also need to take into account work done by other organizations, such
as W3C, and we need to take note of UI concerns.


    More Details


Pete kicked off the BoF with a discussion around common terminology,
with some attempts to define common terms like authentication,
authorization, and credentials.  Required reading: RFC 2828; recommended
reading:  http://identitygang.org/Lexicon and
draft-shirey-secgloss-v2-04.txt.  One word that was considered out of
bounds was "identity".  This caused some issues later.  Jeffrey
Hutzelman suggested and there seemed to be general agreement that the
better approach would be to talk about concepts and then agree on
terms.  Either way, we staggered through the terminology discussion.

Pete then took us through a menu of problems we *could* solve:

    * Capture-Resistant Credentials (CRC)
    * Hijack-Resistant Authentication (HRA)
    * Portable Credentials (PC)
    * Fill-in of Personal Information (FPI)
    * Common User Credentials (CUC)
    * Continuity of Identity (CI)
    * User-Friendly Names (UFN)
    * Assertion of External Claims (AEC)
    * Independent Assertion of Claims (IAC)
    * Private Authentication (PA)
    * Single Site Unlinkability (SSU)
    * Multiple Site Unlinkability (MSU)
    * Attack Resistant Credentials (ARC)
    * Claim Minimality (CM)


On the jabber there was some discussion as to whether CM is the same or
different from IAC.

Sam next presented.  He first talked about the need for an unspoofable
UI.  It was pointed out that simply having a little lock box icon
doesn't solve the problem.  One possible solution would be for users to
brand computers in a way that would be used for sensitive transactions,
the idea being that no spoofer could know what this branding is.  Within
the jabber there was a fair amount of discussion around SAKs (secure
attention keys), and whether they could help/solve the problem.

Next Sam talked about requirements for web authentication.  MUST solve
the problem for passwords without the need for smart cards.  Eliot
raised a concern about needing to support smart cards but not mandating
them as part of the architecture.  This annoyed Sam  ;-)   Sam's
requirements also included not sending password equivalents, mandating
mutual authentication of the server, and binding authentication to the
returned web page.  He went on to describe what his requirements buys.

One of the requirements that got raised on the jabber chat was one of
"supports existing infrastructure".  According to the chat log, the
infrastructure in question is authentication infrastructure or - passwords.

Next Pete and Lisa organized discussion over what problems we could
solve.  She wrote down three, which eventually became four.  Here are
the four:

    * EKR1 - anti-phishing / fixing HTTP authentication, GUI, Mutual
      Authentication, passwords AND other.  About 20 people in the room
      indicated they were interested in working on this problem.  This
      is the one that also requires liaising with W3C.  Layer/Arch TBD.
    * EKR2 - cross site identitiers.  About 15 people were interested in
      working on this problem; while 10 people suggested that more
      analysis was needed.  This effort may required shared mechanisms
      with EKR1 and definitely requires coordination.  Only six people
      want to work on it as a separate problem.
    * EKR3 - claim and attribute exchange.  Not limited to HTTP.  We
      rushed through this in 10 minutes.  Twelve people indicated
      interest in this problem.
    * EKR4 - Eliot's Dad's Problem (EDP) of unhealthy password reuse /
      storage.  There was a view that done properly 1 and/or 2 would
      capture this.  Not clear how common that view was.

Lisa commented in the chat room and perhaps live that there's the
potential for a lot of commonality between EKR1 & EKR2.  [I surmise the
same is the case for EKR4.]

There was a healthy discussion about UI and IETF involvement in which
EKR best summed it up by saying that there are three possible things we
could say:

   1. Nothing;
   2. "Implementations must clearly indicate to users when a password is
      being typed into a trusted interface"; or
   3. "This is how the dialogs must look..."

Eric argued that (2) was most appropriate and I didn't hear or read any
objection.  Bob Morgan put it this way:

    /"where [user makes security decision] and [info available to user
    at that time] are things that can be written into protocol flows"

    /

Eric suggested a loose bottom up hierarchy of EKR1, EKR4(EDP), EKR2, EKR3.


Throughout the entire BoF there was a side conversation of SASL v. GSS.

Eliot


_______________________________________________
dix mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dix