[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have


Hello
There are a couple of qualities that are important to me. I believe they are 
already a part of SCRAM-MD5 but they should be on the bullet-list also.
I would like a client-first mechanism that sends the username before the challenge. My system supports multiple directories so I need to be able to route the session 
to the correct one based on the user account location.
I would also like the hash stored on disk to have arbitrary complexity. I've done some brute-force cracking tests. I find that a 4-core Mac Pro can typically break 7-character passwords with a simple (salt+hash) in under a day. We could also use OpenCL to use the 120 cores on the GPU to up the speed. Because we're dealing with the "stolen laptop case" in addition to locked-room servers, this 
vulnerability is of special concern.

Desirable on-disk hash features:
* salted
* iteration count
• ability to switch algorithms in case the hash-du-jour is compromised

The auth mechanism should communicate the on-disk hash type and
iteration count so that the client can convert the cleartext to the right hash before producing the response. We don't want to have to reconfigure the clients.
BTW: we do use the privacy layer, though I think we can work around its exclusion. 

- Steven Simon
- Directory Services
- Apple Inc.


On Mar 11, 2008, at 8:25 AM, Chris Newman wrote:
--On March 6, 2008 5:59:06 -0800 Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx > wrote: 
In response to reviewer comments on our charter proposal, we need to
quickly produce replacement text which clarifies the qualities we desire 
the DIGEST-MD5 replacement mechanism to have.
I'd like one or two persons (working together) to take a quick stab at this (for initial WG review BEFORE our IETF#71 session). Any volunteers? 

As a technical participant

The qualities I want are:
* Simple username/password mechanism that is hash-based.
* Minimize administrative set-up cost
* Ability to store a password verifier in LDAP (or other identity store) that is not 
the password itself
* Ability to use one layer of reverse/server-side proxy where the proxy doesn't have a direct copy of the password verifier database and doesn't require administrative 
credentials to back-end
* Has equivalent of both server & client nonces (to avoid CRAM-MD5 server-only nonce 
weakness)
* Support for channel bindings to TLS
* Support for authentication & authorization ID

Things mechanism should not do:
* Require client UI for realm selection
* Require client-side configuration for the authentication mechanism itself * Require a write operation to the server credential verifier database on every login * Include a rarely used optional feature, such as a SASL security layer. * Silly syntax variations that create interop problems (folding whitespace, etc). 

Nice-to-have features:
* Complexity closer to CRAM-MD5 than DIGEST-MD5.
* Textual protocol like CRAM-MD5 over binary protocol that's harder to test/debug 
* Support for mutual authentication (may be an option)
* Server-stored password verifier that is not plaintext-equivalent
* Mechanism that's useful without TLS
* Minimize round-trips
* Avoid ASN.1
* Avoid expensive public-key operations in authentication mechanism

		- Chris