Subject: Crypto agility in SCRAM + draft-josefsson-password-auth?

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Mar 2008 17:05:31 +0100

While thinking about merging SCRAM with my document, I thought about how
to handle crypto algorithm agility.  To recap what we have today:

1) SCRAM hard code use of HMAC.  It only specify MD5 today.  It has
extensibility to allow for other hashes (the "h=md5" variable), but
replacing HMAC is not possible.

2) In draft-josefsson-password-auth the core protocol doesn't care about
which crypto algorithm is used.  It lets the GSS-API OID infer which
crypto parameters are used.  The default and only specified algorithm at
this point is HMAC-SHA-256.  It is possible to specify an HMAC-SHA1, or
OMAC-based, profile by using a new OID, and be consistent with my draft.

My initial reaction when merging my ideas with SCRAM is that it would be
nice to have more complete crypto agility in SCRAM.  In other words,
allow not only the hash be specified but also the entire authentication
algorithm (e.g., HMAC, OMAC), as I did in password-auth.

Over the weekend I had a chance to reflect on this.  I have changed my
mind and now believe that it would be nicer to avoid having to specify
and describe crypto negotiation in the mechanism.

The primary reason is that both SASL and GSS-API are flexible protocols
in themselves and can negotiate between mechanisms of different
strengths.  There is no strong need for SASL mechanisms or GSS-API
mechanisms to have crypto agility, as far as I can tell.

Further, the complexity in DIGEST-MD5 compared to CRAM-MD5 stems
(partially) from having to negotiate various things.  The more we can
avoid having to negotiate, the simpler the wire protocol becomes.  The
specification becomes less complex as well.  The crypto negotiation is
not different from character set or security layer negotiations in this
aspect.

If we hard code the crypto mechanism, and the underlying crypto is
broken, we would need to publish a new document that is a search-replace
s/HMAC-MD5/XMAC-SHA3/ or whatever.  It would have a new SASL mechanism
name and a new GSS-API object identifier.  This can be simpler than
specifying a "profile" or "extension" of the base protocol, which needs
to handle backwards compatibility issues and upgrade to a new algorithm.

This approach also allows the framework (i.e., SASL and GSS-API) to be
able to quantify the strength of the mechanism better.

Thus my suggestion is to hard code the crypto algorithm in SCRAMng,
following the simplicity of CRAM-MD5.

What do others think about this proposal?

Am I missing some reason to offer crypto agility in the SASL or GSS-API
mechanism, that gives any value compared to re-using the mechanism
agility already present in SASL and GSS-API?

As for the mechanism to use, I would prefer HMAC-SHA1 or HMAC-SHA256
over HMAC-MD5.  I think there are some arguments for moving away from
HMAC, and use things like OMAC, but I don't think this mechanism is the
best place to experiment with that.

I want to stress that I think the choice of a particular algorithm is
less important than the larger design approach question outline in this
email, though.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Mar 2008 12:03:41 -0500

> to handle crypto algorithm agility.  To recap what we have today:

Funny you should ask.  Sam and I, while discussing how to represent
SCRAM+GS2 in ABNF, both agreed that the hash function used by SCRAM
should be part of its OID.

We also agreed that SCRAM should use PBKDF-2 instead of that Hi()
function (PBKDF-2 does nto add much complexity).

I need to finish writing up the text to go with that ABNF...

> replacing HMAC is not possible.

I've seen no reason to think that the HMAC construction is insecure or
will be any time soon such that simply using a stronger hash function
won't suffice.

Sure, it could happen, but then, if the hash can be negotiated via
standard SASL mechanism negotiation, then so should the MAC.

> and describe crypto negotiation in the mechanism.

That's exactly the right thing to do.

> not different from character set or security layer negotiations in this

I agree, fully.

> able to quantify the strength of the mechanism better.

And it avoids multi-layer negotiation issues.  It makes the list of
mechanisms longer.  And so it may make things seem more complicated.

In particular putting algos into the mech name/OID may leak into user
visible UIs in ways that may not seem helpful.

E.g., imagine that we did this for the krb5 GSS mech, and so for
RPCSEC_GSS, so then when sharing via NFS one would would have a larger
choice of RPCSEC_GSS triples to select from -- "share -o
sec=krb5-aes256-i,..." instead of "share -o sec=krb5i ...", say.

At first glance that's annoying, but on the other hand, it gives the
administrator (and user) better control over what algorithms are used.
That may be a good thing.  And we can always have a special alias in the
UI that refers to the set of mechanisms based on SCRAM/krb5/... but
without regard to algorithms.

> What do others think about this proposal?

Yes please.

> best place to experiment with that.

Absolutely.  No more MD5 anywhere.

> less important than the larger design approach question outline in this

More agreement.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Mar 2008 12:13:18 -0500

Also, one thing I've been wanting is a notion of optional domain or
realm for SCRAM.

The motivation is to allow per-{user, domain/realm} enrolment and the
domain to then distribute verifiers to various servers, where each
verifier is distinct from the others and cannot be reversed to recover
the domain/realm verifier/generator nor any of the other servers'
verifiers.

If the client knows the domain/realm, then it works that into the key
derivation hierarchy and asserts the domain/realm in its first and
second messages to the server.

Else the server asserts a domain/realm in its first message to the
client and the client decides whether that's OK (keep reading), derives
keys, and goes on.  The way the client decides whether a server-asserted
domain/realm is OK is as follows: if the domain/realm == server name
then it's OK, else it will need to use local policy to decide whether to
go on, prompt the user, or fail (with a reasonable default).

Nico
--

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 17 Mar 2008 19:38:43 +0100

> What do others think about this proposal?

Strong ACK, no complex variants, folks wishing SHA-2* should get a
SASL mechanism, I'd like to see MD5, that can get a different name,
and offering an alternative to HMAC deserves its own draft with
its own security considerations explaining "why".  Skip SHA-1, for
true believers in SHA-* that's too soon obsolete (2010).   And for
folks wanting a "free" algorithm nothing is wrong with HMAC-MD5.

 Frank

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 17 Mar 2008 16:12:05 -0400

>> not different from character set or security layer negotiations in this

+1

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 00:11:15 +0100

> should be part of its OID.

