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

From: Alexey Melnikov <[email-masked]>
Date: Tue, 01 Apr 2008 17:22:47 +0100

Kurt Zeilenga wrote:

> A question came up off-list which I think needs to be explicitly  
> addressed in the charter text.
>     While the mechanism provide a security layer?
>
> From list discussions, I think the answer is:
>     The replacement mechanism is expected not to provide a security 
> layer  itself, instead rely on
>     security services provided at a lower layer (e.g., TLS) and 
> channel  bindings.

That is fine with me.
I might be in minority, but I would rather not have any text prohibiting 
development of a security layer.

> I recommend inserting this sentence just before "The WG is expected 
> to  strike..." and deleting the "channel binding" quality.

Sure.

> Also, as it is desirable to have a shorter list of qualities, I also  
> recommend deleting "algorithm agility" and "minimal roundtrips"  
> qualities.

Fine with me. Both are good practices, so we are unlikely to design a 
mechanism that maximizes the number of round trips, etc. ;-).

Date: Tue, 01 Apr 2008 17:22:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
CC: [email-masked]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
Sender: [email-masked]

Kurt Zeilenga wrote:

> A question came up off-list which I think needs to be explicitly  
> addressed in the charter text.
>     While the mechanism provide a security layer?
>
> From list discussions, I think the answer is:
>     The replacement mechanism is expected not to provide a security 
> layer  itself, instead rely on
>     security services provided at a lower layer (e.g., TLS) and 
> channel  bindings.

That is fine with me.
I might be in minority, but I would rather not have any text prohibiting 
development of a security layer.

> I recommend inserting this sentence just before "The WG is expected 
> to  strike..." and deleting the "channel binding" quality.

Sure.

> Also, as it is desirable to have a shorter list of qualities, I also  
> recommend deleting "algorithm agility" and "minimal roundtrips"  
> qualities.

Fine with me. Both are good practices, so we are unlikely to design a 
mechanism that maximizes the number of round trips, etc. ;-).

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 01 Apr 2008 18:07:13 +0200
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> writes:

> A question came up off-list which I think needs to be explicitly
> addressed in the charter text.
> 	While the mechanism provide a security layer?
>
> From list discussions, I think the answer is:
> 	The replacement mechanism is expected not to provide a
> security layer itself, instead rely on
> 	security services provided at a lower layer (e.g., TLS) and
> channel bindings.
>
> I recommend inserting this sentence just before "The WG is expected to
> strike..." and deleting the "channel binding" quality.

+1

> Also, as it is desirable to have a shorter list of qualities, I also
> recommend deleting "algorithm agility" and "minimal roundtrips"
> qualities.

I think crypto algorithm agility may be more harmful than useful, so +1.
SASL itself is crypto agile anyway.

/Simon

> Comments?
>
> -- Kurt
>
> On Mar 31, 2008, at 2:07 PM, Kurt Zeilenga wrote:
>>
>> I think the proposed charter text concerning DIGEST-MD5 to historic/
>> replacement should be replaced with
>> something like:
>>
>>  The group has determined that DIGEST-MD5 (RFC2831) is not suitable
>> for progression on the
>>  Standards Track due to interoperability, internationalization, and
>> security concerns.  The group will
>>  deliver a technical specification for a suitable password-based
>> challenge/response replacement mechanism
>>  for Standard Track consideration.  The replacement mechanism is
>> expected to be "better than" DIGEST-MD5
>>  from a number of perspectives including interoperability,
>> internationalization, and security.  The
>>  WG is expected to strike a consensus-supported balance between the
>> many qualities desired in the
>>  replacement.  Desired qualities include (but is not limited to):
>> 	- Use of well understood and broadly-implemented algorithms
>> (e.g., HMAC, SHA1),
>> 	- Algorithm agility,
>> 	- Negotiated key hardening iteration count,
>> 	- Downgrade attack protection,
>> 	- Mutual authentication,
>> 	- Internationalized,
>> 	- Channel Binding,
>> 	- Minimal Roundtrips.
>>  The group intends to consider a number of approaches, including
>> draft-newman-auth-scam and
>>  draft-josefsson-password-auth, as input.  Additionally, the WG will
>> deliver a document summarizing
>>  its DIGEST-MD5 concerns and requesting RFC 2831 be moved to
>> Historic status.  The WG intends to use
>>  draft-melnikov-digest-to-historic for a starting point for this
>> document.
>>
>> For those wanting to know more about the WG direction here, I would
>> guess they first read Alexey's draft,
>> then read Chris's draft and the WG list discussion regarding desired
>> qualities in the replacement.
>>
>> Anyways, comments on this suggested text?  Any suggested additions/
>> deletions to the list of desired qualities?
>> (For suggested additions, please offer text for the WG to consider.)
>>
>> -- Kurt
>>

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
Date: Tue, 1 Apr 2008 08:46:08 -0700
Sender: [email-masked]

A question came up off-list which I think needs to be explicitly  
addressed in the charter text.
	While the mechanism provide a security layer?

 From list discussions, I think the answer is:
	The replacement mechanism is expected not to provide a security layer  
itself, instead rely on
	security services provided at a lower layer (e.g., TLS) and channel  
bindings.

I recommend inserting this sentence just before "The WG is expected to  
strike..." and deleting the "channel binding" quality.

Also, as it is desirable to have a shorter list of qualities, I also  
recommend deleting "algorithm agility" and "minimal roundtrips"  
qualities.

Comments?

-- Kurt

