Re: [http-auth] Evaluation Criteria

[Yoav Nir <[e-mail]>]

On Jul 18, 2013, at 12:21 AM, Stephen Farrell <[e-mail]> wrote:

>> 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.
> 
> * 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
> sounds like a fine idea.

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