Great.

> function (PBKDF-2 does nto add much complexity).

I have suggested PBKDF-2 to the SCRAM authors as well.

> without regard to algorithms.

I'm not sure the comparison with Kerberos is fair since Kerberos has
internal encryption strength negotiations.  Anyway, until we know this
algorithm leakage is a disadvantage, let's assume it is an advantage. ;)

> Absolutely.  No more MD5 anywhere.

I tend to agree, but I'm not aware of any scientific papers that
suggests HMAC-MD5 is weak.  There is a recent paper that says, IIRC,
that HMAC is stronger than we thought it was, even when used with a
somewhat weak hash function.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 00:24:22 +0100

"Frank Ellermann" <[email-masked]> writes:

> Strong ACK, no complex variants

That makes three in favor so far.

> folks wishing SHA-2* should get a SASL mechanism, I'd like to see
> MD5, that can get a different name, and offering an alternative to
> HMAC deserves its own draft with its own security considerations
> explaining "why".  Skip SHA-1, for true believers in SHA-* that's too
> soon obsolete (2010).  And for folks wanting a "free" algorithm
> nothing is wrong with HMAC-MD5.

There is some progress on HMAC attacks [1].  Are there any comments on
the quality of that paper?

SHA-1 is not covered by the SHA-2 patent as far as I have understood.

/Simon

[1] http://homes.esat.kuleuven.be/~kjongsun/papers/scn02006.pdf

---

From: Chris Newman <[email-masked]>
Date: Mon, 17 Mar 2008 17:48:14 -0700

I support use of HMAC.  CRAM-MD5 demonstrated it is deployable in apps, 
there are published test vectors in RFCs for it we can reference, and 
although the security benefit is not overwhelming IMHO, it has clear 
benefits due to the attacks on concatenated hashes.

I am not convinced the security value of PBKDF-2 offsets the additional 
complexity it adds.  Remember there is negative security benefit if we use 
PBKDF-2 and the additional complexity pushes the mechanism over the edge 
into the "not worth implementing" category.  It may be not a lot of 
complexity, but every bit matters.

I support using the mechanism name for algorithm agility and not having 
sub-negotiation.  This is a tradeoff.  The sub-negotiation occurs after the 
user is identified so it provides significant usability enhancements when 
it's actually necessary to perform an algorithm migration.  However, in 
retrospect I believe the complexity cost to the mechanism outweighs the 
benefit.  It's more important to get a mechanism we can deploy now and work 
out the operational details of hash migration later.  The additional 
complexity of sub-negotiation for the hash adds too much risk the mechanism 
won't deploy.  It doesn't matter how usable the hash migration happens to 
be if the mechanism doesn't deploy.

While I would personally be fine with abandoning MD5 in favor of SHA1 given 
my code toolkit has both algorithms, I'm concerned about the impact. 
Everyone's code toolkit includes MD5, but use of SHA1 is quite rare in 
applications at the moment.  Switching away from MD5 will create a 
deployment barrier.  Again, it doesn't matter how much more secure SHA1 is 
than MD5 if the SHA1-based mechanism doesn't deploy and an MD5-based one 
might have deployed.  I'd like to hear from other SASL implementers before 
making a firm decision on this one: do you have SHA1 in your code toolkit? 
If not, how hard would it be to add it and would that be a deployment 
barrier?

		- Chris

---

From: Chris Newman <[email-masked]>
Date: Mon, 17 Mar 2008 17:56:44 -0700

I am opposed to this suggestion, leaning in the direction of strongly 
opposed.

This is one of the sources of interoperability problems for DIGEST-MD5 
(client implementers didn't understand what the domain/realm meant).

It makes the client UI more complex and thus creates a significant 
complexity barrier (far more significant than any of the crypto algorithm 
issues).

If the domain matters, users can just use an email-style login identifier 
(e.g., [email-masked] as my login identifier).

		- Chris

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 02:12:48 +0100

Chris Newman <[email-masked]> writes:

> I am not convinced the security value of PBKDF-2 offsets the
> additional complexity it adds.  Remember there is negative security
> benefit if we use PBKDF-2 and the additional complexity pushes the
> mechanism over the edge into the "not worth implementing" category.
> It may be not a lot of complexity, but every bit matters.

Implementing PBKDF-2 is easy:

http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/gc-pbkdf2-sha1.c;hb=HEAD

You can find PBKDF-2 implemented in some crypto toolkits.  Using such
toolkits may reduce implementation complexity in some environments.

There are test vectors available for PBKDF-2 and also source code
examples.  Neither is available for the Hi(HMAC()) idea in SCRAM, as far
as I can tell.

> While I would personally be fine with abandoning MD5 in favor of SHA1
> given my code toolkit has both algorithms, I'm concerned about the
> impact. Everyone's code toolkit includes MD5, but use of SHA1 is quite
> rare in applications at the moment.  Switching away from MD5 will
> create a deployment barrier.  Again, it doesn't matter how much more
> secure SHA1 is than MD5 if the SHA1-based mechanism doesn't deploy and
> an MD5-based one might have deployed.  I'd like to hear from other
> SASL implementers before making a firm decision on this one: do you
> have SHA1 in your code toolkit? If not, how hard would it be to add it
> and would that be a deployment barrier?

In my experience, these days SHA-1 is as widely available as MD5.  Any
applications that implement TLS has a SHA-1 implementation somewhere.
Certainly my SASL library has no problem using SHA-1.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 02:20:31 +0100

I'm curious whether using a username that looks like user@realm would
solve Nico's concern, or whether there is something that really needs
protocol semantics?

I agree with Chris that realm handling causes significant user interface
and API complexity for a password-based mechanism.  Password-handling
systems like PAM doesn't understand what a realm is, and they are used
beneath a SASL library sometimes.  I always regarded realms as a
underspecified area of DIGEST-MD5, because the semantics and intended
use of it was never fully described.

Without more justification that the complexities of realms are needed in
this context, I think we are better of without it.

/Simon

Chris Newman <[email-masked]> writes:

> complexity barrier (far more significant than any of the crypto
> algorithm issues).
>
> If the domain matters, users can just use an email-style login
> identifier (e.g., [email-masked] as my login identifier).
>
> 		- Chris
>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Mar 2008 21:35:27 -0500

> (e.g., [email-masked] as my login identifier).

This is not about a domain in the username!

This is about enrolling in a realm so that many servers in that realm
can authenticate the same users but without being able to impersonate
those users to any other servers in that realm.

Without this feature the only way to do the above is by having the
servers authenticate to a realm server, pass through SCRAM messages and
then get the results from the realm server.

Not being able to enroll once but authenticate to many servers seems
obnoxious.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Mar 2008 21:49:11 -0500

> complexity, but every bit matters.

It adds very little additional complexity.  Give it a second read...

> my code toolkit has both algorithms, I'm concerned about the impact. 

Consider the possibility of widespread deployment.  Then will come the
FIPS certification requests, then we'll hate MD5.

> Everyone's code toolkit includes MD5, but use of SHA1 is quite rare in 

I don't believe that people don't have SHA-1.  On Linux?  On Solaris?
On Windows?  On *BSD?  And bindings to most populate languages?  With
most or all of the top FOSS licesnses (GPL, BSD, MPL, ...)?  I haven't
looked at all of them, but I'll eat a shoe (OK, maybe I won't eat a
shoe, but I'll buy a round of beers) if any major OS doesn't have it :)

