Re: [dix] DRAFT: WAE BOF minutes

["Ben Laurie" <[e-mail]>]

On 7/15/06, Eliot Lear <[e-mail]> wrote:
> 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.

For the record, I'd note that CM is about providing properties of
claims (e.g. proving you are over 21 given a claim of your date of
birth, without revealing the date) whereas IAC is about separating
claims.

>
> 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
>

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