Subject: [http-auth] Draft Agenda for Berlin

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Jul 2013 20:19:09 +0000

Hi all

I've uploaded the draft agenda for the Berlin meeting. If you have any comments or corrections, please contact Matt and me either on- or off-list.

See you all in just under two weeks.

Yoav

http://www.ietf.org/proceedings/87/agenda/agenda-87-httpauth

HTTP-Auth Agenda, IETF 87

Wednesday, July 31, 2013 1300-1500  @ Potsdam 2

Audio stream:
     http://ietf87streaming.dnsalias.net/ietf/ietf875.m3u

Jabber room:
     xmpp:[email-masked]?join
     
All the drafts in Kindle and epub format:
     http://tools.ietf.org/ebook/i-d.httpauth.mobi
     http://tools.ietf.org/ebook/i-d.httpauth.epub

 - Agenda Bashing + Blue Sheets + Note Well                      5 min
 - Basic update and open issues (Julian)                        15 min
 - Digest update and open issues (Rifaat)                       25 min
 - Experimental drafts evaluation criteria (chairs)             15 min
 - HOBA                                                         20 min
 - MutualAuth                                                   20 min
 - SCRAM                                                        10 min
 - open mic                                            Whatever's left

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Jul 2013 21:30:23 +0100

Hi Yoav, Matt,

Agenda looks good. One question though:

>  - Experimental drafts evaluation criteria (chairs)             15 min

Can you say a bit about what this agenda topic is meant to
cover?

I guess it could be entirely innocuous (e.g. if you asked for
ideas as to what criteria the wg want to use at WGLC time
for these) or quite controversial (e.g. if you were to insist
that only schemes beginning with the letter H could
progress:-).

So maybe giving the list a heads up about what you'd like
to cover there would be good, just in case we should chat
about it on the list in advance.

Ta,
S.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Jul 2013 21:10:14 +0000

> Can you say a bit about what this agenda topic is meant to

Hi 

Since we are aiming for Experimental with all of these documents, rather than "experimental" as consolation prize, we though we would have a short discussion about what kind of things reviewers should most look for in them. That does not mean that we don't welcome other review comments such as about algorithm agility and I18N (just examples), some of these issues may be left for a time when we want to rewrite one or more of these as standards-track.

I think it's a good idea to start this discussion now. So as a starting point, how about these:

* Security (obviously - look for vulnerabilities or bad practices)

* Implementation pitfalls - anything that will make implementing this unnecessarily difficult

* unstated assumptions or requirements - some examples:
    * if the method requires a file with cleartext passwords on the web server, that's fine or not, but it should be stated. 
    * If the method requires TLS, that should be stated. 
    * If the web server needs access to the TLS state (for extractor, or data from a user certificate), that should be stated.
    * If either or both sides need a good random source, that should be stated.
    * If implementing this requires some UI elements in the client, that should be stated.

* Interaction with infrastructure - can this work with AAA protocols? Can you use this for OpenID/WebID/OAuth ?

* Performance - does this proposal have extraordinary resource (CPU/memory/bandwidth) requirements?  Per authentication? Per logged-in user? Per defined user?

This is by no means a closed list, and we'd be very happy to get feedback and updates to this list.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Jul 2013 22:21:34 +0100

On 07/17/2013 10:10 PM, Yoav Nir wrote:
>> Can you say a bit about what this agenda topic is meant to cover?
> 
> Hi
> 
> Since we are aiming for Experimental with all of these documents,
> rather than "experimental" as consolation prize, we though we would
> have a short discussion about what kind of things reviewers should
> most look for in them. 

That seems reasonable. I'd also note that the charter tells us to
be short-lived though, so there's a balance to be achieved between
thorough/shoddy and short-lived/endless:-)

> That does not mean that we don't welcome other
> review comments such as about algorithm agility and I18N (just
> examples), some of these issues may be left for a time when we want
> to rewrite one or more of these as standards-track.
> 
> * unstated assumptions or requirements - some examples: * if the
> method requires a file with cleartext passwords on the web server,
> that's fine or not, but it should be stated. * If the method requires
> TLS, that should be stated. * If the web server needs access to the
> TLS state (for extractor, or data from a user certificate), that
> should be stated. * If either or both sides need a good random
> source, that should be stated. * If implementing this requires some
> UI elements in the client, that should be stated.
> 
> * Interaction with infrastructure - can this work with AAA protocols?
> Can you use this for OpenID/WebID/OAuth ?
> 
> * Performance - does this proposal have extraordinary resource
> (CPU/memory/bandwidth) requirements?  Per authentication? Per
> logged-in user? Per defined user
> 

* Vulnerable to password-verifier DB theft... or not? :-)

If the above are used as ways to prompt better review that
sounds like a fine idea.

If someone wanted to insist on some form of checklist that
drafts have to include, or a set of criteria that they each
have to meet then I don't think that would have been such
a good plan.

Cheers,
S.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Jul 2013 21:43:34 +0000

> * Vulnerable to password-verifier DB theft... or not? :-)

I hope this falls under security, no?

> If the above are used as ways to prompt better review that

To be clear, there is no check list. I don't think we should advance a clearly broken method. But if a method is practical and secure only under a set of conditions, it can advance as long as it states such conditions.

And to answer another question that I got in private email: these criteria apply to the experimental drafts: HOBA, Mutual, Scram, and RestAuth.  Our charter calls for standards=track for the Basic and Digest documents, plus the protocols (before the update) have over 20 years of deployment experience, so they will be evaluated just like any other IETF draft.

Yoav

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 18 Jul 2013 10:32:07 +0900

> that only schemes beginning with the letter H could

Well, the schemes not starting with the letter H could just rename 
themselves :-). It's all about HTTP, so smuggling in the letter H 
shouldn't be too difficult.

Regards,    Martin.