I don't know enough about embedded devices, but I imagine J2ME, for
example, must have SHA-1 support by now.

Incidentally, for a mechanism like SCRAM deploying a new hash implies
re-enrolling all users (alternatively: the enrolment site keeps all
passwords in the clear; ugh).  This is one reason why picking a good
hash now matters.

> If not, how hard would it be to add it and would that be a deployment 

I'd also like to hear about embedded environments...

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Mar 2008 21:50:19 -0500

> solve Nico's concern, or whether there is something that really needs

No, this isn't about naming.  See my reply to Chris.

---

From: Steven Simon <[email-masked]>
Date: Mon, 17 Mar 2008 20:01:34 -0700

If I understand this deployment issue correctly, there is a single  
provisioning server that
converts the cleartext to realm-bound hashes that can be distributed  
to each server
providing a service?

If that's the case, manipulating the salt value should prevent the  
hash on one server
from being used to gain access to another.

I cringe at the idea of hashing a realm or username into the password  
hash.
The classic problem with DIGEST-MD5 is that sites must force massive  
password
changes to rename a realm or bring new realms online. Updating a  
username is
a hassle too (people get married from time to time).

As a result, most sites end up storing reversible passwords which  
defeats the whole
idea of a verifier.

My other concern is that if the server that receives the verifier  
can't be trusted, there is already
a problem. Any verifier can be attacked offline and cracking the  
password is ultimately only
a matter of the utility bill.

For this type of distribution style for authentication, I tend to  
think a password server
or PKI is in order.

- Steven

On Mar 17, 2008, at 7:35 PM, Nicolas Williams wrote:

>> algorithm
>> identifier

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 18 Mar 2008 07:56:47 +0100

Simon Josefsson wrote:

> There is some progress on HMAC attacks [1].
> Are there any comments on the quality of that paper?

Put them in a draft, please, when you find them.
 
> SHA-1 is not covered by the SHA-2 patent as far as

The patent is not the issue, the certification is.
Please correct me if I got this wrong, but I think
the plan is to find a new "good" hash until 2012,
and to phase out SHA-1 until 2010.  For some value
of "good" not yet published in an Internet draft.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 18 Mar 2008 08:27:08 +0100

Chris Newman wrote:
 
> CRAM-MD5 demonstrated it is deployable in apps

+1
 
> I am not convinced the security value of PBKDF-2
> offsets the additional complexity it adds.

Without asking Google or similar tricks, I have
not the faintest idea what "PBDKDF-2" is.  Is it
worse than "APR1" ?  That is where I'd draw the
line, scripts taking a minute to shuffle 128 bits
on low end platforms are a PITA.

> It may be not a lot of complexity, but every 

I'm more interested in nanoseconds than in bits,
but I guess that means we agree.

> Everyone's code toolkit includes MD5, but use
> of SHA1 is quite rare in applications at the
> moment.  Switching away from MD5 will create a 
> deployment barrier.

+1  I don't think SHA-1 is still rare, but it is
a known dead end, and using MD5 as least common
denominator makes sense.  Very unfair comparison,
MD5 : SHA-1 : xxx ~ ftp : gopher : http

> it doesn't matter how much more secure SHA1 is 
> than MD5 if the SHA1-based mechanism doesn't
> deploy and an MD5-based one might have deployed.

SHA-1 shuffles a few more bits.  I'm mystified 
when say RFC 4122 claims that UUID v5 with 123
bits entropy is "better" than UUID v3 with the
same number of bits, only because v5 uses SHA-1.

After that they go to publish one example using
v3 and apparently get it wrong, in an RFC, and
in an equivalent ITU standard.  

 Frank

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 18 Mar 2008 15:31:03 +0100

Nicolas Williams writes:
> Incidentally, for a mechanism like SCRAM deploying a new hash
> implies re-enrolling all users

SCRAM-HMAC-MD5 implies it if that's what you mean.  SCRAM with
negotiated hash does not, it allows a mixture of new-hash and old-hash
accounts.  With a site policy to delete X days old passwords, the old
hash gets phased out as a side effect and most users won't even notice.

That's a problem with SASL deployment in general though.  When the day
comes for a site to replace SCRAM-HMAC-MD5, it might be in favor of a
non-SCRAM mechanism.  Then it doesn't matter whether or not SCRAM
supports hash algorithm negotiation.

It might make sense to instead define a "wrapper" auth mechanism: The
client sends (user, supported mechanisms), receives a challenge with the
desired mechanism name for that user, and then proceeds with that
mechanism.  Costs one round-trip extra and likely complicates the
security considerations.

> (alternatively: the enrolment site keeps all passwords in the clear;
> ugh).

Not that bad.  The enrolment site keeps public-key encrypted passwords
and locks the private key down in dark dungeon.  Though I imagine the
practical side can still be a pain, e.g. to keep the dungeon dark enough
and be able to formally claim that it is.

-- 
Hallvard

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 16:40:03 +0100