On Mar 31, 2008, at 2:07 PM, Kurt Zeilenga wrote:
>
> I think the proposed charter text concerning DIGEST-MD5 to historic/ 
> replacement should be replaced with
> something like:
>
>  The group has determined that DIGEST-MD5 (RFC2831) is not suitable  
> for progression on the
>  Standards Track due to interoperability, internationalization, and  
> security concerns.  The group will
>  deliver a technical specification for a suitable password-based  
> challenge/response replacement mechanism
>  for Standard Track consideration.  The replacement mechanism is  
> expected to be "better than" DIGEST-MD5
>  from a number of perspectives including interoperability,  
> internationalization, and security.  The
>  WG is expected to strike a consensus-supported balance between the  
> many qualities desired in the
>  replacement.  Desired qualities include (but is not limited to):
> 	- Use of well understood and broadly-implemented algorithms (e.g.,  
> HMAC, SHA1),
> 	- Algorithm agility,
> 	- Negotiated key hardening iteration count,
> 	- Downgrade attack protection,
> 	- Mutual authentication,
> 	- Internationalized,
> 	- Channel Binding,
> 	- Minimal Roundtrips.
>  The group intends to consider a number of approaches, including  
> draft-newman-auth-scam and
>  draft-josefsson-password-auth, as input.  Additionally, the WG will  
> deliver a document summarizing
>  its DIGEST-MD5 concerns and requesting RFC 2831 be moved to  
> Historic status.  The WG intends to use
>  draft-melnikov-digest-to-historic for a starting point for this  
> document.
>
> For those wanting to know more about the WG direction here, I would  
> guess they first read Alexey's draft,
> then read Chris's draft and the WG list discussion regarding desired  
> qualities in the replacement.
>
> Anyways, comments on this suggested text?  Any suggested additions/ 
> deletions to the list of desired qualities?
> (For suggested additions, please offer text for the WG to consider.)
>
> -- Kurt
>

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 1 Apr 2008 16:44:12 +0200
To: Jeffrey Hutzelman <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Chris Newman <[email-masked]>, Simon Josefsson <[email-masked]>, <[email-masked]>
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Sender: [email-masked]

Jeffrey Hutzelman writes:
>On Mon, 31 Mar 2008, Hallvard B Furuseth wrote:
>> 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.)
>> (...)
> 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.

> 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.

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

> 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.

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.

> The important properties are these:
>
>>> 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.

Yup.

-- 
Hallvard

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: "Frank Ellermann" <[email-masked]>
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
Date: Tue, 1 Apr 2008 00:28:11 -0700
Sender: [email-masked]

On Mar 31, 2008, at 10:06 PM, Frank Ellermann wrote:
>
> Kurt Zeilenga wrote:
>
>> The group has determined that DIGEST-MD5 (RFC2831) is not suitable
>> for progression on the Standards Track due to interoperability,
>> internationalization, and security concerns.
>
>
> What I18N concerns ?

For one, lack of a specified character data normalization algorithm and
character encoding for passwords.

> The only security concern I've heard of is the lack of channel
> bindings, did I miss something important ?

Prone to downgrade attack.

Before I respond to your per-quality comments, I note that the short  
list of desired qualities is not intended to impart any requirements  
upon the deliverable.  The list is certainly not inclusive of all the  
desired qualities.  I did purposely try to list some qualities which  
can be consider opposed to each other.

In talking with Pasi, he suggested we keep this list short of key  
qualities.

>> Use of well understood and broadly-implemented algorithms (e.g.,
>> HMAC, SHA1),

>>
>
> Not everybody likes SHA1, and those who like SHA1 are supposed to
> like SHA2 better.

SHA1 is only listed an example of a well-understood and broadly- 
implemented
algorithm.

>
>> Algorithm agility
>
> That's a SASL feature, one side offers what it can do, the other
> side picks what it supports and considers as best.  ITYM hash
> agility, the mechanism must allow to be cloned for another hash.
> No additional negotiation "within" the new mechanism.

There has also been talk of why it might be desirable to provide  
agility within the mechanism.

>
>> Negotiated key hardening iteration count,
>
> When H(x) is not "hard enough", then H(H(x)) shuffling the bits
> again using the same H is not necessarily "harder".  It might
> be interesting to look at H(x||count) or RMX if the PBKDF2 idea
> turns out to only burn cycles, instead of being really "harder".

Just another desirable (to some) quality.

>
>
>> Downgrade attack protection,
>
> I'm not sure what you have in mind.  When one side offers SASL
> mechanisms A, B, and C, the other side can only pick, or say
> "not good enough" - especially if it knows that there used to
> be a better D when not talking to an attacker.

I listed this specifically because DIGEST-MD5 feature negotiation
is prone to downgrade attacks.

>
>
>> Channel Binding,
>
> Unfortunately I'm not sure what this means.  Is this about
> A <- TLS -> M <- TLS -> B, when A and B happily use SASL PLAIN
> and don't know that they really talk "via" an attacker M ?  Do
> channel bindings imply to use TLS ?

This means that it would be desirable for the mechanism to be capable  
of securely binding the ends points of a lower-level security channel,  
such as provided by TLS, to the end points of the mechanism exchange.

>
>
>> Additionally, the WG will deliver a document summarizing its
>> DIGEST-MD5 concerns and requesting RFC 2831 be moved to
>> Historic status.
>
> What will the WG do with standards having a normative reference
> to RFC 2831 ?

Nothing.  The WG is not in the business of updating SASL profiles for  
application profiles.

-- Kurt