Subject: [dix] DRAFT: WAE BOF minutes

From: Dick Hardt <[email-masked]>
Date: Sat, 15 Jul 2006 13:38:04 -0400

The meeting started off with the usual agenda review. Agenda was  
accepted as proposed.

The first item was Terminology.
Reading assignment: read RFC 2828
	Internet Security Glossary
	http://www.ietf.org/rfc/rfc2828.txt
Other Glossaries mentioned:
	Internet Security Glossary, Version 2
	http://www.ietf.org/internet-drafts/draft-shirey-secgloss-v2-04.txt

	SAMLv2: Glossary
	http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf

	"identity gang" lexicon
	http://identitygang.org/Lexicon

The next item was Problems we want to solve (see agenda)
A few things were added:
	- whitelisting
	- claim minimality
	- proof of server identity

Sam Hartman made his presentation, there were a few questions.

There was then discussion on Problems we want to solve.
****** edit here -- right title? same as before

Additional problems
	non-browsing HTTP support
	support for existing infrastructure
	Cross Application Credential (XAC)

Grouping of problems was then started.
Dick Hardt's slide was presented.

Ekr proposed grouping the problem up as:

EKR1: fix http auth
	- anti-phishing
	- passwords and other

EKR2: cross-site identity, Eliot's dad, SSO

EKR3: Claim & Attribute Transferral

More detailed discussion on each problem then ensued:

EKR1: Fix HTTP Auth
AD questions to audience concluded with:
	- Liaise w/ W3C on GUI
	- Liaise w/ APWG
	- Layer / Arch TBD
	- can stand alone, but coordinate w/ EKR2 and EKR3
	EKR1 does not require EKR2

EKR2: cross-site identifier
(Eliot's dad problem was broken off to be EKR4)
	- raw assertions of identity are easier to trust than attributes
	- name subordination
	- existing technology, but glue work
	Question: Is there glue work to be done by the IETF?
			- no one thinks there is no glue work, 15 think there is, 15 are  
not sure
	12 ok on work if EKR1 not happening,

EKR3:Claim & Attribute Transferral
	- existing claims and syntaxes may be used
	- binds attribute assertions to underlying communication
	- not limited to HTTP
	Question: Is there glue work to be done here by the IETF?
	12 support, a couple object

EKR4:
	- eliot's dad problem
	part of EKR1 & EKR 2

Discussion if EKR1 and EKR2 required different BOFs at next IETF  
meeting. Clearly different drafts would be required. Best to combine  
group working on them.

Meeting concluded 15 minutes late.

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

---

From: Eliot Lear <[email-masked]>
Date: Sat, 15 Jul 2006 20:23:46 +0200

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

---

From: "Ben Laurie" <[email-masked]>
Date: Tue, 18 Jul 2006 13:53:57 +0100

> On the jabber there was some discussion as to whether CM is the same or

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.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Jul 2006 07:57:59 -0500

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

Mostly in the jabber room though...