> of "good" not yet published in an Internet draft.

I'm not sure I follow this logic -- MD5 is in an even worse state than
SHA-1 is in this regard.  It is not certified at all, right?  Haven't
people been trying to phase out MD5 since Dobbertin's attack in 1996?

I think our choice should be between HMAC-SHA-1 and HMAC-SHA-256.  I
don't think there are strong technical reasons to chose one over the
other at this point.  I used HMAC-SHA-256 for password-auth.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 16:52:49 +0100

> Not being able to enroll once but authenticate to many servers seems

I think this is out of scope for a simple password based password
mechanism.

If you have an infrastructure like the one you describe, either Kerberos
(if you prefer symmetric encryption) or TLS+EXTERNAL (if you prefer
asymmetric encryption) seems like a better approach to me.

If you really want to achieve something like you want, wouldn't the
following work?  Enroll the user once, and then ask the user to use a
username like [email-masked]', [email-masked]' for each of the
servers in that realm.  The enrollment process could push out the
password-equivalent hash to each server.

In my experience, the realms feature was not used widely with
DIGEST-MD5, but made the specification more complex.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Mar 2008 11:04:13 -0500

> hash gets phased out as a side effect and most users won't even notice.

I don't agree.  SASL apps typically know how to negotiate SASL
mechanisms, so as long as the negotiation happens *somewhere* then you
can migrate.

My point was not about negotiation of hashes, but about what it means
from a user provisioning perspective.

One day your servers all have SCRAM HMAC-MD5 verifiers for your users'
names and passwords.  The next you want to move to SCRAM HMAC-SHA-224,
but you don't have any of those verifiers.  How do you complete the
migration, operationally?

Answers: somehow the users have to either re-enroll (kinda like changing
their passwords) or they have to somehow convey their new verifiers to
the servers.

So one thing we'll need is a flag from the server to the client saying
"you need to re-enroll" and/or "your password is expired."

> supports hash algorithm negotiation.

Putting the hash negotiation inside SCRAM doesn't help you with that.

> mechanism.  Costs one round-trip extra and likely complicates the

One problem with what you suggest is that I think you'll find the
community to be averse to creating more multi-level negotiation schemes.
We've learned from SPNEGO -- we've learned that we don't like it :(
Another problem is that it throws the possibility of privacy protection
for client names out the window (assuming we had PKIX-based mechanisms
that could provide such privacy protection); this is a much lesser
problem.

If there's any negotiation that really must be solved in a new way it
would have to be the "{mechanism, federation/island of trust}" problem.

> and be able to formally claim that it is.

Right.  I'm sure some operators will reject this option, so we need a
way to deal with that (see above).

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Mar 2008 12:07:14 -0400

> asymmetric encryption) seems like a better approach to me.

Except the point is to _not_ have a central authentication server which 
must be online and accessible for logins to succeed.  We're talking about a 
situation in which there may not be much "infrastructure" at all; just a 
bit of automation that pushes out new hashes to all the servers when a user 
is added or a password is changed.

> password-equivalent hash to each server.

OMG no.  What you're suggesting is telling users to enter a different 
username based on which server the load balancer connects them to.  Since, 
depending on the load balancer in use, the client may not even know this, 
it is unreasonable to expect it.  And really, it's creating a UI nightmare 
and more deployment pain in the name of making protocol design and 
implementation easier, and that's backwards.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Mar 2008 11:09:59 -0500

> I think our choice should be between HMAC-SHA-1 and HMAC-SHA-256.  I

I agree.

> other at this point.  I used HMAC-SHA-256 for password-auth.

Well, I think there are strong reasons to prefer SHA-256 over SHA-1: the
existence of more attacks against SHA-1, the fact that SHA-1 will be
considered obsolete in ~two years time.

The main reason for preferring SHA-1 over SHA-256 is that
implementations of the former are probably more widely available than of
the latter.

We can always specify multiple hash functions, make SHA-1 and SHA-256
MUST implement and RECOMMEND SHA-256.  This means that implementors
without suitable SHA-256 libraries will be "non-compliant" but their
code will still be deployable, but at least we get a future-proof
mechanism (for some values of "future-proofing").

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Mar 2008 11:14:10 -0500

> asymmetric encryption) seems like a better approach to me.

Hmmm, I think I can live with this answer, but I also think that a SCRAM
with this option will have sufficiently different properties from
Kerberos that in many case it could be preferable (specifically: no
online infrastructure requirement for the client).

> password-equivalent hash to each server.

Ick.

> DIGEST-MD5, but made the specification more complex.

OK, I withdraw this proposal.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Mar 2008 11:21:41 -0500

> on low end platforms are a PITA.

If you're an implementor then reading the relevant spec (RFC2898, "PKCS
#5: Password-Based Cryptography Specification Version 2.0", section 5.2
-- slightly over one page of text), IMO, is really in order before
claiming that it's too complex.

> but I guess that means we agree.

Oh stop it :), read the spec, notice that PBKDF2 is not much more
complex than Chris' Hi(), and go from there.  Both, Chris' Hi() and
PBKDF2 have an iteration count, so the speed of execution is intended to
be variable.

> MD5 : SHA-1 : xxx ~ ftp : gopher : http

MD5 is much more a dead end than SHA-1.

Nico
--

---

From: Tony Finch <[email-masked]>
Date: Tue, 18 Mar 2008 16:21:49 +0000

> migration, operationally?

The usual way to avoid too much interaction with users is to instrument
the authentication process to capture passwords verified by the old
mechanism and re-encode them using the new mechanism.

> Putting the hash negotiation inside SCRAM doesn't help you with that.

It depends on whether clients are good at automatic fail-over from one
SASL mechanism to another. If you negotiate the algorithm after you know
who the user is, the server can advertise different algorithms for
different users, and advertise only the algorithms that have a chance of
working, so client-side fail-over isn't required.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
MALIN HEBRIDES: MAINLY NORTH OR NORTHWEST 3 OR 4, OCCASIONALLY 5. SLIGHT OR
MODERATE, OCCASIONALLY ROUGH. SHOWERS. GOOD.

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 18 Mar 2008 17:31:05 +0100

Simon Josefsson wrote:

> I think our choice should be between HMAC-SHA-1 and HMAC-SHA-256.

I'll ignore it then.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Mar 2008 11:29:55 -0500

> mechanism and re-encode them using the new mechanism.

Right, that's one of the ways I considered.  Both of the answers I
suggested require additional bits on the wire in SCRAM.

> > > [...]

Ah, good point.  Without a hash negotiation inside SCRAM you have to
effectively deploy verifiers for all your users before you start
advertising the SCRAM with new hash functions.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Mar 2008 12:51:01 -0400

--On Tuesday, March 18, 2008 11:21:41 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

># 5: Password-Based Cryptography Specification Version 2.0", section 5.2

Or FTP, for that matter. :-)

The comparison is not "unfair"; it's simply "wrong".

Frank, I really wish you would stop spreading FUD.  If you have it in your 
head that SHA-1 and/or people who promote its use are evil, feel free to 
ignore it, remain stuck in the 20th century, and fail to interoperate with 
anyone.  In the meantime, the rest of us are getting on with life.

The IETF security area has a mandate to avoid use of MD5 in new protocols, 
in favor of SHA-1 or SHA-256 plus hash agility.  That doesn't (yet) apply 
to HMAC-MD5, because the HMAC construction is believed to be sufficiently 
strong, but mandating the use of HMAC-MD5 in new protocols will eventually 
turn into a requirement to implement MD5 in code that otherwise wouldn't 
need it.  That's OK for people using big crypto toolkits which have it 
anyway, but likely not for embedded devices with limited storage.

-- Jeff

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 18 Mar 2008 18:01:10 +0100

> mechanisms, so as long as the negotiation happens *somewhere* then you

Are we talking about different things?

User A: server secret (mech SCRAM: (hash MD5:  (salt s, ...))
User B: server secret (mech SCRAM: (hash SHA1: (salt t, ...))

The client sends auth(SCRAM, user A, <supports: MD5,SHA1,DES>)
and receives server challenge (MD5, nonce, salt s, etc).

vs:

User A: server secret (mech SCRAM-HMAC-MD5:  (salt s, iter 128, etc)).
User B: server secret (mech SCRAM-HMAC-SHA1: (salt t, iter 160, etc)).

The server announces support for SCRAM-HMAC-MD5 and SCRAM-HMAC-SHA1, but
the client doesn't know which is stored for that user, the admin doesn't
want it or him to need to know either beyond "SCRAM", and the server
response to one SASL mechanism doesn't tell which other mechansism to
try instead for that user.

So "negotiating" the hash function must consist of trying each mechanism
both client and server supports until one of them works.  Which also
interferes with "allowed failed login attempts" policy.

Or one could implement some other way to ask the server which mechanism
to use for that server, which loses the advantage of using SASL in the
first place.

> from a user provisioning perspective.

Yes...

> "you need to re-enroll" and/or "your password is expired."

Yes.  And if accounts using old and new style hashes can coexist, we
don't need to tell everyone to re-enroll at the same time.  Instad we
can relay on password expiry policy which ought to be in place anyway.

> Putting the hash negotiation inside SCRAM doesn't help you with that.

Yes, that's what I said.  It helps if both variants are SCRAM, but not
otherwise.

> We've learned from SPNEGO -- we've learned that we don't like it :(

Too bad.  Then my objection is stronger than I hoped...  Not sure
how strong though.  I haven't implemented SASL myself, so I don't know
about the complexity issues people are talking about.

> that could provide such privacy protection); this is a much lesser

In this case, how?  If you mean it discloses the existence of a user, so
does trying to auth as that user with a particular SCRAM mechanism.
Unless the server sends a challenge which looks like the user exists
whether he does or not - which again can be done in both cases.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 18 Mar 2008 18:15:32 +0100

> to use for that server, which loses the advantage of using SASL in the

sorry,   for that _user_ of course.

> first place.

Though I notice Tony has already answered anyway.

-- 
Hallvard

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 18:15:17 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> Except the point is to _not_ have a central authentication server
> which must be online and accessible for logins to succeed.  We're
> talking about a situation in which there may not be much
> "infrastructure" at all; just a bit of automation that pushes out new
> hashes to all the servers when a user is added or a password is
> changed.
>
> username based on which server the load balancer connects them to.
> Since, depending on the load balancer in use, the client may not even
> know this, it is unreasonable to expect it.  And really, it's creating
> a UI nightmare and more deployment pain in the name of making protocol
> design and implementation easier, and that's backwards.

Sure.  Ok.  Let me see if I understand this properly.

The usage scenario is that you are load-balancing a particular service
(e.g., IMAP or outgoing SMTP), and you don't have a central
authentication server?

The threat model is that you want to avoid that an successful attack on
one of the servers, where the attacker collects the password-equivalent,
enables the attacker to use that information to impersonate the user on
one of the other servers?

If that is the entire problem we want to solve, I think there are much
simpler solutions than introducing a realm concept.  Just make the
server-side password-equivalent unusable as a client-side
password-equivalent.  Is there any problem with that solution?

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 18:21:44 +0100

> online infrastructure requirement for the client).

If I understand your scenario, it may be that it can be solved easily
with unmodified SCRAM, see my response to Jeff.

>> password-equivalent hash to each server.

That is what I do in one (small) environment.  It is simple and works
fairly well.  It is not a load-balancing setup though, where I admit
this approach would not work well.

> OK, I withdraw this proposal.

I'm not strongly opposed to realms, but if it leads to complexity in the
protocol, I think we should motivate it carefully.

The complexity in DIGEST-MD5 was not sufficiently motivated, neither in
the specification nor by real-world requirements, in my opinion.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 18:38:45 +0100

> mechanism (for some values of "future-proofing").

One argument in favor of SHA-1 could be that SHA-1's total life-time in
service (1995-2010?) appears likely be longer than what SHA-256's total
life-time in service will be (2002-?).  I assume that once the SHA-3
competition is finished, that SHA-2 will be deprecated.

The total life-time in service corresponds to the amount of security
critical purposes the hash is used for.  Which consequently corresponds
to the amount of time researchers spend on trying to attack it.  That is
the best measure on a cryptographic algorithm's quality that we can use
in the IETF, I think.

On the other hand, this assumes that one year of cryptographic research
time in 1995 is worth as much as one year of cryptographic research time
in 2008, which isn't true.

I don't think we should specify both, it will cause interop problems.

I would be fine with HMAC-SHA-256.  It will take at least one year until
this RFC is published (if we are optimistic) and then it is even more
likely that all relevant platforms will have SHA-256.

/Simon

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 18 Mar 2008 18:42:54 +0100

> protocol, I think we should motivate it carefully.

As far as I can tell, a realm is nothing but a salt common for all
users on the server.  SCRAM supports a salt.  Am I missing something?

-- 
Hallvard

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 18 Mar 2008 18:52:53 +0100

Jeffrey Hutzelman wrote:

> The IETF security area has a mandate to avoid
> use of MD5 in new protocols, in favor of SHA-1
> or SHA-256 plus hash agility.

That must be a BCP I have not read yet, which is
it ?  I recall that I looked into RFC 2898 some
time ago, but as there was no test case for its
MD5 PBKDF1 forgot it again.

I asked here at least once why Hi(x) = H(Hi-1(x))
should be "better" than Hi(x) = H( i || x ) or
similar.  I've no idea why Nichoas thinks that I
like Hi(), or why he thinks that I claim that it
is faster than PBKDF2 when all I did was ask what
PBKDF2 is.   

Without examples RFC 2898 is not interesting for 
me, it also doesn't explain in which sense if any
HMAC-SHA1 is "better" than HMAC-MD5 when used as
PRF for PBKDF2.

> In the meantime, the rest of us are getting on
> with life.

If that means that CRAM-MD5 is good enough, fine.

 Frank

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 18:52:55 +0100

Hallvard B Furuseth <[email-masked]> writes:

> users on the server.  SCRAM supports a salt.

That's what I tried to describe in many more words in my message to
Jeff.

> Am I missing something?

I'm with you, I think SCRAM already supports this model.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Mar 2008 13:15:43 -0500

> this approach would not work well.

Then no, that's not a good answer (see Jeff's reply as to why).

The use case is not load balancing (as you asked in your other e-mail
just now) but a large site with many distinct services that users may
need to authenticate to.

> > OK, I withdraw this proposal.

We can always do a new mechanism that has this functionality if it turns
out we need it, and in the meantime Kerberos V is a decent answer for
those who need such functionality _now_.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Mar 2008 13:17:24 -0500

> users on the server.  SCRAM supports a salt.  Am I missing something?

It's a bit more than that: it's an extra layer in the key hierarchy.
And that's so that the realm can generate the verifiers for all users
for any new server without having to know the cleartext passwords.

But again, the point is moot.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Mar 2008 13:25:11 -0500

> the best measure on a cryptographic algorithm's quality that we can use

Whereas I think that consensus is the best "measure of a cryptographic
algorithm's quality that we can use in the IETF."

Look, if a paper comes out tomorrow that shows a reduction in strength
of SHA-1 to the point that it's worthless, then all those "years in
service" will no longer be a useful measure of SHA-1's strength.

IETF consensus on these issues will have to be informed by cryptographer
consensus, and by what non-cryptographers can understand the state of
the art and the trends to be.  That's much too subjective, yes, but
"years in service" is only deceptively objective.

> in 2008, which isn't true.

Exactly!

> I don't think we should specify both, it will cause interop problems.

None that we didn't already know we'd have as a result of having hash
agility in the first place.

> likely that all relevant platforms will have SHA-256.

I can agree with that.  I don't think Chriss will like that answer
though.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 20:19:16 +0100

> service" will no longer be a useful measure of SHA-1's strength.

Then the researchers aren't "trying to attack it" anymore, they have
succeeded. ;)

> "years in service" is only deceptively objective.

Sure.

> agility in the first place.

True.  Hm.  Perhaps specifying both actually isn't such a poor idea.

Can we get away with specifying both SCRAM-SHA1 and SCRAM-SHA224 and say
that servers MUST support both and clients MAY support either?

> I can agree with that.  I don't think Chriss will like that answer

I feel the same, but I wonder what platforms Chris works with where even
SHA-1 could be a problem.  When we get the published specification
deployed, I wouldn't be surprised if SHA-1 wasn't already officially
deprecated.

/Simon

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 18 Mar 2008 20:41:46 +0100

> that servers MUST support both and clients MAY support either?

I don't see what good that does.  The server MUST support both, likely
only one password hash is _stored_ in it.  A client which only supports
the other can't authenticate.

You can say that clients MUST support both and servers MAY support
either.

-- 
Hallvard

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Mar 2008 15:21:20 -0500

> > that servers MUST support both and clients MAY support either?

I think you can say that the server MUST implement both and the client
MUST implement at least one.  (I think that's what you meant.)

> the other can't authenticate.

Right, we'd have to say that the server must also store both sets of
verifiers and credentials.

> You can say that clients MUST support both and servers MAY support

That too, but I think Simon is arguing that SHA-* are probably available
on all server platforms, but not necessarily on all clients, so by
giving the client a choice we may improve deployability without making
it too hard to drop one of these hash functions later.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Mar 2008 15:23:24 -0500

> > I think our choice should be between HMAC-SHA-1 and HMAC-SHA-256.

You're free to.  There's no IETF compliance police you know :)

If we say "MUST implement HMAC-SHA-256" and everyone else deploys only
HMAC-MD5, then we'll either wait long enough that everyone has upgraded
and then declare victory, or we update the RFC to say "we got it wrong
and it is now MUST implement HMAC-MD5."

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 18 Mar 2008 21:55:11 +0100

> verifiers and credentials.

No thanks.  "The server implementation SHALL NOT allow a user's
SCRAM-SHA224 or SCRAM-SHA1 credentials to be stored, deleted or replaced
without also updating the other one".  I don't want that bit of code in
the server.  Nor do I want to define it as a user error to only store
one of the values, if the server silently accepts it.

One could define a combined (sha1, sha224) server secret so it can be
administered and e.g. stored in an LDAP attribute as a single value.
Also fairly ugly.

> it too hard to drop one of these hash functions later.

Tradeoff between deployability and interoperability, then.  I prefer
Simon's suggestion over mine or yours.  No opinion of whether that's
better than requireing a single mech.

But come to think of it, which spec are we talking about now?  A
mechanism "SCRAM" spec with a hash function parameter, like before?  Or
a SASL implementation in general?  For the latter my objections are moot
because server admins have enough options to create interoperability
anway.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 18 Mar 2008 22:17:44 +0100

> because server admins have enough options to create interoperability

Typo, I meant "enough options to create NONinteroperability":-)

-- 
Hallvard

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Mar 2008 22:41:20 +0100

> MUST implement at least one.  (I think that's what you meant.)

Yes.

> verifiers and credentials.

Yes, I meant that too.

> it too hard to drop one of these hash functions later.

Exactly.

Server implementations could have very similar code for both SCRAM-SHA1
and SCRAM-SHA256 (not sure why I wrote SHA224 up there, nobody is
advocating for HMAC-SHA224, right?) and the shared secret for the user
stored in the database should contain both the SHA-1 and SHA-256
version.  The implementation must make guarantee consistency between the
two fields, never update the sha-1 password without also updating the
sha-256 password.

If this approach would ease Chris' concerns about SHA-2, I think it is a
reasonable compromise.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Mar 2008 20:45:46 -0400

--On Tuesday, March 18, 2008 01:15:43 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> > Hmmm, I think I can live with this answer, but I also think that a
>> > SCRAM with this option will have sufficiently different properties from
>> >> username like [email-masked]', [email-masked]' for each of
>> >> the servers in that realm.  The enrollment process could push out the

Load balancing isn't _the_ use case; it's an extreme example of why it's 
not reasonable to ask users to use a different username for every server. 
My users would scream bloody murder if we told them they had to use a 
different username for every service.

> For me though, the point is moot as I withdraw the proposal:

And I don't care enough to press it.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Mar 2008 21:10:30 -0400

> about the complexity issues people are talking about.

Nico is right, and not.  A mechanism-negotiating mechanism is generally a 
bad idea, except when it is the _only_ mechanism an application is allowed 
to use.  An application which does its own mechanism negotiation (as all 
SASL applications do) generally should not use mechanism-negotiation 
mechanisms.

However, there are some exceptions.  I don't see a problem with using a 
mechanism-negotiation mechanism such as you describe, provided that the set 
of mechanisms offered by the negotiation MUST be exactly the subset of the 
original offering which could work for the current user.  The theory here 
is that there are no mechanisms which are reachable only via the 
negotiation mechanism (as would be the case with, for example, GS2+SPNEGO) 
_and_ any mechanism in the original set which is not offered in the 
second-level negotiation wouldn't have worked anyway.

Similarly, I think providing hash negotiation within SCRAM rather than 
making the hash part of the mechanism name is not as bad as it sounds. 
This is similar to selecting a Kerberos mechanism and then having to agree 
on an enctype(*).  The client knows what algorithms it supports, and is 
capable of supporting any of them for any user.  The server knows for which 
algorithms it has a secret for this user.  If there is no overlap, then 
authentication with that mechanism isn't going to work, and doing 
negotiation at the next layer up isn't going to help.

In practice, I suspect that the vast majority of SASL application clients 
require the user to specify the mechanism to be used, and the question is 
only "can the server support the mechanism the user selected?".  If we ever 
want that to change, for example to support migration from DIGEST-MD5 to 
SCRAM or from SCRAM to some other password-based mechanism, the negotiation 
mechanism you describe might not be a bad idea.

(*) It's not actually identical, because in Kerberos this actually happens 
when a service ticket is issued by the KDC, which knows which enctypes a 
server supports.  In addition, a Kerberos application server's set of 
supported enctypes is not ever client-dependent (though the question of 
whether there is an overlap may be).  This means that for Kerberos, a 
clever client can try obtaining a service ticket _before_ mechanism 
negotiation, and not trying the mechanism if it couldn't get a ticket.

> whether he does or not - which again can be done in both cases.

Which seems to me like an entirely reasonable approach for people who are 
concerned about that issue.

-- Jeff

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 20 Mar 2008 13:41:02 +0100

> You're free to.  There's no IETF compliance police you know :)

Fortunately.  Others might be forced to consider NIST compliance:

| Only implementations of the SHA-1 that are validated by NIST
| will be considered as complying with this standard. Information
| about the requirements for validating implementations of this
| standard can be obtained from the National Institute of
| Standards and Technology, Computer Systems Laboratory, Attn: SHS
| Validation, Gaithersburg, MD 20899. 
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>

The statement in FIPS 180-2 is very similar, I found only a PDF.
Ditto the FIPS 180-3 draft published last year, export control,
required validation, patents, IANAL.

On <http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html>
they say:

| After 2010, Federal agencies may use SHA-1 only for the following
| applications: hash-based message authentication codes (HMACs); key
| derivation functions (KDFs); and random number generators (RNGs).
| Regardless of use, NIST encourages application and protocol
| designers to use the SHA-2 family of hash functions for all new
| applications and protocols.

From that I deduce that nothing is wrong with using SHA-1 in HMAC,
for obvious reasons this Web page won't say anything about using
MD5, but we have (admittedly old) RFCs saying that using MD5 with
HMAC is okay.

Folks wishing that their software can be used by federal agencies
are encouraged to use a validated SHA-2 anyway.  For these folks
SHA-1 is at best obsolescent.

Folks not interested in FIPS legalese and validation might prefer
to use something that is not SHA-anything, and decide that MD5
like SHA-1 is still good enough for HMAC + KDF + RNG.

> If we say "MUST implement HMAC-SHA-256" and everyone else
> deploys only HMAC-MD5, then we'll either wait long enough that
> everyone has upgraded and then declare victory, or we update
> the RFC to say "we got it wrong and it is now MUST implement
> HMAC-MD5."

Nothing is wrong with offering one of HMAC-SHA-256, -512, etc.
The fallacy is to offer SHA-1 as second choice instead of MD5,
because it makes technically + legally no sense for both groups.

 Frank

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Mar 2008 12:50:26 -0400

Chris> While I would personally be fine with abandoning MD5 in
    Chris> favor of SHA1 given my code toolkit has both algorithms,
    Chris> I'm concerned about the impact. Everyone's code toolkit
    Chris> includes MD5, but use of SHA1 is quite rare in applications
    Chris> at the moment.  Switching away from MD5 will create a
    Chris> deployment barrier.  Again, it doesn't matter how much more
    Chris> secure SHA1 is than MD5 if the SHA1-based mechanism doesn't
    Chris> deploy and an MD5-based one might have deployed.  I'd like
    Chris> to hear from other SASL implementers before making a firm
    Chris> decision on this one: do you have SHA1 in your code
    Chris> toolkit? If not, how hard would it be to add it and would
    Chris> that be a deployment barrier?

I don't think md5 should be used for a new mechanism.
Sha-1 is very widely available in C, Java and other languages.
I think you may get significant pushback in ietf last call to the use of md5 in something new; I I know I'll be part of that.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Mar 2008 12:47:05 -0400

>>>>> "Chris" == Chris Newman <[email-masked]> writes:

    Chris> I support use of HMAC.  CRAM-MD5 demonstrated it is
    Chris> deployable in apps, there are published test vectors in
    Chris> RFCs for it we can reference, and although the security
    Chris> benefit is not overwhelming IMHO, it has clear benefits due
    Chris> to the attacks on concatenated hashes.

I agree.

    Chris> I am not convinced the security value of PBKDF-2 offsets
    Chris> the additional complexity it adds.  Remember there is
    Chris> negative security benefit if we use PBKDF-2 and the
    Chris> additional complexity pushes the mechanism over the edge
    Chris> into the "not worth implementing" category.  It may be not
    Chris> a lot of complexity, but every bit matters.

I support some mechanism for taking a password and converting it to a
key that is generally accepted in the security community.  I would
strongly object to rolling our own.  Scram currently rolls its own;
pbkdf-2 is generally accepted.  If you can point to another generally
accepted mechanism that is simpler, we should consider it.

    Chris> I support using the mechanism name for algorithm agility
    Chris> and not having sub-negotiation.  This is a tradeoff.  

Is it?  I'm not sure sub-negotiation would be valuable for this
mechanism even if we could make it work.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Mar 2008 12:29:24 -0500

> mechanism even if we could make it work.

As discussed earlier in the thread, since the server knows what
verifiers it has for a given user, it would be useful for the hash
negotiation to happen inside the mechanism.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Mar 2008 14:30:54 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Fri, Mar 21, 2008 at 12:47:05PM -0400, Sam Hartman
    >> mechanism even if we could make it work.

    Nicolas> As discussed earlier in the thread, since the server
    Nicolas> knows what verifiers it has for a given user, it would be
    Nicolas> useful for the hash negotiation to happen inside the
    Nicolas> mechanism.

Ah, yes.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 31 Mar 2008 12:37:09 +0200

Jeffrey Hutzelman writes:
> (...)
> bad idea, (...)
> original offering which could work for the current user.

I think security requires that it can return one list of mechanisms
which will work and one with mechanisms which might work.  (Both subsets
of those reachable without mechanism-negotiation, as you say below.)

Otherwise the mechanism-negotiation mechanism could reveal information
which would not be revealed by the chosen mechanism.  (E.g. over an
unencrypted connection, with a mechanism which encrypts the exchange.)

The "might work" list would consist of all supported mechanisms which
would disclose information the admin(?) thinks should be hidden if they
were sent in the "will work" list, or something like that.
(If the user does not exist, the "will work" list could still contain a
suggested mechanism - where authentication would successfully fail:-)

> The theory here

> (...)

Except it seems much harder to do it than for an attacker to analyze it.
But my point here was just that I don't see the difference between SCRAM
and a mechanism-negotiation mechanism in this regard.  Unless i
misunderstood what Nico was talking about.

-- 
Hallvard

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 31 Mar 2008 11:01:19 -0400 (EDT)

> suggested mechanism - where authentication would successfully fail:-)

I haven't fully paged this discussion back in yet, but...

I don't think you actually want to distinguish between two lists, because
doing so provides no utility.  I agree that it should be OK to offer
mechanisms that won't actually work for this user.  Doing so increases the
chance that the client will choose one of those, causing authentication to
fail when it could have succeeded, but that's unlikely in practice because
often the client has been configured to expect a particular mechanism.

I believe there is a tradeoff between the "security" of not exposing
information about which mechanisms work for which users and the potential
interoperability problems caused by advertising mechanisms that won't
actually work.  It is appropriate for this tradeoff to be a matter of
policy.

Similarly, there is no problem advertising some set of mechanisms for a
user that does not actually exist, as a way of hiding information about
wich users exist.

-- Jeff

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 1 Apr 2008 16:44:12 +0200

> I haven't fully paged this discussion back in yet, but...

:-)

> I don't think you actually want to distinguish between two lists,
> because doing so provides no utility.  I agree that it should be OK to
> offer mechanisms that won't actually work for this user.  Doing so
> increases the chance that the client will choose one of those, causing
> authentication to fail when it could have succeeded, but that's
> unlikely in practice because often the client has been configured to
> expect a particular mechanism.

But the reason I suggested a mechanism-negotiation mechanism in the
first place was situations where different users have different
such as when the site is upgrading from an old mechanism.

If nothing else, a "will work" list can reduce the amount of user
interaction:  The client can use that right ahead, but ask the user
for help if there are only "might work" mechanisms.

Alternatively the client could try several "might work" mechanisms in
succession, but as I mentioned that can interfere with policy about
max allowed failed logins.  Or for that matter different mechanisms
can need different information from the user - and thus again more user
interaction than necessary.

The "might work" list might offer no utility when there is a "will work"
mechanism, if so a single list with a "will work"-flag is enough.

> actually work.  It is appropriate for this tradeoff to be a matter of

Yes.  I'd just like to inform the client what it can expect beforehand.

> user that does not actually exist, as a way of hiding information about

Well, there is: I still don't know how to do it right.  See my messages
"Hide presence/absence of users in server (HEXA, SCRAM)" of 30 Apr 2007.
But no extra problem compared with mech="SCRAM" with hash negotiation.

>>> second-level negotiation wouldn't have worked anyway.

Yup.

-- 
Hallvard